Здравствуйте, Max Korotkov, Вы писали:
MK>А если еще глубже копнуть, то все эти определения уже сделаны другими людьми, а мы тут выдаем чужие мысли в своей обработке.-) Предлагаю прекратить обсуждение, или перенести его в "священные войны".-)
Ну, я-то выдаю свои собственные мысли, могу вас уверить . Когда я выдаю чужие, я даю ссылку на первоистчник.
А вообще — после 10 лет в индустрии появляюся и свои мысли, и свое мнение. Если эти мысли совпадают с мыслями других людей (а они во многих пунктах совпадают с Де Марко Peopleware и Джоелом on software, и находится вообще в духе "новой волны" "гуманитарного" менеджмента) — так это же замечательно, значит мы на правильном пути, не так ли?
Так зачем прекращать обсуждение таких важных и животрепещущих вопросов, которые плохо покрыты в литературе, кстати? Причем тут СВ?
Спасибо, очень хорошо сформулировано.
Деньги как единица измерения работы менеджера в большинстве случаев действительно годятся. Можно так и сказать, менеджер делает деньги
Однако это покрывает не все случаи. Например ИТ отдел какого нибудь банка который не делает продукты для продажи. 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> Или менеджер какого нибудь отдела кадров.
Текучесть кадров — процент уходящих в год.
В сущности — это простые примеры. Любой осмысленный бизнес-процесс имеет метрики, прямо или косвенно характеризующий его эффективность. Лучше и проще всего — когда на него удается прямым образом отнести выручку с затратами, это самая лучшая метрика.
Здравствуйте, Michael_E_Smrinov, Вы писали:
G>>ИМХО, единственный критерий успешности работы менеджера — это успех его команды.
M_E>Я где-то слышал такое выражение: M_E>Успех проекта — заслуга разработчиков, провал проекта — вина менеджера.
Это сказано для разработчиков, чтобы они не волновались Руководитель должен ставить разработчикам задачи, с которыми они точно справятся. Если проект удался = отличная работа! команда молодцы!, если провалился = руководитель неверно распорядился ресурсами, которые у него были.
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, Gaperton, Вы писали:
G>>из моей презентации.
AL>Кстати, как ваш проект продвигается?
С переменным успехом. У нас длительный и довольно рискованный проект. Только-только наладили формализованный процесс разработки, он проходит обкатку. Недавно корректировали курс, чтобы снизить риски и уложиться с первой итерацией до конца 2007 года по проекту системы на кристалле. Кое-что простое готовим к запуску небольшим тиражом в ближайший месяц-два — всякая мелочевка для военных, типа микросхем элементарной логики, ЦАП и АЦП.
Здравствуйте, Кодёнок, Вы писали:
Кё>Это сказано для разработчиков, чтобы они не волновались Руководитель должен ставить разработчикам задачи, с которыми они точно справятся. Если проект удался = отличная работа! команда молодцы!, если провалился = руководитель неверно распорядился ресурсами, которые у него были.
Задачи как раз можно ставить и с запасом, в чем то рисковать. А вот в своих расчетах учитывать риски.
Ну и в реальной жизни естественно и ответственность делится между людьми, и между удался проект и провалился есть много полутоновю
Плохим быть очень хорошо, а быть хорошим очень плохо.
Здравствуйте, Gaperton, Вы писали:
G>С переменным успехом. У нас длительный и довольно рискованный проект. Только-только наладили формализованный процесс разработки, он проходит обкатку.
А каким образом в вашем проекте вырабатываются требования к тому, что будет на выходе в конце и на промежуточных этапах? Даже вот так сформулирую вопрос:
— имеется ли ТЗ (или аналог);
— откуда берутся требования для ТЗ (если есть): изнутри организации, извне или так-и-эдак;
— выработкой требований занимается один оракул (внешний или внутренний) или группа (если группа, то в составе каких специалистов: R&D, кастомеры, маркетинг или как-то иначе);
— каким образом принимается решение о "правильности" отдельных требований: кем-то единолично "интуитивно" или иначе и на основании чего;
— каким образом требования ранжируются по приоритетности и важности, кем и на основании чего.
Думаю, поработав некоторое в "длительном и довольно рискованном", а также, насколько я понимаю, сложном проекте с большой исследовательской составляющей, Вы вряд-ли отошлете меня к матчасти
Кроме того, мне очень интересно, как Вы оцениваете планируемую длительность (трудоемкость) задач. Оговорюсь, что с "Методом Гапертона", опубликованным на rsdn, я знаком Вопрос в том, насколько и как(!) это применимо в Вашем текущем проекте. Спрашиваю еще и потому, что не очень понимаю, каким образом итерация может продолжаться год и более.
Наконец, любопытно, до какой степени происходит детализация задач, какова средняя планируемая длительность и удается ли не промахнуться по факту в среднем на группе связанных друг с другом задач (если есть большие промахи, то насколько).
По поводу "формализованного процесса" конечно же тоже интересно было бы узнать, как и что, хотя бы на уровне примерного flow с названиями стадий/этапов и артефактов на выходе каждого. Однако ведь не расскажете
G> Недавно корректировали курс, чтобы снизить риски и уложиться с первой итерацией до конца 2007 года по проекту системы на кристалле. Кое-что простое готовим к запуску небольшим тиражом в ближайший месяц-два — всякая мелочевка для военных, типа микросхем элементарной логики, ЦАП и АЦП.
Мелочевка? Им что, какие-то нетрадиционные цап и ацп нужны? Или это вопросы цены и разрешительного перечня? Просто, насколько мне представляется, сделать, скажем, быстрый цап/ацп с хорошей метрологией и удобными внешними "педалями" довольно сложно, а тем более довести полученное хотя бы до небольших серий. Кроме того, скажем, у вас получился классный ацп, но чтобы сделать на нем нормальный измерительный тракт, требуется куча качественной обвески типа ИОН, мультиплексоров, инструментальников, да и просто пассивных компонентов. Их то они иззарубежа что-ли собираются брать?
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, peoplewarrior, Вы писали:
P>>Ну и в реальной жизни естественно и ответственность делится между людьми
Кё>Ответственность не делится.
+100
P>>, и между удался проект и провалился есть много полутоновю
Кё>Вот для того ответственный и нужен, чтобы не получилось никаких полутонов. Он-то точно знает, делает он то или не то.
...и этот ответственный кроме права вето имеет исключительные права на принятия всех решений. Ответственность должна быть уравновешена полномочиями. Тот факт, что ответственный имеет право делегировать право принятия решений подчиненным, ничего не меняет — это тоже исключительно решение ответственного.
Здравствуйте, Кодёнок, Вы писали: Кё>Ответственность не делится.
Еще раз, в реальной жизни во многих организациях ответственность де факто делится. Не?
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
Здравствуйте, 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
Ну блин, ну я уже не знаю как объяснить. Это если я к примеру говорю что в реальной жизни людей на улицах грабят, а мне возражают — нет, нельзя людей грабить, книжка есть, уголовный кодекс, в ней написано что нельзя.
Абсолютно верно, когда деливераблы не выполняются, начинается бардак и стрелочничество. В идеальной организации где этот принцип на практике выполнен по всей вертикали власти, когда есть абсолютно четкая ответственность каждого на каждом уровне, когда полномочия делегированы строго в соответствии с задачами, когда каждый руководитель компетентен и не лезет не в свои дела, когда при этом зависимости между деливераблами сведены к минимуму этот принцип будет отлично работать. Вы знаета организации где это так?
За ссылку спасибо.
Плохим быть очень хорошо, а быть хорошим очень плохо.
Кё>>Ответственность не делится. P>Еще раз, в реальной жизни во многих организациях ответственность де факто делится. Не?
Не делится. Скорее "награды" спускаются по иерархии.
Кё>>Вот для того ответственный и нужен, чтобы не получилось никаких полутонов. Он-то точно знает, делает он то или не то. P>Да. Однако в реальных условия как раз и наблюдаются полутона. У вас такого нет?
В принципе, неплохо бы определять критерии успеха проекта. Хотя опять-же непонятно,
что если из нескольких критериев достигнуты не все. Так что да, неопределенность
тут может быть.
Здравствуйте, Кодёнок, Вы писали: Кё>Ответственность не делится.
А вот как вы ответите на такие вопросы:
1. Ответственность за профессиональный и личный рост разработчика несет:
а) 100% сам разработчик (если он делает это недостаточно хорошо, менеджер ищет другого)
б) 100% менеджер(если не хватает в нем каких-то скилов или личных качеств коучим до упора, отправляем на курсы, приставляем менторов, пока результат не будет достигнут. В случае неудачи подаем в отставку.)
в)Делится (Где то посередине между этими крайностями, причем что делать в каждом конкретном случае определяется жизненным опытом и мудростью.)
2. Будет ли одинаков ответ на вопрос 1 если смотреть на него с точки зрения разработчика и менеджера?
Мои ответы:
1. с точки зрения разработчика а.
1. с точки зрения менеджера — в.
2. очевидно нет
Плохим быть очень хорошо, а быть хорошим очень плохо.
. Когда я выдаю чужие, я даю ссылку на первоистчник. 
К чему задан вопрос "а как же scrum"? 
