Здравствуйте, Аноним, Вы писали:

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

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

Менеджер создаёт условия для того, что бы
1 проект завершился успешно для всех сторон с соблюдением сроков и объемов
2 исполнители могли сосредоточиться на технических задачах.

В кратце это контроль, планирование, координация и арбитраж.

Если команда из 1 человека, то менеджер не нужен. Зато если команда 50 человек, то очевидно, нужно выстраивать иерархию иначе ничего в принципе не будет готово.

Опиши мне как организовать проектную команду из 50 человек без менеджеров, это будет прорывом в управлении, нобелевка тебе гарантирована.

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

I>Успокойся — любой может делать то что делает менеджер. Вопрос не в этом, а в том, какие функции у менеджера и эффективно ли совмещать их вместе с техническими.

Да я-то как-раз спокоен, это у менеджеров баттхёрт когда сомневаются в их нужности.

I>Менеджер создаёт условия для того, что бы
I>1 проект завершился успешно для всех сторон с соблюдением сроков и объемов
I>2 исполнители могли сосредоточиться на технических задачах.

I>В кратце это контроль, планирование, координация и арбитраж.

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

Зато я скажу для чего реально нужен ПМ.
1) Служить передастом между командой и боссом-с-деньгами. Боссы-с-деньгами больше любят разговаривать c выделенным лакеем чем с реальными исполнителями, потому что технари задают неприятные вопросы.
2) Говорить "за всю Одессу", опять же потому что люди извне воспринимают команду как единый организм обладающий собственной волей.
3) Собирать команду и мотивировать людей работать на результат. Без этого остается только надеяться что само слипнется.
4) Видеть картину в целом и определять приоритеты.

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

I>Если команда из 1 человека, то менеджер не нужен. Зато если команда 50 человек, то очевидно, нужно выстраивать иерархию иначе ничего в принципе не будет готово.

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

I>Опиши мне как организовать проектную команду из 50 человек без менеджеров, это будет прорывом в управлении, нобелевка тебе гарантирована.

Это вообще не вопрос: бьем проект на 3-5 команд по 10-15 человек, внутри команд используем agile и из каждой команды выделяем по человеку в рабочую группу по интеграции. Open Source проекты бывают и побольше, тем не менее замечательно обходятся без управляющих иерархий.

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

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


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

I>>>Он и не начальник, так, вахтёр.

J>>У меня такой был года два. Он казался вообще психбольным.
I>...

I>Вжик он не такой, просто он не понимает зачем нужно руководство. Манагер с его тз ничего не делает и только имитирует кипучую деятельность.

Это все понятно, но в целом это некрасиво. Сделают такого начальником группы, он вообще будет сидеть и не понимать, что бывают хоть какие объективные причины. А иди к психологу, это твои проблемы. Начальник "сделал/не сделал" напоминает просто стену.

Здравствуйте, Аноним, Вы писали:

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

Координирует процессы. Общается с заказчиками, акаунт-менеджерами или кто там по структуре (причём не просто трындит с ними, а берёт на себя ответственность за достижение результата из этого общения). Принимает решения по спорным вопросам. Разводит драчунов по разным углам.

А> Как мы знаем, в переводе на человеческий язык "ответственность менеджера" означает что ему не плевать на проект. Ну так хорошей команде тоже не плевать.

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

Здравствуйте, Аноним, Вы писали:

А>Да я-то как-раз спокоен, это у менеджеров баттхёрт когда сомневаются в их нужности.

Может, они просто болеют за дело? И понимают, что типичный программист сбежит после недели полной менеджерской нагрузки.

I>>В кратце это контроль, планирование, координация и арбитраж.
А>Для этого не нужен отдельный человек. С контролем замечательно справляются тасктрекеры. Любая обезьяна способна посмотреть на список задач и соотнести его с календарным планом.

Не любая обезьяна способна вызвать другую обезьяну на разговор и заставить её рассказать, как же обстоит на самом деле. Более того, другая обезьяна скорее всего пошлёт её нафиг.

А> С планированием гораздо лучше справится архитектор, ведь он знает как будет делаться проект, а менеджер не знает.

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

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

О. Как фокусник из рукава, появился какой-то группенфюрер (сиречь team leader) и всё заверте...

А>Зато я скажу для чего реально нужен ПМ.
А>1) Служить передастом между командой и боссом-с-деньгами. Боссы-с-деньгами больше любят разговаривать c выделенным лакеем чем с реальными исполнителями, потому что технари задают неприятные вопросы.

Важно не то, что он лакей или что задают вопросы, а что ПМ или группенфюрер — один.

А>2) Говорить "за всю Одессу", опять же потому что люди извне воспринимают команду как единый организм обладающий собственной волей.

Именно.

А>3) Собирать команду и мотивировать людей работать на результат. Без этого остается только надеяться что само слипнется.
А>4) Видеть картину в целом и определять приоритеты.

Ура. Вы поняли, и даже перестали троллить.

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

Может, потому, что тут советы со стороны мало помогают? Особенно в первом случае.

I>>Если команда из 1 человека, то менеджер не нужен. Зато если команда 50 человек, то очевидно, нужно выстраивать иерархию иначе ничего в принципе не будет готово.
А>Типичная точка зрения менеджера, которому кажется что без него все развалится.

Снова троллите.

I>>Опиши мне как организовать проектную команду из 50 человек без менеджеров, это будет прорывом в управлении, нобелевка тебе гарантирована.

А>Это вообще не вопрос: бьем проект на 3-5 команд по 10-15 человек, внутри команд используем agile

И организуем присутствие в команде своего персонального диктатора. Чтобы работало.

А> и из каждой команды выделяем по человеку в рабочую группу по интеграции.

По 2 или даже 3. Иначе фиг наинтегрируют.

А> Open Source проекты бывают и побольше, тем не менее замечательно обходятся без управляющих иерархий.

Это кажется. В них иерархии могут быть даже пожёстче, чем в фирме.

I>Вжик он не такой, просто он не понимает зачем нужно руководство. Манагер с его тз ничего не делает и только имитирует кипучую деятельность.

Справедливости ради, такое тоже не редкость.

N>Может, они просто болеют за дело? И понимают, что типичный программист сбежит после недели полной менеджерской нагрузки.

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

N>Осталось найти архитектора, который вместо своей любимой работы будет пилить остальных.

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

N>И организуем присутствие в команде своего персонального диктатора. Чтобы работало.

Кстати, не обязательно диктатора. Лучше бы, напротив, помощника. Чтоб от него была польза, а не чесание ЧСВ.

N>По 2 или даже 3. Иначе фиг наинтегрируют.

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

Здравствуйте, Аноним, Вы писали:

I>>В кратце это контроль, планирование, координация и арбитраж.

А>Для этого не нужен отдельный человек. С контролем замечательно справляются тасктрекеры.

Тасктрекер это только инструмент.

>Любая обезьяна способна посмотреть на список задач и соотнести его с календарным планом.

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

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

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

>Менеджерских планов в стиле "5 недель делаем фичу, две недели тестируем" мы уже насмотрелись, к реальности они имеют очень отдаленное отношение.

Это ж классика — таком духе действуют вчерашние девелоперы.

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

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

А>Зато я скажу для чего реально нужен ПМ.
А>1) Служить передастом между командой и боссом-с-деньгами. Боссы-с-деньгами больше любят разговаривать c выделенным лакеем чем с реальными исполнителями, потому что технари задают неприятные вопросы.
А>2) Говорить "за всю Одессу", опять же потому что люди извне воспринимают команду как единый организм обладающий собственной волей.
А>3) Собирать команду и мотивировать людей работать на результат. Без этого остается только надеяться что само слипнется.
А>4) Видеть картину в целом и определять приоритеты.

Все вместе это будет "контроль, планирование, координация и арбитраж". Ну еще коммуникация, это я пропустил.

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

"контроль, планирование, координация и арбитраж"

I>>Опиши мне как организовать проектную команду из 50 человек без менеджеров, это будет прорывом в управлении, нобелевка тебе гарантирована.

А>Это вообще не вопрос: бьем проект на 3-5 команд по 10-15 человек, внутри команд используем agile и из каждой команды выделяем по человеку в рабочую группу по интеграции.

Кто будет разбиением заниматься ? Кто будет озадачивать каждую из команд ? Кто будет разрешать конфликты в рабочей группе по интеграции ? Кто будет требованиями управлять ? Кто будет конфликты между группами решать ? Кто будет следить за исполнением всего проекта ? Кто будет ставить цели для всего проекта ?

>Open Source проекты бывают и побольше, тем не менее замечательно обходятся без управляющих иерархий.

Ну и заметно, что опенсорс ни в одном из рынков не доминирует, то есть, сливает пропиетарному.

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

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

Это не важно. Важно, что 50% (или 70% кк ты писал) будет спад у студента, а не у основного девелопера.
В большинстве контор из студента пытаются сделать мега-специалиста за пару месяцев и обычно это не выходит, после чего на студентах ставят крест.

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

Специально обучать 15 минут в день не хватит, а если студент будет сам обучаться, то максимум 1 часа в день хватит что бы направлять его деятельность в нужное русло. 1 час в день это не значит буквально именно так. Можно потратить примерно 4-5 часов в неделю что бы вместе делать какую то фичу. За один сеанс такой работы студент узнаёт гораздо больше, чем за один семестр института. Этого времени хватит, что дать хороший толчок примерно на неделю или даже больше.

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

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

Никак! НИКАК! НИКАК!

Я когда был студентом я днями и ночами сидел и писал код/программки/свой блог (с нуля). САМ.
Просто ищите самостоятельных.
Пусть они покажут, что они вообще пишут. Пусть это будут даже недоделанные программы, с глюками и говнокодом. Но ключевое во всём этом — САМОСТОЯТЕЛЬНОСТЬ.

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

I>Тасктрекер это только инструмент.

CAD это тоже инструмент, тем не менее появление CAD систем привело к тому что профессия "чертежник" резко перестала быть востребованной.

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

И в том и в другом случае нужно определять приоритеты. Это как бы очевидно. ПМ этого делать не может, потому как это не его компетенция. Определять что важно, а что нет может только заказчик (в случае аутсорсинга) или продакт менеджер (в случае собственной разработки).

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

IT это такая волшебная область, что планировать можно только то что спроектировано. Архитектор как раз и занимается проектированием, так что это практически единственный человек которые понимает как именно будет делаться проект. Он не переломится если заведет задачи в тасктрекере и проставит им estimation.

I>Это ж классика — таком духе действуют вчерашние девелоперы.

Как раз вчерашние девелоперы сперва проектируют, а потом оценивают.

I>Тимлиды берут на себя часть менеджерских функций, точнее менеджер делегирует им определенные функции. Это может быть планирование,а может быть и арбитраж или координация.

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

I>Кто будет разбиением заниматься ?

Тот кто стартует проект. На этом этапе без менеджера не обойтись.

I>Кто будет озадачивать каждую из команд ?

Команды замечательно могут брать задачи из тасктрекера.

I>Кто будет разрешать конфликты в рабочей группе по интеграции ?

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

I>Кто будет требованиями управлять ?

Продакт менеджер либо аналитик.

I>Кто будет конфликты между группами решать ?

Интеграционная группа же.

I>Кто будет следить за исполнением всего проекта ?

Все, посредством тасктрекера.

I>Кто будет ставить цели для всего проекта ?

Тот, кто платит деньги.

>>Open Source проекты бывают и побольше, тем не менее замечательно обходятся без управляющих иерархий.

Там иерархия не управленческая а техническая.

I>Ну и заметно, что опенсорс ни в одном из рынков не доминирует, то есть, сливает пропиетарному.

Браузеры, компиляторы, языки программирования серверные ОС. Этого мало?

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

N>Может, они просто болеют за дело? И понимают, что типичный программист сбежит после недели полной менеджерской нагрузки.

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

N>Не любая обезьяна способна вызвать другую обезьяну на разговор и заставить её рассказать, как же обстоит на самом деле. Более того, другая обезьяна скорее всего пошлёт её нафиг.

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

N>Осталось найти архитектора, который вместо своей любимой работы будет пилить остальных.

Планирование != пилить. Планирование это оценка, шедулинг и контроллинг. Последние две задачи замечательно могут исполнять автоматические инструменты, а оценку лучше архитектора не сделает никто.

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

N>О. Как фокусник из рукава, появился какой-то группенфюрер (сиречь team leader) и всё заверте...

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

N>Важно не то, что он лакей или что задают вопросы, а что ПМ или группенфюрер — один.

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

А>>3) Собирать команду и мотивировать людей работать на результат. Без этого остается только надеяться что само слипнется.
А>>4) Видеть картину в целом и определять приоритеты.
N>Ура. Вы поняли, и даже перестали троллить.

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

У меня есть мечта. Я вижу будущее, в котором для запуска проекта приглашается не бывший вчерашний тестер Василий П. или мальчик Лёша, который только вчера получил диплом целого магистра, а профессионал именно в запуске проектов уровня хотя бы Гапертона. Этому профессионалу выдается карт-бланш на подбор команды, выбор инструментов, организацию взамиодействия и т.п. Как только проект запущен, профессионал получает свои деньги и отправляется запускать новый проект. Когда требуется рывок, приглашается профессиональный Карабас-Барабас по рывкам. Если вдруг проект перестает удовлетворять, приглашается другой профессионал по разруливанию кризисов. Да, в новом дивном мире многие мальчики- и девочки-менеджеры отпраятся на помоечку, зато толковым управленцам дышать станет свободнее.

N>Может, потому, что тут советы со стороны мало помогают? Особенно в первом случае.

Ну почему же, мне советы Саши Орлова очень помогли.

N>Снова троллите.

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

N>И организуем присутствие в команде своего персонального диктатора. Чтобы работало.

Зачем? Внутри команды выделятся отдельные роли и они сам договорятся как им удобнее работать.

N>По 2 или даже 3. Иначе фиг наинтегрируют.

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

N>Это кажется. В них иерархии могут быть даже пожёстче, чем в фирме.

Это технические, а не управленческие иерархии.

Здравствуйте, Аноним, Вы писали:

N>>Может, они просто болеют за дело? И понимают, что типичный программист сбежит после недели полной менеджерской нагрузки.
А>Типичный программист просто не станет делать дурную работу, которой обожают страдать менеджеры.

"Отучаемся говорить за всех" (tm) — в смысле, что менеджеры обожают страдать.

N>>Не любая обезьяна способна вызвать другую обезьяну на разговор и заставить её рассказать, как же обстоит на самом деле. Более того, другая обезьяна скорее всего пошлёт её нафиг.
А>А зачем? Есть тасктрекер, информация в нем валидная и актуальная. Нужно узнать как на самом деле, welcome. Как только менеджер начинает вытрясать информацию окольными путями, информационная ценность тасктрекера резко падает. Народ просто перестает держать его в актуальном состоянии, потому что менеджер и так в курсе.

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

А> Особенно хорошо это заметно на распределенных командах у которых правила работы с тасктрекером просто драконовские относительно локальных команд, которые на этом фоне кажется раздолбаями.

Три команды по ~10 человек в трёх городах и ещё с полдесятка поодиночке это какой случай по-Вашему?

N>>Осталось найти архитектора, который вместо своей любимой работы будет пилить остальных.
А>Планирование != пилить. Планирование это оценка, шедулинг и контроллинг. Последние две задачи замечательно могут исполнять автоматические инструменты, а оценку лучше архитектора не сделает никто.

Угу. Особенно оценку, кто же является главным тормозом развития, или кого премировать.

N>>О. Как фокусник из рукава, появился какой-то группенфюрер (сиречь team leader) и всё заверте...
А>Почему из рукава? Разделение на роли всегда было и будет. Отличие лида от пма в том что лид находится внутри команды, имеет техническую компетенцию, определенный авторитет вкупе с необходимой информацией. Через это он гораздо лучше разруливает координацию и арбитраж чем ПМ.

Это только в том случае, если он хочет заниматься координацией и арбитражем. Что совершенно необязательно. Я вот в MSL вполне такой себе team leader, но я не хочу брать на себя такие вещи, и арбитражем у нас занимается менеджер проектов.

N>>Важно не то, что он лакей или что задают вопросы, а что ПМ или группенфюрер — один.
А>Я это и сказал. Классовая теория учит нас что буржуи избегают встречаться с пролетариатом лично. Самое веселое что для этой роли абсолютно не обязательно держать менеджера, достаточно девочки-секретарши вообще без полномочий. То же касается и ипостаси пресс-секретаря.

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

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

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

А>У меня есть мечта. Я вижу будущее, в котором для запуска проекта приглашается не бывший вчерашний тестер Василий П. или мальчик Лёша, который только вчера получил диплом целого магистра, а профессионал именно в запуске проектов уровня хотя бы Гапертона. Этому профессионалу выдается карт-бланш на подбор команды, выбор инструментов, организацию взамиодействия и т.п. Как только проект запущен, профессионал получает свои деньги и отправляется запускать новый проект. Когда требуется рывок, приглашается профессиональный Карабас-Барабас по рывкам. Если вдруг проект перестает удовлетворять, приглашается другой профессионал по разруливанию кризисов. Да, в новом дивном мире многие мальчики- и девочки-менеджеры отпраятся на помоечку, зато толковым управленцам дышать станет свободнее.

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

А>Даже и не думал. Я же говорю, значимость менеджеров переоценена. Когда ПМа сбивает трамвай, проект этого даже не замечает.

Мы, видимо, говорим о разных типах ПМ'ов. У нас это было бы заметно немедленно.


N>>Это кажется. В них иерархии могут быть даже пожёстче, чем в фирме.
А>Это технические, а не управленческие иерархии.

В opensource? Ну я посмотрю, как Вы тут, например, примете решение поперёк дядьки Торвальдса и оно будет всеми одобрено. Может, такое проходит в 1 случае из 20, но не чаще.

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

N>"Отучаемся говорить за всех" (tm) — в смысле, что менеджеры обожают страдать.

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

N>Что за муть Вы говорите. Тасктрекер не заменяет, например, необходимости проанализировать статистику ревью и заметить, что среднее время реакции с выставлением оценки резко возросло, поговорить с людьми и попытаться понять причины этого, а дальше — и методы исправления ситуации (если её надо исправлять), и не даёт сам по себе ни одного средства для подобной задачи. И это только навскидку.

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

N>Три команды по ~10 человек в трёх городах и ещё с полдесятка поодиночке это какой случай по-Вашему?

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

N>Угу. Особенно оценку, кто же является главным тормозом развития, или кого премировать.

Это не имеет никакого отношения к планированию.

N>Это только в том случае, если он хочет заниматься координацией и арбитражем. Что совершенно необязательно. Я вот в MSL вполне такой себе team leader, но я не хочу брать на себя такие вещи, и арбитражем у нас занимается менеджер проектов.

Тогда какой-ты к черту тимлид? Координация и арбитраж внутри команды это и есть ключевые функции тимлида. Без них это просто senior developer.

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

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

N>Они не безменеджерские. Они с усилением роли каждого участника, но не с полным избавлением от тех, кто делает "координацию и арбитраж".

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

N>А сейчас в большой конторе оно так и есть, только на уровне разделения времени одного человека, а не нескольких отдельных. Такой общий ПМ нескольких проектов тратит основные усилия на тот, который сейчас в граничной фазе, а остальные текут себе под меньшим контролем.

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

N>Мы, видимо, говорим о разных типах ПМ'ов. У нас это было бы заметно немедленно.

Значит ваши менеджеры слишком часто замыкают на себя ключевые активности.

N>В opensource? Ну я посмотрю, как Вы тут, например, примете решение поперёк дядьки Торвальдса и оно будет всеми одобрено. Может, такое проходит в 1 случае из 20, но не чаще.

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

Здравствуйте, Аноним, Вы писали:

N>>Что за муть Вы говорите. Тасктрекер не заменяет, например, необходимости проанализировать статистику ревью и заметить, что среднее время реакции с выставлением оценки резко возросло, поговорить с людьми и попытаться понять причины этого, а дальше — и методы исправления ситуации (если её надо исправлять), и не даёт сам по себе ни одного средства для подобной задачи. И это только навскидку.
А>Еще раз, а зачем? Грамотно настроенный тасктрекер собирает все необходимые метрики.

Кто его настроит?
Кто скажет, что его надо настраивать и как именно это надо делать, какие нужны метрики и какие им веса?
Команда, что ли? И как же именно она это сделает?

А> Менеджер для этого совершенно не нужен, тем более что когда менеджер замечает такие вещи, команда уже давно в курсе.

У команды есть дела заниматься своими делами, у каждого свои задачи. А не поглядывать за метриками в тасктрекер.

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

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

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

"Товарищ, фантастика — на втором этаже!" ([старый анекдот])
То, что Вы описываете, работает дай бог в 10% случаев. В остальных не получается.

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

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

N>>В opensource? Ну я посмотрю, как Вы тут, например, примете решение поперёк дядьки Торвальдса и оно будет всеми одобрено. Может, такое проходит в 1 случае из 20, но не чаще.
А>Торвальдс не говорит людям как зарабатывать на ядре деньги, какой пиджак носить, в каком режиме работать, как взаимодействовать с остальными разработчиками или, о ужас, с заказчиками, в каком порядки и какие выполнять задачи. Его ответственность это именно технические вопросы, причем не все, а лишь достаточно высокоуровневые.

Агащазз. Ну-ка вспомните, куда он послал NVidia неделю назад.

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

N>Кто его настроит?
N>Кто скажет, что его надо настраивать и как именно это надо делать, какие нужны метрики и какие им веса?

Тот кто запускает проект. Он же научит команду пользоваться трекером.

N>У команды есть дела заниматься своими делами, у каждого свои задачи. А не поглядывать за метриками в тасктрекер.

Сколько ресурсов отнимает поглядывание в трекер? Имеет ли смысл для такой мелочи держать специального человека?

А>>Одно другому не мешает. Менеджеров выкинули, из обязанности раскидали по остальным членам команды, эффективность увеличилась.

N>"Товарищ, фантастика — на втором этаже!" ([старый анекдот])
N>То, что Вы описываете, работает дай бог в 10% случаев. В остальных не получается.

Так стараться надо чтоб получалось, учиться, работать над собой.

N>А ничего, что у меня перед глазами примеры, как это происходит без проблем? Может, это Ваша консерватория криво стоит?

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

N>Агащазз. Ну-ка вспомните, куда он послал NVidia неделю назад.

Это публичная политика, примерно как Хрущев с туфлей. Жест Торвальдса никак не помешает ядру принимать патчи от нвидии, а нвидии зарабатывать деньги.

Здравствуйте, Аноним, Вы писали:

N>>Кто его настроит?
N>>Кто скажет, что его надо настраивать и как именно это надо делать, какие нужны метрики и какие им веса?
А>Тот кто запускает проект. Он же научит команду пользоваться трекером.

Это и есть ПМ. Но не следует думать, что его дела на этом закончатся.

N>>У команды есть дела заниматься своими делами, у каждого свои задачи. А не поглядывать за метриками в тасктрекер.
А>Сколько ресурсов отнимает поглядывание в трекер? Имеет ли смысл для такой мелочи держать специального человека?

При командах от ~15 человек — начинает иметь. От 50 — гарантированно имеет. Это оптимистичные цифры, достаточно часто это происходит ещё раньше.

А>>>Одно другому не мешает. Менеджеров выкинули, из обязанности раскидали по остальным членам команды, эффективность увеличилась.
N>>"Товарищ, фантастика — на втором этаже!" ([старый анекдот])
N>>То, что Вы описываете, работает дай бог в 10% случаев. В остальных не получается.
А>Так стараться надо чтоб получалось, учиться, работать над собой.

"Мышки, станьте ёжиками." (tm)
Мы должны работать с теми людьми, которые есть. И так страшный дефицит.

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

Ни разу я там не был. Всё в разработчиках своих продуктов.

N>>Агащазз. Ну-ка вспомните, куда он послал NVidia неделю назад.
А>Это публичная политика, примерно как Хрущев с туфлей.

Нет. Хрущёв с туфлей — это миф и фотомонтаж. А Торвальдс с факом — это социальное влияние на разработчиков.

А> Жест Торвальдса никак не помешает ядру принимать патчи от нвидии, а нвидии зарабатывать деньги.

Этот жест направлен в первую очередь не на NVidia.

И зачем таким страдать работая программером ?

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

Т.е. эта задача не для среднего руководителя

Известные мне компании, которые решили эту задачу (а нахождение решения позволяло подвальной — ну, точнее, детсадной-с-МКАДом-за-окном — фирмешке начала 90х выбиться в лидеры ИТ-рынка России) — делали примерно так:

— отбор самих студентов. Должны быть фанаты с горящими глазами, искренне интересующиеся тем, как оно все работает, а также доскональным теоретическим знанием технологии (в объеме экзамена по книжке "банды четырех", Страуструп-Эллис или Хейлсберга с соавторами).
— никакого давления по срокам — если написал некрасиво, переписывай. При этом раздолбайствовать не позволено строжайше.
— да, та самая "дедовщина". Обязательное условие применения — высокие требования к "деду".
— создание мощной корпоративной культуры кодирования на уровне "а вот это есть evil, мы так не пишем никогда, это Смертный Грех".

Требования к техдиректору при этом еще более высокие, чем к "деду". Он главный "дед" в компании.

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

С>Никак! НИКАК! НИКАК!

С>Я когда был студентом я днями и ночами сидел и писал код/программки/свой блог (с нуля). САМ.
С>Просто ищите самостоятельных.
С>Пусть они покажут, что они вообще пишут. Пусть это будут даже недоделанные программы, с глюками и говнокодом. Но ключевое во всём этом — САМОСТОЯТЕЛЬНОСТЬ.

100%. Единственный верный способ.
В программировании кого-то "тащить" — это фундаментально неправильный подход.

Литмусовый тест — горящие глаза энтузиаста.

Антитест — взгляд "овоща", который просто жует траву и ползет по жизни.