Техническое исследование: как снизить риски проекта до старта разработки

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

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

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

Что такое техническое исследование на самом деле

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

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

Правильно проведённое исследование даёт другой вид уверенности. Не «мы точно знаем, что строим» — это ложное ощущение определённости. Настоящая уверенность: «Мы знаем, где находятся неизвестные, мы оценили риски и выстроили объём так, чтобы проверять самые рискованные допущения первыми».

Пять вопросов, на которые должно ответить исследование

1. Что именно мы строим?

Не «платформу для X» — конкретное описание пользовательских сценариев, модели данных и границ системы. Что делает пользователь? Что в ответ делает система? Откуда приходят данные и куда уходят? Задача — быть достаточно конкретным, чтобы инженер мог дать оценку, но не настолько детальным, чтобы написание заняло три месяца.

2. Где точки интеграции?

Сторонние API, унаследованные системы, внешние источники данных, платёжные системы, провайдеры идентификации — каждая интеграция несёт риск. Вопросы, на которые нужны ответы: поддерживает ли API, на который вы опираетесь, то, что вам нужно? Каковы лимиты запросов? Кто управляет аутентификацией? Что происходит при сбое? Неверные допущения об интеграциях — одна из самых частых причин задержек проектов.

3. Что неизвестно?

В каждом проекте есть то, чего команда ещё не знает. Разница между хорошо управляемым проектом и плохим — в том, записаны ли эти неизвестные. Честный список «мы ещё не знаем, как это работает» полезнее, чем объём работ, притворяющийся, что всё понятно. Известные неизвестные поддаются планированию. Неизвестные неизвестные разрушают таймлайны.

4. Какое допущение самое рискованное?

В объёме всегда есть одна вещь, которая, окажись она неверной, обесценивает большую часть плана. Может, это «существующий API поддерживает пакетные операции». Может, «мы можем использовать текущую схему базы данных». Может, «сторонний поставщик клиента будет сотрудничать с нашей интеграцией». Что бы это ни было — его нужно выявить, назвать и проверить: прототипом, техническим спайком или прямым разговором — до начала первой фазы.

5. Что значит «готово»?

Договорённость о критериях завершения до начала разработки предотвращает самую распространённую причину трений на поздних стадиях: клиент и разработчик имеют разные ментальные модели того, как выглядит «выпущенный» продукт. Требования к производительности, поддержка браузеров, стандарты доступности, определение тестового покрытия, среда развёртывания — всё это должно быть явным, а не подразумеваемым.

Результаты исследования

Фаза исследования должна производить пять артефактов, а не пятьдесят страниц:

Архитектурная схема. Диаграмма, показывающая основные компоненты системы, их связи и потоки данных между ними. Не полная техническая спецификация — общая карта того, как выглядит система, понятная и техническим, и нетехническим участникам.

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

Реестр рисков. Таблица выявленных рисков, оценённых по вероятности и влиянию, с планом снижения или контингентным планом для каждого. Самая важная колонка — «что происходит, если это пойдёт не так».

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

Определение готовности. Чёткие, согласованные критерии завершения первой фазы, сформулированные в проверяемых, а не трактуемых терминах.

Сколько времени должно занимать исследование

Для большинства проектов: от одной до трёх недель.

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

Исследование не должно занимать три месяца. Если оно занимает три месяца — это уже не исследование, а оплачиваемая фаза дизайна, избегающая тяжёлого разговора о том, чем проект на самом деле является. Цель — скорость и фокус: вытащить риски, структурировать объём, начать строить.

Исследование vs оплачиваемая фаза дизайна

Исследование отличается от дизайна (UX, визуальный дизайн, детальные спецификации). Спринт исследования ведётся инженерами и сфокусирован на рисках. Фаза дизайна ведётся дизайнерами и сфокусирована на результатах.

У обоих есть своё место, но они отвечают на разные вопросы. Исследование отвечает: то, что мы предлагаем, можно построить, и каковы риски? Дизайн отвечает: как это должно выглядеть и как себя вести?

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

Самая распространённая ошибка в исследовании

Пропуск реестра рисков.

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

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

Красные флаги в процессе исследования

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

Начинаете новый проект? Напишите нам на hello@cimpleo.com. Краткое исследование в начале — это самая дешёвая страховка, которую вы можете купить.