Идея классная :) А по рабочим таскам?
В JIRA из коробки такого фукнционала нет, но есть workaround через подписку на фильтр: jira.atlassian.com/browse/JRACLOUD-30665
BI/плагины тоже должны решить проблему .
Ну, вообще да, мы этим вопросом тоже задавались :) В целом, в большинстве случае — это координация задач, и по большей части таск менеджмент в JIRA, когда нужно создать и проконтролировать определенные задачи, а это ведь тоже время. А человек учится, задает вопросы, и постепенно начинает работать более самостоятельно. Есть даже позиция «Project Coordinator».
Вы отвечаете не на тезисы в статье, и комментарии выше. Я не писал о том, что ПМ должен быть скрам мастером, я писал о том, что я рекомендую изучать, а также какие процессы используются в нашей компании для управления кросс-проектной матрицей, и это не Скрам в чистом виде, мы много экспериментировали. А должен ПМ быть скрам мастером, или нет — это другой топик.
Также не согласен насчёт общего функционального / линейного менеджмента, вы упускаете риск менеджмент (а это серьёзный аспект проекта), также аналитику (а это то, как вы считаете ваши часы == ваш бюджет)
Около 17к, это правда. Зависит от стоимости маклера, консультанта по ипотеке и т.д, конечно.
Спасибо за конструктивный комментарий. Я не говорю, что ПМ должен быть Скрам Мастером априори. С моей точки зрения:
1. ПМ должен понимать, что такое итеративная разработка, и почему частые релизы выгодны команде и бизнесу (эта тема также связана с continuous delivery)
2. ПМ должен уметь построить процесс, но не обязательно выполнять роль Скрам Мастера)
3. В случаях, когда вы работаете с shared pull of resources, и состав проектной команды меняется динамически, вы не сможете построить полноценный Скрам, по той причине, что при наличии 7+ проектов одновременно, вам нужно будет запускать 7 итераций, что для проектов длительностью
Как я писал, градация довольно условна, поскольку в разных компаниях роль ПМа может сильно варьироваться. Также добавлю, что Junior PM, в большинстве случаях, не будет вести весь проект самостоятельно (по крайней мере, проект, в котором необходима работа с рисками), а будет выполнять часть работы по проекту (то есть заниматься координацией ресурсов, контролем выполнения задач и т.д.) под руководством старшего коллеги. Аналогично с управлением бюджетом. Но знать и изучать тему риск менеджмента необходимо с самого начала, на мой взгляд.
Согласен, материала много, можно написать более детально в
Речь идёт об основах, конечно, хотя технический менеджер, который не навязывает свое мнение, подарок для команды. Практическая ценность: лучшее понимание логики продукта, зависимостей между различными модулями, лучшее описание пользовательских историй, понимание аналитики по спринту (т.е. если менеджер понимает, почему на эту таску было нужно именно столько времени), консультация клиента в фазе Presale, более грамотное построение WBS, то есть высокоуровневая декомпозиция MVP релиза. Это не уровень Junior, но читать теорию я бы рекомендовал с самого начала, и углубляться при необходимости.
Спасибо за дополнение, согласен, добавим. Да, легкая практика желательна, но точно полезна, потому что мы должны понимать что такое релиз практически, когда мы планируем эту активность. И, соответственно, должна быть правильная (единая для всех проектов одного стека) модель бранчевания.
Спасибо большое :)
Да, но основы, на мой взгляд, менеджер должен понимать в любом случае, просто потому, что иначе сложно понять продукт. А если со стороны клиента технический менеджер, будет довольно сложно обсуждать скоуп. Но здесь очень индивидуально, в зависимости от процессов компании, так что вы правы.
вопрос в том, какие данные могут мониторить сейчас часы?
Попробуй к нам: jobs.dou.ua/...anies/playtech/vacancies
Свои продукты
Откровенно говоря, не понимаю смысла цветных резюме, — отталкивает. Это официальный документ, должен подаваться в строгом виде, ИМХО.
Речь идет не о контроле, а о биллинге клиенту