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