Как однажды сказал Сергей Архипенков: «Если у проекта нет проблем, значит он умер». Проблемы при разработке ПО есть всегда. С другой стороны, заказчика нужно оградить от лишней головной боли, для него проблем быть не должно. Здесь главный вопрос в том, как эти проблемы преподносить заказчику?
Известны случаи, когда разработчики каждое утро присылали заказчику список проблем с надеждой, что он их решит. Так они и работали, но совсем недолго и завершили работу в плохих отношениях.
Заказчики платят деньги за то, что мы берем ответственность на себя, поэтому отдавать «голые» проблемы не самый удачный вариант. Вместо этого я предлагаю хорошо прорабаывать каждую проблему прежде, чем показывать её заказчику. Что значит хорошо проработать проблему:
- Заказчик скорее всего не посвящает всё своё время вашему проекту, поэтому надо позаботится об описании контекста проблемы: почему так получилось, какие были предпосылки, на что сейчас это влияет, на что это не влияет и т.п.
- Придумать варианты решений внутри команды разработки
- Каждый вариант решения должен иметь описание плюсов и минусов относительно других вариантов
- Каждый вариант решения должен иметь список рисков, а каждый риск список мер, которые этот риск снижают
Когда проблема подана с этими данными, заказчик может принять взвешенное и обоснованное решение благодаря вашей оценке. Плюсом будет лояльность заказчика, т.к. мы позаботились о нём.
Заказчик может ошибаться
Что если вы предложили проработанное решение, но заказик настаивает на своём? При этом вы знаете, что решение заказчика ошибочное. Это может касаться любого аспекта разработки: архитектуры системы, инфраструктуры, командообразования и т.п. У нас есть 3 принципиальных варианта выхода из этой ситуации:
- Не спорить с заказчиком, просто согласиться с его ошибочным решением, т.е. отдать ему ответственность, стать исполнителем, ждать когда ошибка вызовет проблемы.
- Категорически не согласиться с решением заказчика, т.к. вы знаете, что окажетесь в проблемной ситуации. При этом возможен конфликт, где каждый останется при своем мнении.
- Детально разобрать решение, которое предлагает заказчик, т.е. расписать плюсы и минусы, риски и варианты снижения этих рисков. В качестве примера рассмотрим ситуацию, когда заказчик не хочет делать Impact Mapping для определения целей проекта, вместо этого он хочет просто прислать вам ТЗ. Можно сказать, что: мы не понимаем целей проекта, можем сделать что-то что не принесет денег и т.п. Если после этих объяснений заказчик всё равно настаивает на своём, т.е. берёт ответственность за эти явно описанные риски на себя, то можно с чистой совестью брать задачу в работу. Сохраните список проблем и рисков под рукой, они вам ещё пригодятся на ретроспективе при разборе ошибочного решения.
Я всегда стараюсь действовать в рамках 3-го варианта, т.к. явно описываются последствия для заказчика, идет попытка понять его решение. Первые два решения оставляют нас в однобокой и закрытой позиции.
Серия статей «Customer satisfaction для программистов»:
Комментариев нет:
Отправить комментарий