Не за час, а за три часа(это я так сейчас стараюсь оценивать время на задачи)
У меня есть большая производственная проблема, и точка роста - я очень плохо прогнозирую время для проектов и задач. Да-да, я из тех чуваков, кто ушел с задачей на день, а вернулся через неделю. Чаще всего это более менее в рамках дозволенного и адекватного. С опорой на однозадачность, тайм боксинг и отключение нотификейшенов. Но этого мало. И я хочу лучше.
Чтобы совсем победить свою неорганизованность приходится еще как-то глубже анализировать настройки, со всем вниманием к деталям, что-то изобретать, экспериментировать, и чем-то компенсировать. Это работает - ситуация улучшается.
Но я же не один такой. Есть еще люди. Некоторые из нас изобретают классные решения. И вот вам
одна из таких попыток. Человек попытался структурировать время на задачу. И показал, почему мы иногда планируем получить результат через час, а получаем через два дня. Он разложил весь тайм баджет на следующие блоки:
The work around the work (1%)
Meetings, reviews, project management, etc
The work to get the work (3%)
Research, experimentation, scoping, quoting, pitching
The work before the work (15%)
Configuration, setup, services, infrastructure
The work (35%)
The actual build, product, design, docs, tests, etc
The work beyond the work (22%)
Changes, omissions, nice-to-haves, scope creep
The work outside the work (12%)
Surprises, contingency, disasters, mission creep
The work after the work (12%)
Hosting, deployment, security, support, updates, fixes
Там еще во всех этих процессах прячется
the work between the work (Iteration, debugging, refactoring, maintenance, tooling).
В итоге, мы учитываем только
the work, и не учитываем (как всегда) все неявные и имплицитные компоненты. То есть не берем в расчет 65% реальной работы.
Идея в том, чтобы визуализировать эти компоненты и научиться на входе правильно тйам-мэппить проект.
→
https://davestewart.co.uk/blog/the-work-is-never-just-the-work