Делевери менеджеры отвечают за поставку ценностей конкретному заказчику.

Ну и вся процессная часть на них :)

Я не знаю, как ответить на Ваш вопрос. Исторически - больше административная. Давайте так, как лично Вы считаете, в команде 6-8 человек, на проекте длительностью 3 мес нужен тимлид? Что он должен делать?

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

В любой команде всегда есть лидер. Либо самозарождается либо назначен. Самозарождение идёт через конфликт. Назначение позволит управлять кто станет лидером.
Будет лидером команды тимлид или ПМ зависит от того сколько проектов на одного ПМ. Если больше одного, то лучше выделять тимлида. Если у ПМ один проект, то ему и быть лидом.

Слушайте, а как это работает?
Вот звучит будто минимум у трех людей функции перекрываются:
"Продакт тащит развитие продукта"
"Проджект ведет проект"
"Деливери отвечает за поставку ценности конкретному заказчику"
Я правильно понял что они все "менеджеры" (продакт-менеджер, проджект-менеджер и деливери-менеджер)?
Т.е. вот на одном ?проекте? сходятся три роли которые отвечают на первый взгляд каждый за свое но, но реально звучит это как неразрывно связанное одно и то же.
Менеджер проекта (по определению) должен вовлекать заказчика, управлять его ожиданиями, поставлять "что договорились" вовремя силами команды.
Деливери (по описанию) делает вот прям то же самое (нет?)
Продукт (если он менеджер, а не просто "владелец продукта") тоже должен сильно руль поворачивать, менять приоритеты и в ходе с обоими прям сильно пересекаться.
Вот что станет если они разойдутся во мнениях? ПМ скажет "заказчику нужно то-то в первую очередь", деливери "это я отвечаю за поставку ценности, мне лучше знать", а продукт такой "на мне развитие продукта, слушайте меня".
Или кто например будет отвечать если проект не уложится в установленные рамки (превысит сроки и бюджет)? ПМ? Или деливери с продактом которые настояли на своем видении "ценности" и "продукта в целом"?
Если конкретнее, все таки  - кто за что отвечает?

Вопрос не про то, кто станет лидером. Вопрос про выделенные роли.  Если говорить про Ваш вопрос, то на ПМа один проект, который длится 3 мес по срокам.

@Selikhovkin Иван, что Вы думаете про мой кейс? в команде 6-8 человек, на проекте длительностью 3 мес нужен тимлид? Что он должен делать? У проекта есть ПМ, у него только этот проект. Меня интересует именно ролевка в данной ситуации. Еще уточнения: исходно структура матричная, проект может на следующий этап не перейти, и тогда команда раскидывается обратно к своим ресурсным менеджерам.

Сугубо субъективно.
Как я (всю жизнь) отнозился к роли тим-лида: для меня это самый толковый представитель "профессии" в команде, который к тому же может минимально организовать других.
Ну условно у нас на проекте 7 разработчиков - 4 на одном языке / стеке, 2 на другом и один какой-нибудь "базушник" (занимается базами данных). А кроме них еще три аналитика. А кроме них еще...
И вот поскольку ПМ не эксперт во всех нужных областях ему реально нужна помощь в экспертных оценках, в понимании того кто в команде объективно какую задачу потянет лучше.
Так вот для этого годятся два человека: либо кто-то из команды (тогда он и будет тим-лид) либо условный "начальник отдела" (вовлечем его как стороннего эксперта).
В моем кейсе у меня могли бы появится, например, тимлид для 4 программистов на одном стэке (один из них) и тим-лид аналитиков (тоже один из них), а остальные обойдутся без тим-лида, более детально будем общаться с каждым или подтянем начальника отдела из которго они пришли в помощь по "тим-лидовским вопросам". У нас же матричная структура, так что таковые начальники должны существовать :)

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

Кто архитектор?

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

Я ждала этого вопроса, спасибо, Алексей. Есть общий архитектор, пошаренный на все проектные команды, он по сути, ревьюит и отвечает на вопросы, если они у команды появляются. За архитектуру своего проекта отвечает.... кто?? :))) Условно назовем самый опытный и умный девелопер внутри команды :)

Вот он и тимлид. Это единственное Нафига он нужен: принятие решений внутри команды если есть спор.

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

обычно архитектуру проекта продумывает не разработчик с проекта, а это делается совместно с техлидом компании (как минимум)
когда архитектура отдается на откуп одному разработчику (пусть и опытному), это часто приводит к казусам в последствии...

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

>>Слушайте, а как это работает?
>>Вот звучит будто минимум у трех людей функции перекрываются:
>>"Продакт тащит развитие продукта"
>>"Проджект ведет проект"
>>"Деливери отвечает за поставку ценности конкретному заказчику"
>>Я правильно понял что они все "менеджеры" (продакт-менеджер, проджект-менеджер и деливери-менеджер)?

Да все верно, все три менеджеры.

>>Т.е. вот на одном ?проекте? сходятся три роли которые отвечают на первый взгляд каждый за свое но, но реально звучит это как неразрывно связанное одно и то же.
>>Менеджер проекта (по определению) должен вовлекать заказчика, управлять его ожиданиями, поставлять "что договорились" вовремя силами команды.
>>Деливери (по описанию) делает вот прям то же самое (нет?)
>>Продукт (если он менеджер, а не просто "владелец продукта") тоже должен сильно руль поворачивать, менять приоритеты и в ходе с обоими прям сильно пересекаться.
>>Вот что станет если они разойдутся во мнениях? ПМ скажет "заказчику нужно то-то в первую очередь", деливери "это я отвечаю за поставку ценности, мне лучше знать", а продукт такой "на мне развитие продукта, слушайте меня".
>>Или кто например будет отвечать если проект не уложится в установленные рамки (превысит сроки и бюджет)? ПМ? Или деливери с продактом которые настояли на своем видении "ценности" и "продукта в целом"?
>>Если конкретнее, все таки  - кто за что отвечает?

Продакт - он про развитие всего продукта. Не только, что сейчас, а что и в будещем. То есть он отвечает, что бы продукт был строен и соответсвовал своему предназначению. Он на вершине пирамиды. Он очень плотно работает с заказчиком и доносит до него вижен продукта и вижен того каким будет продукт в бущем. Общается он с топами. Продакт может отказать проджекту во включении, чего либо в продукт, если это что то противоречит концепции. Если очень нужно то в кастом. Так же проджект может включить работы на переспективу, ни одному заказчику не надо, но через год потребуется, а мы уже готовы. И проджекты счастило от этого :) Мыслит на стретегическом уровне.

Проджекты работают с представителями бизнеса заказчика, работает с его ожиданиями, и рамками, и определят, что и когда будет поставлено, а как будет поставлено - не его проблема. Заказчик хочет в облако, деливери разберись и доложи. Нужно релизить раз 5 минут, деливери у тебя вызов... :)

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

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

Они конечно пересекаются, но по факту оочень в узких областях.
Вот как то так...

Спасибо за подробный ответ!
Из описания сложилось впечатление что "деливери" - он этакий devops. Более-менее понятно как в таком случае он с остальными расходится.

Про продакта / проджекта непонятно абсолютно. Ну то есть если продакт может продукту отказать, а может и не "приказать" (мол это надо, делаем это в первую очередь), то с какими такими ожиданиями заказчика и рамками работает проджект?
Просто вот очень похожую ситуацию видел много раз в жизни. И звучит она очень похоже как нечто вроде "мышки станьте ежиками + не знаю как, я не тактик, я стратег". В компаниях где такое видел продукт с удовольствием занимался видением на высоком уровне продукта, но не любил "огребать" за провал сроков или недовольство заказчика. И как бы за успех продукта отвечал продукат. Но за обратную связь (особенно негативную) а также ответственность за "почему не успели в срок" полностью нес проджект. И так и закреплялось во временем (продакт он не про отвевтстенность, он про "видение на высоком уровне), а проджект он про "пойти и поуправлять ожиданиями в том объеме в каком у него возможности остались" (увы, последнее не про управление проектами совсем).

Впрочем, возможно у меня ложное впечателние сложилось из вашего рассказа. Повторюсь, очень много видел как компании "загонялись" именно не сумев разделить продукта и проджекта (и по болльшому счету направсно их в одном проекте совместив). :)

Еще раз спасибо за подробный ответ и готовность разъяснять! :)

Первые посиделки в 2020 году

Тема: Три простых решения задачи Голдратта
Когда: 2 января, в 16:00.
Где: https://nexign.zoom.us/j/320876728
Календарь: https://calendar.google.com/event?action=TEMPLATE&tmeid=OXAxNG1nc3Zrcms4NWhqc2FtaGp1MnA0NWMgMzRwZW1jdjk0MTQwZ2t0c2EzdnZhbzJuam9AZw&tmsrc=34pemcv94140gktsa3vvao2njo%40group.calendar.google.com

Описание:
Попробуйте сами решить задачу: https://tocpeople.com/2014/02/sindrom-stoga-sena-12/

Скажите, где можно зарегистрироваться на встречу?