Когда мы только начинали, мы брались вообще за всё. Дешёвые проекты — да. Проекты с мутными требованиями — тоже да. Без чёткой идеи, без понимания, зачем продукт и куда он должен прийти — берём.

И, конечно, это регулярно приводило к проблемам.

Со стороны заказчика всё выглядело довольно просто: виноваты мы 😢 Разработчики же. Значит, должны разбираться не только в коде, но и вообще во всём — и в бизнесе, и в том, как «правильно».

А мы в этот момент сидели и не понимали, что происходит. Почему мы друг друга не слышим, почему вроде делаем то, о чём договаривались, а на выходе — недовольство и конфликт.

Мы расстраивались, злились, не находили нормального коннекта в коммуникации. И только со временем, уже в процессе роста компании, стало понятно, в чём на самом деле была проблема.

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

И вот что я могу сказать сейчас.

Процентов 80 проблем в IT-проектах — вообще не про код и не про технологии. Это про управление.

Где всё начинает ломаться

Первое — мы по-разному видим один и тот же проект

Заказчик передаёт какую-то информацию. У него в голове уже сложилась картинка продукта. А мы эту же информацию воспринимаем по-другому и выдаём другой результат.

Не потому что кто-то врёт или специально недоговаривает. Просто: — требования не до конца зафиксированы, — бизнес-задача до конца не понята, — мы не полностью погрузились в процессы заказчика, — а сам заказчик часто вообще неопытен в разработке IT-продуктов.

В итоге у каждого в голове своя картина, которую даже могут не проговорить вслух.

Поэтому сейчас мы делаем иначе: проговариваем всё максимально подробно и только потом уже идём в этапы, коммерческое предложение, ТЗ и дальше по процессу.

Вторая большая проблема — непонятно, кто за что отвечает

Очень часто нет одного человека со стороны клиента, который реально принимает финальные решения.

Мы что-то согласовали с менеджером проекта — и думаем, что всё ок. А потом заказчик говорит: «А почему вы это согласовали? Это надо было со мной». Потом появляется маркетолог с совсем другими требованиями. Ответственность размывается, нет единого окна.

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

Третья проблема — сложные решения откладываются

Есть вопрос, в который надо вникнуть и принять решение. И его начинают переносить.

«Давайте потом», «Я отвечу», «Вернёмся к этому позже».

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

Про роль “главного по продукту”

В разработке продукта эта роль критически важна. Как со стороны подрядчика или заказчика.

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

Ему не обязательно быть технарём. Важно уметь собрать всё в одну систему и понимать, зачем вообще делается этот продукт.

Вывод: Если IT-проект начинает буксовать, имеет смысл сначала посмотреть не в код и даже не в команду. А в того, кто принимает решения и отвечает за них.

Очень часто именно там и находится ответ, почему проект идёт тяжело — или почему он вообще не едет.

📚 Книжная ремарка: Элияху Голдратт «Цель» — книга не про заводы и не про IT.

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

#управление #рынокIT