На одном из созвонов потенциальный заказчик поделился болью:

“Меньше чем за год велосити команды внешнего вендора упала в разы. Почему задачи, которые должны занимать 2–3 дня, растягиваются на недели?”

Проект шел уже почти год с участием внешнего IT-вендора. По документам на проекте работала senior-команда: сильные CV, большой опыт, уверенные интервью. Ожидания были понятные - стабильная скорость разработки и предсказуемый результат.

Первые месяцы так и было. Но примерно через полгода начали появляться странные сигналы. Скорость разработки постепенно снижалась. Задачи, которые раньше закрывались за несколько дней, начали затягиваться. Планирование становилось все менее точным. Это не выглядело как резкий провал, а скорее как медленное ухудшение, которое легко объяснить ростом сложности проекта или накопившимся техдолгом. Но динамика все равно вызывала вопросы.

Заказчик решил разобраться и обратился к нам.

Мы посмотрели код, провели техническую оценку команды и разобрали, кто какие задачи закрывает. Важно было не то, что написано в CV, а то, как команда работает на практике.

Картина оказалась неожиданной - около 30% команды были junior-разработчиками.

Не “почти senior”.

Не middle.

Именно junior!

При этом бюджет проекта строился исходя из senior-ставок.

Когда мы начали разбираться, выяснилась еще одна деталь - на замену специалистов заказчик никакого апрува не давал. Часть senior-разработчиков постепенно заменили на junior. Это происходило не сразу, а постепенно, поэтому долго оставалось незаметным. Формально команда оставалась «той же», но по факту ее уровень изменился.

Именно поэтому скорость разработки начала падать.

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

По итогам технического аудита мы помогли:

- пересобрать часть состава; 
- вернуть senior-специалистов на ключевые позиции;
- выстроить прозрачный процесс согласования специалистов.

После этого ситуация довольно быстро стабилизировалась: скорость разработки выросла, а планирование снова стало предсказуемым.

К сожалению, на рынке СНГ эта история не про одного конкретного вендора, и такие случаи происходят все чаще.

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

Есть еще два наблюдения из практики.

Если вам предлагают senior-разработчика по ставке дешевле 25$/час, вас 100% обманывают. 

В таких ситуациях реальный уровень специалиста оказывается ниже заявленного.

И второе: наличие сильного техлида и PM значительно снижает риск подобных ситуаций.

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

А вы уверены, что на вашем проекте работают именно те разработчики, которых вы интервьюировали?