Здравствуйте, 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 — налог на перечисление денег по статье "зарплата". Как делят оставшуюся сумму внутри — вам все равно никто не скажет, но уже можно оценить, сколько получают студенты — в лучшем случае, десятую часть от суммы договора.