Представьте, что обычно Вы носите костюмы, а также, что Вы — образец счастливого менеджера проекта по разработке ПО. Вы гладко выбриты, от Вас вкусно пахнет новой туалетной водой, галстук идеально сочетается с рубашкой, стрелки на брюках отутюжены и Вы просто излучаете правильность, уверенность и оптимизм.
Еще бы, ведь Вам достался новый, интересный, денежный, но вполне предсказуемый проект. Он конечно слегка сжат по срокам, но Вы уже имеете опыт реализации подобный проектов и подстраховались от всех шероховатостей, которые только смогли придумать. Даже после подстраховки, у Вас остался небольшой запас по срокам, которого по всем расчетам должно хватить, чтобы успеть выкрутиться даже если произойдет что-то разумно непредвиденное. Заказчик — крупная компания, этот проект будет отличной строчкой в Вашем резюме и в портфолио Вашей компании.
Вчера Вы отправили клиенту по почте первый прототип с Вашими комментариями. А сегодня вас в ящике должно ждать письмо о том, что…
… все, что вы делаете — неправильно и неверно и все нужно переделать.
Вы начинаете анализировать весь Ваш предыдущий опыт и пытаетесь понять где же именно Вы совершили ошибку. Казалось бы все шло как по маслу. Вы решили, что в условиях сжатых сроков вы сначала утвердите с клиентом интерфейс и общие требования к приложению, потом предоставите первый прототип и параллельно будете разрабатывать функционал, делая клиенту много поставок и оперативно согласовывая изменения.
До того, как разработать прототип, вы провели несколько совещаний с клиентом, разработали wireframes, показали, получили одобрении и получилось все в итоге… неправильно и неверно.
Где же Вы ошиблись? А вот где, в связи со сжатыми сроками, Вы углубились в непосредственное планирование и управление командой и не удостоверились, что заказчик действительно углубился в тот набор страниц и функциональных требований, что вы прислали. Заказчик тоже занятой, у него вот-вот случится что-то важное и Ваш проект всего лишь одна из шестеренок, которые должны крутиться в огромном маховике. А теперь когда он может посмотреть на живой пример, он прекрасно понимает, что этот пример совсем не похож на образец из его головы. Ну может только чуть чуть. Можно конечно вступать в открытую конфронтацию, приводить цитаты из договора, занимать жесткую позицию, только все это не приведет к написанию системы, проект будет провален, если Вы и получите прибыль, то наверняка она будет много меньше ожидаемой, а Ваша репутация, даже в случае полной Вашей невиновности все равно будет слегка запятнана.
При разработке внутренней системы для журналистов пресс-центра XI Петербургского международного экономического форума я работал в условиях очень сжатых сроков, но в общем то достатка времени. И вот, когда я, с некоторым опережением, отдал задание программисту на реализацию дополнительных функциональных требований на основе существующего решения, я послал клиенту дизайн и получил полный разнос. Я недоумевал, ведь я до этого согласовал все макеты страниц! Однако факт был фактом, и это стоило мне нескольких бессонных ночей, потери части прибыли и кучи нервных клеток. С тех пор, я всегда стараюсь заставить заказчика вникать в проект на всех его этапах, а не только на тех, на которых ему удобно это делать.
Как же избежать этой опасности? Рецепт настолько же прост, насколько и сложен. Вам придется в любом случае, выделить время на то, чтобы убедиться, что Ваши с заказчиком мысли сходятся, или как минимум предельно близки к этому. Этому процессу может помочь:
Если у вас есть мысли как еще можно предотвратить подобные ситуации, Вы можете оставить их в комментария или высказать мне лично. Успехов Вам и Вашим проектам!
Оригинал: Управление рисками. Работа с заказчиком
Еще бы, ведь Вам достался новый, интересный, денежный, но вполне предсказуемый проект. Он конечно слегка сжат по срокам, но Вы уже имеете опыт реализации подобный проектов и подстраховались от всех шероховатостей, которые только смогли придумать. Даже после подстраховки, у Вас остался небольшой запас по срокам, которого по всем расчетам должно хватить, чтобы успеть выкрутиться даже если произойдет что-то разумно непредвиденное. Заказчик — крупная компания, этот проект будет отличной строчкой в Вашем резюме и в портфолио Вашей компании.
Вчера Вы отправили клиенту по почте первый прототип с Вашими комментариями. А сегодня вас в ящике должно ждать письмо о том, что…
… все, что вы делаете — неправильно и неверно и все нужно переделать.
Вы начинаете анализировать весь Ваш предыдущий опыт и пытаетесь понять где же именно Вы совершили ошибку. Казалось бы все шло как по маслу. Вы решили, что в условиях сжатых сроков вы сначала утвердите с клиентом интерфейс и общие требования к приложению, потом предоставите первый прототип и параллельно будете разрабатывать функционал, делая клиенту много поставок и оперативно согласовывая изменения.
До того, как разработать прототип, вы провели несколько совещаний с клиентом, разработали wireframes, показали, получили одобрении и получилось все в итоге… неправильно и неверно.
Где же Вы ошиблись? А вот где, в связи со сжатыми сроками, Вы углубились в непосредственное планирование и управление командой и не удостоверились, что заказчик действительно углубился в тот набор страниц и функциональных требований, что вы прислали. Заказчик тоже занятой, у него вот-вот случится что-то важное и Ваш проект всего лишь одна из шестеренок, которые должны крутиться в огромном маховике. А теперь когда он может посмотреть на живой пример, он прекрасно понимает, что этот пример совсем не похож на образец из его головы. Ну может только чуть чуть. Можно конечно вступать в открытую конфронтацию, приводить цитаты из договора, занимать жесткую позицию, только все это не приведет к написанию системы, проект будет провален, если Вы и получите прибыль, то наверняка она будет много меньше ожидаемой, а Ваша репутация, даже в случае полной Вашей невиновности все равно будет слегка запятнана.
При разработке внутренней системы для журналистов пресс-центра XI Петербургского международного экономического форума я работал в условиях очень сжатых сроков, но в общем то достатка времени. И вот, когда я, с некоторым опережением, отдал задание программисту на реализацию дополнительных функциональных требований на основе существующего решения, я послал клиенту дизайн и получил полный разнос. Я недоумевал, ведь я до этого согласовал все макеты страниц! Однако факт был фактом, и это стоило мне нескольких бессонных ночей, потери части прибыли и кучи нервных клеток. С тех пор, я всегда стараюсь заставить заказчика вникать в проект на всех его этапах, а не только на тех, на которых ему удобно это делать.
Как же избежать этой опасности? Рецепт настолько же прост, насколько и сложен. Вам придется в любом случае, выделить время на то, чтобы убедиться, что Ваши с заказчиком мысли сходятся, или как минимум предельно близки к этому. Этому процессу может помочь:
- Последовательное обсуждение всех предварительных результатов, последовательно, один за одним;
- Вопросы, которые заставят заказчика изучать материалы и размышлять над ними (Посмотрите! Если следовать логике будущего приложения на макетах с 8 по 12, не кажется ли Вам, что блок конечной информации стоит дополнить во-о-от этими данными и расположить чуть ниже и левее, как это сделано на макете 14?);
- Контроль проекта со стороны нескольких представителей заказчика;
- Упор на личные встречи или видео конференции, чем на телефонные звонки и электронные средства связи.
Если у вас есть мысли как еще можно предотвратить подобные ситуации, Вы можете оставить их в комментария или высказать мне лично. Успехов Вам и Вашим проектам!
Оригинал: Управление рисками. Работа с заказчиком
