Эмпирический закон Паркинсона:
Работа заполняет всё время, отпущенное на неё
Типичный алгоритм с таймером:
1. Неким образом происходит оценка, за какой срок программист может выполнить работу.
2. Включается таймер обратного отсчёта.
3. Варианты:
3.а. Задача не выполняется в срок
3.б. Задача выполняется точно в срок
3.в. Задача выполняется до истечения срока
Вариант "а" может происходить потому, что срок был излишне оптимистичен для конкретного программиста. Или потому, что программист не делал задачу, так как думал, что сможет сделать её быстрее, а потом когда начал в итоге не успел.
Вариант "б" может быть результатом эффективного предсказания времени. А может просто следствием закона Паркинсона, программист сделал задачу, а всё оставшееся время отдыхал.
Варинат "в" произошёл вопреки закону Паркинсона. Может было выделено столько времени, что программист просто не знал, как можно так сильно растянуть задачу. В общем на него закон не подействовал или подействовал в не полную силу.
Против этого выступает алгоритм с секундомером.
1. Изначальное предполагается, что оценивать время на решение задачи, значит попасть на алгоритм с таймером, и в свою очередь на закон Паркинсона, потому время не оценивается.
2. Включается секундомер прямого отсчёта.
3. Варианты:
3.а. Срока нет, программист делает задачу запредельно долго.
3.б. Срока нет, задача выполняется за приемлемое время.
3.б. Срока нет, задача была выполнена на удивления быстро.
Причём есть ещё вариант без таймера и секундомера, когда нет сроков, но и смотреть на убегающее время негде. Вот и возникает вопрос, а насколько на самом деле оправдано использование таймеров, помогает ли это быстрее сделать задачу, или напротив вредит и расхолаживает?
Идея же секундомера вытекает из гибких методологий. Взять хотя бы тот же скрам. Временное ограничение спринта условность для максимально быстрого получения новой работающей версии, а вовсе не для обратного отсчёта решения задачи по классической модели водопада. Нужно делать как сделается, но делать. Второй вопрос насколько целесообразно использовать секундомеры, так как просто отказаться от подсчёта времени на задачу нельзя?
Здравствуйте, velkin, Вы писали:
V>Тема относится к управлению временем. V>
V>Эмпирический закон Паркинсона:
V>Работа заполняет всё время, отпущенное на неё
При нормальной организации работ:
1. Программист сначала прогнозирует трудоёмкость задачи (в днях).
2. Знает за какую следующую задачу он возьмётся (или какой список возможных следующих задач).
3. Если есть шанс, что он начнёт делать что то лишнее (например преждевременную оптимизацию), нужен за ним контроль.
4. Программист ни за каким таймером не следит.
Если сроки не совпали с ожидаемыми — должно быть объяснение у программиста, но не более.
Все попытки "ускорить" программиста, который и так сидит и работает, интенсивными "накачками", или подвешиванием таймера могут иметь совсем не тот который ожидается.
Re[2]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, slm, Вы писали:
slm>При нормальной организации работ: slm>1. Программист сначала прогнозирует трудоёмкость задачи (в днях).
Трудоемкость в днях??? Может в человеко-днях? Или вы полагаете (ошибочно) что человеко-день всегда равен 1 человек*1 день?
slm>2. Знает за какую следующую задачу он возьмётся (или какой список возможных следующих задач).
Откуда знает?
slm>3. Если есть шанс, что он начнёт делать что то лишнее (например преждевременную оптимизацию), нужен за ним контроль.
Что значит контроль?
slm>4. Программист ни за каким таймером не следит.
А что если не указывается в оценку?
Здравствуйте, velkin, Вы писали:
V> Вот и возникает вопрос, а насколько на самом деле оправдано использование таймеров, помогает ли это быстрее сделать задачу, или напротив вредит и расхолаживает?
Я так понимаю вопрос в том, что дедлайн по времени помогает работе или нет. На практике конечно помогает. Большинство программистов недостаточно дисциплинированны и очень любят любят заниматься "архитектурным творчеством", не остигая реальных целей.
Идеальный вариант — ясная цель, короткий дедлайн, понятное вознаграждение за достижение цели в срок (или наказание за не достижение).
Re[3]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, slm, Вы писали:
slm>>При нормальной организации работ: slm>>1. Программист сначала прогнозирует трудоёмкость задачи (в днях). G>Трудоемкость в днях??? Может в человеко-днях? Или вы полагаете (ошибочно) что человеко-день всегда равен 1 человек*1 день?
Сколько он дней будет делать эту задачу. Это чисто — чтобы он знал, какие решения по дизайну он собирается использовать (или сколько строк собирается написать) и не писал лишнего.
slm>>2. Знает за какую следующую задачу он возьмётся (или какой список возможных следующих задач). G>Откуда знает?
Забота менеджера или тимлида или прочих элементов процесса разработки.
slm>>3. Если есть шанс, что он начнёт делать что то лишнее (например преждевременную оптимизацию), нужен за ним контроль. G>Что значит контроль?
Кто то его должен раз в день спросить — какой прогресс, что осталось, какие трудности, итд.
slm>>4. Программист ни за каким таймером не следит. G>А что если не указывается в оценку?
Если в свою — пусть объяснит почему. Чисто что бы от действительности не отрываться,
и при следующей оценке — не расслабляться, а наоборот сосредоточится.
Если оценку менеджера проекта — значит менеджер проекта плохо спланировал.
Re[2]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, gandjustas, Вы писали:
G>Идеальный вариант — ясная цель, короткий дедлайн, понятное вознаграждение за достижение цели в срок (или наказание за не достижение).
Дрессировка какая-то... А как наказывать собираетесь?
Кодом людям нужно помогать!
Re[3]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Идеальный вариант — ясная цель, короткий дедлайн, понятное вознаграждение за достижение цели в срок (или наказание за не достижение).
S>Дрессировка какая-то... А как наказывать собираетесь?
Ну как в уставе — выговор, строгий выговор, с занесением в партбилет, наряд на кухню
А по факту вознаграждение и наказание сильно зависит от системы мотивации и оплаты труда в компании.
ЗЫ. Именно дрессировка, чтобы результат совпадал с ожиданиями не требовал усилий со стороны руководителя.
Re[4]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, slm, Вы писали:
slm>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, slm, Вы писали:
slm>>>При нормальной организации работ: slm>>>1. Программист сначала прогнозирует трудоёмкость задачи (в днях). G>>Трудоемкость в днях??? Может в человеко-днях? Или вы полагаете (ошибочно) что человеко-день всегда равен 1 человек*1 день? slm>Сколько он дней будет делать эту задачу. Это чисто — чтобы он знал, какие решения по дизайну он собирается использовать (или сколько строк собирается написать) и не писал лишнего.
Сколько он дней будет делать задачу величина, которую сам программист оценить не сможет. Он может сказать три дня, а у него будет совещание на полдня, потом внезапный критичный баг, который еще день съест, а потом срочная задача починить ченить клиенту. За 3 дня он может и не приступить к задаче.
Вообще срок спрашивать у программиста — бессмысленное занятие, он сам свое время не контролирует.
slm>>>3. Если есть шанс, что он начнёт делать что то лишнее (например преждевременную оптимизацию), нужен за ним контроль. G>>Что значит контроль? slm>Кто то его должен раз в день спросить — какой прогресс, что осталось, какие трудности, итд.
Скажет все ок, закончу завтра, трудностей нет.
И будет говорить так в течение недели.
slm>>>4. Программист ни за каким таймером не следит. G>>А что если не указывается в оценку?
slm>Если в свою — пусть объяснит почему. Чисто что бы от действительности не отрываться, slm>и при следующей оценке — не расслабляться, а наоборот сосредоточится.
См выше про контроль своего времени программистом.
Здравствуйте, velkin, Вы писали:
V>Против этого выступает алгоритм с секундомером.
Это дичайшее упрощение. Час Пети сегодня и час Васи завтра — две абсолютно разные вещи. Допустим, у Пети сегодня отходняк после днюхи. Васю штырит с кофе т.к. у него дедлайн, но завтра на работе он будет откровенно дрыхнуть, т.к. вчера работал за пятерых. Вы серьёзно хотите управлять такими мелочами?
Куда проще ограничиться распределением задач по итерациям: все случайные вылеты за сроки успевают нейтрализовать друг друга и остаются только системные проблемы, с которыми и надо разбираться.
V>Идея же секундомера вытекает из гибких методологий. Взять хотя бы тот же скрам. Временное ограничение спринта условность для максимально быстрого получения новой работающей версии, а вовсе не для обратного отсчёта решения задачи по классической модели водопада. Нужно делать как сделается, но делать. Второй вопрос насколько целесообразно использовать секундомеры, так как просто отказаться от подсчёта времени на задачу нельзя?
Это не имеет никакого отношения к скраму. Вот классное описание
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, slm, Вы писали:
slm>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, slm, Вы писали:
slm>>>>При нормальной организации работ: slm>>>>1. Программист сначала прогнозирует трудоёмкость задачи (в днях).
G>Вообще срок спрашивать у программиста — бессмысленное занятие, он сам свое время не контролирует.
Мы вроде говорим про трудоёмкость? Откуда сроки взялись?
Да количество "рабочих" часов в трудодне обычно известная в среднем величина.
Смысл этой оценки — информация для планирования для прожект менеджера, и понимание самим программистом ожидаемых сроков.
slm>>Кто то его должен раз в день спросить — какой прогресс, что осталось, какие трудности, итд. G>Скажет все ок, закончу завтра, трудностей нет. G>И будет говорить так в течение недели.
Если будете для "галочки" спрашивать, ответ то же получите для "галочки"
А если таки программист "влип" на небольшой задаче в такое, то надо разбираться и что то предпринимать для неповторения в будущем.
slm>>Если в свою — пусть объяснит почему. Чисто что бы от действительности не отрываться, slm>>и при следующей оценке — не расслабляться, а наоборот сосредоточится. G>См выше про контроль своего времени программистом.
Я же говорю, разбираться с такими случаями надо.
Re[6]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, slm, Вы писали:
slm>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, slm, Вы писали:
slm>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Здравствуйте, slm, Вы писали:
slm>>>>>При нормальной организации работ: slm>>>>>1. Программист сначала прогнозирует трудоёмкость задачи (в днях).
G>>Вообще срок спрашивать у программиста — бессмысленное занятие, он сам свое время не контролирует. slm>Мы вроде говорим про трудоёмкость? Откуда сроки взялись?
Ты сам сказал про дни, а дни это срок. Если ты говоришь человеку "будет готово за 3 дня", то результат с тебя спросят ровно через три дня.
slm>Да количество "рабочих" часов в трудодне обычно известная в среднем величина.
А вот продуктивность — величина неизвестная и очень даже изменчивая.
slm>Смысл этой оценки — информация для планирования для прожект менеджера, и понимание самим программистом ожидаемых сроков.
Так мы про сроки или про трудоемкость? Определись.
slm>>>Кто то его должен раз в день спросить — какой прогресс, что осталось, какие трудности, итд. G>>Скажет все ок, закончу завтра, трудностей нет. G>>И будет говорить так в течение недели. slm>Если будете для "галочки" спрашивать, ответ то же получите для "галочки"
И как спрашивать "не для галочки"? Из твоих сообщений этого не видно.
slm>>>Если в свою — пусть объяснит почему. Чисто что бы от действительности не отрываться, slm>>>и при следующей оценке — не расслабляться, а наоборот сосредоточится. G>>См выше про контроль своего времени программистом. slm>Я же говорю, разбираться с такими случаями надо.
Какими? Думаешь они не возникают постоянно? Попробуй померить за неделю сколько программист не за разработкой проводит, получится очень непостоянная во времени величина. Особенно если по дням разбить.
Re[7]: Закон Паркинсона: секундомеры против таймеров
G>>>Вообще срок спрашивать у программиста — бессмысленное занятие, он сам свое время не контролирует. slm>>Мы вроде говорим про трудоёмкость? Откуда сроки взялись? G>Ты сам сказал про дни, а дни это срок. Если ты говоришь человеку "будет готово за 3 дня", то результат с тебя спросят ровно через три дня.
Ээээ
Правильно сказать (и самое главное услышать) "у меня это займёт 3 дня.".
Похоже на формальную придирку.
slm>>Да количество "рабочих" часов в трудодне обычно известная в среднем величина. G>А вот продуктивность — величина неизвестная и очень даже изменчивая.
slm>>Смысл этой оценки — информация для планирования для прожект менеджера, и понимание самим программистом ожидаемых сроков. G>Так мы про сроки или про трудоемкость? Определись.
Чего не понятного от программиста ждём трудоёмкость.
Если он над задачей работал 2 дня из трёх, и кто надо в курсе (тим лид, PM), то все об этом знают.
Какие проблемы?
slm>>>>Кто то его должен раз в день спросить — какой прогресс, что осталось, какие трудности, итд. G>>>Скажет все ок, закончу завтра, трудностей нет. G>>>И будет говорить так в течение недели. slm>>Если будете для "галочки" спрашивать, ответ то же получите для "галочки" G>И как спрашивать "не для галочки"? Из твоих сообщений этого не видно.
Поговорить надо с разработчиком не для галочки. Как объяснить это даже и не знаю.
Представь просто что ты с человеком разговариваешь о чём то лично для тебя важном.
slm>>>>Если в свою — пусть объяснит почему. Чисто что бы от действительности не отрываться, slm>>>>и при следующей оценке — не расслабляться, а наоборот сосредоточится. G>>>См выше про контроль своего времени программистом. slm>>Я же говорю, разбираться с такими случаями надо. G>Какими? Думаешь они не возникают постоянно? Попробуй померить за неделю сколько программист не за разработкой проводит, получится очень непостоянная во времени величина. Особенно если по дням разбить.
Проблемы с мотивацией ?
Так не демотивируйте его разными таймерами и прочими мелко-шкурными ужимками.
Ну и с "реальной" мотивацие что то делать надо.
Re[8]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, slm, Вы писали:
slm>Здравствуйте, gandjustas, Вы писали:
G>>>>Вообще срок спрашивать у программиста — бессмысленное занятие, он сам свое время не контролирует. slm>>>Мы вроде говорим про трудоёмкость? Откуда сроки взялись? G>>Ты сам сказал про дни, а дни это срок. Если ты говоришь человеку "будет готово за 3 дня", то результат с тебя спросят ровно через три дня.
slm>Ээээ slm>Правильно сказать (и самое главное услышать) "у меня это займёт 3 дня.". slm>Похоже на формальную придирку.
В том то и прикол, что заранее ты не знаешь сколько займет. Ибо возникают "внезапные" задачи, ожидания других людей итд.
Если взять проект, побить на задачи, потом попросить каждую оценить в днях, сложить оценки и поделить на количество людей, то итоговый срок окажется примерно в Пи^2 раз меньше, чем реальный срок выполнения проекта.
slm>>>Да количество "рабочих" часов в трудодне обычно известная в среднем величина. G>>А вот продуктивность — величина неизвестная и очень даже изменчивая.
slm>>>Смысл этой оценки — информация для планирования для прожект менеджера, и понимание самим программистом ожидаемых сроков. G>>Так мы про сроки или про трудоемкость? Определись.
slm>Чего не понятного от программиста ждём трудоёмкость.
Как тогда оценить трудоемкость в днях?
slm>Если он над задачей работал 2 дня из трёх, и кто надо в курсе (тим лид, PM), то все об этом знают. slm>Какие проблемы?
Проблема в том, что оценка 3 дня, а работал 5. И не потому что сам баран, а потому что совещания, багфиксы итп.
Оценка то дается заранее.
slm>>>>>Кто то его должен раз в день спросить — какой прогресс, что осталось, какие трудности, итд. G>>>>Скажет все ок, закончу завтра, трудностей нет. G>>>>И будет говорить так в течение недели. slm>>>Если будете для "галочки" спрашивать, ответ то же получите для "галочки" G>>И как спрашивать "не для галочки"? Из твоих сообщений этого не видно.
slm>Поговорить надо с разработчиком не для галочки. Как объяснить это даже и не знаю. slm>Представь просто что ты с человеком разговариваешь о чём то лично для тебя важном.
То есть ты сам не очень понимаешь что же означает "контролировать", про которое ты говорил выше.
slm>>>>>Если в свою — пусть объяснит почему. Чисто что бы от действительности не отрываться, slm>>>>>и при следующей оценке — не расслабляться, а наоборот сосредоточится. G>>>>См выше про контроль своего времени программистом. slm>>>Я же говорю, разбираться с такими случаями надо. G>>Какими? Думаешь они не возникают постоянно? Попробуй померить за неделю сколько программист не за разработкой проводит, получится очень непостоянная во времени величина. Особенно если по дням разбить.
slm>Проблемы с мотивацией ? slm>Так не демотивируйте его разными таймерами и прочими мелко-шкурными ужимками. slm>Ну и с "реальной" мотивацие что то делать надо.
В том то и прикол, что не с мотивацией. Просто работа проектная так устроена. Как ни крути — не сидит программист по 8 часов над одной задачей.
А даже если сидит, то это соврешенно не означает, что он одинаково эффективно работает в каждый момент.
Именно нелинейность утилизации времени и нелинейность продуктивности делает бессмысленной оценку в часах\днях\неделях или любых других временных величинах. Человеко-дни тоже ничуть ни лучше.
Re[9]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, gandjustas,
slm>>Правильно сказать (и самое главное услышать) "у меня это займёт 3 дня.". G>В том то и прикол, что заранее ты не знаешь сколько займет. Ибо возникают "внезапные" задачи, ожидания других людей итд. G>Проблема в том, что оценка 3 дня, а работал 5. И не потому что сам баран, а потому что совещания, багфиксы итп. G>Оценка то дается заранее.
Программисты обычно оценивают трудоемкость в "идеальных днях" (человеко-днях). Перевести трудоемкость в сроки (идеальные дни -> в календарные сроки) с учетом всех совещаний, багфиксов и т.п. — это уже задача менеджера.
Re[10]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, Vlad_SP, Вы писали:
V_S>Здравствуйте, gandjustas,
slm>>>Правильно сказать (и самое главное услышать) "у меня это займёт 3 дня.". G>>В том то и прикол, что заранее ты не знаешь сколько займет. Ибо возникают "внезапные" задачи, ожидания других людей итд. G>>Проблема в том, что оценка 3 дня, а работал 5. И не потому что сам баран, а потому что совещания, багфиксы итп. G>>Оценка то дается заранее.
V_S>Программисты обычно оценивают трудоемкость в "идеальных днях" (человеко-днях). Перевести трудоемкость в сроки (идеальные дни -> в календарные сроки) с учетом всех совещаний, багфиксов и т.п. — это уже задача менеджера.
Ты забыл добавить "в теории".
Есть еще одна проблема — "идеальные дни", сука, у всех разные.
Re[9]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, gandjustas, Вы писали:
G>В том то и прикол, что заранее ты не знаешь сколько займет. Ибо возникают "внезапные" задачи, ожидания других людей итд.
G>Если взять проект, побить на задачи, потом попросить каждую оценить в днях, сложить оценки и поделить на количество людей, то итоговый срок окажется примерно в Пи^2 раз меньше, чем реальный срок выполнения проекта.
Есть количество рабочих часов в день для программиста (от 4 до 6)
Есть планируемый процент загрузки с учётом техподдрежки, инспекций итд.
И если вам важны сроки — то есть статистика по программисту. (или хотя бы коэфициент ошибки для данного программиста)
Можно уже планировать и вносить по ходу изменения в план (например, при повышении загрузки на поддержке).
G>>>Так мы про сроки или про трудоемкость? Определись.
slm>>Чего не понятного от программиста ждём трудоёмкость. G>Как тогда оценить трудоемкость в днях?
Если не получается оценить в 5-часовых днях, оцените в часах.
Оцените в количестве строк кода. (Если есть статистика по предыдущим задачам)
slm>>Если он над задачей работал 2 дня из трёх, и кто надо в курсе (тим лид, PM), то все об этом знают. slm>>Какие проблемы? G>Проблема в том, что оценка 3 дня, а работал 5. И не потому что сам баран, а потому что совещания, багфиксы итп. G>Оценка то дается заранее.
Он то в 3 дня оценил, а прожект менеджер в сколько ?
slm>>>>>>Кто то его должен раз в день спросить — какой прогресс, что осталось, какие трудности, итд. G>>>>>Скажет все ок, закончу завтра, трудностей нет. G>>>>>И будет говорить так в течение недели. slm>>>>Если будете для "галочки" спрашивать, ответ то же получите для "галочки" G>>>И как спрашивать "не для галочки"? Из твоих сообщений этого не видно.
slm>>Поговорить надо с разработчиком не для галочки. Как объяснить это даже и не знаю. slm>>Представь просто что ты с человеком разговариваешь о чём то лично для тебя важном. G>То есть ты сам не очень понимаешь что же означает "контролировать", про которое ты говорил выше.
Действительно, как разговаривать с людьми не "для галочки", научить и объяснить не могу.
slm>>>>>>Если в свою — пусть объяснит почему. Чисто что бы от действительности не отрываться, slm>>>>>>и при следующей оценке — не расслабляться, а наоборот сосредоточится. G>>>>>См выше про контроль своего времени программистом. slm>>>>Я же говорю, разбираться с такими случаями надо. G>>>Какими? Думаешь они не возникают постоянно? Попробуй померить за неделю сколько программист не за разработкой проводит, получится очень непостоянная во времени величина. Особенно если по дням разбить.
Что случается постоянно?
оценивает в 3 дня, а делает за 5?
отлично.
с такой стабильностью уже можно планировать.
slm>>Проблемы с мотивацией ? slm>>Так не демотивируйте его разными таймерами и прочими мелко-шкурными ужимками. slm>>Ну и с "реальной" мотивацие что то делать надо. G>В том то и прикол, что не с мотивацией. Просто работа проектная так устроена. Как ни крути — не сидит программист по 8 часов над одной задачей. G>А даже если сидит, то это соврешенно не означает, что он одинаково эффективно работает в каждый момент.
G>Именно нелинейность утилизации времени и нелинейность продуктивности делает бессмысленной оценку в часах\днях\неделях или любых других временных величинах. Человеко-дни тоже ничуть ни лучше.
Нелинейность возникает при нарушении тех-процесса: отсутствует дизайн/архитектура/требования.
Плюс ко всему из за этих проблем становится невозможным адектватное действительности разбиение на задачи.
Re[2]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, Sinix, Вы писали: S>Это дичайшее упрощение. Час Пети сегодня и час Васи завтра — две абсолютно разные вещи. Допустим, у Пети сегодня отходняк после днюхи. Васю штырит с кофе т.к. у него дедлайн, но завтра на работе он будет откровенно дрыхнуть, т.к. вчера работал за пятерых. Вы серьёзно хотите управлять такими мелочами?
Давайте тогда уточним термин секундомеры. Предположим есть очень хорошая разбивка задач на подзадачи. К каждой задаче привязывается тип: моделирование, требование, проектирование, конструирование, испытание, ошибка, документирование, развёртывание, поддержка и так далее. Так же существует жёсткая связь между задачей в трекере и репозиторием. Если программист что-то коммитит, то не от балды исправляя весь проект, а под конкретную подзадачу. Иначе говоря существует некий уровень организации процесса разработки.
И, для примера, у него в трее болтается секундомер, абсолютно любой, хоть помидорного типа. Секундомер этот с помощью некоего api связывается с трекером и получает список текущих задач. Далее программист выбирает или меняет в секундомере задачу. Учёт времени происходит автоматически, то есть он пусть хоть сто раз переключается с задачи на задачу, секундомер это просто запишет, и общее время тоже сам посчитает. Речь здесь как раз не о менеджере проекта, а о разработчике, который решает подзадачу.
Иными словами в процессе работы программиста никто не пинает, не спрашивает сколько он работал и что сделал. Мысль отчасти напоминает TDD, когда всё работает, юнит тесты уже писать как-то лень, да и из памяти улетучиваются детали. Так же и тут, с той лишь разницей, что если взять не автоматизированный секундомер, и заставить вручную править трекер, тогда да, разработчику это будет крайне не удобно и времязатратно. Потому речь прежде всего об автоматизированных секундомерах, которые могут записывать всё вплоть до мелочей, и при этом никого не напрягать.
Под таймерами тоже понимались приложения высокого уровня интерактивности. Не просто какая-то дата, которую ещё нужно где-то посмотреть, или активировать событие посредством человека. Нет, имелся в виду список задач, в каждой из которых есть таймер и в реальном времени убывают секунды (минуты, часы).
Пример не автоматизированных секундомера и таймера.
секундомер
таймер
Вопрос в том, какое преимущество даёт та или иная техника и её общая адекватность. Используемые инструменты должны решать проблемы, а не создавать их. Потому изначально не рассматриваю техники, когда программистам нужно самим думать сколько времени займёт задача, особенно не разделённая ещё на подзадачи. Или ручной подсчёт и запись времени, так как такой способ в любом случае не точен и заставляет писать всё от балды, что искажает картину больше, нежели если бы подсчёта вообще не было.
Re[10]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, slm, Вы писали:
slm>Здравствуйте, gandjustas, Вы писали:
G>>В том то и прикол, что заранее ты не знаешь сколько займет. Ибо возникают "внезапные" задачи, ожидания других людей итд.
G>>Если взять проект, побить на задачи, потом попросить каждую оценить в днях, сложить оценки и поделить на количество людей, то итоговый срок окажется примерно в Пи^2 раз меньше, чем реальный срок выполнения проекта.
slm>Есть количество рабочих часов в день для программиста (от 4 до 6) slm>Есть планируемый процент загрузки с учётом техподдрежки, инспекций итд.
И какой процент запланировать? Он ведь тоже нелинейный.
slm>И если вам важны сроки — то есть статистика по программисту. (или хотя бы коэфициент ошибки для данного программиста)
А пробовали реально статистику снимать? Я пробовал. Из-за закона паркинсона программист никогда не делает быстрее срока, даже если срок раздут в несколько раз. (отчего от раздут ниже)
slm>Можно уже планировать и вносить по ходу изменения в план (например, при повышении загрузки на поддержке).
Хороший план должен оставаться в пределах допустимых значений все время проекта, а не разъезжаться в разы.
G>>>>Так мы про сроки или про трудоемкость? Определись. slm>>>Чего не понятного от программиста ждём трудоёмкость. G>>Как тогда оценить трудоемкость в днях?
slm>Если не получается оценить в 5-часовых днях, оцените в часах. slm>Оцените в количестве строк кода. (Если есть статистика по предыдущим задачам)
Так всетаки в чем оценивать? В днях или строках кода? Это две принципиально разные величины.
slm>>>Если он над задачей работал 2 дня из трёх, и кто надо в курсе (тим лид, PM), то все об этом знают. slm>>>Какие проблемы? G>>Проблема в том, что оценка 3 дня, а работал 5. И не потому что сам баран, а потому что совещания, багфиксы итп. G>>Оценка то дается заранее. slm>Он то в 3 дня оценил, а прожект менеджер в сколько ?
А ПМ не оценивает. Он может выполнить преобразования и вписать оценку в план.
Вот я и спрашиваю что какие оценки давать и что с ними потом деалть, чтобы получить реалистичный план и уменьшить эффект паркинсона.
slm>>>>>>>Если в свою — пусть объяснит почему. Чисто что бы от действительности не отрываться, slm>>>>>>>и при следующей оценке — не расслабляться, а наоборот сосредоточится. G>>>>>>См выше про контроль своего времени программистом. slm>>>>>Я же говорю, разбираться с такими случаями надо. G>>>>Какими? Думаешь они не возникают постоянно? Попробуй померить за неделю сколько программист не за разработкой проводит, получится очень непостоянная во времени величина. Особенно если по дням разбить.
slm>Что случается постоянно? slm>оценивает в 3 дня, а делает за 5? slm>отлично. slm>с такой стабильностью уже можно планировать.
Если бы такая стабильность была всегда, проблем бы не было.
на практике чаще получается так:
1) Программист оценивает задачу в 3 дня, а делает за 5
2) Появляется похожая по объему задача, он снова оценивает в 3 дня, а делает за 5
3) Появляется тертья задача, которая такая же как первая и на 90% может быть скопипащена, она также оценена в 3 дня, но ПМ уже посчитал поправочный коэффициент и поставил 5 дней. А программист за день все скопипастил, и 4 дня смотрел котиков.
Об этом и был пост ТС — если ты начинаешь считать время, то попадаешь на эффект паркинсона.
slm>>>Проблемы с мотивацией ? slm>>>Так не демотивируйте его разными таймерами и прочими мелко-шкурными ужимками. slm>>>Ну и с "реальной" мотивацие что то делать надо. G>>В том то и прикол, что не с мотивацией. Просто работа проектная так устроена. Как ни крути — не сидит программист по 8 часов над одной задачей. G>>А даже если сидит, то это соврешенно не означает, что он одинаково эффективно работает в каждый момент.
G>>Именно нелинейность утилизации времени и нелинейность продуктивности делает бессмысленной оценку в часах\днях\неделях или любых других временных величинах. Человеко-дни тоже ничуть ни лучше.
slm>Нелинейность возникает при нарушении тех-процесса: отсутствует дизайн/архитектура/требования.
Это заблуждение. Нелинейность возникает потому что люди это люди, а не роботы.
Re[3]: Закон Паркинсона: секундомеры против таймеров
Здравствуйте, velkin, Вы писали:
V> Предположим есть очень хорошая разбивка задач на подзадачи.
Допустим, но это сверхтребование конечно.
V>И, для примера, у него в трее болтается секундомер, абсолютно любой, хоть помидорного типа. С
Ну а зачем? Что с этого получит программист, что получит менеджер?
Только чур, про оценку тикетов в часах не писать. Час разработчика сегодня (день тяжёлый) и час завтра — настроение ок, сделал как-бы-невозможный-тикет — могут отличаться по продуктивности в разы.
Оценка тикетов? Тоже мимо.
Если перед итерацией уже провели планёрку и все тикеты на ближайшую итерацию уже размечены в трекере, смысл в дополнительном отслеживании?
V>Потому речь прежде всего об автоматизированных секундомерах, которые могут записывать всё вплоть до мелочей, и при этом никого не напрягать.
Не сработает, вот тут
Вот допустим у меня сейчас в личной очереди висит 7 тикетов (если общая очередь пустая — остальные могут что-то забрать себе), из них 5 ждут исправления других компонентов, над двумя работаю (первый — чисто написать код, второй — погонять и найти проблему в уже написанном). Как по ним автоматически раскидать время и как использовать это время для оценки?
Хинт: по одному тикету из пяти "зависших" нужна пара человекодней работы, остальные 4 висят чисто для формальности, чтобы не забыть проверить после исправления других тикетов (дел на 5 минут). Как усреднять будем?
V>Вопрос в том, какое преимущество даёт та или иная техника и её общая адекватность. Используемые инструменты должны решать проблемы, а не создавать их.
+1.
Встречный вопрос: зачем нам точное время, если процесс поставлен более-меннее правильно?
Достаточно:
1. Поставленного цикла работы с тикетами. Т.е. для каждой задачи не приходится изобретать что-то новое, достаточно поменять статус в трекере (или он именяется автоматом, после коммита кода/срабатывания тестов).
2. Разбиения задачи на мелкие тикеты (работа одному человеку на промежуток от пары часов до двух дней.
3. Соглашения о работе малыми итерациями — на момент закрытия итерации тикеты или исправлены, или переезжают на следующую итерацию.
4. Раскидывания задач по итерациям, например, как описано у SkyDance
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, slm, Вы писали:
slm>>Здравствуйте, gandjustas, Вы писали:
G>>>В том то и прикол, что заранее ты не знаешь сколько займет. Ибо возникают "внезапные" задачи, ожидания других людей итд.
G>>>Если взять проект, побить на задачи, потом попросить каждую оценить в днях, сложить оценки и поделить на количество людей, то итоговый срок окажется примерно в Пи^2 раз меньше, чем реальный срок выполнения проекта.
slm>>Есть количество рабочих часов в день для программиста (от 4 до 6) slm>>Есть планируемый процент загрузки с учётом техподдрежки, инспекций итд. G>И какой процент запланировать? Он ведь тоже нелинейный.
(50 — 80) подбор методом тыка (другими словами статисика). Главное — предыдущие случаи не забывать.
Да и спросить можно (мэнеджера по поддержке?) чего ожидать.
slm>>И если вам важны сроки — то есть статистика по программисту. (или хотя бы коэфициент ошибки для данного программиста) G>А пробовали реально статистику снимать? Я пробовал. Из-за закона паркинсона программист никогда не делает быстрее срока, даже если срок раздут в несколько раз. (отчего от раздут ниже)
Этот закон паркинсоно — в некотором разе -стёб, а не истина в последней инстанции.
Если нужно написать 2 класса — 100 строк, то как не вертись, придёт программист на второй-третий день работу просить.
slm>>Можно уже планировать и вносить по ходу изменения в план (например, при повышении загрузки на поддержке). G>Хороший план должен оставаться в пределах допустимых значений все время проекта, а не разъезжаться в разы.
G>>>>>Так мы про сроки или про трудоемкость? Определись. slm>>>>Чего не понятного от программиста ждём трудоёмкость. G>>>Как тогда оценить трудоемкость в днях?
slm>>Если не получается оценить в 5-часовых днях, оцените в часах. slm>>Оцените в количестве строк кода. (Если есть статистика по предыдущим задачам) G>Так всетаки в чем оценивать? В днях или строках кода? Это две принципиально разные величины.
Не понял.
При сложившемся процессе программист пишет в среднем Х строк кода в неделю +- 20-30 %
Оценивать программисту проще и точнее в строках.
Если у вас статистика есть, то можете сами перевести.
Но !!!! Перед этим потребуется дизайн сделать что бы размер оценить.
slm>>>>Если он над задачей работал 2 дня из трёх, и кто надо в курсе (тим лид, PM), то все об этом знают. slm>>>>Какие проблемы? G>>>Проблема в том, что оценка 3 дня, а работал 5. И не потому что сам баран, а потому что совещания, багфиксы итп. G>>>Оценка то дается заранее. slm>>Он то в 3 дня оценил, а прожект менеджер в сколько ? G>А ПМ не оценивает. Он может выполнить преобразования и вписать оценку в план. G>Вот я и спрашиваю что какие оценки давать и что с ними потом деалть, чтобы получить реалистичный план и уменьшить эффект паркинсона.
Вообще то как раз ПМ, беря информацию из разных источников и разным образом её преобразуя и получает оценку по проекту.
А эффект Паркинсона уже как то тут совсем мифологизировался.
Нету его на практике если работник не совсем раздолбай.
slm>>Что случается постоянно? slm>>оценивает в 3 дня, а делает за 5? slm>>отлично. slm>>с такой стабильностью уже можно планировать. G>Если бы такая стабильность была всегда, проблем бы не было. G>на практике чаще получается так: G>1) Программист оценивает задачу в 3 дня, а делает за 5 G>2) Появляется похожая по объему задача, он снова оценивает в 3 дня, а делает за 5 G>3) Появляется тертья задача, которая такая же как первая и на 90% может быть скопипащена, она также оценена в 3 дня, но ПМ уже посчитал поправочный коэффициент и поставил 5 дней. А программист за день все скопипастил, и 4 дня смотрел котиков.
Какие ужасы вы рассказываете
Т.е. программист приходит на работу что бы ничего не делать?
Как то всё плохо и с подбором кадров и с мотивацией.
Если человек работать не хочет, надо разбираться почему.
А заставить его программировать из под-палки нормально не получится.
G>Об этом и был пост ТС — если ты начинаешь считать время, то попадаешь на эффект паркинсона.
slm>>>>Проблемы с мотивацией ? slm>>>>Так не демотивируйте его разными таймерами и прочими мелко-шкурными ужимками. slm>>>>Ну и с "реальной" мотивацие что то делать надо. G>>>В том то и прикол, что не с мотивацией. Просто работа проектная так устроена. Как ни крути — не сидит программист по 8 часов над одной задачей. G>>>А даже если сидит, то это соврешенно не означает, что он одинаково эффективно работает в каждый момент.
G>>>Именно нелинейность утилизации времени и нелинейность продуктивности делает бессмысленной оценку в часах\днях\неделях или любых других временных величинах. Человеко-дни тоже ничуть ни лучше.
slm>>Нелинейность возникает при нарушении тех-процесса: отсутствует дизайн/архитектура/требования. G>Это заблуждение. Нелинейность возникает потому что люди это люди, а не роботы.
Вообще то если нет: дизайн/архитектура/требования
(Т.е. нет чёткого понимания что делать программисту)
То уже без разницы люди или роботы.
