Мы все учимся на ошибках. Но быстрее всего — когда работаем с крупными заказчиками.

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

Но есть нюанс. Крупные проекты умеют «учить» так, что седина появляется раньше срока.

За последние годы я выделила несколько тихих, но очень опасных триггеров. И некоторые из них я прочувствовала лично.

Триггер № 1. Поговорить со всеми, кроме тех, кто будет пользоваться продуктом

Классическая история.

Мы общаемся с топ-менеджерами, дирекцией, руководителями направлений. Все всё понимают, прекрасные презентации, сложные графики, красивые слова: «нам нужно оптимизировать, ускорить, автоматизировать».

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

1. операторы колл-центра,
2. бухгалтеры,
3. супервайзеры,
4. логисты,
5. сотрудники смены,
6. администраторы точки.

И вот они смотрят на систему как на пришельца с другой планеты:

«А куда здесь нажимать?» «Почему у меня стало дольше?» «А где кнопка, которая была всегда?» «Мы так работать не будем».

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

Вывод: говорить нужно и с теми, кто принимает решения, и с теми, кто работает руками. Всегда.

Триггер № 2. Не уточнить критерии приёмки ПО

Звучит скучно. Но именно из-за этого иногда рушатся огромные проекты.

Ситуация из реальности. Мы сделали систему, все довольны. Подходит момент ставить продукт на баланс — и начинается веселье:

1. не хватает инструкций,
2. нет подготовленных регламентов,
3. нет обучающих материалов,
4. нет описаний API,
5. «закладка» под интеграции не сделана,
6. нет документа о вводе в сопровождение.

А всё это — не было в бюджете.

И да, если мы «подвинулись в цене», то исправлять это приходится за свой счёт, чтобы проект поехал дальше.

Вывод: критерии приёмки, формат документации, перечень артефактов и требования ИБ/аудита — выясняем на старте. Это экономит месяцы и нервы.

Триггер № 3. «Сделайте чуть-чуть по-другому» (без официального изменения требований)

Это самый тихий и разрушительный триггер.

Представьте: топ-менеджер заходит в Zoom и спокойно говорит:

«Слушайте, а давайте вот здесь фильтры переставим, а отчёт добавим? Это же минутное дело».

Минутное дело. А реальность — каскад изменений в логике, API, структуре данных, тестировании и аналитике.

Мы делаем. Ведь попросил важный человек.

А потом приходит аудит и спрашивает:

— Почему функционал не соответствует исходным требованиям? — Почему отчёты отличаются? — Кто согласовал изменение?

А тот самый менеджер может быть уже в отпуске на Бали. Или в новой компании. И никто его просьбу официально не фиксировал.

А отвечать — нам.

Вывод: даже маленькие изменения — через Change Request. Это не бюрократия. Это самостраховка.

Триггер № 4. Перебрасывание мячика между командами

Такое особенно часто встречается в крупных компаниях.

— «Аналитики не дали данные — мы не сделали». — «Разработчики не сделали — мы не протестировали». — «Тестировщики не протестировали — мы не приняли». — «Мы не приняли — проект не готов».

И так по цепочке.

Все правы. Но проект стоит.

Сроки уходят вправо. Бюджет взлетает. Риски множатся.

И в глазах заказчика виноват всегда один — исполнитель. Даже если «мячик» бросали пять команд подряд.

Вывод: если видим пробку в процессе — поднимаем флаг, создаём единый чат/канал, назначаем ответственных, фиксируем блокеры. И закрываем вопрос до конца.

Триггер № 5. Не вести внутреннюю документацию

Я знаю, что многие студии ведут её «как получится». Мы — нет. И это спасало нас десятки раз.

Мы фиксируем всё:

1. понимание бизнес-логики,
2. артефакты,
3. решения,
4. структуру данных,
5. договорённости,
6. API,
7. схемы процессов,
8. даже «временные костыли», если они есть.

Почему это важно:

1. новый человек входит в проект без боли;
2. если кто-то ушёл — проект не останавливается;
3. у клиента появляется уверенность в стабильности;
4. команда работает единообразно, а не «кто как привык».

Документация — лучшая страховка в мире аутсорса.

Самый важный вывод

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

И цель у нас одна:

Сделать проект хорошо и оставаться в нём надолго.

Когда это понимаешь — большинство конфликтов, недопониманий и споров исчезают сами собой.

Вопрос к вам

А какие «тихие триггеры» встречались у вас? Те самые мелочи, которые сначала кажутся пустяком, а потом выстреливают и парализуют проект?

Поделитесь опытом — уверена, нам всем есть что вспомнить.

***

Если вам интересны честные заметки о лидерстве без пафоса, практические инсайты про разработку и ИИ, факапы, кейсы, цифровую трансформацию и всё, что происходит «по ту сторону» проектов, то подписывайтесь на мой телеграм канал https://t.me/CEOItFox