ThinkStage Conference — 30+ speakers about BA, Product, UX. Regular price ends May, 24.
×Закрыть

Задачка для Junior PM

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

Для этого они разделили задачи по софту на три части:
Legacy Bugfix
Software Upgrade
Feature Request

Legacy Bugfix — приносит небольшие, но гарантированные деньги. Остальные два — строго на оборот.

Ну а теперь собственно сама задачка:

Senior Business Analyst крайне не любит Feature Request, мотивируя тем, что надо отрефакторить Software Upgrade, потому что иначе все развалится.

Chief Technical Officer наоборот, хочет работать с Feature Request, потому что для него Software Upgrade- это уже Legacy полугодичной давности, а Legacy Bugfix — вообще кромешный пындец, который непойми как поддерживать.

А еще есть Developers, которым:
1) некогда делать Legacy Bugfix, потому что надо рефакторить Software Upgrade — иначе все развалится
2) не хватает времени закончить Software Upgrade, потому что Feature Request намного интереснее
3) хотелось бы закончить с Feature Request, но вылез критикал на Legacy Bugfix или блокер на Software Upgrade

И вот ты — Junior PM был призван для того, чтоб тут все разрулить. Окончательное решение будет за тобой. Твои действия?

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Можно я попробую в джуниор ПМ-а?
Feature Request — в долгий ящик, пока не закончили Software Upgrade. Ну разве что за исключением каких-то капец-каких критичных вещей, с ними решать в «индивидуальном порядке».
Команду делим на 2 части. Одна занимается исключительно Legacy Bugfix, если там срочной работы нету может помогать второй части которая занимается Software Upgrade. Software Upgrade для нас будет первостепенной задачей. Людей между багфиксом и апгрейдом переодически ротируем что бы не засиживались. Можно на багфикс отправлять на недельное, 2 недельное, месячное дежурство.

Все это обсудить с командой и заказчиком. Chief Technical Officer таки какой-то странный, если не будет работать по плану может его куда-нибудь сротировать?

Feature Request — в долгий ящик, пока не закончили Software Upgrade.

Ты не нанят. Такой подход разорит владельца.
Обычно проект делят на 2-3 части (ветки, каталоги и т.п.). В одной фиксят баги и самые важные фиксы переносят в другие ветки. Тоже и с фичами. Причем всё максимально покрывают автоматическими тестами.

Такой подход разорит владельца

Сам придумал?
Какие там 2 ветки, если речь о разных технологиях. Синхронизировать старую и новую версии это вейст, хоть в двух ветках, хоть на двух технологиях. То же самое и с покрытием «всего» автотестами.

Где ты там увидел разные технологии. Я увидел у ТС только рефакторинг, в том числе и архитектуры.

Легаси — это Кобол. Новый софт — это Ява. Джава? Kak eto budet pravilno napisat?

dou.ua/...​ign=reply-comment#1571899

две расходящиеся ветки да в долгосрочной перспективе, да с изменением архитектуры поддерживать то ещё занятие, даже на одном языке программирования/технологиях. По сути это означает каждую фичу имплементировать дважды. Покрыть автотестами старый монолитный код — а вот не факт что это возможно и не факт что ты будешь использовать одинаковые подходы к тестированию в двух разных по сути проектах. Короче пока есть 2 ветки имплементировать и тестировать все придется 2 раза. И делать это надо только в критических случаях. Клиет скорее раззорится при таком подходе.

Если очень очень нужны фичи на существующей системе — тогда никакого апдейта, только фичи в старом коде и только багофикс, пока не дойдете до состояния, в котором работу на старой системе можно заморозить и вернуться к плану 1. Ну и да, по ходу можно отдельно подумать про тестирование, да как то так что бы тесты можно было переиспользовать на новой системе.... Но это скорее утопия и это скорее про функиональные тесты.

Клиет скорее раззорится при таком подходе.

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

Ну и первый шаг по легаси — это разрезание его на маленькие модули и только потом переписывание и модификации

Вот тут согласен.

Но часто это делают параллельно, разрезают легаси, пишут тесты и делают новое решение.

Прибирання Software Upgrade розкиданням по іншим двом частинам, дозволить використовуючи аксіому Ескобара звести задачу до класичної про два стільця.

Legacy Bugfix — приносит небольшие, но гарантированные деньги.

Т.е., стейкхолдеры — это другая галера, которая за небольшую денежку поддерживает существующее решение? А его замена на more maintainable — за счёт галеры (стейкхлдера)? Я правильно понимаю?

Senior Business Analyst крайне не любит Feature Request, мотивируя тем, что надо отрефакторить Software Upgrade, потому что иначе все развалится.

А откуда у BA такое глубокое понимание архитектуры? Это мнение скорее характерно для Architect, а не для BA.

Chief Technical Officer наоборот, хочет работать с Feature Request, потому что для него Software Upgrade- это уже Legacy полугодичной давности, а Legacy Bugfix — вообще кромешный пындец, который непойми как поддерживать.

Исходя из

Легаси — это Кобол. Новый софт — это Ява

, команда, которая занимается багфиксом и команда, которая пилит другое решение — 2 разных команды, поскольку ЯП абсолютно разные. Я вообще не вижу тут проблемы: эти 2 команды пересекаются только на knowledge sharing sessions.
Что в себя включает

Software Upgrade

и что —

Feature Request

?
FR — это новые хотелки? Которых нету в исходной версии? Если да — то тут всё просто: есть 2 зависимости:
1. Бизнес приоритеты (эта новая фича нам важнее, чем оторвать вот этот кусок от монолита и перевести на микросервисы).
2. Ограничения архитектуры (эта новая фича не может быть запилена / не будет работать в соответствии с требованиями по нагрузке, пока не оторвём вот этот кусок от монолита).

Учитывая 1 и 2, балансируем SU & FR в бэклоге. Команда 1 при этом занимается багфиксом существующего кобол-решения.

С учётом специфики задач, я бы рекомендовал канбан + CI, лучше — CD, чтобы новые фичи попадали на прод ASAP, без ожидания конца спринта.

треба як мінімум поговорити з замовником і посортувати задачі відповідно до потреб замовника (тут в ВА починається довгий діалог з стейкхолдерами), а також визначити чи не можна
1. Розбити ще на менші підзадачі і їх дати їм пріоритети також
2. Чи потрібно все робити по черзі чи можна паралельно
3. Визначити як це бачить стейкхолдер взагалі, можливо його варіант та свіже бачення буде найкразою ідеєю
Далі варитись у цьому всьому, беручи до уваги що потрібно буде йти зі всіма на компроміси — і з ВА і з СТО і з девелоперами і з стейкхолдерами по черзі

Якщо все що було сказано вже сталось (і нічого не змінилось) тоді прийдеться робити Soft Upgrade з паралельним легасі, а коли буде зроблено 50-60% апгрейду починати робити фічі, так само продовжуючи попередні дві задачі та розприділяти ресурси по ситуації (в залежності чи треба щось термінове, чи нічого часом не впало чи ніякий баг не вискочив)

Перефразирую задачу для ясности.
Есть автомобиль с рулем, педалями, ручками и кнопками. Вас сажают на место водителя. Что вы нажмете или повернете, чтобы машина доехала в пункт назначения? Дайте окончательное решение.

Я нажму на смартфоне «Вызов водителя» и когда тот подойдет — сообщу ему пункт назначения. Так что аналогия не верная.

Собеседование на позицию водителя — вам дают цели и рычаги, поэтому вариант «вызвать такси» не сгодится.

Это аналогично

Я нажму на смартфоне «Вызов PM» ...

Мда как то абстрактно.

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

Легаси — это Кобол. Новый софт — это Ява. Джава? Kak eto budet pravilno napisat?

Senior Business Analyst
Chief Technical Officer

Якісь ну дуже вже дивні пацани

нащо вони там взагалі потрібні, якщо ключові питання вирішує аж цілий Junior PM

Хехехе!!!! Это задание раздает Zeo Alliance в качестве тестового)))) Краудхайринг?

Это тот случай, когда у дураков мысли сошлись. Про Zero Alliance никогда раньше не слышал.

Это типичный случай конфликта интересов. Интеллектуальные качества сторон — ни при чем.

Я про совпадения заданий писал.

просто у вас гугл одинаково выдает ))) это не Ваш косяк

Ахаха, це типовий сценарій у довгограючому ентерпрайзі.
Мітинги з представниками усіх 3х гілок влади, пріоритети для задач, резервування у спринті певного відсотка часу на багфікси та на апгрейди. Якщо виявиться, що після резерву перманентно не вистачає часу на фічи -> вимога збільшення кількості дев ресурсів.

Тобто є один девелопер, який робить всю роботу, а над ним стоїть манагер, СТО і ВА і кожен з цих трьох тормошить девелопера аби той робий те, що цікаво кожному з цих трьох?

НАйняти ще одного сініор девелопера і розподілити таски між ними, починаючи з критичного багфіксу і закінчуючи новими фічами, спочатку стабілізація, потім надбудова. Якщо грошей на нового девелопера нема, забрати їх від манагера, СТО і ВА.

Developers

 — их много и они на разрыв.

В такому випадку треба ініціювати зустріч між манагером, СТО і ВА і спробувати максимально об’єктивно вирішити пріорітети задач з точки зору бізнесу, хоча б на найближчий спрінт. Після чого поставити девелоперів перед фактом, що є зараз важливим, а що ні і гребсти в цьому напряму.

гнати, доки цілі. Програмування тут жодним боком не присутнє

Чтобы рубиться с СТО и Senior BA — должны быть яйца соответствующего размера, а голос иметь определенный вес в компании. Не уверен, что Junior PM соответствует этим критериям.

— продукт, аутсорс?
— софт приносит бабло или..?
— кто принимает окончательное решение?
— какую проблему пытаются решить?

Проблема с приоретизацией задач? Юзайте WSJF
ashigabutdinov.ru/...​sob-prioritezacii-zadach

Дели на 3-2 проекта и иногда мержи необходимое при острой на то необходимости.
Понятно покрывай все фичи тестами, чтобы ветка с новым решением удовлетворяла старым фичам.

Я звісно не ПМ, але як ви хочете впроваджувати фічі якщо в старому коді куча багів ?
Цей пункт одразу в кінець.
Далі пріоритетизуємо фікси і апгрейди і виконуємо їх.
Після фіксів впроваджуємо новий функціонал

це позиція СТО. Аргумент «проти» (тобто позиція ВА) — «фічі» можуть не продатися. А «легасі» — вже продається, і годує весь той натовп. Задача насправді дуже типова, навіть в напів-художніх книжках описана :)
І варіанти рішень — теж 8-)

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