MyStory: Выпуск №2 – Третий лишний

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

Дальше по тексту история Глеба и анализ истории в разрезе отношений с Заказчиком. Глеб в своем блоге написал выводы с точки зрения тестирования, а я в конце статьи напишу свои :).

История:

Мы работали с медицинской компанией, в свою очередь, сотрудничающей с частными медицинскими агентствами  США. Работали по SCRUMу, я отвечал за тестирование, также на проекте работали менеджер и несколько программистов, роль Product Ownera(PO), выполнял человек, являющийся посредником между конечными заказчиками и нами. Нам повезло в том, что PO, был бизнес аналитиком, поэтому Epics и User stories мы получали от него довольно вменяемые, что впоследствии сыграло с командой не добрую шутку. На демо PO, не выражал недовольства, но в итоге конечным заказчикам работа не нравилась. Каждый раз на Ретроспективе, команда поднимала вопрос о том, почему мы делаем все как надо, а когда это видит конечный заказчик, то ему работа не нравится. PO обещал разобраться с ситуацией, но результаты не менялись, немного помог прототип, разработанный нами. Мы надеялись, что прототип  поможет PO выяснить, что же на самом деле хотят заказчики. Было довольно сложно работать так как, казалось, что мы делаем все как надо, предлагаем различные варианты дизайна и архитектуры системы, а вот непосредственно контакт с заказчиками (в нашем случае бизнес аналитик) не может эффективно донести эту информацию в надлежащем виде и убедить заказчиков или прийти с ними к общему решению. Так продолжались первые несколько спринтов. Собственно последствия привели к тому, что система переделывалась несколько раз практически с нуля. Ситуация не из приятных: сроки сорваны, ожидания не выполнены, заказчик не доволен.

Теперь попробую дать свое видение ситуации и основных моментов, которые можно улучшить.

Самый общий комментарий: Любое дополнительное звено (человек) в цепи искажает информацию. Нет такого человека, у которого коэффициент искажения информации равнялся бы 0. На своих тренингах я привожу цитату Эдмонда Уелса:

Между тем, что я думаю, тем, что я хочу сказать, тем, что я, как мне кажется, говорю, тем, что говорю, и тем, что вы хотите услышать, тем, что, как вам кажется, вы слышите, тем, что вы слышите, тем, что вы хотите понять, тем, что вы понимаете, стоит десять вариантов возникновения непонимания. Но все-таки давайте попробуем…»

С точки зрения отношений с Заказчиком проект нельзя назвать провальным или даже плохим. Заказчиком для команды Глеба выступал посредник. Он платил команде, а значит, являлся Заказчиком. Сыграл риск того, что тот продукт, который разрабатывал Заказчик, не понравился конечным пользователям. Это точно также как команда, которой аутсорсят разработку игры не виновата в том, что игра не понравилась пользователям. Идея-то была не их :).

Вторым важным моментом, который, возможно(!), можно было улучшить – объяснить Заказчику что мы предоставляем сервис по «превращению идей в код». Мы не можем угадать мысли других людей, если они прямо нам об этом не скажут. И исходя из этого можно предложить следующие action items:

  1. В случаях сбора фидбека от реальных пользователей удобно пользоваться записью разговора. То есть демо, которое проходило на стороне конечных пользователей могло записаться в аудио-видео формате и презентовано команде. Возможно, это убрало бы лишние искажения.
  2. Спросить Заказчика: «Что вам может помочь сделать продукт лучше?». Возможно, предложить свои, так как команда обладает большим опытом демонстраций продуктов/прототипов Заказчику.

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

И последнее, если несколько вариантов системы не понравилось конечным пользователям, то возможно и продукт был не нужен. Заказчик сделал с вами концепт, попробовал и «не пошло». Что является абсолютно нормальным в бизнесе.

Jan 26th, 2011
No comments yet.

Leave a comment