Монопольная зависимость от подрядчика в ИТ: симптомы, риски и как это вылечить
Недавно к нам в Profiterole пришел заказчик, который понял, что его проект буксует, но у него не было достаточно компетенций, чтобы разобраться в том, что не так делает его ИТ-подрядчик. Мы подключились к проекту, провели аудит и увидели две серьезные проблемы:
1. Не было технической документации — когда есть только код, нужно много времени, чтобы понять, что сделано, а что нет, есть ли готовая версия продукта, какие кейсы она закрывает.
2. Были проблемы на бэкенде — подход к работе с блокчейном не соответствовал требованиям заказчика, у подрядчика не хватило коммерческого опыта проектов на смарт-контрактах. Это критично, потому что ключевая ценность проекта для пользователей — прозрачность транзакций. Вся суть проекта именно в этой доказуемой честности.
Мы предложили усилить разработку и разделили задачи — первая команда делает фронтенд, а мы помогаем технологиями на беке и правильно выстроить коммуникацию на проекте, включая разработку документации.
Почему вообще заказчик получил слабый результат?
Потому что он был зависим от своего подрядчика и не имел экспертизы, чтобы провести технический аудит и оценить зрелость команды.
Монопольная зависимость заказчика проекта от незрелого исполнителя — смертельная болезнь проекта.
Заказчик имеет в голове образ результата, но не обязан досконально знать, как к нему прийти. Он платит деньги за то, чтобы ему этот результат обеспечили. Контролировать разработку — задача вне его компетенции.
Отсутствие контроля или просто «второй пары глаз» — благодатная почва для рисков. Незрелая команда, предоставленная сама себе, будет стремиться решить задачу так, как удобно ей, а не так, как лучше для проекта. Даже без злого умысла, а просто по неопытности исполнитель может неверно оценить задачу, привлечь недостаточно опытных специалистов, которые применят неоптимальные решения:
Но и от зрелой команды зависеть опасно — а что если возникнут неожиданные обстоятельства, и они просто не доделают работу?
В результате заказчик получит слабый код, неполную документацию, растянутые сроки. В худшем случае — проект нужно будет делать заново, списав потраченные деньги и время.
По нашему опыту, 90% проектов не готовы к масштабированию
Когда мы приходим на проект, чаще всего, оказывается, что продолжать разработку в том же духе, как ее вела первая команда уже опасно. Вот что мы видим:
- MVP, которое себя уже изжило, но на него ценой великих вложений пытаются накинуть какие-то новые фичи, которые изначально не подразумевались. Продолжать кодить так дальше — значит раздувать бюджеты на каждую доработку;
- либо качество кода уже не тянет дальнейшее развитие, и пора делать рефакторинг;
- либо продукт дожил до этапа, когда пора переходить на микросервисную архитектуру.
В каждом проекте наступает момент, когда нужно переезжать на новую систему, потому что уже нецелесообразно дальше поддерживать старую. Без аналитики и ИТ-экспертизы заказчик разработки этот момент не увидит.
Все эти риски снимает одно решение, которым мы пользуемся сами — вести разработку двумя командами, мотивированными независимо друг от друга
Мы стараемся работать с кем-то по принципу «четырёх глаз» — когда за результат отвечают две независимые и непредвзятые стороны. В больших проектах нашим партнером часто выступает внутренняя команда, которая отвечает за поддержку и эксплуатацию продукта после запуска. Если такой команды на старте нет, мы стараемся донести до заказчика важность такого подхода. И вот какие преимущества мы видим:
- Когда в проекте есть две команды и правильная мотивация, включается «белая» конкуренция. Одна команда стремится сделать без ошибок, потому что вторая команда стремится эти ошибки найти и не пропустить в продакшн.
- Команды начинают конкурировать за то, чтобы внедрять эффективные решения и технологии.
- Две команды сразу выстроят грамотные процессы коммуникации. Документация необходима, чтобы делить задачи и передавать результаты друг другу. А это значит, что заказчику будет проще пригласить больше разработчиков.
- Две команды усилят друг друга — так снимается риск, что разработчик упустит важные моменты, потому что не хватит скиллов.
Используя эту модель, заказчик сразу получает качественную разработку, может контролировать сроки, и будет спокоен за проект, даже если сам не эксперт в ИТ.
Как заказчику организовать такую работу?
— Если есть внутренняя команда — их мотивация в том, что им будет проще поддерживать продукт после запуска, если они будут хорошо контролировать подрядчика на этапе разработки.
— Если нет внутренней команды — привести второго подрядчика и мотивировать деньгами на совместный поиск багов и эффективных решений.
А не слишком ли это дорого?
Рискнуть и сэкономить на разработке до запуска можно, если вы делаете MVP и планируете проверить востребованность решения на реальном рынке. Но если ваш план — выпустить зрелый продукт и как можно скорее отбить инвестиции, дешевле сразу убрать как можно больше рисков. Баги и технический долг после запуска будут стоить дороже.
Что делать, если прямо сейчас вы в ситуации монопольной зависимости, и проект уже посыпался?
Как можно скорее найдите проблему. Пригласите стороннего эксперта провести аудит проекта, инвентаризацию созданного функционала. Это сразу может быть ваш потенциальный второй подрядчик.
Худшее, что может случиться — возникнет необходимость приостановить проект, чтобы новая команда могла дособрать документацию и подключиться к работе. Но это все равно лучше полной остановки и отката к началу.
Мы проводим опрос заказчиков разработки, чтобы узнать, как складываются ваши отношения с внешними подрядчиками в ИТ.
Мы обязательно поделимся обобщенными результатами с каждым участником и в благодарность разыграем 10 бесплатных 30 минутных консультаций по вашему вопросу, связанному с внешней разработкой.