Комментарии 58
Ух и спорные статусы...
Я использую такие:
1) New (Новая и никому не назначенная)
2) Assigned (Назначенная, в работе)
3) Discussion (Обсуждается, возникли вопросы)
4) Completed (Завершена, всё сделано)
5) Closed (Закрыта, все проверили, протестировали и утвердили)
Я использую такие:
1) New (Новая и никому не назначенная)
2) Assigned (Назначенная, в работе)
3) Discussion (Обсуждается, возникли вопросы)
4) Completed (Завершена, всё сделано)
5) Closed (Закрыта, все проверили, протестировали и утвердили)
Ага, и разработчики, вместо того чтобы хоть как-то оценить объем выполненных работ, будут просто писать "Выполняется"... А как тогда контролировать процесс выполения работ? Имхо такое годится только в случае мелких задач, на несколько часов, на день...
Можно крупные задачи дробить на более мелкие, где такой подход к оценке готовности эффективен.
Если разбить всеь процесс на достаточно мелкие задачи, то хватит и двух одного статуса - выполнено. Тогда всю решаемую проблему можно представить в виде графа и потихоньку по мере продвижения закрашивать его. Бред?
Кхм. От чего же? Правда, я боюсь, подобный подход не везде применим.
В принципе мы о чём говорим? О том, что стоит уйти от цифровых статусов, к более "человечным" словесным. Лично мне практически всегда непонятно, каким образом можно определить, что вот в данный момент задача решена на 43%, а через час на %55. В этом мне видится некое лукавство оценщика. В случае же словесных статусов, он (оценщик) будет, имхо, более честен.
В принципе мы о чём говорим? О том, что стоит уйти от цифровых статусов, к более "человечным" словесным. Лично мне практически всегда непонятно, каким образом можно определить, что вот в данный момент задача решена на 43%, а через час на %55. В этом мне видится некое лукавство оценщика. В случае же словесных статусов, он (оценщик) будет, имхо, более честен.
Хорошо бы, да только человеческие статусы сравнительно малоинформативны. Что такое "Почти готова"? Если толкования программиста и менеджера не совпадут, получится конфликт.
Возьмем однако такой пример: ставится программисту задача. Он говорит "ОК, я сделаю это с десяти шагов, вот таких и таких". После чего им вывешивается некий списочек в каком-нибудь tadalist и по мере завершения работы ставится галочка. И в итоге опять приходим к процентам выполнения.
В чем мысль? Проценты обесчеловечены, потому что не видно их содержания. А если содержание будет опубликовано, то и прогресс будет виден, и программист уже не отделается вывешиванием статуса "работаю".
Возьмем однако такой пример: ставится программисту задача. Он говорит "ОК, я сделаю это с десяти шагов, вот таких и таких". После чего им вывешивается некий списочек в каком-нибудь tadalist и по мере завершения работы ставится галочка. И в итоге опять приходим к процентам выполнения.
В чем мысль? Проценты обесчеловечены, потому что не видно их содержания. А если содержание будет опубликовано, то и прогресс будет виден, и программист уже не отделается вывешиванием статуса "работаю".
Цифры работают лучше для больших проектов с большим числом вложенных задач, когда проведе адекватная предпроектная поджкотовка.
Если же мы пытаемся описать цифрами свой творческий проект, когда не знаем, что хотим получить на выходе, и работаем когда придёт вдохновение - тогда цифры конечно бесполезны.
Если же мы пытаемся описать цифрами свой творческий проект, когда не знаем, что хотим получить на выходе, и работаем когда придёт вдохновение - тогда цифры конечно бесполезны.
Декомпозиция задач IMHO вообще единственный способ хоть как-то сделать процесс разработки подконтрольным. В идеале дробление должно доходить до уровня микрозадач продолжительностью не более 4 часов.
В каждой шутке есть доля шутки :) Мысль была в том, что программер в любом случае нереалистично оценивает прогресс - так пусть лучше менеджер не обманывает себя ростом цифирек, а тщательнее контролирует ФАКТИЧЕСКИЙ статус задачи.
3. Тестируется
4. Почти готова
Это же одно и тоже.
4. Почти готова
Это же одно и тоже.
1. Не начата
Как минимум делится на Черновик, На согласовании, На утверждении, В плане
2. Выполняется
Выполняется первый раз? Или находится на доработке?
3. Тестируется
Модульное тестирование? Или в составе системы? И так далее, и тому подобное.
4. Почти готова
Расшифруйте? Всем известно, что последние 10% работы занимают 90% времени (или, если хотите, ресурсов).
5. Завершена
Выполнена? Отменена? Заморожена ввиду текущей невозможности выполнить? Перемещена в архив?..
Так-то.
На самом деле, все это частные случаи, а обобщенный граф движения активности между стадиями (с участием нескольких фигурантов) существенно проще (просто таких переходов в графе много, но по сути они все однотипны). И все предлагаемые автором топика названия - частные случаи, к которым он пришел, используя частный вариант бизнес-процесса.
P.S. Чем Вам RUP или XP не угодил?..
Одной из главных задач открытия этой откровенно провокационной ветки и было - увидеть, кто какие статусы использует и узнать, насколько хороший эффект они дают. Так что критика - это первое, чего я и ожидал. Буду только рад, если появятся альтернативные "качественные" (не процентные) версии - это будет наилучшим результатом.
Для небольших задач раздумывание над тем, а не пора ли обновить статус задачи и какой теперь поставить, заставляет отвлекаться от собственно решения задачи, и потому просто отметается мозгом - качественная оценка перестает существовать до момента завершения.
Для больших задач деление их на маленькие неизбежно, а тут мы снова имеем дело с количеством, а количество оценивать качественно, значит терять информацию, которую мы уже бесплатно имеем.
По любому оценка выполнения должна быть количественной. Проценты это будут или нет - уже дело вкуса.
Для больших задач деление их на маленькие неизбежно, а тут мы снова имеем дело с количеством, а количество оценивать качественно, значит терять информацию, которую мы уже бесплатно имеем.
По любому оценка выполнения должна быть количественной. Проценты это будут или нет - уже дело вкуса.
Разумных статусов 5
1. В работе (поставлена, результата пока нет)
2. Отменена (результат более не нужен, работы остановлены)
3. Отложена (результат нужен не срочно, есть более приоритетные задачи, работы перенесены на более поздний срок)
4. Сделана (исполнитель заявил, что результат достигнут)
5. Закрыта (заказчик подтвердил, что результат его удовлетворяет)
В принципе, можно обойтись без статуса 2, используя в таких случаях пятый.
1. В работе (поставлена, результата пока нет)
2. Отменена (результат более не нужен, работы остановлены)
3. Отложена (результат нужен не срочно, есть более приоритетные задачи, работы перенесены на более поздний срок)
4. Сделана (исполнитель заявил, что результат достигнут)
5. Закрыта (заказчик подтвердил, что результат его удовлетворяет)
В принципе, можно обойтись без статуса 2, используя в таких случаях пятый.
Саш, это хорошо.
А как быть в случаях, когда приходится отчитываться на промежуточных стадиях?
Менеджеру тоже нужно прогнозировать сроки.
Всё-таки, если нам приходится использовать тотальный или частичный контроль, без разбивки на промежуточные этапы не обойтись, к которым и применим твой вариант.
Или ты это и имел в виду?
А как быть в случаях, когда приходится отчитываться на промежуточных стадиях?
Менеджеру тоже нужно прогнозировать сроки.
Всё-таки, если нам приходится использовать тотальный или частичный контроль, без разбивки на промежуточные этапы не обойтись, к которым и применим твой вариант.
Или ты это и имел в виду?
Статусы, полезные исполнителю, проектному менеджеру и клиенту это три большие разницы.
Надо признаться, у Вас неплохо получается притворяться.
Хотя... у меня лично, к примеру, 30% и 70% готовности вызывают вполне определенные ассоциации. Бытовало даже понятие такое - "0,7-версия".
Хотя... у меня лично, к примеру, 30% и 70% готовности вызывают вполне определенные ассоциации. Бытовало даже понятие такое - "0,7-версия".
В момент перехода задачи в статус "Выполняется" мы полностью теряем контроль над процессом, в рамках описанной системы отслеживания. Статусы 2 и 4 крайне малоинформативны для отслеживания прогресса.
А зачем смешивать статус задачи (по сути просто состояние в котором она находится) и то, на сколько эта задача выполнена? Имхо, много разумнее для проекта в целом применять показатель ООФ (освоенный объем функционала), каждая задача = функиональная единица. Таким образом мы получаем достаточно реальное представление о том, на сколько готов проект в целом (в тех самых %). А поскольку каждая задача оценивается по времени, необходимому для ее выполнения - мы контролируем состояние каждой задачи (когда она должна быть выполнена и на сколько реально выполнение задачи в этот срок). Т.е. мы видим, что совсем нет необходимости скрывать под статусом задачи % ее выполнения. Есть еще не очевидный плюс - нет различий в понимании что за статусом, например, "Почти готова" скрывается 50% или 98%.
Не уловил сути: «Ага, шеф, ррработаю…» — и все тут? Уж лучше: «Холодно», «Тепло», «Жарко» :) Шутка, конечно, но эти стадии хоть какое-то определение ситуации дают, ведь после подведения баг-листа может оказаться, что «Почти готово» нет ни разу.
Да и подходит только для мега-глобальных проектов, а на тех же сайтах тестирирование и исправление 90% ошибок осуществляются в процессе разработки, который очень легко дифференцируется на четко обособленные блоки (при наличии единой логики планирование усложняется, но остается допустимым).
Составив план работ («Проектирование» вместо «Не начата» и список небольших заданий вместо остальных пунктов) можно, как минимум, говорить о степени готовности проекта и в процессе разработки делать прогнозы с некоторой погрешностью.
Да и подходит только для мега-глобальных проектов, а на тех же сайтах тестирирование и исправление 90% ошибок осуществляются в процессе разработки, который очень легко дифференцируется на четко обособленные блоки (при наличии единой логики планирование усложняется, но остается допустимым).
Составив план работ («Проектирование» вместо «Не начата» и список небольших заданий вместо остальных пунктов) можно, как минимум, говорить о степени готовности проекта и в процессе разработки делать прогнозы с некоторой погрешностью.
Мне очень понравился чтатус "почти готова"!=)) Попытался по этому статус-листу расписать свою работу. У меня всё что я делаю всегда пребывает в состоянии "ща покурим и пойдём" - т.е. "почти готова" =)
"Процентный" способ оценки готовности проекта может быть очень эффективен и нагляден, если все операции по проекту могут быть хронологически нормированы, на основании прошлого опыта. Я когда-то использовал такой подход в разработке собственных программ для управления проектами. Допустим, изготовление сайта делится на следующие операции, по которым может быть спрогнозировано время выполнения: (просто для примера)
1. Проектирование (1 день)
2. Разработка движка (10 дней)
3. Отрисовка граф. элементов (4 дня)
4. Тестирование и наполнение начальным контентом (5 дней)
Соответственно, на каждую точку проставляется процент готовности (5, 55, 75 и 100 %% в вышеприведённом примере). Естественно, в любой день можно вычислить промежуточное значение готовности. Также естественно, необходима корректировка данных в случае изменения сроков какой-либо операции. И всё это возможно, к сожалению, только при адекватном нормировании операций по проекту, что само по себе очень непросто...
1. Проектирование (1 день)
2. Разработка движка (10 дней)
3. Отрисовка граф. элементов (4 дня)
4. Тестирование и наполнение начальным контентом (5 дней)
Соответственно, на каждую точку проставляется процент готовности (5, 55, 75 и 100 %% в вышеприведённом примере). Естественно, в любой день можно вычислить промежуточное значение готовности. Также естественно, необходима корректировка данных в случае изменения сроков какой-либо операции. И всё это возможно, к сожалению, только при адекватном нормировании операций по проекту, что само по себе очень непросто...
В случае описанного подхода мы можем столкнуться с такой проблемой: исполнитель осилил первые два пункта и выставил 55%. Занимаясь отработкой графических элементов он пришел к выводу о необходимости доработки кода и запланировал еще четыре дня. И какой статус теперь ему ставить? Опять 5%? Или пересчитать на новое суммарное количество дней, добавить уже сделанное и выставить 48,3%? О чем нам скажет такая цифра? Или еще добавить сюда уже сделанное по графике за два дня и отобразить 54,16%? И тогда менеджер проекта перестанет смотреть на эти цифры, потому что они ничего не будут ему говорить о том, что происходит.
дело в том, что у большинства проектов, по крайней мере тех, с которыми мне приходится работать, есть дедлайны, оговоренные с заказчиками, и несдача в срок грозит (в лучшем случае) потерей заказчика. Потому, задержка исполнения одного этапа, автоматически уменьшает время на оставшиеся этапы... Если же оставшееся просто не успеть сделать до срока - сразу видно, кого и на сколько наказывать. :)
А вообще, самой большой проблемой применения программ управлением проектами является не их функциональность, а то, что многие работники, не привыкшие планировать своё рабочее время, просто неспособны их применять в своей работе.
А вообще, самой большой проблемой применения программ управлением проектами является не их функциональность, а то, что многие работники, не привыкшие планировать своё рабочее время, просто неспособны их применять в своей работе.
Данный метод выставления процентов может быть вырожден до индикатора [X дней до завершения проекта], что будет легче для понимания и менеджмента.
Степень готовности следует указывать бесконечной дробью.
Степень готовности IT-проектов нельзя определять процентами. Разумнее - "сделано"-"не сделано".
мои статусы :)
- начато
- выполнено
- делегировано кому-то
Всё остальное - имхо от лукавого, либо может быть использовано как расширение перечисленного.
мои статусы :)
- начато
- выполнено
- делегировано кому-то
Всё остальное - имхо от лукавого, либо может быть использовано как расширение перечисленного.
боюсь что все эти статусы сводятся к одному - менеджер не хочет видеть реальное состояние дел или попросту не хочет налаживать нормальную работу команды. Ведь дело, согласитесь, не в статусах и их количествах, а в нормальной организации работы. Если ваши программисты не пользуются статусами надлежащим образом, значит: вы не разъяснили им сути статусов, они на это забили и им пофиг, на это забили вы и пофиг всем. Все просто.
Как справедливо написали выше:
1. проценты ни о чем не говорят.
2. статусы (назначена, тестируется, готова...) слишком редки и также малозначущи.
Есть еще вариант который используется например в dotProject:
В каждый момент времени когда сделана некая часть работы и ее нужно залогать. Это значит написать комментарий что было сделано (или что осталось) и одновременно проставить процентики выполнения до нужного уровня (можно не ставить или понизить даже если нужно). Итого:
1. работник сам учится оценивать продолжтительность работы
2. с потолка цифру он взять не сможет (потом не отмажется по логам)
3. Не беда если он ошибся, все ошибаются в планировании, а особенно работник. Просто поправь процент (это будет залогано тоже) и напиши отмазку почему неправильно определял проценты ранее.
4. манагер получает практически точную цифру и весь проект медленно но уверенно двигается шагами вплоть до 0.05%
1. проценты ни о чем не говорят.
2. статусы (назначена, тестируется, готова...) слишком редки и также малозначущи.
Есть еще вариант который используется например в dotProject:
В каждый момент времени когда сделана некая часть работы и ее нужно залогать. Это значит написать комментарий что было сделано (или что осталось) и одновременно проставить процентики выполнения до нужного уровня (можно не ставить или понизить даже если нужно). Итого:
1. работник сам учится оценивать продолжтительность работы
2. с потолка цифру он взять не сможет (потом не отмажется по логам)
3. Не беда если он ошибся, все ошибаются в планировании, а особенно работник. Просто поправь процент (это будет залогано тоже) и напиши отмазку почему неправильно определял проценты ранее.
4. манагер получает практически точную цифру и весь проект медленно но уверенно двигается шагами вплоть до 0.05%
Статусы сами по себе искусственны, на них надо тратить ресурсы чтобы они работали. Было бы идеально если бы статус выставлялся без участия человека. Например:
- Открыл программист файл проекта и лабает какой-то код. Некий монитор статуса сам это дело отслеживает и отображает над каким проектом работает человек.
- Сделал программист нечто, положил его в папку "Готовое", закрыл файл проекта, система ловит статус "Готово"
и т.д.
А чтобы ввести элемент планирования, заранее создать структуру папок и договориться, что должно где лежать в итоге. А в планировщик ввести дедлайны и отслеживать по файлам в этих папках выполнение.
Тогда в любое время можно построить хоть граф, хоть проценты посмотреть, и время оставшееся прикинуть. Соответственно замативировать отстающих, и т.п.
- Открыл программист файл проекта и лабает какой-то код. Некий монитор статуса сам это дело отслеживает и отображает над каким проектом работает человек.
- Сделал программист нечто, положил его в папку "Готовое", закрыл файл проекта, система ловит статус "Готово"
и т.д.
А чтобы ввести элемент планирования, заранее создать структуру папок и договориться, что должно где лежать в итоге. А в планировщик ввести дедлайны и отслеживать по файлам в этих папках выполнение.
Тогда в любое время можно построить хоть граф, хоть проценты посмотреть, и время оставшееся прикинуть. Соответственно замативировать отстающих, и т.п.
Ключевым вопросом мне кажется, является то, на сколько измерима работа. В строительстве, например можно говорить о конкретном объеме. Или скажем процесс перевода статьи можно измерять в знаках или страницах. В данном случае можно говорить о процентах, так как понятно проценты чего указываются.
Если объем оценить сложно, можно только говорить о сроках. И в данном случае, исполнителю следует указывать либо вероятностный прогноз завершения в указанный срок (успею, не успею, с трудом) либо свой прогноз даты завершения.
Если объем оценить сложно, можно только говорить о сроках. И в данном случае, исполнителю следует указывать либо вероятностный прогноз завершения в указанный срок (успею, не успею, с трудом) либо свой прогноз даты завершения.
Я пользуюсь вот этим способом, правда не всегда, в основном когда нужно посчитать проект
Painless Software Schedules
Видно какие задачи в работе, а процент, можно определить, оценив сколько ещё нужно времени
Всё в целом просто, и не напрягает. Ещё нравиться что есть две цифры, запланированная сначала, и динамическая - тренирует правильность оценки "себя"
Painless Software Schedules
Видно какие задачи в работе, а процент, можно определить, оценив сколько ещё нужно времени
Всё в целом просто, и не напрягает. Ещё нравиться что есть две цифры, запланированная сначала, и динамическая - тренирует правильность оценки "себя"
довольно интересная методика, насколько я могу понять. А нет ли подобного описания на русском?
на русском невидел
суть проста
для каждой подзадачи задаётся:
-приоритет (я пока непользуюсь, хотя если нужно, можно по нему сортирвоать если много пунктов)
-часы которые планируются в начале
-часы которые корректируются в процессе выполнения (хотел 4, а понял что нужно 6)
затем вычисляемые поля
-сколько осталось
-сколько потрачено
затем внизу это всё сумируется (экселем), я ещё ввёл паро подытоживающих
ячеек - там делю на 8 (рабочий день) и вижу в днях, сколько нужно было в оригинале, сколько поулчилось, сколько времени потратил, и сколько осталось
получается достаточно простая табличка
суть проста
для каждой подзадачи задаётся:
-приоритет (я пока непользуюсь, хотя если нужно, можно по нему сортирвоать если много пунктов)
-часы которые планируются в начале
-часы которые корректируются в процессе выполнения (хотел 4, а понял что нужно 6)
затем вычисляемые поля
-сколько осталось
-сколько потрачено
затем внизу это всё сумируется (экселем), я ещё ввёл паро подытоживающих
ячеек - там делю на 8 (рабочий день) и вижу в днях, сколько нужно было в оригинале, сколько поулчилось, сколько времени потратил, и сколько осталось
получается достаточно простая табличка
НЛО прилетело и опубликовало эту надпись здесь
В проекте лучше всего бинарные вехи использовать - готово/неготово. Тогда все понятно и прозрачно. - Готово на 90%? Да ты что! Пошел найух!
Не готова веха до степени 100% - задача провалена. Вот тут то начинается и контроль и сроки нормальные.
Не готова веха до степени 100% - задача провалена. Вот тут то начинается и контроль и сроки нормальные.
Тогда менеджеры проектов идут туда же. При таком подходе они просто не нужны. Исполнитель сдавший работу в срок просто получает зарплату.
ага
вот вы и дошли до сакральной сути, поздравляю.
вот вы и дошли до сакральной сути, поздравляю.
В таком случае исполнителю работу (ТЗ) должен давать клиент напрямую. Что не всегда возможно.
Ага, а как команда разработчиков (программеры, дизайнеры, копирайтеры и еще туева хуча народа) будет работать, к примеру, без менеджера? :)
Вот тут-то мы проектов и налабаем!
Какое многообещающее название у блога. :)
"Пилите, Шура, пилите".
"Пилите, Шура, пилите".
НЛО прилетело и опубликовало эту надпись здесь
Программисты тоже разные бывают. Бывают нормальные, которые и сами себя неплохо менеджить могут, бывают ленивые - этих гнать в шею, бывают увлекающиеся - этих надо стаскивать с небес на землю и гладить по голове. Хороший менеджер это тот, который к каждому из них знает как по-человечески подойти, без статусов и процентов.
И сколько процентов от рабочего дня специалиста отводится на выяснение отношений и самоповышение квалификации по умению уйти от ответственности? 50, 70?
трэкинг выполнения задач в %, долях и т.п. не по плечу большинству программистов, дизайнеров и иже с нимиОн не осуществим просто теоретически, потому что разработка - это НИОКР, а не стройка по заранее подготовленному плану, когда надо положить N штук кирпичей, и уже видно, что на данный момент положено M штук. Любой, казалось бы, простой и линейный шаг на стадии разработки может обернуться сюрпризом, когда оказывается, что тут всё гораздо глубже, и 1-дневная запланированная работа по простому печатанию кода может превратиться в недельное исследование.
По поводу ограниченности количества статусов: есть отличный трэкер TrackStudio (это не реклама, так как сам я его не приобрёл и там не работаю). Там статусы создаются и настраиваются совершенно производно в любом количестве, причём могут быть разными для разных типов проектов.
Пришёл к выводу, что трэкинг должен быть внедрён не только в программистких подразделениях, но и вообще во всех управленческих структурах предприятий. Но надо понимать, что попытка внедрения может столкнуться с огромными трудностями управленцы рассмотрят это как покушение на святое, ибо действительно, многая их деятельность станет просто бессмысленной.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Статусы задач/проектов