Как не утопить ИТ-проект

Андрей Корниенко, ведущий архитектор программного обеспечения ИТ-интегратора AWG, объясняет, почему это происходит, а также делится чек-листом, на что обратить внимание, чтобы не тратить месяцы и бюджеты впустую.

Как часто расходятся ожидания с реальностью и почему это никого не учит

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

С одной стороны, бизнес постепенно учится на собственном опыте. После пары подобных случаев заказчик начинает понимать, что прежде, чем заказывать систему, важно провести подготовку: сходить к разным интеграторам, задать вопросы, подключить архитекторов и аналитиков. В крупных компаниях «разведка» может даже занимать один или два года, особенно если речь идет о внедрении таких систем, как ERP или программ лояльности.

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

Искусство ставить ТЗ

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

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

есть барьер, который мешает бизнесу (проблема); есть цель или возможность, к которой компания стремится.

Мы можем сделать красивый сайт или внедрить CRM, но, если это не связано с задачей, эффекта не будет — ведь клиенту нужна не система как объект, а результат от ее внедрения. Настоящий эффект — это, например, рост продаж, ускорение обработки заказов, снижение издержек, увеличение оборота. Иногда ответ, какого эффекта ждет заказчик, оказывается неожиданным, и именно он формирует корректное ТЗ.

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

Планирование, выраженное в цифрах

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

Допустим, клиенту кажется, что новый сайт стоит определенную сумму, потому что они сравнивают его с обычной «витриной». Но при проведении оценки ИТ-компанией, может выясниться, что реальный бюджет — не в два или три, а в десятки раз больше. Причина в том, что бизнес-процессы у компаний очень разные: внешне все похоже, но внутри — уникальные процессы ценообразования, работы с остатками, логистики, интеграции с ERP. Плюс у каждой компании уже есть «наследие»: старые сайты, 1С, отраслевые системы. Это может сделать проект сложнее и дороже, чем клиент изначально ожидает.

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

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

Или еще один пример — мгновенное обновление остатков: звучит красиво, но стоит бесконечно дорого. В одном из проектов мы реализовали компромиссное решение: начали напрямую забирать чеки из 1С с касс магазинов. Мы сделали временную блокировку: если в магазине кто-то купил товар, то на сайте сразу «-1» виртуально. Полное обновление через системы происходит через несколько часов, и данные корректируются. Это рабочее решение: клиент получает корректный пользовательский опыт, а бюджет остается адекватным. Разработанный подход позволил снизить затраты примерно на 5–7% от общего бюджета проекта — а он был огромным. Экономия составила десятки миллионов рублей.

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

Гигиена коммуникации

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

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

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

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

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

Казалось бы, простые «гигиенические правила», но на практике именно их игнорирование чаще всего убивает проект.

Как говорить с заказчиком о проблемах

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

Но главное — никогда нельзя «вываливать» проблему и перекладывать ее на заказчика. Корректный подход — прийти с готовыми вариантами ее решения. Например: «Есть риск. Вот три сценария, у каждого свои плюсы и минусы. Давайте обсудим». Тогда заказчик видит, что ситуацию держат под контролем. Приносить вместе с проблемой решение — это знак профессионализма, заботы о заказчике и уважения к его работе. Ведь у него такие же KPI, давление и риски, как и у нас.

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

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

Если что-то пошло не так

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

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

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

Итоговый чек-лист

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

Не принимайте за ТЗ готовое решение по мнению клиента — совместно сформулируйте проблему или цель. Спрашивайте: какой эффект нужен бизнесу? Заранее учитывайте уникальные бизнес-процессы клиента и переводите особенности в измеримые показатели (в идеале денежные). Оценку показывайте клиенту через цепочку: решение — процесс — влияние — деньги. Назначьте ответственных за ключевые процессы еще на этапе анализа. С самого начала зафиксируйте каналы коммуникации. Проводите встречи эффективно: не больше 5-7 участников, всегда с повесткой и протоколом, все, что можно решить письменно — решайте письменно. Принцип врача: почувствовали проблему — обсуждайте сразу, иначе будет поздно. Но соблюдайте баланс: проблемы нельзя замалчивать, но и панику создавать не нужно. Обсуждайте сложности сначала в личном контакте, а не на общем совещании. Приносите клиенту не только проблему, но и варианты решений. Помните: «совсем не то» происходит, если в начале не задали правильных вопросов.