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