Здравствуйте, malkolinge, Вы писали:
M>Вы назвали много правильных вещей но вывод не правильный
Не вижу ни одного аргумента против, одна лирика.
M>Руководитель дейсвительно набирает команду. Для этого у него должно быть определнное чутье.Зверинное чутье. И хорошие експерты. (тут правда возникает задача по типу курицы и яйца, а именно что было раньше)
Ну? И как решить проблему курицы и яйца? Как пеньку-манагеру понять, хорошие у него эксперты или нет? Звериннным чутьем и наукой доверять?
M>Согласитесь набрать команду, чтобы потом ей не доверять ? назвать своих ребят "эксперами", причем в кавычках ? В общем есть у вас тяга к садомазохизму. На самом деле все просто, нужно уметь доверять. Это наука а определить что проект движется не туда куда надо можно без всякого технического опыта
В кавычках про экспертов сказано по причине того, что обозначена вспомогательная роль, придуманная господами-идеологами от науки "управления чем-угодно". А своих ребят я тут не упомянал.
У меня есть некая аксиома и я буду её думать. А аксиома такая: основные добродетели менеджера — это правильно передать задачу (из этого следует подбор команды, управление) и вовремя решить т.наз. политический вопрос, который все боятся трогать (то есть в нужный момент прервать демократию и сказать "будет так то", с полной ответственностью за решение).
Менеджер, делающий оценку проекта... Ааа... Для этого есть аналитики, архитекторы. COCOMO, опять-таки. Вот из оценки сделать бюджет, понять, будем ли мы играть по-максимуму или по-минимуму, это уже его дело. Но делать оценку — увольте.
У "играющего" менеджера есть один очень большой соблаз, прогнать всех нафиг и сделать самому трудную часть. При этом управление проектом собственно откладывается, и проект летит кувырком. К сожалению, я такое видел на предыдущей работе у субконтракторов. 3 аналитика + 5 программистов + 2 тестера + техписатель. И вот менеджер взял на себя роль архитектора сложной части. Брр...
А то, что все описывали, это роль тим-лидера. Стопроцентная.
Другое дело, что в маленьком проекте очень часто менеджер == тим-лидер == архитектор. Иногда ещё и аналитик. И это, возможно, правильно, если его может сверху подстраховать топ-менеджер именно в административных вопросах. Но не надо всё это смешивать.
P.S. А Билл Гейтс — гениальный менеджер. И то, что он, возможно, никакой программист (не держал свечку, не знаю), ничуть ему не мешает в этом.
A.Lokotkov wrote: > > M>Вы назвали много правильных вещей но вывод не правильный > > Не вижу ни одного аргумента против, одна лирика.
У вас действительно имеет место аксиома, что менеджер должен
разбираться в деталях проекта. На самом деле вовсе нет. Он
может быть вынужден разбираться, если не может положиться
на экспертов, или если кастомерами проекта являются
технари (менеджер должен разговаривать на языке
кастомеров и их потребностей).
В общем, за минимальную необходимую техническую компетенцию
менеджера при наличии хороших экспертов можно взять
предполагаемую техническую же компетенцию кастомера.
> M>Руководитель дейсвительно набирает команду. Для этого у него должно > быть определнное чутье.Зверинное чутье. И хорошие експерты. (тут правда > возникает задача по типу курицы и яйца, а именно что было раньше) > > Ну? И как решить проблему курицы и яйца? Как пеньку-манагеру понять, > хорошие у него эксперты или нет? Звериннным чутьем и наукой доверять?
По результатам их работы (сбываемость оценок), по отзывам, по
бекграунду. Если менеджер-технарь, то ему оценить адекватность
экспертов ничуть не легче, а может быть даже труднее, т.к.
легко спутать компетентность исполнителя-программиста,
способного написать код, с компетентностью эксперта,
способного код оценить.
Для примера. Глядя на один старый участок кода программист
скажет, что данный участок системы очень крив и его надо
переписать.
Эксперт скажет, что участок может быть улучшен с примерно
такими-то плюсами, а в текущем состоянии будет вполне
приемлем тогда-то и тогда-то и если этого достаточно,
то ее переписывать не надо (мысль, совершенно чуждая
простым программистам). В то же время, если потребуется
регулярно вносить изменения в данный участок, то все
же порекомендует его переписать для снижения
трудоемкости изменений и тестирования.
> В кавычках про экспертов сказано по причине того, что обозначена > вспомогательная роль, придуманная господами-идеологами от науки > "управления чем-угодно". А *своих* ребят я тут не упомянал.
В реальных проектах, где есть и эксперты, и менеджеры-бывшие
эксперты, наблюдал полную загрузку и тех, и других. Причем
квалификация "бывшего эксперта" на задачи менеджера влияла
мало. Помогать — помогала, но только ввиду недостаточности
штата экспертов (которых регулярно теребят "обычные"
разработчики по техническим вопросам).
Ваше сообщение оставляет впечатление, что вы описываете
ситуацию, когда работы на их всех не хватит. Могу успокоить,
с лихвой хватит и еще останется.
Мы несколько отклонились от изначальной темы разговора "что делать с гениальными раздолбаями?", поскольку сей вопрос делится на два:
1. Как отличить просто раздолбая от раздолбая гениального?
2. Какие действия предпринять в отношении гениального раздолбая?
Главный вопрос здесь первый, и решить его в состоянии менеджер, который может объективно понять, гениален ли раздолбай.
В своих сообщениях в этом топике я вел речь о роли руководителя разработки (тимлиде, инженере проекта, главном архитекторе... как угодно).
По моим наблюдениям роль руководителя или администратора проекта сводится только к обеспечению внешнего интерфейса проекта (общение с заказчиками, верхним менеджментом компании и менеджерами смежных проектов), а также к логистике (грубо говоря, распорядиться починить кондиционер, сбегать за пивом для разработчиков и т.п). Т.е. в отношении команды разработчиков он никаких действий предпринимать не может и не должен. С другой стороны, сами разработчики не считают менеджера проекта своим руководителем, поскольку он фактически не руководит их повседневной деятельностью в проекте.
A.Lokotkov wrote: > > В своих сообщениях в этом топике я вел речь о роли руководителя > разработки (тимлиде, инженере проекта, главном архитекторе... как угодно).
Тимлид и главный архитектор — разные люди.
Серху имеет место менеджер проекта. Занимается вопросами, касающимися
всего проекта вообще.
Под ним — менеджеры подпроектов, несколько десятков целовек на каждый.
Занимаются вопросами, специфичными для проектов, организацией работы
каждого подпроекта.
Под ними — на одном уровне — эксперты, архитекторы, и тимлидеры.
Под тимлидерами уже сидят программисты (3-10 человек на тимлида).
> По моим наблюдениям роль руководителя или администратора проекта > сводится только к обеспечению внешнего интерфейса проекта (общение с > заказчиками, верхним менеджментом компании и менеджерами смежных > проектов),
Безусловно. Но только руководителя, а не администратора.
> а также к логистике (грубо говоря, распорядиться починить > кондиционер, сбегать за пивом для разработчиков и т.п). Т.е. в отношении
А вот это уже администратор.
> команды *разработчиков* он никаких действий предпринимать не может и не > должен. С другой стороны, сами разработчики не считают менеджера проекта
Он должен предпринимать действия в отношении своих непосредственных
подчиненных.
> своим руководителем, поскольку он фактически не руководит их > повседневной деятельностью в проекте.
Вы о проектах какого размера говорите ? Если там полсотни человек
нет, то да, многие роли совмещаются одними и теми же людьми. Если
же проект большой, то все разносится по отдельным человекам, и
никакого "просто руководителя" нет. Есть глава проекта, есть
непосредственный начальник, есть много других людей.
Здравствуйте, Mikhail Polykovsky, Вы писали:
AL>>По моим наблюдениям роль руководителя или администратора проекта сводится только к обеспечению внешнего интерфейса проекта
MP>А кто в данной схеме принимает решения типа "это мы сделаем сейчас, а это — потом" и "ты иди сделай вот это к этому сроку"?
Зависит от самого вопроса. Если это вопрос по порядку кодирования классов — то тимлид, или даже сам программист. Если же это относится к функциональности или не дай бог к срокам — то только вместе с менеджером проекта (который отвечает за проект, за бюджет и за принятие проекта заказчиком).
Здравствуйте, Mikhail Polykovsky, Вы писали:
MP>А кто в данной схеме принимает решения типа "это мы сделаем сейчас, а это — потом" и "ты иди сделай вот это к этому сроку"?
В контексте руководства разработкой -- технический руководитель. В контексте руководства проектом -- руководитель проекта или "главный инженер" компании. На уровне руководства компанией -- технический или генеральный директор.
Здравствуйте, A.Lokotkov, Вы писали:
AL>Мы несколько отклонились от изначальной темы разговора "что делать с гениальными раздолбаями?", поскольку сей вопрос делится на два:
AL>1. Как отличить просто раздолбая от раздолбая гениального?
Может вспомнить старые "идеологические правила", что критерием теории является практика. И вот просто сесть и спокойно попробовать выписать на бумажку, мол этот раздолбай придумал раз-два-три решения, которые сэкономили XXX сумму, а вот здесь ликвидировал отставание в проекте на две недели и обеспечил его принятие заказчиком. А по результатам бумажки и думать.
Есть ещё опция, некоторые люди являются как бы катализаторми жизни команды, прямых "бонусов" от них нет. Но в данном случае, похоже, это не так.
AL>2. Какие действия предпринять в отношении гениального раздолбая?
Зависит от п.1. Назначить главным архитектором, или наоборот экспертом (это для катализатора, который может разрулить сложные вещи, но не может чётко структурировать в голове картину). Или выгнать.
Здравствуйте, kittown, Вы писали:
K>Вы о проектах какого размера говорите ? Если там полсотни человек K>нет, то да, многие роли совмещаются одними и теми же людьми. Если K>же проект большой, то все разносится по отдельным человекам, и K>никакого "просто руководителя" нет. Есть глава проекта, есть K>непосредственный начальник, есть много других людей.
То, о чем Вы говорите, примерно теми же словами излагается в многочисленной матчасти (Рассел Арчибальд с его "Управлением высокотехнологичными проектами..." -- один из примеров). Основная мысль: создание иерархии команд, в которой менеджер проекта руководит не разработкой, а командой менеджеров, руководящих разработкой по направлениям.
Я говорю о проектах, с которыми сталкивался -- суммарно не более 20-ти исполнителей из разных областей (программирование, железо, тестирование, испытания и пр.). Проекты бОльшего размера мне изначально подозрительны. Кроме того, моя критика прежде всего нацелена на попытки верхнего руководства компаний сразу строить иерархию команд и делать проект большим искусственно независимо от его реального размера. Например, сразу назначается менеджер-пенёк, который собирает кучу экспертов из разных областей и т.д. В результате оказывается, что количество народа в проекте выросло до немыслимых размеров, а людей, реально занимающихся делом, "полтора калеки".
AL>..... Например, сразу назначается менеджер-пенёк, который собирает кучу экспертов из разных областей и т.д. В результате оказывается, что количество народа в проекте выросло до немыслимых размеров, а людей, реально занимающихся делом, "полтора калеки".
А с другой стороны. Я не могу себе представить экспертов-технарей, архитекторов и программистов, решающих оргвопросы. Особенно на этапе начала проекта. Потом, принцип единоначалия тоже никто не отменял. См. те же правила Ашманова.
BK>А с другой стороны. Я не могу себе представить экспертов-технарей, архитекторов и программистов, решающих оргвопросы. Особенно на этапе начала проекта. Потом, принцип единоначалия тоже никто не отменял. См. те же правила Ашманова.
Я не предлагаю технарям-экспертам решать оргвопросы. Мне думается, для успеха наверху должен быть аналог Королева, Фон Брауна и т.п. Хотя допускаю, что проекты типа автоматизации бухгалтерии или банковской деятельности можно делать иначе.
Здравствуйте, A.Lokotkov, Вы писали:
BK>>А с другой стороны. Я не могу себе представить экспертов-технарей, архитекторов и программистов, решающих оргвопросы. Особенно на этапе начала проекта. Потом, принцип единоначалия тоже никто не отменял. См. те же правила Ашманова.
AL>Я не предлагаю технарям-экспертам решать оргвопросы. Мне думается, для успеха наверху должен быть аналог Королева, Фон Брауна и т.п. Хотя допускаю, что проекты типа автоматизации бухгалтерии или банковской деятельности можно делать иначе.
Для успеха должна быть пара. Генератор "безумной идеи" плюс менеджер "ноги и локти для этой идеи". А они уже раскрутят всё дело. Если не будет кого-то одного, то перекос :/
Да, кстати, разработка коробочного продукта и заказная разработка систем несколько разные направления. Может в этом и дело. Для заказной разработки, особенно корпоративных систем, особые "прорывы" не нужны, а местами даже вредны. И наоборот.
A.Lokotkov wrote: > > Здравствуйте, kittown, Вы писали: > > То, о чем Вы говорите, примерно теми же словами излагается в > многочисленной матчасти (Рассел Арчибальд с его "Управлением > высокотехнологичными проектами..." -- один из примеров). Основная мысль: > создание иерархии команд, в которой менеджер проекта руководит не > разработкой, а командой менеджеров, руководящих разработкой по направлениям.
Именно.
> Я говорю о проектах, с которыми сталкивался -- суммарно не более 20-ти > исполнителей из разных областей (программирование, железо, тестирование, > испытания и пр.). Проекты бОльшего размера мне изначально подозрительны.
С моей стороны — 20 исполнителей в одной области на одном мини-проекте,
рядом еще 20 в той же области, но на другом. Плюс балласт в виде совсем
зеленых ньюкамеров.
Возьмите всех ваших исполнителей и добавьте каждому еще пяток
специалистов в той же области и найдите достаточно работы для
всех. Тогда будет похоже.
Это все из серии "промышленное программирование" — когда нет одного,
тем более прикладного, приложения, а есть здоровенный
аппаратно-программный комплекс. В случае application development-а
в команду из 20 человек я поверить могу, но случае аппаратно-программных
монстров — могу поверить только в разработку первых версий. Долгосрочная
рутинная поддержка и развитие требуют существенно большего количества рук.
> Кроме того, моя критика прежде всего нацелена на попытки верхнего > руководства компаний сразу строить иерархию команд и делать проект > большим искусственно независимо от его реального размера. Например, > сразу назначается менеджер-пенёк, который собирает кучу экспертов из > разных областей и т.д. В результате оказывается, что количество народа в > проекте выросло до немыслимых размеров, а людей, реально занимающихся > делом, "полтора калеки".
Осмысленность такого мероприятия зависит от компетенции всех участвующих
сторон и от того, чем собралась управлять вся эта толпа. Если внешними
связями, то смысл может быть (или не быть), а если теми самыми
"полтора калеки", то я с вами согласен.
Здравствуйте, Bor-ka, Вы писали:
BK>Здравствуйте, Mikhail Polykovsky, Вы писали:
AL>>>По моим наблюдениям роль руководителя или администратора проекта сводится только к обеспечению внешнего интерфейса проекта
MP>>А кто в данной схеме принимает решения типа "это мы сделаем сейчас, а это — потом" и "ты иди сделай вот это к этому сроку"?
BK>Зависит от самого вопроса. Если это вопрос по порядку кодирования классов — то тимлид, или даже сам программист. Если же это относится к функциональности или не дай бог к срокам — то только вместе с менеджером проекта (который отвечает за проект, за бюджет и за принятие проекта заказчиком).
Ну вот. Я к тому и веду, что проектом руководит (решает, что собственно делать) менеджер проекта. А чай пусть секретарша носит.
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, Mikhail Polykovsky, Вы писали:
MP>>А кто в данной схеме принимает решения типа "это мы сделаем сейчас, а это — потом" и "ты иди сделай вот это к этому сроку"?
AL>В контексте руководства проектом -- руководитель проекта или "главный инженер" компании.
Ну вот. А вы ему предлагаете чай программерам подносить
А ещё есть такое слово. Продукт = программа (30%) + ещё-что-то (70%). Догадайтесь, что
И вот руководить разработкой программы может (и должен, наверное) тимлид. А вот проектом в целом (то есть продуктом) именно менеджер. И для него совершенно необязательно быть высококлассным девелопером.
Ибо у микрософта отличные продукты (чего не всегда скажешь о программах). А в юникс-мире чаще всего только программы, местами отличные. Но очень мало продуктов.
Наверное я сам когда-то был таким ра...ем. Сейчас уже точно могу сказать — по неграмотности. Скажу больше неграмотно был организован процесс в 3х!!! конторах + отсутствие авторитетов. Точнее процесса этого почти и не было. Как только я попал в сильную команду (с авторитетными людьми) и отработал в небольшом XP проекте от начала до конца (2 мес.), рас...яй сразу кончился... Не хватало какого-то небольшого, но важного опыта, а как только показали как надо работать — дела резко пошли в гору.
Здравствуйте, Joker6413, Вы писали:
J>Здравствуйте, Garrrrr, Вы писали:
J>Наверное я сам когда-то был таким ра...ем. Сейчас уже точно могу сказать — по неграмотности. Скажу больше неграмотно был организован процесс в 3х!!! конторах + отсутствие авторитетов. Точнее процесса этого почти и не было. Как только я попал в сильную команду (с авторитетными людьми) и отработал в небольшом XP проекте от начала до конца (2 мес.), рас...яй сразу кончился... Не хватало какого-то небольшого, но важного опыта, а как только показали как надо работать — дела резко пошли в гору.
"Тут зритель воскликнет: "Здесь вся в чярном свете.
Ведь есть у тузов и молодцы сыновья".
Дружок, я вся знаю.
Я сам, брат, из зтих"
Абсолютно с вами согласен... Та же ситуация + отсутствие объединяющей идеи и _ответсвтвенности_ за свои действия.
