Часто разработчики говорят мне, что soft skills им не нужны. Разработчик — не менеджер и управленческие навыки может не развивать. С одной стороны так и есть — разработчику очень важно углублять свои знания в технологиях и методологиях проектирования ПО. С другой стоны, я уверен, каждому хочется уметь отстаивать свою позицию и получать заслуженную похвалу за хорошую работу. А если так, то почему бы не продвинуться в этом направлении?
В этой статье я собрал техники и подходы, которые помогают мне в повседневной работе наносить непоправимую пользу заказчику и самому оставаться с позитивным настроем. Предлагаю их вам на пробу и надеюсь для вас они будут также полезны как и для меня.
Серия статей «Customer satisfaction для программистов»
Материала получилось довольно много, поэтому каждый раздел выйдет отдельной статьей:
- Визуализация
- Доверие и прозрачность
- Все программисты — оптимисты
- Проблем быть не должно
- Используем Domain Driven Design
Под «заказчиком» я имею ввиду любые отношения заказчик-исполнитель, где вы являетесь исполнителем. Заказчиками могут быть пользователи вашего продукта, может быть Project Manager, может быть совет директоров, может быть бухгалтер из соседнего отдела и т.д.
Всё, о чём будет идти речь, точно сработает, если вы действительно хорошо сделали свою работу. Мы не будем рассматривать случаи, когда качество работы низкое и стоит задача убедить заказчика в обратном.
Ниже слайды и видео с конференции, где эта тема обсуждалась:
Выступление на HappyDev'14 на эту же тему с вопросами из зала
На видео и в слайдах (22-й слайд) есть упоминание про принятие решений на разных уровнях. Эту тему я вынес в отдельную статью Модель принятия решений.
На выступлениях не удалось полностью раскрыть часть тем. Дальше статья с более подробными комментариями и ссылками.
Когда возникают проблемы?
Как часто бывает, что вы написали отличный код, решили задачу, а заказчик недоволен? Лично я в такие моменты думаю, что потратил силы, но не получил никакой отдачи.
Или такая ситуация: Вам дали систему, которая работает на костылях, попросили исправить несколько багов. Вы обнаружили в системе множество проблем, убрали весь г@внокод, заставили систему работать, буквально совершили чудо. Оказалось, что до ваших исправлений она в принципе не работала, но заказчик об этом не знал. В итоге, заказчик предъявляет вам претензии из-за низкой скорости работы — он не понимает как можно было так долго исправлять несколько ошибок.
Ещё типичный случай: Заказчик попросил добавить новую фичу в систему. После того, как вы её реализовали, вам говорят, что она совсем не нужна бизнесу, по крайней мере в такой реализации. Заказчик удивляется, как вы, такой профессионал, могли позволить ему заплатить за эту нелепую фичу.
Во всех этих случаях мы с одной стороны написали качественный рабочий код, но чего-то не хватило, чтобы результат был оценён заказчиком по достоинству. Если хотите, то у нас не получилось «продать» результат заказчику.
Не все заказчики одинаково полезны
Надо отметить, что заказчики бывают разные. Не от всех стоит ожидать радости по поводу высокого качества работы. В некоторых случаях ваши старания в принципе никто не собирается ценить. Несколько полу-юмористических случаев из не-IT, которые можно спроецировать на нашу работу:
У платного врача:
— Вы знаете, я, пожалуй, не буду платить за прием. Как-то мне диагноз не понравился. Изюминки нет, понимаете ли.
В диагностической лаборатории:
— Почему я должен платить за анализ вперед? А если вы ничего не найдете?
В туристической фирме:
— Нет, вы меня сначала свозите в несколько отелей, покажите, дайте выбрать. Тогда и решим.
В магазине:
— Я вот тут бутылку минералки купил у вас. Налил, отпил и внезапно понял, что минералки я сегодня не хочу. Поменяйте ее на квас. Какие деньги? Я же напиток оплатил!
В ресторане:
— А вы сначала сварите несколько блюд, дайте мне их все попробовать, а я уже потом оплачу, но только то, которое мне понравится.
С такими заказчиками лучше даже не начинать работу, ничего хорошего не произойдёт. Но если работать приходится, то заранее откажитесь от идеи, что вам скажут простое человеческое спасибо.
Делимся своим опытом
В комментариях будет интересно узнать про ваши способы нанесения заказчикам непоправимой пользы или услышать о том, что в вашем случае не работает.
Оригинал статьи вышел в CMS Magazine http://www.cmsmagazine.ru/library/items/programming/customer-satisfaction-for-programmers
Комментариев нет:
Отправить комментарий