Здравствуйте, Огнеплюх, Вы писали:

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

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

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

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

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

Любая система с четкой вертикалью власти рано или поздно приходит к тому, что мы видим в Северной Корее — задача главного не допустить утраты власти, завязать все под себя и стать незаменимым. Если это возможно сделать, то это будет сделано — это самый легкий путь и именно он будет выбран. Это естественный процесс, и с этим ничего не поделать. Единственный ИМХО вариант — это минимизировать количество роководителей, формальную работу разделять между всеми, делать ставки на неформальных лидеров и т.д. Вот только это сработает только в том случае, если тот, кто наверху, реально в этом заинтересован + если у него хватит способностей все нужным образом организовать. Для этого нужно работать очень усердно, нужно иметь мозги значительно выше среднего + надо постоянно развиваться, стараясь делать свою работу как можно лучше, а в случае успеха не гордиться и не расслабляться. Таких людей, кто с таким сможет справиться один на миллион наверно. И далеко не факт, что этот один на миллион сможет прорваться на соответствующую его способностям должность, возможно ему придется всю жизнь такси водить.

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

L>Если для вас все программисты — г..но, то вы просто г..но-менеджер.

После таких слов тебе осталось только от меня получить удар кулаком в лицо.

Ну вот кем надо быть, каким пигмеем, каким асоциальным существом, какое куриное сознание надо иметь, чтобы такое написать? Совершенно без причины, вот так грубо, оскорбить незнакомого человека?

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

Ну кого я оскорбил своим сообщением, интересно? Что я сказал?

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

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

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

B>Проблема скорее в другом.
B>В управленцы нередко попадают те, кто к этому не способен.

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

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

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

Здравствуйте, Огнеплюх, Вы писали:

О>Не спорю, может хоть мильон передастов быть которые транслируют информацию с уровня на уровень. Возможно это даже в каких то случаях необходмо.
О>Но ценность их на рынке не очень высокой должна быть.
О>Просто одному из старших специалистов дать совещательное право и все. Особые навыки тут не нужны, главное читать и писать по русски. Многие программисты/тестеры и т.д. с этим вполне справляются. Заводить отдельную штатную прокладку не нужно особо или если и заводить то з.п. уровня девочки на телефоне.
О>Для этого выделенная единица с фул-зарплатой не нужна. Можно взять одного из старших специалистов и послать на совещание чтобы договорится. Или конечно можно завести штатную единицу , но з.п. у нее не должна превышать з.п. курьера.

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

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

Короче, проект и его менеджмент суть далеко не то, что представляет себе пациент. Поскольку, ежели понимать, что такое есть проект, и насколько сложно поддерживать на ходу всю эту машину целиком, вместе со всеми вовлечёнными в процесс людьми, силами, интересами, денежными потоками и случайными факторами — то не возникнет странных вопросов о том, почему ПМам платят в разы больше разработчиков. Да просто потому, что ПМы имеют дело с систамами на порядок более сложными/хаотичными, нежели девелоперы. Так что на больших проектах типична ситуация, когда работает даже не один ПМ, а целая команда ПМов, а вы тут говорите — 1 FTE это много...

Но хватит об очевидном — теперь об интересном, а именно почему в случае маленьких или аутсорсинговых проектов, где, по сути, полноценный ПМ и не нужен, всё равно нужна его сублимация, "передаст" или "прокладка" по терминологии пациента. А также о том, почему таким менеджерам платили, платят, и всегда будут платить больше, чем разработчикам — пусть не в разы, но всё же. А дело в том, что деньги платятся не только за полезные скилзы, но и за желание заниматься чем-то, чем другие заниматься не хотят, например. Ведь работа такого манагера сводится к занудным и неинтересным операциям вроде сочинения статусрепортов (любой дев повесится на третий день, если заставить его заниматься чем-то таким — или будет ежедневно ныть на форумах, какие все плохие, так сильно ограничили его творческую личность), стрессам (даже если не взвалят весь груз финансовой и пр. ответственности за факапы тех же девелоперов, всё равно отбрехиваться манагеру; мало кому такое пожелаешь), а также к общению с людьми (да, всё время, и с живыми — а не по скайпу или мылу; 95% девелоперов одно только это уже не под силу). Так что даже такой манагер выполняет одну очень полезную функцию: он изолирует разработчиков от тех дел и явлений, с которыми они не могут или не хотят справится. Вот именно за это им платили, платят, и будут платить больше, чем девелоперам — потому как за меньшие деньги никто за эту работу тупо не возьмётся, проще будет сидеть в своём уголке и тихо кодить что-то.

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

Здравствуйте, Огнеплюх, Вы писали:

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

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

Хороших программистов вокруг — хоть жопой ешь. А нормальных менеджеров можно по пальцам пересчитать.

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

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

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

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

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

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

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

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

Здравствуйте, Огнеплюх, Вы писали:


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

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

О>Обеспечивает взаимодействие = промокашка. Любой заказчик или бизнес-аналитик как правило стремится напрямую общаться с разработчиком, а промежуточные звенья которые только вносят искажения в информацию им не интересны.
Ничего подобного! Ни в одной компании не видела, чтобы заказчик звонил программистам и говорил, что он хочет. У программистов совсем другая работа, они не должны слушать капризы, требования и т.п., они должны читать ТЗ и составлять алгоритмы, которые это реализуют. Судя по вашим словам, у меня сложилось ощущение, что вы работаете в компаниях, где бизнес-процессы не определены и отсюда вот такой хаус и смешение обязанностей.


О>Опять же у менеджера нет никакого выбора — выбор за заказчиком и профи, за специалистами. Менеджер на поводу у заказчика, архитектора и других специалистов — что они скажут/сделают так и придется это воспринимать. Менеджер не может/не имеет профессиональной компетенции оспорить мнение архитектора о том какая должна быть архитектура.
То есть архитектор у вас — это типа бог, который может разработать архитектуру на миллион долларов для простейшего приложения, и менеджер ничего не может возразить? Это несерьезно! Менеджер как раз должен выслушать архитектора и оспорить архитектуру, если она недопустима по каким-либо причинам.
Опять же — если один разработчик скажет, что он будет кодить в Visual Stodio 6.0, а другой — Visual Studio 2005, менеджер должен промолчать? А вы в курсе, что во всех нормальных компаниях лицензии закупаются на определенные линейки продуктов и не разработчикам решить, в какой версии студии они будут кодить!

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

О>>Не понимаю.

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

О>>Что интересного там находят — сидеть смотреть как другие работают,

DB>Зачем смотреть как другие работают? Достаточно задать направление, описать цель и контроллировать получаемые результаты. Естественно, приходится что-то довыяснять (у заказчиков), что-то дообъяснять (разработчику), но при вменяемых заказчиках и разработчиках это всё происходит в виде ненапряжённой беседы. А беседовать приятнее, чем писать код .

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

DB>Это ерунда. Пятиминутная беседа с вышестоящим начальством (чтобы выделил денег) и с системным администратором (чтобы купил и установил).

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

О>>Быть прокладкой между ген.директором и разработчиками.

DB>Почему же прокладкой? Вышестоящее начальство не передаёт через меня поручения моим подчинённым. Это можно и договориться до дого, что все генералы, полковники и другие офицеры в армии — прокладка между главнокомандующим и солдатами.

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


О>>При этом зарплата не намного выше, а иногда у менеджеров даже меньше или равна зарплате программиста.

DB>В России, практически всегда выше. Не говоря о перспективах дальнейшего его роста. Если мой отдел и направление будет расти (что весьма вероятно), то я буду расти как руководитель. Программисты же останутся теми же самыми программистами.

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


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

DB>Это как посмотреть на это дело . По мне, так результат работы разработчика является и моим результатом тоже. Т.е. я создаю результат и продукт. Только программист считает своим результатом то, что сделал лично он. А я считаю своим результатом то, что сделала команда. Т.е. у меня ощущение результата гораздо больше. Так бывает приятно смотреть, как проект растёт и развивается .

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

О>>А начальник что, сидеть ждать когда же тебе кто-то зайдет в кабинет чтобы расставить росчерк на заявлении об отпуске/увольнении.

DB>Ну, бумаги с росчерками об отпуске собирает не начальник, как правило, а рядовая сотрудница HR отдела .

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

О>>Ждать когда позвонит ген.дир и даст по голове , чтобы выскочить из своего кабинета и как попугай повторить это.
DB>Ну с ген.диром разговоры как правило происходят в весьма позитивном и дружественном тоне. Самое интересное, даже в случае неудач .

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

О>>Следить за временем прихода/ухода...просто скукатища.
DB>Следить за временем прихода/ухода — вообще бред. Это все и всегда говорили.

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


DB>Если коротко про плюсы:
DB>1. Всех перечисленных тобой минусов практически не существует. Если повезло работать с классными специалистами и людьми, то вообще всё замечательно.
DB>2. Выше зарплата и интереснее перспективы (рост отдела — рост его руководителя, но не рост программистов).
з.п. бывает как выше так и ниже и в среднем не сильно отличается от з.п. специалиста.

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


DB>4. Больше ощущения результата, так как считаешь своим результатом и то, что делают другие. Когда был рядовым программистом, своим результатом считал только то, что сделал сам.


DB>5. Меньше сложной и напряжённой работы (например, разобраться почему какая-то хрень работает не так как должна) и больше несложной и ненапряжённой (составить план, обсудить задачи, обсудить перспективы и высказать своё мнение и т.д.).
Только кто потом плоды этой работы использует ? План через пару дней уйдет на помойку т.к. окажется что что-то пошло не так и его нужно будет переделывать. Обсудить задачи и перспективы, высказать мнение это бла-бла которое никому не нужно , кроме самого начальника чтобы хоть как-то проявить себя ,а то забудут о его существовании.

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

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

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

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

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

Лидер != менеджер.

Здравствуйте, Огнеплюх, Вы писали:


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

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

Здравствуйте, Тролль зеленый и толстый, Вы писали:

ТЗИ>Я ищу программистов, предложил приличную зарплату (чуть выше средней на рынке), а ко мне на собеседование уже месяц идут люди, у каждого из которых по несколько лет опыта работы, не знающие элементарных основ языка, на котором собираются программировать. И ни один человек не написал (элементарное!) тестовое задание, чтобы в нем не было хотя бы какой-нибудь одной ошибки, или хотя бы аккуратно (просто аккуратно) его оформил.
Можно немного подробностей, что понимается под знанием элементарных основ языка? Вот не верю, что не знают именно элементарные вещи. Синтаксис наиболее часто используемых конструкций знают вообще все. Именно это я подразумеваю под элементарными основами. Могут не знать то, что никогда не применяли. Я вижу очень много народа с двухлетним опытом, и очень сильно на них матерюсь — да, не умеют писать структурированно, обобщенно и понятно, да, не соблюдают <span name="mcb_s" id="mcb_s" style="display:-moz-inline-stack; display:inline-block; overflow:hidden; zoom:1; *display:inline; margin: 0px; padding: 0px;">best practices</span>, да, не умеют предугадывать будущие изменения и никогда не подумают на шаг вперед и не напишут на перспективу, да, никогда не проявят инициативу и будут делать только то, что им сказали, да, на аккуратность в оформлении плюют — таких к сожалению большинство.
Но на незнание основ именно языка я пожаловаться никак не могу. Наиболее вероятно — под основами подразумеваются детали работы сборщика мусора, тонкости реализации библиотечных функций, перечисление на память иерархии классов в стандартных библиотеках. Ну и вопросы типа скомпилируется или нет код, для которого на практике среда разработки выдаст предупреждение еще до компиляции — типа что будет если написать блок try, finally, из try return, catch нет вообще. Тут да, если к сертификации не готовился, далеко не каждый вспомнит, так как при работе это даже близко не надо. Да и то, именно имеющие 2 года опыта на такие вопросы как раз и ответят, так как апофеоз их крутости это сертификат и они зациклены именно на языке, а не на умении программировать — не ответить могут те, у кого опыт побольше.
Вот не верю и все! ИМХО просто не то спрашиваете, что требуется, потому всех и последними словами обзываете.

Огнеплюх пишет:

> Я об этом и говорю что в 90% случаев из хорошего специалиста получилось
> это "позорное лошье" и мне не понятна мотивация состоявшегося
> специалиста который решил прыгнуть в этот омут. Не понятно почему так
> стесняются быть специалистами , типа фразы "если в 30 ты не начальник то
> лох", помоему это какое-то недарозумение или как общественный грипп ,
> стереотип.
Проблема в том, что из трёх майоров получается один подполковник, а из
трёх подполковников — один полковник. То есть 6 человек из 9 будут
дослуживать майорами.

В ИТ примерно так же — то есть выше senior developer поднимутся далеко
не все "хорошие специалисты", столько архитекторов просто не нужно. И
это нормально, это не является признаком какой-то неправильности ИТ или
чем-то новым и доселе невиданным.

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

С тем что в этом нет ничего хорошего — согласен.

Вот тут про это неплохо написано:
http://ab-pokoj.livejournal.com/54046.html

--
WBR,
Serge.

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

О>>При этом зарплата не намного выше, а иногда у менеджеров даже меньше или равна зарплате программиста.

DB>В России, практически всегда выше. Не говоря о перспективах дальнейшего его роста. Если мой отдел и направление будет расти (что весьма вероятно), то я буду расти как руководитель. Программисты же останутся теми же самыми программистами.

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

DB>Это как посмотреть на это дело . По мне, так результат работы разработчика является и моим результатом тоже. Т.е. я создаю результат и продукт. Только программист считает своим результатом то, что сделал лично он. А я считаю своим результатом то, что сделала команда. Т.е. у меня ощущение результата гораздо больше. Так бывает приятно смотреть, как проект растёт и развивается .

DB>Если коротко про плюсы:
DB>2. Выше зарплата и интереснее перспективы (рост отдела — рост его руководителя, но не рост программистов).
DB>4. Больше ощущения результата, так как считаешь своим результатом и то, что делают другие. Когда был рядовым программистом, своим результатом считал только то, что сделал сам.
DB>5. Меньше сложной и напряжённой работы (например, разобраться почему какая-то хрень работает не так как должна) и больше несложной и ненапряжённой (составить план, обсудить задачи, обсудить перспективы и высказать своё мнение и т.д.).

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

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

Здравствуйте, Огнеплюх, Вы писали:

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

Не повезло с начальством?

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

Здравствуйте, Огнеплюх, Вы писали:

О>Здравомыслящий заказчик понимает нашу российскую ситуацию и то что у нас нет хороших управленцев — нет институтов. Поэтому практически любой начальник/менеджер в 99% случаев это такой же управленец , как студент архитектор или обезьяна с гранатой. Изредка занимающийся самообразованием.

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


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


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

Marduk пишет:
>
> Там много под-систем, но над основной системой работало больше сотни
> разработчиков, тестировщиков, автоматизаторов. Это было, когда я там
> работал.
И главное, все при деле.
А по сути, оное пишется максимум 10 человеками.

Здравствуйте, Огнеплюх, Вы писали:

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

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

Работа, конечно, более тяжелая чем у программиста. Но это того стоит.

Здравствуйте, Тролль зеленый и толстый, Вы писали:

ТЗИ>Не укажете ли место, где эта замечательная жопа ест? А то мне тут как раз понадобилось несколько хороших программистов, а прет одно г..но.
А тут все просто. До черта разработчиков, которые потенциально могут стать очень хорошими (причем в короткий срок), если им не мешать и немного помогать. Вот только задача менеджера часто стоит в том, чтобы сдержать профессиональный рост разработчиков, ни в коем случае не допустить появления незаменимых. Так как если будет рост, то будет текучка, и они перейдут туда, где требуется высокая квалификация. Тоже самое — допустил развития программистов — плохой менеджер. Если для разработчики увязли в болоте, и деваться им некуда — это хороший менеджер. То, что не можешь найти хороших (в твоем понимании) программистов — это результат того, что много развелось хороших (в понимании бизнеса) менеджеров.

S>Руками менеджера, который управляет проектом, тоже очень многое делается. Например, принимаются важные решения по развитию проекта и его архитектуре. Менеджер обеспечивает взаимодействие бизнес-аналитика и разработчиков, составляет ТЗ и т.п. Для этого всего надо иметь обширные знания и опыт как разработки, как и общения с людьми.

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


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

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

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

G>Лидер != менеджер.

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

Здравствуйте, Огнеплюх, Вы писали:

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

F>>Здравствуйте, Огнеплюх, Вы писали:

О>>>Не понимаю.
F>>Деньги, что же ещё?

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

О>Можно также услышать — а как же специалисты смогут работать без менеджера , сразу возникает вопрос — а как тогда специалист который не может работать без менеджера — вдруг может стать менеджером ?

У менеджмента может быть множество звеньев.

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

А вот давайте посмотрим на всё с позиции владельца компании. У него есть определенное количество сотрудников, допустим, человек 50 и нужно выполнить некоторую задачу. Как вы думаете, реально ли ему всем 50 описать, что каждый из них должен делать? Как по мне, там в этом есть некоторые трудности. К тому же ему еще нужно вдаваться во все мельчайшие детали проекта, на что просто времени не хватит. Если человек всего 5-6, то это выполнимо еще, но вот если 50, то надо как-то по-другому поступать. Вот и приходим к необходимости того, что нужен человек, который представляет команду в целом и которому уже можно ставить задачи. То есть уже нужно поставить задачу не 50 людям, а где-то 5-6. Это куда более выполнимо, к тому же вам надо только указать high-level направления, детали уже будут разбираться внутри команды. А те уже распределят задачи дальше, на каком-то этапе это уже вырисовывается в детально описанное задание индивидуально на каждого рядового исполнителя. В обратном порядке идет сбор информации о статусе работы.

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

Ну, и по поводу разных форс-мажорных ситуаций. Например, на стороне заказчика засбоило приложение, которое разрабатывает ваша команда. Заказчик, в данном случае, это дядька, который платит деньги за вашу работу и которого только интересует, чтоб система работала нормально. Будет ли он выискивать, кто там накосячил, Вася Пупкин или Петя Какашкин, или кто-то еще? Врядли. Ну и уж наверняка ему не особо охота высклушивать про какие-то там SQL, Java , веб-сервисы и прочее. Но разобраться надо. И кто-то команду разработчиков должен представлять, переговорить с заказчиком и уже дальше определить, кто это будет исправлять.

Да и просто, нужен человек, который мог бы видеть состояние проекта в целом (пусть и высокоуровнево, но охватывая все направления), а не отдельной части. Рядовой сотрудник далеко не всегда знает, над чем работает тот или иной человек в соседней команде, хоть и в пределах одного проекта. У него есть свои узконаправленные задачи, которые он и выполняет. Вот и всё. И если надо узнать о состоянии проекта, темпах продвижения и т.п., то надо бы обратиться к тому, кто это знает, по-крайней мере должен бы знать.

Если вы с этим не столкнулись, то попробуйте поработать в команде хотя из человек 30-ти. Хотя бы.

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

Здравствуйте, leonty:
> G>Лидер != менеджер.
> Вам только так кажется.

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

> А тем временем этот лидер настаивает на определенных решениях,
> принимает решение тогда, когда все сомневаются или всем фиолетово, он
> инициативен,
> интересуется всеми аспектами деятельности своего проекта и т.д. Одной
> фразой — задаёт
> направление течения, то самое русло. Какая разница знает ли он при этом
> язык программирования
> или нет. Это и есть менеджер.

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

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

В общем-то, таким "менеджерам", как вы описали, обычно платят не больше. А — или столько же, или даже меньше. Это действительно project manager'ы, оные есть в микрософте.
Вы, похоже, с упорством, достойным лучшего применения, путаете "манагерус русикус традицикус" с хорошим менеджером. Российский менеджмент, увы, пока в большинстве случаев представляет из себя очень кривое зеркало нормального.

Здравствуйте, Огнеплюх, Вы писали:

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

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

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

M>Продолжаем тему тех. лида. Вот покрутился он так годик/другой, распараллелил активности так, чтоб было минимум коллизий внутри команды. Поработав над ключевыми частями кода, позволил увеличить производительность команды и стабильность кода. Заказчик принял решение расширит команду до 20 человек.
Вот это как раз и ужасает. Стремление не делать так, чтобы можно делать ту же работу командой из 5 человек, а всеми силами сделать так, чтоб заказчик был вынужден нанимать еще 20. Только делается это совершенно по другому, стабильность кода нельзя увеличивать ни в коем случае, а то и текущими силами можно производительность наращивать. То есть — хороший с точки зрения высшего руководства должен:
1) ни в коем случае не допустить кодогенерации рутинных операций, так как гораздо выгоднее выделять на это человека, тестера + выделять время на факс багов, произведенных человеком. Кодогенерацию в принципе применять можно, но надо написать ее так, чтобы с ее помощью понизить производительность команды, а не повысить;
2) не допускать рефакторинга, пресекать его на корню. Так как иначе слишком будет все понятно, и есть шанс что проект передадут другим;
3) постараться написать ключевые детали так, чтобы стать незаменимым. Специально насадить багов в ключевых библиотеках, чтоб заказчику ничего не оставалось делать, как продолжать пользоваться услугами конторы, так как новые пока разберутся, пройдет год.
4) особенно хорошо, если получится насадить багов типа циклических зависимостей между проектами. Так, что просто сборка проекта занимает целый день, без возможности автоматизировать (чтоб не автоматизировали случайно, можно подвязать кодогенерацию, причем исключительно из UI, исходники не давать, и писать исходники так, чтоб даже если бы заказчик их получил, от UI ему б не отвертеться было — никакой автоматизации. Кодогенерацию естественно написать так, что кодогенерацией пользоваться гораздо сложнее, строчек кода будет больше, и писать окажется гораздо дольше, чем делать без какой-нидь кодогенерации).

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

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

V>cvetkov пишет:
>>
>> чую этого не избежать.
V>Избежать. Просто из того, что я видел в 95% штаты безмерно раздуты (по
V>разным причинам).
V>И никогда не поверю, что то, что было описано marduk нельзя сделать
V>10-15 максимум специалистами за тот же срок и качественнее.

Раздутый штат необходим для поддержки идеологии: незаменимых нет.

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

G>>Лидер != менеджер.
L>Вам только так кажется.

Менеджер — это тот, кто официально управляет проектом (т.е. официально отвечает перед бизнесом за успешную реализацию проекта в целом).
Точка.

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

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

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Огнеплюх, Вы писали:

О>Не понимаю.
Деньги, что же ещё?

Здравствуйте, Огнеплюх, Вы писали:

О>Я об этом и говорю что в 90% случаев из хорошего специалиста получилось это "позорное лошье" и мне не понятна мотивация состоявшегося специалиста который решил прыгнуть в этот омут. Не понятно почему так стесняются быть специалистами , типа фразы "если в 30 ты не начальник то лох", помоему это какое-то недарозумение или как общественный грипп , стереотип. И мне кажется что он очень плохо влияет на отрасль, хорошие люди теряют себя, из полезного человека превращаются в менеджерский планктон, который в 90% в российской нашей действительности является сорняком а не полезным растением.

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

Здравствуйте, Тролль зеленый и толстый, Вы писали:

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

ТЗИ>Задавать по почте вопросы на знание языка было бы глупо, не правда ли?
Не правда. Глупо тратить свое время на то, что можно сделать в режиме offline.

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

О>Не понимаю.

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

О>Что интересного там находят — сидеть смотреть как другие работают,

Зачем смотреть как другие работают? Достаточно задать направление, описать цель и контроллировать получаемые результаты. Естественно, приходится что-то довыяснять (у заказчиков), что-то дообъяснять (разработчику), но при вменяемых заказчиках и разработчиках это всё происходит в виде ненапряжённой беседы. А беседовать приятнее, чем писать код .

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

Это ерунда. Пятиминутная беседа с вышестоящим начальством (чтобы выделил денег) и с системным администратором (чтобы купил и установил).

О>Быть прокладкой между ген.директором и разработчиками.

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

О>При этом зарплата не намного выше, а иногда у менеджеров даже меньше или равна зарплате программиста.

В России, практически всегда выше. Не говоря о перспективах дальнейшего его роста. Если мой отдел и направление будет расти (что весьма вероятно), то я буду расти как руководитель. Программисты же останутся теми же самыми программистами.

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

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

О>А начальник что, сидеть ждать когда же тебе кто-то зайдет в кабинет чтобы расставить росчерк на заявлении об отпуске/увольнении.

Ну, бумаги с росчерками об отпуске собирает не начальник, как правило, а рядовая сотрудница HR отдела .

О>Похарахорится при приеме на работу , построить из себя важную птицу — вдруг зауважает ктонить.

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

О>Ждать когда позвонит ген.дир и даст по голове , чтобы выскочить из своего кабинета и как попугай повторить это.

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

О>Следить за временем прихода/ухода...просто скукатища.

Следить за временем прихода/ухода — вообще бред. Это все и всегда говорили.

Если коротко про плюсы:
1. Всех перечисленных тобой минусов практически не существует. Если повезло работать с классными специалистами и людьми, то вообще всё замечательно.
2. Выше зарплата и интереснее перспективы (рост отдела — рост его руководителя, но не рост программистов).
3. Больше общения с людьми. Приходится общаться с людьми с разных конетенентов с разным мировоззрением, уровнем и культурой. Общение как правило приятное, так как люди вцелом приятные.
4. Больше ощущения результата, так как считаешь своим результатом и то, что делают другие. Когда был рядовым программистом, своим результатом считал только то, что сделал сам.
5. Меньше сложной и напряжённой работы (например, разобраться почему какая-то хрень работает не так как должна) и больше несложной и ненапряжённой (составить план, обсудить задачи, обсудить перспективы и высказать своё мнение и т.д.).

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

Можно сразу примеры? Что за инструмент-то такой?

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

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

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

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

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

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

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

Здесь речь идёт скорее не о "приписывании результата на свой счёт"... Ты никогда не замечал, что программисты практически никогда не говорят "мы", "команда" и т.д.? ну, по крайней мере я никогда не говорил... а менеджеры говорят, и чем дальше, тем больше. Короче говоря, менеджеры начинают чувствовать себя частью чего-то (компании, команды, отдела и т.д.). И здесь речь идёт о приписывании результата, а о том, что менеджер чувствует, что результат работы программиста — это и его результат тоже. По крайней мере я это чувствую .

О>Но подписывает он, HR-ка заявление на отпуск не имеет право подписать чужое.

Ок, скажем так. Я не подписываю, кто это делает — не знаю.

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

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

О>Хорошо , вот один из специалистов вдруг не появился на работе во время, или ушел сразу после обеда, кто должен ему выговор или замечание сделать ? Откуда этот человек узнает о том что это нужно сделать если у него нет механизма отслеживания прихода/ухода.

Если специалист при этом выдаёт нужный и качественный результат — честь ему и хвала. Если он результат не выдаёт, то какой же это специалист? Он же и под определение специалиста-то не подходит... Да и вообще, что за детский сад с выговороми за ранний уход и опоздания?

О>з.п. бывает как выше так и ниже и в среднем не сильно отличается от з.п. специалиста.

Хочешь так думать — думай .

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

Может придётся, может — не придётся... в любом случае, я написал лишь то, что общения становится больше.

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

Здесь у тебя какие-то непонятные слова, которые комментировать не хочется...

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

Пусть убеждение, что план=сферический конь в вакууме у тебя и останется, у меня нет желания тебя переубеждать. Торжественные речи произносятся крайне редко, думаю, что в нашей компании торжественную речь произносит только ген.директор на новогоднем корпоративе...
Про "разобраться почему хрень не работает — это как раз очень интересно" — спорить не буду. Я утверждал только то, что зачастую это бывает очень сложно и напряжённо. Бывает так, что это вытягивает все твои моральные силы, бывает, что после решения такой проблемы наступает полнейшая аппатия... а бывает и так, что после решения не чувствуешь никакого удовлетворения... У менеджера такой работы (сложной и напряжённой) — меньше. Лёгкой и ненапряжённой — больше.

Здравствуйте, Огнеплюх, Вы писали:

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

Они говорят на разных уровнях абстракции.
Программист мыслит в терминах кода. — дизайна, архитектуры, конкретных классов.
Аналитик мыслит в терминах бизнес-логики и use-case-ов.
Клиент мыслит в терминах например маркетинга.

Здравствуйте, Огнеплюх, Вы писали:

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

Здравствуйте, Огнеплюх, Вы писали:

О>Насчет увольнений — во время кризиса в нашей компании в основном порезали вакансии начальников, уволили 50% менеджеров. При этом разработчиков не тронули.

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

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

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



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

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


О>>Обеспечивает взаимодействие = промокашка. Любой заказчик или бизнес-аналитик как правило стремится напрямую общаться с разработчиком, а промежуточные звенья которые только вносят искажения в информацию им не интересны.
S>Ничего подобного! Ни в одной компании не видела, чтобы заказчик звонил программистам и говорил, что он хочет. У программистов совсем другая работа, они не должны слушать капризы, требования и т.п., они должны читать ТЗ и составлять алгоритмы, которые это реализуют. Судя по вашим словам, у меня сложилось ощущение, что вы работаете в компаниях, где бизнес-процессы не определены и отсюда вот такой хаус и смешение обязанностей.

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



О>>Опять же у менеджера нет никакого выбора — выбор за заказчиком и профи, за специалистами. Менеджер на поводу у заказчика, архитектора и других специалистов — что они скажут/сделают так и придется это воспринимать. Менеджер не может/не имеет профессиональной компетенции оспорить мнение архитектора о том какая должна быть архитектура.
S>То есть архитектор у вас — это типа бог, который может разработать архитектуру на миллион долларов для простейшего приложения, и менеджер ничего не может возразить? Это несерьезно! Менеджер как раз должен выслушать архитектора и оспорить архитектуру, если она недопустима по каким-либо причинам.

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

S>Опять же — если один разработчик скажет, что он будет кодить в Visual Stodio 6.0, а другой — Visual Studio 2005, менеджер должен промолчать? А вы в курсе, что во всех нормальных компаниях лицензии закупаются на определенные линейки продуктов и не разработчикам решить, в какой версии студии они будут кодить!

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

О>и з.п. меньше и авторитет — зачем тому кто меньше напрягается платить больше.

После этих слов, думаю, c тобой спорить бесмысленно . Это примерно также, как спорить с человеком, утверждающим, что ночью светлее, чем днём, так как светит и луна и лампочки и фонари.

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

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

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

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

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

G>>Лидер != менеджер.

L>Вам только так кажется. А тем временем этот лидер настаивает на определенных решениях,
L>принимает решение тогда, когда все сомневаются или всем фиолетово, он инициативен,
L>интересуется всеми аспектами деятельности своего проекта и т.д. Одной фразой — задаёт
L>направление течения, то самое русло. Какая разница знает ли он при этом язык программирования
L>или нет.
А молнии из жопы у него не вылетают?

L>Это и есть менеджер.
Нифига.

L>Если же вы под словом менеджер имеете в виду то, что озвучил топикстартер, то это ну не предмет
L>обсуждения, а просто способ пожалеть себя и пожаловаться ещё раз на "эту страну".
Нет.

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

S>Риски — это всегда работа менеджера там, где бизнес-процессы правильно организованы.

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

Здравствуйте, Огнеплюх, Вы писали:

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

Здравствуйте, Огнеплюх, Вы писали:

О> Я говорю о том что заказчик бы предпочел взаимодействовать напрямую с людьми которые работают над его детищем — минуя всякие передаточные звенья.

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

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

V>Мы говорили про команду программистов, а не про стадо баранов (с этим
V>лучше в горы). А команда программистов уже не может работать вразнобой.
V>А пути коллегиального принятия решений никто не отменял (про твою
V>вселенную не знаю)
Коллегиальное принятие решений работает в случае максимум 10 человек. на практике не более 5. и это только в том случае если люди выдержаные и способные к взаимопониманию.
если людей больше то в лучшем случае выделится неформальный лидер. но без формальных полномочий действовать он сможет только уговорами и авторитетом. т.е. на него можно забить и в ответ получить максимум общественное порицание.

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

L>Любой лидер, который начитает распоряжаться данными ему
L>полномочиями/ресурасами является менеджером.

Ты кого это ресурасами назвал?! Сам ты ресурас. А мы — люди, квалифицированные специалисты в большинстве своём, между прочим.

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

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

M>Здравствуйте, Огнеплюх, Вы писали:

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

F>>>Здравствуйте, Огнеплюх, Вы писали:

О>>>>Не понимаю.
F>>>Деньги, что же ещё?


M>У менеджмента может быть множество звеньев.

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

M>А вот давайте посмотрим на всё с позиции владельца компании. У него есть определенное количество сотрудников, допустим, человек 50 и нужно выполнить некоторую задачу. Как вы думаете, реально ли ему всем 50 описать, что каждый из них должен делать? Как по мне, там в этом есть некоторые трудности. К тому же ему еще нужно вдаваться во все мельчайшие детали проекта, на что просто времени не хватит. Если человек всего 5-6, то это выполнимо еще, но вот если 50, то надо как-то по-другому поступать. Вот и приходим к необходимости того, что нужен человек, который представляет команду в целом и которому уже можно ставить задачи. То есть уже нужно поставить задачу не 50 людям, а где-то 5-6. Это куда более выполнимо, к тому же вам надо только указать high-level направления, детали уже будут разбираться внутри команды. А те уже распределят задачи дальше, на каком-то этапе это уже вырисовывается в детально описанное задание индивидуально на каждого рядового исполнителя. В обратном порядке идет сбор информации о статусе работы.

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


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

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

M>Ну, и по поводу разных форс-мажорных ситуаций. Например, на стороне заказчика засбоило приложение, которое разрабатывает ваша команда. Заказчик, в данном случае, это дядька, который платит деньги за вашу работу и которого только интересует, чтоб система работала нормально. Будет ли он выискивать, кто там накосячил, Вася Пупкин или Петя Какашкин, или кто-то еще? Врядли. Ну и уж наверняка ему не особо охота высклушивать про какие-то там SQL, Java , веб-сервисы и прочее. Но разобраться надо. И кто-то команду разработчиков должен представлять, переговорить с заказчиком и уже дальше определить, кто это будет исправлять.

Ну я не спорю что менеджер тут участвует, но участвует как промокашка — девочка на телефоне. Звонит заказчик объясняет промокашке проблему, промокашка хлопая глазами бежит к специалистам и пытается им пересказать. Специалисты ему говорят — пусть посмотрить лог такой-то что там пишется, промокашка бежит к телефону и передает информацию ( дай бог без искажений ). Заказчик соотвественно выполняет и присылает результат, промокашка снова бежит к спецам — показывает. Спецы смотрят, и говорят пусть в файле таком-то изменить значение с 0 на 1.
То есть конечно хорошо что есть эта девочка на побегушках, но мне непонятно еще раз повторяю — почему специалисты хотят стать этими побегушками. Кто пустил эту фальшивую рекламу.



M>Да и просто, нужен человек, который мог бы видеть состояние проекта в целом (пусть и высокоуровнево, но охватывая все направления), а не отдельной части. Рядовой сотрудник далеко не всегда знает, над чем работает тот или иной человек в соседней команде, хоть и в пределах одного проекта. У него есть свои узконаправленные задачи, которые он и выполняет. Вот и всё. И если надо узнать о состоянии проекта, темпах продвижения и т.п., то надо бы обратиться к тому, кто это знает, по-крайней мере должен бы знать.

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


M>Если вы с этим не столкнулись, то попробуйте поработать в команде хотя из человек 30-ти. Хотя бы.

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


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

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

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

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

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

L>>Исключения бывают, раз на миллион.

I>Open Source? Или как раз потому, что их миллионы?

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

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

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

Здравствуйте, Тролль зеленый и толстый, Вы писали:

ТЗИ>Что я сказал?

Ты сказал:

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

Здравствуйте, Тролль зеленый и толстый, Вы писали:

ТЗИ>Ну вот кем надо быть, каким пигмеем, каким асоциальным существом, какое куриное сознание надо иметь, чтобы такое написать? Совершенно без причины, вот так грубо, оскорбить незнакомого человека?

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

ТЗИ>Ну кого я оскорбил своим сообщением, интересно? Что я сказал?

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

Здравствуйте, Тролль зеленый и толстый, Вы писали:

G>>Ты не попал в категорию хороших менеджеров.

ТЗИ>Увы мне, убогому. Видимо, ты причислен к этому Пантеону Великих.
Да нет, я пока не дорос до менеджмента.

ТЗИ>Тем не менее, еще раз: при чем тут мои менеджерские качества, если я этих людей еще даже не нанял на работу?
Как минимум при том что такие люди приходили на собеседование.
На кой вообще иметь дело со вчерашними студентами, если нужны хорошие программисты?
Лень было составить список вопросов для того чтобы заранее оценить уровень?
Или денег предлагалось столько что только студенты пойдут?

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

G>>ну и что получится в результате такой разработки?

SD>Google вот получился. На первый взгляд не так и плохо.

Гугл разрабатывался бесцельно?

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

Огнеплюх пишет:
>
> При этом зарплата не намного выше, а иногда у менеджеров
> даже меньше или равна зарплате программиста.
Иногда да, а вот в большинстве, что я видел, у начальника обычно раза в
полтора выше. Если такой вилки нет, то контора находится в постоянном
поиске менеджеров — часто висят такие объявления.

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

Здравствуйте, Огнеплюх, Вы писали:

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

О>Программисту конечно тоже не сахар в плане свободы действий, но хотя бы эта деятельность она более интеллектуальна и интересна, а главное что мне больше всего в ней нравится — это то что руками программиста создается результат, продукт.
Руками менеджера, который управляет проектом, тоже очень многое делается. Например, принимаются важные решения по развитию проекта и его архитектуре. Менеджер обеспечивает взаимодействие бизнес-аналитика и разработчиков, составляет ТЗ и т.п. Для этого всего надо иметь обширные знания и опыт как разработки, как и общения с людьми.

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

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

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

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

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

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

Вы спутали менеджера с традиционным российским project planner and status reporter.

Менеджер может гораздо больше. И зарабатывает он больше. Значительно.

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

SD>Вы спутали менеджера с традиционным российским project planner and status reporter.

SD>Менеджер может гораздо больше. И зарабатывает он больше. Значительно.

Ссылки на вакансии плиз. Максимум что я видел — 150 т.р., такие же потолки з.п. видел и у разрабочиков. Ген.директоров или ТОП-менеджеров не приводить, только вакансии промокашек ( среднее звено ).
Почему только среднее звено — т.к. именно в него почему-то стремяться спгырнуть люди достигшие статуса разработчика. В ген.директора им прыгнуть никто не даст — тут надо свое дело только открывать.

Но в основном все что начальник что программист < 100 000 р.
А если в рамках одной компании рассматривать то з.п. начальника +-10-20% от специалиста. Минус — тоже бывает, например у нас менеджер получает на 10 тыр. меньше чем старший программист и в 2 раза меньше архитектора — у архитектора 80 тыр. у менеджера 40 тыр.

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

E>Здравствуйте, Огнеплюх, Вы писали:

О>>Не понимаю.
E>Все просто. Меньше вероятность быть уволенным, меньше реальной ответственности, больше перспектив.

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

Огнеплюх пишет:
>
> А если в рамках одной компании рассматривать то з.п. начальника +-10-20%
> от специалиста. Минус — тоже бывает, например у нас менеджер получает на
> 10 тыр. меньше чем старший программист и в 2 раза меньше архитектора — у
> архитектора 80 тыр. у менеджера 40 тыр.
И соотвественно все его обязанности, отследить, чтобы народ не сильно
сачковал работу, обеспечить разработчиков кофе и чаем и т.п.?

De-Bill пишет:
>
> О>Следить за временем прихода/ухода...просто скукатища.
>
> Следить за временем прихода/ухода — вообще бред. Это все и всегда говорили.
Тем ни менее есть куча манагеров, которые считают оное своей основной
функцией.

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

G>Здравствуйте, Огнеплюх, Вы писали:


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

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


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

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

V>De-Bill пишет:
>> О>Следить за временем прихода/ухода...просто скукатища.
>> Следить за временем прихода/ухода — вообще бред. Это все и всегда говорили.
V>Тем ни менее есть куча манагеров, которые считают оное своей основной
V>функцией.

за 10 лет работы в IT не встретил ни одного такого. Либо я везучий, либы вы невезучий.

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

G>Здравствуйте, Огнеплюх, Вы писали:

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

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

Нет это вы не про здравомыслящего, а про сферического в вакууме.

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

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

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

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

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

Здравствуйте, Огнеплюх, Вы писали:

О>Здравомыслящий заказчик понимает нашу российскую ситуацию и то что у нас нет хороших управленцев — нет институтов. Поэтому практически любой начальник/менеджер в 99% случаев это такой же управленец , как студент архитектор или обезьяна с гранатой. Изредка занимающийся самообразованием.
О>Поэтому ему важно выбрать "врача" или разработчика лично.
Хм, забавно... вот я работаю в компании, где имеется около сотни крупных клиентов, которые пользуются продуктом... Вы считаете нормальным, если каждый из этих людей придет к нам в офис выбирать программистов, которые буду фиксить баги в этом ПО?

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

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

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


E>ИМХО в будующем количество начальства сведется к минимуму, и такой иерархии и такого количества начальства как сейчас не будет. ИМХО будет один человек — заказчик, который определяет что и как он хочет, а все распределение задачь, контроль и т.д. возможно будет неплохо автоматизировано. Тогда наступит счастье, есть проекты, в которых все делается подобным образом, когда роли меняются, нет выделенного главного, вроде такое работает довольно успешно.
ребята, вы из какой паралельной вселенной нам пишите?

Здравствуйте, Огнеплюх, Вы писали:

О>А начальник что, сидеть ждать когда же тебе кто-то зайдет в кабинет чтобы расставить росчерк на заявлении об отпуске/увольнении.

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

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


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

M>Те немногие планы, задачи и перпективы которые проходили через меня, всегда давали отдачу. Но труда и энергии сьедали очень хорошо.

С этим сложно поспорить. У всех бывают сложные задачи. Просто вспоминаю некоторые свои программерские задачи:
1. Разобраться почему серверная часть системы(миллионы строк кода, написанные совершенно незнакомыми людьми, живущими на другом континенте), работающей с сложном многопоточном и многопроцессном окружении, переодически непредсказуемо и непрогнозируемо падает. Когда нужно перерабатывать не только эти миллионы строк кода, но и исходники .NET Framework.
2. Разобраться, почему система оценки производных финансовых инструментов работает в 5 раз дольше предполагаемого. Тоже миллионы строк кода, многопоточное и многопроцессное окружение, несколько языков программирования, включая VB6 и т.д.

Короче говоря, сидишь по 10 часов в день в течении месяца, в голове всё плывёт, ночами всё это снится как в бреду... а главное, практически никакого удовлетворения от решения. Большие дядьки где-то через океан приехали на мининг на крутых машинах, произнесли речи, попожимали друг другу руки, подписали договоры о сотрудничестве... а тебя по плечу похлопал ген.директор и сказал — "Молодец!" .

Здравствуйте, Огнеплюх, Вы писали:

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


Ничего подобного.
По цепочке надо будет детализировать приказ о "начале освобождения северной осетии".
А иначе до солдата вообще будут доходить только политические решения
и он будет их игнорировать, что и будет верной реакцией.

Здравствуйте, Огнеплюх, Вы писали:

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

Наверху клиенты и им нужно регулярно от...ть :D Особенно это касается молодого бизнеса.

Здравствуйте, Огнеплюх, Вы писали:

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

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

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

Потому что все мы разные.

PS: Но это не про меня

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

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

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

Ну если также подходить — то у программиста растет количество его проектов и тем ценнее он для компании.


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

DB>Здесь речь идёт скорее не о "приписывании результата на свой счёт"... Ты никогда не замечал, что программисты практически никогда не говорят "мы", "команда" и т.д.? ну, по крайней мере я никогда не говорил... а менеджеры говорят, и чем дальше, тем больше. Короче говоря, менеджеры начинают чувствовать себя частью чего-то (компании, команды, отдела и т.д.). И здесь речь идёт о приписывании результата, а о том, что менеджер чувствует, что результат работы программиста — это и его результат тоже. По крайней мере я это чувствую .

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


О>>Но подписывает он, HR-ка заявление на отпуск не имеет право подписать чужое.
DB>Ок, скажем так. Я не подписываю, кто это делает — не знаю.

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




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

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

О>>Хорошо , вот один из специалистов вдруг не появился на работе во время, или ушел сразу после обеда, кто должен ему выговор или замечание сделать ? Откуда этот человек узнает о том что это нужно сделать если у него нет механизма отслеживания прихода/ухода.

DB>Если специалист при этом выдаёт нужный и качественный результат — честь ему и хвала. Если он результат не выдаёт, то какой же это специалист? Он же и под определение специалиста-то не подходит... Да и вообще, что за детский сад с выговороми за ранний уход и опоздания?

Ну я не видел еще компании где можно было бы просто уйти в обед с работы и ничего за это бы небыло. Точнее чтоб никто этого не заметил.

О>>з.п. бывает как выше так и ниже и в среднем не сильно отличается от з.п. специалиста.

DB>Хочешь так думать — думай .

Хочешь думать по другому — покажи вакансию компании где менеджеру платят намного больше спеца.

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

DB>Пусть убеждение, что план=сферический конь в вакууме у тебя и останется, у меня нет желания тебя переубеждать. Торжественные речи произносятся крайне редко, думаю, что в нашей компании торжественную речь произносит только ген.директор на новогоднем корпоративе...
DB>Про "разобраться почему хрень не работает — это как раз очень интересно" — спорить не буду. Я утверждал только то, что зачастую это бывает очень сложно и напряжённо. Бывает так, что это вытягивает все твои моральные силы, бывает, что после решения такой проблемы наступает полнейшая аппатия... а бывает и так, что после решения не чувствуешь никакого удовлетворения... У менеджера такой работы (сложной и напряжённой) — меньше. Лёгкой и ненапряжённой — больше.

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

Здравствуйте, Огнеплюх, Вы писали:

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

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

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

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

S>Здравствуйте, Огнеплюх, Вы писали:

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

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

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

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

Здравствуйте, Огнеплюх, Вы писали:

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

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

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

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

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

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

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

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

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

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

genre пишет:
>
>> > но большая команда даже с плохим
>> > менеджером.
>
> Работающие вразнобой никакого вменяемого продукта в принципе не
> создадут.
Мы говорили про команду программистов, а не про стадо баранов (с этим
лучше в горы). А команда программистов уже не может работать вразнобой.
А пути коллегиального принятия решений никто не отменял (про твою
вселенную не знаю)

> С менеджером, пусть и плохим, шансы заметно выше.
Плохой менеджер, во-первых угробит команду (видел не раз — за 3-6
месяцев). Во-вторых, направит разработку в русло не выхода ожидаемого
результата.

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

V>genre пишет:
>>
>>> > но большая команда даже с плохим
>>> > менеджером.
>>
>> Работающие вразнобой никакого вменяемого продукта в принципе не
>> создадут.
V>Мы говорили про команду программистов, а не про стадо баранов (с этим
V>лучше в горы). А команда программистов уже не может работать вразнобой.

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

V>А пути коллегиального принятия решений никто не отменял (про твою
V>вселенную не знаю)

Я подобное представляю для проекта, где работает человек 5-6. Там еще можно как-то всё и коллегиально решить и т.п.
А как вы представляете вот это всё для проекта в порядка 200 человек, причем не только программистов, а еще и аналитиков, QA, тестировщиков, системных администраторов? Причем продукт должен выйти качественным и вовремя. И при этом ни одного человека, который бы представлял некоторую группу людей в целом и через которого бы адресовались/решались различные вопросы, связанные с работой конкретной группы.

Интересно, можно ли нечто подобное получить?

Marduk пишет:
>
> Кто-то просто пишет медленно, кто-то вначале основательно всё обдумает и
> только потом что-то делает, а кто-то поставленные задачи решает
> достаточно быстро.
Так бы и сказал, что не вразнобой у тебя — это когда все пишут одинаково
средне и по качеству и по скорости.
Но это к команде обычно не относится, это ортогональные вещи.

>
> А как вы представляете вот это всё для проекта в порядка 200 человек,
> причем не только программистов, а еще и аналитиков, QA, тестировщиков,
> системных администраторов? Причем продукт должен выйти качественным и
> вовремя. И при этом ни одного человека, который бы представлял некоторую
> группу людей в целом и через которого бы адресовались/решались различные
> вопросы, связанные с работой конкретной группы.
Даже интересно стало, что за продукт вы такой толпой разрабатываете?
Ты про Microsoft?

Здравствуйте, Marduk:
> Вы пропустили один момент. Реальные риски озвучивают действительно
> технические специалисты. Но вот всё это собрать воедино, оценить и самое
> главное принять решение, после чего распределить задачи и
> проконтролировать их выполнение — это уже как раз задачи менеджера.

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

Здравствуйте, Ромашка, Вы писали:

Р>Это не манагер, это лидер. Это хорошо, если оно совпадает, но задачи
Р>менеджера, то-бишь управленца, совершенно в другом. Более того, роль
Р>лидера в подавляющем большинстве проектов играет не руководитель.

Неаргументированное обобщение.
В проектах с командой 5-7 человек именно так, как я сказал.
Если команда больше, то всё равно среди групп в 5 человек появляются
те, кто задаёт направление и его выдерживает и именно эти усилия по
выдерживанию направления, темпа и эффективности называются управлением
(менеджментом). Любой лидер, который начитает распоряжаться данными ему
полномочиями/ресурасами является менеджером.

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

G>Они говорят на разных уровнях абстракции.
G>Программист мыслит в терминах кода. — дизайна, архитектуры, конкретных классов.
G>Аналитик мыслит в терминах бизнес-логики и use-case-ов.
G>Клиент мыслит в терминах например маркетинга.

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

Здравствуйте, leonty:
> Неаргументированное обобщение.

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

> Любой лидер, который начитает распоряжаться данными ему
> полномочиями/ресурасами является менеджером.

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

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

Бред какой-то. Зачем нужен менеджер, не являющийся лидером и не
принимающий решений? У вас там agile что ли?

--
WBR,
Serge.

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

О>>Насчет увольнений — во время кризиса в нашей компании в основном порезали вакансии начальников, уволили 50% менеджеров. При этом разработчиков не тронули.

S>Это означает, что не начальники они, а лошье позорное. Потому как не смогли убедительно втереть гене про свою важность. Короче, это их факап по линии people skills.

Согласен. Вот в фирме моего знакомого повыгоняли 60% разработчиков. И выгнали только одного начальничка.

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

V>Marduk пишет:
>>
>> Кто-то просто пишет медленно, кто-то вначале основательно всё обдумает и
>> только потом что-то делает, а кто-то поставленные задачи решает
>> достаточно быстро.
V>Так бы и сказал, что не вразнобой у тебя — это когда все пишут одинаково
V>средне и по качеству и по скорости.
V>Но это к команде обычно не относится, это ортогональные вещи.

Вот о том я и говорю, что пока нас зовут Васями, петями, Колями и т.п. а не T-101 производства CyberDyne Systems у нас будет разное сочетание показателей скорость, качество. И это дело надо как-то синхронизировать.

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

V>Даже интересно стало, что за продукт вы такой толпой разрабатываете?

Ну уж явно не CD-ejector.

V>Ты про Microsoft?

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

Не только Microsoft творит подобные вещи. И у нас есть такие компании.

Marduk пишет:
>
> V>Даже интересно стало, что за продукт вы такой толпой разрабатываете?
>
> Ну уж явно не CD-ejector.
Но не скажу что — это тайна, Великая Коммерческая Тайна.

>
> V>Ты про Microsoft?
>
> А что, только Майкрософт разрабатывает продукты требующие большого
> количества людей? Есть множество других компаний, которые разрабатывают
> свой продукт и в штате которых сотни людей, которые так или иначе
> участвуют в разработке.
"Которые так или иначе участвуют в разработке" — великолепно сказано.
И кто после оного будет спорить с тем, что производительность у нас в
разы меньше американской.

Компаний множество, но не знаю ни одной такой, ни в России, ни в
Украине, ни в Беларуси.

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

Пусть меня накажут на оверквотинг — но это исключительно верное описание существующей действительности

Здравствуйте, hrensgory:
> Бред какой-то. Зачем нужен менеджер, не являющийся лидером и не
> принимающий решений?

Для распределения ответственности. Это сфера действий манагера. Ты,
Вася, отвечаешь за UI, а ты, Петя, за БД. И потом решения принимают Вася
с Петей в рамках своей компетенции, а чего выходит за рамки их
возможностей, то продавливается лидером (кто из них будет лидером —
неважно).

> У вас там agile что ли?

Да отвлекитесь от ИТ, это всегда и везде так, не только в ИТ.

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

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

SD>В общем-то, таким "менеджерам", как вы описали, обычно платят не больше. А — или столько же, или даже меньше. Это действительно project manager'ы, оные есть в микрософте.
SD>Вы, похоже, с упорством, достойным лучшего применения, путаете "манагерус русикус традицикус" с хорошим менеджером. Российский менеджмент, увы, пока в большинстве случаев представляет из себя очень кривое зеркало нормального.

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

Ромашка пишет:

>> Бред какой-то. Зачем нужен менеджер, не являющийся лидером и не
>> принимающий решений?
> Да отвлекитесь от ИТ, это всегда и везде так, не только в ИТ.

Слова "всегда и везде" подозрительны
Вы бы не могли название своей компании озвучить и профиль деятельности?

--
WBR,
Serge.

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

V>Marduk пишет:
>>
>> V>Даже интересно стало, что за продукт вы такой толпой разрабатываете?
>>
>> Ну уж явно не CD-ejector.
V>Но не скажу что — это тайна, Великая Коммерческая Тайна.

>>
>> V>Ты про Microsoft?
>>
>> А что, только Майкрософт разрабатывает продукты требующие большого
>> количества людей? Есть множество других компаний, которые разрабатывают
>> свой продукт и в штате которых сотни людей, которые так или иначе
>> участвуют в разработке.
V>"Которые так или иначе участвуют в разработке" — великолепно сказано.

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

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

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

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

V>Компаний множество, но не знаю ни одной такой, ни в России, ни в
V>Украине, ни в Беларуси.

Например, http://isd.dp.ua. Когда я там работал, то на одном из основных проектов было задействовано более 100 человек.

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

S>Здравствуйте, Огнеплюх, Вы писали:

О>>Насчет увольнений — во время кризиса в нашей компании в основном порезали вакансии начальников, уволили 50% менеджеров. При этом разработчиков не тронули.

S>Это означает, что не начальники они, а лошье позорное. Потому как не смогли убедительно втереть гене про свою важность. Короче, это их факап по линии people skills.

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

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

F>Здравствуйте, Огнеплюх, Вы писали:

О>>Не понимаю.
F>Деньги, что же ещё?

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

Можно также услышать — а как же специалисты смогут работать без менеджера , сразу возникает вопрос — а как тогда специалист который не может работать без менеджера — вдруг может стать менеджером ?

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

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

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

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

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

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

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

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

Хочешь попробуй провести эксперимент, посади штук хотя бы 6-8 своих коллег и попроси их договорится по какому-нибудь не сильно тривиальному вопросу.
Ну например пусть коллегиально выберут состав сборной россии по футболу. или что-нибудь в таком духе, чтоб вариантов выбора было много.
очень удивишься когда увидишь, что в 9 случаях из 10 договорится у них не получится.

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

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

Четко поставленных задач в природе не бывает начиная с некоторого уровня сложности.

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

А если в команде кроме тебя еще 10 человек?

Marduk пишет:
>
> V>"Которые так или иначе участвуют в разработке" — великолепно сказано.
>
> Помимо программеров непосредственно в разработке участвуют еще и
> тестировщики, QA да много кого еще.
А кого еще много?

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

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

>
> Например, http://isd.dp.ua <ISD>. Когда я там работал, то на одном из
> основных проектов было задействовано более 100 человек.
"Information Systems Development (ISD) — украинская IT-компания, которая
предоставляет услуги по проектированию, разработке, интеграции и
сервисной поддержке лабораторных информационных систем для медицинских
учреждений США и Канады."
Так что за продукт, где понадобилась сотня человек?

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

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

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

G>А если в команде кроме тебя еще 10 человек?
и что? у меня есть мой кусок работы, с которым я работаю. не факт, что эту работу мне дает менеджер. скорее уж тимлид будет решать, кто и что будет делать.

elmal пишет:
>
> В России же идет ставка на укрепление вертикали власти. Большинство
> организаций тоже работают по принципу вертикали власти. А при таком
> подходе, чем выше, тем спокойнее, главное найти крайнего.
А вот и иллюстрация: http://rsdn.ru/forum/message/3607965.aspx

Автор: vermont
Дата: 19.11.09

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

V>Marduk пишет:
>>
>> V>"Которые так или иначе участвуют в разработке" — великолепно сказано.
>>
>> Помимо программеров непосредственно в разработке участвуют еще и
>> тестировщики, QA да много кого еще.
V>А кого еще много?

Аналитики, автоматизаторы, также бывает выделяют отдельно людей, которые занимаются сборками билдов.

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

Системные администраторы, служба безопасности сюда тоже относится.

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

>>
>> Например, http://isd.dp.ua <ISD>. Когда я там работал, то на одном из
>> основных проектов было задействовано более 100 человек.
V>"Information Systems Development (ISD) — украинская IT-компания, которая
V>предоставляет услуги по проектированию, разработке, интеграции и
V>сервисной поддержке лабораторных информационных систем для медицинских
V>учреждений США и Канады."
V>Так что за продукт, где понадобилась сотня человек?

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

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

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

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

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

И>и что? у меня есть мой кусок работы, с которым я работаю. не факт, что эту работу мне дает менеджер. скорее уж тимлид будет решать, кто и что будет делать.

ну то есть против тимлида ты ничего не имеешь?
а кто по твоему должен координировать 5-10 тимлидов?

cvetkov пишет:
>
> V>Компаний множество, но не знаю ни одной такой, ни в России, ни в
> V>Украине, ни в Беларуси.
> если это правда то разговор может быть окончен.
Думаю да.
> не знать что в россии работают сан, моторола, и интел довольно тяжело.
Коль тебе хочется обсуждать американские конторы.

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

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

есть и чисто россейских примеров. тот-же яндекс. и куча телекомов еще есть.

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

V>Marduk пишет:
>>
>> Там много под-систем, но над основной системой работало больше сотни
>> разработчиков, тестировщиков, автоматизаторов. Это было, когда я там
>> работал.
V>И главное, все при деле.
V>А по сути, оное пишется максимум 10 человеками.
хватит ходить вокруг да около, начинаем меряться.
сколько проектов закончено, сколько было человек в них и каков объем работы?

и до кассы сколько лет в бизнесе?

чую этого не избежать.

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

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

G>>А если в команде кроме тебя еще 10 человек?
И>и что? у меня есть мой кусок работы, с которым я работаю. не факт, что эту работу мне дает менеджер. скорее уж тимлид будет решать, кто и что будет делать.
а тимлид это не менеджер? это такой джин из волшебной страны?

ps: запустите сюда луговского

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

V>Marduk пишет:
>>
>> Там много под-систем, но над основной системой работало больше сотни
>> разработчиков, тестировщиков, автоматизаторов. Это было, когда я там
>> работал.
V>И главное, все при деле.
V>А по сути, оное пишется максимум 10 человеками.

Ну конечно, ящик водки и еще 2-е друзей и за ночь русскую ОС забабахать.

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

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

cvetkov пишет:
>
> есть и чисто россейских примеров. тот-же яндекс. и куча телекомов еще есть.
С Яндексом словил, соглашусь. Да, одну контору нашел, учитывая
количество сервисов, им действительно нужно много народа.
А вот про телекомы, интересно стало, что же там такое пишут толпами пишут.

cvetkov пишет:
>
> чую этого не избежать.
Избежать. Просто из того, что я видел в 95% штаты безмерно раздуты (по
разным причинам).
И никогда не поверю, что то, что было описано marduk нельзя сделать
10-15 максимум специалистами за тот же срок и качественнее.
Приведу маргинальный пример: "Была такая гос.программа (НИОКР, детали
называть не буду, еще некоторые живы) по достаточно нетривиальной
тематике, так вот делали ее 2 человека, а мертвых и полумервых душ было
еще 18." Повторю — это был маргинальный пример.

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

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

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

S>>Риски — это всегда работа менеджера там, где бизнес-процессы правильно организованы.

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

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

Marduk пишет:
>
> Там побольше девелоперов было. Да и сама система многоуровневая. Плюс не
> забывайте, что подобные продукты — это не какая-то фриварка, которую
> написал от нефиг делать и забыл. Продукт развивается, дорабатывается
> фичами, новыми подсистемами, а при этом надо и поддерживать уже
> написанное. А разные заказчики просят для себя еще и фичи. И опять же,
> это всё надо тестировать, постоянно регрессионку делать.
А также уже неподдерживаемое переписывать постоянно, рефакторить все и т.д.

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

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

Огнеплюх пишет:
>
> Ну я не спорю что менеджер тут участвует, но участвует как промокашка —
> девочка на телефоне. Звонит заказчик объясняет промокашке проблему,
> промокашка хлопая глазами бежит к специалистам и пытается им
> пересказать. Специалисты ему говорят — пусть посмотрить лог такой-то что
> там пишется, промокашка бежит к телефону и передает информацию ( дай бог
> без искажений ). Заказчик соотвественно выполняет и присылает результат,
> промокашка снова бежит к спецам — показывает. Спецы смотрят, и говорят
> пусть в файле таком-то изменить значение с 0 на 1.
Хорошо сказано. И самое прикольное в данном, что эта промокашка часто не
передает точно, что ей сказали, а как испорченный телефон: свободно
излагает.

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

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

>>
>> а то так я могу заявить что и виндовс в десятером написать можно.
V>Linux один человек написал.

По оценкам объем работы, необходимый для написания ядра линкуса, составляет примерно 8000 человеко-лет. Уверяю вас, линус не настолько стар.

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

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

Lloyd пишет:
>
> V>Linux один человек написал.
>
> По оценкам объем работы, необходимый для написания ядра линкуса,
> составляет примерно 8000 человеко-лет. Уверяю вас, линус не настолько стар.
Как мне нравятся эти любители человеко-лет, человеко-дней,
человеко-секунд, человеко-наносекунд.
Да фиктивная это вещь, нужная только для одного, чтобы обосновать
заказчику, почему он столько заплатить должен, причем заказчику, который
понимает только затратный механизм создания чего-либо (таких очень и
очень много).

Здравствуйте, Огнеплюх, Вы писали:

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

B>>Проблема скорее в другом.
B>>В управленцы нередко попадают те, кто к этому не способен.

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

Хм...
Надеюсь ты не стремишься в начальники?
А иначе ведь пополнишь ряды тех, кого я имел ввиду

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

V>Marduk пишет:
>>
>> Там побольше девелоперов было. Да и сама система многоуровневая. Плюс не
>> забывайте, что подобные продукты — это не какая-то фриварка, которую
>> написал от нефиг делать и забыл. Продукт развивается, дорабатывается
>> фичами, новыми подсистемами, а при этом надо и поддерживать уже
>> написанное. А разные заказчики просят для себя еще и фичи. И опять же,
>> это всё надо тестировать, постоянно регрессионку делать.
V>А также уже неподдерживаемое переписывать постоянно, рефакторить все и т.д.

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

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

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

Вот только не надо про мифологию типа "10 крутых специалистов сделают всё".

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

B>Хм...
B>Надеюсь ты не стремишься в начальники?
B>А иначе ведь пополнишь ряды тех, кого я имел ввиду

Если вопрос про прокладку — 100% нет.
Что касается собственного дела — врятли, только если будут деньги/связи + идея которую я не смогу осилить один. Но в этом случае если у меня будут прокладки то получать они будут точно раза в 2 меньше чем начальный программист.

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

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

А управление нельзя заменить самоуправлением?

Здравствуйте, Огнеплюх, Вы писали:

О>Что касается собственного дела — врятли, только если будут деньги/связи + идея которую я не смогу осилить один. Но в этом случае если у меня будут прокладки то получать они будут точно раза в 2 меньше чем начальный программист.

Ну тогда ты рискуешь со своим бизнесом вылетить в трубу.
Вернее не рискуешь, а гарантированно вылетишь.

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


G>Несет, еще как несет.
G>Для неглобальных успехов/провалов материальный пряник/кнут в виде премий/лишения премий.
G>Для фатальных провалов — кнут в виде пинка под зад. Для успехов (в частности, вытащить проект, проваленный предыдущим недоменеджером из ж.) — повышение в должности и з/п.

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