Проект должен заканчиваться?

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

И это действительно так, если ваша бизнес-модель — сервис, т. е. ваша работа ориентирована на процесс, и ваши ресурсы изначально приспособлены для этого (тщательно подобраны, зарезервированы на неопределенный срок, готовы к регулярной и рутинной работе по переделкам, допилкам, обновлениям).

Но если это не так, тогда, вероятно, самое важное для вас — это результат, и именно на его достижение направлены все силы. Вы тщательно планируете проект, составляете график работ, расписываете количество итераций. Весь рабочий аппарат готовится к тому, чтобы заверить проект в назначенный срок. В этом случае каждая дополнительная непредвиденная итерация будет болезненна для вас, несмотря на то что денежный поток по-прежнему идет. В худшем случае вам уже не будут интересны деньги, и вы будете думать только о том, как бы скорее покончить с проектом, потому что за это время все ваши сотрудники взвыли и переругались и уже думают, куда бы уйти.

Как разглядеть «бесконечный» проект?

Едва ли можно сказать, что есть универсальный способ выявить проблемный проект еще на берегу. (Заметим, что «проблемный» не означает, что от этого проекта нужно отказаться, а только что к нему следует быть готовым. Хотя бы морально.) Однако некоторые общие тревожные маячки, которые дадут повод задуматься, вполне можно назвать.

а) Нет четкого ТЗ.

Само по себе отсутствие ТЗ — это норма. Особенно в области разработки UI. Ведь заказчик для того вас (или нас) и нанимает, чтобы вы сделали лучше, чем он сам. И платит он за то, чтобы вы подумали, проанализировали, подумали еще раз и предоставили спасительное решение. Речь идет о том, что заказчик, как правило, по той или иной причине не готов составить четкое техническое задание. Как это выглядит? Позиция заказчика в проекте только условно активна. Т. е. он охотно дает доступ к информации, проводит встречи, выслушивает предложения, дискутирует. В конце каждой встречи составляется протокол, который подписывают все участники. А потом в течение итерации, которая началась по итогам совещания, члены рабочей группы начинают что-то вспоминать и додумывать, к ним присоединяются другие, и пошло-поехало. А иногда и вовсе по кругу: вчера решили заменить «А» на «Б», а сегодня подумали — и вернули обратно. И это при том, что всё каждый раз фиксируется.

Что делать?

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

Чего мы этим достигаем?

• Члены рабочей группы более ответственно относятся к собственным решениям и активнее участвуют в работе по проекту.

б) У заказчика нет одного главного менеджера проекта, зато в наличии большое количество ответственных лиц (рабочая группа, где каждый отвечает за свой кусок).

Чем больше активных участников, тем больше мнений. А также писем, их цепочек, комментариев, комментариев на комментарии — и так до бесконечности. В какой-то момент следить за ходом дискуссии становится сложно. Особенно потому, что каждый из ее участников — компетентный специалист (главный по своему направлению) и его мнение крайне важно для проекта. В итоге складывается ситуация, когда «картин проекта» на стороне заказчика столько же, сколько специалистов в рабочей группе и нет никакой возможности для экспертной оценки (что надо, что не надо, что показать, что спрятать, что потом и т. д.). Сопутствует этому постоянно растущая гора версий рабочих документов.

Что делать?

• Любыми способами стараться добиться того, чтобы заказчик назначил ответственным за проект одного человека, который будет видеть общую картину, понимать приоритеты и сглаживать противоречия.

Чего мы этим достигаем?

• Процесс совместной работы с заказчиком становится линейным.
• Изменения в проекте легко отследить.
• Ответственность заказчика за принятие решений не распыляется.

в) Нет точного срока запуска.

Если у проекта нет четкой даты релиза, пусть даже она смещается из-за объективных причин, то заказчик может утратить понимание временных рамок проекта (не намеренно, конечно). В такой ситуации задачи ставятся неконкретно, критерии оценки размываются, а заказчик пытается перебрать все возможные варианты в поисках идеала и подключить сторонних экспертов. И в результате проекту не видно конца — даже если после многочисленных переделок лучшим решением оказывается первое из предложенных.

Что делать?

• Постоянно следить, насколько текущие задачи тормозят разработку.
• Определять и фиксировать параметры, критически важные для запуска проекта.
• Делать акцент на том, что достигнутые результаты соответствуют требованиям и не могут быть причиной отложить запуск.

Чего мы этим достигаем?

• Помогаем заказчику понять, что срок запуска его проекта зависит скорее от того, как скоро он начнет разработку, чем от того, насколько «вылизан» прототип или дизайн.

Какие опасности есть в процессе работы?

Главные враги в жизненном цикле проекта — изменение реальности проекта до того, как он закончен. Например:

• внезапное появление в рабочей группе новых специалистов со своим пониманием того, что и как должно быть;
• регулярные дополнения к фиксированным требованиям и договоренностям;
• текучесть контента заказчика в процессе работы: вы занимаетесь своей разработкой, а заказчик параллельно — своей, и в итоге пока вы разрабатывали всё по согласованному ТЗ, условия заказчика изменились.

Что делать?

• Фиксировать проделанную работу и получать подтверждение заказчика, что на момент до изменения реальности проекта всё было сделано правильно и согласно поставленным задачам, а значит к этой части работы у него не должно быть претензий (то же и со сроками).

Чего мы этим достигаем?

• Заказчик понимает, что мы всё делаем правильно и в соответствии с его требованиями. И даже если реальность проекта изменилась, клиент остается уверенным, что он работает с нужными людьми и последующая совместная деятельность будет столь же продуктивной. .
• Мы в свою очередь понимаем, что не сваляли дурака и всё делали как надо. Заказчик нами доволен, и поэтому у нас не возникает упаднических настроений и ощущения, что наша работа была проделана зря.

На закуску. Прототип — это не дизайн!

Это, пожалуй, один из самых тонких моментов. Не то чтобы это сильно мешало процессу разработки, но не упомянуть об этом было бы небрежностью с нашей стороны. Наш опыт показывает, что в большинстве случаев термины «прототип» и «дизайн» для заказчика тождественны. Почему это неудобно? Потому что к обсуждению функциональности прототипа примешиваются личные переживания клиента относительно стиля кнопок, иконок и т. п.

Что делать?

• Улыбаться и каждый раз уточнять, что проектирование — это исключительно функциональная задача.

Чего мы этим достигаем?

• Сохраняем фокус внимания заказчика (да и наш собственный) на том, что важно в данный момент (например, на прототипе).

Итого

В каждом проекте всегда существует множество нюансов, связанных и с типом проекта, и с заказчиком, и со спецификой отрасли. Самое главное в управлении проектом — относиться к нему внимательно на всех его стадиях и стараться принимать меры при первых же тревожных сигналах. Удачи!

Павел Сушков

Я бы добавил, что трудозатраты и сроки могут расти, если в проекте несколько подрядчиков и у них нет опыта взаимодействия между собой. Это один из индикаторов потенциальных «бесконечных» проектов, о которых говорит Илья. Заказчик часто (и это разумно) рассматривает подрядчиков, как одну команду и принимает результат, как у одной команды. Это значит, что подрядчикам в начале и в течение проекта нужно договариваться о порядке взаимодействия, синхронизировать результаты работ, следить за тем, чтобы параллельные направления не противоречили друг другу. На это нужно время (иногда много времени), но еще возрастает вероятность срабатывания специфичных рисков, которые легко могли быть не заложены в проект.

О Time & Material: даже при повременной оплате у заказчика есть бюджет. Иногда перед началом работ просят сказать планируемые трудозатраты, и когда в конце выясняется, что реальность сильно превышает план, возникают вопросы и различные схемы переноса оплаты на следующие периоды в целях вписаться в текущий бюджет. По факту разница с Fixed Price бывает малозаметной и сводится к удобству в каких-то технических вещах. Ну и для заказчика бывает дешевле. Золотая жила здесь не столько в способе расчета между заказчиком и подрядчиком, сколько в сложившихся отношениях и стабильном потоке работ.

Проблема с восприятием прототипа как готового дизайна есть, но она вполне решается показом прототипов в таком виде, чтобы заказчик не заподозрил в нем дизайн или его зачатки. Вплоть до экранов в ЧБ-исполнении, полного отсутствия градиентов и использования очевидно неподходящих к дизайну шрифтов вроде Comic Sans :)

Александр Цыбульский
Креативный директор в Hardheaded

Хотелось бы внести свое мнение о том, как постараться сделать так, чтобы проект превратился из бесконечного в более четко определяемый во времени.

1. При отсутствии четкого ТЗ, и даже при его наличии составлять документ «Перечень работ» (Scope of works). Именно этот список будет аргументом в ситуациях, когда клиент просит то, чего не упоминал ранее.
2. Списки правок и замечаний должны быть консолидированы, то есть содержать финальную информацию, собранную внутри компании клиента. Никаких «менеджер N предложил внести» или «Ой, мы передумали».
3. Количество раундов правок должно быть ограничено. Обычно, их 3-5.
   
4. Определить максимальное количество часов для проекта, даже и особенно для проектов с фиксированным бюджетом.
5. На уровне Договора определить ответственного менеджера от компании клиента.
6. Использовать гибкие методологии для планирования.
7. Определить точные сроки сдачи результатов итераций проекта.

Подытожив хочется сказать, что дизайн-процесс почти всегда невозможно вписать в перечисленные выше правила. Это всегда творческий процесс, и помочь завершить проект вовремя, сохранить отличное качество и UX будущего продукта поможет только полное взаимопонимание клиента и исполнителя, активное участие клиента в процессе, понимание сложности дизайн-процесса.

Алексей Шишкин
Генеральный директор в Redsoft

Илья, классный подход к подаче материала!
Но истина дороже..
Прототип — это не дизайн! Это утверждение так же верно, как и то, что вода в чайнике кипит при 100 градусов (температура на самом деле зависит от давления и состава воды).
Мы (разработчики разных компаний) давно запутали коллег, насколько близко должен дизайн  соответствовать сделанным прототипам. У одних разработчиков дизайнеры просто раскрашивают прототипы, у других — дизайн совершенно не похож на прото, третьи сразу делают прото в дизайне (и
обычно проигрывают). На самом деле степень соответствия отличается для разных типов проектов.
Для сервисов (например, калькулятора кредитов) дизайн действительно может свестись к раскраске, если прототип продуман и сделан правильно. Для промосайта дизайн будет напоминать о нем только несколькими похожими заголовками. Главное — договориться об этом на берегу — до начала проектирования, или на худой конец, дизайна — и это задача менеджера проекта.

Хочу еще отметить, что долгострои требуют более плотного (подробного) проектирования именно из-за риска изменения требований и фиксировать стоит каждый новый этап проектирования (мы это делаем на старте каждого спринта)