Процент завершенности для задач (не проектов)

[Algen]

У меня есть проекты, задачи в которых имеют довольно большой объем и не делятся на подзадачи. Например, "Перевести статью" - это проект. У него есть подзадачи:

- Черновой перевод (занимает 80% времени)
- Редактура перевода (занимает 10% времени)
- Вычитка перевода (занимает 8% времени)
- Написание пояснительной записки заказчику (2% времени)

Как видим, основная задача - это "Черновой перевод", Он может занимать 2-3 дня. И все это время завершенность проекта в целом будет 0% и только на третий день она скакнет сразу на 80%.

Было бы правильно дать возможность задавать вручную процент завершенности отдельных задач. Данная информация для задач нижнего уровня должна вводиться вручную "на глаз" и служить только для оценки степени завершенности проекта.

Другой случай: задача сильно разорванная во времени. Пример. Проект: "Купить зеркальный фотоаппарат". Первая задача: "Выбрать модель". Покупка дорогая, и чтобы как следует разобраться в текущем состоянии рынка, нужно потратить минимум целый рабочий день. Но просидеть целый день подряд нет никакой возможности. Занимаешься этим урывками, в один день полчаса, в другой - час. Задача может растянуться на неделю-две. И хотелось бы отмечать, как идет прогресс, то есть, как постепенно созревает чувство уверенности в выборе, которое как раз и отражает степень завершенности данной задачи. Я могу сказать: "на данный момент я определился с выбором на 70%", что означает: я проанализировал ~70% необходимой информации, и мне нужна еще примерно половина от уже затраченного времени, чтобы принять окнчательное решение.

Во избежание возражений сразу оговорюсь, что здесь нельзя играть ни усилием, ни параметрами Мин/Макс. Длительность и усилие у задачи остаются неизменными. Просто надо иметь возможность отметить, что часть работы уже выполнена, и чтобы это учитывалось в объемлющем проекте.

Пока можно пользоваться эрзац-методикой: создать у большой подзадачи 10 условных подзадач с названиями: 10%, 20%, ..., 90%, 100%. Ну, и помечать их галочками в по мере необходимости. Но это зря перегружает схему и все равно недостаточно гибко. Скажем при переводе я знаю объем выполненной работы с точностью до процента (делением числа переведенных знаков на общее число). Так что хотелось бы руками цифру вбивать.

[edw]

У меня есть проекты, задачи в которых имеют довольно большой объем и не делятся на подзадачи.

Всё зависит от того, что вы называете подзадачей. В GTD рекомендуется задачей считать то, что можно сделать сразу, за один "подход" без перерыва. Т.е. дело, которое займёт не более 1,5 часов. Таким образом есть только две сущности - проект и задача.

Другой случай: задача сильно разорванная во времени.

Разорванные задачи - это уже разные задачи. Благодаря многоуровневой вложенности в MLO вы можете детально расписать весь комплекс работ. Так первая задача "Выбрать модель" будет состоять из таких подзадач как сделать обзор рынка, подготовить список требований, отобрать 3-5 моделей, сравнить модели на основе критериев. И, обратите внимание, - это совсем не однотипные задачи. Их лучше расписать и выполнять в определённой последовательности. Кроме того, все эти задачи хорошо впишутся в ваш календарь и не потеряются среди прочих дел.

Пока можно пользоваться эрзац-методикой: создать у большой подзадачи 10 условных подзадач с названиями: 10%, 20%, ..., 90%, 100%. Ну, и помечать их галочками в по мере необходимости. Но это зря перегружает схему и все равно недостаточно гибко.

Подзадачи "зря перегружают схему" только до тех пор, пока "всё идёт по плану". Но стоит жизни внести свои коррективы, как вы столкнётесь с выбором - "выполнить 10% перевода" или "отобрать 3-5 моделей". Именно для определения приоритетов дел, когда что-то пошло не по плану, и нужен MLO.
Что до "недостаточной гибкости"... Мы с вами говорим об организации времени. Пунктуальность - хорошая черта. Но действительно ли надо учитывать каждые 15 мин своего времени или 1% перевода статьи?