Rescue image via Shutterstock.Перед прочтением этой статьи рекомендуем ознакомиться с предыдущим материалом: «Как реанимировать старый безнадежный проект. Часть 1: Рефакторинг vs переписывание с нуля».
Муки выбора: формат команды и проекта
Кроме первой проблемы — «рефакторинг vs переписывание с нуля», вас ждет не менее увлекательная задача — построение команды и проектов.
Вы можете:
1. Создать две конкурирующие команды. Одна из них сопровождает старый проект, вторая — пишет новый.
2.Создать два проекта (новый и старый) в рамках одной команды.
В первом случае старая команда остаётся сопровождать умирающий проект, пока новая команда с нуля переписывает систему. Стоит предостеречь от искушения выпускать переписанную систему только после полного повторения функциональности старой системы. Зачастую такое решение приводит к очень долгому противостоянию между старым и новым проектом, время разработки нового проекта затягивается из-за неоправданно высоких ожиданий по функциональности. Программисты испытывают давление со стороны менеджмента, а от старой команды всё чаще слышны смешки «уж два годка как ждем релиза». В таких условиях программисты «нового» проекта вынуждены торопиться и совершать ошибки, они пишут «грязный код», часть из них разочаровывается и покидает проект, а спустя время вы получаете хаос ничуть не лучше, чем в старом проекте.
Чтобы избежать этой участи, нужно установить разумные рамки функциональности новой системы. Это тот самый случай, где без MVPи разумного системногоаналитикавам просто не обойтись. А во избежание ненужной конкуренции между командами — изолируйте их друг от друга, разместив офисы разработчиков, например, в разных концах города. Связующим между старым и новым проектом должен выступать аналитик, но никак не разработчики.
Очень часто встречается ситуация, когда старая команда ничего не знает о написании новой заменяющей системы. Это один из худших вариантов, с которым вы можете столкнуться, потому что в результате порождаются сразу несколько рисков: если заранее не побеспокоиться о том, как вы будете старой команде объяснять причину её внезапного роспуска, то о вашей фирме поползут неприятные слухи в профессиональной среде. Если о ситуации станет известно новым разработчикам, что скорее всего и случится, то они вполне справедливо могут посчитать, что вы с лёгкостью можете поступить с ними так же.
Почему работодатели не ставят в известность разработчиков старой команды о написании новой системы? Они беспокоятся, что команда, узнав о скором закрытии своего проекта, откажется его сопровождать. Найти выход из этой ситуации, морально подготовить команду и корректно сообщать ей эти непростые новости — еще одна головная боль, о которой нужно подумать заранее.
Выпускать новую систему как заменитель старой или создавать внутреннего бренд-конкурента — вопрос к маркетолагам, но над этим тоже следует подумать заблаговременно.
Разумеется, ни о каком рефакторинге при использовании данного подхода речи быть не может. Такая стратегия подходит только в случае переписывания системы «с нуля».
Второй способ организации команд и проектов — это создание старого и нового проекта в рамках общей команды.
Для реализации этого плана в команду вводятся новый системный архитектори аналитик. Эти две роли начинают работу над новой системой. Аналитик собирает требования к новому проекту, на базе этих данных архитектор принимает решения о нужной архитектуре системы. На базе принятых решений создаются таски, которые помещаются в общий пул задач.
Суть этой стратегии заключается в создании «конкуренции с самим собой». Старые разработчики получают реальные задачи из нового проекта, которые они выполняют в соответствии с новыми требованиями системного архитектора по новым для них стандартам. В результате разработчик может сравнить старый подход к разработке ПО с новым, «пощупать» предлагаемые технологии и понять их. А всем нам известно, что «к хорошему привыкаешь быстро» — разработчики мотивируются как можно быстрее полностью перейти на новый проект и забыть о старой системе как о страшном сне.
Кроме построения бизнес архитектуры и системной архитектуры, аналитик и архитектор отвечают за теоретическое и практическое обучение старой команды. А так же за построение новых стандартов разработки ПО. По истечении некоторого срока все старые сотрудники должны успешно пройти внутреннюю аттестацию, чтобы продолжить работу на новом проекте. Поддержка старого проекта по мере необходимости прекращается.
Стоит упомянуть, что команда будет препятствовать грядущим изменениям всеми возможными средствами. Вариант «всех уволить» нам не подходит, т.к. кто-то должен сопроводить старый «не-пойми-как-работающий» продукт. И чтобы минимизировать пагубное влияние на принятие решений в рамках новой системы — очень желательно выделить для «Проекта 2» отдельное совещательное помещение (и это не должен быть общий митинг-рум).
Успех данной стратегии во многом зависит от доступности необходимых ресурсов. После первичной оценки объемов будущей системы, архитектор и аналитик могут запросить в команду одного или нескольких новых специалистов. Как правило, для этого есть веские основания, будьте готовы к этому.
Из недостатков этого метода можно перечислить:
1.Сложности при поиске достаточно грамотных и коммуникабельных архитектора и аналитика, которые согласятся обучать команду.
2.По истечении времени часть разработчиков придется уволить, потому что, скорее всего, для сопровождения новой системы понадобится гораздо меньшее количество программистов, чем для старой.
Однако, вместо того чтобы отпускать толковых людей — можно перенаправить высвобожденные человеческие ресурсы на новые направления и проекты. Таким образом, минус может превратиться в плюс.
Данная стратегия применима как для полного переписывания системы, так и для глубокого рефакторинга текущего проекта.
Какой бы подход к построению команд и проектов вы бы не выбрали — предварительно очень желательно провести аудит проекта и девелопмент-процессов. Ведь прежде чем «лечить», нужно выяснить «диагноз». Проще всего попросить о такой услуге знакомого архитектора и аналитика из любого успешного проекта, которым вы можете доверять.
И в завершение, всегда помните: вашу команду формируют личности, у которых есть свои переживания и мысли. У них разные характеры, привычки и коммуникативные способности. Успех вашего предприятия в большей мере зависит даже не от технического уровня специалистов, а от личных качеств этих людей. Каждый из ваших разработчиков — маленький «станочек» в вашем IT бизнесе — он создаёт продукт, который вы продаёте. Никогда не забывайте, что они — живые люди, относитесь к ним по-человечески, и тогда очень велика вероятность, что они ответят взаимностью.
Послесловие
В качестве убедительного аргумента привожу правдивую историю программиста — ныне матёрого системного архитектора, который пытался отрефакторить проект, не имея политической поддержки сверху. Рассказ от первого лица, вот как это было:
«Когда я пришел в этот проект, я понятия не имел, что так можно работать. В предыдущей команде был постоянный кодревью, «били по рукам» за неправильное имя переменной, криво написанную функцию, неправильно выбранный алгоритм, не тот примененный паттерн проектирования и.т.д. У меня был очень красивый код. У меня был правильный стиль. У меня была поддержка со стороны (мой же код постоянно смотрели), и вероятность ошибок падала экспоненциально. Именно такой «светлый», «отчеканенный» я пришел.Первое, с чем я столкнулся, — это хаос. Натуральный кошмар. Хотя в том безнадежном проекте тоже была своя «система». Был таск-менеджер, были таски, сроки, код. Главное, чего не было — это стандарты. И первое, что я сделал, — за неделю написал стандарты кодирования: как переменные именовать, какие отступы, куда ставить скобочки, как писать запросы, какие классы использовать и.т.д.
Сначала стандарты обсмеяли. Потом все-таки их вынесли на утренний митинг. На митинге их бурно обсудили, перевели в холивар:
— А вот я привык пользоваться пробелами!
— А я привык пользоваться табами!..
И так далее. Что потом? А ничего. Каждый остался при своём, и мне сказали:
— Вот видишь, не будут все писать одинаково.Как должен вести себя руководитель в этом случае? Жестко взять и сказать: «хватит бардака! Делаем так и так». Устраивание балагана и/или «пусть всё решает общее вече с утра пораньше» — это банальный уход от ответственности.
Нет системного подхода — бардак! Бардак способен решать задачи, но не способен делать это эффективно. Бардак не способен быстро исправлять ошибки. Бардак не способен не допускать ошибки. Бардак способен плодить ошибки.
Когда вместо набора
if()...if()...if()я предложил использовать Абстрактную фабрику, все, кроме одного парня, спросили: «Что? Что это?» — это было показательно. Есть шаблоны проектирования. Они не с потолка придуманы. И это не уровень «нравится — не нравится». А это уровень «поддерживается — не поддерживается».Я попытался внедрить неймспейсы, но это было сделано некорректно. Многие вещи я тогда не мог по-другому внедрять — от начальства я получал всегда отказ типа: «а нафиг оно надо?», поэтому всё внедрялось так, чтобы не поломать то, что уже есть. И чтобы этих изменений по возможности никто не заметил.
Я пытался внедрить массовое код-ревью — не получилось. И дело не столько в инструментарии, сколько в том, что: «да кто ты такой, что указываешь мне, что делать с моим кодом? Ты сколько тут работаешь? Два месяца? А я — два года. Фигово написано? Не твоего ума дела. Работает? Вот и не компостируй мозг».
Я переписывал тихо. Один парень там умел спорить и доказывать. Если не получилось доказать — он не исправлял ничего. Работало, как работало. Я же молча и без шума что-то менял сам, и тихо радовался своей работе. Никто этого не оценил. В конечном итоге я ушел. Меня ждали новая компания, новый мир, бурный рост, осознание собственной глупости.
Ты спрашиваешь, почему я ушел: я начал тупеть. Очень сильно. За неделю до ухода я открыл фрагмент кода, посмотрел и обалдел: он был очень красиво написан.
И мне стало интересно, кто ж у нас так красиво пишет. И когда я понял, что это был мой код, написанный в первую неделю в этой конторе, — меня поразило, как сильно я деградировал. А на новом месте в первый месяц я очень тупил.
Я рад, что ушел в новую компанию, где мои качества оценили по достоинству. Очень приятно заниматься любимым делом, реализовать себя, быть нужным и уважаемым специалистом, да еще и получать достойную компенсацию за свой труд".
Сердечно благодарю Славу Конашковаза профессиональные консультации и помощь в написании этой статьи.