организация работы, планирование. Что делать с невыполненными задачами

Phoenix

Пишу здесь, потому что ничего более подходящего в голову не пришло.
Хочу как-то организовать планирование работ по проганию.
Что есть сейчас: trac с этапами. Этапы привязаны к срокам. условно возьмём по месяцам.
этап1 (до февраля) сделать AAA, BBB
этап2 (до марта) сделать ССС, DDD
этап3 (до апреля) сделать XXX
В них раскиданы задачи. Что делать если задачи не успели выполниться?
переносить в следующий этап незавершённые? Тогда он разбухнет и уже заведомо через месяц будет то же самое.
не закрывать этап, пока в нём все задачи не закроются? Тогда смысл сроков не очень понимаю.
Исхожу из того, что дальше, чем на полгода планировать смысла нет. В общем-то разработка идёт достаточно маленькими итерациями, но размер этих итераций может оказаться больше ожиданий (2 месяца вместо недели может оказаться, а может и наоборот).
Основная задача - примерно представлять, когда будет CCC,DDD и BBB. и если что-то оказалось сложнее, чем я предполагал - то сроки как-то переносятся чуть дальше.
Посоветуйте, как можно организовать или, может, подскажите какие-нибудь свежие идеи, у кого как сделано.

okis

В общем-то разработка идёт достаточно маленькими итерациями, но размер этих итераций может оказаться больше ожиданий (2 месяца вместо недели может оказаться, а может и наоборот).
Может ты недостаточно точно оцениваешь квалификацию разработчиков или сложность задач, раз так все варьируется?
То есть, обычно, выделяется задача, имеется некоторое соображение (свое сколько она должна занимать, разработчик сам оценивает, сколько ему нужно на задачу, из этих двух показателей получается один, который вписывается в план. Соответственно, можно понять, насколько хорошо разработчик оценивает свои силы (недооценивает/переоценивает/вообще невозможно понять). Или план строится загодя без каких-либо обсуждений?
Что делать — зависит от класса задач, какие-то нужно решить как-нибудь, но в срок, какие-то нужно решить качественно, но потратив чуть больше времени. Процесс сам по себе — лишь форма организации, думать всё равно постоянно надо.

VitMix

Может просто нанять руководителя проекта?

Phoenix

задача может быть что-то вроде такой:
прикрутить к бухгалтерии интерфейс работы с банком.
1. есть время, которое банк будет согласовывать/сертифицировать и т.д.
2. документация может быть корявая. Может понадобиться время на общение с разработчиками с другой стороны, для выяснения поведение интерфейсов.
Поэтому неделя может растянуться на месяц.

Phoenix

Может просто нанять руководителя проекта?

И как это поможет мне с ответом на вопрос?

okis

значит надо закладывать на это время (см последний пост в юморе, там ровно про это). понятно, что если заказчик работает с вами и просит сделать именно это, он может какое-то время подождать, так что это не фатально.

Phoenix

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

Bibi

у тебя есть четыре возможности:
1. начать что-то делать
2. перестать что-то делать
3. делать что-то больше, чем сейчас
4. делать что-то меньше, чем сейчас

naska79

Если на втором этапе надо доделать BBB, то можно перенести DDD на третий этап - оно же явно не срочное (в отличие от ССС).

ppplva

Здравая мысль! Вообще, я считаю, нужно определиться - если эти задачи все еще важны и актуальны, то их надо делать. Если нет - то, напротив, их делать не надо.

Phoenix

т.е. получается
1. в конце месяца(пусть январь) на следующий месяц(февраль) переносятся все невыполненные,
2. сортируются там по приоритетам (возможно у некоторых приоритет поменяется
3. заведомо невыполнимые переносятся на март.
после этого п2 можно выполнить для марта. Ну так примерно и происхдоит. Но как-то очень много редактирований получается.

Boris1980

Полезно еще делать свод по выполненным задачам за месяц.
Т.е. а что было сделано? Многое расставит по местам.

desdichado88

Перед задачей ААА вставлять в план задачу pre-ААА, которая будет называться "оценить время на выполнение ААА". Смысл: изучается задание (описание) и документация на предмет кривизны, если затык может быть в этом. Оценивается, что для ААА нужно со стороны (доработка чужих модулей, согласование деталей и т.п.).
Иначе говоря, изучаются все возможные подводные камни. После этого срок выполнения ААА становится прозрачным и обоснованным.
А если задача не готова к выполнению (не хватает документации, что-то не согласовано задачу нельзя ставить в план (по крайней мере, со сроками выполнения). Потому что тогда очень часто план будет срываться, причем всегда можно будет придумать отговорку - и обоснованную от надуманной не всегда отличишь.
Оставить комментарий
Имя или ник:
Комментарий: