Закончил на днях технический аудит очередного клиента. Хочу поделиться историей, которую вижу буквально в каждом втором случае.
Начинается новый бизнес, сильно завязанный на софте. Первое время, все классно: один программист — хорошо, два — почти в два раза лучше. 10 программистов — можно делать вещи, о которых раньше и помыслить было нельзя.
Через 3-6 лет в компании уже 50 разработчиков. Продукт при этом практически не развивается, фичи доставляются разработкой в продакшен со скорость улитки. Добавьте к этому зарплаты разработчиков в 100-400 тысяч в месяц и вы можете представить, что чувствует бизнес. Почему так?
А происходило вот что: все эти годы, каждый раз, когда нужно было выбрать между «сделать фичу побыстрее прямо сейчас» и «сделать так, чтобы это можно было потом поддерживать, пусть и подольше прямо сейчас» — бизнес с разработкой вместе выбирали первый вариант. Логично, что рано или поздно гора неподдерживабельного кода становится слишком высокой и уже никто не может докинуть ещё что-то сверху.
Сложно винить в этом бизнес: они не обладают компетенцией, чтобы ясно увидеть, как копают себе яму. Сложно винить разработку: спорить с бизнесом очень трудно, они профессиональные переговорщики, а объяснять разработку не-технарям — редкий скилл, отличный от умения писать крутой софт. Вообще, этот процесс требует взаимного доверия и открытости, когда бизнес пытается вникнуть в разработку, а разработка — подумать о бизнесе, с помощью друг-друга.
В общем, искать виноватого смысла нет, а варианты решений следующие:
1. Если это допустимо, то перевести проект в режим поддержки, пусть зарабатывает сколько может, большую часть команды уволить или перекинуть на новый бизнес-проект. Этот вариант выглядит радикальным, но по сути — самый простой, не требующий изменений подходов к работе. Вариант со звездочкой — с помощью той же команды написать с нуля новое решение — конкурента старому, учтя уроки прошлого.
2. Если же вам нужно развивать то, что есть — то впереди вас ждут пот и слёзы.
Во первых, признайте, что это не случайность и не временные трудности, а капитальная жопа, выбираться из которой месяцы, если не годы. Быстрых и дешевых решений, к сожалению, нет. И нет, применение нового фреймворка типа эджайла или канбана — не поможет.
Нужно отдавать технические долги и приводить код в порядок. Технически, есть несколько основных подходов и обычно используется их комбинация. Подход первый: выделить изолированный кусочек проекта и переписать его «начисто», минимально затрагивая остальные части. Подход второй: начать писать тесты поверх функциональности, которая есть. И тд и тп. Это — исключительно сложная инженерная работа. В несколько раз сложнее, чем написать аналогичный проект с нуля. Плюс в том, что вы так потеряете меньше знаний, который вложили в продукт за эти годы.
Организационно, вам придётся выделять на это адское количество времени и сил. Речь о 30-50% времени ваших инженеров. Результаты, в плане увеличения скорости разработки, вы увидите через месяцы в лучшем случае. Другого пути я не знаю.
Также, имеет смысл добавить в команду новых опытных бойцов. Дело тут не только в технической компетентности, но и в отсутствии психологических «долгов», свежести и незамутненности взгляда, в четком мандате на перемены. Желательно, чтобы человек уже имел опыт подобного рефакторинга.
В общем, это — путь смелых.
—
Добавлю, что обычно, ко всем этим техническим проблемам добавляется ещё и нежелание признать реальность, когда бизнес требует, а команды регулярно обещают больше, чем могут реализовать. В результате, разработка постоянно существует в режиме пожара (какая уж тут инженерная культура, когда ничего не успеваешь!), а бизнес постоянно не доволен и не верит обещаниям программистов.
Приведение этого процесса в порядок — отдельная работа, но об этом — в следующий раз.