Почему ветка называется Administrator, хотя по сути это Project Manager?

очень долго холиварили про это

мне не нравится название “проджект менеджер” для того, кто просто управляет потоком задач

оно фреймит только на одну из областей ответственности

тогда может быть process manager?

тоже был такой вариант

бизнесовый фокус (PO, Integrator) и технический (Techlead) конфликтуют. более быстрые поставки или более качественный код?

у нас роль тимлида начинает распадаться на отдельные. в командах, работающих по канбан, тимлид исторически состоит примерно из SRM + SDM + чаптерлида + разработчика/техлида. сейчас SRM (менеджер запросов) и SDM (менеджер поставки) - уже почти всегда выделенная роль.

чаптерлид - про наём и развитие, имхо это неотделяемая часть тимлида. специалист/техлид - тоже, чтобы не терять квалификацию, иначе как ты будешь развивать ребят

кстати, центральная "роль" у нас в компании называется Project Lead, а не Team Lead, ведь по сути у тебя всегда точно есть проект/продукт, но не всегда может быть команда вовлечена в эти активности (у нас под веткой Team Lead воспринимаются Tech Lead + Resource Manager). В принципе, если пробежаться по веткам то можно заметить, что не во всех ветках идет взаимодействие с командой (например, почему Product Owner это часть Teamlead, хотя в компетенциях этой ветки ничего про команду (как минимум, кор-команду) нет

не всегда так. В матричной структуре у тебя может быть команда без проекта, которая сидит на бенче ¯\_(ツ)_/¯

они же должны быть где-то задействованы, пусть это будут внутренние проекты или прототипы, а значит, есть какие-то артефакты на выходе, а значит, есть какая-то работа 🙂 просто так они там не могут сидеть

ну я вот скорее так смотрю:
1. Resource Manager – вокруг команды
2. Administrator – вокруг процесса
3. Techlead – вокруг технологии
4. Product – вокруг продукта
5. Integrator – вокруг бизнеса

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

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

мы когда формировали роадмап, изолировали лида в рамках только одной роли, а потом думали чем он должен заниматься

А будет ли подобный текст что не должен делать тимлид?

Насколько ли тимлиды отличаются от тех же хэдов? Если говорить абстрактно?

Мы в каждой отдельной ветке описываем примеры хорошего и плохого поведения (вернее планируем описать :))

Да ничем концептуально, кроме уровня абстракции, эта карта подходит и для хэдов в целом.

ну то есть и для линейных руководителей и для managers of managers

А как можно помочь данной инициативе?