Вообще первые лет 8 работать легко. Все растет и развивается, ты меняешь свою роль в компании и каждые пару лет погружаешься в новые домены. Сначала я в основном программировал, потом налаживал процессы на уровне команд, потом занялся UX и всем что с ним связано, потом культурой компании, потом визуализацией информации. Каждая тема довольно глубокая и интересная. Но потом начинают происходить интересные вещи: ты набираешься опыта и начинаешь замечать огромное количество недостатков. Раньше-то они были скрыты, потому что продукт свежий на новом рынке, а тут рынок развивается очень быстро, а продукт уже не успевает. И ты с биноклем накопленного опыта вглядываешься в даль и понимаешь, что… ну что-что, пиздец! Все надо переделать. Вот тут-то тебя и накрывает.
Переделка продукта с нуля невероятно рискованное мероприятие, которое далеко не всегда заканчивается хорошо. Накопленный опыт штука довольно хитрая. С одной стороны, ты проблемы видишь. Но с другой стороны в качестве решения ты пытаешься подняться наверх по уровням абстракции, и это может окончиться божественной системой, которая должна решить ВСЕ ПРОБЛЕМЫ. И тут три варианта:
Надо понимать, что если предыдущую версию системы вы делали лет 8 или 10, то на новую придется потратить ну никак не меньше 3–4 лет. Это с учетом знаний, опыта, более прогрессивных технологий, команды блестящих программистов и удачи. Терпение заканчивается года через 2, поэтому обычно ничего не получается.
Если терпения все же хватает, то есть какой-то шанс успеха. Однако, как рациональный руководитель, ты вроде бы не должен увлекаться жирным, но очень далеким журавлем. Поэтому большинство продуктов никогда не переписываются с нуля, а пытаются развиваться эволюционно. Этим занимаешься и ты.
И вот тут тебя через пару лет накрывает снова. Ну как же, у тебя в голове есть крутейшее решение всех проблем, а вместо этого приходится иметь дело с замедляющейся эволюцией старого продукта, который оброс бесполезным и даже вредным функционалом. И ладно бы все быстро происходило, но ведь скорость разработки падает, нужно все больше программистов чтобы сохранять даже текущую скорость. Об ускорении даже речи не идет. Жизнь становится безрадостной, а планы — недостижимыми.
Выход один — довериться варианту номер 3, но выделить для его реализацию очень маленькую команду хороших программистов (2–8 человек, не больше). Дальше надо как-то сделать, чтобы эта команда смогла и захотела работать 3–4 года. Достигается это как можно более ранним релизом и живыми пользователями. Если первый релиз занимает больше года — команду тоже накроет. Не допускайте выгорания.
С основным продуктом можно сделать две вещи: либо продолжить эволюционное развитие (ну так себе дорога), либо приложить серьезные усилия для ускорения разработки: постепенный переход на новую архитектуру, переписывание некоторых модулей, и все такое.
В случае почти закономерного провала варианта номер 3 у вас все же останется шанс на успех. Но даже в случае тотальной неудачи по всем фронтам у вас будет бесценный опыт и один успокаивающий ответ “я попытался”.