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

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

P>А что делает менеджер?

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

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

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

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

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

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

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

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

G>>ИМХО, единственный критерий успешности работы менеджера — это успех его команды.

M_E>Я где-то слышал такое выражение:
M_E>Успех проекта — заслуга разработчиков, провал проекта — вина менеджера.

Это сказано для разработчиков, чтобы они не волновались Руководитель должен ставить разработчикам задачи, с которыми они точно справятся. Если проект удался = отличная работа! команда молодцы!, если провалился = руководитель неверно распорядился ресурсами, которые у него были.

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

P>Здравствуйте, Gaperton, Вы писали:
P>Спасибо за подробный ответ.
P>Я эту тему начинал не в том духе, что менеджеры бездельники, и не для выяснения куда уходит у кого рабочее время. Я сам менеджер, хотя и с не очень большим опытом, и знаю как иногда зашиваешься и на что конкретно время уходит.
P>Я наоборот пытаюсь результаты деятельности сформулировать как раз в терминах результата а не процесса, что бы можно было сказать к примеру — этот менеджер сделал столько то Х, где Х — мера полезной менеджерской работы, значит он хороший менеджер, а этот сделал меньше, значит не очень. Но чем больше я это пытаюсь сделать тем больше понимаю что это не тот критерий — во многом менеджер как раз отвечает за процесс.
P>С футбольным тренером кстати намного проще оценить результат чем с менеджером в крупной организации на долгосрочном проекте. Посмотрел на место комманды в турнирной таблице в конце года — и всё ясно.

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

ИМХО, единственный критерий успешности работы менеджера — это успех его команды. Успех команды складывается из...
1) Правильного позиционирования продукта/услуги, правильных свойств результата работы (управление требованиями + стратегия развития, учитывающая всевозможные риски)
2) Бизнес-процессы (степень зрелости процесса разработки — планы по срокам и качеству должны быть точными, должно делаться то, что нужно, с заданным качеством и в срок, менеджер уехал в отпуск — работа не должна встать), включая процесс найма на работу и работу с кадрами (аттестации).
3) Технологии — выбор базовых технологий (которые покупаются) должен быть обоснован, и не приводить к проблемам. В процесса работ должны накапливаться компетенции и интеллектуальная собственность в областях, соответствующих выбранной стратегии.
4) Люди. The right people решают все — именно они создают собственные технологии (3), разрабатывают и следуют процессу (2), и достигают результата (1). Обязанности и полномочия должны находится в баллансе (это регламентирует процесс (2)), и быть оптимально распределены по людям. The right people не просто должны быть наняты , процесс их поиска, фильтрации, и меры по снижению текучки (например, соцпакет), должны быть определены и работать на постоянной, а не авральной основе.

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

P>А что делает менеджер?

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

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

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

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

Кстати в Англии тот, кого у нас называют тренером, называется manager, не coach.

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

P>А что делает менеджер?

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

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

Спасибо за ответы.

G>Да нет матчасти-то толковой, вот в чем проблема . Рад был бы, если бы меня к ней кто отослал.

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

G>"Метод Гапертона" — применим для тим-лидов, и небольших проектов, и разработан, когда Гапертон был тим-лидом. Сейчас у нас есть кое-что получше. Скоро опубликую. В методах прогноза длительности, впрочем, поменялось мало чего.

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

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

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

G>Флоу очень близок по принципам построения к RUP. Стадий побольше — из-за специфики разработки аппаратуры.

А какие появляются специфические стадии, учитывающие наличие co-design-а? У нас практические вся работа -- сплошной co-design, и 99% проблем связано с неудовлетворительной координацией работы разных функциональных подразделений.

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

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

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

Согласен.

G>А хрен его знает. Мне кажется, это уже не наша проблема. Если интересно — у инженеров спрошу в понедельник.

Большинство производителей законченных устройств (модулей) аналогового ввода, скажем, для рынка АСУТП, используют одни и те же многоразрядные сигма-дельта АЦП, которые сами по себе имеют очень заманчивые характеристики, как по точности, так и по скорости. Однако точность модулей в большинстве своем не лезет ни в какие ворота и в лучшем случае эквивалентна использованию 9-10 разрядного АЦП. Это же относится и к скорости (времени опроса каналов). Поэтому вам, видимо, придется тщательно разрабатывать референс-дизайн на базе ваших микросхем совместно с разрешенной к использованию дополнительной обвеской и тестировать его вдоль и поперек, в том числе в заявленном диапазоне рабочих температур. Иначе обозначенная проблема станет вашей.

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, peoplewarrior, Вы писали:

P>>Ну и в реальной жизни естественно и ответственность делится между людьми

Кё>Ответственность не делится.

+100

P>>, и между удался проект и провалился есть много полутоновю

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

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

MK>А если еще глубже копнуть, то все эти определения уже сделаны другими людьми, а мы тут выдаем чужие мысли в своей обработке.-) Предлагаю прекратить обсуждение, или перенести его в "священные войны".-)

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

А вообще — после 10 лет в индустрии появляюся и свои мысли, и свое мнение. Если эти мысли совпадают с мыслями других людей (а они во многих пунктах совпадают с Де Марко Peopleware и Джоелом on software, и находится вообще в духе "новой волны" "гуманитарного" менеджмента) — так это же замечательно, значит мы на правильном пути, не так ли?

Так зачем прекращать обсуждение таких важных и животрепещущих вопросов, которые плохо покрыты в литературе, кстати? Причем тут СВ?

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

P>Ну и в реальной жизни естественно и ответственность делится между людьми

Ответственность не делится.

P>, и между удался проект и провалился есть много полутоновю

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

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

MK>Rule of thumb: "Ensure each deliverable has an owner."
MK>Иначе — бардак и стрелочничество. Во многих книгах сквозит эта идея.
MK>Хорошо расписано тут. Книге почти десять лет, но мало что изменилось. Я получал удовольствие и систематизировал знания и опыт, что у меня было. Прагматично составлено, по делу все.
MK>http://www.amazon.com/Surviving-Object-Oriented-Projects-Software-Development/dp/0201498340

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

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

За ссылку спасибо.

Очень легко ответить на подобный вопрос когда речь идет о девелопере: девелопер пишет код, создает программы и компоненты, пишет документацию, юнит тесты, отчеты о своей работе.

А что делает менеджер? Мне пока пришло на ум следующее. Менеджер делает:
Задачи для девелоперов.
Отчеты за комманду.
Собрания, где обсуждаются рабочие вопросы.
Табличку учета времени, работы, задач.
Коммандный дух.(это если он хороший менеджер)
Квалификацию и мотивацию сотрудников(не всегда)

Что ещё? И какие из этих вещей по вашему мнению главные?

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

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

P>А что делает менеджер? Мне пока пришло на ум следующее. Менеджер делает:
P>Задачи для девелоперов.
P>Отчеты за комманду.
P>Собрания, где обсуждаются рабочие вопросы.
P>Табличку учета времени, работы, задач.
P>Коммандный дух.(это если он хороший менеджер)
P>Квалификацию и мотивацию сотрудников(не всегда)

P>Что ещё? И какие из этих вещей по вашему мнению главные?

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

Все, что помогает решать задачу — и есть задача менеджера.

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

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

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

MK>Все, что помогает решать задачу — и есть задача менеджера.

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

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

P>Здравствуйте, Max Korotkov, Вы писали:

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

MK>>Все, что помогает решать задачу — и есть задача менеджера.

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

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

Притча: был на одном собеседовании. Большой начальник лет 55 заявил мне, что книжек он не читает из принципа.(к счастью — живет в США, к несчастью — руководит проектом, где часть людей в России работают). Мы друг другу сразу не понравились. Я ему задавал неприятные вопросы про проект — бил ниже пояса, как говорится. Мне хотелось на последок высказать три причины, почему его проект загнется(а он с тех пор начал быстро загибаться). Но промолчал. У него был опыт, у меня больше теории.
Мораль: нужно и то и другое.
Ссылка: http://61.132.102.124/books/PeopleWare_2ed.pdf
Лучше, чем там — мало кто скажет. А пересказывать 200+ страниц не станет никто. Вопрос у тебя конкретный, большой такой.-)
Есть и другие книги на эту тему. Мне еще нравятся статьи и книги Алистера Коуберна. Получаю истинное наслаждение от такого чтения. Его сайт: http://alistair.cockburn.us/index.php/Main_Page

Надеюсь, что помог.-)

P.S> Есть PMBok 3-rd edition на русском. Могу зашарить ненадолго. Пиши на мыло. Не знаю, есть в сети или нет. Мне друг принес.

За ссылки спасибо. От peopleware у меня ник образован так что пересказывать её мне не надо.
Меня скорее интересуют конкретные примеры, написанные простым человеческим языком. Чтобы я мог для себя(ну и иногда для других) сформулировать, что я уже делаю, и что я ещё могу сделать.

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

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

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

MK>Все, что помогает решать задачу — и есть задача менеджера.

А по-русски?

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

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

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Max Korotkov, Вы писали:

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

Кё>А что конкретно он делает? Ну то есть сидит менеждер на стуле, создает условия, а как именно — руками машет, или мыслью предметы двигает, или приказы выкрикивает налево-направо?

MK>>Все, что помогает решать задачу — и есть задача менеджера.

Кё>А по-русски?

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

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

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

Всего хорошего!

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

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

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Max Korotkov, Вы писали:

Кё>Ну главное-то в работе менеджера есть? На каком основании роль "менеджер" в одной компании называется так же и в другой. Если бы они были прямо настолько разные, что без специфики фирмы ничего не сказать, никому бы и в голову не пришло говорить, что у этих двоих одна роль. Напиши, что есть менеджер в этом смысле, в котором в фирме из 3х девелоперов один — менеждер, и в фирме из 100 некоторые тоже — менеджеры.

Я пока не готов писать книги о менеджменте.-)) А меньшим объемом тут не отделаешься.
Кое-что о различие проектов можно почитать у Алистера Коуберна в статье. Если провести аналогию на весь спектр проблем — то получите мое сообщение в предыдущем сообщении.-)
http://alistair.cockburn.us/index.php/Methodology_per_project

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

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

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

P>А что делает менеджер? Мне пока пришло на ум следующее. Менеджер делает:
P>Задачи для девелоперов.
P>Отчеты за комманду.
P>Собрания, где обсуждаются рабочие вопросы.
P>Табличку учета времени, работы, задач.
P>Коммандный дух.(это если он хороший менеджер)
P>Квалификацию и мотивацию сотрудников(не всегда)

P>Что ещё? И какие из этих вещей по вашему мнению главные?

Ну как бы менеджер продукт делает , а что же еще ?

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

Здравствуйте, Dr.Gigabit, Вы писали:
DG>Кстати в Англии тот, кого у нас называют тренером, называется manager, не coach.

То есть Моуринье в Челси и Венгер в Арсенале называются manager?

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



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

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

P>>А что делает менеджер?

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

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

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

G>Почему столь многие этого не замечают? Что ж, на то есть как минимум две причины.

G>Во-первых, что неоднократно упоминалось в литературе кстати, работа менеджера не видна со стороны. Если менеджер плох — его работы, понятное дело, не видно. Однако, что интересно — если менеджер хорош — его работы тоже не видно, так как команда работает хорошо как бы сама по себе . Тренер с менеджером были бы идиотами, если бы бегали за мячом по полю .

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

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

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

P>То есть Моуринье в Челси и Венгер в Арсенале называются manager?

Точно так

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

P>Здравствуйте, Dr.Gigabit, Вы писали:
DG>>Кстати в Англии тот, кого у нас называют тренером, называется manager, не coach.

P>То есть Моуринье в Челси и Венгер в Арсенале называются manager?

Именно.

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

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

P>>Здравствуйте, Gaperton, Вы писали:
P>>Спасибо за подробный ответ.
P>>Я эту тему начинал не в том духе, что менеджеры бездельники, и не для выяснения куда уходит у кого рабочее время. Я сам менеджер, хотя и с не очень большим опытом, и знаю как иногда зашиваешься и на что конкретно время уходит.
P>>Я наоборот пытаюсь результаты деятельности сформулировать как раз в терминах результата а не процесса, что бы можно было сказать к примеру — этот менеджер сделал столько то Х, где Х — мера полезной менеджерской работы, значит он хороший менеджер, а этот сделал меньше, значит не очень. Но чем больше я это пытаюсь сделать тем больше понимаю что это не тот критерий — во многом менеджер как раз отвечает за процесс.
P>>С футбольным тренером кстати намного проще оценить результат чем с менеджером в крупной организации на долгосрочном проекте. Посмотрел на место комманды в турнирной таблице в конце года — и всё ясно.

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

G>ИМХО, единственный критерий успешности работы менеджера — это успех его команды. Успех команды складывается из...
G>1) Правильного позиционирования продукта/услуги, правильных свойств результата работы (управление требованиями + стратегия развития, учитывающая всевозможные риски)
G>2) Бизнес-процессы (степень зрелости процесса разработки — планы по срокам и качеству должны быть точными, должно делаться то, что нужно, с заданным качеством и в срок, менеджер уехал в отпуск — работа не должна встать), включая процесс найма на работу и работу с кадрами (аттестации).
G>3) Технологии — выбор базовых технологий (которые покупаются) должен быть обоснован, и не приводить к проблемам. В процесса работ должны накапливаться компетенции и интеллектуальная собственность в областях, соответствующих выбранной стратегии.
G>4) Люди. The right people решают все — именно они создают собственные технологии (3), разрабатывают и следуют процессу (2), и достигают результата (1). Обязанности и полномочия должны находится в баллансе (это регламентирует процесс (2)), и быть оптимально распределены по людям. The right people не просто должны быть наняты , процесс их поиска, фильтрации, и меры по снижению текучки (например, соцпакет), должны быть определены и работать на постоянной, а не авральной основе.

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

Сложно что-либо добавить к этому расширенному определению-частному_видению. Мелочей всех не рассмотришь. Но вот пункт 4(right people) я бы поставил отдельно от всех остальных, а не просто на первое место. Да и в пункте 2 отметил роль спонсора проекта(из высшего руководства). Без этого менеджер будет решать проблемы общения с внешним миром "вязко". Или еще шире — нужна здоровая корпоративная культура. В гнилой конторе впустую уйдет бОльшая часть энергии менеджера...и мотивация со временем уйдет ниже плинтуса.

А если еще глубже копнуть, то все эти определения уже сделаны другими людьми, а мы тут выдаем чужие мысли в своей обработке.-) Предлагаю прекратить обсуждение, или перенести его в "священные войны".-)

Спасибо, очень хорошо сформулировано.
Деньги как единица измерения работы менеджера в большинстве случаев действительно годятся. Можно так и сказать, менеджер делает деньги
Однако это покрывает не все случаи. Например ИТ отдел какого нибудь банка который не делает продукты для продажи. R&D отдел железячной фирмы типа AMD или IBM. Или менеджер какого нибудь отдела кадров.

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

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

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

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

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

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

P>>А что делает менеджер?


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


а как же scrum? Предпологается, что комманда самоорганизующееся звено и сама решает, "что", "как" и "кому" делать. Manager (или scrum master) только фасилитирует этот процесс, следит, что бы "процесс шел", организует митинги и пр.

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

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


_>а как же scrum? Предпологается, что комманда самоорганизующееся звено и сама решает, "что", "как" и "кому" делать. Manager (или scrum master) только фасилитирует этот процесс, следит, что бы "процесс шел", организует митинги и пр.

Как сказал один мой коллега, "то ли я с ума сошель, то ли я всю жизнь бил тюпой" К чему задан вопрос "а как же scrum"? Вы по какому-то поводу мне возражаете? Если да, то по какому именно? Что сказать-то хотели, короче?

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

P>Однако это покрывает не все случаи. Например ИТ отдел какого нибудь банка который не делает продукты для продажи.

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

P>R&D отдел железячной фирмы типа AMD или IBM.
Зависит от того, что делает этот отдел, и можно ли отнести прибыль и выручку по продуктам на затраты этого отдела.

P> Или менеджер какого нибудь отдела кадров.
Текучесть кадров — процент уходящих в год.

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

из моей презентации.

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

G>из моей презентации.

Кстати, как ваш проект продвигается?

G>ИМХО, единственный критерий успешности работы менеджера — это успех его команды.

Я где-то слышал такое выражение:
Успех проекта — заслуга разработчиков, провал проекта — вина менеджера.

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

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

G>>из моей презентации.

AL>Кстати, как ваш проект продвигается?

С переменным успехом. У нас длительный и довольно рискованный проект. Только-только наладили формализованный процесс разработки, он проходит обкатку. Недавно корректировали курс, чтобы снизить риски и уложиться с первой итерацией до конца 2007 года по проекту системы на кристалле. Кое-что простое готовим к запуску небольшим тиражом в ближайший месяц-два — всякая мелочевка для военных, типа микросхем элементарной логики, ЦАП и АЦП.

Здравствуйте, Кодёнок, Вы писали:

Кё>Это сказано для разработчиков, чтобы они не волновались Руководитель должен ставить разработчикам задачи, с которыми они точно справятся. Если проект удался = отличная работа! команда молодцы!, если провалился = руководитель неверно распорядился ресурсами, которые у него были.

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

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

G>С переменным успехом. У нас длительный и довольно рискованный проект. Только-только наладили формализованный процесс разработки, он проходит обкатку.

А каким образом в вашем проекте вырабатываются требования к тому, что будет на выходе в конце и на промежуточных этапах? Даже вот так сформулирую вопрос:
— имеется ли ТЗ (или аналог);
— откуда берутся требования для ТЗ (если есть): изнутри организации, извне или так-и-эдак;
— выработкой требований занимается один оракул (внешний или внутренний) или группа (если группа, то в составе каких специалистов: R&D, кастомеры, маркетинг или как-то иначе);
— каким образом принимается решение о "правильности" отдельных требований: кем-то единолично "интуитивно" или иначе и на основании чего;
— каким образом требования ранжируются по приоритетности и важности, кем и на основании чего.

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

Кроме того, мне очень интересно, как Вы оцениваете планируемую длительность (трудоемкость) задач. Оговорюсь, что с "Методом Гапертона", опубликованным на rsdn, я знаком Вопрос в том, насколько и как(!) это применимо в Вашем текущем проекте. Спрашиваю еще и потому, что не очень понимаю, каким образом итерация может продолжаться год и более.

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

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

G> Недавно корректировали курс, чтобы снизить риски и уложиться с первой итерацией до конца 2007 года по проекту системы на кристалле. Кое-что простое готовим к запуску небольшим тиражом в ближайший месяц-два — всякая мелочевка для военных, типа микросхем элементарной логики, ЦАП и АЦП.

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

Здравствуйте, Кодёнок, Вы писали:
Кё>Ответственность не делится.
Еще раз, в реальной жизни во многих организациях ответственность де факто делится. Не?

P>>, и между удался проект и провалился есть много полутоновю

Кё>Вот для того ответственный и нужен, чтобы не получилось никаких полутонов. Он-то точно знает, делает он то или не то.
Да. Однако в реальных условия как раз и наблюдаются полутона. У вас такого нет?

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

P>Здравствуйте, Кодёнок, Вы писали:
Кё>>Ответственность не делится.
P>Еще раз, в реальной жизни во многих организациях ответственность де факто делится. Не?

Rule of thumb: "Ensure each deliverable has an owner."
Иначе — бардак и стрелочничество. Во многих книгах сквозит эта идея.
Хорошо расписано тут. Книге почти десять лет, но мало что изменилось. Я получал удовольствие и систематизировал знания и опыт, что у меня было. Прагматично составлено, по делу все.
http://www.amazon.com/Surviving-Object-Oriented-Projects-Software-Development/dp/0201498340

Кё>>Ответственность не делится.
P>Еще раз, в реальной жизни во многих организациях ответственность де факто делится. Не?

Не делится. Скорее "награды" спускаются по иерархии.

Кё>>Вот для того ответственный и нужен, чтобы не получилось никаких полутонов. Он-то точно знает, делает он то или не то.
P>Да. Однако в реальных условия как раз и наблюдаются полутона. У вас такого нет?

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

Здравствуйте, Кодёнок, Вы писали:
Кё>Ответственность не делится.

А вот как вы ответите на такие вопросы:
1. Ответственность за профессиональный и личный рост разработчика несет:
а) 100% сам разработчик (если он делает это недостаточно хорошо, менеджер ищет другого)
б) 100% менеджер(если не хватает в нем каких-то скилов или личных качеств коучим до упора, отправляем на курсы, приставляем менторов, пока результат не будет достигнут. В случае неудачи подаем в отставку.)
в)Делится (Где то посередине между этими крайностями, причем что делать в каждом конкретном случае определяется жизненным опытом и мудростью.)
2. Будет ли одинаков ответ на вопрос 1 если смотреть на него с точки зрения разработчика и менеджера?

Мои ответы:
1. с точки зрения разработчика а.
1. с точки зрения менеджера — в.
2. очевидно нет

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

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

G>>С переменным успехом. У нас длительный и довольно рискованный проект. Только-только наладили формализованный процесс разработки, он проходит обкатку.

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

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

AL> — откуда берутся требования для ТЗ (если есть): изнутри организации, извне или так-и-эдак;
Требования собираются во взаимодействии с потенциальными потребителями, одновременно с уточнением объема спроса. Это сложно — необходимо идентифицировать всех участников "пищевой цепочки", и выбрать из них правильные организации для взаимодействия. Например, прямой потребитель (производство), как это не странно, не всегда может являться источником требований для систем на кристалле, которые применяются в их изделиях.

AL> — выработкой требований занимается один оракул (внешний или внутренний) или группа (если группа, то в составе каких специалистов: R&D, кастомеры, маркетинг или как-то иначе);

Выработка требований для продуктов — задача маркетинга. Обычно за требования отвечает product manager, при их составлении и проверке участвуют все типы специалистов, и все типы компаний, завязанные в выбранном нами секторе рынка.

AL> — каким образом принимается решение о "правильности" отдельных требований: кем-то единолично "интуитивно" или иначе и на основании чего;

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

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

AL>Думаю, поработав некоторое в "длительном и довольно рискованном", а также, насколько я понимаю, сложном проекте с большой исследовательской составляющей, Вы вряд-ли отошлете меня к матчасти

Да нет матчасти-то толковой, вот в чем проблема . Рад был бы, если бы меня к ней кто отослал.

AL>Кроме того, мне очень интересно, как Вы оцениваете планируемую длительность (трудоемкость) задач. Оговорюсь, что с "Методом Гапертона", опубликованным на rsdn, я знаком Вопрос в том, насколько и как(!) это применимо в Вашем текущем проекте. Спрашиваю еще и потому, что не очень понимаю, каким образом итерация может продолжаться год и более.

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

"Метод Гапертона" — применим для тим-лидов, и небольших проектов, и разработан, когда Гапертон был тим-лидом. Сейчас у нас есть кое-что получше. Скоро опубликую. В методах прогноза длительности, впрочем, поменялось мало чего.

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

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

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

Флоу очень близок по принципам построения к RUP. Стадий побольше — из-за специфики разработки аппаратуры.

G>> Недавно корректировали курс, чтобы снизить риски и уложиться с первой итерацией до конца 2007 года по проекту системы на кристалле. Кое-что простое готовим к запуску небольшим тиражом в ближайший месяц-два — всякая мелочевка для военных, типа микросхем элементарной логики, ЦАП и АЦП.

AL>Мелочевка? Им что, какие-то нетрадиционные цап и ацп нужны? Или это вопросы цены и разрешительного перечня?

Это именно вопрос цены и разрешительного перечня .

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

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

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

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

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

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

Кё>>Ответственность не делится.
P>А вот как вы ответите на такие вопросы:
P>1. Ответственность за профессиональный и личный рост разработчика несет:

Короче, я сначала написал много, а длинные тексты никто не читает, поэтому стёр, написал меньше, стёр, написал мало, стёр, на самом деле я тут напился абсента и спать хочу

1. Ответственность поделить невозможно, ибо она бывает только перед собой. Ответственность перед другим — иллюзия.
2. У каждого свои цели. Единая цель у нескольких человек — иллюзия. Типа профессионального роста разработчика.
3. Sapienti sat.
4. Завтра больше, если не sapient или не sat

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

G>>"Метод Гапертона" — применим для тим-лидов, и небольших проектов, и разработан, когда Гапертон был тим-лидом. Сейчас у нас есть кое-что получше. Скоро опубликую. В методах прогноза длительности, впрочем, поменялось мало чего.

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

Готово. Методика здесь — http://rsdn.ru/Forum/Message.aspx?mid=2302507&only=1

Автор: Gaperton
Дата: 15.01.07

ЗЫ: Для решения проблем координации:
1) вводишь в план специальный тип целей, которые будут общими для нескольких подразделений.
2) Применяешь на регулярной основе методику перекрестных инспекций дизайна и архитектуры, включая людей разных подразделений в качестве инспекторов. Методика здесь — http://rsdn.ru/Forum/Message.aspx?mid=1358322&only=1

Автор: Gaperton
Дата: 01.09.05

Здравствуйте, Кодёнок, Вы писали:
Кё>1. Ответственность поделить невозможно, ибо она бывает только перед собой. Ответственность перед другим — иллюзия.
Что это, бывает ответственность перед другими, материальная например. Замечательно между прочим делится.
Ответственность перед собой тоже бывает, и тоже прекрасно делится.

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

Кё>3. Sapienti sat.
Кё>4. Завтра больше, если не sapient или не sat
Не понял, буквы какие то нерусские.

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

P>Здравствуйте, Кодёнок, Вы писали:
Кё>>1. Ответственность поделить невозможно, ибо она бывает только перед собой. Ответственность перед другим — иллюзия.
P>Что это, бывает ответственность перед другими, материальная например. Замечательно между прочим делится.
P>Ответственность перед собой тоже бывает, и тоже прекрасно делится.

Материальная ответственность, это не ответственность, это название наказания. Когда ответственность есть, проект удается и материальная ответственность не наступает. Когда её УЖЕ нет, проект бросают или делают кое-как, и наступает "материальная ответственность". Наказание и награды делятся.

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

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

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

1. Один хлопнет дверью, а второй один закончит проект.
2. Споры не кончатся и проект не будет сделан.
3. Один главный, он по умолчанию всегда прав (за ним последнее слово). Что равносильно тому, что делающий опять же один, а второй лишь помощник, как наемные рабочие, хоть и с большими полномочиями и работает за процент. Вы должно быть часто встречали как работники отзываются (негативно) о начальнике что он считает себя самым умным и всегда правым.

Еще варианты? Как ни крути, но сделан проект будет только если делающий — ОДИН, и никто ему не мешает.

Кё>>3. Sapienti sat.

Умному достаточно Философская часть не удалась, ну и ладно. Если думать долго и упорно, то придешь к тому, что ответственность — это договор с самим собой.

Здравствуйте, Кодёнок, Вы писали:

Так все таки в проекте с домиком, где отвестсвенный один, у него ответственность перед кем? Перед самим собой? И это заказчик назначил его ответственным перед самим собой? А мог бы назначить двоих, и тогда бы каждый отвечал перед собой, или перед обоими? Или ответственнен он все таки перед заказчиком?

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

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

P>Так все таки в проекте с домиком, где отвестсвенный один, у него ответственность перед кем? Перед самим собой? И это заказчик назначил его ответственным перед самим собой? А мог бы назначить двоих, и тогда бы каждый отвечал перед собой, или перед обоими? Или ответственнен он все таки перед заказчиком?

Ни перед кем. Есть договор, между такими-то и такими-то. А есть ответственность, как отношение к своим обязанностям по договору. Если она есть, то исполнение гарантировано, помешать может только форс-мажор.

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

P>До сих пор не понимаю с чем в этом утверждении можно спорить.

Если тебе просто надо чтобы с тобой не спорили, то это запросто.

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

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

P>А что делает менеджер? Мне пока пришло на ум следующее. Менеджер делает:
P>Задачи для девелоперов.
P>Отчеты за комманду.
P>Собрания, где обсуждаются рабочие вопросы.
P>Табличку учета времени, работы, задач.
P>Коммандный дух.(это если он хороший менеджер)
P>Квалификацию и мотивацию сотрудников(не всегда)

P>Что ещё? И какие из этих вещей по вашему мнению главные?

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

Здравствуйте, Кодёнок, Вы писали:

Кё>Если тебе просто надо чтобы с тобой не спорили, то это запросто.

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

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

P>Здравствуйте, Кодёнок, Вы писали:

P>Так все таки в проекте с домиком, где отвестсвенный один, у него ответственность перед кем? Перед самим собой? И это заказчик назначил его ответственным перед самим собой? А мог бы назначить двоих, и тогда бы каждый отвечал перед собой, или перед обоими? Или ответственнен он все таки перед заказчиком?

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

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

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

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

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

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

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

А>В английском языке есть такое слово — derive. Если его переводить как делить со смыслом выводить, порождать, и т.п., тогда можно говорить, что ответственность делится .

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

Не всегда можно назначить одного ответственного, и не всегда это делают даже когда можно.

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

P>Не всегда можно назначить одного ответственного

Всегда можно.

Здравствуйте, Кодёнок, Вы писали:
P>>Не всегда можно назначить одного ответственного

Кё>Всегда можно.

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

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

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

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

P>Не всегда можно назначить одного ответственного, и не всегда это делают даже когда можно.

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

P>Не всегда можно назначить одного ответственного, и не всегда это делают даже когда можно.

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

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

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

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

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

А>Всегда можно не назначить одного ответственного . К сожалению, не знаю, почему руководители этим постоянно пользуются . Может потому, что в этом случае можно не беспокоиться за свое место?



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