Приветствую!

может кто-то поделиться индикаторами производительности разработчика, которые используются в Вашей команде/конторе? Как рассчитывается производительность людей?
используются ли эти показатели для подсчета успешности команда/проекта/конторы?

ссылки на умные книжки по теме приветствуются

спасибо.

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

D>может кто-то поделиться индикаторами производительности разработчика, которые используются в Вашей команде/конторе? Как рассчитывается производительность людей?
D>используются ли эти показатели для подсчета успешности команда/проекта/конторы?

Мы используем собственно придуманные коэффициенты (скорее всего, кто-то это придумывал до нас):

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


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

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

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

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

надо же начинать с малого. сначала простые оценки для девелоперов и тестеров, потом введем зависимости от качества работы постановщика заданий

интересны подходы в других компаниях к оценке своей работы как отдельных людей так и команд и компании в целом.

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

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

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

статистика. с группы разработчиков можно получить статистику и сравнить данные между учасниками. одного "начальника" оценивать надо по другим критериям.

D>статистика. с группы разработчиков можно получить статистику и сравнить данные между учасниками. одного "начальника" оценивать надо по другим критериям.
Да нет, я не об этом...
Я говорю о том, что если эффективность разработчика оценивать только по критерию — "Сколько пришлось переделывать потом", никак не оценивая труд других перцев, то разработчик быстро может потерять энтузиазм — т.к. далеко не всегда количество переделок в будущем связано лишь только с его личным трудом.

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

D>Приветствую!

D>может кто-то поделиться индикаторами производительности разработчика, которые используются в Вашей команде/конторе? Как рассчитывается производительность людей?
D>используются ли эти показатели для подсчета успешности команда/проекта/конторы?

D>ссылки на умные книжки по теме приветствуются

D>спасибо.

Производительность в нашем нелегком деле измерена быть не может.
Кто скажет как ее измерить — пусть первый бросит в меня камень.-)

Как написано в одной книге Коуберна, единственное, что есть только одно измерение, которое работает: счастье пользователя.-))
Но поможет ли это вам во время разработки — большой вопрос.
Неплохо высказался на эту тему Robert Austin, чья цитата взята в статью Martin Fowler "The New Methodology".
---------------------------------------------------
Introducing measured management without good measures leads to its own problems. Robert Austin made an excellent discussion of this. He points out that when measuring performance you have to get all the important factors under measurement. Anything that's missing has the inevitable result that the doers will alter what they do to produce the best measures, even if that clearly reduces the true effectiveness of what they do. This measurement dysfunction is the Achilles heel of measurement-based management.
---------------------------------------------------

Но идея KPI в нашей области меня также волнует. Я пришел к выводу, что производительность это не поможет измерить, но вот сделать KPI как часть Employee Development and Contribution Process — вполне. Например, для юниоров получение сертификата по Java от Сана — чем не индикатор его роста? Условный рост от юниора к сеньору — чем не рост. Не просто так ведь введены грейды в больших лавках. Английский все знают? Нет! Значит пусть учат — тоже индикатор. Можно создать внутренний университет, где учить сотрудников. Там будут экзамены — достижимость определенных результатов также в отдельный индикатор. И раз в полгода(год) делать подсчет слонов, говорить о повышении зп, спрашивать о том, чего он хочет, как организация может помочь и т.д.
Но я не встречал IT компаний, где все это делают. Но всегда кто-то становится первым.-)

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

LW>Но идея KPI в нашей области меня также волнует. Я пришел к выводу, что производительность это не поможет измерить, но вот сделать KPI как часть Employee Development and Contribution Process — вполне. Например, для юниоров получение сертификата по Java от Сана — чем не индикатор его роста? Условный рост от юниора к сеньору — чем не рост. Не просто так ведь введены грейды в больших лавках. Английский все знают? Нет! Значит пусть учат — тоже индикатор. Можно создать внутренний университет, где учить сотрудников. Там будут экзамены — достижимость определенных результатов также в отдельный индикатор. И раз в полгода(год) делать подсчет слонов, говорить о повышении зп, спрашивать о том, чего он хочет, как организация может помочь и т.д.
LW>Но я не встречал IT компаний, где все это делают. Но всегда кто-то становится первым.-)

по-моему в IBS есть и грейды и чтобы переползти нужно что-то осваивать и т.п. ... т.е. "расти над собой". Интересно узнать насколько это эффективно работает у них.

Вот тут много примеров метрик по разным областям в том числе и ИТ www.kpisolutions.ru

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

V>Вот тут много примеров метрик по разным областям в том числе и ИТ www.kpisolutions.ru

Ты ничего умнее не нашел, чем пиарится здесь своим УГ-сайтом, подимая старые ветки

Автор:
Дата: 21.08.09

?

Посмотрите здесь: http://kpilibrary.com/

Сколько можно некропостингом заниматься?!

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

D>>статистика. с группы разработчиков можно получить статистику и сравнить данные между учасниками. одного "начальника" оценивать надо по другим критериям.
N_C>Да нет, я не об этом...
N_C>Я говорю о том, что если эффективность разработчика оценивать только по критерию — "Сколько пришлось переделывать потом", никак не оценивая труд других перцев, то разработчик быстро может потерять энтузиазм — т.к. далеко не всегда количество переделок в будущем связано лишь только с его личным трудом.

Почему? Если требования не меняются, а разработчик тратит время на устранение ошибок?

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

D>может кто-то поделиться индикаторами производительности разработчика, которые используются в Вашей команде/конторе? Как рассчитывается производительность людей?

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

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

S>- коэффициент исполнения плановых сроков. Считается от планового срока по задаче (согласовывается вместе с исполнителем) и его фактической протяженностью в часах

Здорово. Исполнитель штрафуется за появление непредвиденных проблем, обнаружающихся в ходе решения задачи, и поощряется за "надежные" по времени решения в духе затыкания дыр. Таким образом, разработчики, работающие над простыми и низкорисковаными задачами, легко поддающимися предсказанию сроков, будут в среднем иметь лучший показатель. Гут. Также этим показателем поощряется супернадежный перезаклад по срокам, с выносом мозга начальству на тему "как это сложно", и сопровождающим его пинанием балды в расслабленном режиме. Хороший показатель .

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

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

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

И никакой субъективщины, сразу видно, кто как работает. Как, гхм, автомат Калашникова. Какая зловещая и точная аналогия.

B>Почему? Если требования не меняются, а разработчик тратит время на устранение ошибок?
Потому, что это практически синтетика. Во-первых, чтобы не менялись требования, во-вторых, чтобы шло постоянное исправление ошибок в каком-то участке кода. В-третьих опять-же никто не смотрит из-за чего плодятся ошибки...

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

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

B>>Почему? Если требования не меняются, а разработчик тратит время на устранение ошибок?
N_C>Потому, что это практически синтетика. Во-первых, чтобы не менялись требования, во-вторых, чтобы шло постоянное исправление ошибок в каком-то участке кода. В-третьих опять-же никто не смотрит из-за чего плодятся ошибки...

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

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

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

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

Мне однажды пришлось наблюдать апофеоз последнего варианта — я описал бизнес-процесс выполнения задач разработчиков в одной известной компании: любая задача из плана в Project проходила 12 шагов (в минимальном случае, максимум — 16) с подписью ответственного на бумаге по завершении каждого шага. Все хватались за голову при взгляде на эту схему, но признавали, что при существующем KPI по-другому нельзя — иначе виноватого найти будет нельзя и без месячной премии останутся все причастные, включая невиновных. Угадайте, как там обстояло дело со сроками? Правильно, люди предпочитали не рисковать и закладывались в оценках с большим запасом. И всем было хорошо, включая директора — вот в этом месяце этот без премии остался, а в прошлом — те двое, деньги экономим

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

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

nvb>Мне однажды пришлось наблюдать апофеоз последнего варианта — я описал бизнес-процесс выполнения задач разработчиков в одной известной компании: любая задача из плана в Project проходила 12 шагов (в минимальном случае, максимум — 16) с подписью ответственного на бумаге по завершении каждого шага. Все хватались за голову при взгляде на эту схему, но признавали, что при существующем KPI по-другому нельзя — иначе виноватого найти будет нельзя и без месячной премии останутся все причастные, включая невиновных. Угадайте, как там обстояло дело со сроками? Правильно, люди предпочитали не рисковать и закладывались в оценках с большим запасом. И всем было хорошо, включая директора — вот в этом месяце этот без премии остался, а в прошлом — те двое, деньги экономим

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

А по-моему, лучше просто свалить нах из такой компании, где начальство занято только поисками крайних, и впредь стараться выявлять подобные случаи и обходить их за километр (для надёжности)...

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

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

Работа у нас такая — надо максимизировать зарплату при минимизации телодвижений Такая вот жизненная задачка на оптимизацию

Здравствуйте, 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 это моя библия", и следующих ей как магическому спеллбуку. Право, лучше бы своей головой думали, проку больше было бы.

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

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

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

Да. Со студенческой скамьи нельзя стать ПМ-ом. Для того, чтобы быть ПМ-ом в нашей индустрии, инженерный опыт совершенно необходим. Чтобы уметь руководить, надо уметь подчиняться. Быть в команде хорошего ПМа — лучшее обучение из всех, которые только можно придумать.

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

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

Надо учесть, что база кода в CQG тогда составляла примерно 2,5 миллионов строк концентрированного кода (не всякой сервисно-оберточной лабуды, функционал доминирует). Это много.

Вот так. Имея большое количество подобных примеров, и провалов "правильных" проектов — какой можно сделать вывод? Что у нас важно-то получается по настоящему?

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

Еще пример. Хороший пример. Вы на музыкальных инструментах играете? Я вот, скажем, неплохо умел играть на гитаре. Учился, кстати, самостоятельно, вообще без книг — слушая магнитофонные записи, и "снимая" по слуху музыку с аккордами. Что впоследствии дало мне любопытное свойство, приводящее людей в трепет — я мог сходу достаточно прилично сыграть большинство песен, которые когда-либо слышал. Зато не умел читать нот . Ну да неважно.

Как вы считаете, если у музыканта правильная техника — он будет хорошо играть? А если техника неправильная — у него будет получаться плохо?

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

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

Список можно продолжать до бесконечности — суть, собственно, в чем. Академичность техники не делает из тебя хорошего музыканта. Можно исполнить песню под гитару простыми аккордами (!) так, что люди придут в экстаз. И можно исполнить нечто очень техничное под метроном, так, что все заснут, ибо потеряется сама суть музыки. И быть плохим музыкантом, обладая хорошей техникой. Как, например, Зенчук. Или как его там, ну в общем, ему гитару в руки давать нельзя.

Техника полезна? Безусловно. Однако, она задает не более, чем набор возможностей. И совершенствование техники расширяет возможности. Но главное-то — в чем? В чем самом главном может ошибиться музыкант? В умении ПОЛЬЗОВАТЬСЯ той техникой, которой он владеет, для достижения результата. Вот почему "непрофессионалы" могут обходить людей, прошедших спец подготовку. И делают это часто. И будут обходить их в дальнейшем.

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

G>Техника полезна? Безусловно. Однако, она задает не более, чем набор возможностей. И совершенствование техники расширяет возможности. Но главное-то — в чем? В чем самом главном может ошибиться музыкант? В умении ПОЛЬЗОВАТЬСЯ той техникой, которой он владеет, для достижения результата. Вот почему "непрофессионалы" могут обходить людей, прошедших спец подготовку. И делают это часто. И будут обходить их в дальнейшем.

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

"Умный, но дурак" — человек, обладающий умом и знаниями, но не умеющий ими пользоваться, не владеющий навыком problem solving и лишенный гибкости. Своего рода "инвалид умственного труда". Про результаты деятельности таких людей иногда говорят — "иногда слишком много ума — это хуже, чем если бы его не было совсем".

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

G>В этом состоит суть парадоксальной поговорки "умный, но дурак". Никогда не слышали?

Ничего личного, кстати. Я эту поговорку часто слышал в школе от учительницы по физике. В свой адрес .

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

G>Техника полезна? Безусловно. Однако, она задает не более, чем набор возможностей. И совершенствование техники расширяет возможности. Но главное-то — в чем? В чем самом главном может ошибиться музыкант? В умении ПОЛЬЗОВАТЬСЯ той техникой, которой он владеет, для достижения результата. Вот почему "непрофессионалы" могут обходить людей, прошедших спец подготовку. И делают это часто. И будут обходить их в дальнейшем.

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

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

ЗЫ: Я вовсе не уверен, что у меня получится с "ЧеГеварой", если что . И дело не в моей исполнительской технике, конечно. Вот так же и в менеджменте, уважаемые коллеги.
ЗЗЫ: Если вдруг кого заинтересует результат — показывать в любом случае не буду. Это, знаете, как домашняя еда — готовится для себя или для друзей. А вот в менеджменте — увы, совсем не так.

Э-эх... Музыка, пнимаете-ли. Иллюстрацию можно раскрыть еще полнее. И оффтопичнее. Тем более, что воспоминания полились, как будто кто-то кран открыл.

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

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

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

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

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

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

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

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

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

Разумеется, сравнивать Крюка и остальных с командами Москвы и Питера — смешно. Техника профессионалов и качество материала несравнимы. Да. И эти тверские парни — первые, кто будет от души смеяться, при попытке сравнить их с профессиональными музыкантами.

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

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

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

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

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

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

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

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

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

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

Правила есть в любой организации — от семьи до государства. Просто иногда они бывают писаные, а бывают неписаные. С писаными проще, вот и вся разница.

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

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

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

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

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

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

Хорошо, теперь есть понимание, что все-таки нужен список или емейл, т.е. визуализация хранящихся у ПМа в голове рисков. Идем дальше.

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

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

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

Придется разбираться. Но это уже будет скорее итог невезения, чем неопытности РМа. Потому что опытный человек, ставя штамп одобрения плана действий, во-первых, перед этим правит явные ошибки, а во-вторых (ваша правда) начинает приглядывать за исполнением. Потому что не хочет услышать на разборе полетов "Ну ладно, РМ дурак, но ты-то куда смотрел, когда подписывал?". Активно не хочет, и предпринимает к этому некоторые усилия. Что и требовалось.

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

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

Конечно, это не является полным оправданием. Выводы сделаны будут, но уже в отношении не РМа, а его руководителей. Что, по-моему, вполне справедливо.

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

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

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

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

О! То есть расхождение у нас получается только в способах обучения и обмена опытом. Идем дальше. А что, если в компании наблюдается явный дисбаланс между количеством людей, которые могут обучать и количеством людей, которым нужно обучение и присмотр. Как быть? Обучить первых 10, а на остальных махнуть рукой? Или дать всем поверхностные знания и пустить в плавание?

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

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

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

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

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

Ну хорошо — как правило, смещают. Есть исключения, согласен.

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

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

Так никто же не спорит! Я вообще не могу представить себе процесса разработки, в котором, например, создаются ВСЕ положенные артефакты — это глупость.
Слышал такое определение разницы между мастером и новичком: оба они неизбежно нарушают правила, но мастер знает, когда это можно сделать, а когда нельзя.

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

Да ладно... Ваши рассказы о CQG говорят об обратном. Просто это называлось по-другому. А может, это я так воспринял написанное вами.

G>За исключениям того, что я не приветствую изменения в требованиях на любом этапе проекта.

В этом вы не оригинальны! Я тоже. Ненавижу, надо признаться

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

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

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

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

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

Никто не мешает следовать инструкции и думать головой, прежде чем выполнять из нее какие-то пункты. Вот пример — заставьте ПМа создавать ВСЕ артефакты из РМВОК в проекте с бюджетом в $200К и он гарантированно провалит проект, потому что ни на что другое времени у него и его подчиненных не останется

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

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

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

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

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

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

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

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

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

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

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

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

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

Развлечение №1 — "повтори аккорд". В нее начинающие музыканты играют от нефиг делать, а также с целью "замера пиписьками". Куда ж без этого.

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

Развлечение №2 — "это не аккорд!". К нему переходят в случае, если участник первой игры подозрительно хорошо угадывает аккорды, и тогда играть становится не интересно.

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

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

Развлечение №3. Повтори ритм-секцию. Циклическая группа аккордов, или в сложном варианте — с примесью лабуды, с нерегулярным ритмом. Отлично тренирует память, и чувство ритма.

Развлечение №4. Антиджем сешшн. Для двоих людей с гитарами, когда совсем нефиг делать.

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

Развлечение №5.
— Will it be rock-session, drink-session, or fuck-session?
— Hmm... It will be jam-session.

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

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

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

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

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

G>Насчет CQG. У нас никогда не было контроля сверху в процессе. Никогда. CQG, во времена, когда я там работал (начало 2000-х) — умудрилась сохранить гибкость стартапа (организована в начале 80-х). Процедуры касательно учета дефектов, и хранения кода были, естественно, так они к проектной деятельности не имеют никакого отношения. Они необходимы, чтобы большая географически распределенная группа людей могла продуктивно общаться по текущим вопросам — так же, как и телефон у каждого разработчика на столе с функцией конференц-связи. По сути — перечисленные вещи — это регламент человеческого общения, а не процесс разработки.

Да-да, какое же это управление процессом разработки...
Просто оно вас, как разработчика, почти не касалось — а вот чтобы так сделать, нужно действительно быть гениальныи ПМом.

G>И я могу вспомнить один из самых успешных проектов своего периода работы — группа студентов со скамьи очень быстро и качественно сделала пакет Advanced Options. Никакого мегаПМа, никаких мегапроцедур. Зато — Юджин Соренсен в роли продакт менеджера (известный эксперт по опционной торговле, сейчас один из топ-менеджеров Блумберга), и ставка на личную инициативу всех участников, которые любят свою работу. Итерации с показами Соренсену, плюс беседы с ним, где он разъясняет сое намерение, прося его развить и додумать — никаких документов! Никто не говорил, как надо делать. И даже не говорили, что. 500 подписчиков почти сразу с момента старта (это очень много), лучший опционный пакет на момент выпуска.

G>Надо учесть, что база кода в CQG тогда составляла примерно 2,5 миллионов строк концентрированного кода (не всякой сервисно-оберточной лабуды, функционал доминирует). Это много.

G>Вот так. Имея большое количество подобных примеров, и провалов "правильных" проектов — какой можно сделать вывод? Что у нас важно-то получается по настоящему?

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

Искусство ПМа состоит не в том, чтобы управлять гениальными людьми и сделать суперпродукт. Искусство состоит в том, чтобы с помощью обычных людей выполнить проект, который принесет прибыль.

Я немного знаю, как делаются проекты в МГУ. Из полусотни (примерно столько проходит через одного преподавателя) весьма неглупых студентов выбираются в течение года лучшие и они, обычно бесплатно или за копейки, действительно делают продукты приличного класса. Я утрирую, конечно, но обычный ПМ такой роскоши в выборе лишен. И даже раздолбайство — как студентов, так самого ПМа — не так сильно влияет на результат, как в заказной разработке, где за каждый час работы самого плохого кодера из проекта исправно списывают по тысяче рублей.

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

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

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

Некоторые блюзмены играли (и играют) на акустике четырьмя пальцами обеих рук. И получалось так, будто целый ансамбель с ритмом, басом, соло и барабаном. Только строй там был open C или open D (в стандартном open E на левой руке нужен еще один палец, а лучше два).

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

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

Пардон. Перечитал пост, и понял, что я зря помянул в последнем предложении Крюка. Ощущение создается не то. Не правильное.

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

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

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

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

Зачем же мне тратить массу усилий. Я напишу в список рисков балшыт, отнесясь к нему формально, и все. Компанию ненавидеть не надо — на ее интересы можно просто наплевать. И это ни разу не трудно, если считать требования инструкций дурью, а свои интересы — выше интересов компании. А на проектную премию, которая, вероятно, платится по какому-то KPI (?!! разве мы не KPI обсуждаем? А по какому такому признаку платится эта премия?), в принципе, можно и изначально забить, да.

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

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

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

nvb>Еще раз — как конкретно разбирается ситуация?

Ситуация разбирается вникая в суть ситуации. Приведите конкретную ситуацию, покажу на примере. Вы отыграете "разбираемого", я — "разбирающего".

nvb> Все, что вы перечислили — это номинализация, под этими выражениями можно понимать все, что угодно.

Предлагаю чрезмерно умные слова исключить из обихода. Я вот, например, не знаю, что такое "номинализация".

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

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

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

Следуя Auftragstaktik, я не могу "грузить подчиненных работой" в принципе. Я ставлю перед ними проблемы, которые надо решить. Все. Помощь в решении проблем предоставить могу, да.

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

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

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

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

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

nvb>Правила есть в любой организации — от семьи до государства. Просто иногда они бывают писаные, а бывают неписаные. С писаными проще, вот и вся разница.

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

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

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

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

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

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

Не, нет никакого "понимания", ибо факт "авторизации" возможен и без е-мейла со списком. Т.е. без визуализации хранящихся у ПМа в голове рисков. Это все может быть, например, оговорено устно, и факт авторизации подтвержден. Дальше идти никак нельзя. Что делать будем?

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

nvb>Придется разбираться. Но это уже будет скорее итог невезения, чем неопытности РМа. Потому что опытный человек, ставя штамп одобрения плана действий, во-первых, перед этим правит явные ошибки, а во-вторых (ваша правда) начинает приглядывать за исполнением. Потому что не хочет услышать на разборе полетов "Ну ладно, РМ дурак, но ты-то куда смотрел, когда подписывал?". Активно не хочет, и предпринимает к этому некоторые усилия. Что и требовалось.

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

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

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

nvb>Конечно, это не является полным оправданием. Выводы сделаны будут, но уже в отношении не РМа, а его руководителей. Что, по-моему, вполне справедливо.

А по-моему, это достаточно глупо. Цель _полезного_ "разбора полетов" — сделать выводы относительно ситуации и поведения в ней, а не выводы относительно персоналий. С целью вести в будущем себя лучше в аналогичных ситуациях, и получить опыт, а не с целью найти виноватых. Разница в подходах понятна, уважаемый коллега? Я повторяюсь по отношению к предыдущему посту — разбирается не человек, а ситуация.


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

nvb>О! То есть расхождение у нас получается только в способах обучения и обмена опытом. Идем дальше.

Нет, не только. Расхождение у нас в фундаментальных посылках к управлению.

nvb> А что, если в компании наблюдается явный дисбаланс между количеством людей, которые могут обучать и количеством людей, которым нужно обучение и присмотр. Как быть? Обучить первых 10, а на остальных махнуть рукой? Или дать всем поверхностные знания и пустить в плавание?

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

nvb>При обучении руководству проектами вы ведь книжки читали? То есть не все передается при личном контакте — иногда полезнее сказать "Почитай этот материал, а потом поговорим".

Не вижу в данном примере ничего противоречащего идее личного обучения.

nvb>Кстати и ваш блог тем же целям служит — делиться опытом невербально

Нет. Я веду свой блог с целью систематизировать свои мысли, а не с целью кого-либо чему-либо обучить. Написание поста-статьи вынуждает привести в порядок мысли, и это отличный стимул. Кроме того, это позволяет зафиксировать мысль в той форме, в которой ее можно потом перечитать. Наличие аудитории дисциплинирует в том смысле, что заставляет выдерживать минимальное качество изложения.

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

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

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

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

nvb>Ну хорошо — как правило, смещают. Есть исключения, согласен.

Почему же "как правило". Грань между "итальянской забастовкой" в полую силу и частично очень тонка. Хотя, это скорее вопрос веры. Я вот — не верю в инструкции. Я верю в инициативу и персональное видение ситуации.

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

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

nvb>Так никто же не спорит! Я вообще не могу представить себе процесса разработки, в котором, например, создаются ВСЕ положенные артефакты — это глупость.

Как же так — а как насчет списка рисков? "Нет? Понятно!" Или список рисков — исключение?

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

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

G>>...увы, не работал в таких компаниях. По духу мой подход ближе к убеждениям агилистов, на самом деле.

nvb>Да ладно... Ваши рассказы о CQG говорят об обратном. Просто это называлось по-другому. А может, это я так воспринял написанное вами.

Я специально привел "агилистский" рассказ про Юджина Соренсена. Кроме того, рассказ "Читай код", наделавший много шума, вряд-ли производит такое впечатление.


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

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

Да, я как раз раздумывал, упоминать ли "ката", как пример бесполезного упражнения, или нет. Дело в том, что на ринге в миксфайте можно схватить в морду независимо от того, как хорошо вы делаете "ката". Особенно, если учесть, что в карате в лицо руками вроде как не бьют, только в корпус, не так ли? А в миксфайте всем на это плевать, и низкое положение ваших рук, рассчитанное на удары "по правилам" в корпус, сильно обрадует оппонента с боксерской подготовкой (я уж не говорю о том, что многие бои заканчиваются в партере).

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

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

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

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

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

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

nvb>Никто не мешает следовать инструкции и думать головой, прежде чем выполнять из нее какие-то пункты. Вот пример — заставьте ПМа создавать ВСЕ артефакты из РМВОК в проекте с бюджетом в $200К и он гарантированно провалит проект, потому что ни на что другое времени у него и его подчиненных не останется

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

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

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

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

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

А это ничего, что на высоте вообще-то был блиндаж с пулеметом, и на запрошенный солдатом удар с воздуха по полевому телефону все положили длинный ...? А это ничего, что в отсутствии подготовки для выполнения боевой задачи виноват не солдат?

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

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

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

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

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

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

Отсутствие опыта помешает, и установка на следование алгоритму.

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

nvb>А у этих ПМов сертификация по РМВОК была? Уверен, что нет, иначе бы так не говорили.

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

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

nvb>Давайте завязывать с топиком. Он уже разросся до безобразия, а времени жалко. Готов даже публично признать, что вы правы . Или хотя бы сократим его до трех самых важных пунктов.

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

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

nvb>Я немного знаю, как делаются проекты в МГУ. Из полусотни (примерно столько проходит через одного преподавателя) весьма неглупых студентов выбираются в течение года лучшие и они, обычно бесплатно или за копейки, действительно делают продукты приличного класса. Я утрирую, конечно, но обычный ПМ такой роскоши в выборе лишен. И даже раздолбайство — как студентов, так самого ПМа — не так сильно влияет на результат, как в заказной разработке, где за каждый час работы самого плохого кодера из проекта исправно списывают по тысяче рублей.

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

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

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

D>Приветствую!

D>может кто-то поделиться индикаторами производительности разработчика, которые используются в Вашей команде/конторе? Как рассчитывается производительность людей?
D>используются ли эти показатели для подсчета успешности команда/проекта/конторы?


Доброго времени суток.


У нас используются индикаторы производительности команды.
Причем очень простые:
а) проект приносит деньги — проверяется по бухгалтерии.
б) директор доволен результатом — как результат возможно повышение з/п и премии.

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

А если проект проваливается — то редко по вине простых разработчиков. Почти никогда.

Вообще непроизводительный разработчик в небольшой компании (до 100 человек) заметен всегда и почти сразу.

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

Я сократил список вопросов до тем, которые кажутся мне важными.

nvb>>Еще раз — как конкретно разбирается ситуация?

G>Ситуация разбирается вникая в суть ситуации. Приведите конкретную ситуацию, покажу на примере. Вы отыграете "разбираемого", я — "разбирающего".

И что получится? У вас свои взгляды, у меня свои. У нас нет общего референса, на который мы бы могли оба сослаться. Вы же, например, с "Медведями" деМарко не согласны? А без этого наш спор превращается в бесконечную дискуссию о добре и зле... типа сравнения, какое из воинских искусств лучше. И выигрывает в таком споре не тот кто прав (здесь понятия "прав" и "неправ" нет и быть не может, ибо не с чем сравнивать), а тот, у кого лучше подвешен язык. Для ухода от ответственности за проваленный проект — просто идеальная питательная среда.

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

Вы предлагаете подменить "понятиями" четко прописанные законы. А все сколь-нибудь приличные руководители в истории невероятным упорством делали обратное. Может быть, я присутствую при рождении нового типа управления, но что-то есть у меня сомнения. Путь разбора ситуации, опираясь на писаные документы, несовершенен, вы это наглядно показали, но пока ничего лучшего не придумано.

G>Руководитель может работать на опережение, реагировать в настоящем, и обрабатывать последствия. В работе руководителя 60% вклада в успех имеет первое, 30% — второе, и 10% — последнее. При условии, что он хороший руководитель. Оценка рисков относится к первому, реагирование на них — ко второму. Разумеется, все это будет учтено при оценке его действий.

G>Какая бы ни была у человека картина мира, совершенно понятно, что выгоднее работать на опережение, чем обрабатывать последствия.

Ну наконец-то! Итак, есть понимание, что с рисками надо работать до того, как они превратятся в проблемы. Тогда вопрос, как. Можно держать список из 30 рисков в голове. Можно выписать на бумажку. Можно сравнить эту бумажку со стандартной формой оценки, принятой в компании и дополнить свой список, если окажется, что что-то упустил (РМ != Бог). Можно дополнить те риски, о которых забыли в стандарте (заказчик пьет, не переставая)(стандарт != полному набору базовых векторов). Можно отбросить заведомо невозможные риски из стандарта. Можно свериться с другой бумажкой, в которой описаны проблемы в предыдущем проекте. Можно показать итоговую бумажку более опытному товарищу.

В перечисленных действиях есть что-то плохое, категорически неприемлемое? Они оскорбляют свободную личность с персональным видением ситуации? Сковывают инициативу?

А может быть, нашему инициативному РМу совсем поперек души держать код под системой контроля версий и писать комменты к чекинам? Или создавать тесты в течение проекта, а не перед сдачей? Требовать от заказчика следовать порядку внесения изменений? Что из описанных мной в кейсе требований совершенно неприемлемо и подвигнет РМа на итальянскую забастовку? Ждать, пока РМ набьет сам шишки и осознанно придет к необходимости всего вышеперечисленного? Так дорого для компании получится.

nvb>> А что, если в компании наблюдается явный дисбаланс между количеством людей, которые могут обучать и количеством людей, которым нужно обучение и присмотр. Как быть? Обучить первых 10, а на остальных махнуть рукой? Или дать всем поверхностные знания и пустить в плавание?

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

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

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

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

Я тоже согласен с тем, что солнце восходит на востоке. Если у человека нет инициативы, он не может быть ПМом. Однако, это необходимое, но не достаточное условие.

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

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

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

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

Есть в проектном менеджменте заботливо поставленные светофоры, есть, правилами называются

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

Я же сказал — в случае малого опыта. Вы при работе с незнакомой библиотекой, если вам понадобится сделать FFT, будете хелп по API читать, или же включите персональное видение ситуации и, поставив себя на место разработчика, будете перебирать варианты названия и сигнатур?

И почему у вас везде звучит как аксиома, что у человека, прочитавшего инструкцию, отключается голова? Вы абсолютно все теоремы при обучении в МГУ сами доказывали, не ходя на лекции и не глядя в учебник?

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

Теперь возьмем свежеиспеченного ПМа. Есть у вас такие? Лучше двоих или троих. Дайте им какое-нибудь незнакомое ТЗ и попросите их перечислить ТОР5 рисков. Интересно получится, обещаю(кстати, хоть кто-то начнет задавать вопросы, не связанные с ТЗ?). Вряд ли их персональное видение покажется вам удовлетворительным. Пока нет собственного опыта — приходится его чем-то заменять, например, изучением чужого, выраженного в виде инструкции ("Правила эксплуатации электроустановок" написаны кровью"). При этом никто не мешает критически относиться к этому чужому опыту.

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

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

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

Это проблемы не студентов, а ПМа: Дмитрий в первую очередь — прекрасный архитектор, а уже потом РМ. Приоритет активностей здесь играет роль.
Кроме того, ВМК работает и по другим проектам

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

Да можете сами прикинуть — факультет ВМК оставляет исполнителям примерно 30% от суммы договора. Еще 70% (не знаю, почему, но это так) из этих 30 — налог на перечисление денег по статье "зарплата". Как делят оставшуюся сумму внутри — вам все равно никто не скажет, но уже можно оценить, сколько получают студенты — в лучшем случае, десятую часть от суммы договора.