Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Держи код, что делать дальше — разберешься. Инструкция по выживанию в 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-проектами. Я надеюсь, что эти советы станут подспорьем на старте вашей работы, помогут не наломать дров и выбрать правильный путь.

И помните: удача — это немного везения в комбинации с опытом. Не бойтесь ошибаться, ведь это путь к повышению профессионализма при должном уровне рефлексии и самоанализа.

Удачных и интересных проектов всем нам! :)

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось12
До обраногоВ обраному7
LinkedIn

Схожі статті




41 коментар

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Не смотря на то, что опыт автора привлек больше внимания, чем содержание статьи. Считаю, чтоподобную инструкцию важно бы показать sales отделу на этапе pre-sales, когда идет согласование условий работы и проясняются ожидания клиента.

И самому клиенту ответить честно на вопросы, в каком состоянии все таки его продукт, чтобы возможно, скорректировать свои планы, а не искать другую команду, которая быстро, дешево сделает чудо, которое предыдущая команда не смогла сделать.

К ключевым вопросам добавила бы, а какой беклог в планах у клиента на ближайшие 3-6 месяцев (в связке с вопросом о важных датах). Активная разработка в заведомо нестабильный продукт к какой-то дате превратит разработку в добавление *костылей на вчера* на существующие костыли.

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

Если же клиент готов к изменениям, включая рост команды и изменения процессов, проверьте у себя внутри, а сможет ли компания оперативно найти\подключить необходимые ресурсы, чтобы поддерживать рост продукта. Иначе — несколько людей не смогут (даже с овертаймами) поддерживать продукт за команду, которая должна состоять из десятка людей с соответствующими ролями.

Как я скучно живу, 21 лет в этой вашей АйТи и всего с десяток проектов.
По легаси все просто, нет тестов нет работы с легаси. Сначала тесты — потом стулья.

В IT-сфере уже четыре года. За это время сопровождала 45+ проектов с командами от 3 до 20 человек

Это как Давидыч в интервью Дудю: «Делаю пресс 3000 раз» :)

В цитате выше, равно как и в моей фразе, НЕ СКАЗАНО — «за один раз». Поэтому не вижу никакой проблемы в том, чтобы за 4 года сопровождать 45 проектов, равно как и в принципе сдлеать пресс 3000 раз :) Удачи в достижениях!

После подобных статей я начинаю понимать почему ПМ стоит как одна четвёртая программиста

Вы уверены в информации, которой обладаете? Советую в ней усомниться :)

Сомневаться в информации — моя работа. Но есть статистика. П.М. это две

IT-сфере уже четыре года. За это время сопровождала 45+ проектов с командами от 3 до 20 человек и на личном опыте познала многие сложности legacy-проектов, научилась выходить из сложных ситуаций и решила поделиться лайфхаками.

кажеться дальше читать нет смысла.

Это ваше право.

Какая бизнес-идея продукта?

С точки зрения legacy-аутсорса, не настолько уж и критично.
Может быть критичным, если планируется выстраивать длительные отношения с заказчиком и команда выступает как единственный центр разработки клиента. Если же это — типичный аутсорс, то есть, команда — это 1 из многих центров разработки, этот вопрос будет абсолютно неинтересен, поскольку вся работа будет происходить в режиме «вот вам таска, когда сделаете?»

Похоже вы путаете аутсуртнг с аутстафингом. Первое как раз аутсурсинг — т.е. офшорная разработка на заказ. Второе аутстафинг — т.е. вынос персонала за штат компании и работа с ними через посредника.

Кто сказал, что в аутсорсе Вам отдадут всю систему целиком? Могут отдать 1 модуль на переписать, как, например, UBS и DB делали в Люксе.
Задачи ставились примерно так: вот вам модуль, напишите такой же, только на Java, нам надоело разрабов на коболе искать.
Какое у него бизнес- значение- не парило никого, поскольку задачи «сделать лучше» не было. Была задача сделать так же.

Да, поддерживаю ответ Виктора. Также, если мы будем говорить об аутстафе, то и в этом случае я бы не игнорировала понимание бизнес-идеи. Ибо все в коненчом итоге будет сводиться к тому, насколько успешным будет результат труда ваших ребят. И я не говорю сейчас просто о качественно написанном коде, а в принципе о «нужности» его как таковом.

см. выше. Я не говорю, что это — единственный возможный кейс, но таких оч много. Я бы сказал, не меньше трети, а то и половины аутсорса.

в моем опыте практически не было legacy-проектов с подробным описанием, чтобы достаточно было прочитать и понять историю прошлой разработки и ключевой функционал

І в моєму практично не було. Вочевидь, ідея написання внутрішньої технічної документації для передачі проєкту не працює на практиці. Ще там якщо виставляється якесь публічне API чи SDK, то можна сподіватися на якусь доку. Але от так, щоб команда писала технічну документацію з усвідомленою метою спрощення розуміння для іншої команди, якій колись доведеться прийняти код — такого не буває. Нам потрібна якась нова ідея організації знань, бо ця не працює.

Это достаточно сложная и фундаментальная работа.
Проблема в том, что она мало кому нужна, и работодатель не скажет за нее ни спасибо, ни премию не выпишет. Т.е. перед тобой огромный пласт работы и ~0 мотивации ее делать. Вот и все причины.

Увы, это так. Даже зачатки такой актвиности на старте проекта со временем сходят на нет. В начале проекта никто не отрисовывает в будущем возможность передачи проекта и как результат необходимость в создании такой документации. И Дима правильно подметил, что это много работы, польза от которой многим не видна ((

легаси проект которым занималась не ваша команда (но в пределах одной фирмы) это еще лайт вариант. бывает легаси проект который появился в результате мерджа или покупки одной фирмы другой вместе с их продуктом. при этом стандарты качества написания кода в той «другой» фирме могут сильно отличаться (часто в худшую сторону)

Это вообще жопа. Когда ты открываешь проект(ы) и не понимаешь что за херня здесь вообще написана.
Потом спустя пару месяцев оказывается, что проект продали (читай спихнули) другой компании потому что спецы-родоначальники накосячили и проект почти нерабочий, а продали его как единорога.

бывает юнит тестов нет, континиус интегрейшен нет, и дебажат прямо на проде :-))))

Ты знаешь, я теперь считаю, что это не такая уж и проблема. Потому что есть много проектов где 3/4 тестов написаны не для того чтобы проверить функционал а чтобы вытянуть кавередж статистику в сонаре. Или написаны так адово что что-то угадать можно только из названия теста.

С континиус интегрейшном тоже самое.

В IT-сфере уже четыре года. За это время сопровождала 45+ проектов

це як?:)

По-разному :) когда бывает по 13-15 проектов параллельно, то и выходишь на такие цифры

Мне кажется, что вы рассказали про «внутреннюю кухню» в вашей компании больше, чем хотел ваш pr-менеджер.

Эм, а что не так? У меня за три года на фрилансе было около 300 проектов. Практически все — успешные. Просто проект-проекту рознь. Одно дело двигать пиксели, другое — данные из майнфреймов в облака. И то и другое называется проект.

Ну, мне как разработчику удобнее и комфортнее работать с ПМом, который на 100% вовлечен в мой проект, а не на 6-7% (или 30мин времени в день)

Когда речь идет о 15 проектах, то , коненчо же, здеь не имеется в виду, что все они в активной фазе полного цикла разработки. Часть проектов на сапорте, часть с минорными доделками по фидбекам, часть на этапе старта и первых активностей, ну и 2-3 в активной фазе. В общую цифру действительно сложно поверить без дополнительных пояснений)) По своему личному опыту могу сказать, что я осиливала 2-3 проекта в активной фазе с размером команды около 10 человек, остальные были небольшие проекты, которые не требовали много времени и сил от меня ибо были «поставлены на рельсы» ранее. И, если уж речь о «внтуренней кухне», то у нас РМ сам может влиять на формирование своей нагрузки — поэтому мой пример и статистика, являются только моими :)

Дякую тобі, боже, що я не PM в NIX.
А розкажіть, як розпланований Ваш день при керівництві 15 проєктами?

як розпланований Ваш день при керівництві 15 проєктами?

1) написать 15 лидам «когда будет готово?»
2) не читая кликнуть «прочитано» на ответ
3) переспросить «так когда будет?»
4) проигнорить второй ответ
5) написать «давайте быстрее, кастомеру надо»
Повторять ежедневно, можно и в субботу.

с вашего описания можно сложить картинку под названием «Как выглядит работа ПМа со стороны»)) Вполне допускаю, что в ряде кейсов без должного погружения в дневную рутину так может казаться. Одновременно с этим, многие действия и решения, о которых команда не в курсе, подчас скрываются под этой мишурой дневной активности. А в результате, «просто» получается, что клиент доволен, выплатил положенные деньги, у людей «магически» появляется то, чего им не хватало и многое другое. Я бы не обесценивала работу другого, не имея возможности погрузиться в нее полноценно.

1) написать 15 лидам «когда будет готово?»
2) не читая кликнуть «прочитано» на ответ
3) переспросить «так когда будет?»
4) проигнорить второй ответ
5) написать «давайте быстрее, кастомеру надо»
Повторять ежедневно, можно и в субботу.

Красиво расписал. Аж руки потянулись написать скрипт и cron джобу, чтоб это автоматизировать.

Эй, не лишай ПМов хлеба ))

не лешит))) чтоб такой скрипт отрабатывал успешно, нужно его писать, используя AI , а это уже совсем иная история)) Ну и если таки удастся — буду рада быть в составе бетта-тестеров, почему бы и нет)) пишите ;)

Владимир, зачем же так категорично)) День, конечно, распланирован и костяк распорядка составляют стендапы и спланированные встречи с клиентами, бОльшая часть команд в один период времени уже «поставлена на рельсы», поэтому не требует от меня существенных времязатрат. Мои команды — это моя сила, при оговаривании процессов на старте проекта, со временем это приводит к саморганизации и некой автономности команды, когда РМу не нужно решать абсолютно все вопросы, ибо он уверен, что команда знает и понимает как это сделать в ряде случаев самостоятельно. Вот такие дела :)

У нас РМ с тимлидами ежедневно проводит дейли стендапы, как и тимлиды со своими командами. При том что все мы (РМ, тимлиды, инженеры) работаем на всего 1 проекте.
У вас 13-15 дейли митингов ежедневно и 13-15 разных планирований/ретро в начале/конце каждого спринта?

У нас понятие менеджер очень расплывчатое. В это можно вложить разные определения в одной компании это может быть — руководитель и лицо принимающее решение (право финансовой подписи). Может быть — административный руководитель — который работает вместе с: техническим, кадровым, финансовым и т.п. и в такой сируктуре решения принимаются коллегиально. Ну и есть «менеджеры по продажам» — это когда обычного продавца так называют чтобы не обидно было.

Выше уже отписывала особенности. Ресь не идет о 13-15 актвиных проектов в один период времени.

Это было бы физически невозможно, за исключением случаев супервайзинга или сейлс. Я с 2006-го года поучаствовал разве что в 20-ти проектах в общей сложности. Конечно если проекты уж совсем маленькие вроде наверстовать пару тройку страниц для заказчика — возможно и 13-15 проектов можно за раз вести и на каждом таком проекте всего 1-2 UI/UX. Такую организацию труда уже сложно назвать проектной. При таком подходе в кофешопах — каждая чашка кофе для покупателя — это проект.

Дякую за інструкцію, особливо сподобалось про «дізнатись про дати» та «зафіксувати legacy-помилки»

Підписатись на коментарі