С оценкой времени выполнения задачи в программировании все сложно. Менеджерам очень важно знать точный срок, за который работа будет выполнена. Программисты этот срок оценить не могут. Обычно это выливается в бесконечные конфликты. Менеджеры считают программистов ленивыми уродами, программисты считают, что менеджеры не понимают их тонкую программерскую душу. Все счастливы.
Но мы не такие! Мы решаем проблемы, а не ищем виноватых. Мы ищем способ, а не причину. Мы не жалуемся на Злую Судьбу, Законы Вселенной и не вздыхаем обреченно "оно всегда так".
Эта статья ориентирована прежде всего на программистов. Со стороны менеджеров тоже требуются определенные усилия - например, если менять постановку задачи каждый день, то оценить время станет сильно сложнее. Но на этом я останавливаться не буду.
Итак, как обычно происходит оценка сроков? Вот очень распространенный сценарий. Программиста спрашивают "сколько времени этой займет?" Ответ ожидается прямо сейчас, у программиста есть несколько секунд на раздумья. У него в голове возникает некий срок. Пускай будет "три недели". При этом программист отбрасывает время, нужное для отладки, учитывается только время кодирования. Потом внутренний голос говорит ему "Ты же крут! Какие три недели! За две справишься!". "Две недели" - отвечает программист. После этого начинается торг. Менеджер пытается уменьшить уже сильно заниженный срок. В итоге они сторгуются на неделе. Это просто какой-то срок, взятый с потолка, который выполнен не будет.
Через некоторое время становится очевидным, что данные оценки по срокам не выполнялись никогда. Программист приходит к выводу, что оценить время выполнения работы невозможно. Мысль "я не умею, значит это невозможно" гораздо приятнее мысли "я не так крут, как мне казалось, эта задача занимает гораздо больше времени".
Увы, я не знаю волшебных заклинаний и HOWTO как всегда со стопроцентным попаданием рассчитывать сроки. Но есть несколько известных мне приемов, которые ситуацию с оценкой сроков улучшают значительно. Я их все использовала, опробовала на себе. Все они требуют активного сотрудничества между менеджером и программистами. Если такого сотрудничества нет, попробуйте делать временные оценки для себя. Это полезный навык, может потом пригодиться.
Оценка времени программирования задач в часах
Этот способ рекламировал Джоэл Спольски у себя в блоге. Там вы найдете его подробную статью об этом: Evidence Based Scheduling. Разбиваем задачу на подзадачи, оцениваем время каждого этапа в часах.
Если вы привыкли брать сроки с потолка, то оценки по этому методу будут получаться пугающе большими. Это нормально.
Временные отсечения
У нас есть задача, требующая определенных исследований. Наши программисты ни разу такое не делали. И вообще не представляют как это делать. Мы начинаем исследование и бросаем его в определенный срок. Например, 20 мая. Если до этого времени не успели - все. Даже если "почти все готово", даже если "вот сейчас заработает". Откатываемся к предыдущей версии. Беремся за следующую задачу.
Разработка по спирали
Наверное, у этого способа есть какое-то умное название. Задача как можно быстрее получить работающую версию продукта. В случае игры - играбельная версия, один уровень, почти без графики, без спецэффектов, без меню или с убогим меню. А потом уже на нее навешиваем фичи. Добавляем спецэффекты. Делаем оптимизацию. Разработка получается гибкой. Мы на ранних этапах можем отказаться от каких-то фичей, от спецэффектов.
Предоставить другую информацию
Если программист не знает когда задача будет выполнена, то зачастую он может назвать срок, в который она точно выполнена не будет. Этого может оказаться достаточно менеджеру, чтобы принять какое-то решение. Например, перенести собрание или вовсе отказаться от выполнения этой задачи. Можно побеседовать и выяснить, что программист может предложить некое решение, которое можно сделать очень быстро, но оно будет обладать существенными недостатками. Например, не будет работать в некоторых случаях или будет работать очень медленно. Его можно будет использовать в качестве заглушки. Зачастую бывает лучше продемонстрировать медленно работающую программу, чем вообще ничего не продемонстрировать.
Постмортемы
После окончания проекта полезно сверить реальные оценки с теми, что были напланированы и попытаться уяснить где были допущены ошибки и почему. Что нужно сделать, чтобы их не повторить. Очень важно тут не скатиться к поиску виноватых.
Это нужная вещь, потому что научиться делать хорошие оценки с первого раза вряд ли получится. Это итеративный процесс. Постепенно будет получаться все лучше и лучше.
Пример из жизни
В одном очень критичном по времени проекте я оценивала время в часах, по Спольски. И там действительно счет шел на часы. Проект вышел вовремя, при этом сразу же были порезаны минорные фичи, когда по оценкам стало ясно, что они занимают неприлично много времени.
Для того, чтобы лучше понимать нужды менеджера полезно бывает что-нибудь отменеджить. Если вам предоставится такая возможность, то вы увидите, что важен не столько срок, сколько общий контроль над процессом. Пускай что-то пойдет медленнее, чем ожидалось, главное, что мы можем этим управлять, знаем причины, знаем как на это влиять. Главная цель - удержать контроль над ситуацией.
Atom feed
33 коммент.:
«Разработку по-спирали», в Web-разработке, еще кажется называют «методом прогрессивного JPEG'а».
Вот , кстати, и Яндекс, со-своим семинаром про «Гибкими методиками разработки» 19-го и хабр туда же. Наверно это сезонное ;)
Как программер, потом менеджер, потом фрилансер могу сказать что сроки нужно называть разумно-максимальные. Ну то есть если недели 2 вроде нормально, но может быть и 3, то правильный ответ 2.5-3 недели.
Что бы быть близко к правде, принято делать 2 вещи
- разбивать задачу на мелкие и оценивать элементарные задачи в часах или днях. На птичьем это называется WBS
- там где могут быть проблемы - надо закладываться на troubleshooting. На птичьем это risk assessment
Обязательно надо учитывать тестирование, ревью кода, возможные мерджи и все-все что в команде бывает. И какой-то буфер на всякий пожарный. Ваш менеджер не знает что, допустим в Ноябре половина вашей родни родилась, а другая переженилась. Про праздники он должен вроде бы знать, но может и забыть.
Сроки надо оценивать не по тому как бы я это сделал. А по предыдущему опыту - поглядеть в историю коммитов или issue tracker. Человеку свойственно преукрашивать прошлое и будущее.
Никогда не соглашайтесь что-то сделать быстрее, потому что менеджеру надо быстрее. Укорачивание сроков проекта и уламывание программиста согласиться на меньший срок - это абсолютно разные действия. И если происходит последнее то
- спросите что из функционала можно выкинуть
- можно ли считать альфа версию со всеми багами готовой к поставке
- готов ли менеждер оплачивать переработки в случае проблем в 2-ом ( 3,5 - насколько наглости хватит) размере
В крайнем случае работает старое правило "пи". Представляем как бы мы это сделали, в уме что-нить считаем, умножаем на pi и называем менеджеру.
PS. по спирали называют по разному - итерационной, early deploy. Так работает agile. Почти так работают спринтами в scrum.
Wot
В крайнем случае работает старое правило "пи". Представляем как бы мы это сделали, в уме что-нить считаем, умножаем на pi и называем менеджеру.
Очень не люблю я это правило и считаю его нерабочим. Знаю людей, для которых это пи стремится к бесконечности.
У меня вообще долгое время была другая проблема - у меня после быстрых подсчетов получалось времени больше чем надо, а не меньше. Если бы я его еще и на три домножала...
Звучит как перефразированные принципы Agile Development с их спринтами, backlog grooming, sprint planning, sprint retrospective, ну и так далее.
может я чего не понял но вроде как получается что каждый программист непосредственно общается с одним или несколькими менеджерами. то есть как бы получается если и есть начальник у программистов, то он этим не занимается? Как бы более логично было бы чтоб этим занимался начальник программистов, ну или хотя бы старший программист.
на счет числа ПИ все зависит от ситуации, некоторые менеджеры так подставить могут что не вольно начнешь завышать.
для себя ориентировочно срок увеличиваю 1.5 на подводные камни.
Для подчиненных ставил сроки индивидуально с коэффициентом 1.0-0.8, а для начальства 1.5 и не плохо работало.
Опытные менеджеры/тим-лидеры знают, что программист излишне оптимистичен, поэтому его срок сначала умножается на 2, а потом еще добавляется константа :-)
Каждый раз удивляюсь, когда не обнаруживаю Planning Poker в списке методов оценки сроков.
Алёна, попробуйте обязательно! По моему опыту, этот способ даёт на удивление точные оценки.
Анонимный
может я чего не понял но вроде как получается что каждый программист непосредственно общается с одним или несколькими менеджерами.
Я рассматривала для примера ситуацию программист-менеджер. Вместо менеджера может быть ведущий программист, геймдизайнер, неважно.
Как бы более логично было бы чтоб этим занимался начальник программистов, ну или хотя бы старший программист.
Вот это как раз очень неправильно и про это пишет Спольски. Программисту самому сложно оценить сроки выполнения задачи, хотя он в нее полностью погружен. Браться оценивать срок за него - странная затея.
некоторые менеджеры так подставить могут что не вольно начнешь завышать.
Могут. Тут можно попробовать найти общий язык с менеджером, попробовать сменить менеджера, ставить одни сроки для себя - другие для него.
Alex Ott
Опытные менеджеры/тим-лидеры знают, что программист излишне оптимистичен, поэтому его срок сначала умножается на 2, а потом еще добавляется константа :-)
Программеры это довольно быстро просекают. Слегка проседает мораль. А, самое главное, у человека теперь нет стимула учиться давать точные оценки.
Ну и про то, что все люди ошибаются по-разному и не всегда в меньшую сторону, я уже говорила. Я как-то работала с программистом, который очень точно оценивал сроки для небольших задач, хотя никогда этому не учился.
ну это также зависит от менеджера - он должен видеть, когда человек черезчур оптимистичен или нет
Alex Ott
ну это также зависит от менеджера - он должен видеть, когда человек черезчур оптимистичен или нет
В таком случае имеет смысл побеседовать с человеком и рассказать ему как делаются временные оценки.
Не, я понимаю, что бывают совсем уж безнадежные случаи, но хотя бы попытаться стоит.
мне кажется, в статье несколько путают оценку задач с методологией разработки и оценкой проекта.
да, разработчик должен сам оценивать задачи, которые он будет выполнять.
однако, разработчик зачастую не включает в оценку кроме названных code review,debugging, defect fixing такие вещи, как коммуникация, выяснение требований, техническая сложность решения, внешние и внутренние зависимости. набрасывать процент на оценку программиста в таких случаях крайне необходимо. и сделать это проще менеджеру, у которого есть статистика по выполненным ранее задачам.
есть еще один нюанс: при оценке проекта, над которым работает 5-10-... человек, не всегда есть возможность привлечь всех для оценки. зачастую в таком случае в оценке участвуют один-два программиста, а менеджер "делает поправку" т.к. представляет, кто будет выполнять задачи и какова средняя "производительность" разработчиков.
я являюсь искренним приверженцем planning poker (который отлично работает при итерационной разработке), хотя тут есть и свои ограничения в виде несогласованности несработавшейся команды, например, или нежелания заказчика получать оценку на кусочки, а не на весь проект в целом.
книга Фредерика Брукса
http://ru.wikipedia.org/wiki/Мифический_человеко-месяц
Анонимный
мне кажется, в статье несколько путают оценку задач с методологией разработки и оценкой проекта.
Эммм... Разве? Я говорила именно об оценке времени выполнения конкретной задачи программистом.
Про проект целиком речь не идет. Проект - это несколько больше чем программирование.
есть еще один нюанс: при оценке проекта, над которым работает 5-10-... человек, не всегда есть возможность привлечь всех для оценки. зачастую в таком случае в оценке участвуют один-два программиста, а менеджер "делает поправку" т.к. представляет, кто будет выполнять задачи и какова средняя "производительность" разработчиков.
В таком проекте будет иерархия. Один-два ведущих могут собрать оценки с остальных и свести их вместе. Я уже говорила выше, что считаю, что придумывание оценок за других программистов - это плохая идея. Производительность сильно зависит от задачи.
Но в любом случае. Если такая система используется и работает - то это прекрасно.
Если она используется, но ее результатом является вывод, что программисты плохие, мало стараются и виноваты, то имеет смысл попробовать что-то еще.
Анонимный
http://ru.wikipedia.org/wiki/Мифический_человеко-месяц
AFAIR, Брукс тут опять же говорит про оценки в проекте целиком, то есть о том, что происходит на уровне выше.
Вот это как раз очень неправильно и про это пишет Спольски. Программисту самому сложно оценить сроки выполнения задачи, хотя он в нее полностью погружен. Браться оценивать срок за него - странная затея.
я не говорил что программисту не надо, обязательно надо, я говорил что с менеджером(руководителем) должен общаться например руководитель программистов у которого опыта побольше в оценке времени и со стороны виднее сколько каждому необходимо надбавить или убавить времени.
Алёна, мне кажется, что причины, по которым программист ошибается в сроках вы сильно упростили и, я бы сказал, выставили программистов в плохом свете. Если интересно, то я когда-то пытался проанализировать, почему же это происходит даже при искренем желании программиста назвать нормальные сроки.
И я думаю, что программерский оптимизм неистребим. Посему менеджерам ничего не остаётся, как продолжать использовать коэффиценты. А еще лучше -- использовать практику пересмотра сроков. Поскольку порочная практика спросить срок один раз в самом начале, а потом строго ему следовать, похоже, неискоренима.
Формула проста - время, которое первое всплывает в голове умножить на три, там и на отладку хватит и на все остальное, если не нравится - идите лесом или урезайте ТЗ до базовой версии...
Евгений Охотников
Алёна, мне кажется, что причины, по которым программист ошибается в сроках вы сильно упростили и, я бы сказал, выставили программистов в плохом свете. Если интересно, то я когда-то пытался проанализировать, почему же это происходит даже при искренем желании программиста назвать нормальные сроки.
О, интересно, как-то я пропустила эту статью.
Свою позицию я уже озвучила. Это статья про то, почему "невозможно". Возможно, я видела как люди с этим работают. Сложно, да. Достигается тренировками. Но не невозможно.
Мое дело тут - предложить. Я не настаиваю. :-)
И я думаю, что программерский оптимизм неистребим.
Очень разные все. Есть пессимисты.
Основная моя идея, что сроки можно научиться оценивать лучше, если оценивать их не эмоционально, а сесть и расписать сколько куда чего уйдет.
Это как прикидывать вероятность. Ну не умеет человек ее угадывать. Зато можно сесть и подсчитать.
Поскольку порочная практика спросить срок один раз в самом начале, а потом строго ему следовать, похоже, неискоренима.
Зависит от менеджера. Работала с пересмотром сроков. Работала с ситуациями, когда сроки пересмотреть было нельзя, резали фичи. Ну с упертыми товарищами тоже работала... Все разные.
Веталь
если не нравится - идите лесом
вот это грамотный профессиональный подход :-)
Возможно, я видела как люди с этим работают. Сложно, да. Достигается тренировками. Но не невозможно.
Соглашусь. Оценка времени - это отдельный навык, так же тренируется, как и любой другой. Чаще оценивать задачи и перестанет бросать в дрожь, когда подходит менеджер :)
P.S. У меня есть ощущение, что к статье "парой" подойдет пост http://gaperton.livejournal.com/50685.html
@Alena:
>Это статья про то, почему "невозможно".
Да. Я просто хотел подчеркнуть, что причина "Ты же крут! Какие три недели! За две справишься!" далеко не самая определяющая и, с возрастом, она играет все меньшую и меньшую роль.
>Сложно, да. Достигается тренировками. Но не невозможно.
Есть у меня подозрение, что это достигается лишь при определенных стечениях обстоятельств. И хороший менеджер далеко не последнее обстоятельство :)
Я хотел спросить: когда вы говорите о положительном опыте предсказания сроков, то о каких объемах задач и сроках идет речь? Скажем, это задачи на неделю работы, на месяц, три месяца, полгода или больше?
Евгений Охотников
И хороший менеджер далеко не последнее обстоятельство :)
Безусловно. Я об этом вначале написала.
Я хотел спросить: когда вы говорите о положительном опыте предсказания сроков, то о каких объемах задач и сроках идет речь?
В описанном посте случае было то ли две, то ли три недели.
Скажем, это задачи на неделю работы, на месяц, три месяца, полгода или больше?
В основном делала оценки на недели. Самое большое, что я сейчас вспомню - 3 месяца.
Многомесячные работы надо разбивать на этапы. Хотя бы для того, чтобы тестирование провести.
@Alena:
>Многомесячные работы надо разбивать на этапы. Хотя бы для того, чтобы тестирование провести.
В заказном ПО распространены случаи, когда от разработчика требуют указать срок выполнения многомесячного проекта сразу. Мол, что мы можем обещать вот этому заказчику, а хочет он вот это, это и это? А потом бах, и фиксируют оценку разработчика как срок выполнения и запуска проекта.
Не говоря уже про случаи, когда сроки выполнения (где счет идет в диапазонах 6-12 месяцев) определяется не техническими, а политическими соображениями.
Ну и совсем уж тяжелые случаи -- когда ПО должно быть готово к определенной совсем далекими от разработки людьми дате (смене законодательства, запуска нового аэропорта и т.д.) Взять хотя бы печально известную систему ЕГАИС.
Евгений Охотников
В заказном ПО распространены случаи, когда от разработчика требуют указать срок выполнения многомесячного проекта сразу.
Я написала пост о том, как одному программисту оценить срок выполнения выданной ему задачи.
Как оценивать срок проекта целиком, куда входит далеко не только программирование - это отдельная большая история.
@Alena:
>Я написала пост о том, как одному программисту оценить срок выполнения выданной ему задачи.
Прошу прощения, это уже "Остапа понесло". Флеймить прекращаю.
Тут уже писали про правило ПИ, я про него не слышал. Со временем у меня этот коэффициент получился равным 2,3. При условии что было дано время оценить задачу и прикинуть что к чему.
Я кстати склоняюсь к версии того что проблема возникает из-за того что неделя считается, например, 40 часовой, хотя реально никто не работает(трудится над конкретной задачей) по 8 часов в день (в среднем). Все же и блоги читают и тематику и башорг в конце-концов.
Спасибо за статью.
Небольшой комментарий из собственной практики.
В работе используем оценку только в часах, если нужно, то потом полученный результат переводиться в недели, месяцы, года. Для оценки задачи разбиваются на более мелкие и спускаются вниз по иерархии.
Менеджер идет к лиду и рассказывает требования. Потом лид разбивает на более мелкие задачи и раздает людям, которые предположительно будут выполнять данную работу. Каждый оценивает свой фронт работ и лид сводит это в одну таблицу. Чтобы случайно чего-то не забыть, лид работает с каждым программером отдельно, а не просто копирует цифры.
Помимо вопроса, сколько времени займет фича от программиста требуется рассказать, что конкретно он сделает за этот срок. Т.е. будет ли это финальная версия фичи или нужна будет дополнительная отладка, будет ли фича работать на всех платформах или только на одной и т.д. Это позволяет определить насколько программист правильно понял задачу и не забыл ли он что-то при оценке.
При таком подходе очень много ответственности ложится на лида. Но постепенно команда учится правильно оценивать свои возможности и не теряется боевой дух, поскольку люди видят, что их мнение не игнорируется.
greesha-ru пишет...
Каждый раз удивляюсь, когда не обнаруживаю Planning Poker в списке методов оценки сроков.
Использовали в работе, но подходит только если команда достаточно ровная, т.е. все равно круты. Также есть негативный опыт при работе с командой в 9 человек - составление спринта занимает очень много времени.
Интересно было бы узнать о вашем опыте использовании Planning Poker.
Alex Ott пишет...
Опытные менеджеры/тим-лидеры знают, что программист излишне оптимистичен, поэтому его срок сначала умножается на 2, а потом еще добавляется константа :-)
В таком случае решение принимаеся по каждому конкретному человеку отдельно, и при этом с ним ведется работа по улучшению его абилок в оценке.
Wot пишет...
- там где могут быть проблемы - надо закладываться на troubleshooting. На птичьем это risk assessment
При составлении плана мы обычно закладываем риск буфер, размер которого зависит от нашего понимания задачи. Также при этом составляет список наших предположений, т.е. мы сразу говорим, что в данный срок будет поставлена версия только с базовым функционалом, или же фича будет работать только на такой-то платформе. Константы и коэфициенты стараемся не использовать. Если это не устраивает менеджера или заказчика, то начинается торг. К сожалению на данном этапе от программеров не все зависит, но очень помогает если налажен хорошший контакт со своим проджект менеджером и вы выступаете одним фронтом.
ForestMan
Спасибо за статью.
Пожалуйста :-)
В работе используем оценку только в часах, если нужно, то потом полученный результат переводиться в недели, месяцы, года.
Сколько у вас часов в дне, если не секрет?
Тут выше было предположение о восьмичасовом дне. Я считала 4-6, в зависимости от задачи.
Alena пишет...
Сколько у вас часов в дне, если не секрет?
Тут выше было предположение о восьмичасовом дне. Я считала 4-6, в зависимости от задачи.
Мы считаем что один день это 8 часов. Так проще оперировать данными. При этом в эстимацию закладывается время на раскрутку для программера, время на то, чтобы включится в работу. Лично я считаю, что активно программист работает только 5 часов.
Не совсем в тему, но в принципе - о том же:
http://www.computerra.ru/compunity/russ/32031/
@ForestMan
Использовали в работе, но подходит только если команда достаточно ровная, т.е. все равно круты. Также есть негативный опыт при работе с командой в 9 человек - составление спринта занимает очень много времени.
Интересно было бы узнать о вашем опыте использовании Planning Poker.
Пробовали на неподготовленной команде из пяти человек. Один, правда, самоустранился (отказывался давать комментарии), но он и правда по делу ничего не мог сказать.
Среди оставшихся выявились, как на подбор: пессимист, оптимист и реалист. В их спорах и рождалась истина в виде оценок, которые потом с высокой точностью подтвердились.
Времени это занимало на первый взгляд немало, это правда. Но мы планировали проект вперёд сразу на несколько этапов (каждый по одному-два месяца). И потом оказалось, что день, потраченный на покер, на фоне выполненной работы - это совсем ничего.
greesha-ru пишет...
Пробовали на неподготовленной команде из пяти человек...
Спасибо за ответ. Планирования на несколько отрезков вперед неплохое решение, попробуем подумать как реализовать у нас.
По поводу точности согласен, данный способ эстимации позволяет получить достаточно точную оценку.
У нас основная проблема была с затратами на планирования. Команда в 10 человек работала 2-х недельными спринтами. Соответственно покерная игра была каждые две недели и занимала практически весь день, иногда полтора дня. Достаточно большой оверхед для команды :(.
Вторая проблема была в неровности команды. Только 2-3 человека обладали достаточными знаниями в данной области, поэтому остальным приходилось долго обьяснять как, что и где будет работать.
В результате мы отказались от покерной игры в чистом виды и выработали свой подход. Начиналось с того, что каждый получал примерный фронт работ и шел на свое рабочее место, дабы подумать как это реализовать. Потом огранизовывались небольшие митинги с каждым программером. Участники: лид, программер и еще 1-3 человека, которые реально могли помочь с решением задачи. Такой группой управлять проще, соответственно игра происходила быстрее и эффективнее. В конце, когда все проэстимировали свои задачи был общий митинг, на котором просто проходились по спринту, чтобы каждый мог знать чем занимаются коллеги и, если что, внести поправки.
При таком подходе мы составляли спринт за 4-6 часов и при этом не вся команда отрывалась от работы.
Все, больше сказать нечего :). Прошу извинить, если сильно ушел от основной темы.
Сегодня делали по учебе расчеты, на основе объема кода, для оценки времени разработки системы, которая состоит из кода на JAVA, немного C++ и HTML. Потом перевели это все через коэффициенты (JAVA = 6, C++ = 3.5, HTML = 30) в строки ассемблерного кода, поделили на производительность и получили и получили примерный срок 6-10 лет на 4-ых. Все перепроверили несколько раз. Как придумывают такие методологии?
Алёна, насколько это уместно здесь, вам решать. :-)
Взгляд с другой стороны баррикад: http://dtf.ru/articles/read.php?id=4085
Мне очень нравится подход известный под названием Earned Value Analysis http://en.wikipedia.org/wiki/Earned_value_management . Он предназначен не сколько для начального планирования, сколько для поддержания плана проекта в актальном состоянии. Пользовался этим подходом и в качестве разработчика и в качестве руководителя команды. Смысл подхода довольно прост - регулярные корректировки оценки времени оставшейся до выполнения задачи. MS Project неплохо поддерживает эту тухнологию через Basilines и Actual Work values.
Полностью согласен с мнением что для хорошего менеджера важны не сколько точные комитменты, сколько понимание состояния проекта и опасных и потенциально опасных мест (ну да risks management).
А оценку сроков по задачам всегда делаю по Сколнски - разбиваю на мелкие задачи максимум на день и оцениваю их. Плюс буфер на задачи не попавшие в оценку. А потом откладываю оценку и смотрю на задачу с точки зрения практического смысла - сколько по макисмуму имеет смысл на нее потратить времени. Если потом сравнить оценки - получается интересный результат :-).
Отправить комментарий