Полная переделка проекта - камень преткновения на старых проектах

В большинстве старых, больших проектов есть две силы: разработка, которая хочет все переписать, и бизнес, который ни в коем случае не хочет этого допустить. Кто прав? Давайте разбираться.

Почему разработка все время хочет все переписать
Сразу развеем один распространенный миф. Среди многих бизнес команд бытует мнение, что IT команде совсем не интересен продукт, - это не так. Все любят делать проект для людей, чтобы им пользовались и чтобы он приносил пользу. Ничего так не демотивирует команду, как задачи сделанные “в стол”.

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

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

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

Почему бизнес сопротивляется
Бизнес при этом не видит каждый день тех проблем в коде, которые видит разработка. У него все идет, как обычно, возможно задачи стали делаться чуть дольше, возможно ошибок на проекте стало больше, может немного текучка разработки увеличилась, но это все бывает и по другим причинам. Однако, чаще всего, сам продукт работает, как обычно (если проблемы с кодом не сказываются на производительности проекта). Он приносит деньги, приходят пользователи, клиенты, идут продажи. Есть много планов на будущее, которые хочется реализовать. А самое главное, есть конкуренты, которые постоянно дышат в затылок и стараются обойти.

И тут приходит разработка и говорит, что надо все срочно останавливать и переписывать проект с нуля ближайшие полгода - год. Если разработка видит после переписывания удобно отлаженный проект, то бизнес видит потерю позиций на рынке, падение прибыли, а может быть и полное банкротство, потому что конкуренты за этот год уйдут так далеко вперед, что догнать их может уже не получится. Желание тут же категорически отказаться тоже вполне понятно.

Так кто же прав?
Все зависит от ситуации на конкретном проекте. Бывают случаи, когда разработка слишком спешит и предлагает слишком радикальные меры. А бывает, что проект действительно нужно срочно спасать, иначе никакая конкурентоспособность на рынке ему не светит уже по причине полной потери работоспособности. Как решить, что делать конкретно вам, расскажем в следующих постах.

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

#agile #управлениекомандой #разработка #ит #бизнеспроцессы