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

25 февраля 2015 г.

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

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

Заказчики платят деньги за то, что мы берем ответственность на себя, поэтому отдавать «голые» проблемы не самый удачный вариант. Вместо этого я предлагаю хорошо прорабаывать каждую проблему прежде, чем показывать её заказчику. Что значит хорошо проработать проблему:

  1. Заказчик скорее всего не посвящает всё своё время вашему проекту, поэтому надо позаботится об описании контекста проблемы: почему так получилось, какие были предпосылки, на что сейчас это влияет, на что это не влияет и т.п.
  2. Придумать варианты решений внутри команды разработки
  3. Каждый вариант решения должен иметь описание плюсов и минусов относительно других вариантов
  4. Каждый вариант решения должен иметь список рисков, а каждый риск список мер, которые этот риск снижают

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

Заказчик может ошибаться

Что если вы предложили проработанное решение, но заказик настаивает на своём? При этом вы знаете, что решение заказчика ошибочное. Это может касаться любого аспекта разработки: архитектуры системы, инфраструктуры, командообразования и т.п. У нас есть 3 принципиальных варианта выхода из этой ситуации:

  1. Не спорить с заказчиком, просто согласиться с его ошибочным решением, т.е. отдать ему ответственность, стать исполнителем, ждать когда ошибка вызовет проблемы.
  2. Категорически не согласиться с решением заказчика, т.к. вы знаете, что окажетесь в проблемной ситуации. При этом возможен конфликт, где каждый останется при своем мнении.
  3. Детально разобрать решение, которое предлагает заказчик, т.е. расписать плюсы и минусы, риски и варианты снижения этих рисков. В качестве примера рассмотрим ситуацию, когда заказчик не хочет делать Impact Mapping для определения целей проекта, вместо этого он хочет просто прислать вам ТЗ. Можно сказать, что: мы не понимаем целей проекта, можем сделать что-то что не принесет денег и т.п. Если после этих объяснений заказчик всё равно настаивает на своём, т.е. берёт ответственность за эти явно описанные риски на себя, то можно с чистой совестью брать задачу в работу. Сохраните список проблем и рисков под рукой, они вам ещё пригодятся на ретроспективе при разборе ошибочного решения.

Я всегда стараюсь действовать в рамках 3-го варианта, т.к. явно описываются последствия для заказчика, идет попытка понять его решение. Первые два решения оставляют нас в однобокой и закрытой позиции.


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

Комментариев нет:

Отправить комментарий

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

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