Когда нужно уйти из проекта

http://englishrussia.com/2009/07/24/russian-jet-fighter-cabrios

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

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

Аргумент этот связан с ситуацией, когда в разрабатываемой системе назрел “The Big Rewrite” — положение, при котором количество технических проблем, сопровождающее текущее поступательное развитие системы, превышает некоторый психологически важный порог. Проще говоря, когда количество костылей, вставляемых в ПО при разработке очередной фичи, начинает бесить разработчиков и негативно влиять на развитие продукта. При этом, какой-то части команды становится понятно, что нужно частично или полностью переписать систему. Обычно “переписать” означает разработать полный аналог, приняв иные дизайнерские и архитектурные решения, отличные от тех, которые были заложены при первоначальной разработке.

Порог именно психологический. Можно было бы подвести под это какую-то экономику, посчитав сколько времени тратится на “костыли” и показав, что инвестировав X времени в переписывание, мы на дистанции Y месяцев съэкономим Z денег и окупим затраты на переписывание, а дальше будет сплошной профит. Но это всё равно почти никто не умеет считать.

На пути переписывания часто встает существенная преграда. И это не ребята из бизнеса, как можно было бы подумать сначала. Они-то как раз нередко осознают, что системы устаревают и не соответствуют новым требованиям, и готовы обсуждать выделение нужных ресурсов. В конце концов, кто как не они каждый год-полтора полностью переделывают промосайт продукта, т.к. старый уже не “торт” ☺

Преграда эта — психология тех самых “ключевых” разработчиков, которые часто работают в проекте с самого его начала и воспринимают назревшую потребность в переписывании как доказательство своих ошибок, совершенных в момент принятия ключевых решений. Т.е. они воспринимают переписывание как прямое следствие того, что конкретно они в какой-то момент времени в прошлом приняли ошибочные решения, и все последующие костыли есть следствия этих ошибок. А значит, разговор о переписывании равняется разговору об их технической некомпетентности, о том, что они оказались не способны развивать проект так, чтобы технический долг не накапливался до критических значений. “Ключевые” программисты, как правило, уважаемые и авторитетные люди и не любят подрывать свой авторитет. И, как следствие, держатся за прошлые решения, не желая признавать своих ошибок.

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

Именно в такой момент уход “ключевого” инженер(а/ов) может оказать положительное влияние на развитие продукта. Уберёт тормоз для “переписывания” и запустит этот непростой процесс. При этом важно постараться сохранить знания о том, почему были приняты те или иные технические решения, чтобы после переписывания не получить систему с такой же функциональностью, но другим набором багов. Мы же знаем, что старый баг лучше новых двух ☺

Так что, коллеги, особенно опытные, не сидите на месте по-долгу. Меняйте проекты, от этого хорошо и вашей карьере, и вашим профессиональным навыкам, и продуктам, которые вы разрабатывали.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.