А по моему - банально и фигня ;-) Курить вредно, не пейте кофе, питайтесь правильно, побольше двигайтесь, вставайте рано - спасибо за отличную статью :)
Если выбирать график я бы предпочел такой, когда меньше пересекаешься с основным траффиком людей, который как раз заточен под тот режим для что описан в статье. Айтишники обычно могут себе это позволить в отличие от других людей (обслуживание, производство, и т.д.), где график ж0сткий и утренний. Есть возможность выбрать именно продуктивный для себя режим и избегать проблем с трафиком.
Если по себе - то могу продуктивно работать или утром или поздно вечером-ночью. Это для той работы что не требует коммуникаций, а требует именно сосредоточения. Вечер-ночь иногда включает такое состояние мозга что можно сделать за один раз то, что если делать днем то надо 3-4 дня.
У меня сейчас как раз утренний режим: пока на работе никого нет - можно столько полезного сделать.
Не понимаю о чем тут вообще можно задумываться. Думаю евросеть очень заинтересована в том чтобы покупатели были довольны, а ее продавцы - вежливы и професиональны. Однако без обратной связи от покупателей не решить такие проблемы. Если вы сами забиваете, то такие ситуации будут повторятся с вами во всяких обслуживающих службах.
Не, так не интересно. Есть ли какой-нибудь план по по достижению прибыли? Например, покупаем 40 сковородок по 20р и продаем по 60р в результате получаем нужную прибыль. Вот когда есть план можно искать неопределенности, типа "у нас же никто не купит сковородки по 60р о_О".
Да нет, стратегий может быть несколько. Например идеально (и иногда получается) когда риск продается. Например, если стороней библиотекой поддерживается функционал, то время решения нашей задачи - 1 день, если не поддерживается - то 2 недели чтобы написать с нуля. Если изначально заложить в план 2 недели и заказчик соглашается - то можно считать что риск продан.
Лучше вы дайте пример определенности, с которой нельзя работать. Как только формируется описание неопределенности, так сразу придут на ум стратегии как можно с ней поступить, или как лучше разбить эту неопределенность на вероятные исходы. Высокоуровневые неопределенности вроде "проект не будет выполнен в срок" лучше не рассматривать.
Важно понимать что, что успех проекта может зависит от того или иного развития событий в рамках описанной неопределенности.
Любую неопределенность можно как-то определить что с ней можно работать. Если неопределенности возникают постоянно и неожиданно как на поле боя - ну значит такая среда, где важнее оперативное принятие решений. Думаю под управлением можно понимать такие неопределенности которые можно идентифицировать заблаговременно, и как-то с ними работать.
Риск вида "проект не будет сделан вовремя" обычно слишком выского уровня, чтобы с ним можно было иметь дела менеджеру проекта (хотя данная статья призвана помочь уменьшить вероятность именно такого риска). Это скорее риск для бизнеса заказывающего проект. Вообще нужно разделять эти роли, у бизнеса и у проекта могут быть противоположные интересы )
Примеры неопределенностей:
- через неделю становится понятно ложится ли человек в больницу на месяц или нет
- является ли third party код достаточно стабильных для использования в данном проекте
- интеграция с продуктом заказчика может занять неопределенное время.
Можно забить на все и действовать по ходу дела, действовать по наитию, а можно вести какую-нибудь формальную дейтельность вокруг этого как советуют светлые умы. Например, начинать попросить передать наиболее критичные знания другому разработчику, провести предварительное тестирование библиотеки, продать больше времени на интеграцию заказчику.
Я уверен что когда какие-нибудь крупные компании аутсорят проекты каким-нибудь крупным исполнителям риск мэнеджмент будет достаточно формальным, чтобы обе стороны знали что происходят с теми рисками которые известны и не вылезают ли какие-нибудь новые.
Ну такие эвристики из статьи больше подоходят для организаций типа где мне приходится работать. Вот случае когда на вход получаешь требования и нужно сказать когда будет готов результат и сколько это будет стоить, после чего нужно сделать по этой оценке.
Когда задача ставится таким образом, что надо успеть за месяц, то фактически никто за нее не отвечает. Что если задачу в принципе нельзя сделать за месяц? Кто согласился что сделает ее за месяц? Кто виноват если через месяц нет сайта?
Ну управление проектом и организация эффективного бизнеса разные вещи. В идеале компания должна предоставить среду для менеджера проектов, чтобы оне не думал про эти вещи, а работал в своем "проектном" мирке подключая ресурсы компании (исполнителей, сисадминов, юристов, и т.д.) когда необходимо. Эта задача уровня выше, чем выполнение какого-то конкретного проекта в срок.
Насчет второго примера: ну уж извините :) Это и есть планирование. Планирование задач может в часности осуществлятся на основе архитектурной декомпозиции, когда есть на высоком уровне понимание как задачи соотносятся между собой. Нужно закладывать время на интеграцию, нужно выделять задачи и готовить архитектуру таким образом, чтобы минимизировать издержки на коммуникацию, использовать технику непрерывной интеграции, и т.д.
Вообще если задача изначальна поставлена так что в течении месяца десяти программистам надо сделать сайт - это плохой сетап. Хороший сетап - когда ПМ получает хорошо оформленные требования (от заказчика, продукт менеджера, и т.д.), делает свою оценку по ним и отвечает за реализацию продукта на основе этих требований в рамках бюджета и в срок.
Почему бред? Под управлением рисками подразумевается вполне конкретный набор работ. Если минимально, то перед подготовкой плана проекта можно иметь список рисков и понимать что какие-то риски в случае их возникновения включены в план,а какие-то нет. Бывают конечно самые общие риски - вроде задача была недооценена, заняла больше времени чем предполагалась, и т.д. В данной статье как раз описано как минимизировать ущебр от этих рисков по проекту в целом. Бывают совершенно конкретные риски, которых ближе к концу проекта становится все меньше и меньше.
Вообще считается что уровень неопределенности к началу проекта высок, а к концу проекта низок. Когда неопределенностью управляют - это значит что у менеджера есть понимание того как именно она уменьшается )
В соответствии с PMBOK есть организации у которых образ действия операционный, а есть проектный. Насколько я понял по Вашим статьям у вас больше операционный образ действия, когда надо делать какую-то работу, а не то что называется проектом.
Про зависимости между задачами в этом статье не забывается. На счет остальных издержек мне не совсем понятно. Если есть риски связанные с тем что синхронизация отделов повлияет на сроки сдачи проекта, то с ними надо поступать как с обычными рисками, т.е. продавать, обходить, и т.д.
Другие издержки менеджеру проекта обычно не очень интересны, это больше к тем кто управляет финансами и портфелем проектов.
Если выбирать график я бы предпочел такой, когда меньше пересекаешься с основным траффиком людей, который как раз заточен под тот режим для что описан в статье. Айтишники обычно могут себе это позволить в отличие от других людей (обслуживание, производство, и т.д.), где график ж0сткий и утренний. Есть возможность выбрать именно продуктивный для себя режим и избегать проблем с трафиком.
Если по себе - то могу продуктивно работать или утром или поздно вечером-ночью. Это для той работы что не требует коммуникаций, а требует именно сосредоточения. Вечер-ночь иногда включает такое состояние мозга что можно сделать за один раз то, что если делать днем то надо 3-4 дня.
У меня сейчас как раз утренний режим: пока на работе никого нет - можно столько полезного сделать.
Важно понимать что, что успех проекта может зависит от того или иного развития событий в рамках описанной неопределенности.
Лично я имею в виду стандартные определения, которые можно например на википедии найти. http://en.wikipedia.org/wiki/Uncertainty, http://en.wikipedia.org/wiki/Risk_manage…
- через неделю становится понятно ложится ли человек в больницу на месяц или нет
- является ли third party код достаточно стабильных для использования в данном проекте
- интеграция с продуктом заказчика может занять неопределенное время.
Можно забить на все и действовать по ходу дела, действовать по наитию, а можно вести какую-нибудь формальную дейтельность вокруг этого как советуют светлые умы. Например, начинать попросить передать наиболее критичные знания другому разработчику, провести предварительное тестирование библиотеки, продать больше времени на интеграцию заказчику.
Я уверен что когда какие-нибудь крупные компании аутсорят проекты каким-нибудь крупным исполнителям риск мэнеджмент будет достаточно формальным, чтобы обе стороны знали что происходят с теми рисками которые известны и не вылезают ли какие-нибудь новые.
Когда задача ставится таким образом, что надо успеть за месяц, то фактически никто за нее не отвечает. Что если задачу в принципе нельзя сделать за месяц? Кто согласился что сделает ее за месяц? Кто виноват если через месяц нет сайта?
Насчет второго примера: ну уж извините :) Это и есть планирование. Планирование задач может в часности осуществлятся на основе архитектурной декомпозиции, когда есть на высоком уровне понимание как задачи соотносятся между собой. Нужно закладывать время на интеграцию, нужно выделять задачи и готовить архитектуру таким образом, чтобы минимизировать издержки на коммуникацию, использовать технику непрерывной интеграции, и т.д.
Вообще если задача изначальна поставлена так что в течении месяца десяти программистам надо сделать сайт - это плохой сетап. Хороший сетап - когда ПМ получает хорошо оформленные требования (от заказчика, продукт менеджера, и т.д.), делает свою оценку по ним и отвечает за реализацию продукта на основе этих требований в рамках бюджета и в срок.
Вообще считается что уровень неопределенности к началу проекта высок, а к концу проекта низок. Когда неопределенностью управляют - это значит что у менеджера есть понимание того как именно она уменьшается )
Про зависимости между задачами в этом статье не забывается. На счет остальных издержек мне не совсем понятно. Если есть риски связанные с тем что синхронизация отделов повлияет на сроки сдачи проекта, то с ними надо поступать как с обычными рисками, т.е. продавать, обходить, и т.д.
Другие издержки менеджеру проекта обычно не очень интересны, это больше к тем кто управляет финансами и портфелем проектов.