Проектирование в agile-процессе. График работы команд разработки и аналитики

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

Про выстраивание процесса проектирования с учетом интересов команды разработки я недавно писал. В третьей части материала как раз говорится о том, как мы пытаемся решать проблему сроков. Эту же темы мы с коллегами поднимали в апрельском выступлении на конференции РИТ-2008.

Если вкратце, то вся работа разбивается на три части — концепция, интерактивный прототип и поддержка спецификации. Для каждой из них в идеале заключается свой договор, идущий по разным методикам. Концепцию удобнее прорабатывать по классической схеме с четким календарным планом. Интерактивный прототип бывает проще создавать в agile-процессе. Правда, такой подход годится не для всех проектов — в основном там, где важнее функциональные, а не потребительские качества продукта. Поддержку спецификации удобнее вести по чистому agile, но иногда удобнее иметь готовый пакет документации сразу, сделав все одним махом без всяких итераций.

Хочется расписать эту схему подробнее. Для начала важно понять, что вообще важно во всем этом деле заинтересованным лицам проекта — заказчику, разработчикам, проектировщикам:

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

Определяющий здесь — первый пункт. Исходя из задач клиента мы определяем ключевые вехи, которые говорят что к “такому-то числу должно быть готовы такие-то вещи”. Под них строится и весь процесс работы. Он может отличаться в каждом конкретном случае, но в целом придерживается следующей схемы. Которая при этом удовлетворяет и остальным пунктам списка:

Этап 1. Pre-Sale

1-2 недели (хотя случается и полгода, и год)

Отдел проектирования

Предварительный анализ проекта, описание объема работ, оценка сроков и стоимости работ.

Документы

коммерческое предложение;
договор на проработку концепции.

Отдел разработки

Предварительная оценка сроков, трудозатрат и рисков проекта.

Документы

нет формализованных документов.

Этап 2. Сбор требований и проработка концепции

2-4 недели

Отдел проектирования

Бизнес-анализ и сбор требований. Планирование работ по детальному проектированию.

Документы

видение проекта;
описание целевой аудитории;
краткие сценарии взаимодействия;
перечень функциональности;
карта сайта;
черновые структурные схемы страниц;
договор на детальное проектирование бета-релиза;
перечень функциональности бета-релиза;
перечень функциональности финального релиза;
устав проекта.

Отдел разработки

Выбор технологической платформы, планирование работ, сбор команды.

Документы

план работ по разработке;
оценка рисков;
эксплуатационные требования;
договор на разработку альфа-релиза.

Этап 3. Интерактивный и функциональный прототип (альфа-релиз)

1-2 месяца

Отдел проектирования

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

Документы

структурные схемы страниц;
дизайн-макеты страниц;
интерактивный прототип;
атрибуты и методы сущностей;
критерии приемки функциональности;
договор на детальное проектирование финального релиза.

Отдел разработки

Разработка альфа-релиза продукта (ядро + модули без дизайна) по договору с фиксированной ценой и сроками.

Документы

функциональный лист (backlog);
отчетность о ходе проекта;
доработка существующих документов;
договор на agile-разработку.

Этап 4. Бета-релиз

1,5-3 месяца

Отдел проектирования

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

Документы

Отдел разработки

Разработка и отладка бета-релиза продукта по agile-договору.

Документы

план тестирования;
отчетность о ходе проекта;
доработка существующих документов.

Этап 5. Финальный релиз

2-6 месяцев

Отдел проектирования

Доработки документации по запросу команды разработки.

Документы

доработка существующих документов.

Отдел разработки

Разработка и отладка финального релиза продукта по agile-договору.

Документы

сопроводительная документация к проекту;
доработка существующих документов.

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

Есть здесь один спорный вопрос по поводу того, нужно ли продолжать активное проектирование после сдачи интерактивного прототипа. Точнее, проблема даже глубже — нужно ли вести проектирование по agile, если разработка идет по гибким методикам? Я уверен, что как минимум ключевую функциональность нужно детально спроектировать до начала ее окончательного внедрения. После чего вести ее поддержку и обновление. Важно ведь не только красиво расставить кнопки в форме, но и понять, нужна ли вообще вот эта конкретная форма — в этом модуле или проекте в целом. Но это отдельная тема. Которую, наверное, я также скоро распишу.

P.S. Общий вид диаграммы Ганта на основе описанного выше графика. Так он смотрится куда нагляднее.

P.P.S. Отмечу соавторство Юры Шиляева — он руководит минским офисом разработки нашей компании и именно с ним мы доводим эту схему до ума в ходе работы над проектами.

‍