Проекты быстрой "разморозки"

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

Вариант 1. Участники проекта (один или несколько) все ещё работают у нас. Они быстро вспоминают - что это за проект, оценивают размеры «хотелок» заказчика в человеко-часах, в идеальном варианте подключается аналитик, который вел требования по проекту. Проект «размораживается» очень быстро, и сама деятельность по «размораживанию» стоит компании совсем мало времени (а значит и денег). Разработчики уже в курсе предметной области и архитектуры системы, их оценки точны, шансы на успех нового проекта (по доделке старой системы) очень высоки.

Вариант 2. А теперь – плохой вариант развития событий. Все кто занимался данным проектом – уже уволились (учитывая смену работы у людей, в среднем, раз в два года и небольшой размер команд – дело самое обычное). И у потенциального руководителя проекта возникает целый ворох проблем. Например

• Найти материалы по проекту – требования (если они вообще были), исходники последней версии (трясти админов).
• Напрячь людей на вхождение в курс дела. Аналитикам выдать требования, попытаться выяснить, насколько вообще эти требования актуальны. Разработчиков напрячь развёртыванием исходников и необходимого окружения (в случае старых разработчиков, рабочее и тестовое окружение может уже быть где-то развёрнуто).
• Выждать время пока аналитики и разработчики вникнут в предметную область и разберутся с уже созданной системой, и потом маленькими шажками выяснять насколько затратны новые хотелки заказчика. Люди которые создавали данную систему, как правило, могут быстро оценить – насколько реализуемо то или иное улучшение \ изменение. Новые люди могут не знать тонкостей архитектуры и особенностей реализации (кривых и сложных мест).

И это все чистые затраты этапа пресейла. Возможно, что придётся все это время (деньги) потратить впустую, и договор на развитие не будет подписан. А даже если и будет, то вероятность успеха – уменьшается.

Естественно всем хочется первого варианта развития событий. Однако рассчитывать на то, что ваши разработчики будут на вас работать десятилетиями – не стоит.

Предлагаю опустить обсуждение вопроса «кто виноват» и сразу перейти к «что делать».

На лицо стандартная ситуация по управлению рисками.

Риск. С уходом ведущих разработчиков стоимость «размораживания» проекта существенно возрастает, а шансы на успешную модификацию системы – падают.

Индикатор риска. Текущий проект завершается с большим набором новых «хотелок» заказчика «на будущее», но прямо сейчас покупать развитие проекта заказчик не хочет \ не может.

Способ избежать риска.

Не отпускать разработчиков :) . К сожалению это практически нереально – людям может просто захотеться сменить обстановку. Поэтому серьёзно на это рассчитывать не стоит.

Способы ослабить риск.

Вот тут начинается самое интересное.

Способ первый. При увольнении, ведущий разработчик (или архитектор) передаёт свои знания о проектах другим разработчикам (архитекторам). Прямо садится и рассказывает где что и как сделано в этой системе, почему именно так, а не иначе, рассказывает про предметную область, указывает на проблемные и сложные не очевидные места в коде, архитектуре, базе данных. Все это сопровождается показом исходников, а слушающий товарищ все это дело конспектирует, задает вопросы – входит в курс дела. Можно даже рассказать об известных будущих «хотелках», которые, скорее всего, заказчик купит в будущем. Чтобы мотивировать слушателя, ему сообщается, что в случае чего, именно он станет ведущим разработчиком (архитектором) на развитии данного проекта. Происходит прямая передача знаний. Аналитики могут поступать аналогичным образом.

Когда этот подход можно применять? Во-первых, когда текучка не очень большая. Если знания передадутся из уст в уста 3 раза, то от них ничего уже не останется. Должна существовать большая вероятность что тот, кому передают знания в первый раз как раз и будет заниматься развитием проекта. Во-вторых, сам проект не должен быть сделан откровенно плохо. Потому что перспектива доделывать невероятно кривой и глючный проект, в котором даже малейшее изменение может вызвать огромный поток незапланированных работ по «переклейке заплаток» - отпугнет любого нормального разработчика. Он вас просто лесом пошлет с таким «наследием» и уволится вслед за первым. :)

Способ второй. В процессе работы над проектом требования и техническая документация (архитектура и дизайн) поддерживаются в актуальном состоянии. При завершении проекта документация проверяется. В результате должен появиться комплект документов, по которым человек даже не знакомый с проектом сумеет быстро вникнуть в суть дела. Тут очень важно понять одну вещь. В реальной работе написание документации и требований служит одной важной цели – добиться общего видения разрабатываемой системы у всех участников проекта. Если участников 2-3 человека и они к середине проекта прекрасно себе представляют как должна выглядеть и как должна работать система, и это видение совпадает с видением заказчика, то написание подробной документации превращается в пустую трату времени. Если до финиша остался месяц, и все разработчики в курсе предметной области, архитектуры, и т.п., то тратить деньги проекта на какое-то описание (которое может и не понадобиться) – жаба задушит :). Под описанием я не обязательно понимаю какие-то word’овские документы. Это могут быть требования в какой-то системе управления требованиями, use-cases, диаграммы классов, описание архитектуры, база знаний «заплаток» и т.д. В маленьком и «понятном» проекте есть соблазн пожертвовать техническим описанием в угоду эффективности. Для слаженной команды требования могут быть не очень четкими, полными или актуальными – у всех есть общий контекст. Для новичка у которого не будет контакта с «хранителем сакрального знания» о проекте - четкая, полная и актуальная документация просто необходима.

Получается, что вложение сил в поддержание хороших требований и дизайнерской документации – это вложение в потенциальное будущее. Повышение той самой «сопровождаемости» (maintainability) программного продукта. Достижение стратегических целей в ущерб тактическим успехам. Страховка. И забота эта, прежде всего, топ-медеджмента. Потому что maintainability не является целью руководителя проекта. Его задача – уложиться в установленные ограничения. То, что поддержка и развитие продукта будет стоить дорого – это просто новое ограничение, в которое он постарается уложиться. Потом. Если оно вообще случиться. Снижение стоимости поддержки и развития продукта – задача топов, занимающихся стратегией.

Итого. Проблема передачи знаний о проекте довольно актуальна. Прямая передача знаний от разработчика к разработчику – самый дешевый и эффективный способ. Но он не всегда срабатывает. Более надежный, но дорогой способ – поддержание в актуальном состоянии требований и технической документации. Выбор того или иного способа должен быть осознанным. Чтобы удешевить процесс ведения требований необходима удобная система управления требованиями (вот так банально, да). Но это совсем другая история...