Держи код, что делать дальше — разберешься. Инструкция по выживанию в legacy-проектах
Меня зовут Рената Решетникова, я Project Manager в NIX и спикерка NIXMultiConf. В IT-сфере уже четыре года. За это время сопровождала 45+ проектов с командами от 3 до 20 человек и на личном опыте познала многие сложности legacy-проектов, научилась выходить из сложных ситуаций и решила поделиться лайфхаками.
Legacy-проект — это как ящик Пандоры: никогда не знаешь, что из него достанешь. Иногда сталкиваешься с такими головоломками, что и нескольких недель командной работы не хватит, чтобы разгадать суть. Вдобавок ко всему — разбираешься с багами и ограничениями архитектуры, лавируя между целями и бюджетом клиента.
Проектным менеджерам вести такие проекты сложно, поэтому мне захотелось поделиться своим опытом и знаниями. Верю, что эта статья поможет начинающему РМ’у понять, на что обратить внимание, как успешно поддерживать и сдать legacy-проект.
Иллюстрация создана при помощи Awesomic
Что такое legacy project
Это проект, разработкой которого изначально занималась не ваша команда. Чтобы прогнозировать риски и строить дальнейший процесс разработки, сначала важно определить тип legacy-проекта. Я выделяю такие:
- «предрелизный» — проект еще находится в стадии разработки;
- «пострелизный» — проект в продакшене, и продукт уже доступен конечным пользователям.
В случае пострелизных проектов цена ошибки высока. Любой недочет напрямую влияет на опыт пользователей и может испортить впечатление о продукте.
О предрелизном проекте пока никто не знает, кроме предыдущих разработчиков. Но и здесь может быть подвох. По каким-то причинам идея не воплотилась либо была реализована частично — и теперь вам разбираться с ее витиеватой логикой.
Однажды мы с командой взялись переписывать фронтенд с одной технологии на другую. Бэкенд оставили, новых фич в системе не добавилось. Казалось бы, все просто. В процессе выяснилось, что есть data-ориентированные куски системы — новые страницы, которые внезапно открываются при комбинации определенных данных. Система была настолько объемная, что на этапе presale выловить такой нюанс было проблематично. В итоге все эти необнаруженные части системы не были учтены в изначальном расчете бюджета и сроков.
Знакомство с клиентом и продуктом
Чем больше вы знаете о заказчике и проекте, тем лучше вооружены и готовы к сюрпризам. Перед личной беседой полистайте соцсети клиента, посмотрите, что пишут в интернете о компании и ее деятельности в целом. У вас сложится представление о том, с кем вы будете выстраивать сотрудничество. На первой встрече важно показать уверенность и профессионализм. Нужно уметь слушать и слышать заказчика. Важный момент — проявить заинтересованность продуктом, который переходит в ваши руки.
Пострелизный проект можно оценить с позиции конечного потребителя. Здесь основное преимущество — возможность погрузиться в предстоящую работу с пониманием имеющегося функционала и удобства его использования.
Ключевые вопросы, которые нужно задать клиенту на старте
Я сформулировала общие вопросы, которыми пользуюсь сама. В зависимости от специфики проекта, могут быть и другие, но пока рассмотрим эти.
Какая бизнес-идея продукта? Как ни странно, клиент может не понимать, как будет зарабатывать или какую другую пользу будет получать с помощью своего продукта. Бизнес-модель должна быть четкая и ясная. С этим напрямую связан успех и востребованность продукта на рынке.
На какой стадии разработки находится проект? Выясняете, к какому типу legacy-проектов относится ваш (см. выше).
Сколько у продукта пользователей? Для пострелизного проекта узнайте количество пользователей на текущий момент и проговорите ожидания клиента о нагрузке в будущем. Если проект еще в разработке, вам остается только вторая часть вопроса — предполагаемая нагрузка.
Есть ли важные для клиента даты? В моей практике у заказчиков были ивенты, на которых они должны были презентовать продукт, демонстрировать прогресс разработки на публику. К таким мероприятиям у вас должна быть готовая итерация продукта. Задача команды — показать, насколько вы продвинулись с тем или иным этапом. Спросите у клиента о календаре важных дат и учитывайте его при планировании работы команды.
Что не устраивало в прошлой команде и какие проблемы беспокоят клиента сейчас? Без четких ответов на эти вопросы вряд ли все пройдет легко и вы не наступите на те же грабли. Обычно вендор меняется из-за того, что работа команды не оправдала ожидания клиента. Понимая проблемы, с которыми столкнулись предыдущие разработчики, вы сможете исключить их в налаживании своего процесса. Конечно, абсолютно всех трудностей не избежать. Но вы хотя бы попытаетесь расположить к себе клиента, минуя эти «болевые точки».
Как работать с артефактами legacy-проекта
Следующий этап — анализ входящей информации. К нему относятся различные артефакты — код, документация, информация об архитектуре проекта и так далее. Внимательно изучите каждый.
Ревью кода. Получив доступ к репозиторию или архиву с кодом, узнайте у клиента, насколько текущая версия кода актуальна. Сумбур и недопонимание никому не нужны. Ревьювить код — это одно, а убедиться в его работоспособности — совершенно другое. Разверните проект у себя и проверьте, запускается ли он вообще, корректно ли работает заявленный функционал.
Ревью документации. Скажу честно: в моем опыте практически не было legacy-проектов с подробным описанием, чтобы достаточно было прочитать и понять историю прошлой разработки и ключевой функционал. Обычно ситуация прямо противоположная. Продукт «прилетает» без единой детали. Есть код, а дальше — разбирайтесь. Но кода для этого недостаточно. Чтобы сфокусироваться на отдельных компонентах системы, надо иметь полное представление о ней. Без этого многое останется незамеченным, в том числе ошибки в разработке и риски. Подключайте аналитика и клиента, чтобы выявить белые пятна. Плотное общение «РМ — аналитик — клиент» советую поддерживать на протяжении всей работы.
Текущая архитектура. Архитектура — это фундамент проекта. Если он непрочный и непродуманный, что бы вы не воздвигли, все может рухнуть. Архитектура legacy-проекта — это то, что уже решено за вас. Однако всегда есть варианты, как эти решения изменить, адаптировать. Или прямо заявить: текущая архитектура не приведет клиента к успеху, поэтому ее нужно переделать. В своих командах я уделяю много времени обсуждению архитектуры, осмыслению и валидации идей.
Текущая инфраструктура. Узнайте, какие сервера использует клиент для хостинга, соответствуют ли их возможности потребностям продукта.
Интеграция и зависимости из прошлой разработки. Если раньше продукт интегрировали с каким-то сервисом, выясните, есть ли у вас соответствующий опыт работы. Не теряйте время. Возможно, придется что-то подучить, чтобы продолжить качественную работу.
Система учета задач от предыдущей команды. Вряд ли прошлая команда даст доступ к ней, но попробовать можно. Дополнительная информация лишней не будет. Особенно если нет полноценной документации о проекте.
Ключевые артефакты проанализировали. Теперь есть основа для прогнозирования и минимизации рисков.
Типичные риски и их решения
Вы уже на низком старте. Прогнозирование рисков — этап, который обезопасит всю команду и позволит подготовиться к различным маневрам не лету. В legacy-проектах я выделяю несколько распространенных рисков. Пройдемся по ним и рассмотрим способы минимизации.
Клиент преподносит legacy-баги как новые. Заказчик не всегда внимателен или может просто не запомнить, в каком состоянии передал вам продукт. Сделайте «слепок» проекта до начала работы и зафиксируйте перечень legacy-багов. В дискуссиях о качестве продукта у вас уже будет козырь. Также обсудите возможные варианты работы. Все зависит от целей и пожеланий клиента:
- сначала исправить найденные дефекты и затем приступить к реализации новых запросов;
- начать разработку нового функционала и параллельно исправлять старые баги.
Архитектура имеет ограничения. Во время ревью архитектуры покажите клиенту проблемные зоны. Но не просто указывайте на узкие места, а предложите пути решения/улучшения. Вы сможете избежать проблем, а заказчик увидит, что из себя сейчас представляет проект.
Превышение прогнозируемого бюджета. Работать с legacy-проектами по схеме fixed price практически невозможно. Риски настолько велики, что лучше на это не соглашаться. Предложите клиенту схему time and material, когда оплачивается все затраченное на разработку время. Параллельно стоит вести учет бюджета и отправлять клиенту копию, например, каждые две недели. Интервал выбирайте сами. Главное — держать заказчика в курсе.
Можно говорить о приблизительных цифрах и привязывать их к примерному скоупу, под которым вы подписываетесь. Открывая потайные уголки системы в процессе работы, честно заявляйте: «Этого мы не учли. На устранение проблемы требуется дополнительное время и бюджет». Если у клиента есть деньги и он готов их потратить, скорее всего, подобные вопросы получится быстро закрыть. Однако, когда есть ограничения по финансам, а проект настолько тяжелый, что текущий бюджет и рядом не стоял, задумайтесь: надо ли вам это?
Каждый проект привносит что-то свое в список рисков. Мой чек-лист постоянно пополняется массой нюансов. В любом случае каждая набитая шишка обогащает опытом. В будущем каких-то рисков точно удастся избежать. А если они все-таки появятся, возможно, мои советы помогут.
Со временем клиент перестанет воспринимать legacy-проект как «унаследованный» вами. Он будет считать продукт детищем теперешней команды. Вся ответственность и новые проблемы лягут на ваши плечи, как и успех (добавим нотку оптимизма :)). Что получится в итоге, зависит от работы всей команды. В аутсорсе вы непременно столкнетесь с legacy-проектами. Я надеюсь, что эти советы станут подспорьем на старте вашей работы, помогут не наломать дров и выбрать правильный путь.
И помните: удача — это немного везения в комбинации с опытом. Не бойтесь ошибаться, ведь это путь к повышению профессионализма при должном уровне рефлексии и самоанализа.
Удачных и интересных проектов всем нам! :)
