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

Вопрос к Project Managers по распределению ролей в команде

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Вопрос адресуется Project менеджерам\Scrum мастерам на проекте где ваша команда живет между уровнями в стеке, существует ли у вас разделение на мейнтейнеров и feature девелоперов?
Смоделируем ситуацию:
-> есть компания «A» которая предоставляет софтверный продукт
-> компания «А» является косьюмером b2b платформы/фреймворка которую делает компания «В»
-> активная разработка продукта идет и в компании А и в компании В(иногда возникают регресии и прочие недопонимания)
-> конечный продукт имеет прямыет вызовы фич вреймворка
-> при возникновении багов консьюмер репортит их компании A

Как PM/Scrum команды в компании А вы получаете тикеты и начинаете триажинг:
— ваши тикеты
— тикеты фреймворка
— спорное\неясно

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

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
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

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

Я не project manager, но из того что читал на ДОУ как описание реальных процессов и подходов в командах\компаниях которые хотели что-то улучшить или достичь (ну и сделали это более-менее) — везде это выглядело как переход к более широкой универсальности и уход от узкой специализации. И я тоже считаю что в общем итоге это дает больше пользы и результата.
Если говорить словами ответов что давали ниже: то по простому — дежурства для всех, т.е. ротации.
Мне сложно наверное это аргументировать без подготовки структурированного ответа, поэтому это просто мое мнение.

депендс он циркум стенсиес.

косьюмером

глаза, мои глаза!!!

Спасибо за коментарии. Озвучу свои догадки по этому поводу, сможет ли кто подтвердить\опровергнуть.
И так, бытует мнение что у инженера програмиста в основном 2 пути развития — технический, в условно, архитекторы, и «гуманитарный», в менеджеры проекта\продукта,сейлза, etc...
Как мне кажется предрасположенность к одному или другому типу как то проявляется в разделении мейнтейнеры vs девелоперы. Тоесть человеку которому явно больше нравиться возиться с бумажками\тикетами путь в менеджеры, а товарищам которые упариваются по оптимизации\рефакторингу\архитектурам другая дорога.
Следовательно на собеседовании\перфоманс ревью, спросив в каком направлении тебя повышать(одно из двух), програмист выбирает ту или иную стезю, вы как менеджер можете предположить что, скажем, процес багофикса подразумевает больше работы с трекингом\комуникацией потому этого товарища отдать на багофикс.
Понятно что есть корнер кейсы, но в целом, верна ли эта гипотеза ?

И так, бытует мнение что у инженера програмиста в основном 2 пути развития — технический, в условно, архитекторы, и «гуманитарный», в менеджеры проекта\продукта,сейлза, etc...

да

Как мне кажется предрасположенность к одному или другому типу как то проявляется в разделении мейнтейнеры vs девелоперы. Тоесть человеку которому явно больше нравиться возиться с бумажками\тикетами путь в менеджеры, а товарищам которые упариваются по оптимизации\рефакторингу\архитектурам другая дорога.

нет, ему выгоднее сменить работу на тимлида или БА в соседней конторе. Саппорт — тупик развития.

Саппорт — тупик развития.

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

открывай ротик, летит вертолетик...

именна!!1

Что на самом деле надо сделать: задонатить создателей фреймворка. Мало того что ваши баги будут в приоритете, так ещё и ваши фичи будут в приоритете. А уж ежели вы сотрудника отдадите хотя б на 6 часов в неделю пилить фреймворк в команде создателей... разумеется не самого опытного.

Хорошее слово «триажинг». Особенно если знать что оно значит. Triage — это ОТСЕВ несрочных дел из очереди. В изначальном смысле [военном] оно означает посылнах тех раненых, которые не нуждаются в срочной помощи.

Саппортеры будут увольняться, либо туда надо садить самых пассивных и ленивых, чтобы больше отписывали, чем делали.
Вообще, говорят, в такой ситуации назначают дежурства — каждую неделю кто-то один (по очереди) разгребает письма или задачи от заказчика, смотрит, что там конкретно происходит, и назначает на владельца модуля, который глючит.
Также, играются в двухуровневый канбан: есть основная канбанная задача, которую дев пилит. Если на него появляется срочный баг — заспускается высокоприоритетная очередь багов, которые вытесняют низкоприоритетную фичу. Как только баги в очереди закончились — восстанавливается выполнение низкоприоритетной очереди фич.
en.wikipedia.org/...​ty_pre-emptive_scheduling

У нас оно когда-то было на базе недельных ротаций на дежурство по супорту. Сейчас все и баги фиксят-инвестигейтят-триажат и фичи пилят одновременно — как то успевают.

Как этому относятся сами инженеры?

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

А взагалі розділення команди на безпосередньо розробку та саппорт залежить ще від розміру компанії\команди — якщо команда невелика, то особливого сенсу ділити команду на розробку та саппорт нема, бо по суті ви розмножите процеси на невелику кількість людей. При рості команди вже є сенс розділити на саппорт та безпосередньо розробку і подумати над процесами для кожної з команд.

вот эти ребята фиксят баги и разруливают вопросы между стейкхолдерами, а вот те (интроверты) клепают заумную бизнес логику и у нас на проекте идилия, всех все устраивает?
разруливают вопросы между стейкхолдерами

А чому деви повинні розрулювати питання стейкхолдерів? Чи написано неправильно?

ну, наверное тут имелось ввиду помогать в этом проджекту, в тех нюансах, где проджект не шарит

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