×

О роли PM и менеджменте больших масштабируемых проектов

Добрый день! Эта статья — попытка ответить на самые часто задаваемые вопросы об эффективном управлении ИТ-проектами, которые мне задавали во время и после семинара Vertamedia Experience Sharing, посвященному проектному менеджменту.

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

Кто такой ПМ

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

Но бывает другая реальность — проект бессрочен, требования расплывчаты ибо заказчик сам до конца не понимает, чего хочет. Естественно, что проект в такой ситуации «разбивается» на этапы, очерёдность которых сильно зависит от уровня осознания Заказчиком конечного продукта. А если этого осознания нет? Тогда в дело вступает команда аналитиков, задача которых очень толерантно помочь Заказчику «превратить» идею в совокупность требований. Опять все кажется очень простым, однако команда аналитиков может помочь Заказчику сформулировать такие требования, что проектной команде они будут не под силу. И чтобы это не произошло, нужен сдерживающий фактор, гарантирующий, что требования не выйдут за границы компетентности проектной команды или будут в рамках, достижимых командой в разумные сроки. И таким сдерживающим фактором является ПМ.

Можно услышать много историй как в молодых командах проектными менеджерами становятся наиболее подготовленные или авторитетные разработчики. И не факт, что на момент такого «назначения» человек мечтает исполнять обязанности ПМ-а. Так же нет уверенности, что у человека есть задатки к такой деятельности или хотя бы базовые знания специфики управления проектами. Можно выйти на рынок и купить готового ПМ-а. Но давайте вместе ответим на вопрос: что лучше, купить или вырастить ПМ-а?

Купить или взрастить

Предлагаю рассмотреть этот вопрос с точки зрения управления рисками. Давайте ответим на вопрос: какие риски являются наиболее критичными в реализации ИТ-проектов?

Опыт позволяет говорить о трех наиболее значимых рисках в порядке убывания критичности:
— Реализовали не то, что нужно;
— Реализовали то, что нужно, но с опозданием;
— Реализовали не то, что нужно и с опозданием.

Итак, наиболее важно реализовать то, что ожидает Заказчик, а для этого нужно, чтобы ПМ «сходу» действительно понимал суть проекта. Не вызывает сомнений, что наиболее опытный разработчик из числа проектной команды будет лучше понимать суть проекта, чем нанимаемый сторонний ПМ. Именно поэтому мы предпочитаем растить своих ПМ-ов. Это позволяет эволюционным образом улучшать качество управления, так как вчерашний разработчик, который видел ошибки ПМ-а со стороны девелопмента, наиболее вероятно не будет допускать такие же. Более того, переход разработчика на уровень проектных менеджеров открывает другим менеджерам возможность получения обратной связи от «уже не разработчика», так как полностью устраняет возможный дискомфорт общения представителей разных «цехов».

Есть ещё один весомый аргумент в пользу «взращивания» своих ПМ-ов. Компании, которые работают на активно растущих рынках, сталкиваются с отсутствием единой терминологии, что создаёт немало проблем. Девелопер, который проработал определённый срок в компании, априори в той или иной мере владеет этим тезаурусом, а нанимаемый ПМ вынужден будет этот тезаурус осваивать, что на практике оказывается весьма непростым и затратным по времени делом.

Следует сказать пару слов о социо-культурных особенностях проектной команды. При приходе нового менеджера со стороны есть риск потери времени на изменение социо-культурной среды, что является следствием попыток нового руководителя «переделать» команду под «себя». Выходец из команды максимально вероятно будет следовать устоявшимся практикам общения — сохранять общность команды путём сохранения правил. Очень важно понимать, что назначение нового руководителя не всегда должно быть основанием для «ломания через колено» команды.

Изложенное выше якобы однозначно говорит о том, что «домашний» ПМ лучше. С другой стороны, человек со стороны со своим опытом может быть хорош тем, что привнесет новые опыт и новые практики управления из других компаний, с которыми местные «выращенные» специалисты могут быть незнакомы. Так же если команда «теряет» проект, то лучшим решением может быть привлечение «варяга», то есть стороннего ПМ-а, который помимо основных функций управления проектом выполнят ряд антикризисных мер. В кризисных ситуациях, особенно в длящихся долго, «поломать через колено» может быть лучшей стратегией. Но нужно помнить, что в столь радикальных мерах можно «выплеснуть ребёнка с водой».

Точка принятия решений

Выше под «выплескиванием ребёнка» подразумевалось недоведение проекта до минимального жизнеспособного состояния (Minimum viable product, MVP). MVP — это точка принятия решений. В момент инициирования нового проекта основная задача ПМ-а — «нащупать» эту точку.

Это точка важна по ряду факторов, среди которых я бы выделил следующие:
— Любые требования, выходящие за рамки MVP, могут быть пересмотрены по результатам эксплуатации продукта с минимально необходимой функциональностью;
— Если Заказчик получит MVP в оговорённые сроки, то вероятность отказа от проекта близка к нулю;
— Если Заказчик получит MVP немного ранее оговорённых сроков, то его удовлетворённость от сотрудничества значительно повышается.

Иными словами — требования, определяющие MVP, самые приоритетные. И тут мы не изобретаем «велосипед». Мы лишь строго следуем принципу Вильфредо Парето: 20% усилий дают 80% результата. В данном случае я не подразумеваю результат в виде доходности, я подразумеваю под словом результат удовлетворённость Заказчика, а следовательно MVP, который и составляет как правило 20% проекта, обеспечивает стабильность команде на оставшиеся 80%.

Но для того, чтобы удовлетворённость заказчика росла, ПМ-у необходимо чёткое представление о компетентности каждого члена проектной команды и его продуктивности. В противном случае у ПМ-а нет инструментов контроля сроков выполнения задач. А вопрос о возможности решения той или иной задачи в предполагаемые сроки становится центральным, так как без однозначного ответа на этот вопрос риск невыполнения обязательств в оговорённые сроки значительно повышается.

Закладывать разумные запасы временного ресурса опытному ПМ-у позволяют показатели ключевых индикаторов производительности (Key Performance Indicators, KPI) каждого члена команды. Я оставлю KPI без рассмотрения, так как это предмет иной статьи. Замечу только, что использование этих метрик минимизирует риск невыполнения взятых обязательств в срок.

Если с привлечением внешнего ПМ-а все более или менее понятно, то процесс взращивания ПМ-а из девелоперов заслуживает отдельного рассмотрения. И тут следует рассматривать два варианта: ПМ-а раньше не было в команде или ПМ раньше был в команде, но ушёл «по велению души».

Первый вариант мы уже частично рассмотрели, когда говорили о «превращении» девелопера в ПМ-а в условиях, когда существует «каста» или «цех» проектных менеджеров. А вот ситуация, когда ПМ-а раньше не было (что свойственно стартапам, например) не так тривиальна.

Из девелоперов в ПМ-ы

Новоиспечённому ПМ-у придётся стать единственной точкой коммуникации между Заказчиком и командой — шаг, который позволит снять нервное напряжение с разработчиков и систематизировать постановку задач. Как правило, это самая значимая проблема на ранних этапах: сотрудники проекта в хаотическом порядке ходят ко всем разработчикам с устными идеями — без приоритетов, без подробного описания, без понимания реальной ценности отдельно взятой задачи в рамках идеи проекта и т.д. Взять этот процесс под контроль удастся только поняв, сколько вообще задач поступает в команду и как эти задачи связаны друг с другом. И тут главное помнить, что «к сказанному нельзя вернуться». Поэтому все требования должны быть детально описаны, согласованы и приоритезированы в случае, когда ПМ совмещает роль бизнес-аналитика. Очень важно помнить при описании о необходимости единого толкования терминов, поэтому задача формирования единого тезауруса — это неотъемлемая часть формирования требований.

Описанные, согласованные, приоритезированные и понятные (подчеркиваю) требования позволяют выстроить упорядоченную очередь с последующим планированием итераций, что является фундаментом на пути построения роадмапов (road-maps) и конкретизации целей в долгосрочной перспективе.

Об оценивании сроков и их предварительной проверке мы уже немного говорили. Как показала практика, молодые команды едва ли могут оценивать даже небольшие задачи точнее, чем в днях. На этом этапе самое время учиться эстимировать ваши задачи. Я рекомендую идти от большого к меньшему: начните с оценки в днях и двигайтесь в сторону почасовой оценки, улучшая постепенно точность прогнозов на основе реальной статистики. Будете вы использовать для этого реальное время или стори-поинты (story-points) — ваше дело. Но понимать, сколько команда способна производить продукта за выбранный период времени, новоиспеченый ПМ просто обязан.

И тут на помощь приходят инструменты, без которых сложно представить эффективное проектное управление: трекинг системы, ведение бизнес и технической документации, разработка мокапов (mock-ups) и интерфейсов (вряд ли на этом этапе у вас появится UX инженер) и т. д. Не откладывайте использование инструментов в долгий ящик. Помните, что они не только позволяют решать задачи управления проектами, но и являются «точками» передачи критичных знаний. Именно поэтому стоит уделять много времени ведению документации.

Проблемы роста

На определённом этапе команда становится настолько большой, а задачи настолько различными, что приходит время делить проектную команду на несколько взаимосвязанных (например, frontend/backend) или самостоятельных команд (проекты с различным целевым назначением).

Координация работы нескольких команд в рамках одного проекта — «тяжёлый хлеб». Почему? Есть несколько причин:

1) В несколько раз больше требований — чтобы успевать собирать требования и преобразовывать их в понятные задачи для нескольких команд, необходимо непропорционально больше времени или выделенная роль аналитика. И чтобы не «утонуть» в сборе требований, ПМ должен выстроить такой режим коммуникации с Заказчиком, чтобы средне-долгосрочные планы были едино понимаемы обоими сторонами как можно раньше.

2) Требуется время на синхронизацию команд — это новый и отдельный процесс для ПМ-а. Если работа команд взаимосвязана, команды могут блокировать друг друга, что приведёт к потере эффективности.

3) Требуется время на формирование культуры производства — привить проектным командам понимание, что с результатом их труда придётся иметь дело не только заказчику, но и коллегам из соседних команд. Не факт, что это потребуется, но вероятность существует.

4) Требуется время на донесение сути продукта до проектной команды, что, если проекты взаимосвязаны, значительно поможет разработчикам принимать более правильные технические решения.

5) Требуются моральные и временные ресурсы на демонстрацию результатов — очень вероятно, что ваш заказчик (пусть даже он и часть вашей компании) уже глубоко погряз в бизнес процессах и не «тусуется» с вами постоянно в одном кабинете. При этом ваш продукт стал куда больше, чем то, что можно показать мимолётом. Обязательно выделяйте время для проведения демонстрации значимых этапов реализации. Это отличный способ обсудить текущее решение и получить по нему целостную обратную связь (фидбек), которая может стать основой развития проекта в форме, например, фича-листа.

6) Требуется больше времени на документирование — если у вас документации ещё нет, то это очень плохой знак! Хорошая техническая и бизнесовая документация значительно сокращает время внедрения каждого нового сотрудника. В последствии она будет экономить до одного месяца на вовлечение в проект каждого нового члена проектной команды.

А что дальше? Дальше, при активном росте компании, времени на выстраивание внутренних процессов проектных команд практически не остаётся. Вы оглянуться не успеваете, как у вас:
— Орда стэйкхолдеров — владельцы бизнеса, финансовые и кадровые специалисты, руководители отдела продаж, отдел поддержки клиентов, ключевые клиенты и т.д. Задачи «сыпятся» безостановочным потоком как из рога изобилия, а продукты отгружаются в совершенно различных направлениях;
— Отряды разработчиков — много команд, кто по SCRUM, кто по Kanban, где 5 человек, где 2, где есть Scrum-мастер, а где один «ниндзя» сидит в углу и выдаёт стабильный и крутой код, но он сильный мизантроп.

Кроме того, ещё есть временные задачи, которые хорошо бы отдать на аутсорсинг.

В такой обстановке скорее всего вы уже не будете ПМ-ом в классическом понимании. Вам судьба предлагает выбор. Вероятно, вы себя найдёте в одной из ипостасей: product manager, business analyst, intelligence analyst (trend spotter). И тогда вам придётся искать ответы на другие вопросы: как жить в этой среде, какие навыки, концепции и принципы применять и развивать, что такое системы и системные мышление, как и зачем децентрализовать процесс принятия решений. И может быть вам приглянется идея бережливого производства, и хорошим решением станет Scaled Agile Framework, но это уже другая история.

Иерархический структурированный микроменеджмент

Расскажу пару слов о практике управления проектами, которая на опыте оказалась «тупиковой». Изначально мы делили ПМ-ов на «сервер-сайд» и «фронт-енд-сайд». Такое разделение не позволило достичь приемлемого уровня синхронизации — казалось бы, задачи на каждой «стороне» сделаны, а целостного продукта не получается. Постепенно пришли к пониманию, что должно работать правило «один проект — один ПМ». Но так как проектов становилось больше, и количество ПМ-ов росло, нам потребовался человек, способный организовать работу ПМ-ов. Так родилась двухуровневая модель — стратегически-тактический и тактически-оперативный уровень.

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

В такой трехуровневой модели управления обязанности распределятся следующим образом. «Полевые командиры» или ПМ-ы оперативного уровня управляют небольшими командами конкретных проектов. Именно они общаются с девелоперами и принимают участие во встречах с Заказчиком. Как правило, ПМ-ы этого уровня и взращиваются из девов.

Следующий уровень — «штабные командиры», или ПМ-ы тактического уровня, отслеживает прогресс по нескольким проектам с целью независимого контроля удовлетворенности бизнеса. Данный уровень более остальных сконцентрирован на потребностях заказчиков и дистанцирован от девелоперов. Представители ПМ-ов тактического уровня менторствуют над «полевыми командирами». Их хлеб — это сроки по этапам и прогноз их выполнения. Данный уровень может комплектоваться ПМ-ами обоих типов — «домашними» и «варягами».

Перед стратегическим уровнем (PM Director) поставлены следующие цели — отладить процесс управления проектами, обеспечить по запросу информирование собственников о проектах, обеспечить Business Continue и Business Recovery, оптимизировать внутренние проектные затраты.

А цербер ли?

Прежде чем закончить наш разговор, я хочу задать вам вопрос — кем должен быть ПМ в команде — цербером (надсмотрщиком) или авторитетным специалистом?

Убеждён, что ответ на данный вопрос был найден вами при прочтении этой статьи. Если нет, я буду рад помочь — в комментариях или при живом общении на следующем мастер-классе VertaMedia Experience Sharing, куда я всех приглашаю.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




52 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
Прежде чем закончить наш разговор, я хочу задать вам вопрос — кем должен быть ПМ в команде — цербером (надсмотрщиком) или авторитетным специалистом?

it depends

хороша статья

Спасибо за статью

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

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

Хочешь сказать: а что если бюрократический ад — это так надо, и кто хорошо слушается сам попадёт в рай станет манагером и будет устраивать другим бюрократический ад?

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

Хотел уточнить у автора статьи рентабельно ли для компании выстраивать целую отдельную иерархию менеджеров?

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

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

Ну скажем так: тебе, чтобы работать, вся эта иерархия менеджеров сверху нужна?

Дело в том, что я сам часть этой иерархии :-) просто раньше такого не встречал, а сейчас сначала столкнулся с этим на практике, а теперь и статью об этом прочёл.

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

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

Кирилл, не подумайте ничего плохого, просто мысли со стороны.

Спасибо за ваш комментарий.

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

Будьте попроще и люди потянутся. А пока что — консультанты консультировали-консультировали, да не выконсультировали.

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

Ни разу не встречал хорошего PM-а IT проектов, который не имел хоть сколько-то девелоперского прошлого. Отмазка гуманитариев и прочих непрофильных нищебродов, не сумевших стать профессионалами в своих областях.

Т.е. человек, допустим, подняший с нуля пару свечных заводиков «гуманитарный нищеброд», а багофиксер получивший лычку в бодишопе звезда?

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

Да-да, CSS это не для средних умов...

CSS может и для средних, а вот какой-то dependency injection уже вряд ли

Ну да, ну да. Rocket Science, недоступный человеку сдавшему матан, ТОЭ или сопромат.
И кстати зачем менеджеру разбираться во всем этом говне? Он что это клиенту должен правильно транслировать?

Вы все верно сказали — для правильной трансляции клиенту. Кстати тандем ПМ/ТехЛид тоже возможен как прокомментировали ниже по ветке.

Главная задача ПМа, это сбить требования с заказчика и оформить их в нормальные требования для девелоперов. Главный навык ПМа — communication. Ну а с тонкостями кодописания разберется лид девелопер.

А зачем ПМу понимание тонкостей dependency injection? Для этого есть архитектор / тех. лид

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

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

1 — ответы/вопросы помогающие клиенту определиться с техн обоснованием того или иного решения в проекте
2 — да
3 — нет, но должен понимать что предложили и уметь это защищать перед клиентом
4 — да, если является также аналитиком

ответы/вопросы помогающие клиенту определиться с техн обоснованием того или иного решения в проекте

Для этого ПМ идёт к тех лиду / архитектору, если только один человек не совмещает в себе обе «шапки» (что редкость, да и крайне нежелательно на больших проектах, т.к. обеим «шапкам» есть чем заняться на full time)

Для больших проектов так и делается. Для мелких — лишние траты.

должен понимать что предложили и уметь это защищать перед клиентом

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

Верно, но в большинстве случаев и сам должен (если также совмещает биз аналитика) уметь перевести на понятный бизнесу язык.

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

согласен, но вы описали крайность, которая тоже только вредит

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

Я би радив не вигадувати свою термінологію, якісь особливі описи стандартних ролей і незрозумілі варіації управлінських практик — а просто почитати спеціалізовану літературу і вивчити те, що в проектному менеджменті (як в ІТ індустрії так і в інших) вже давно є загальноприйнятим. Почати можна звідси — www.pmi.org/...undational-standards.aspx. Щодо корпоративного управління — то всі типові організаційні структури зі своїми сильними і слабкими сторонами детально описані в книзі Генрі Мінцберга «Структура в кулаке».

Тестировщики рассказали, какой должен быть ПМ. Разработчики тоже рассуждали на тему. Теперь вот Бизнес Аналитик. Когда же ПМ расскажет, каким он должен быть?:)

К слову сказать у аналитика больше оснований рассказывать о том каким должен быть ПМ(как может следовать из уже упомянутой Volodymyr Oros «Структуры в кулаке») чем у многих других перечисленных. А уж тем более если этот аналитик с опытом ПМ-ства(что в наших «краях» далеко не редкость).

Годно написано. Только сейчас опять набегут фронтэнщики и начнут разоряться, что как это ПМ может управлять командой без знания CSS.

Я ПМ и мне нужно знание ЦСС чтобы двигать пиксели в панели разработчика браузера. ШАХ И МАТ.

ТрЭш.
1.

Именно поэтому мы предпочитаем растить своих ПМ-ов.
Только ты пришел со стороны. Как же так получилось?

2.

Это позволяет эволюционным образом улучшать качество управления, так как вчерашний разработчик, который видел ошибки ПМ-а со стороны девелопмента, наиболее вероятно не будет допускать такие же.
 но
Выходец из команды максимально вероятно будет следовать устоявшимся практикам общения — сохранять общность команды путём сохранения правил. Очень важно понимать, что назначение нового руководителя не всегда должно быть основанием для «ломания через колено» команды.
Т.е. ошибки видим, исправлять не можем, ибо «ломаем устоявшееся бла-бла через колено».

3.

Девелопер, который проработал определённый срок в компании, априори в той или иной мере владеет этим тезаурусом, а нанимаемый ПМ вынужден будет этот тезаурус осваивать, что на практике оказывается весьма непростым и затратным по времени делом
Весомый аргумент для застаивания всей отрасли — каждая компания варится в своем соку. Шаг влево-вправо — и ты уже не спец, а не пойми-кто и не знаешь, о чем люди вокруг говорят.

4.

Поэтому все требования должны быть детально описаны, согласованы и приоритезированы
и
если у вас документации ещё нет, то это очень плохой знак!
— но на каждой схеме мы видим Agile Team?

5.

кем должен быть ПМ в команде — цербером (надсмотрщиком) или авторитетным специалистом?
Вообще финал. Либо надсмотрщик, либо начальник. Третьего не дано?

Добрый день Тарас.
1. В любом случае вы откуда-то придёте — если только это не первое место работы. Тут скорее важно, на каком этапе вы стали частью компании / команды.

А в остальном — это анализ различных подходов. Где-то нужна стабильность, где-то гибкость, а где-то скорость вопреки качеству. Всё зависит от задачи и это нужно понимать. Идеального рецепта на все случаи жизни скорее всего нет.

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

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

Всё упирается в качество эстимейтов. И с каждой новой задачей в проекте/итерации разброс будет всё шире, и шире, и шире. А тут ещё и чёрные лебеди приплывают как не в виде увольнения одного тиммейта, так в виде свадьбы другого. У cartmendum есть хорошее видео на тему — penxy.com/gije
P.S. «воряги» через «а» пишутся.

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