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