?

Log in

No account? Create an account

beskov


Программные продукты и проекты

Методы, Подходы, Новости, Объявления, Заметки


Previous Entry Share Next Entry
"Почему так популярна профессия руководителя проекта?"
beskov
Мой ответ на этот вопрос, заданный в форуме SQL.ru:
Почему так популярна и востребована профессия руководителя проекта?
Зачем их так много??
Давайте посмотрим с малого - зачем вообще нужны лидеры в любом коллективе. Скажем, собралась группа из N людей пойти в кино. И тут выясняется, что одним нравятся боевики, другим детективы, одни не хотят ехать на другой конец города, третьи не могут в выходные и у каждого есть своё мнение. Происходит гвалт, до какого момента?

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

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

По методу Л работает классическая теория лидерства и руководства. По методу С - теория самоорганизации однородных систем.

Что мешает вам и вашим друзьям (программистам) пойти и придумать идею продукта, взять кредит в банке, разработать систему и продавать её, живя в своё удовольствие?

  1. Нежелание брать на себя риски востребованности продукта, сроков и качества его реализации
  2. Отсутствие необходимых навыков целеполагания, планирования, контроля, маркетинга и т.д.
  3. Нежелание брать на себя риски того, что в коллективе произойдёт конфликт/ы, которые:
    а) могут происходить систематически и фактически саботировать разработку;
    б) могут привести к распаду коллектива
Что мешает вам, оставаясь в коллективе в компании в качестве наёмного работника, обходиться без менеджера проекта?
  • Отсутствие навыков и желания общаться с заказчиком.
  • Отсутствие навыков долгосрочного планирования.
  • Отсутствие навыков ведения эффективных переговоров.
  • Отсутствие навыков согласования интересов разных сторон.
  • Отсутствие навыков финансовых расчётов.
  • Отсутствие навыков и методов управления рисками.
  • Отсутствие практики точного следования договорённостям.
  • Отсутствие навыков предотвращения и разрешения конфликтов.
  • Отсутствие желания заниматься обеспечением ресурсами.
Метод Л в разработке ПО - это классический проектный менеджмент из серии "вот приедет дядя, дядя нас рассудит".

Метод С в разработке ПО - это то, что предлагает Agile и что естественным образом происходит во многих стартапах.

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

PS: Там, как обычно, тусовка базданщиков устроила сральню с меряньем пиписьками, но уж такая культура на форуме.


  • 1
Хороший ответ. Спасибо.

(Deleted comment)
(Deleted comment)
как программист неудачник и как не странно (по мнению руководства) хороший менеджер, могу сказать, что самое главное понять, в чем ты неудачники, и не упорствовать в том что тебе не особо дается, а заняться тем, что у тебя хорошо получается. Мне не светило стать даже хорошим программистом (хотя собеседуя последний год программистов, ловлю себя на мысли, что я был гений :)) и хоть немного приблизиться к уровням более продвинутых коллег. Вовремя это поняв, я начал заниматься тем что у меня получалось лучше - управлять проектами (не руками водить-руководить, не командовать и тд), и только недавно мой уровень компенсации чуть-чуть поднялся над уровнем хорошего программиста.
За последние 5 лет работы я наблюдаю картину, когда неплохой ПМ получает меньше хорошего программиста (как минимум в 3-х конторах это было так). А супер профессиональный тестер может получать больше всех в компании.
уровень зарплат это отдельный разговор, который во много зависит от текущей рыночной ситуации, но если ты хороший специалист-профессионал, не важно в какой области, без работы не останешься. :)

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

> Вполне можно применять эти методики для организации взрослых коллективов.
Можете озвучить названия методик?

1. КТД - коллективные творческие дела (методика Игоря Петровича Иванова). Правда его ученица говорила, что у нас была модификация этой методики.
2. Методики для обучения. Здесь названия сходу не вспомню - надо искать.

Вы что-то подобное используете?

Ещё не знаю. :)
Нужно познакомиться с теорией.

С радостью поделюсь опытом - обращайтесь.

скажу про себя

потому, что когда я придумываю в подробностях, как нужно что-то делать, мне интереснее придумать что-то еще, чем делать самому то, что уже и так понятно ;-)

Re: скажу про себя

О! Очень точно прозвучало, спасибо :) Проектировать очень интересно, видеть целую картину, планировать. Быть этаким "визионером". А вот потом кирпичик за кирпичиком складывать - непросто. Тут нужен немного другой склад ума :)
Еще раз спасибо за хорошую мысль, буду ее обдумывать.

Re: скажу про себя

(Anonymous)
Придумывать программу - это удовольствие, настоящая работа - искать маленькие сволочные ошибки.
ЛСЕ.

ИМХО, способ С, где не предполагается никакого лидера, довольно утопичный. Ну ведь скорей всего люди, собравшиеся в кино, коллективно выберут компромисс, - это значит, что всем будет неблизко и жанр будет никому не подходящий. А после похода обменяются взаимными упреками и разойдутся. В итоге никто довольным не останется.
И вообще, даже хорошо самоорганизованная команда имеет очень высокий риск распада из-за отсутствия в ней лидера. Срок ее жизни не может быть долгим, - рано или поздно схлестнутся чьи-то интересы, дяди, чтобы рассудил не будет, и произойдет раскол. Такая Agile-команда будет неустойчивой.
Выходит, чтобы сохранить стабильность, лидер все же нужен, но с более развитыми качествами психолога, чем в Л-случае, - он должен создавать видимость своего нелидерства, то есть быть неформальным. Вот это, наверное, и будет устойчивой Agile-командой.

Какой же это компромисс, если "жанр никому не подходящий"?

Я считаю, что самоорганизация - это не утопия, а просто редкий случай.

Не утопия. Отнюдь.

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

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

Ответ зависит, как всегда, от ответа на вопрос ради чего все затевается.


Re: Не утопия. Отнюдь.

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

Вот у меня сложилось абсолютно такое же впечатление (см. мой пост ниже). Уже тенденция :)

Я извиняюсь, что так туманно высказалась.
Когда я говорила об утопичности, я подразумевала следующее:Вероятность произвольной самоорганизации без вмешательства извне мала, и именно поэтому она не может служить базисом для какой-либо методологии разработки ПО. То есть, как мне кажется, Agile в первую очередь опирается на профессиональное неформальное лидерство, которое в свою очередь приводит к наблюдаемой извне самоорганизации.
Я не Agile-профессионал, и вообще не руководитель проектов, а просто человек, интересующийся методологиями разработки для себя. Мне нравится ваше определение, но смущает идея первичности самоорганизации. Т.к. она ведет к тем заблуждениям (или спекуляциям), с которыми я сталкивалась раньше, когда руководителю проекта очень выгодно объявить команде: "У нас Agile проект, извольте самоорганизовываться", - а самому получить дополнительное свободное время. В итоге, в команде споры с утра и до вечера, у продукта низкое качество, сроки сдвинуты, разработчики без сил, а руководитель в стороне от всего этого тешится, что все по Agile.
Для себя после всего прочитанного здесь и по ссылке на SQL.ru я укрепилась во мнении, что Agile требует большой искусности и не подходит для неопытных руководителей. Если мне доведется работать руководителем, я буду смотреть в сторону более формальных методологий, RUP, например.




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

Я нигде не писал про методологию, базирующуюся на совсем САМОПРОИЗВОЛЬНОЙ самоорганизации. Agile предлагает ряд принципов и техник, которые распределяют ответственность и делают принятие решений коллективным - т.е. это самоорганизация, которой дали инструменты. Эти принципы и техники внедряются либо агентом изменений внутри существующего коллектива, либо менеджером, либо сторонним консультантом, которые выступают в роли тренера (Agile Coach) при запуске и мастера (Scrum Master) в процессе работы команды.

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

Agile - это набор практик, которые надо отрабатывать. В России много мест, где говорят, что они работают в agile-стиле, но на поверку оказывается как с Web2.0 - есть какая-то аура, но под ней ничего нет.

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

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

>Метод С в разработке ПО - это то, что предлагает Agile и что естественным образом происходит во >многих стартапах.
Если честно, то я очень поверхностно знаком с основами Agile, он не предполагает наличие роли ПМ?
А с кого спрашивать за результаты, за те самые работы в определенный срок, с надлежащим качеством и в рамках бюджета? Со всех? Тогда не получится как Райкина "к пуговица претензии есть? нет, стоят намертво."
Повторюсь, скорее всего мои вопросы вызваны не достаточно полным знакомством с Agile практикой, так что заранее прошу прощения :)

PS: тема очень напоминает недавние беседы в Яndex, у них там тоже все круто саморегулируемо. Но опыт подсказывает, что когда подкрадывается северный пушной зверек и чересчур гибкие, и чересчур фиксированные могут подвести.

Я не привёл никаких особых фукций ПМа, которых не было бы в классике управления проектами. Бизнесмен как роль всё-таки по-моему другими вещами занимается ) На моей практике хорошим ПМ свойственны и креативность (лучезарность) и дотошность.

В Agile в разновидности SCRUM - 3 роли - Команда, Мастер и Владелец продукта. Посм. статью "Основы SCRUM".

За результаты спрашивают с команды, т.к. Команда представляет собой целостную единицу. Интересно, что вопрос "с кого спрашивать?" является типовым :)

Представь, что музыкальная группа вышла играть концерт и отыграла плохо - с кого спрашивать? )

А с кем ты общался в Яндексе? Их техдир прямо заявляет, что у них кастомизированный Agile. О какого рода зверьках идёт речь, например?

>Представь, что музыкальная группа вышла играть концерт и отыграла плохо - с кого спрашивать? )
В PMBOK ответ - с дирижера (с продюсера, со старшего):). Не получится со всей группы спросить. По моему иначе Райкин получится. Причем каждый из группы сделал все правильно, но результат отрицательный
В SCRUM (как я понял) ответ - со Scrum Master (он же PM)

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

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


Еще наблюдение про Яндкс, у них сейчас, к счастью, вопрос "кто пуговицы пришевал" не встает. Если им удастся выдержать команду и управление в таком духе то они супер проффесионалы (и сейчас в этом сомнений нет), но если такой ворпос встанет, то придет еще немного кастомизировать Agile, на мой взгляд, в сторону усиления роли Scrum Master.

Со SCRUM Master'а действительно спрашивать нельзя, хотя и хочется. SCRUM Master отвечает только за то, чтобы все соблюдали правила SCRUM. Ну и ещё разнимает подравшихся на SCRUM Meeting'ах :))).
Спрашивать за неудачу можно с команды. Когда команда хорошая - всем стыдно, опускают глаза. Когда плохая - все со скучающими лицами смотрят по сторонам, "моя хата с краю".

Спасибо, роль Scrum Master значительно прояснилась.

Вообще-то группа отличается от PMI-команды хотя бы тем, что СЫГРАННОСТЬ группы достижима только через слушание и подстраивание друг под друга, а не игру того, что показывает дирижёр (которого нет).

Я-таки процитирую статью:

Скрам Мастер отвечает за успех Scrum в проекте.
..
Команда берет на себя обязательства по выполнению объема работ на спринт перед Product Owner. Работа команды оценивается как работа единой группы. Команда ... Отвечает за результат перед Product Owner.


Можно сравнивать принципы управления проектом в SCRUM/RUP и PMI.

Подумав, сделал для себя некоторые обобщения:
- Agile, это тщательный подбор в команду людей отвечающих духу команды и готовых работать в соответствие с принципами и в условиях саморегуляции. Каждый член команды является равноправным и равноценным элементом, и вся команда выступает как единое целое. Тот кто выбивается из команды органически замещается новым членом. Но при этом поиск нового члена команды проводится долго и тщательно (Яндексе именно так)
- не Agile (скажем так), это когда набрал "таджиков" за $10, или "индусов" за $50, все четко расписал и распланировал, контролируешь результаты. Если "таждики" будут выкабениваться, или плохо работать, выгоняем и нанимаем "китайцев" за $5, тк работа стандартизирована, то выполнять может любой индивид с достаточной квалификацией. Проблема найма сводится только к наличии на текущий момент свободной рабочей силы приемлемого качества на рынке.

По своему "Agile опыту" могу сказать, что лет 5 назад работал в gamedev лавке, с очень хорошим стартом и быстро растущей. Там тоже был Agile, сплоченная команда, очень было интересно работать, но как только коллектив вырос с 10 до 60 человек все резко поменялось и контора потеряла управляемость. У меня сложилось впечатление, что виноват Agile, что он не приспособлен для быстрого роста компании, теряется управляемость. Но сейчас, на примере Яндекса, могу судить о том что дело не в методе, а в правильном применение. В общем надо всегда четко отслеживать ситуацию и принимать правильные решения, тогда все будет работать :)

По большому счету

Не полемизируя со сказанным.

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

По моему, опыту все остальное команда с удовольствием берет на себя. В вот в этих двух функциях коллектив нуждается.

Хотя это наверное оффтопик, потому что отвечает на другой вопрос.

Re: По большому счету

да, это функции "наставника"

  • 1