Смена подрядчика на проекте — больно, но возможно 👨‍💼

Смена подрядчика по разработке программного продукта (сайта, приложения, сервиса, платформы) — как правило огромная боль для заказчика.

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

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

В итоге, заказчик часто уже имеет опыт неоднократных факапов на своём проекте и повторять этот опыт не хочет. Поэтому на входе начинает всесторонне проверять нового подрядчика и ставить его в строгие рамки.

Например, частой для нас ситуацией является требование дать фиксированную оценку на развитие проекта с существующей кодовой базой. Для этого мы вынуждены сначала дать хоть какую-то вилку (то есть, фактически совершить продажу) , и только когда доверие завоёвано, подписан NDA и получен доступ к исходному коду, мы можем увидеть, с чем нам реально предстоит работать.

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

Как вы думаете, с чем мы в итоге порой сталкиваемся? Например, метафорически задача может выглядеть как проект по пристройке к дому на фундаменте, который этого не выдержит (и в моменте информация об этом может быть недоступна) .

А клиент уже ждёт, что мы вот-вот приступим к работе. Оценку же дали? Исходный код увидели? Шаблон договора обсудили? А мы вынуждены возвращаться к началу и объяснять, почему после анализа наша оценка увеличится вдвое. Или втрое. Почему так?

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

Как заложить риски так, чтобы не ошибиться? На отдельно взятом проекте никак. Увеличив кратно оценку, потеряешь клиента. Занизив — сработаешь в ноль или в минус. Остаётся балансировать где-то по-середине.

Есть и другой неплохой вариант для обеих сторон — работать по схеме T&M (time & material). По ней мы разбиваем проект на минимально возможные блоки и плавно включаемся в работу.

Что при этом происходит?
1. Разработчики, до этого только видевшие код, разворачивают его в своей локальной или тестовой среде и получают доступ к живой системе
2. Появляется возможность понаблюдать за работой системы локализовать места в коде, которые потребуют доработки и прикинуть эту доработку
3. В оценке небольшой части проекта вероятность сильно ошибиться радикально снижается. И даже если мы ошибёмся, это будет не так критично, и мы можем сделать выводы, чтобы далее корректировать оценки на сыгравший фактор риска

Не каждый заказчик соглашается на такое сразу.
— А что, если вы после первой недели работ скажете, что тут всё плохо и раздуете оценки в разы без оснований?
— Что, если вам что-то не понравится и вы бросите проект на середине?
— Что, если вы будете плохо справляться, и у меня не будет рычагов воздействия на вас?

На все эти вопросы хочется ответить так: Слава богу, если это случится на раннем этапе! Правильным будет скорее бежать от такого подрядчика сразу, как только вы это обнаружите.

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

А ведь ещё бывает, что это делается неосознанно. Из области: я не знаю, что я не знаю, и поэтому продолжаю это делать. Учитывая, что в мире IT сегодня всё меняется с космической скоростью, вчерашние подходы быстро устаревают, новые библиотеки сменяют старые. Проектам тоже приходится идти в ногу, иначе без поддержки и обновления через 3-5 лет они уже базируются на не лучшем коде, а через 8-10 превращаются в почти безнадёжную свалку заплаток поверх заплаток, за которую ни один разработчик не возьмётся работать на адекватных условиях.

Далее немного о нас (Cyberform Systems + Soft-works).

С каждым клиентом мы стараемся строить технологическое партнёрство. Партнёрство — потому, что мы не менее, чем сам клиент, заинтересованы в успехе проекта. Ведь мы зарабатываем на этом проекте вместе с клиентом. И чем больше зарабатывает клиент, тем охотнее он будет развивать проект и далее.

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

Но даже при этом проекты могут порой идти непредсказуемо. Особенно на старте. Это сложное время для обеих сторон. Мы знакомимся, притираемся, подбираем команду (и при этом возможны замены) , вырабатываем темп движения и способы взаимодействия.

Но далее, как правило, всё выравнивается (обычно это занимает до 2-3 месяцев, но бывает и дольше) , и проект начинает идти гладко и существенно более предсказуемо. Вот здесь обычно и выстраивается настоящее партнёрство, основанное на доверии и синергии.

Поэтому если меняете подрядчика и ищете партнёрский подход — пишите, с интересом обсудим ваш проект!