Краткий гайд от бизнес- и технического руководителей центра компетенций разработки ITQ Group Даниэла Кнежевича и Максима Макеева.

Привет! Сегодня мы хотим поговорить о предпроектном исследовании — этапе разработки IT-проектов. 

Начнем с примера. Однажды, в одной финтех-компании выкатили на прод новую функциональность. Функциональность не заработала. Стали разбираться и выяснили,  что не учли необходимых изменений в кор. системе, а без них новая функциональность недееспособна. Пошли к разработчикам кор. системы: бэклог забит на год вперед, влезть вне очереди не получится. Спустя два года функциональность так и висит без релиза. Между тем, она важна для одного из бизнес-направлений, ее отсутствие несет нормативные риски для компании…

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

В материале разберём: для чего нужен предпроект, как его проводить и как убедить бизнес-заказчика потратить на него деньги. 

Начнем с базы. 

Что такое предпроект и зачем он нужен 

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

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

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

Какие вопросы задает предпроект и какие ответы предоставляет 

В рамках предпроекта команда формирует ответы на важные вопросы:

• цели и бизнес-эффекты проекта; 

• бизнес-, технические и инфраструктурные требования;

• участники проекта: системы/ответственные за эти системы лица/исполнители; 

• определение архитектурного решения (выполняется не всегда, но если выполняется, существенно повышает качество оценки); 

• скоуп работ; 

• временные затраты.  

И получает важные сведения: 

• набор требований заказчика;

• декомпозицию работ (разделение ее на отдельные задачи); 

• оценку трудозатрат и сроков реализации; 

• календарный план; 

• согласованный бюджет. 

В чем основная ценность предпроекта 

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

То же применимо и к запуску новых продуктов, разработке сложных систем: предпроект дает возможность максимально близко оценить как будущие затраты (чтобы впоследствии заложить их в бюджет), так и потенциальную выгоду от внедрения. И свести одно с другим. 

Помимо этого, предпроектное исследование дает возможность участникам проекта договориться и лучше понять цели друг друга, задачи и ограничения. 

Как предпроект работает с рисками 

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

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

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

А если бы предпроект был проведен, то сложности, появившиеся в ходе реализации, были бы понятны еще до старта разработки. У команды была бы возможность решить, что с этим делать: увеличивать бюджет, сроки или корректировать бизнес-требования.  

Если есть этап аналитики, то зачем нужен предпроект 

Скорее всего, у некоторых читателей к этому моменту уже назрел вопрос: а разве все перечисленные работы не относятся к этапу аналитики? Может, предпроект — это та же аналитика, только под другим названием? 

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

Этапы предпроекта 

Разберем основные этапы предпроекта. 

Этап 1. Согласовываем цели и бизнес-эффекты проекта. 

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

Например: 

• Запустить кредитный конвейер, который приведет к увеличению клиентской базы на 20% и повышению скорости оформления заявок на кредит в мобильном приложении на 2 минуты. 

• Изменить кнопку выдачи кредитной карты в МП с красной на зелёную, что позволит привлечь + 100 000 клиентов. 

• Разработать новую систему и перевести туда 100% пользователей из приложения, не удовлетворяющего требованиям регулятора. 

• Пересмотреть и изменить процесс оформления банковского продукта для улучшения пользовательского опыта: на 2 минуты сократить время оформления заявки, на 35% снизить количество обращений в поддержку. 

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

Этап 2. Формулируем бизнес-требования 

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

Сквозной этап. Проектирование UI 

Кажется, что это уж точно к предпроекту не относится, ведь UI обычно проектируют на этапе аналитики или после нее. Зачем заниматься этим раньше? 

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

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

Этап 3. Формируем архитектурное видение проекта 

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

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

Этап 4. Определяем скоуп работ 

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

Этап 5. Приступаем к оценке проекта: участники, виды работ, ресурсы 

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

Важный момент. Некоторые виды работ забывают учесть в оценке, в результате «едут» бюджет и сроки. Так что не забывайте о таких задачах: 

• модульное/авто/нагрузочное тестирование; 

• проверки на соответствие требованиям безопасности; 

• приемо-сдаточные испытания; 

• подготовка инструкций для пользователей; 

• подготовка и исполнения заявок на сетевые доступы. 

Можно ли все учесть в скоупе? Разумеется, нет.
Поэтому дополнительно к оценке объема закладываем: 

20% — когда все понятно 

30% — есть серые зоны 

50% — когда много неизвестного (вообще, это означает, что предпроект сделан некачественно). 

Этап 6. Определяем методологию ведения проекта. 

Этап методологии нужен для того, чтобы сформулировать и договориться о том, как именно будет происходить управление проектом. 

На какие вопросы отвечаем:

1. По какой методологии работаем: WATERFALL, SCRUM, KANBAN и т.д.  

2. Какие у нас стандарты разработки: 

   • Есть ли код-ревью? 

   • Подготовка и ревью технической, тестовой, архитектурной документации? Если да, то на каких этапах?

   • Как и какое именно тестирование проводится? 

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

3. Как будет происходить взаимодействие между командами:

   • Как команды синхронизируются? 

   • Кто участвует во встречах: РП или представители команд? 

   • Как часто проходят встречи?  

4. Как и с какой частотой синхронизируемся с бизнес-заказчиком? 

5. Как происходят приемо-сдаточные испытания? 

6. И т.д.

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

Этап 7. Разрабатываем и согласовываем план проекта

Берем наш скоуп и:  

• приоритезируем задачи и планируемые сроки их реализации; 

• составляем карту проекта; 

• согласовываем работы и карту проекта с заказчиками и исполнителями проекта; 

• формируем точки контроля реализации плана: как мы будем отслеживать ход проекта. 

В плане также указываем, какие задачи ведутся параллельно, а какие последовательно. 

Этап 8. Согласовываем и утверждаем бюджет

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

• цели и бизнес-эффекты; 

• требуемые ресурсы;

• бюджет;

• рентабельность. 

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

Что нужно, чтобы сделать предпроект 

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

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

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

Если предпроект так хорош, то почему его не делают 

На своем личном опыте убедились, что 80% проектов стартуют без этапа предпроектной аналитики.

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

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

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

Как аргументировать необходимость предпроекта перед бизнес-заказчиками и реально ли это

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

1. Предпроект поможет сформировать точный бюджет на проект. Ситуации, когда на реализацию просто не хватит денег, не случится.
2. Точность оценки трудозатрат и сроков реализации существенно повысится — вы уложитесь в установленные сроки, а команда разработки не выгорит и не побежит увольняться.
3. Бизнес-требования и функциональность будут соответствовать заявленным: вам не придется ни от чего отказываться в процессе, выпускать полуготовый продукт, который не будет соответствовать первоначальным целям.
4. Вы сможете оценить рентабельность разработки, а не ориентироваться на примерный финансовый эффект.

Иными словами — вкладываясь в предпроект, вы снижаете неопределенность в проекте. Если уровень неопределенности высокий (много бизнес-требований, систем и доработок), то риски форс-мажора тоже высоки. И они могут обернуться существенными убытками. Тогда как затраты на предпроект всегда запланированы и держатся в рамках 5% бюджета проекта. 

И последний момент. Если речь идет о инхаус-разработке, то согласовать предпроект проще. Если же вы работаете в аутсорс-компании, то вас ждут тендеры. А тендеры — это часто про «сделать "Cybertruck" по цене "Москвича"». 

Кажется, что предложить заказчику сначала потратить деньги на предпроектное исследование — задача нереалистичная. Однако, если заказчик заинтересован в качестве конечного продукта и хочет работать с опытной командой, у которой есть экспертиза в отрасли и в похожих задачах, то согласовать этот момент можно. 

Делитесь в комментариях своим опытом работы с предпроектными исследованиями и тем, каким образом удается убедить бизнес-заказчиков в том, что они действительно нужны.