Еще раз проще: менеджер да, должен уметь общаться, это его ключевой навык. Он должен нести ответственность — это ключевое зачем он есть вообще. НО
Ответственность не за все. О чем вы вообще? Он несет ответственность за вверенный ему проект или продукт, если он лезет со своей ответственностью куда-то еще — его оттуда выпроводят, потому что занимайся своим делом. Да, он должен при этом взаимодействовать с другими, но взаимодействовать, не нести ответственность за их продукт, проект или функцию.
Дальше — прекращайте смотреть на все в формате черное-белое, мир несколько сложнее. Общаться уметь это не значит что в 100% случаев переговоры проходят успешно. Это утопия.
Что значит если не умеете договориться то идите ищите? Вы сами бизнес-переговоры вели? С командой в кризисной ситуации общались? У меня возникает ощущение что нет — вы слишком идеализируете. На подобии — ты либо попадаешь белке в глаз, либо вообще стрелять не умеешь.
У любого крутого коммуникатора бывают фейлы. Потому что он не может просчитать любого человека и с ходу воздействовать на его него так, чтобы тот его понял. Есть люди с которыми договориться в целом невозможно — потому что упертые и никого не слушают. Это раз.
Два — когда с тобой принципиально не хотят иметь дело по независящим от тебя причинам — навыки в общении не помогут. Потому что когда у тебя нет машины, навыки вождения не помогают.
Не, разные варианты бывают в жизни, мне, например, как-то ПМ платил из своего кармана за свехурочные, поскольку ему таких полномочий платить за счёт бюджета проекта не дали.
На кризисных проектах и у меня возникает иногда такое желание, правда как правило разруливается все без таких методов. Но когда хочешь чтобы разработчики чувствовали себя нормально и получали за свой труд — это естественно.
однако тянуть в мир менеджмента программистские установки «уволюсь, а после меня хоть потоп» — как минимум не профессионально.
вы это в моей публикации увидели?
Если так — то во-первых я никогда не был программистом. Во-вторых вы видимо что-то не так поняли. Мой посыл был не про потоп, а про то что в описанных условиях, я считаю работать — разрушать себя, и впустую тратить время. И после ухода никакого потопа не произойдет явно — потому что в описанных условиях от этого менеджера особо ничего не зависит, ему как следует ничего не делегировали, и со стороны работодателя было ошибкой его нанимать, так как он явно не хочет ему ничего делегировать, соответственно этой позиции быть не должно.
Плюс — конкретно в примере из собственной практики — я сделал все от меня зависящее чтобы ситуацию решить, и с командой и с начальством. Не помогло.
И я не склонен идеализировать места — это как раз программистский подход правильно-неправильно, есть подходящие места, и подходящее начальство. Это завязано плотно и на личностях и на корпоративной культуре. Думаю не будете отрицать что все таки выбирать надо, и работать надо там где комфортно. А не терпеть стиснув зубы — чтоб потопы не оставлять.
Есть компании с собственниками и менеджерами которые подойдут одному человеку, претендующему на позицию управленца низшего звена, но для другого будут казаться неадекватами, и это тоже нормально.
Безусловно. Был и такой опыт, но мое личное наблюдение — что неадекватность эта часто граничит с непрофессионализмом этих самых собственников. При этом по моему мнению любому руководителю низшего звена — профессионалу, с таким начальством работать не захочется, потому что он видит все его недочеты, пробелы, и не впечатляется его «харизмой». Но бывают и такие профессионалы-хариматики, которые и феерят и дело делают — с ними работать вполне себе можно, если абстрагироваться от их приколов.
Я же не отрицаю что такие случаи бывают — иногда нужно вмешиваться, но это исключительные случае. В целом имхо нужно строить иерархию — если есть ПМ, то его нужно подобрать хорошо и дать ему полномочия руководить. И команде объяснить что вот ваш новый ПМ, любить, жаловать и делать таски.
Да, я согласен. Больше скажу — огромная часть провалов в бизнесе в целом — это плохое руководство. Но я не об этом сейчас.
Во-первых команде не следует быть наивной и полагать что все будет красиво и идеально, никаких переработок — все рады бы так, но это так не работает, всегда есть фактор неопределенности, есть неожиданные вещи. Вопрос лишь — заморачивается менеджер тем чтобы с этим бороться и защищать своих разработчиков от переработок и прочих негативных явлений, или ему плевать на людей — он думает о премии. Видел много таких.
Но статья не об этом — статья о том, что попробуйте стать на позицию этого менеджера который между двух огней находится, и попытаться разрулить такую ситуацию.
Продукт-оунер это не представитель клиента, конечного бенефициара, это часть команды скрама.
тут все замечательные практики скрама отправляются в помойку, поскольку субподрядчик может даже не знать, на кого он в конечном итоге работает.
Почему же — субподрядчик может юзать скрам у себя внутри. Продукт-оунер у него свой, который получает все задачи, обсуждает их вносит в бэклог команды.
Как-то все просто у вас получается — умеет не умеет, делает не делает. Черно-белая картина. Общаться и договариваться это софт-скилл, он не работает безотказно как АК. Есть люди которые просто не слушают, и договориться с ними нельзя от слова совсем. Таких всегда есть определенный процент, и с ними проще просто не связываться чем тратить время.
И такие люди есть как среди начальства и подчиненных, плюс зависит очень сильно от среды — где как на каких ролях это все происходит. Именно про это я написал.
Команда лично ему ничего не должна — она должна компании на которую работает, выполнять обязательства по трудовому договору, в котором обычно написано что поставленные таски нужно делать, менеджеру подчиняться.
Если менеджер не выстреливает в продукте (хотя я говорил про проекты, не про продукты, это разное) — то ему там в целом нечего делать, про ответственность точно также.
Примерно так я и сделал когда попал в такую ситуацию. И формулировки очень похожи — начальство такого поворота не ожидало, в той организации прямо говорили очень немногие. Не помогло — ушел, и рад. Ибо нашел и адекватное начальство, и нормальные команды, и перспективы и всё.
Все так.
Только вот как раз моя статья о том — что будь ты хоть лучшим оратором и психологом — у объяснения две стороны, кто объясняет, и кто слушает (или не слушает). И бывают ситуации когда слушающим просто неинтересно это все. Они не сомневаются в своей правоте и не хотят никаких аргументов слышать. У человека два состояния когда его пытаются чему то научить (что-то объяснить) — либо он слушает и впитывает, либо он уходит в оборону и ничего не воспринимает. Я выше уже писал — когда люди адекватные, с ними можно работать даже если есть различия во мнениях, им можно объяснить, с ними можно наладить рабочий контакт. Когда настроены консервативно и закрыто — это почти невозможно, нельзя заткнувшему уши что-то объяснить, это его выбор тебя не слушать.
Вот как раз тут я не вижу смысла биться головой и пытаться пробить стенку.
Все вышесказанное относится ко всем в целом — я видел случае когда наоборот, команда что-то пытается донести менеджеру, а он ни в какую не слушает, и делает по своему и получается дичь. Послы статьи в том что команда находится в менее уязвимом положении — у нее только начальники, один плохой — идешь к следующему, эскалируешь. А у менеджера с двух сторон могут прилететь проблемы, и виноват будет он.
Частично соглашусь. Да, есть которых надо смело увольнять, и очевидно что нужно думать о деле — я этого не отрицал, мы обсуждаем другой сегмент работы менеджера, никто не говорит посвящать этому 100% времени и ресурсов. Без результата понятно это все имеет мало значения.
Прикрывать нужно всех имхо — а потом самому разбираться, подчиненных должен наказывать прямой руководитель, не тот кто выше. Иначе остальные будут думать что вот сейчас пока мы все делаем — он добрый и защищает, а как только косяк — отдаст на съедение высокому начальству.
И мудрый руководитель менеджера это знает — он не начинает разносить сам, а поручает это прямому начальнику провинившегося.
Спорю. Есть просто неприятие чужих — чужих, т.е. только пришедших в команду где люди вместе работают уже какое то время, чужих — представителей других профессий, с другим бэкграундом, просто выглядящих по другому.
Менеджер может быть токсичным — но такие в этой профессии долго не задерживаются, тут коммуникации ключ.
Да кстати
Но все люди делятся на два типа.
Те, кто что-то делает.
Те, кто ищут причины почему не получилось.
Это было серьезно сказано? Давайте не будем мемами из вк разговаривать.
Во-первых люди не делятся на 2 категории. Прежде чем что-то делать — надо для начала подумать. Потом делать. Думать почему не получилось (или получилось) тоже надо всегда — человек среди прочего, отличается от животных способностью прикидывать возможные последствия, а также учитывать собственный опыт.
У меня ощущение что вы просто увидели себя описанной команде, и пытаетесь всеми правдами защитить её, и найти повод все свалить на условного ПМ-а. Поправьте если я ошибаюсь.
Я тоже видел, но это если команда адекватная — да вариант, на личных качествах вывозить.
Но когда команда токсична и в целом враждебна, а начальству все равно — я считаю что пустой номер пытаться головой пробить стенку. Ради чего?
Представьте себе, что Вы участвуете в проекте, работу над которым ведут одновременно 100 человек, распределённых по разным командам, а команды находятся в разных городах и на разных континентах. Насколько тогда хватит одного менеджера-коммуникатора?
Кто сказал что он будет один? Это в целом другая тема, как управлять в таком масштабе, как дробить команды, есть свои методологии, сейчас не совсем про это, так что опущу.
Тут я с Вами не согласен. Наоборот, считаю, что если программист работает над реализацией определённой фичи, то ему нужно коммуницировать с продюсером, который эту фичу придумал и описал. Не все аспекты фичи можно заранее прописать в документе. Иногда возникают вопросы. И если вопрос возник — самое время обратиться к автору фичи. Если это сделать через менеджера, то он, скорее всего, пропустит мимо ушей определённые тонкости, т.к. не он реализует фичу и не он является её продюсером.
Вы описываете один конкретный случай из множества возможных. Кто сказал что автор фичи и заказчик одно лицо? Выше уже было обсуждение — я говорил именно о проектах, то есть о то что имеет начало и конец, скоуп и так далее, не продукт. Проект зачастую делают для кого-то внутреннего или внешнего заказчика, и в 90% случаев краткосрочная история разработки. Соответственно в этих условиях часто заказчик не является грамотным технарем, продуктовым менеджером и так далее. Он не описывает детально фичу. Это делается на стороне исполнителей на основе условных «хотелок» заказчика. И соответственно с этим надо идти к тому кто руководил процессом — к менеджеру.
Также если смежную фичу реализует другой программист из другой команды, то первый программист должен обязательно с ним общаться, т.к. есть пересекающиеся места в коде, в архитектуре. Технические решения нужно согласовать.
Обещать не значит жениться. Должен и делает это разное. Я согласен что в современной разработке это обязательно, но многие ли из них по факту комфортно себя чувствуют в общении и умеют четко доносить свои мысли? Особенно учитывая что это зачастую их прямая обязанность разработка, коммуникация на третьем плане. Еще раз — я не спорю что должен, я лишь утверждаю что практика (моя и коллег) показывает что часто на этом спотыкаются. Многим просто лень подойти к коллеге из другой команды и пообщаться, или в чат ему написать. У меня буквально на днях такой случай был — программист со стороны заказчика внедряя наш код, не спрашивал непонятное — а делал по своему разумению, чем создал сложности, хотя имел все возможности спросить. Даже языкового барьера не было.
Синхронизация осуществляется довольно просто. Программист обращается к продюсеру с каким-нибудь вопросом по фиче, продюсер даёт ему ответ, а затем — если необходимо — вносит изменения в документацию по фиче и/или в условия задачи.
Это один частный случай. Про продюссера ответил выше. Про документацию — в Agile вообще документация стоит ниже по приоритету, согласно принципам. И документация мертва, а древо жизни зеленеет. Живое общение всегда лучше, можно задать вопрос и сразу получить ответ. Также нужно дублировать минимум на два канала, потому что всегда есть вероятность что в документацию не заглянут в нужный момент. Нужно страховаться.
Следует различать менеджера проекта и продуктового менеджера. Менеджер проекта не вмешивается в вопросы дизайна фичи и в вопросы технической реализации. Его интересует скоуп работ, сроки, ресурсы. А менеджер продукта — да, как раз занимается фичами.
Нет, совсем нет. Продуктовый менеджер занимается стратегией продукта, метриками, он дает фичи в достаточно общем виде, без деталей. В том же Яндексе к примеру ровно наоборот — есть продуктовый, он главный, есть проектный, он занимается операционкой и ежедневной координацией. Ну и я сразу сказал что речь идет про проекты, не про продукты, и про проектных менеджеров. Скоуп работ сроки и ресурсы — из классического PMBok — кто им пользуется в разработке софта? И то это не исключает того что он руководит проектной командой и заботится о коммуникации.
Риски справедливы, но при описанном методе имхо их еще больше.
Наоборот, лучше, когда по конкретной задаче разработчик коммуницирует с представителем заказчика напрямую
Во-первых это не их работа. Во-вторых не все умеют. В-третьих они тогда должны делиться всей информацией с командой, чтобы все были в курсе о принятых решениях, изменениях. В таком случае это будет сплошной поток разных договоренностей. Один договорился об одном, другой о другом, что полностью или частично идет в разрез с первой договоренностью из перечисленных и это порождает еще большую неразбериху чем бутылочное горлышко с испорченным телефоном, кстати в случае коммуникации большего количества людей — он портится еще больше.
Переговоры всегда ведет один человек, это не с потолка взято, когда все под контролем у одного менеджера, спрос тоже с него, и вопросы тоже к нему. Как промежуточное решение — все общаются в одном чате с заказчиком, но контроль, фасилитация и ответственность за это — все равно на менеджере.
В тему — из телеграм-канала Темная сторона
Услуга как продукт
1. Может ли услуга быть продуктом? Может. Если она а) стандартизована по составу, процессу, результату и цене, б) многократно повторяема и в) вы можете научить оказывать ее кого-то другого.
2. Можно ли быть бизнесом, оказывая услуги, но не имея продукта? Нельзя. Этот «бизнес» умрет, как только основатели устанут, уйдут или умрут.
3. А как же, например, большие консалтинговые компании — они же под каждого клиента подстраиваются? А у них просто продукт другой — система набора, тренировки, контроля и продвижения людей, которые способны такие нестандартизованные услуги оказывать. Именно этот продукт создали основатели, и он продолжает жить, даже когда люди в компании сменились.
4. В общем, продукт — это когда что-то стандартно, повторяемо и передаваемо. На этом фоне меня умиляют люди, которые строят «бизнес», выдвигая в качестве своего конкурентного преимущества свой «высокий профессионализм» в продаваемой области. Тем самым они намекают, что обладают уникальным и неповторимым умением.
ну и да, ничто не мешает быть ПМу еще и тех-лидом. Если хватает компетенций.
Это мое профессиональное хобби — исследовать насколько много специалистов которые могут совмещать, и как они к этому пришли. Пока выводы сводятся к тому что таких людей катастрофически мало, и это зачастую талантливейшие профессионалы. И компании которые таких хотят зачастую сталкиваются с трудностями. Ну или берут человека который явно проседает по каким либо из компетенций.
А ПМ, если он сам не вышел из разработки, не сможет спрогнозировать сроки ровным счетом НИКАК. То-есть, для первичной оценки ему в любом случае нужен технический специалист(ы). Ну а дальше вы описываете ровно те два случая
Согласен, в прогнозах ПМ опирается исключительно на техлида, или команду разработчиков если его нет. Но он таки может какие-то вещи понимать, особенно когда команда уже сплотилась — например оценивать разработчиков с точки зрения софт-скиллов — что собственно его непосредственная обязанность. А также понимать что они делают на начальном уровне — где ему нужна общая техническая грамотность. Ну и разумеется анализировать все с точки зрения пользователя.
Просто с другой стороны, даже если он вышел из разработки, он может а) не знать языки на котором пишется проект; б) быть уже не в теме. В итоге тоже проблематично и нужен техлид.
Насчет продукта — согласен. Просто у услуги много специфических моментов с точки зрения организации ее предоставления, про которые я собственно и написал.
Так или иначе я свои выводы сделал, вернусь тоже с другими материалами по теме.
Склонен считать что нормального управления на бумажке с ресурсами не получится. Поэтому выступаю за то чтобы как раз знать максимально о членах команды, и ресурсами воспринимать именно членов команды, ставя им задачи. У тимлида и без этого задач хватает.
Оба подхода имеют место быть, но я за то чтобы выстраивать все горизонтально, без лишних уровней.
И только тех-лид отвечает перед ПМ-ом по срокам, срывам и прочим радостям.
Лично мое мнение — эффективнее когда все работают со всеми, и каждый имеет право голоса. То есть ПМ ставит задачи напрямую команде совместно с тех-лидом. И спрашивает с каждого члена команды, опять же в связке с техлидом. Для этого конечно важно чтобы ПМ и Техлид отлично друг друга понимали и эффективно взаимодействовали. Плюсы же в том что исключается один уровень передачи информации, больше коммуникаций и открытости. Но это лично мое мнение, работать разумеется будет не везде.
Ответственность не за все. О чем вы вообще? Он несет ответственность за вверенный ему проект или продукт, если он лезет со своей ответственностью куда-то еще — его оттуда выпроводят, потому что занимайся своим делом. Да, он должен при этом взаимодействовать с другими, но взаимодействовать, не нести ответственность за их продукт, проект или функцию.
Дальше — прекращайте смотреть на все в формате черное-белое, мир несколько сложнее. Общаться уметь это не значит что в 100% случаев переговоры проходят успешно. Это утопия.
Что значит если не умеете договориться то идите ищите? Вы сами бизнес-переговоры вели? С командой в кризисной ситуации общались? У меня возникает ощущение что нет — вы слишком идеализируете. На подобии — ты либо попадаешь белке в глаз, либо вообще стрелять не умеешь.
У любого крутого коммуникатора бывают фейлы. Потому что он не может просчитать любого человека и с ходу воздействовать на его него так, чтобы тот его понял. Есть люди с которыми договориться в целом невозможно — потому что упертые и никого не слушают. Это раз.
Два — когда с тобой принципиально не хотят иметь дело по независящим от тебя причинам — навыки в общении не помогут. Потому что когда у тебя нет машины, навыки вождения не помогают.
На кризисных проектах и у меня возникает иногда такое желание, правда как правило разруливается все без таких методов. Но когда хочешь чтобы разработчики чувствовали себя нормально и получали за свой труд — это естественно.
вы это в моей публикации увидели?
Если так — то во-первых я никогда не был программистом. Во-вторых вы видимо что-то не так поняли. Мой посыл был не про потоп, а про то что в описанных условиях, я считаю работать — разрушать себя, и впустую тратить время. И после ухода никакого потопа не произойдет явно — потому что в описанных условиях от этого менеджера особо ничего не зависит, ему как следует ничего не делегировали, и со стороны работодателя было ошибкой его нанимать, так как он явно не хочет ему ничего делегировать, соответственно этой позиции быть не должно.
Плюс — конкретно в примере из собственной практики — я сделал все от меня зависящее чтобы ситуацию решить, и с командой и с начальством. Не помогло.
И я не склонен идеализировать места — это как раз программистский подход правильно-неправильно, есть подходящие места, и подходящее начальство. Это завязано плотно и на личностях и на корпоративной культуре. Думаю не будете отрицать что все таки выбирать надо, и работать надо там где комфортно. А не терпеть стиснув зубы — чтоб потопы не оставлять.
Безусловно. Был и такой опыт, но мое личное наблюдение — что неадекватность эта часто граничит с непрофессионализмом этих самых собственников. При этом по моему мнению любому руководителю низшего звена — профессионалу, с таким начальством работать не захочется, потому что он видит все его недочеты, пробелы, и не впечатляется его «харизмой». Но бывают и такие профессионалы-хариматики, которые и феерят и дело делают — с ними работать вполне себе можно, если абстрагироваться от их приколов.
Во-первых команде не следует быть наивной и полагать что все будет красиво и идеально, никаких переработок — все рады бы так, но это так не работает, всегда есть фактор неопределенности, есть неожиданные вещи. Вопрос лишь — заморачивается менеджер тем чтобы с этим бороться и защищать своих разработчиков от переработок и прочих негативных явлений, или ему плевать на людей — он думает о премии. Видел много таких.
Но статья не об этом — статья о том, что попробуйте стать на позицию этого менеджера который между двух огней находится, и попытаться разрулить такую ситуацию.
Почему же — субподрядчик может юзать скрам у себя внутри. Продукт-оунер у него свой, который получает все задачи, обсуждает их вносит в бэклог команды.
И такие люди есть как среди начальства и подчиненных, плюс зависит очень сильно от среды — где как на каких ролях это все происходит. Именно про это я написал.
Команда лично ему ничего не должна — она должна компании на которую работает, выполнять обязательства по трудовому договору, в котором обычно написано что поставленные таски нужно делать, менеджеру подчиняться.
Если менеджер не выстреливает в продукте (хотя я говорил про проекты, не про продукты, это разное) — то ему там в целом нечего делать, про ответственность точно также.
Только вот как раз моя статья о том — что будь ты хоть лучшим оратором и психологом — у объяснения две стороны, кто объясняет, и кто слушает (или не слушает). И бывают ситуации когда слушающим просто неинтересно это все. Они не сомневаются в своей правоте и не хотят никаких аргументов слышать. У человека два состояния когда его пытаются чему то научить (что-то объяснить) — либо он слушает и впитывает, либо он уходит в оборону и ничего не воспринимает. Я выше уже писал — когда люди адекватные, с ними можно работать даже если есть различия во мнениях, им можно объяснить, с ними можно наладить рабочий контакт. Когда настроены консервативно и закрыто — это почти невозможно, нельзя заткнувшему уши что-то объяснить, это его выбор тебя не слушать.
Вот как раз тут я не вижу смысла биться головой и пытаться пробить стенку.
Все вышесказанное относится ко всем в целом — я видел случае когда наоборот, команда что-то пытается донести менеджеру, а он ни в какую не слушает, и делает по своему и получается дичь. Послы статьи в том что команда находится в менее уязвимом положении — у нее только начальники, один плохой — идешь к следующему, эскалируешь. А у менеджера с двух сторон могут прилететь проблемы, и виноват будет он.
Прикрывать нужно всех имхо — а потом самому разбираться, подчиненных должен наказывать прямой руководитель, не тот кто выше. Иначе остальные будут думать что вот сейчас пока мы все делаем — он добрый и защищает, а как только косяк — отдаст на съедение высокому начальству.
И мудрый руководитель менеджера это знает — он не начинает разносить сам, а поручает это прямому начальнику провинившегося.
Менеджер может быть токсичным — но такие в этой профессии долго не задерживаются, тут коммуникации ключ.
Да кстати
Это было серьезно сказано? Давайте не будем мемами из вк разговаривать.
Во-первых люди не делятся на 2 категории. Прежде чем что-то делать — надо для начала подумать. Потом делать. Думать почему не получилось (или получилось) тоже надо всегда — человек среди прочего, отличается от животных способностью прикидывать возможные последствия, а также учитывать собственный опыт.
У меня ощущение что вы просто увидели себя описанной команде, и пытаетесь всеми правдами защитить её, и найти повод все свалить на условного ПМ-а. Поправьте если я ошибаюсь.
Интересная и чёткая концепция.
Прикрывать своих мне кажется обязательным условием. Любой руководитель который этого не делает — обречён на провал.
Я тоже видел, но это если команда адекватная — да вариант, на личных качествах вывозить.
Но когда команда токсична и в целом враждебна, а начальству все равно — я считаю что пустой номер пытаться головой пробить стенку. Ради чего?
Кто сказал что он будет один? Это в целом другая тема, как управлять в таком масштабе, как дробить команды, есть свои методологии, сейчас не совсем про это, так что опущу.
Вы описываете один конкретный случай из множества возможных. Кто сказал что автор фичи и заказчик одно лицо? Выше уже было обсуждение — я говорил именно о проектах, то есть о то что имеет начало и конец, скоуп и так далее, не продукт. Проект зачастую делают для кого-то внутреннего или внешнего заказчика, и в 90% случаев краткосрочная история разработки. Соответственно в этих условиях часто заказчик не является грамотным технарем, продуктовым менеджером и так далее. Он не описывает детально фичу. Это делается на стороне исполнителей на основе условных «хотелок» заказчика. И соответственно с этим надо идти к тому кто руководил процессом — к менеджеру.
Обещать не значит жениться. Должен и делает это разное. Я согласен что в современной разработке это обязательно, но многие ли из них по факту комфортно себя чувствуют в общении и умеют четко доносить свои мысли? Особенно учитывая что это зачастую их прямая обязанность разработка, коммуникация на третьем плане. Еще раз — я не спорю что должен, я лишь утверждаю что практика (моя и коллег) показывает что часто на этом спотыкаются. Многим просто лень подойти к коллеге из другой команды и пообщаться, или в чат ему написать. У меня буквально на днях такой случай был — программист со стороны заказчика внедряя наш код, не спрашивал непонятное — а делал по своему разумению, чем создал сложности, хотя имел все возможности спросить. Даже языкового барьера не было.
Это один частный случай. Про продюссера ответил выше. Про документацию — в Agile вообще документация стоит ниже по приоритету, согласно принципам. И документация мертва, а древо жизни зеленеет. Живое общение всегда лучше, можно задать вопрос и сразу получить ответ. Также нужно дублировать минимум на два канала, потому что всегда есть вероятность что в документацию не заглянут в нужный момент. Нужно страховаться.
Нет, совсем нет. Продуктовый менеджер занимается стратегией продукта, метриками, он дает фичи в достаточно общем виде, без деталей. В том же Яндексе к примеру ровно наоборот — есть продуктовый, он главный, есть проектный, он занимается операционкой и ежедневной координацией. Ну и я сразу сказал что речь идет про проекты, не про продукты, и про проектных менеджеров. Скоуп работ сроки и ресурсы — из классического PMBok — кто им пользуется в разработке софта? И то это не исключает того что он руководит проектной командой и заботится о коммуникации.
Во-первых это не их работа. Во-вторых не все умеют. В-третьих они тогда должны делиться всей информацией с командой, чтобы все были в курсе о принятых решениях, изменениях. В таком случае это будет сплошной поток разных договоренностей. Один договорился об одном, другой о другом, что полностью или частично идет в разрез с первой договоренностью из перечисленных и это порождает еще большую неразбериху чем бутылочное горлышко с испорченным телефоном, кстати в случае коммуникации большего количества людей — он портится еще больше.
Переговоры всегда ведет один человек, это не с потолка взято, когда все под контролем у одного менеджера, спрос тоже с него, и вопросы тоже к нему. Как промежуточное решение — все общаются в одном чате с заказчиком, но контроль, фасилитация и ответственность за это — все равно на менеджере.
Услуга как продукт
1. Может ли услуга быть продуктом? Может. Если она а) стандартизована по составу, процессу, результату и цене, б) многократно повторяема и в) вы можете научить оказывать ее кого-то другого.
2. Можно ли быть бизнесом, оказывая услуги, но не имея продукта? Нельзя. Этот «бизнес» умрет, как только основатели устанут, уйдут или умрут.
3. А как же, например, большие консалтинговые компании — они же под каждого клиента подстраиваются? А у них просто продукт другой — система набора, тренировки, контроля и продвижения людей, которые способны такие нестандартизованные услуги оказывать. Именно этот продукт создали основатели, и он продолжает жить, даже когда люди в компании сменились.
4. В общем, продукт — это когда что-то стандартно, повторяемо и передаваемо. На этом фоне меня умиляют люди, которые строят «бизнес», выдвигая в качестве своего конкурентного преимущества свой «высокий профессионализм» в продаваемой области. Тем самым они намекают, что обладают уникальным и неповторимым умением.
Это мое профессиональное хобби — исследовать насколько много специалистов которые могут совмещать, и как они к этому пришли. Пока выводы сводятся к тому что таких людей катастрофически мало, и это зачастую талантливейшие профессионалы. И компании которые таких хотят зачастую сталкиваются с трудностями. Ну или берут человека который явно проседает по каким либо из компетенций.
Согласен, в прогнозах ПМ опирается исключительно на техлида, или команду разработчиков если его нет. Но он таки может какие-то вещи понимать, особенно когда команда уже сплотилась — например оценивать разработчиков с точки зрения софт-скиллов — что собственно его непосредственная обязанность. А также понимать что они делают на начальном уровне — где ему нужна общая техническая грамотность. Ну и разумеется анализировать все с точки зрения пользователя.
Просто с другой стороны, даже если он вышел из разработки, он может а) не знать языки на котором пишется проект; б) быть уже не в теме. В итоге тоже проблематично и нужен техлид.
Насчет продукта — согласен. Просто у услуги много специфических моментов с точки зрения организации ее предоставления, про которые я собственно и написал.
Так или иначе я свои выводы сделал, вернусь тоже с другими материалами по теме.
Оба подхода имеют место быть, но я за то чтобы выстраивать все горизонтально, без лишних уровней.
Лично мое мнение — эффективнее когда все работают со всеми, и каждый имеет право голоса. То есть ПМ ставит задачи напрямую команде совместно с тех-лидом. И спрашивает с каждого члена команды, опять же в связке с техлидом. Для этого конечно важно чтобы ПМ и Техлид отлично друг друга понимали и эффективно взаимодействовали. Плюсы же в том что исключается один уровень передачи информации, больше коммуникаций и открытости. Но это лично мое мнение, работать разумеется будет не везде.