Customer satisfaction для программистов: Проблем быть не должно

Как однажды сказал Сергей Архипенков: «Если у проекта нет проблем, значит он умер». Проблемы при разработке ПО есть всегда. С другой стороны, заказчика нужно оградить от лишней головной боли, для него проблем быть не должно. Здесь главный вопрос в том, как эти проблемы преподносить заказчику?

Известны случаи, когда разработчики каждое утро присылали заказчику список проблем с надеждой, что он их решит. Так они и работали, но совсем недолго и завершили работу в плохих отношениях.

Customer satisfaction для программистов: Все программисты — оптимисты

Ничего не раздражает заказчика больше, чем неверная оценка сроков. Ничего не делает давление на разработчика сильнее, чем неправильно оценненная задача. Причем со временем развития IT-отрасли мало что меняется. Вот цитата из классической книжки Мифический человеко-месяц, которая была выпущена около 40 лет назад:

Возможно, эта современная разновидность колдовства особенно привлекательна для тех, кто верит в хэппи-энды и добрых фей. Возможно, сотни неудач отталкивают всех, кроме тех, кто привык сосредоточиваться на конечной цели. А может быть, дело всего лишь в том, что компьютеры и программисты молоды, а молодости свойствен оптимизм. Как бы то ни было, в результате одно: «На этот раз она точно пойдет!» Или : «Я только что выявил последнюю ошибку!»

Итак, в основе планирования разработки программ лежит ложное допущение, что все будет хорошо, т.е. каждая задача займет столько времени, сколько «должна» занять. (с) Брукс

Customer satisfaction для программистов: Доверие и прозрачность

Есть отличная статья Управленческие инструменты: Почему заказчики требуют дурацкие отчеты? от компании Stratoplan. Рекомендую прочитать саму статью, а здесь я коротко опишу как мы используем матрицу 2x2 в своей работе.

Рисуем матрицу, где по одно оси «Прозрачность» вашей работы для заказчика, а по другой «Доверие» заказчика к вам:

Customer satisfaction для программистов: Визуализация

Одна из ключевых практик в Kanban — это визуализация работы: «You cannot improve what you cannot see». Следующие три подхода нацелены на визуализацию целей проекта, задач и текущего процесса.

Customer satisfaction для программистов

Часто разработчики говорят мне, что soft skills им не нужны. Разработчик — не менеджер и управленческие навыки может не развивать. С одной стороны так и есть — разработчику очень важно углублять свои знания в технологиях и методологиях проектирования ПО. С другой стоны, я уверен, каждому хочется уметь отстаивать свою позицию и получать заслуженную похвалу за хорошую работу. А если так, то почему бы не продвинуться в этом направлении?

В этой статье я собрал техники и подходы, которые помогают мне в повседневной работе наносить непоправимую пользу заказчику и самому оставаться с позитивным настроем. Предлагаю их вам на пробу и надеюсь для вас они будут также полезны как и для меня.

Серия статей «Customer satisfaction для программистов»

Материала получилось довольно много, поэтому каждый раздел выйдет отдельной статьей:

Под «заказчиком» я имею ввиду любые отношения заказчик-исполнитель, где вы являетесь исполнителем. Заказчиками могут быть пользователи вашего продукта, может быть Project Manager, может быть совет директоров, может быть бухгалтер из соседнего отдела и т.д.

Всё, о чём будет идти речь, точно сработает, если вы действительно хорошо сделали свою работу. Мы не будем рассматривать случаи, когда качество работы низкое и стоит задача убедить заказчика в обратном.

Модель принятия решений

Когда-то меня вдохновило выступление Евгения Кривошеева Design & Process Models. В нём рассматривается много аспектов разработки ПО, рекомендую выделить 2 часа и посмотреть видео целиком. Сейчас я хочу остановится на взаимодействии связанных между собой моделей и том, как это можно использовать в повседневной работе:

  • Business Model — бизнес заказчика, на чём он зарабатывает деньги.
  • Process model — как должен быть устроен процесс формирования ценности: этапы, фазы, роли, артефактры для получения ценности. Описывает также порядок появление нижележащих моделей и их взаимодействие. Например, пишем код и рефакторим до хорошего дизайна или сначала делаем дизайн (upfront) и потом пишем код.
  • Requirements Model + Domain Model — какие требования есть к продукту/проекту, тексты, UML-диаграммы и т.д.
  • Design Model — архитектура, шаблоны проектирования и т.п.
  • Implementation Model — исходный код

Моя книга «Антихрупкость в IT»

Как достигать результатов в IT-проектах в условиях неопределённости. Подробнее...