И тут Канбан как нельзя лучше подходит к проектам, где изменения происходят очень часто.
Факт! И таких проектов не так уж мало. Когда в разгар работы приходит менеджер по продажам и говорит что нашел кучу денег, но надо срочно делать прототип — моя команда садится и делает. И приходится забыть про текущий спринг, рассчитанный фокус-фактор… И с кураторами проектов мне проще торговаться за то, какие задачи сейчас отложить, чтоб сделать что то внезапно-срочное, чем доказывать что сначала надо закончить текущий спринг. И зачастую это единственнный выход!
Может и усложняю, но я полагал что фокус-фактор — отношение идеальных дней к реальным в последнем спринте. На практике в команде могут быть настолько по разному подготовленные люди, и задачи можно раздать этим исполнителям так, что получим довольно разные значения фокус-фактора для одного и того же спринга. Вплоть до нуля.
Комментарий заставил задуматься над тем как я работаю со своей командой, спасибо…
Фокус-фактор штука мощная, когда она есть. Но, если в команде работают люди с сильно разной квалификацией, он превращается в среднюю температуру по палате.
Вопрос «будут ли ВСЕ важные запланированные задачи готовы к сроку поставки» не всегда является центральным. Подход может быть другим, например: «Вот задачи А, В, С. Скажите нам, что из них когда мы будем продавать». Получается поток задач и это не плохо само по себе. Всего лишь вопрос выбора бизнес-модели.
Впихивания задач в канбане не произойдет, если менеджер ( мы кстати о каком менеджере говорим? о менеджере продаж надеюсь? ) принимает условие, что количество открытых задач в потоке конечно, и чтобы что то добавить — надо что то убрать. Как оценить это количество? Тут фокус-фактор сам по себе меня никогда не спасал. На самом деле эту оценку всегда приходится проводить и доказывать заново, как только кому то надо подвинуть сроки или расширить объем работ. Можете считать индивидуальный фокус-фактор для каждого члена команды, и давать оценки в зависимости от того, кто конкретно будет делать работу.
а я бы фазы Формирование и Столкновение объединил бы в одну. потому что на моей практике работы в командах процессы этих двух фаз шли всегда вперемешку. Так же объединил бы Нормализацию и Исполнение. Потому что Исполнение дает предпосылки для Нормализации а Нормализация в свою очередь стимулирует Исполнение
А еще команда может пребывать в стадии Сна. :-) Но Такман об этом не знал.
В этой модели 2 последние фазы «Исполнение» и «Завершение» кажутся мне особенно притянутыми за уши. что то создатель модели слукавил.
Перечисленные риски не завершаются и не появляются от фазы к фазе. Они присутствуют практически все время. Например «Лидеру не удается удерживать в поле зрения все задачи, которыми необходимо заниматься параллельно». Не думайте, что вы расстанетесь с этим риском по прохождении фазы формирования :-)
Вставлю свои 5 копеек в дело просвещения начинающих докладчиков. Вообще то я хотел разместить ссылку в топике, но вы меня опередили :-) Правда, мои советы касаются не просто презентации а скорее, выступления в целом. www.vzzvzz.com/presentation-advice-to-beginner/
Мне знание PMBOOK помогло Оргтех предложение на конкурс писать. Там надо было описать в том числе как планируется оказывать услугу по разработке и внедрению. Так и написал, по стандарту, по пунктам.
Однозначно, надо знать хотя бы один стандарт. Хотя бы в общих чертах.
«Клиент всегда прав» — это какая-то лакейская убежденность. Надо все таки понимать что каждая сделка это ВАШ шаг к ВАШЕЙ цели, и из этого исходить.
Быть снобом на рынке не надо, но от некоторых сделок лучше отказываться, если понимаете что общий язык с клиентом не найдется.
Если обсуждать суть ваших претензий, то я готов принять только замечание по поводу Приложения 1, которое действительно «повисло» по моему недосмотру. В остальном настаиваю на письме as is. Да стиль письма далек от разговорного, и он должен быть далек.
Должен покаяться, статья не вполне удалась. Судя по отзывам читателей, многие не поняли о каких письмах идет речь. Конечно речь не идет о том, что мы пишем по e-mail в повседневной работе с заказчиком. Глупо было бы писать в таких формулировках КАЖДОЕ письмо.
Речь в статье шла об ОФИЦИАЛЬНЫХ письмах, которые отправляются в бумажном виде и пишутся для фиксирования переломных моментов в проекте. Обычно к этому моменту вы уже «отстрелялись» пачкой e-mail всем специалистам, где нормальным языком все объяснили. И теперь надо вовремя ОФИЦИАЛЬНО доложить.
В целом же ход дискуссии мне нравится, было много ценных комментариев. Я больше всего переживал, что тема будет вовсе невостребована. Но нет, вижу, не один я «писатель». Про то, что есть книга о написании текстов, я, честно говоря, вообще слышу первый раз ( а то уже собирался свою сочинить :-) )
«я -> отдел тестирования» — хорошая схема. Когда в нее руководство вмешивается — это микроменеджмент называется, страшное зло :-) Руководство помогает в общении с заказчиком. Иногда, двум гендирам легче договориться чем, например, ПМ и начальнику отдела продаж. И вот тут время на решения проблемы сокращается, и сама проблема становится меньше. Ура настоящему директору!
Начальство всегда обвиняет ПМ, так и должно быть. Но все таки отчеты нужны, потому что степень ответственности в случае провала бывает разной. Если вы молча весь год все делали как считали нужным — тут ответственность выше, если вы свои шаги декларировали заранее — то последствия шагов будут для вас как правило мягче. Пишите отчеты. Пишите что уже сделано и что хотите сделать.
«Минусовый» проект, это проект, по которому ожидания (да ладно ожидания, а то и уверенность что «все уже есть»!) верховного руководства не соответствуют действительности. Это плохо, так нельзя, но так бывает. И тут попадаешь в забавную ситуацию, когда и скрывать правду нельзя, и выложить эту самую правду разом тоже неэффективно. А главное, за словами «все неправильно» надо обязательно тут же предложить внятный, укладывающийся в сроки план действий по спасению ситуации.
Я достаточно много встречал менеджеров проектов, которые таковыми себя не осознавали. И, как ни странно, справлялись. К примеру, в один прекрасный день пришел босс, показал пальцем на «самого умного» и сказал «ты главный». Чтоб было с кого спросить. Случаи разные бывают. Не надо так категорично «кто работал — кто не работал». Вопросы я писал не для того чтоб помочь «крутить носом» а, например, помочь кому то ответить на предложение «ты главный». Оценить свои шансы, и стоит ли предложенное вознаграждение необходимых трудов.
Вопрос 5 теряет свою важность по мере приобретения опыта управления. Но, на первых порах или при переходе на качественно новый уровень, способен «попортить кровь».
Вопрос 6 нужен для того чтобы вы не забыли ознакомиться с документацией, как она есть, и знали что от вас могут потребовать.
Вопрос 9 архиважный. Работа с отделом качества или без него — два разных стиля работы.
Вопрос 11 важный, но его наверное надо переформулировать. Я имел ввиду, что вам надо знать заранее на что способны ваши люди. Можете это узнать без чтения их резюме (а читая их исходный код) — вот и славно!
От начальства помимо постановки цели и сроков вам много еще чего может понадобиться, а начальству от вас — еще больше :-) Автономность менеджера — опасное заблуждение. Хотя бы раз в месяц ставьте в известность своих руководителей, пишите отчеты. Этим вы хоть как то разделите ответственность за принятые решения. Многие проблемы с заказчиком решаются именно через руководство. Далее, цели и сроки вам поставят четко, но надо же оценить их реалистичность. А уж влияние смежников ( отдел тестирования, отдел внедрения, отдел маркетинга, юридический отдел ) могут подкинуть и своих «обстоятельств».
Из минуса вытягивать сложнее, потому что результат нужен вчера. Сроки в контракте уже подошли, а неустойку платить никому не хочется. Причины провала вы за пару недель поймете, но придется достигать цели с тем продуктом, который есть и отвечать не только за свои, но и за чужие ошибки.
Сколько их, хороших но сокращенных специалистов? Где они? Трудности в кризис испытывают в первую очередь молодые и неопытные. А предприятия сокращают бюджеты проектов. И сроки, пока заказчик в состоянии платить.
Статья не о том, как понравиться работодателю, а о том как понять что работодатель вам нравится. И насколько. :-). Может вас и захотят «оторвать», только зачем вам самим это надо?
Если надо запустить проект «с нуля» — это ничего. Бывает что хотят запустить проект из отрицательной зоны. Понимаете?
Работу любите, нелюбимым делом заниматься горько, только менеджер работает в первую очередь не с uml-схемами, а с людьми в изменчивых условиях. В этом интерес и вся сложность работы. Потому надо уметь оценивать.
А насчет «работу менять не нужно» — ой не зарекайтесь, на дворе 2009 год. :-)
Факт! И таких проектов не так уж мало. Когда в разгар работы приходит менеджер по продажам и говорит что нашел кучу денег, но надо срочно делать прототип — моя команда садится и делает. И приходится забыть про текущий спринг, рассчитанный фокус-фактор… И с кураторами проектов мне проще торговаться за то, какие задачи сейчас отложить, чтоб сделать что то внезапно-срочное, чем доказывать что сначала надо закончить текущий спринг. И зачастую это единственнный выход!
Фокус-фактор штука мощная, когда она есть. Но, если в команде работают люди с сильно разной квалификацией, он превращается в среднюю температуру по палате.
Вопрос «будут ли ВСЕ важные запланированные задачи готовы к сроку поставки» не всегда является центральным. Подход может быть другим, например: «Вот задачи А, В, С. Скажите нам, что из них когда мы будем продавать». Получается поток задач и это не плохо само по себе. Всего лишь вопрос выбора бизнес-модели.
Впихивания задач в канбане не произойдет, если менеджер ( мы кстати о каком менеджере говорим? о менеджере продаж надеюсь? ) принимает условие, что количество открытых задач в потоке конечно, и чтобы что то добавить — надо что то убрать. Как оценить это количество? Тут фокус-фактор сам по себе меня никогда не спасал. На самом деле эту оценку всегда приходится проводить и доказывать заново, как только кому то надо подвинуть сроки или расширить объем работ. Можете считать индивидуальный фокус-фактор для каждого члена команды, и давать оценки в зависимости от того, кто конкретно будет делать работу.
А еще команда может пребывать в стадии Сна. :-) Но Такман об этом не знал.
Перечисленные риски не завершаются и не появляются от фазы к фазе. Они присутствуют практически все время. Например «Лидеру не удается удерживать в поле зрения все задачи, которыми необходимо заниматься параллельно». Не думайте, что вы расстанетесь с этим риском по прохождении фазы формирования :-)
www.vzzvzz.com/presentation-advice-to-beginner/
Однозначно, надо знать хотя бы один стандарт. Хотя бы в общих чертах.
Быть снобом на рынке не надо, но от некоторых сделок лучше отказываться, если понимаете что общий язык с клиентом не найдется.
Речь в статье шла об ОФИЦИАЛЬНЫХ письмах, которые отправляются в бумажном виде и пишутся для фиксирования переломных моментов в проекте. Обычно к этому моменту вы уже «отстрелялись» пачкой e-mail всем специалистам, где нормальным языком все объяснили. И теперь надо вовремя ОФИЦИАЛЬНО доложить.
В целом же ход дискуссии мне нравится, было много ценных комментариев. Я больше всего переживал, что тема будет вовсе невостребована. Но нет, вижу, не один я «писатель». Про то, что есть книга о написании текстов, я, честно говоря, вообще слышу первый раз ( а то уже собирался свою сочинить :-) )
Менеджер и программист — это разные профессии. Не надо их сталкивать
Начальство всегда обвиняет ПМ, так и должно быть. Но все таки отчеты нужны, потому что степень ответственности в случае провала бывает разной. Если вы молча весь год все делали как считали нужным — тут ответственность выше, если вы свои шаги декларировали заранее — то последствия шагов будут для вас как правило мягче. Пишите отчеты. Пишите что уже сделано и что хотите сделать.
«Минусовый» проект, это проект, по которому ожидания (да ладно ожидания, а то и уверенность что «все уже есть»!) верховного руководства не соответствуют действительности. Это плохо, так нельзя, но так бывает. И тут попадаешь в забавную ситуацию, когда и скрывать правду нельзя, и выложить эту самую правду разом тоже неэффективно. А главное, за словами «все неправильно» надо обязательно тут же предложить внятный, укладывающийся в сроки план действий по спасению ситуации.
Вопрос 5 теряет свою важность по мере приобретения опыта управления. Но, на первых порах или при переходе на качественно новый уровень, способен «попортить кровь».
Вопрос 6 нужен для того чтобы вы не забыли ознакомиться с документацией, как она есть, и знали что от вас могут потребовать.
Вопрос 9 архиважный. Работа с отделом качества или без него — два разных стиля работы.
Вопрос 11 важный, но его наверное надо переформулировать. Я имел ввиду, что вам надо знать заранее на что способны ваши люди. Можете это узнать без чтения их резюме (а читая их исходный код) — вот и славно!
Из минуса вытягивать сложнее, потому что результат нужен вчера. Сроки в контракте уже подошли, а неустойку платить никому не хочется. Причины провала вы за пару недель поймете, но придется достигать цели с тем продуктом, который есть и отвечать не только за свои, но и за чужие ошибки.
Сколько их, хороших но сокращенных специалистов? Где они? Трудности в кризис испытывают в первую очередь молодые и неопытные. А предприятия сокращают бюджеты проектов. И сроки, пока заказчик в состоянии платить.
Если надо запустить проект «с нуля» — это ничего. Бывает что хотят запустить проект из отрицательной зоны. Понимаете?
Работу любите, нелюбимым делом заниматься горько, только менеджер работает в первую очередь не с uml-схемами, а с людьми в изменчивых условиях. В этом интерес и вся сложность работы. Потому надо уметь оценивать.
А насчет «работу менять не нужно» — ой не зарекайтесь, на дворе 2009 год. :-)