Нулевой этап проекта: как у нас подходят к проектной оценке
Краткий гайд от бизнес- и технического руководителей центра компетенций разработки ITQ Group Даниэла Кнежевича и Максима Макеева.
Привет! Сегодня мы хотим поговорить о предпроектном исследовании — этапе разработки IT-проектов.
Начнем с примера. Однажды, в одной финтех-компании выкатили на прод новую функциональность. Функциональность не заработала. Стали разбираться и выяснили, что не учли необходимых изменений в кор. системе, а без них новая функциональность недееспособна. Пошли к разработчикам кор. системы: бэклог забит на год вперед, влезть вне очереди не получится. Спустя два года функциональность так и висит без релиза. Между тем, она важна для одного из бизнес-направлений, ее отсутствие несет нормативные риски для компании…
Уверены, вы тоже сталкивались с ситуациями, когда уже запущенные в разработку проекты сильно превышали установленные рамки бюджета, растягивались по срокам, замораживались или выпускались с сильными недоработками, теряя в качестве. Или доходили до продакшена, но функциональность, заложенная в проекте, оказывалась никому не нужной, или сам проект нерентабельным. Причина в большинстве случаев в отсутствии этапа предпроектного исследования, на котором экономят деньги и ресурсы.
В материале разберём: для чего нужен предпроект, как его проводить и как убедить бизнес-заказчика потратить на него деньги.
Начнем с базы.
Что такое предпроект и зачем он нужен
Предпроект — это этап, предваряющий сами проектные работы. В ходе предпроектного исследования заказчики и исполнители разбираются с целями проекта, их актуальностью, достижимостью, масштабами и т.д.
Разбираются — значит, не просто обсуждают и что-то фиксируют, а готовят полноценный документ по результатам этой работы.
Цель этого этапа — оценить будущие работы, согласовать и выделить бюджет. Либо, такое тоже случается, прийти к выводу, что проект запускать нецелесообразно.
Изображение
Какие вопросы задает предпроект и какие ответы предоставляет
В рамках предпроекта команда формирует ответы на важные вопросы:
цели и бизнес-эффекты проекта;
бизнес-, технические и инфраструктурные требования;
участники проекта: системы/ответственные за эти системы лица/исполнители;
определение архитектурного решения (выполняется не всегда, но если выполняется, существенно повышает качество оценки);
скоуп работ;
временные затраты.
И получает важные сведения:
набор требований заказчика;
декомпозицию работ (разделение ее на отдельные задачи);
оценку трудозатрат и сроков реализации;
календарный план;
согласованный бюджет.
В чем основная ценность предпроекта
Предпроект помогает принять более взвешенное решение о целесообразности проекта. Грубо говоря — если вам кажется, что какую-то новую фичу просто необходимо внедрить в банковское приложение, то после предпроекта вам уже не кажется — вы в этом уверены. Либо убедились в обратном: фича не так уж и нужна или внедрение будет нерентабельным.
То же применимо и к запуску новых продуктов, разработке сложных систем: предпроект дает возможность максимально близко оценить как будущие затраты (чтобы впоследствии заложить их в бюджет), так и потенциальную выгоду от внедрения. И свести одно с другим.
Помимо этого, предпроектное исследование дает возможность участникам проекта договориться и лучше понять цели друг друга, задачи и ограничения.
Как предпроект работает с рисками
Проектные риски связаны с незапланированным ростом бюджета, срывом сроков, потерей качества или невозможностью реализовать проект в принципе.
Причины могут быть разные: ошибки проектирования, бизнес-требования, которые не были учтены, отсутствие специалистов нужной квалификации, нехватка человеческих ресурсов, наконец, потеря сотрудников из-за выгорания (если людям приходится работать за двоих днем и ночью, чтобы уложиться в сроки, бюджета не хватает и приходится жертвовать качеством) .
Еще один пример: запустили проект с верхнеуровневой оценкой без погружения в детали. На этапе реализации поняли, что часть работ не учли. Текущих ресурсов: человеческих и бюджетных не хватало, чтобы реализовать проект в заданные сроки. А срок в данном случае был критичным. В результате пришлось резать скоуп работ, функциональность пострадала, бизнес-эффекты проекта не были достигнуты в полной мере.
А если бы предпроект был проведен, то сложности, появившиеся в ходе реализации, были бы понятны еще до старта разработки. У команды была бы возможность решить, что с этим делать: увеличивать бюджет, сроки или корректировать бизнес-требования.
Если есть этап аналитики, то зачем нужен предпроект
Скорее всего, у некоторых читателей к этому моменту уже назрел вопрос:, а разве все перечисленные работы не относятся к этапу аналитики? Может, предпроект — это та же аналитика, только под другим названием?
Нет. Предпроект — это верхнеуровневая оценка, определение и согласование глобальных целей. На этом этапе как раз и формируется бюджет. А на этапе аналитики глобальными целями не занимаются — предполагается, что они уже утверждены, как и бюджет. И если в ходе аналитики вдруг выяснится, что денег не хватит, дополнительные средства согласовать будет сложно. В результате придется жертвовать целями проекта или экономить на качестве.
Этапы предпроекта
Разберем основные этапы предпроекта.
Этап 1. Согласовываем цели и бизнес-эффекты проекта.
На этом этапе выясняем цели и ожидания всех заинтересованных лиц. Цели должны быть понятны всем участникам, однозначны, вести к ощутимому бизнес-эффекту, который в идеале ещё и можно измерить.
Например:
Запустить кредитный конвейер, который приведет к увеличению клиентской базы на 20% и повышению скорости оформления заявок на кредит в мобильном приложении на 2 минуты.
Изменить кнопку выдачи кредитной карты в МП с красной на зелёную, что позволит привлечь + 100 000 клиентов.
Разработать новую систему и перевести туда 100% пользователей из приложения, не удовлетворяющего требованиям регулятора.
Пересмотреть и изменить процесс оформления банковского продукта для улучшения пользовательского опыта: на 2 минуты сократить время оформления заявки, на 35% снизить количество обращений в поддержку.
Измеримые показатели нужны для того, чтобы по окончании проекта можно было оценить, насколько он был успешен. Дополнительно можно разработать и другие параметры: соответствие бюджету, сроки, качество, полнота реализации.
Этап 2. Формулируем бизнес-требования
На этом этапе собираем максимально подробные бизнес-требования со всех заинтересованных лиц, чтобы появилась ясность относительно решения задачи на уровне бизнеса: что именно необходимо сделать и как. После оцениваем объем требований, следим, чтобы они не противоречили друг другу, проводим оценку затрат на реализацию проекта.
Сквозной этап. Проектирование UI
Кажется, что это уж точно к предпроекту не относится, ведь UI обычно проектируют на этапе аналитики или после нее. Зачем заниматься этим раньше?
Затем, что это поможет лучше оценить скоуп работ и самое главное — даст возможность заказчикам увидеть конечный результат и понять, отвечает ли он поставленным целям и задачам.
Если заниматься проектированием в рамках этапа аналитики или после нее, то когда выяснится, что UI будущей системы должен работать как-то иначе, и это иначе предполагает больше работ, больше ресурсов и больше денег, придется столкнуться с нелёгким выбором: урезать бюджет или сокращать бизнес-требования. Или откатывать разработку и начинать этап аналитики заново. А это время и деньги.
Этап 3. Формируем архитектурное видение проекта
На этом этапе у нас должен появиться список систем, которые будут участвовать в проекте: существующих, и тех, которые предстоит создать. Понимание того, как эти системы будут между собой интегрированы. Из этого появится представление о необходимых доработках.
Архитектурное решение на этапе предпроекта часто пропускают. Например, на одном из проектов на начальных этапах (предпроект и даже аналитика) не выявили все системы. В результате на этапе внедрения случился крупный сбой. Пришлось откатывать доработки с прода, тратить значительное время на исправление и договариваться со смежными командами, чтобы они срочно взяли новые задачи. Итог: временной сдвиг на два месяца и плюс 3 млн бюджета.
Этап 4. Определяем скоуп работ
Здесь декомпозируем бизнес-требования на небольшие задачи, которые нужно выполнить, чтобы реализовать весь проект. После того как скоуп готов, обращаемся к ранее собранным бизнес-требованиям, чтобы удостовериться, что все они учтены, а задачи полноценно декомпозированы.
Этап 5. Приступаем к оценке проекта: участники, виды работ, ресурсы
Берем скоуп работ и оцениваем ресурсы (аналитики, тестировщики, разработчики и т.д.) и объем работ для каждой роли. В результате получаем данные по количеству человеко-дней на реализацию каждой задачи и проекта в целом.
Важный момент. Некоторые виды работ забывают учесть в оценке, в результате «едут» бюджет и сроки. Так что не забывайте о таких задачах:
модульное/авто/нагрузочное тестирование;
проверки на соответствие требованиям безопасности;
приемо-сдаточные испытания;
подготовка инструкций для пользователей;
подготовка и исполнения заявок на сетевые доступы.
Можно ли все учесть в скоупе? Разумеется, нет.
Поэтому дополнительно к оценке объема закладываем:
20% — когда все понятно
30% — есть серые зоны
50% — когда много неизвестного (вообще, это означает, что предпроект сделан некачественно).
Этап 6. Определяем методологию ведения проекта.
Этап методологии нужен для того, чтобы сформулировать и договориться о том, как именно будет происходить управление проектом.
На какие вопросы отвечаем:
По какой методологии работаем: WATERFALL, SCRUM, KANBAN и т.д.
Какие у нас стандарты разработки:
Есть ли код-ревью?
Подготовка и ревью технической, тестовой, архитектурной документации? Если да, то на каких этапах?
Как и какое именно тестирование проводится?
Другие вопросы, которые относятся к процессу разработки и помогут команде сделать ее более прозрачной.
Как будет происходить взаимодействие между командами:
Как команды синхронизируются?
Кто участвует во встречах: РП или представители команд?
Как часто проходят встречи?
Как и с какой частотой синхронизируемся с бизнес-заказчиком?
Как происходят приемо-сдаточные испытания?
И т.д.
Этот этап кажется менее важным, чем остальные, однако, он помогает сократить время на выстраивание модели взаимодействия и повышает эффективность работы. Если есть возможность, нужно уделить время и ему. Минимально — определиться с методологией, порядком подготовки документации, схемой взаимодействия между командами.
Этап 7. Разрабатываем и согласовываем план проекта
Берем наш скоуп и:
приоритезируем задачи и планируемые сроки их реализации;
составляем карту проекта;
согласовываем работы и карту проекта с заказчиками и исполнителями проекта;
формируем точки контроля реализации плана: как мы будем отслеживать ход проекта.
В плане также указываем, какие задачи ведутся параллельно, а какие последовательно.
Этап 8. Согласовываем и утверждаем бюджет
После считаем бюджет и готовим презентацию для защиты проекта с тем, чтобы на реализацию выделили деньги. В презентации обычно указываем:
цели и бизнес-эффекты;
требуемые ресурсы;
бюджет;
рентабельность.
То есть, в результате у вас на руках будет два документа. Первый — более полноценный и детальный, сформированный по итогам предпроектного исследования, второй — презентация с самыми важными аспектами будущего проекта.
Что нужно, чтобы сделать предпроект
Если речь идет о внедрении новой фичи в существующее приложение, каких-то изменений или доработок — можно уложиться в пару недель.
Если готовитесь к старту серьезного проекта, который будет длиться пару лет — закладывайте не меньше двух месяцев.
Для предпроекта нужны: архитектор, аналитик и руководитель проекта, — которые на разных этапах будут общаться с лидами разработки и тестирования. И, разумеется, деньги.
Чтобы предварительно рассчитать затраты на предпроект, нужно учесть объем и характер бизнес-процессов, под которые планируете создавать новую систему или фичу, количество экранных форм, интеграции и доработки БД. В результате получите оценку трудоемкости будущего исследования и список специалистов, который нужно будет к нему подключаться. Опираясь на эти данные, сможете рассчитать сроки и стоимость предпроекта. Если усреднять, нормальная стоимость предпроекта — не больше 5% от прогнозного бюджета самого проекта.
Если предпроект так хорош, то почему его не делают
На своем личном опыте убедились, что 80% проектов стартуют без этапа предпроектной аналитики.
Во-первых, никому не хочется тратить на это время и деньги. В крупном бизнесе деньги выделяются на реализацию самих проектов в рамках годового планирования. Предпроектные исследования часто касаются проектов следующего года, а на это бюджет обычно не закладывают.
Во-вторых, всегда кажется, что лучше быстрее стартануть, а разобраться с деталями можно и на этапе аналитики.
И наконец, политика. Случается, что для бизнес-заказчика проект — ступенька к новой должности. Если на этапе предпроекта выяснится, что сам проект нежизнеспособный, желаемого повышения не произойдет.
Как аргументировать необходимость предпроекта перед бизнес-заказчиками и реально ли это
Чтобы убедить коллег или заказчиков в том, что вам нужен этап предпроектного исследования, опирайтесь на следующие пункты:
1. Предпроект поможет сформировать точный бюджет на проект. Ситуации, когда на реализацию просто не хватит денег, не случится.
2. Точность оценки трудозатрат и сроков реализации существенно повысится — вы уложитесь в установленные сроки, а команда разработки не выгорит и не побежит увольняться.
3. Бизнес-требования и функциональность будут соответствовать заявленным: вам не придется ни от чего отказываться в процессе, выпускать полуготовый продукт, который не будет соответствовать первоначальным целям.
4. Вы сможете оценить рентабельность разработки, а не ориентироваться на примерный финансовый эффект.
Иными словами — вкладываясь в предпроект, вы снижаете неопределенность в проекте. Если уровень неопределенности высокий (много бизнес-требований, систем и доработок), то риски форс-мажора тоже высоки. И они могут обернуться существенными убытками. Тогда как затраты на предпроект всегда запланированы и держатся в рамках 5% бюджета проекта.
И последний момент. Если речь идет о инхаус-разработке, то согласовать предпроект проще. Если же вы работаете в аутсорс-компании, то вас ждут тендеры. А тендеры — это часто про «сделать «Cybertruck» по цене «Москвича».
Кажется, что предложить заказчику сначала потратить деньги на предпроектное исследование — задача нереалистичная. Однако, если заказчик заинтересован в качестве конечного продукта и хочет работать с опытной командой, у которой есть экспертиза в отрасли и в похожих задачах, то согласовать этот момент можно.
Делитесь в комментариях своим опытом работы с предпроектными исследованиями и тем, каким образом удается убедить бизнес-заказчиков в том, что они действительно нужны.
