Здравстуйте, такой вопрос — как управлять программистами эффективно?
У нас в фирме — сроки по разработке _постоянно_ не выполняются, задержки, авралы... В чем дело?
Может есть грамотная система по организации труда программистов? Буду рад любым советам!
Здравствуйте, vohta, Вы писали:
V>Здравстуйте, такой вопрос — как управлять программистами эффективно? V>У нас в фирме — сроки по разработке _постоянно_ не выполняются, задержки, авралы... В чем дело? V>Может есть грамотная система по организации труда программистов? Буду рад любым советам!
Сдаётся мне у вас проблема большего масштаба, а именно в организации всего процесса.
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, vohta, Вы писали:
V>>Здравстуйте, такой вопрос — как управлять программистами эффективно? V>>У нас в фирме — сроки по разработке _постоянно_ не выполняются, задержки, авралы... В чем дело? V>>Может есть грамотная система по организации труда программистов? Буду рад любым советам!
IT>Сдаётся мне у вас проблема большего масштаба, а именно в организации всего процесса.
проблема в том что программисты не выполняют работу в срок. как ее решить?
Здравствуйте, vohta, Вы писали:
V>Здравстуйте, такой вопрос — как управлять программистами эффективно? V>У нас в фирме — сроки по разработке _постоянно_ не выполняются, задержки, авралы... В чем дело?
неэффективный менеджмент
V>Может есть грамотная система по организации труда программистов? Буду рад любым советам!
сократить вдвое начальствующий контингент. остальных заставить провести разбор полетов по сорванным срокам
Здравствуйте, vohta, Вы писали:
UN>>Кнутом и пряником. V>а подробнее что за кнут? какие практикуются денежные штафы? V>пряник? какой = отгулы? деньги? сколько? проценты?
Если бы все было так просто, то менеджеры бы сидели на печи и ели калачи.
Скажу с точки зрения программиста. А то менеджеры любят друга-друга учить, а программистов спросить забывают
1. Любой штраф убивает мою мотивацию начисто. Денежный тем более.
2. Кнутом для меня является отсутствие пряника. Чем меньше пряник тем обидней.
3. Я не люблю непосредственные поощрения. Типа выкатили релиз вовремя, на, получи премию. А если не выкатили? А если я тут не при чем?
4. Пряник достигается через работу. И он в том, что начальство помогает в решении насущных проблем.
5. У меня должно быть ощущение, что менеджер не забывает поглядывать на результаты его работы. Никакого отпускания на самотек. Иначе расслаблюсь чрезмерно.
6. Никаких "да тут пару ифов все-го то вставить". Сколько ифов вставить и в какое место, я уж сам как нибудь решу.
7. Иногда я люблю поработать подольше. Но лучше даже не пытаться меня к этому принудить.
8. Не забывай спрашивать, что мне нужно. Удобно ли мое кресло, велик ли монитор.
9. Иногда даже спрашивай, а не хочу ли повышения зарплаты. Но торгуйся — спроси, что я хочу еще сделать для компании (и для себя) ради этого повышения.
Ну вроде все.
Да, еще одно. Если у вас спускают даты выпуска "сверху", то постоянный срыв сроков — ваша объективная реальность вне зависимости от приложенных усилий.
Здравствуйте, vohta, Вы писали:
IT>>Сдаётся мне у вас проблема большего масштаба, а именно в организации всего процесса.
V>проблема в том что программисты не выполняют работу в срок. как ее решить?
Программисты могут не выполнить работу в срок, например, из-за отсутствия чётких функциональных требований. В таком случае никакая "грамотная система по организации труда программистов" не поможет.
... << RSDN@Home 1.2.0 alpha rev. 771>>
Если нам не помогут, то мы тоже никого не пощадим.
vohta пишет: > > Здравстуйте, такой вопрос — как управлять программистами эффективно? > У нас в фирме — сроки по разработке _постоянно_ не выполняются, > задержки, авралы... В чем дело? > Может есть грамотная система по организации труда программистов? Буду > рад любым советам! > > Отцы! подскажите!
Выгнать всю прослойку между владельцем и программистами и набирать
новую, но профессиональную (тех, у которых есть хотя бы пару проектов
нормально завершенных).
vohta пишет: > > V>>Может есть грамотная система по организации труда программистов? Буду > рад любым советам! > > IT>Сдаётся мне у вас проблема большего масштаба, а именно в организации > всего процесса. > > проблема в том что программисты не выполняют работу в срок. как ее решить?
За какое время разгрузишь вагон угля? За день? Медленно, я вот по
молодости за полдня разгружал. Так что вот тебе полдня, работай.
Здравствуйте, vohta, Вы писали:
V>Отцы! подскажите!
С удовольствием Нужно прочитать пару книжек на тему. Например Брукса "Мифический человеко-месяц" http://www.ozon.ru/context/detail/id/83760/
Здравствуйте, vohta, Вы писали:
V>Здравствуйте, IT, Вы писали:
IT>>Здравствуйте, vohta, Вы писали:
V>>>Здравстуйте, такой вопрос — как управлять программистами эффективно? V>>>У нас в фирме — сроки по разработке _постоянно_ не выполняются, задержки, авралы... В чем дело? V>>>Может есть грамотная система по организации труда программистов? Буду рад любым советам!
IT>>Сдаётся мне у вас проблема большего масштаба, а именно в организации всего процесса.
V>проблема в том что программисты не выполняют работу в срок. как ее решить?
Оценка спускается сверху — начальству стоит перестать выдавать желаемое за действительное
Оценка дается самими разработчиками — при значительном отклонении (в любую сторону) — посчитать поправочный коэффициент, домножать оценку на него, со временем коэффициент пересматривать.
Оценка рождается "посередине" — менять "середину"
Здравствуйте, vohta, Вы писали:
V>проблема в том что программисты не выполняют работу в срок. как ее решить?
Сначала нужно разобраться, откуда берутся сроки.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
SE>1. Любой штраф убивает мою мотивацию начисто. Денежный тем более.
Это да. А вот казалось бы, всё справедливо, оплошал — получи наказание, ан нет, всё равно не нравится, так уж люди устроены.
SE>2. Кнутом для меня является отсутствие пряника. Чем меньше пряник тем обидней.
Не для всех это работает, к сожалению.
SE>3. Я не люблю непосредственные поощрения. Типа выкатили релиз вовремя, на, получи премию. А если не выкатили? А если я тут не при чем?
В общем, да.
SE>4. Пряник достигается через работу. И он в том, что начальство помогает в решении насущных проблем.
В общем, да.
SE>5. У меня должно быть ощущение, что менеджер не забывает поглядывать на результаты его работы. Никакого отпускания на самотек. Иначе расслаблюсь чрезмерно.
Это да. Здесь, по-видимому, срабатывает психология "ну если руководству это не нужно, значит это никому не нужно, а делать что-то не нужное — это, ребята, как-то противоестественно, пойду-ка чаю попью...".
SE>6. Никаких "да тут пару ифов все-го то вставить". Сколько ифов вставить и в какое место, я уж сам как нибудь решу.
Это да. Бывало хочется засунуть эти if'ы во вполне определённое место вполне определённому человеку.
SE>7. Иногда я люблю поработать подольше. Но лучше даже не пытаться меня к этому принудить.
Это смотря как тебя об этом просят. Бывает, тебя об этом правильно просят, и ты не можешь (ну или не хочешь) отказать. Это целая наука — договариваться с людьми, в т.ч. и с подчинёнными.
SE>8. Не забывай спрашивать, что мне нужно. Удобно ли мое кресло, велик ли монитор.
Это да, это важно.
SE>9. Иногда даже спрашивай, а не хочу ли повышения зарплаты. Но торгуйся — спроси, что я хочу еще сделать для компании (и для себя) ради этого повышения.
Ох уж мне все эти душеспасительные беседы... Фтопку.
SE>Если у вас спускают даты выпуска "сверху", то постоянный срыв сроков — ваша объективная реальность вне зависимости от приложенных усилий.
А вот это в корне неверно. Советую почитать/посмотреть Ашманова, здесь на форуме вроде бы даже ссылка пробегала. Если вкратце, то он говорит о том, что устанавливать сроки, собирая оценки "снизу" — неверно, потому что программисты в силу своей природы никогда не смогут адекватно оценить время, необходимое им для выполнения поставленных задач. Моё мнение — сбор оценок сроков должен начинаться таки "снизу", но не с программеров, а с руководителей групп, которые прекрасно знают способности каждого из своих подчинённых.
Здравствуйте, vohta, Вы писали:
V>Здравстуйте, такой вопрос — как управлять программистами эффективно? V>У нас в фирме — сроки по разработке _постоянно_ не выполняются, задержки, авралы... В чем дело? V>Может есть грамотная система по организации труда программистов? Буду рад любым советам!
А как вы назначаете сроки? В какой момент вам становится понятно, что сроки не выдерживаются — за месяц до конца срока, за день до сдачи, или через неделю после того, как все сроки уже прошли? Что вы пытаетесь делать, когда понимаете, что сроки проходят?
Без знания ответов на эти вопросы трудно что-либо посоветовать. Ну разве кроме одного: ни при каких обстоятельствах не заставляйте людей работать более положеных 40-а часов в неделю, никаких работ после окончания рабочего дня или по выходным быть не должно (ну разве если кто сам вдруг хочет, но не надо это поощрять).
Здравствуйте, x64, Вы писали:
SE>>1. Любой штраф убивает мою мотивацию начисто. Денежный тем более. x64>Это да. А вот казалось бы, всё справедливо, оплошал — получи наказание, ан нет, всё равно не нравится, так уж люди устроены.
Нет, это не справедливо и не умно. Работа — это не школа и не детский сад. По умолчанию, каждый пытается выполнить свою работу наилучшим образом. Мешать могут только условия. Следовательно, оплошность (как и любая другая ошибка) — естественная составляющая процесса. А значит, "наказание" за неё естественное, сиречь — сам факт ошибки. Никаких дополнительных наказаний не требуется. А иначе кто-то выбрал неправильное место работы или ошибся в подборе персонала.
SE>>2. Кнутом для меня является отсутствие пряника. Чем меньше пряник тем обидней. x64>Не для всех это работает, к сожалению.
Тогда опять — либо не те люди, либо неправильные условия.
SE>>Если у вас спускают даты выпуска "сверху", то постоянный срыв сроков — ваша объективная реальность вне зависимости от приложенных усилий.
x64>А вот это в корне неверно. Советую почитать/посмотреть Ашманова, здесь на форуме вроде бы даже ссылка пробегала. Если вкратце, то он говорит о том, что устанавливать сроки, собирая оценки "снизу" — неверно, потому что программисты в силу своей природы никогда не смогут адекватно оценить время, необходимое им для выполнения поставленных задач. Моё мнение — сбор оценок сроков должен начинаться таки "снизу", но не с программеров, а с руководителей групп, которые прекрасно знают способности каждого из своих подчинённых.
Ну и где противоречие? Всё равно же опорой служит мнение исполнителей.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Pzz, Вы писали:
Pzz>А как вы назначаете сроки? В какой момент вам становится понятно, что сроки не выдерживаются — за месяц до конца срока, за день до сдачи, или через Pzz>неделю после того, как все сроки уже прошли? Что вы пытаетесь делать, когда понимаете, что сроки проходят?
работа определяется на неделю-две вперед. узнается что не укладываемся в срок в конце срока — мол неуспели... и что делать.. ну давайте еще неделю берите и делайте... в итоге работа делается только к концу третей недели (что в 3-и раза больше...)
Сроки устанавливают сами программисты, с небольшой поправкой менеджера проекта, причем на планерке все реально и даже время есть с запасом....
Здравствуйте, x64, Вы писали:
SE>>1. Любой штраф убивает мою мотивацию начисто. Денежный тем более.
x64>Это да. А вот казалось бы, всё справедливо, оплошал — получи наказание, ан нет, всё равно не нравится, так уж люди устроены.
Наказание за ошибку убивает инициативу. Если уж и наказывать то за невыполнение четких внутренних распорядков и правил, которые заранее приказано не нарушать И все равно нарушать будут
SE>>5. У меня должно быть ощущение, что менеджер не забывает поглядывать на результаты его работы. Никакого отпускания на самотек. Иначе расслаблюсь чрезмерно.
x64>Это да. Здесь, по-видимому, срабатывает психология "ну если руководству это не нужно, значит это никому не нужно, а делать что-то не нужное — это, ребята, как-то противоестественно, пойду-ка чаю попью...".
Там я опечатался, "на результаты моей работы". Но вариант с "его работой" тоже неплох. Пусть будет "моей и своей"
SE>>7. Иногда я люблю поработать подольше. Но лучше даже не пытаться меня к этому принудить.
x64>Это смотря как тебя об этом просят. Бывает, тебя об этом правильно просят, и ты не можешь (ну или не хочешь) отказать. Это целая наука — договариваться с людьми, в т.ч. и с подчинёнными.
Да, полностью согласен. Когда-просят по человечески, то остаться поработать даже в радость. Тем более что, если просят, то это обычно форс мажор и за это доплачивают, независимо от.
SE>>8. Не забывай спрашивать, что мне нужно. Удобно ли мое кресло, велик ли монитор.
x64>Это да, это важно.
Причем выгодно даже.
SE>>9. Иногда даже спрашивай, а не хочу ли повышения зарплаты. Но торгуйся — спроси, что я хочу еще сделать для компании (и для себя) ради этого повышения.
x64>Ох уж мне все эти душеспасительные беседы... Фтопку.
Тут суть не в душеспасительных беседах. Лучшим предметом торговли со стороны менеджера является самообучение/обучение, изучение технологий/компонентов, языковая практика, публичные доклады, сдача проф. экзаменов и т.д.
Начальство нужно точно также мотивировать на увеличение зарплат сверх простой компенсации инфляции.
SE>>Если у вас спускают даты выпуска "сверху", то постоянный срыв сроков — ваша объективная реальность вне зависимости от приложенных усилий.
x64>А вот это в корне неверно.
Под "сверху" я имел в виду лозунги вроде "Запустим реакторы в строй к Первомаю!!!". Все помнят чем закончилось.
x64>Моё мнение — сбор оценок сроков должен начинаться таки "снизу", но не с программеров, а с руководителей групп, которые прекрасно знают способности каждого из своих подчинённых.
vohta пишет: > > > работа определяется на неделю-две вперед. узнается что не укладываемся в > срок в конце срока — мол неуспели... и что делать.. ну давайте еще > неделю берите и делайте... в итоге работа делается только к концу третей > недели (что в 3-и раза больше...) > > Сроки устанавливают сами программисты, с небольшой поправкой менеджера > проекта, причем на планерке все реально и даже время есть с запасом....
Вы не заметили, что сами себе противоречите: в реальности не успеваете,
а на планерке еще и свободное время будет.
Мне кажется, что на планерке у вас сильно оптимистичные оценки.
Задачи бывают сильно разные, для одних можно сделать оценку с точностью
до дня-двух, для других, может вообще ее нельзя сделать. Какие у вас?
Возможно вы пытаетесь делать оптимистичные оценки для задач из второй
группы?
А вообще телепатов здесь нет.
Так что, если нужна помощь давай приводи более конкретную проблему: как
производите оценку времени выполнения, планируете ли работу, если
разбивка больших задач на более мелкие, как отслеживается процесс
выполнения, задачи тривиальны или нет (например распознавание слитной
речи независимо от диктора для большого словаря с процентом ошибок менее
1% вы не сделаете и за 5 лет)
Здравствуйте, x64, Вы писали:
x64>Это да. А вот казалось бы, всё справедливо, оплошал — получи наказание, ан нет, всё равно не нравится, так уж люди устроены.
Тебе никогда не приходило в голову, что подход типа "оплошал — получи наказание" начисто на корню убивает какую бы то ни было инициативу подчиненных, — люди будут думать не о том, как сделать работу, а только о том, как избежать наказания?
Здравствуйте, vohta, Вы писали:
V>работа определяется на неделю-две вперед. узнается что не укладываемся в срок в конце срока — мол неуспели... и что делать.. ну давайте еще неделю берите и делайте... в итоге работа делается только к концу третей недели (что в 3-и раза больше...)
Классический случай когда срок можно умножать на Пи.
Реально причи этому может быть несколько:
1)Низкая квалификация программистов — лечится только введением в команду опытного программита.
2)Неумение давать оценки — лечится детальным планом работ (желательно почасовым) с соотвествующем контролем, потом можно вводить поправочные коэффициенты
3)Отсутствие автоматизированного тестирования и непрерывной интеграции, обычно может заятнуть сроки на 25% — 100%
4)Отсутсвие ручного тестирования также может заятнуть сроки на 25% — 100%
5)Вера в "человеко-месяц" — не вся работа может быть распараллелена между разработчиками. То что один будет делать месяц не всегда быть сделано четырьмя за неделю.
6)Изменение требований (хотя вряд ли такое бывает за неделю-две) — тут уже никуда не денешься, если требования постоянно меняются срок могут рости до бесконечности. Требованиями надо управлять.
7)Разгильдяйство программистов — вместо работы "тупо рубятся в кваку".
То что узнается о невыполнимости сроков в конце — ужасно. Менеджер должен знать о запаздывании на 1 день и сразуже сообщать начальству или принимать меры.
V>Сроки устанавливают сами программисты, с небольшой поправкой менеджера проекта, причем на планерке все реально и даже время есть с запасом....
Какова поправка менеджера, в большую или меньшую сторону?
Кстати как указывается срок, одной датой или диапазоном оптимистичной и пессимистичной оценки?
Здравствуйте, gandjustas, Вы писали:
G>Какова поправка менеджера, в большую или меньшую сторону?
в меньшую...
G>Кстати как указывается срок, одной датой или диапазоном оптимистичной и пессимистичной оценки?
одной датой
>Так что, если нужна помощь давай приводи более конкретную проблему: как >производите оценку времени выполнения,
Обговариваем функционал, рисуем интерфейс — программист грит — это примерно сутки — ставим 8 часов.
Далее бывают задачи оч.большие = где требуется редактирование ядра — программист грит неделя = ставим 16-32 часа
> планируете ли работу, если >разбивка больших задач на более мелкие,
да пытаемся детализировать. но задачи меньше чем на 4 часа пока не удалось запланировать... >как отслеживается процесс >выполнения,
по окончании запланированного срока — смотрим сделано или нет. всегда нет. думаем какого х.... че делать. добавляем еще неделю. через неделю тоже самое.
че делать? >задачи тривиальны или нет (например распознавание слитной >речи независимо от диктора для большого словаря с процентом ошибок менее >1% вы не сделаете и за 5 лет)
задачи в основном работа с реляционной БД, + прикручивание к не ГУИ + экспорт и импорт из различных форматов...
Здравствуйте, vohta, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Какова поправка менеджера, в большую или меньшую сторону? V>в меньшую...
То есть менеджер знает о стабильном срыве сроков, но дает меньшую оценку?
Или он совсем глупый или под начальство прогибается (что в принципе тоже самое).
G>>Кстати как указывается срок, одной датой или диапазоном оптимистичной и пессимистичной оценки? V>одной датой
Очень зря. Оценка названная программистом чаще всего является оптимистичной.
Для начала стоит все сроки множить на Пи (3.14), записывать оптимистичную оценку, данную программистом, и пессимистичную (домноженную). Потом можно контролировать ход выполнения работ и смотреть на что время тратится.
Здравствуйте, vohta, Вы писали:
G>>Какова поправка менеджера, в большую или меньшую сторону? V>в меньшую...
Ну приехали . Народ правильно сказал: умножать на ПИ!
V>Далее бывают задачи оч.большие = где требуется редактирование ядра — программист грит неделя = ставим 16-32 часа
Здравствуйте, vohta, Вы писали:
>>производите оценку времени выполнения, >Обговариваем функционал, рисуем интерфейс — программист грит — это примерно сутки — ставим 8 часов. >Далее бывают задачи оч.большие = где требуется редактирование ядра — программист грит неделя = ставим 16-32 часа
Да, потрясающий у Вас подсчет времени. Неделя 8 * 5 = 40. А ваших менеджеров таки направить на курсы повышения квалификации. 2 класс общеобразовательной школы. Учить арифметику и таблицу умножения. Дроби не давать — не осилят.
Теперь разберем из чего состоит задача.
1. Если код незнакомый, знакомство. Понимание через отладку. Если нужно рефакторинг. Понимание через рефакторинг.
2. Проектирование нового функционала. Подробное. А не в уме, как на совещании было.
3. Подготовка кода в внесению изменений. Опять рефакторинг.
4. Собственно кодирование. Говорит неделя, ну так 40 часов и запишем. И это только на пункт 4. А вы говорите 16-32.
5. Интеграция с остальным кодом. Это то что в пункте 3 делали, но теперь уже начисто.
6. Тестирование (в это время можно программеру дать другое задание), либо дать на проверку код соседа, попросить отревьювить код и т.д. Опять же старые баги есть наверно.
7. А теперь откровение. Оказывается после тестирования надо баги поправить. Иначе зачем тестировать-то. А потом снова на тестирование и снова баги.
Ну допустим у меня один баг в неделю на 20 коммитов. Но это в неторопливой обстановке. А ктоме того еще штук десять в неделю "not a bug" и половинка "a change request"
Далее пункты выполняемые совместно с остальными:
8. Покрытие тестами.
9. Документирование.
10. Коммуникации с коллегами по работе, совещание.
11. Коммуникации с начальством, отчеты, совещания.
12. Чтение проф литературы, блогов, RSDN и т.д.
13. Перерывы на отдых, чай, сигареты (кто курит), поболтать на различные темы.
14. Обязательно поболтать с любимой/любимым по ICQ.
А теперь начинаем думать. Я тут 14 пунктов перечислил, а программист (и я тож из таких) думает только про пункт 4.
Причем если вам пункты 12 — 14 не нравятся, то программистам, да и вообще здоровым людям, они необходимы. За пункт 14 вообще перегрызу горло
А вот теперь становится понятно на что уходит время программистов. Причем могу поспорить я тут что-то забыл. Но это еще не все.
Вот вы там делаете разбивку на части? Делаете. А если обнаруживается что забыли что-то уже в процессе работы? Добавляете в планы? Сдвигаете сроки? Как нет?! Почему?!
Но об этом в следующий раз.
Здравствуйте, vohta, Вы писали:
V>Здравствуйте, gandjustas, Вы писали:
G>>Какова поправка менеджера, в большую или меньшую сторону? V>в меньшую...
У вас там невроз должен быть всеобщий.
G>>Кстати как указывается срок, одной датой или диапазоном оптимистичной и пессимистичной оценки? V>одной датой
Зря. Но тут уже об этом сказали.
>>Так что, если нужна помощь давай приводи более конкретную проблему: как >>производите оценку времени выполнения, V>Обговариваем функционал, рисуем интерфейс — программист грит — это примерно сутки — ставим 8 часов. V>Далее бывают задачи оч.большие = где требуется редактирование ядра — программист грит неделя = ставим 16-32 часа
16 часов в неделе? Экстремально!
Есть хорошая практика: если прогнозы одно и того же специалиста всё время расходятся с реальностью, то нужно вычислить поправочный коэффициент, который потом использовать для более надёжного прогнозирования.
>> планируете ли работу, если >>разбивка больших задач на более мелкие, V>да пытаемся детализировать. но задачи меньше чем на 4 часа пока не удалось запланировать...
Ну это как раз нормально.
>>как отслеживается процесс >>выполнения, V>по окончании запланированного срока — смотрим сделано или нет. всегда нет. думаем какого х.... че делать. добавляем еще неделю. через неделю тоже самое.
Кино. Вот смотри, что происходит на самом деле. С одной стороны, менеджер сознательно занижает сроки, с другой — всё равно оттянет их туда, куда надо. Но начав оттягивать, он их будет тянуть хоть до бесконечности (будет-будет, можешь не спорить). Бухтеть — но всё равно тянуть. В таких условиях можно выкатить совершенно любые оценки, поскольку де-факто менеджменту безразлично — адекватные у него прогнозы или нет.
Или это такой метод подгонять сотрудников?
V>че делать?
Вылезти из виртуальной реальности.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
SE>Вот вы там делаете разбивку на части? Делаете. А если обнаруживается что забыли что-то уже в процессе работы? Добавляете в планы? Сдвигаете сроки? Как нет?! Почему?!
если что то забыли то это в следующий план. а в текущем то что записано не больше.
SE>Но об этом в следующий раз.
Спасибо за подробный ответ. кое что прояснилось:
— добавить время на планирование
— добавить время на багфиксинг
— добавить время на коммуникации
Здравствуйте, vohta, Вы писали:
SE>>Вот вы там делаете разбивку на части? Делаете. А если обнаруживается что забыли что-то уже в процессе работы? Добавляете в планы? Сдвигаете сроки? Как нет?! Почему?! V>если что то забыли то это в следующий план. а в текущем то что записано не больше.
Уже хорошо. В идеале оно так и должно работать. Но проблема в том, что если без забытой части релиз, как правило, выпустить не получится.
Объясню на примере. Работал я в одной небольшой конторе и заинтересовался, а почему, собственно, я сроки срываю. И заметил, что при разбиении проекта на части, я записывал части, а переходы между частями упускал. Не все линки и кнопочки на страничке не работали как надо. Сдай я страницу без доделок, я бы добавил кучу бесполезной работы тестировщикам и себе самому. Да еще и срок бы затянул сильнее.
Таким образов требуется постоянно корректировать текущий план, а не требовать завершить ошибочный план любой ценой.
Мой коллега так эту ситуацию описал:
— Хозяюшка, а шов то криво пошел!
— Да знаю я, вот сейчас его закончу, а потом уже спорю.
Тут много рассказали про умножение планов на коэффициенты и про оптимистичную/пессимистичную оценку.
У коэффициента есть по моему мнению существенный недостаток — он берется соверщенно произвольно. Причем чаще всего программист задачу завершает вовремя, но дополнительное время требует на ускользнувшие из первоначальной оценки задачи.
Дополнительный минус — необходимость скрывать от разработчиков этот коэффициент. Они ведь не дураки, быстро догадаются что к чему и начнут лодырничать. Неприятно, но и я тоже иногда этим грешу.
А вот оценка диапазона может дать более точный результат. Достигается это использованием риск-менеджмента. Мало того, кроме диапазона дат на выходе будут еще и вероятностные оценки для каждой даты. Плюс появляется возможность влиять на ситуацию — кто предупрежден, тот вооружен.
Сам механизм учета рисков прост — берем с полки книгу ДеМарко "Вальсируя с медведями"
и там даже примеры расчетов есть и ссылки на сайты с тулзами.
Но вот незадача — выделить и оценить действительно существующие риски очень непросто. Я до сих пор топчусь вокруг этого и не знаю с какой стороны подступиться. Скорее всего нужно собирать метрики по текущим проектам: с чем непредвиденным столкнулись, какие убытки (расход времени) и как часто такие ситуации возникают.
Проблема также и в том, что мне от этого ни холодно не жарко — я на своих проектах ни разу не менеджер.
Здравствуйте, gandjustas, Вы писали:
G>Для начала стоит все сроки множить на Пи (3.14), записывать оптимистичную оценку, данную программистом, и пессимистичную (домноженную). Потом можно контролировать ход выполнения работ и смотреть на что время тратится.
Вы что, "умножить на Пи" действительно воспринимаете буквально?
Здравствуйте, dmoz, Вы писали:
D>Здравствуйте, gandjustas, Вы писали:
G>>Для начала стоит все сроки множить на Пи (3.14), записывать оптимистичную оценку, данную программистом, и пессимистичную (домноженную). Потом можно контролировать ход выполнения работ и смотреть на что время тратится.
D>Вы что, "умножить на Пи" действительно воспринимаете буквально?
Зато какая высокая точность у пессимистичной оценки. Пусть срок на задачу три дня.
Тогда пессимистичной оценкой будет одна неделя, четыре дня, три часа, двадцать одна минута и тридцать шесть секунд, и не секундой больше.
Здравствуйте, dmoz, Вы писали:
D>Здравствуйте, gandjustas, Вы писали:
G>>Для начала стоит все сроки множить на Пи (3.14), записывать оптимистичную оценку, данную программистом, и пессимистичную (домноженную). Потом можно контролировать ход выполнения работ и смотреть на что время тратится.
D>Вы что, "умножить на Пи" действительно воспринимаете буквально?
Да. И во многих случаях такой коэффициент очень адекватен.
gandjustas пишет:
> Реально причи этому может быть несколько:
8) Программисту банально не работается. Хроническая депрессия и
меланхолия. С девушкой поссорился, голубь на голову нагадил, в
транспорте нахамили, начальник поругал итд итп. Столкнулся. Победить не
смог. Потом эти парни со временем ушли искать лучшей жизни.
vohta пишет: > > > G>Какова поправка менеджера, в большую или меньшую сторону? > в меньшую...
А обоснование сего действа. Программисты в 90% случаев дают
оптимистичные оценки (т.е. когда все хорошо, нигде никаких ошибок, все
идет у программиста, как по маслу — но много ли вы таких ситуаций
наблюдали?)
> >>Так что, если нужна помощь давай приводи более конкретную проблему: как >>производите оценку времени выполнения, > Обговариваем функционал, рисуем интерфейс — программист грит — это > примерно сутки — ставим 8 часов.
Значит до 16 раб часов будет
> Далее бывают задачи оч.большие = где требуется редактирование ядра — > программист грит неделя = ставим 16-32 часа
Во-первых, длительность задач больше 2-3 днех — это моветон, пусть
программист сделает план на задачи не более, чем о 2-3 дня.
Во-вторых, программист дает опять же сильно оптимистичную оценку, а вы
ее еще и урезаете.
В итоге вы получаете только нервотрепку, понижение качества и все едино
не успеваете быстрее, чем если бы не резали так оценки.
SE пишет: > > Тут много рассказали про умножение планов на коэффициенты и про > оптимистичную/пессимистичную оценку. > У коэффициента есть по моему мнению существенный недостаток — он берется > соверщенно произвольно. Причем чаще всего программист задачу завершает > вовремя, но дополнительное время требует на ускользнувшие из > первоначальной оценки задачи.
+100
Если нам не помогут, то мы тоже никого не пощадим.
Автор(ы): Фредерик Брукс
Автор(ы): Дж. Ханк Рейнвотер
. Народ правильно сказал: умножать на ПИ!
Автор(ы): Том ДеМарко, Тимоти Листер
