Здравствуйте, Gaperton,

Вот здесь я бы не согласился с уважаемым Gaperton'ом.
Если в ходе решения задачи обнаружились непредвиденные проблемы (действительно непредвиденные, а не просто срок не выдержан потому, что девелопер тупо пинал балду на рабочем месте) — девелопер сразу же, в тот же день должен довести это до менеджера, и этот самый "плановый срок" должен быть пересчитан. Адекватный менеджер так и сделает. Неадекватный же.... думаю, обсуждать бессмысленно — для неадекватного менеджера любая задача должна быть выполнена "еще вчера". Хотя, я согласен, что этот механизм действительно более поощряет решение простых и низкорискованных задач с предсказуемым результатом. Что, впрочем, не мешает менеджеру сразу закладывать в [озвученные руководству] сроки "коэффициент каверзности задачи" — именно для сложных задач.
Касаемо "супернадежного перезаклада по срокам, с выносом мозга начальству" — это проходит только с весьма начинающими менеджерами. Более опытные могут предсказать сроки даже точнее разработчиков
Далее. Баги, оставшиеся в продукте/компоненте/etc. после выпуска релиза — это действительно показатель качества его исполнения. А вот развитие продукта/компонента, реализация новых фич/пожеланий пользователей и/или маркетологов — это уже другая задача, по моему пониманию это уже не может входить в "коэффициент поддержки закрытой задачи".

В общем, весь вопрос в применении данного инструмента, — ведь и штык-ножом того же АК можно резать тушенку, а можно — людей....

Кстати, я согласен с коллегой nvb в следующем: "внедрение KPI для программистов — ритуальная жертва, приносимая их непосредственным начальником руководству компании, которое считает, что программисты сидят и целыми днями валяют дурака. Внедри KPI у себя в подразделении — и от тебя на полгода отвяжутся." Также согласен и со всеми следствиями из упомянутой затеи, — бо программисты (да и не только) отлично умеют искать и максимизировать локальные максимумы

Здравствуйте, Vlad_SP, Вы писали:

V_S>Здравствуйте, Gaperton,

V_S>Вот здесь я бы не согласился с уважаемым Gaperton'ом.
V_S>Если в ходе решения задачи обнаружились непредвиденные проблемы (действительно непредвиденные, а не просто срок не выдержан потому, что девелопер тупо пинал балду на рабочем месте) — девелопер сразу же, в тот же день должен довести это до менеджера, и этот самый "плановый срок" должен быть пересчитан. Адекватный менеджер так и сделает. Неадекватный же.... думаю, обсуждать бессмысленно — для неадекватного менеджера любая задача должна быть выполнена "еще вчера". Хотя, я согласен, что этот механизм действительно более поощряет решение простых и низкорискованных задач с предсказуемым результатом. Что, впрочем, не мешает менеджеру сразу закладывать в [озвученные руководству] сроки "коэффициент каверзности задачи" — именно для сложных задач.
V_S>Касаемо "супернадежного перезаклада по срокам, с выносом мозга начальству" — это проходит только с весьма начинающими менеджерами. Более опытные могут предсказать сроки даже точнее разработчиков
V_S>Далее. Баги, оставшиеся в продукте/компоненте/etc. после выпуска релиза — это действительно показатель качества его исполнения. А вот развитие продукта/компонента, реализация новых фич/пожеланий пользователей и/или маркетологов — это уже другая задача, по моему пониманию это уже не может входить в "коэффициент поддержки закрытой задачи".

V_S>В общем, весь вопрос в применении данного инструмента, — ведь и штык-ножом того же АК можно резать тушенку, а можно — людей....

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

Здравствуйте, nvb,

ну так в чем проблема-то — высказаться?

Здравствуйте, Vlad_SP, Вы писали:

V_S>Здравствуйте, Gaperton,

V_S>Вот здесь я бы не согласился с уважаемым Gaperton'ом.
V_S>Если в ходе решения задачи обнаружились непредвиденные проблемы (действительно непредвиденные, а не просто срок не выдержан потому, что девелопер тупо пинал балду на рабочем месте) — девелопер сразу же, в тот же день должен довести это до менеджера, и этот самый "плановый срок" должен быть пересчитан. Адекватный менеджер так и сделает. Неадекватный же.... думаю, обсуждать бессмысленно — для неадекватного менеджера любая задача должна быть выполнена "еще вчера".

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

Если адекватный менеджер по каждому такому случаю будет адекватно переносить срок, то "объективность" данного показателя сведется субъективному к выбору менеджера в каждом конкретном случае, пинает человек балду или нет. Что ровно так же и происходит и без данного показателя. А это никакой не не KPI. См сабж темы — обсуждается именно это.

V_S>Касаемо "супернадежного перезаклада по срокам, с выносом мозга начальству" — это проходит только с весьма начинающими менеджерами. Более опытные могут предсказать сроки даже точнее разработчиков

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

Если вы хотите иметь адекватные прогнозы сроков, и хотите, чтобы вам разработчики говорили правду — категорически запрещено закладывать характеристики прогноза в KPI. Категорически. Нельзя мотивировать людей врать.

V_S>Далее. Баги, оставшиеся в продукте/компоненте/etc. после выпуска релиза — это действительно показатель качества его исполнения. А вот развитие продукта/компонента, реализация новых фич/пожеланий пользователей и/или маркетологов — это уже другая задача, по моему пониманию это уже не может входить в "коэффициент поддержки закрытой задачи".

Второе, вы похоже пропустили то, что я сказал. Количество найденных багов пользователем зависит не только от количества внесенных программистом, но и от:
1) Качества процедур тестирования у вас в компании. Вообще-то баги находить — это их работа, и если они прошли в релиз — в этом виноват не программист.
2) Сложности логики. Чем сложнее — тем больше багов, и сложнее тестирование.
3) Количества пользователей. Чем больше пользователей, чем активнее они используют модуль — тем больше багов найдут.

Данный показатель характеризует, помимо "качества исполнения", еще и данных три пункта. Что делать будем?

V_S>В общем, весь вопрос в применении данного инструмента, — ведь и штык-ножом того же АК можно резать тушенку, а можно — людей....

Это не инструмент для KPI. Для обсуждаемого применения он не пригоден. Метрики вообще не игрушка. Практика их употребления часто напоминает "маленький мальчик нашел пулемет — больше в деревне никто не живет".

V_S>Кстати, я согласен с коллегой nvb в следующем: "внедрение KPI для программистов — ритуальная жертва, приносимая их непосредственным начальником руководству компании, которое считает, что программисты сидят и целыми днями валяют дурака. Внедри KPI у себя в подразделении — и от тебя на полгода отвяжутся."

Да, а еще можно кого-нибудь уволить в качестве ритуальной жертвы. Или оштрафовать. Свои косяки в планировании и организации работ на кого-нибудь свалить. И от тебя тоже отвяжутся.

Здравствуйте, Vlad_SP, Вы писали:

V_S>ну так в чем проблема-то — высказаться?

Ну ладно — уговорили

V_S>Если в ходе решения задачи обнаружились непредвиденные проблемы (действительно непредвиденные, а не просто срок не выдержан потому, что девелопер тупо пинал балду на рабочем месте) — девелопер сразу же, в тот же день должен довести это до менеджера, и этот самый "плановый срок" должен быть пересчитан.

Есть некоторая разница между "должен" и "реально делает". Если бы девелоперы репортили проблемы менеджеру в день их появления, число проваленных проектов было бы на порядок меньше. Бяка в том, что девелоперы молчат о проблемах до тех пор, пока их об этом напрямую не спросишь, или дальше уже молчать невозможно из-за опасности для собственной задницы.

V_S>Адекватный менеджер так и сделает. Неадекватный же.... думаю, обсуждать бессмысленно — для неадекватного менеджера любая задача должна быть выполнена "еще вчера". Хотя, я согласен, что этот механизм действительно более поощряет решение простых и низкорискованных задач с предсказуемым результатом. Что, впрочем, не мешает менеджеру сразу закладывать в [озвученные руководству] сроки "коэффициент каверзности задачи" — именно для сложных задач.
V_S>Касаемо "супернадежного перезаклада по срокам, с выносом мозга начальству" — это проходит только с весьма начинающими менеджерами. Более опытные могут предсказать сроки даже точнее разработчиков

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

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

В-третьих, менеджер проекта не обязан быть экспертом в написании кода. У РМа с избытком хватает других задач, и чем больше он менеджер, тем меньше он программист. И даже если он действительно эксперт, он провалит проект, если будет тратить время на объяснение, как именно надо реализовать тот или иной функционал в каждой задаче — это называется микроменеджмент. Если уж есть неодолимое желание ущучить разработчика за сроки, можно попросить об этом архитектора, но... см.выше.

V_S>Далее. Баги, оставшиеся в продукте/компоненте/etc. после выпуска релиза — это действительно показатель качества его исполнения. А вот развитие продукта/компонента, реализация новых фич/пожеланий пользователей и/или маркетологов — это уже другая задача, по моему пониманию это уже не может входить в "коэффициент поддержки закрытой задачи".

А при чем тут новые фичи? О них вроде речи не шло.

Здравствуйте, Gaperton, Вы писали:

V_S>>Кстати, я согласен с коллегой nvb в следующем: "внедрение KPI для программистов — ритуальная жертва, приносимая их непосредственным начальником руководству компании, которое считает, что программисты сидят и целыми днями валяют дурака. Внедри KPI у себя в подразделении — и от тебя на полгода отвяжутся."

G>Да, а еще можно кого-нибудь уволить в качестве ритуальной жертвы. Или оштрафовать. Свои косяки в планировании и организации работ на кого-нибудь свалить. И от тебя тоже отвяжутся.

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

Здравствуйте, Gaperton, Вы писали:

G>Если вы хотите иметь адекватные прогнозы сроков, и хотите, чтобы вам разработчики говорили правду — категорически запрещено закладывать характеристики прогноза в KPI. Категорически. Нельзя мотивировать людей врать.

Эххх...... Истинная правда! Твои бы слова да довести до этих самых руками-водителей.... Да вот только происходит чаще всего — с точностью до наоборот.

Здравствуйте, nvb, Вы писали:

V_S>>>Кстати, я согласен с коллегой nvb в следующем: "внедрение KPI для программистов — ритуальная жертва, приносимая их непосредственным начальником руководству компании, которое считает, что программисты сидят и целыми днями валяют дурака. Внедри KPI у себя в подразделении — и от тебя на полгода отвяжутся."

G>>Да, а еще можно кого-нибудь уволить в качестве ритуальной жертвы. Или оштрафовать. Свои косяки в планировании и организации работ на кого-нибудь свалить. И от тебя тоже отвяжутся.

nvb>От организации зависит. Если бы я сказал на совещании у своего прежнего руководства "Вот в моем проекте из-за раздолбая Васи сорвались сроки сдачи этапа, давайте его оштрафуем" — меня бы уволили тут же. Или от работы с людьми отстранили бы, но скорее всего, первое.

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

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, nvb, Вы писали:

V_S>>>>Кстати, я согласен с коллегой nvb в следующем: "внедрение KPI для программистов — ритуальная жертва, приносимая их непосредственным начальником руководству компании, которое считает, что программисты сидят и целыми днями валяют дурака. Внедри KPI у себя в подразделении — и от тебя на полгода отвяжутся."

G>>>Да, а еще можно кого-нибудь уволить в качестве ритуальной жертвы. Или оштрафовать. Свои косяки в планировании и организации работ на кого-нибудь свалить. И от тебя тоже отвяжутся.

nvb>>От организации зависит. Если бы я сказал на совещании у своего прежнего руководства "Вот в моем проекте из-за раздолбая Васи сорвались сроки сдачи этапа, давайте его оштрафуем" — меня бы уволили тут же. Или от работы с людьми отстранили бы, но скорее всего, первое.

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

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

А откуда взялось "все прощелкать"? Вроде я говорил о "руководстве компании, которое считает, что программисты сидят и целыми днями валяют дурака". Конечно, внедрение KPI может инициироваться провалом проекта, но обычно это вытекает из более позитивных намерений — либо дань моде, либо подготовка фирмы к продаже, либо воспоминания вчерашней пьянки с директором какого-нибудь call-центра, который хвалился, как у него затраты на персонал уменьшились.

И отвязаться можно тоже более позитивно. Например, предложить (вроде в шутку, но в присутствии директора) ответственному за внедрение KPI составить мотивационную схему, которая различает, скажем, Пушкина и Юру Шатунова. И соглашаться на внедрение в своем подразделении только после доказательства корректности данной схемы или объяснения (РМу! ха-ха!) разницы между поэтом и программистом.

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

Здравствуйте, nvb, Вы писали:

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

nvb>Выяснить виноват менеджер или нет — не очень сложно. Его действия проверяются на предмет соответствия бизнес-процессам, принятым в компании, обычно этого достаточно. Менеджеры разные бывают, и их начальники тоже, давай сойдемся на этом

Что на этом сходится. Я же написал — в _некоторых_ организациях.

А вот проверка на соответствие действий менеджера принятым бизнес-процессам — это прикольно . Предполагается, что правильность действий менеджера определяется точностью выполнения им некоего алгоритма, принятого в компании. Любопытный взгляд на вещи .

nvb>А откуда взялось "все прощелкать"? Вроде я говорил о "руководстве компании, которое считает, что программисты сидят и целыми днями валяют дурака".

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

nvb> Конечно, внедрение KPI может инициироваться провалом проекта, но обычно это вытекает из более позитивных намерений — либо дань моде, либо подготовка фирмы к продаже, либо воспоминания вчерашней пьянки с директором какого-нибудь call-центра, который хвалился, как у него затраты на персонал уменьшились.

По моему, перечисленное не является более позитивным. Оно является более идиотичным. Если в первом случае хотя-бы наличествует проблема, которую пытаются решить идиотским способом, то во втором даже нет никакой конкретной проблемы, наличествует одно вредительство из любви к искусству.

nvb>И отвязаться можно тоже более позитивно. Например, предложить (вроде в шутку, но в присутствии директора) ответственному за внедрение KPI составить мотивационную схему, которая различает, скажем, Пушкина и Юру Шатунова. И соглашаться на внедрение в своем подразделении только после доказательства корректности данной схемы или объяснения (РМу! ха-ха!) разницы между поэтом и программистом.

У вас странные представления о позитивности, коллега.

nvb>Но большинство, увы, соглашается на эту ритуальную жертву, которая кажется вначале такой маленькой. Собственно, в ветке и говорится о том, что делать этого нельзя — будет хуже.

"Большинство", увы, не брезгует довольно широким спектром малодушного поведения, чтобы избежать отвественности и переложить ее на исполнителей. То, что вы называете "ритуальная жертва" — один из примеров переноса ответственности. Да, делается это всегда с красивыми словами. Суть остается.

Здравствуйте, Vlad_SP, Вы писали:

G>>Если вы хотите иметь адекватные прогнозы сроков, и хотите, чтобы вам разработчики говорили правду — категорически запрещено закладывать характеристики прогноза в KPI. Категорически. Нельзя мотивировать людей врать.

V_S>Эххх...... Истинная правда! Твои бы слова да довести до этих самых руками-водителей.... Да вот только происходит чаще всего — с точностью до наоборот.

Вообще, я на своей лекции по планированию всегда это довожу, когда рассказываю про метрики . Недавно исполнил ее на бис на Software People, заменял внезапно исчезнувшего докладчика. Видео этого доклада должно быть на сайте. Тему вреда использования метрик в KPI можно раскрыть и более подробно, впрочем.

Скажем, привести результаты исследования, предпринятого когда-то у нас в CQG. Там менеджмент пробовал разные формы KPI, и достаточно научным образом установил, что чтобы они ни выбирали, программисты всегда в течении нескольких месяцев учатся показатель загонять в максимум. Благо не идиоты.

Или же, можно сослаться на самую фошыстскую методологию PSP/TSP, которая явно _запрещает_ менеджерам _видеть_ _все_ персональные статистики сотрудников — только агрегаты по группе.

Здравствуйте, nvb, Вы писали:

nvb>Есть некоторая разница между "должен" и "реально делает". Если бы девелоперы репортили проблемы менеджеру в день их появления, число проваленных проектов было бы на порядок меньше. Бяка в том, что девелоперы молчат о проблемах до тех пор, пока их об этом напрямую не спросишь, или дальше уже молчать невозможно из-за опасности для собственной задницы.

По моему опыту подобное встречается в основном при кретине-манагере, который начинает вести себя неадекватно, когда слышит такие новости. Естесственно, к такому никто не пойдёт, пока не "припрёт". Особенно смешно выглядели попытки одного такого "манагера" "поговорить по душам" с разрабами Крик из конфрума начинает доноситься через 5-10 минут после начала разговора Откровенно говоря, за всё время работы в Москве я встречал только одного ПМа, с которым работать было одно удовольствие. Все остальные были более или менее склонны к истерическим реакциям на такие новости, хотя по идее им стоило бы благодарить разработчиков за своевременные сообщение...

Здравствуйте, Gaperton, Вы писали:

nvb>>Выяснить виноват менеджер или нет — не очень сложно. Его действия проверяются на предмет соответствия бизнес-процессам, принятым в компании, обычно этого достаточно. Менеджеры разные бывают, и их начальники тоже, давай сойдемся на этом

G>Что на этом сходится. Я же написал — в _некоторых_ организациях.

G>А вот проверка на соответствие действий менеджера принятым бизнес-процессам — это прикольно . Предполагается, что правильность действий менеджера определяется точностью выполнения им некоего алгоритма, принятого в компании. Любопытный взгляд на вещи .

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

Берем начинающего менеджера. Он провалил сроки, из-за чего на компанию наложили штрафные санкции. Разбор полетов. Первый же вопрос к менеджеру: покажи список рисков. Нет? Понятно. А п.7.3 инструкции "Порядок выполнения проектов в компании ХХХ" ты читал? Почитай, узнаешь много интересного. Система упала перед самой сдачей? Покажи логи регрессионных тестов. Что, таких тестов вообще нет? Жаль, п.8.4 об этом явно говорит. Ну хорошо, а просто откатить систему назад было нельзя? Что значит — Вася Пупкин вообще не коммитил свои результаты под версионный контроль? См. п.5.1, это проблема не Васи, а твоя. Ах, заказчик выставил кучу дополнительных требований и это потребовало времени? А как он их выставил? Какой-то инженер от заказчика по телефону периодически звонил и просил? А в п.3.4 черным по белому написано, что дополнительные требования принимаются только письмом, только от руководителя проекта со стороны заказчика и должны перед реализацией проходить через нашу систему управления требованиями. Можно посмотреть на то, что ты в эту систему внес? Там пусто? Надо же... Ну и так далее.

Понятно, что в большинстве случаев реально виноват не наш начинающий менеджер, а те люди, которые его не контролировали и не обучали его действовать по этой инструкции — у него-то самого опыта пока нет. Но такой разбор полетов, по крайней мере, лучше, чем "Что, сроки провалил? Урезаю зарплату на треть. В следующий раз уволю. Все, пока." Потому что в первом случае он внимательнейшим образом прочитает — наконец-то — эту инструкцию и в следующем его проекте глупых ошибок будет существенно меньше. И винить он будет, большей частью, себя. А во втором случае... ну, мы не дети и понимаем, что возможна куча вариантов, которые для компании негативны все, как на подбор.

nvb>>А откуда взялось "все прощелкать"? Вроде я говорил о "руководстве компании, которое считает, что программисты сидят и целыми днями валяют дурака".

G>Из этого следует, что руководство компании не понимает, чем заняты программисты, и лишены контроля над ситуацией. Сложно что-нибудь не "прощелкать" при таком подходе и взгляде на вещи.

Если взять не чисто программисткую компанию, а, например, Русал или Газпром — такая ситуация является совершенно нормальной. Когда "Мороз-воевода дозором обходит владенья свои", скажем, в 9 утра, вряд ли он застанет всех программистов на рабочем месте, за чем последуют оргвыводы.

nvb>> Конечно, внедрение KPI может инициироваться провалом проекта, но обычно это вытекает из более позитивных намерений — либо дань моде, либо подготовка фирмы к продаже, либо воспоминания вчерашней пьянки с директором какого-нибудь call-центра, который хвалился, как у него затраты на персонал уменьшились.

G>По моему, перечисленное не является более позитивным. Оно является более идиотичным. Если в первом случае хотя-бы наличествует проблема, которую пытаются решить идиотским способом, то во втором даже нет никакой конкретной проблемы, наличествует одно вредительство из любви к искусству.

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

nvb>>Но большинство, увы, соглашается на эту ритуальную жертву, которая кажется вначале такой маленькой. Собственно, в ветке и говорится о том, что делать этого нельзя — будет хуже.

G>"Большинство", увы, не брезгует довольно широким спектром малодушного поведения, чтобы избежать отвественности и переложить ее на исполнителей. То, что вы называете "ритуальная жертва" — один из примеров переноса ответственности. Да, делается это всегда с красивыми словами. Суть остается.

Вот уж с чем спорить не буду — так с этим утверждением.

Здравствуйте, nvb, Вы писали:

G>>А вот проверка на соответствие действий менеджера принятым бизнес-процессам — это прикольно . Предполагается, что правильность действий менеджера определяется точностью выполнения им некоего алгоритма, принятого в компании. Любопытный взгляд на вещи .

nvb>Да, ибо чтобы судить о правильности или неправильности действий индивида в определенной среде, требуется фиксированный и общепринятый эталон, с которым сверяются действия этого индивида. Закон, должностная инструкция, моральный кодекс строителя коммунизма, черная библия — смотря в какой среде рассматриваются действия. Это исключает взаимные обиды и перевод разговора о проблемах в дискуссии о том, что есть добро и что есть зло — как у нас с тобой сейчас

"Индивида", "определенной среде"... Слова-то какие умные, хосподи. Верный признак незамысловатой мысли, Вы уж меня простите. Но это так. "Умняк" с терминологией включают для маскировки, а не для объяснения.

Результат оценивать, а не соответствие действий "общепринятому алгоритму", которого нет — не приходила такая свежая и неожиданная мысль в голову?

И кстати, меня совершенно не интересуют вопросы добра и зла. Меня интересуют вопросы эффективности управления.

nvb>Берем начинающего менеджера.

Берем.

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

Что именно вам понятно, не объясните? А теперь допустим, что он есть. И что? Ну есть он, "а х-ли толку", как говорили в одном их анекдотов? Как будто наличие какой-то бумажки означает, что человек проанализировал угрозы, и выработал адекватный план с их учетом. И если его нет, это также не означает, что план не учитывал угроз. Это то же самое, что думать, что архитектура будет хорошая и адекватная, если ее описание вбить в руповский шаблон.

Давай я задам другой вопрос — кто проверял план, когда он был готов? В "инструкции" про это ничего не было сказано? А почему?

nvb> А п.7.3 инструкции "Порядок выполнения проектов в компании ХХХ" ты читал? Почитай, узнаешь много интересного.

О, а мне понятно. Исполнение "инструкций" надо проверять _до_ окончания проекта провалом, уважаемый коллега. Либо выбросить их в топку.

nvb>Понятно, что в большинстве случаев реально виноват не наш начинающий менеджер, а те люди, которые его не контролировали и не обучали его действовать по этой инструкции — у него-то самого опыта пока нет. Но такой разбор полетов, по крайней мере, лучше, чем "Что, сроки провалил? Урезаю зарплату на треть. В следующий раз уволю. Все, пока."

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

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

Какая вера в силу инструкций . Удивительное рядом. Можно пример такой инструкции с Вашей работы, коллега?

nvb>>>А откуда взялось "все прощелкать"? Вроде я говорил о "руководстве компании, которое считает, что программисты сидят и целыми днями валяют дурака".

G>>Из этого следует, что руководство компании не понимает, чем заняты программисты, и лишены контроля над ситуацией. Сложно что-нибудь не "прощелкать" при таком подходе и взгляде на вещи.

nvb>Если взять не чисто программисткую компанию, а, например, Русал или Газпром — такая ситуация является совершенно нормальной. Когда "Мороз-воевода дозором обходит владенья свои", скажем, в 9 утра, вряд ли он застанет всех программистов на рабочем месте, за чем последуют оргвыводы.

Из этого по-прежнему следует, что руководство компании не понимает, чем заняты программисты, и лишены контроля над ситуацией. Сложно что-нибудь не "прощелкать" при таком подходе и взгляде на вещи. Даже если это Русал или Газпром.

G>>По моему, перечисленное не является более позитивным. Оно является более идиотичным. Если в первом случае хотя-бы наличествует проблема, которую пытаются решить идиотским способом, то во втором даже нет никакой конкретной проблемы, наличествует одно вредительство из любви к искусству.

nvb>Это с нашей точки зрения. У руководства компании могут быть другие мнения. Оно создало — в отличие от нас с тобой — свои фирмы и ими управляет так, как считает нужным.

Это с моей точки зрения. Комментирую я не слова воображаемого руководства компании, а твои слова.

Здравствуйте, Gaperton, Вы писали:

G>Результат оценивать, а не соответствие действий "общепринятому алгоритму", которого нет — не приходила такая свежая и неожиданная мысль в голову?

Ну, вы же сами сказали — прощелкал. Вот и оцениваем этот результат.

nvb>>Берем начинающего менеджера.

G>Берем.

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

G>Что именно вам понятно, не объясните? А теперь допустим, что он есть. И что? Ну есть он, "а х-ли толку", как говорили в одном их анекдотов? Как будто наличие какой-то бумажки означает, что человек проанализировал угрозы, и выработал адекватный план с их учетом. И если его нет, это также не означает, что план не учитывал угроз. Это то же самое, что думать, что архитектура будет хорошая и адекватная, если ее описание вбить в руповский шаблон.

Конечно, не означает. Это означает лишь то, что риски и архитектура были визуализированы — то есть доступны для оценки и просмотра другим, более опытным человеком, и авторизованы им. Или не авторизованы. Или не просмотрены. Трудно залезть в мозги другому человеку, проще посмотреть на документ.

Да и самому РМу полезно такой документ иметь — правило 7+-2 никто не отменял. Это очень много значит.

Это первое. Второе — если уж брать нормальную компанию, в ней обычно хранятся списки проблем по прошлым проектам, которые переносятся в списки рисков на будущие проекты. Например, отказ заказчика оплачивать доп.изменения. Или, что одно и то же, полная апатия заказчика до окончания проекта и масса требований переделок по его завершению... да куча всего, вплоть до пофигизма юридического отдела. Совершенно не факт, что все проблемы из прошлого проекта перенесутся в будущий, но знать-то о них надо. И помнить надо. И учитывать надо. Я, например, честно признаюсь, не помню многих рисков из своих прошлых проектов — вот вчера на собеседовании обнаружилось . Сунуть новичку этот список под нос и потребовать составить для своего проекта подобный с учетом имеющихся данных — какой от этого вред, кроме пользы, как вы выражаетесь?

G>Давай я задам другой вопрос — кто проверял план, когда он был готов? В "инструкции" про это ничего не было сказано? А почему?

nvb>> А п.7.3 инструкции "Порядок выполнения проектов в компании ХХХ" ты читал? Почитай, узнаешь много интересного.

G>О, а мне понятно. Исполнение "инструкций" надо проверять _до_ окончания проекта провалом, уважаемый коллега. Либо выбросить их в топку.

nvb>>Понятно, что в большинстве случаев реально виноват не наш начинающий менеджер, а те люди, которые его не контролировали и не обучали его действовать по этой инструкции — у него-то самого опыта пока нет. Но такой разбор полетов, по крайней мере, лучше, чем "Что, сроки провалил? Урезаю зарплату на треть. В следующий раз уволю. Все, пока."

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

Готов подписаться под этими вашими словами.

G>И разумеется, процедуры не гарантируют ровным счетом ничего касательно успеха проекта и его срока — процесс вероятностный.

Естественно, и процедуры смещают матожидание в сторону успеха. На сколько процентов — вот это вопрос спорный, и на него ответа нет.

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

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

G>Какая вера в силу инструкций . Удивительное рядом. Можно пример такой инструкции с Вашей работы, коллега?

Нет!!! Это страшно подумать, что тут начнется, если будем ее обсуждать

Да нет у меня никакой веры в силу инструкций. Есть разные методы передачи знаний, культуры проектной деятельности и разные методы контроля. Ясное дело, при личном общении все это происходит на порядок быстрее и качественнее, чем при формальном "Читай ГОСТ, там все написано". Вы мне это пытаетесь доказать? Так я согласен.

Теперь зайдем с другой стороны. Еще кейс. Возьмем пару свежеиспеченных, со студенческой скамьи, РМов. Один не имел архитектуры нигде, кроме как в своей голове (проект маленький, архитектора нет), тупо реализовывал все требования заказчика, никак не учитывал риски, забил на промежуточное тестирование и держал черт-те-знает-где код. Второй же, по крайней мере, пытался следовать формальным процедурам, которые писали успешные менеджеры проектов. Контроля сверху в процессе почти нет — это не CQG и не Люксофт, это, скажем, Газпром.

Вопрос: у кого будет больше вероятность успешного завершения проекта? Не гарантия, а вероятность?

Здравствуйте, nvb, Вы писали:

nvb>Например, отказ заказчика оплачивать доп.изменения. Или, что одно и то же, полная апатия заказчика до окончания проекта и масса требований переделок по его завершению...

А как вообще бороться с такими рисками? Закладывать в стоимость решения? Бывают же компании с которыми уже работали и эти риски срабатывали. Как быть с ними дальше?
Как исправлять ситуацию, когда видно, что риск сыграл, но сроки и цены заказчик увеличивать не желает?

Здравствуйте, Ziaw, Вы писали:

nvb>>Например, отказ заказчика оплачивать доп.изменения. Или, что одно и то же, полная апатия заказчика до окончания проекта и масса требований переделок по его завершению...

Это не одно и то же, тут я не подумал, извиняюсь.

Z>А как вообще бороться с такими рисками? Закладывать в стоимость решения? Бывают же компании с которыми уже работали и эти риски срабатывали. Как быть с ними дальше?
Z>Как исправлять ситуацию, когда видно, что риск сыграл, но сроки и цены заказчик увеличивать не желает?

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

Ну, а если не соглашается и после этого — надо считать себестоимость выполнения контракта для себя с учетом рисков из прошлого проекта, и если получается себе в убыток — решение очевидно.

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

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

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

Здравствуйте, nvb, Вы писали:

nvb>Согласитесь, что заказчик, имея такой список перед глазами, будет реагировать на предложение увеличения сроков и цены более благожелательно, чем на фразу "Вы в прошлом проекте внесли массу изменений, поэтому давайте на этом проекте увеличим цену в полтора раза".

Если в прошлом проекте и в текущем заказчик — один и тот же, то апелляция к опыту взаимодействия "Заказчик — Исполнитель" действительно представляется продуктивной. А вот как быть, если заказчики меняются? Заказчик-то хитер, ответит: "Ну, я-то вносить изменения в требования не буду! Поэтому давайте уменьшим цену." — хотя, в глубине души знает, что — будет!

Здравствуйте, Vlad_SP, Вы писали:

nvb>>Согласитесь, что заказчик, имея такой список перед глазами, будет реагировать на предложение увеличения сроков и цены более благожелательно, чем на фразу "Вы в прошлом проекте внесли массу изменений, поэтому давайте на этом проекте увеличим цену в полтора раза".

V_S>Если в прошлом проекте и в текущем заказчик — один и тот же, то апелляция к опыту взаимодействия "Заказчик — Исполнитель" действительно представляется продуктивной. А вот как быть, если заказчики меняются? Заказчик-то хитер, ответит: "Ну, я-то вносить изменения в требования не буду! Поэтому давайте уменьшим цену." — хотя, в глубине души знает, что — будет!

Это самый лучший вариант.

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

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

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

Используйте юристов, они друзья РМа... если уметь их готовить

Здравствуйте, nvb, Вы писали:

G>>Результат оценивать, а не соответствие действий "общепринятому алгоритму", которого нет — не приходила такая свежая и неожиданная мысль в голову?

nvb>Ну, вы же сами сказали — прощелкал. Вот и оцениваем этот результат.

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

Немцы, следуя Auftragstaktik, в таких случаях оценивали наличие и адекватность "персонального видения ситуации", и "проявление инициативы" (сделал ли человек все возможное для успеха), т.е. гибкость реагирования на эту ситуацию. И это ИМХО правильно, это то, что имеет значение, и может помочь. Вообще, разбирается ситуация, а не человек.

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

G>>Что именно вам понятно, не объясните? А теперь допустим, что он есть. И что? Ну есть он, "а х-ли толку", как говорили в одном их анекдотов? Как будто наличие какой-то бумажки означает, что человек проанализировал угрозы, и выработал адекватный план с их учетом. И если его нет, это также не означает, что план не учитывал угроз. Это то же самое, что думать, что архитектура будет хорошая и адекватная, если ее описание вбить в руповский шаблон.

nvb>Конечно, не означает. Это означает лишь то, что риски и архитектура были визуализированы — то есть доступны для оценки и просмотра другим, более опытным человеком, и авторизованы им. Или не авторизованы. Или не просмотрены. Трудно залезть в мозги другому человеку, проще посмотреть на документ.

Если они авторизованы более опытным человеком, то не имеет большого значения, существуют они в виде списка, или же короткого емейла этому человеку, например. Факт "авторизованности" подтверждается очень просто, не так ли? Если, конечно, "более опытный" товарищ с испугу не уйдет в глухую несознанку. Что будет означать, что что-то не так в королевстве Датском, и дело вовсе не в списках рисков.

Но интересно-то другое. И что мы будем делать, если план был "авторизован" более опытным человеком, а проект провалился? Вот ведь подстава — все авторизовано . Неужто придется отставить инструкции и формальности в сторону, и начать разбираться в сути конкретной ситуации?

nvb>Да и самому РМу полезно такой документ иметь — правило 7+-2 никто не отменял. Это очень много значит.

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

nvb>Это первое. Второе — если уж брать нормальную компанию, в ней обычно хранятся списки проблем по прошлым проектам, которые переносятся в списки рисков на будущие проекты. Например, отказ заказчика оплачивать доп.изменения. Или, что одно и то же, полная апатия заказчика до окончания проекта и масса требований переделок по его завершению... да куча всего, вплоть до пофигизма юридического отдела.

Толку-то с того, что что-то где-то хранится. Важно не то, что хранится, а когда и в какой ситуации это люди должны читать. Люди не любят заниматься ерундой, знаете-ли.

nvb>Совершенно не факт, что все проблемы из прошлого проекта перенесутся в будущий, но знать-то о них надо. И помнить надо. И учитывать надо. Я, например, честно признаюсь, не помню многих рисков из своих прошлых проектов — вот вчера на собеседовании обнаружилось . Сунуть новичку этот список под нос и потребовать составить для своего проекта подобный с учетом имеющихся данных — какой от этого вред, кроме пользы, как вы выражаетесь?

Никакого вреда ровным счетом. Кроме пользы. Это отлично. Только это ведь не "разбор полетов" на предмет соответствия алгоритму, правда? Это уже есть обучение и обмен опытом.

G>>И разумеется, процедуры не гарантируют ровным счетом ничего касательно успеха проекта и его срока — процесс вероятностный.

nvb>Естественно, и процедуры смещают матожидание в сторону успеха. На сколько процентов — вот это вопрос спорный, и на него ответа нет.

Найн. Вообще говоря — не смещают. "Итальянская забастовка" — помните? Это контпример к данному утверждению.

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

Да, "практические навыки", и "умение обращаться с оружием" тоже смещают матожидание. Однако, речь идет о методических материалах, которые ни в коем случае не имеют статуса обязательной к выполнению инструкции, и от которых _требуется_ отступать если того требует ситуация.

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

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

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

Ну, мой подход к разбору полетов я опысал выше, рядом с ключевым словом auftragstaktik. Сверяться при разборе полетов с неким алгоритмом считаю в принципе, в корне ошибочным. Это противоречит самой сути проблемы. Вы проиграли поединок не потому, что плохо выполняете приемы. А потому, что не смогли среагировать на поведение соперника. Это может произойти от недостатка техники, да. Но даже если вы все делаете "правильно" — вы можете проиграть. И если делаете "неправильно" — вы можете выиграть, ибо никакого алгоритма для выигрыша нет и не может быть.

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

G>>Какая вера в силу инструкций . Удивительное рядом. Можно пример такой инструкции с Вашей работы, коллега?

nvb>Нет!!! Это страшно подумать, что тут начнется, если будем ее обсуждать

Именно. Порвут. Причем, независимо от того, какая была инструкция.

nvb>Да нет у меня никакой веры в силу инструкций. Есть разные методы передачи знаний, культуры проектной деятельности и разные методы контроля. Ясное дело, при личном общении все это происходит на порядок быстрее и качественнее, чем при формальном "Читай ГОСТ, там все написано". Вы мне это пытаетесь доказать? Так я согласен.

Не это. Я пытаюсь дать вам увидеть нечто более общее, частностью которого является обсуждаемая тема. Если вы уверены в превалировании результата над активностью, то надо идти в этом убеждении до конца. Сместить фокус в вашем подходе к разбору полетов с процесса на результат. С алгоритмов, и следованию инструкциям, на персональное видение ситуации и проявление инициативы. Короче, с Befehlstaktik на Auftragstaktik.

nvb>Теперь зайдем с другой стороны. Еще кейс. Возьмем пару свежеиспеченных, со студенческой скамьи, РМов. Один не имел архитектуры нигде, кроме как в своей голове (проект маленький, архитектора нет), тупо реализовывал все требования заказчика, никак не учитывал риски, забил на промежуточное тестирование и держал черт-те-знает-где код. Второй же, по крайней мере, пытался следовать формальным процедурам, которые писали успешные менеджеры проектов. Контроля сверху в процессе почти нет — это не CQG и не Люксофт, это, скажем, Газпром.

nvb>Вопрос: у кого будет больше вероятность успешного завершения проекта? Не гарантия, а вероятность?

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

Собственно, я наблюдал много молодых PM-ов, говорящих "PMBoK это моя библия", и следующих ей как магическому спеллбуку. Право, лучше бы своей головой думали, проку больше было бы.