Не за час, а за три часа

(это я так сейчас стараюсь оценивать время на задачи)

У меня есть большая производственная проблема, и точка роста - я очень плохо прогнозирую время для проектов и задач. Да-да, я из тех чуваков, кто ушел с задачей на день, а вернулся через неделю. Чаще всего это более менее в рамках дозволенного и адекватного. С опорой на однозадачность, тайм боксинг и отключение нотификейшенов. Но этого мало. И я хочу лучше.

Чтобы совсем победить свою неорганизованность приходится еще как-то глубже анализировать настройки, со всем вниманием к деталям, что-то изобретать, экспериментировать, и чем-то компенсировать. Это работает - ситуация улучшается.

Но я же не один такой. Есть еще люди. Некоторые из нас изобретают классные решения. И вот вам одна из таких попыток. Человек попытался структурировать время на задачу. И показал, почему мы иногда планируем получить результат через час, а получаем через два дня. Он разложил весь тайм баджет на следующие блоки:

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