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