Как я понимаю, основное отличие от привычных нам функциональных структур заключается в отрыве лид и реп-линков друг от друга (то есть от одного человека — начальника подразделения).
Ну а нормально построить процессную работу и нанять вменяемых людей — задача, не теряющая актуальности и при холакратии.
Могу посоветовать время на планирование/разбор/проектирование и тп. выделять в отдельную задачу. После ее завершения планировать саму разработку.
В самом отличии факта от плана нет ничего необычного. Главное, не упускать это из виду и по возможности принимать меры по минимизации разницы. Последний ваш пример как раз про разницу плана и факта, причем существенную) Но там есть нюанс: кто определил трудоемкость задачи? Как он это сделал? Вполне возможно, что для целей тестирования декларированная трудоемкость была занижена.
Как выяснилось, слова «самбик» (самолет по-детски) и «мастерка» («олимпийка», спортивная кофта с рукавами на молнии) в Москве немногие знают. На юге, как мне кажется, многие.
Первый косяк лично для меня самый значимый. Реально неудобно, когда громкость одна на всю систему. Мне кажется, давно пора прислушаться к пользователям, наверняка, значительный их процент хотел бы видеть раздельные регуляторы.
Ну и проблема с длиной темы письма в почте гугл. Больше 20 символов в теме — адресат получает кашу из символов. И вроде бы это Гугл виноват, но разве это важно пользователям? Почините уже, пусть даже каким-то временным решением…
Тоже не совсем понял позицию автора. Некоторые ругают диаграмму Гантта, а по мне это довольно удобный инструмент. Здесь, во-первых, планирование не должно опираться только на математику или статистику, должна быть доля здравого человеческого смысла (который должен быть у менеджера проектов). А во-вторых, расчет верен, только если у нас по одному исполнителю на каждый вид работ и работаем мы по жесткому «водопаду».
В целом советую интересующимся читать Риту Мулкахи. PMBok при этом можно вообще не читать. Это здорово приводит в порядок мысли. А PMBok суховат для изучения.
В управлении проектами, как и других областях, можно выделить некое «научное ядро». И смысл изучения его в том, чтобы каждодневные ситуации сводить к конкретному набору сущностей, с которыми наука управления проектами уже знает, как работать. Надеюсь, понятно получилось)
А можете кинуть ссылку на какой-нибудь внятный текст, где описано, в чем же заключается эта существенная разница? Давно хотел понять, да никто не мог объяснить.
ПС Автору за статью спасибо. Многое из сказанного подтверждено и моим опытом.
явно дело в цифрах. Пока не пойму, учитывать ли двух программистов и семимильные шаги. Скорее всего, нет. Приведенные числа указаны с ошибками. Это беглый анализ показал, я, к сожалению, на работе)
У коллеги был случай: Альфа потребовала вернуть 9000 р. стоимости услуг Альфа-Чек + пени за большой срок. Карта давно закончилась, но услуга продолжала потреблять деньги. В итоге все благополучно закончилось претензией на тему невидимой и ненужной услуги и уплатой 180 р.
Самый большой вопрос в том, как оценить ИТ-проекты с не столь явными профитами, как торты или посетители. Например, инфраструктурные проекты в крупной компании.
Хочется спросить у BegeMode: а реальными проектами по методике ЛИНК вы управляли? Насколько они были успешными? Могу точно сказать, что на практике указанные Магнусом нюансы имеют большую ценность, так как помогают найти выход в тумане. PMBOK — хоть и теория, но без лишнего. И еще большую практическую ценность имеют, на мой взгляд, ее «трактовки» вроде книжки Rita Mulcahy.
Ну а нормально построить процессную работу и нанять вменяемых людей — задача, не теряющая актуальности и при холакратии.
В самом отличии факта от плана нет ничего необычного. Главное, не упускать это из виду и по возможности принимать меры по минимизации разницы. Последний ваш пример как раз про разницу плана и факта, причем существенную) Но там есть нюанс: кто определил трудоемкость задачи? Как он это сделал? Вполне возможно, что для целей тестирования декларированная трудоемкость была занижена.
Ну и проблема с длиной темы письма в почте гугл. Больше 20 символов в теме — адресат получает кашу из символов. И вроде бы это Гугл виноват, но разве это важно пользователям? Почините уже, пусть даже каким-то временным решением…
В управлении проектами, как и других областях, можно выделить некое «научное ядро». И смысл изучения его в том, чтобы каждодневные ситуации сводить к конкретному набору сущностей, с которыми наука управления проектами уже знает, как работать. Надеюсь, понятно получилось)
ПС Автору за статью спасибо. Многое из сказанного подтверждено и моим опытом.