1) Первичен всегда здравый смысл.
1.1) Все принимаемые организационные решения в идеале должны исходить из здравого смысла.
2) Когда люди уже не способны (по объективным/субъективным причинам) исходить из голого здравого смысла, начинается формализация.
[OFF: Отсюда кстати растёт т.н. "делегирование полномочий" — это совершенно верная попытка как можно дольше оставлять ситуацию на условно идеальном уровне "здравого смысла"]
3) Формализация может мешать или не мешать работе. Сделать так, чтобы формализация не мешала работе — задача менеджмента, включая и тимлида.
4) Если принятая формализация не помогает различить раздолбая от хорошего работника — она никакая. Виноваты те, кто ввёл такую систему.
Отсюда два варианта:
— Если текущая ситуация не очень парит, то и фиг с ней.
— Если текущая ситуация сильно мешает работать — надо отвечать себе сосем на другие вопросы(типа "to be or not to be") — и форум rsdn-а тут не помощник
Здравствуйте, kochmin_alexandr, Вы писали:
_>Ежедневный отчет о проделанной работе. И желательно в письменном (электронном) виде. Пусть даже на это уйдет час времени.
Постарайтесь не переусердствовать
Так как программеров, обычно, напрягают такие заморочки. И при прочих равных условиях они уйдут туда, где каждый день отчеты писать не надо.
Кстати, если на это дело будет уходить час в день — свалят многие. Так как сомневаюсь, что разработчики, заботящиеся о своем профессиональном уровне, будет готовы тратить 250 часов в год на такую работу
Да, еще — один из моих учителей однажды сказал мне на подобный вопрос:
Если ты не можешь доверять своей команде — ты плохой руководитель.
Здравствуйте, xtile, Вы писали:
X>Каждую неделю минисовещание с тимлидом и pm. (обсуждаются задачи на неделю, прикидываются сроки на каждую. Если задача большая — разбивается на части, для выполнения которых нужно 1-2 дня).
У нас прoхoдят сoвeщания каждую нeдeлю всeм пoдoтдeлoм (у нас нe сoфт-oриeнтирoванная фирма) и oбсуждаются ВСE тeкущиe прoeкты (пoрядка 30-ти — 40-а). Начальник пoдoтдeла пoлучаeт инфoрмацию o тoм, какиe прoeкты нe укладываются в срoки или у кogo нeт рабoты. Пишeтся прoтoкoл измeнeния прoeктoв за нeдeлю.
X>Ежедневно — отчеты о проделанной работе (контроль соблюдения сроков). В отчете должно быть зафиксировано все, что отняло более получаса времени.
Практичeски тoжe самoe, тoлькo у нас всё этo oрганизoванo как oтдeльная систeма а-ля "Timesheets". Eсть списoк прoeктoв (кoтoрый автoматичeски закрeпляeтся за рабoтникoм), eсть дни мeсяца и надo прoстo в кoнцe дня затрачeныe часы раскидать пo таскам прoeктoв. На этoй oснoвe фoрмируются различныe oтчёты o затрачeнoм врeмeни/финансах итд.
Впoлнe удoбнo и нe трeбуeт мнoгo врeмeни.
Здравствуйте, Constructor, Вы писали:
C>Здравствуйте! C>В конторе складывается такая ситуация. C>Составляется квартальный план, с учетом мнения разработчика. Т.е., по общему мнению руководителя и разработчика плотный, но выполнимый график.
Если вы будете составлять план на пятилетку, то его вообще никто кроме редких бездельников, которые изначально утроили сроки выполянть не будет.
И не означает ли "выполнимый" в данном случае — "можно успеть, если поднапрячься и не отвлекться ни на что другое"? Если да — а судя по письму в целом это так, то чего же вы хотите? Намечаете план на длительный срок — изначально закладывая в условия его выполнения мину в виде очень жёсткого условия, которое почти наверняка окажется нарушенным, не даёте запас на ошибки и потом удивляетесь — почему ничего не вышло?
C>Далее, по прошествии некоторого времени, руководитель выдает разработчику дополнительное срочное, жизненно важное задание. Обычно не надолго, на 2-3 недели. За квартал так может быть 1-2 раза. Такие задания обычно не вносятся в план. C>По прошествии квартала разработчик отчитывается за свой первоначальный план, а дополнительные задания упускаются из рассмотрения. Чаще всего, естественно, разработчик свой план выполнить неуспевает.
Ну так сами себе злобные бакланы! То есть из 14 недель в квартал человек 4-6 недель т.е. 30-45% времени человек занимается "срочными заданиями" — которые вообще не учитываются в плане — и как следует из письма вообще нигде не учитываются, а потом с него требуют план в полном объёме? Что бы понять что вы делаете — поездите на работу с месяц из соседненго города за 200-300 км от Вашего. Получите весьма наглядное представление о требованиях, которые предявляете к другим...
Кстати учтите — что после занятия 2, а тем более 3 недели "каким-нибудь срочным заданием" человеку потребуется 3-5 дней, что бы полностью восстановить в голове тот уровень понимания и видения задач изначального плана, который у него был до прерывания. Это время следует прибавить ко времени задания, при оценки времени, которое будет затрачено на его исполнения — на этапах планирования и приёмки работ.
Если следовать ЛЮБОЙ методологии — то при внесении подобного "задания" — весть план должен пересматриваться и корректироваться. А после его завершения — должен пересматриваться и корректироваться ещё раз. Судя по всему — у Вас этого не делается, по причине лени и раздолбайства менеджеров, а так же по причине не желания менеджеров выслушивать от руководства ласковые слова по поводу изменения сроков — этим же руководством и заказанные. Гораздо проще сослаться на то, что "неизвестно кто у нас в конторе и чем занимается" и "разработчики разгильдяи"
C>Поднимается вопрос о том, что разработчик — разгильдяй.
В то время, как надо поднимать вопрос о служебном соответствии его начальника.
В бизнесе двано известна простая истина — не бывает разгильдяев исполнителей. Бывают разгильдяи начальники.
C>Это с одной стороны. Я сам часто бываю таким разработчиком.
C>С другой стороны, было уже несколько раз, что я выступал в роли руководителя.
Похвально.
C>Я предлагал человеку сделать определенную работу. Вместе мы обсуждали объем и сроки. Вроде бы было полное согласие. И после этого план свой он не выполнял. Я вроде следил, чтобы никаких других работ у него не было.
- Вась, а Вась — скока тебе времени надо что бы этот XML файл прочитать?
— Ну дня 3-4
— Да ты что?! Лох что ли — тут же работы дня два от силы!
— М..мм..мм... Ну наверное да....
— Вот! Это уже лучше! Что там у нас следующее?
C>Складывается такая ситуация: практически не отслеживается, кто, когда и чем занимался. Точно могу сказать, что разные люди у нас выполняют совершенно разный объем работ. Разные люди разное время проводят в инете. Разные люди проявляют разный интерес к освоению новых технологий и разную степень стремления к повышению своей квалификации.
Это факт. С которым приходится иметь дело как с рассветом и закатом.
C>Всх ровнять под одну гребенку нехорошо... Хотелось бы научиться ненавязчиво контролировать, кто чем занимается, кто сталкивается с какими трудностями. Научиться достоверно определять: если человек не справился с работой, то это из-за 1) разгильдяейства или 2) его еще слабой подготовки или 3) недооценки сложности задачи. C>Причем чтобы свои оценки можно было четко обосновать. И руководителю, и подчиненному.
"Контролировать" это всего лишь средство. А какова цель?
C>Вот такая у вот проблема... Поделитесь опытом, пожалуйста!
Здравствуйте, LaptevVV, Вы писали:
LVV>По многолетнему опыту могу сказаить: после всех договоренностей и согласий можно смело умножать сроки на 2 (а лучше — на Пи ) — тогда это будет похоже на реальный срок выполнения. И это при добросовестном отношении к работе.
"На пи". Для того, чтобы проверить реалистичность плана, достаточно делать прогноз не только времени, но и объема (в любой метрике. Строки кода — адекватная и одна из самых стабильных метрик, как показывает практика, что-бы там про них не говорили). И держать "продуктивность" труда в коридоре 80-160 строк кода без комментариев день (а лучше взять средние значения продуктивности с завершенных проектов — это совсем не сложно). И все.
Еще лучше вместо чесания репы при составлении прогноза применять хотя-бы элементарный PERT Estimation, который доступен каждому человеку без какого-либо специального образования в силу своей простоты, и позволяет количественно учесть в плане риски. И тогда на продолжительных проектах все будет иметь реальные шансы сойтись день в день (при большом количестве задач погрешность планирования, при отсутствии выраженной тенденции к переоценке/недооценке, как ни странно, уменьшается).
А поправочные коэффициенты, если уж человек у человека есть постоянная тенденция к недооценке/переоценке (что элементарно определется по истории закрытых задач), берутся из исторических данных.
И все, совсем не надо быть семи пядей во лбу. Это азы проектного менеджмента, а не ноу-хау Gaperton-а. И изложены в любой толковой книге по вопросу.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, LaptevVV, Вы писали:
LVV>>По многолетнему опыту могу сказаить: после всех договоренностей и согласий можно смело умножать сроки на 2 (а лучше — на Пи ) — тогда это будет похоже на реальный срок выполнения. И это при добросовестном отношении к работе.
G>"На пи". Для того, чтобы проверить реалистичность плана, достаточно делать прогноз не только времени, но и объема (в любой метрике. Строки кода — адекватная и одна из самых стабильных метрик, как показывает практика, что-бы там про них не говорили). И держать "продуктивность" труда в коридоре 80-160 строк кода без комментариев день (а лучше взять средние значения продуктивности с завершенных проектов — это совсем не сложно). И все.
G>Еще лучше вместо чесания репы при составлении прогноза применять хотя-бы элементарный PERT Estimation, который доступен каждому человеку без какого-либо специального образования в силу своей простоты, и позволяет количественно учесть в плане риски. И тогда на продолжительных проектах все будет иметь реальные шансы сойтись день в день (при большом количестве задач погрешность планирования, при отсутствии выраженной тенденции к переоценке/недооценке, как ни странно, уменьшается).
G>А поправочные коэффициенты, если уж человек у человека есть постоянная тенденция к недооценке/переоценке (что элементарно определется по истории закрытых задач), берутся из исторических данных.
G>И все, совсем не надо быть семи пядей во лбу. Это азы проектного менеджмента, а не ноу-хау Gaperton-а. И изложены в любой толковой книге по вопросу.
Кактта рахмат за разъяснения. Не знал, что у нас так все классно! — давно не являюсь руководителем разработок...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Gaperton, Вы писали:
G>И все, совсем не надо быть семи пядей во лбу. Это азы проектного менеджмента, а не ноу-хау Gaperton-а. И изложены в любой толковой книге по вопросу.
Всё указанное работает в идеальном контексте. Под идеальным контекстом понимаю наличие идеального ТЗ. Если же работа с нечётким ТЗ (а бывают и нечёткие Requirements), то расчёт строк кода никак не поможет. К сожалению, слишком часто приходится работать с такими нечёткими исходными требованиями. И в данном случае, возвращаясь к теме вопроса, отличить разгильдяя от нормального исполнительного специалиста по такому критерию, как "выполнение плана" невозможно, поскольку сам план грешит.
Так что ИМХО отличить разгильдяя можно только по косвенным признакам...
И ещё... Есть разница между разгильдяем и некачественным специалистом. Оба, в общем, не самый удачный вариант, но второй всё же лучше. Объясню. Некачественный программист постепенно растёт и, при достаточно стабильном использовании в проекте определённых технологий такой программист постепенно растёт (меньше копается в документации, быстрее работает засчёт наработок и т.п.), выходя на свою предельную мощность. Разгильдяй же постоянно показывает низкий результат, обосновывая это различными проблемами, а то и просто никак не объясняя. Так же сроки некачественного программиста всё же поддаются прогнозированию. С разгильдяем же можно всевозможных сюрпризов ожидать.
Здравствуйте, Spidola, Вы писали:
S>Здравствуйте, Gaperton, Вы писали:
G>>И все, совсем не надо быть семи пядей во лбу. Это азы проектного менеджмента, а не ноу-хау Gaperton-а. И изложены в любой толковой книге по вопросу.
S>Всё указанное работает в идеальном контексте. Под идеальным контекстом понимаю наличие идеального ТЗ.
Можно, конечно, считать свои условия работы уникальными. А если так не считать, и уметь перечисленное применять — то вся уникальность волшебным образом куда-то уйдет.
S>Если же работа с нечётким ТЗ (а бывают и нечёткие Requirements), то расчёт строк кода никак не поможет. К сожалению, слишком часто приходится работать с такими нечёткими исходными требованиями. И в данном случае, возвращаясь к теме вопроса, отличить разгильдяя от нормального исполнительного специалиста по такому критерию, как "выполнение плана" невозможно, поскольку сам план грешит.
Нечеткие? Так уточняйте их (или организуйте этот процесс), это ваша работа. Если вы проработав по первоначальному плану 10%-20% времени не в состоянии сделать реалистичный план, это признак отсутствия управления рисками (а в вашем случае — еще и управления требованиями). Решение — (угадайте что?) — снятие руководителя проекта с должности по несоответствию, и назначение компетентного менеджера, который не будет обосновывать свои провалы нечеткими требованиями, или чем-то еще.
В любом деле нужны профессионалы. Руководить командой разработчиков (а не "управлять ресурсами" в Microsoft Project) — это специальная работа, и ее тоже нужно учится делать, чтобы делать ее хорошо. Хотите в этом убедится? Попробуйте пройти PM тест на brainbench. В первый год, когда он появился, его по их статистике провалило 98% людей, попытавшихся его пройти. Сравните со статистикой по С++.
S>Так что ИМХО отличить разгильдяя можно только по косвенным признакам...
Желание "отличить разгильдяя" — симптом, о чем здесь уже писали, и я полностью с этим согласен.
Здравствуйте, Gaperton, Вы писали:
G>Нечеткие? Так уточняйте их (или организуйте этот процесс), это ваша работа. Если вы проработав по первоначальному плану 10%-20% времени не в состоянии сделать реалистичный план, это признак отсутствия управления рисками (а в вашем случае — еще и управления требованиями). Решение — (угадайте что?) — снятие руководителя проекта с должности по несоответствию, и назначение компетентного менеджера, который не будет обосновывать свои провалы нечеткими требованиями, или чем-то еще.
У нас частo пoлучаeтся, чтo заказчик сам нe сoвсeм увeрeн в тoм, чтo хoчeт. Сoздаёт брeйн-стoрминг сoвeщания с участиeм экспeртoв ужe в прoцeссe разрабoтки. Чтoбы на oснoвe прoтoтипoв ужe рeшать куда двигаться дальшe. Плюс кo всeму из-за спeцифичнoсти разрабoтки мнoгиe вeщи прoвeряются при участии юристoв. Так чтo каким кoмпeтeнтным бы нe был мeнeджeр, зараниe никакoгo чёткoгo ТЗ и быть у нас oбычнo нe мoжeт.
Кoнeчнo, oплата прoeкта нe фиксирoванным бюджeтoм, а пo врeмeни разрабoтки мoжeт стимулирoвать разгильдяйствo прoграммистoв. Нo на тo и eсть ПМ-ы, кoтoрыe рабoтают как с клиeнтами, так и с прoграммистами
Здравствуйте, Dimonka, Вы писали:
D>Здравствуйте, Gaperton, Вы писали:
G>>Нечеткие? Так уточняйте их (или организуйте этот процесс), это ваша работа. Если вы проработав по первоначальному плану 10%-20% времени не в состоянии сделать реалистичный план, это признак отсутствия управления рисками (а в вашем случае — еще и управления требованиями). Решение — (угадайте что?) — снятие руководителя проекта с должности по несоответствию, и назначение компетентного менеджера, который не будет обосновывать свои провалы нечеткими требованиями, или чем-то еще.
D>У нас частo пoлучаeтся, чтo заказчик сам нe сoвсeм увeрeн в тoм, чтo хoчeт. Сoздаёт брeйн-стoрминг сoвeщания с участиeм экспeртoв ужe в прoцeссe разрабoтки. Чтoбы на oснoвe прoтoтипoв ужe рeшать куда двигаться дальшe. Плюс кo всeму из-за спeцифичнoсти разрабoтки мнoгиe вeщи прoвeряются при участии юристoв. Так чтo каким кoмпeтeнтным бы нe был мeнeджeр, зараниe никакoгo чёткoгo ТЗ и быть у нас oбычнo нe мoжeт.
Заказчик никогда не знает чего хочет, и не в состоянии сделать постановки задачи. Потому что это специальная работа, и ее тоже в идеале должны делать специалисты. Называется "аналитик", "постановщик", итд. Грамотный аналитик вытянет правильную постановку даже тогда, когда заказчик полностью невменяем. Наблюдал такое много раз, и сам так умею. Кстати, ничего сложного, на самом деле, просто немного тренировки (читаем книгу SADT — главы про проведение обследования + любую книгу про НЛП — глава про "мета-модель", думаем о прочитанном, далее немного практики, и через месяц-другой начнет получаться).
Если заказчик проявляет самостоятельную активность (думает, брейнстормит и обсуждает) и меняет постановку по ходу — ничего страшного. В таких условиях разумно применять XP, IBM Rad Cycle, или что-то подобное. Двигаетесь вперед через серию прототипов, каждый из которых делается, допустим, с интервалом в неделю, и обсуждается с заказчиком. Конечный срок не лимитируется, деньги берутся за время работы — хозяин барин.
D>Кoнeчнo, oплата прoeкта нe фиксирoванным бюджeтoм, а пo врeмeни разрабoтки мoжeт стимулирoвать разгильдяйствo прoграммистoв. Нo на тo и eсть ПМ-ы, кoтoрыe рабoтают как с клиeнтами, так и с прoграммистами
Проверь их продуктивность (строки кода/время), и вопиющее "разгильдяйство" сразу вылезет наружу. Всякое конечно бывает, но в массе своей программисты хорошо мотивированны (если им не портить удовольствие от работы и адекватно платить) и любят свою работу, что подверждается статистикой De Marco/Lister ("Peopleware"). Так что вопрос "разгильдяйства" программистов — совсем не тот вопрос, который должен обсуждаться в контексте проектного менеджмента. Это, еще раз, симптом, позволяющий отличить "разгильдяя" менеджера. Удобно, кстати
Здравствуйте, SergeySPb, Вы писали:
SSP>Всегда хотел узнать: почему руководство предпочитает задания раздавать в устной форме, SSP>а отчёты получать в письменной.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Spidola, Вы писали:
S>>Здравствуйте, Gaperton, Вы писали:
G>>>И все, совсем не надо быть семи пядей во лбу. Это азы проектного менеджмента, а не ноу-хау Gaperton-а. И изложены в любой толковой книге по вопросу.
S>>Всё указанное работает в идеальном контексте. Под идеальным контекстом понимаю наличие идеального ТЗ. G>Можно, конечно, считать свои условия работы уникальными. А если так не считать, и уметь перечисленное применять — то вся уникальность волшебным образом куда-то уйдет.
Уникальные условия — это как раз "идеальные". Реальные обычно отличаются. Где сильнее, где слабее...
S>>Если же работа с нечётким ТЗ (а бывают и нечёткие Requirements), то расчёт строк кода никак не поможет. К сожалению, слишком часто приходится работать с такими нечёткими исходными требованиями. И в данном случае, возвращаясь к теме вопроса, отличить разгильдяя от нормального исполнительного специалиста по такому критерию, как "выполнение плана" невозможно, поскольку сам план грешит. G>Нечеткие? Так уточняйте их (или организуйте этот процесс), это ваша работа. Если вы проработав по первоначальному плану 10%-20% времени не в состоянии сделать реалистичный план, это признак отсутствия управления рисками (а в вашем случае — еще и управления требованиями). Решение — (угадайте что?) — снятие руководителя проекта с должности по несоответствию, и назначение компетентного менеджера, который не будет обосновывать свои провалы нечеткими требованиями, или чем-то еще.
G>В любом деле нужны профессионалы. Руководить командой разработчиков (а не "управлять ресурсами" в Microsoft Project) — это специальная работа, и ее тоже нужно учится делать, чтобы делать ее хорошо. Хотите в этом убедится? Попробуйте пройти PM тест на brainbench. В первый год, когда он появился, его по их статистике провалило 98% людей, попытавшихся его пройти. Сравните со статистикой по С++.
Всё это громкие слова, не более (особенно начало второго абзаца) . Про уточнение требований — это понятно. Как это соотносится с количеством строк кода — непонятно. Тем более непонятно, как вы будете "отличать разгильдяя" среди проектировщиков и других ролей, которые кода-то не пишут? По количеству строк обычного написанного ими текста в документе?
Ладно, согласен, передёргиваю слегка... Разговор шёл про разработчиков... С разработчиками самые богатые будут те, кто на Ассемблере пишут — у них строк больше
А если не глумиться, то количеством строк кода можно оценивать только те задачи, на которые заведомо известен объём необходимого кода. Т.е. те задачи, которые имеют типовые решения. Другими словами, данную технологию оценки можно применять в тех случаях, где она применима. А где неприменима, там бесполезно и даже вредно.
По поводу "управления ресурсами в Project" — здесь желательно отделить мух от котлет. Project даёт весьма неплохое визуальное представление проекта (редко видел, чтобы кто-то использовал прожект для моделирования проекта, например). Управление ресурсами в scope MS Project не попадает, поскольку учёта материальных ресурсов там нет. Кстати, вот вам выдержка из рекламного буклета:
"Project 2003 предлагает разнообразные эффективные способы работы над календарным планом проекта."
Вот для этого он и нужен, чобственно.
По поводу Брэйнбенча — терпеть не могу этот сервер. Мало того, что половина тестов там исскусственные, так и сертификаты их ничего не говорят о человеке... Ну и что вам даст тест на PM??? Узнаете, что нужно риски просчитывать? Это каждому мало мальски сообразительному человеку понятно... Вопрос как их считать. А ещё точнее, знать, как их в Москве считать, как в Казани, а как в Германии... Об этом в книжках тоже написано?
Здравствуйте, SergeySPb, Вы писали:
SSP>Всегда хотел узнать: почему руководство предпочитает задания раздавать в устной форме, SSP>а отчёты получать в письменной.
Тому есть ряд причин:
1) Не может сформулировать свои мысли.
2) Жопу (Простите за франц.) прикрывает — ибо корпоративное письмо при обвинении вдруг может снять само обвинение.
3) Боиться менеджеров старшего звена. Не путать со вторым пунктом. Ибо, этот пункт касаеться ситуации когда данный менеджер боиться продвинуть инициативу по улучшению общения между подчиненными, которая обычно приходит от подчененных.
4) Свои собственные ошибки. Например, — "Болезнь? Какая болезнь? Мы это не предусматривали!" Дальше все в устной форме...
Здравствуйте, Spidola, Вы писали:
S>Уникальные условия — это как раз "идеальные". Реальные обычно отличаются. Где сильнее, где слабее...
Мы так работаем последние четыре года. И никаких проблем с идеальными условиями не испытываем. Это все отмазки.
G>>В любом деле нужны профессионалы. Руководить командой разработчиков (а не "управлять ресурсами" в Microsoft Project) — это специальная работа, и ее тоже нужно учится делать, чтобы делать ее хорошо. Хотите в этом убедится? Попробуйте пройти PM тест на brainbench. В первый год, когда он появился, его по их статистике провалило 98% людей, попытавшихся его пройти. Сравните со статистикой по С++.
S>Ладно, согласен, передёргиваю слегка... Разговор шёл про разработчиков... С разработчиками самые богатые будут те, кто на Ассемблере пишут — у них строк больше
Да не слегка. Кстати, сразу видно, что вы не считаете строки кода. Сколько именно строк кода конкретный программист колбасит в день — совершенно пофигу, лишь бы сильно не выбивалось за коридор средних (в обе стороны), это говорит о проблемах. Кстати, продуктивность в строках не так сильно зависит от языка. Речь идет о строках отлаженного кода без комментариев.
S>А если не глумиться, то количеством строк кода можно оценивать только те задачи, на которые заведомо известен объём необходимого кода. Т.е. те задачи, которые имеют типовые решения. Другими словами, данную технологию оценки можно применять в тех случаях, где она применима. А где неприменима, там бесполезно и даже вредно.
Нет совершенно никаких подтвержденных данных, которые бы хоть как-то согласовывались с этим вашим абзацем. По индустриальной статистике, которая подтверждается статистикой нашей компании, метрика продуктивности основанная на строках кода ведет себя удивительно стабильно. И считается, кстати, проще всех остальных метрик (что означает, что в ней проще всего делать прогноз). А другого от метрики объема и не требуется.
Так что именно эта метрика применялась, применяется и будет применяться в будущем в софтверном ptoject management как основная. Если же вы не в состоянии сделать прогноз объема, это значит что весь ваш план взят с потолка. Как следствие, вы автоматически проиграете любой тендер министерства обороны США, да и вообще не сможете написать толковый SDP (что это такое, да? RTFM), т. е. проиграете практически любой серьезный тендер. А будете им объяснять, что де "она здесь не применима", вас 1) поднимут на смех 2) скажут досвиданья.
S>
S>"Project 2003 предлагает разнообразные эффективные способы работы над календарным планом проекта."
S>Вот для этого он и нужен, чобственно.
Использовать его для составления календарного плана для разработки софта — самоубийство для проекта. А если не пользоваться его генератором schedule, то он вообще нафиг не нужен. Нельзя позволять машине раскидывать задачи на разработчиков, если вы, конечно, хоть как-то озабочены управлением рисками. Почему? Программисты не взаимозаменяемы, учитывать их индивидуальность необходимо для успеха проекта. В этом ключ к успешной командной работе.
S>По поводу Брэйнбенча — терпеть не могу этот сервер. Мало того, что половина тестов там исскусственные, так и сертификаты их ничего не говорят о человеке...
А я вам не тыкаю своими сертефикатами, у меня их нет. Эти тесты позволяют довольно надежно и объективно отсеять людей, ну совсем нихрена не разбирающихся в вопросе.
S> Ну и что вам даст тест на PM??? Узнаете, что нужно риски просчитывать?
По моему я ясно выразился — по их статистике в PM не разбирается 98% людей, на это претендующих. Что имхо весьма правдоподобно. Причем им часто даже чтение литературы не помогает. Мне он в свое время (5 лет назад) дал понимание того, что я ничего не понимаю в PM. Что стимулировало меня к чтению факен мануалов. С тех пор его не проходил, как то уже и не надо стало .
S>Это каждому мало мальски сообразительному человеку понятно... Вопрос как их считать. А ещё точнее, знать, как их в Москве считать, как в Казани, а как в Германии... Об этом в книжках тоже написано? Вопрос не в том, как их считать. Вопрос, как их корректно учесть при планировании времени задачи . А вот об этом в книжках написано. Впрочем, в военное время в какой-нибудь Казани может перестать работать не только проектный менеджмент, но и теория вероятностей, я уж не говорю о значении синуса. А у нас в Москве — все перечисленное работает без сбоев, риски исправно учитываются в планах, которые привычно выходят на deadline. В Германии я слыхал тоже. Чего и вам желаю.
Здравствуйте, Constructor, Вы писали:
C>Всх ровнять под одну гребенку нехорошо... Хотелось бы научиться ненавязчиво контролировать, кто чем занимается, кто сталкивается с какими трудностями. Научиться достоверно определять: если человек не справился с работой, то это из-за 1) разгильдяейства или 2) его еще слабой подготовки или 3) недооценки сложности задачи. C>Причем чтобы свои оценки можно было четко обосновать. И руководителю, и подчиненному.
У всех программеров есть плюсы и минусы.
Зачем тебе определять степень разгильдяйства каждого из них?
Что за мания гнобить программеров?
Тебе же нужно, чтобы проект был сделан этими разгильдяями в срок.
Из любого разгильдяя можно сделать работягу в поте лица, если:
1. Дать ему четкий объем работ и сроки (ТЗ + Планирование).
2. Дать ему почувствовать, что его контролируют (Ежедневная отчетность, именно ежедневная).
Над какими работами из плана работал, сколько часов в день, каков результат (кратенько).
Занимает это не более 15 мин/день, вырабатывает чувство самоконтроля и ответственности.
3. Собрания по мере надобности и раз в неделю по пятницам (постыдить шалопаев и похвалить).
Труднее именно предоставить в нормальном виде объем работ!!!
Если ты знаешь что именно нужно делать, то у тебя нет проблем.
ИМХО, вся проблема в проектировании системы и формировании конкретных заданий.
Сроки срываются из-за того, что проектировщик что-то там не учел.
Решается путем поэтапной сдачи проекта и накидывания времени прозапас на каждый этап.
Дополнительную работу, данную в устной форме, следует оформить в письменной и занести в план.
Жестко ставить вопрос перед уже твоим начальством по поводу возможных срывов сроков и на сколько.
Пусть знаю, что они виноваты!!!
Если программер халтурит, то клей разборки с ним четко, но нежно и по делу, предметно.
Практика показывает, что люди быстро самоорганизуются и будут нормально работать.
Если же план есть, но нет контроля и программер никак не отчитывается о работе, то
он будет по сайтам лазить, кофе пить, курить, ржать, а потом отмазку придумает.
А времени поругать уже не будет!
И бревно, бревно должен нести ты тоже, чтобы был пример.
Вспомни Вождя!
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Spidola, Вы писали:
S>>Уникальные условия — это как раз "идеальные". Реальные обычно отличаются. Где сильнее, где слабее... G>Мы так работаем последние четыре года. И никаких проблем с идеальными условиями не испытываем. Это все отмазки.
Без комментариев. Не знаком с вашей компанией...
G>>>В любом деле нужны профессионалы. Руководить командой разработчиков (а не "управлять ресурсами" в Microsoft Project) — это специальная работа, и ее тоже нужно учится делать, чтобы делать ее хорошо. Хотите в этом убедится? Попробуйте пройти PM тест на brainbench. В первый год, когда он появился, его по их статистике провалило 98% людей, попытавшихся его пройти. Сравните со статистикой по С++.
S>>Ладно, согласен, передёргиваю слегка... Разговор шёл про разработчиков... С разработчиками самые богатые будут те, кто на Ассемблере пишут — у них строк больше G>Да не слегка. Кстати, сразу видно, что вы не считаете строки кода. Сколько именно строк кода конкретный программист колбасит в день — совершенно пофигу, лишь бы сильно не выбивалось за коридор средних (в обе стороны), это говорит о проблемах. Кстати, продуктивность в строках не так сильно зависит от языка. Речь идет о строках отлаженного кода без комментариев.
Не сильно я, конечно, разбираюсь в проджект менеджменте, однако, не помню, чтобы где-нибудь в COCOMO II или FPA учитывались строки кода без учёта языка, а точнее средств разработки. Не дадите ссылку?
S>>А если не глумиться, то количеством строк кода можно оценивать только те задачи, на которые заведомо известен объём необходимого кода. Т.е. те задачи, которые имеют типовые решения. Другими словами, данную технологию оценки можно применять в тех случаях, где она применима. А где неприменима, там бесполезно и даже вредно. G>Нет совершенно никаких подтвержденных данных, которые бы хоть как-то согласовывались с этим вашим абзацем. По индустриальной статистике, которая подтверждается статистикой нашей компании, метрика продуктивности основанная на строках кода ведет себя удивительно стабильно. И считается, кстати, проще всех остальных метрик (что означает, что в ней проще всего делать прогноз). А другого от метрики объема и не требуется.
G>Так что именно эта метрика применялась, применяется и будет применяться в будущем в софтверном ptoject management как основная. Если же вы не в состоянии сделать прогноз объема, это значит что весь ваш план взят с потолка. Как следствие, вы автоматически проиграете любой тендер министерства обороны США, да и вообще не сможете написать толковый SDP (что это такое, да? RTFM), т. е. проиграете практически любой серьезный тендер. А будете им объяснять, что де "она здесь не применима", вас 1) поднимут на смех 2) скажут досвиданья.
По существу: когда вы говорите про "прогноз объёма" в строках кода — вы говорите серьёзно? И про то, что без этого прогноза ни один серьёзный заказчик не будет разговаривать и тем более тендер заключать?
И вы действительно считаете указанную вами метрику "основной"?
Надеюсь про тендеры — это шутка?.. Про минобороны США не знаю — не участвовал в тендерах. Американцы — они вообще народ интересный... Про минобороны наше (да и про наши центральные органы власти) — уж поверьте — там никого не интересует "объём кода" при анализе тендерных предложений.
S>>
S>>"Project 2003 предлагает разнообразные эффективные способы работы над календарным планом проекта."
S>>Вот для этого он и нужен, чобственно. G>Использовать его для составления календарного плана для разработки софта — самоубийство для проекта. А если не пользоваться его генератором schedule, то он вообще нафиг не нужен. Нельзя позволять машине раскидывать задачи на разработчиков, если вы, конечно, хоть как-то озабочены управлением рисками. Почему? Программисты не взаимозаменяемы, учитывать их индивидуальность необходимо для успеха проекта. В этом ключ к успешной командной работе.
Не вижу, честно говоря, "самоубийства". "Раскидывать задачи" в Project Central действительно не удобно, также как неудобно осуществлять там трекинг задач. Думаю, что существуют более удобные и интегрирующиеся в среды разработки инструменты, применяемые в конкретных командах. Что касается использования Project для расписывания общего календарного плана — пока проблем не видно.
S>>По поводу Брэйнбенча — терпеть не могу этот сервер. Мало того, что половина тестов там исскусственные, так и сертификаты их ничего не говорят о человеке... G>А я вам не тыкаю своими сертефикатами, у меня их нет. Эти тесты позволяют довольно надежно и объективно отсеять людей, ну совсем нихрена не разбирающихся в вопросе.
Не согласен. Можно заодно отсеить и часть людей, которые вам очень могут пригодиться. Тесты брэйна довольно синтетические, на мой взгляд, и только формально проверяют вас на знание вопросов, также формально изложенных в теории. В конкретных практических вопросах часть элементов теории может не применяться и знание этих элементов может не требоваться. Тем более на большинство вопросов брэйнбенча можно ответить, прочитав одну две книги. А вы сами утверждали выше, что прочитывание книг не даёт уверенности в знании вопроса. У самого была несколько лет назад мысль по поводу использования брэйна при приёме на работу новых сотрудников. Эта модель была опробована и быстро отброшена, как бесполезная и даже вредная.
S>> Ну и что вам даст тест на PM??? Узнаете, что нужно риски просчитывать? G>По моему я ясно выразился — по их статистике в PM не разбирается 98% людей, на это претендующих. Что имхо весьма правдоподобно. Причем им часто даже чтение литературы не помогает. Мне он в свое время (5 лет назад) дал понимание того, что я ничего не понимаю в PM. Что стимулировало меня к чтению факен мануалов. С тех пор его не проходил, как то уже и не надо стало .
Думаю, что когда вы проходили данный тест, то встретили много незнакомых слов и подумали, что "ничего не понимаете". По прочтении "факен мануалов" вы поняли, что большинство из них действительно "факен" и не потребуются на практике. Если после этого вы выделили то, что вам реально нужно сейчас, то это хорошо. Но брэйнбенч тут просто подвернулся конкретно вам, поскольку после разговора с каким-нибудь опытным специалистом в области управления проектами у вас было бы не меньшее чувство непонимание, а ещё даже большее, поскольку вас уделал не какой-то далёкий брейнбенч, а реальноый товарисч. Это к слову о брейнбенче.
S>>Это каждому мало мальски сообразительному человеку понятно... Вопрос как их считать. А ещё точнее, знать, как их в Москве считать, как в Казани, а как в Германии... Об этом в книжках тоже написано? G> Вопрос не в том, как их считать. Вопрос, как их корректно учесть при планировании времени задачи . А вот об этом в книжках написано.
Не понял. Как их можно учитывать не считая??? В процентах? Т.е. время на набор 20 программистов в Москве и в Усть-Урюпинске одинаково? И не зависит от среды разработки и платформы?
G>Впрочем, в военное время в какой-нибудь Казани может перестать работать не только проектный менеджмент, но и теория вероятностей, я уж не говорю о значении синуса. А у нас в Москве — все перечисленное работает без сбоев, риски исправно учитываются в планах, которые привычно выходят на deadline. В Германии я слыхал тоже. Чего и вам желаю.
Мои вам поздравления. Вы, видимо, достигли нирваны. Далеко не каждый может этим похвастаться (и я в том числе, к сожалению).
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ> ГВ>По моему скромному опыту больше всего неприятностей вызывает честный и исполнительный трудяга. Почему так получается, не знаю. Но подозреваю, что здесь задействован принцип "несдвигания сроков во что бы то ни стало". Во всяком случае, от тех, кто строг и исполнителен в административном смысле проблемы в архитектуре или кривой API получить удавалось чаще, чем от лентяев, к которым как ни зайдёшь, так они либо в инете сидят, либо музыку слушают, либо ещё чем-то занимаются.
Это вы путаете разгильдяев и раздолбаев. Разгильдяи — это такие мужики, которые всё что надо пытаются делать, но в какой-то момент тупят или ленятся и ничего хорошего в результате не получается. А раздолбаи — это такие талантливые ребята, которые всякой, пардон, хернёй, занимаются, но дело знают.
Здравствуйте, Spidola, Вы писали:
S>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>> ГВ>>По моему скромному опыту больше всего неприятностей вызывает честный и исполнительный трудяга. Почему так получается, не знаю. Но подозреваю, что здесь задействован принцип "несдвигания сроков во что бы то ни стало". Во всяком случае, от тех, кто строг и исполнителен в административном смысле проблемы в архитектуре или кривой API получить удавалось чаще, чем от лентяев, к которым как ни зайдёшь, так они либо в инете сидят, либо музыку слушают, либо ещё чем-то занимаются.
S> Это вы путаете разгильдяев и раздолбаев. Разгильдяи — это такие мужики, которые всё что надо пытаются делать, но в какой-то момент тупят или ленятся и ничего хорошего в результате не получается. А раздолбаи — это такие талантливые ребята, которые всякой, пардон, хернёй, занимаются, но дело знают.
хм. а более подробной классификации нет? если можно огласите весь список )))
Здравствуйте, Spidola, Вы писали:
S>Не сильно я, конечно, разбираюсь в проджект менеджменте, однако, не помню, чтобы где-нибудь в COCOMO II или FPA учитывались строки кода без учёта языка, а точнее средств разработки. Не дадите ссылку?
Не дам . В СOCOMO II язык учитывается. Я кстати, не говорил, что от языка продуктивность не зависит. Я говорил, что она зависит не сильно. У программиста на ассемблере не будет на порядок выше продуктивность в строках отлаженного кода в час (генеренные строки и комментарии не считать). Хотите — проведите межязыковое сравнение по своей компании — это не сложно. Готов заключить пари, что средняя продуктивность программиста за год по вашей компании уложтся в коридор 20-60 строк строк в час независимо от языка. Мы сравнивали С++ и С#, В Ericsson сравнивали 5 непохожих друг на друга языков.
S>По существу: когда вы говорите про "прогноз объёма" в строках кода — вы говорите серьёзно? И про то, что без этого прогноза ни один серьёзный заказчик не будет разговаривать и тем более тендер заключать?
Да, я говорю серьезно. Почитайте Хамфри, автора модели CMM, он тоже говорит серьезно.
S>И вы действительно считаете указанную вами метрику "основной"?
Я дал повод в этом сомневаться? По-моему, я объяснил почему я считаю ее основной и в чем конкретно ее преимущества перед остальными метриками.
S>Надеюсь про тендеры — это шутка?.. Про минобороны США не знаю — не участвовал в тендерах. Американцы — они вообще народ интересный... Про минобороны наше (да и про наши центральные органы власти) — уж поверьте — там никого не интересует "объём кода" при анализе тендерных предложений.
Конечно. Там их интересует объем откатов. Как и в большинстве тендеров в России. Я надеюсь, вы привели этот пример в шутку?
S>Не согласен. Можно заодно отсеить и часть людей, которые вам очень могут пригодиться. Тесты брэйна довольно синтетические, на мой взгляд, и только формально проверяют вас на знание вопросов, также формально изложенных в теории. В конкретных практических вопросах часть элементов теории может не применяться и знание этих элементов может не требоваться. Тем более на большинство вопросов брэйнбенча можно ответить, прочитав одну две книги. А вы сами утверждали выше, что прочитывание книг не даёт уверенности в знании вопроса. У самого была несколько лет назад мысль по поводу использования брэйна при приёме на работу новых сотрудников. Эта модель была опробована и быстро отброшена, как бесполезная и даже вредная.
Тест брейна на PM (я говорю только о нем, и не хочу обсуждать brainbench) проверяет знакомство со специализированной литературой по PM и элементарное понимание базовый понятий PM. Менеджер, который не может его пройти — профнепригоден. Так же как и программист на С++, который ни разу за не читал книг по своей специальности.
S>Думаю, что когда вы проходили данный тест, то встретили много незнакомых слов и подумали, что "ничего не понимаете". По прочтении "факен мануалов" вы поняли, что большинство из них действительно "факен" и не потребуются на практике. Если после этого вы выделили то, что вам реально нужно сейчас, то это хорошо. Но брэйнбенч тут просто подвернулся конкретно вам, поскольку после разговора с каким-нибудь опытным специалистом в области управления проектами у вас было бы не меньшее чувство непонимание, а ещё даже большее, поскольку вас уделал не какой-то далёкий брейнбенч, а реальноый товарисч. Это к слову о брейнбенче. Не понимаю, что вы хотите доказать.
S>Не понял. Как их можно учитывать не считая??? В процентах? Т.е. время на набор 20 программистов в Москве и в Усть-Урюпинске одинаково? И не зависит от среды разработки и платформы? Вы вот тут COCOMO упоминали. Неужели вы не знаете две элементарных формулы PERT, и не понимаете, как именно он помогает количественно учесть риски?
G>>Впрочем, в военное время в какой-нибудь Казани может перестать работать не только проектный менеджмент, но и теория вероятностей, я уж не говорю о значении синуса. А у нас в Москве — все перечисленное работает без сбоев, риски исправно учитываются в планах, которые привычно выходят на deadline. В Германии я слыхал тоже. Чего и вам желаю. S>Мои вам поздравления. Вы, видимо, достигли нирваны. Далеко не каждый может этим похвастаться (и я в том числе, к сожалению).
Нет, я применяю базовые вещи из project management. Согласен, далеко не кадждый может этим похвастаться.
Что бы понять что вы делаете — поездите на работу с месяц из соседненго города за 200-300 км от Вашего. Получите весьма наглядное представление о требованиях, которые предявляете к другим... 
Неужели вы не знаете две элементарных формулы PERT, и не понимаете, как именно он помогает количественно учесть риски?