Сразу хочу сказать, что речь идет о небольших проектах — 2-5 человек, продолжительностью около года или менее.
Столкнувшись уже несколько раз с необходимостью стать менеджером такого небольшого проекта, решил:
а) поделиться своими мыслями и
б) спросить совета (ведь наверняка я не первый, кто столкнулся с описанным ниже).
Итак, столкнулся я прежде всего вот с чем. Одна из главных (для меня) задач была оценка статуса проекта. Нужно было понять, все ли идет по плану, и если нет, то своевременно обнаружить отклонение от расписания и предвидеть новую дату завершения.
К моему большому удивлению, я так и не смог найти простого решения этой задачи. В компании использовали Microsoft Project, который, на мой взгляд, эту задачу решает очень плохо.
Коротко, почему я счел Microsoft Project и подобные инструменты неподходящими: их ключевой компонент — это диаграмма Ганта. Которая, может быть, и работает для «материальных» проектов типа строительства моста или небоскреба, но для небольшого ИТ-проекта мне показалась применимой слабо.
— Для большинства задач мне не нужно выстраивать зависимости типа «Старт-ту-финиш».
— Более того, для большинства задач последовательность их выполнения может быть любой и меня, как ПМ, она очень мало интересует.
— Если я назначаю без дополнительных телодвижений две задачи продолжительностью 10 дней на единственного человека в проекте, то я хочу сразу же видеть, что проект будет закончен через 20 дней. В Microsoft Project я увижу, что человек будет первые 10 дней загружен на 200 процентов. Если, конечно, «ручками» не подвину задачи.
— Я хочу иметь возможность «на лету» перебрасывать задачи между людьми и изменять их запланированную продолжительность. Сразу же видя, как изменится ориентировочная дата завершения проекта.
— И собственно, я хочу видеть то, что я назвал time tracking.
Еще одна картинка в общую кучу — почему-то довольно много людей для этой задачи использовали и используют… банальный лист в экселе.
Теперь же перейду к тому, как же я вижу этот процесс, и что бы я хотел видеть от системы управления проектами.
Общее:
1. Древовидный список задач.
2. Одна задача — один ответственный.
3. Задачам-«листьям» можно (и нужно) задать оценку времени выполнения.
4. Задачи-«узлы» автоматически суммируют время выполнения всех подзадач.
5. Задачи создаются и распределяются по участникам ПМ-ом.
Отчетность о работе (главное — должно быть ОЧЕНЬ простым — а то или не будут делать, или будут делать формально!):
1. Каждый участник команды ежедневно вносит, сколько часов было потрачено на ту или иную задачу.
2. При этом он видит «remaining time» для этой задачи и может его изменить при необходимости.
3. Когда задача завершена, ее remaining time становится равным нулю. (В идеале, если оценка необходимого времени была сделана исключительно точно, это произойдет само, без изменения remaining time вручную).
Отчеты для ПМ:
1. Ориентировочная дата дедлайна (вначале только исходя из оценок, потом с учетом поправок к remaining time, сделанным участниками). Из расчета, что каждый участник каждый день делает 8 часов работы (в идеале, с поправкой на эффективность, коммуникацию и т.п.) Собственно, ради него все и затевается.
2. Процент выполненных работ на данный момент. Тоже достаточно важный показатель.
3. Изменение даты дедлайна во времени (отражает, например, точность планирования, большие изменения и т.п.).
4. Различные срезы по задачам (потрачено времени, изменение оценки и т.п.).
5. Отклонения от расписания.
6. Проблемные места (большая разница между первоначальным планом и реально потраченным временем, резкие изменения remaining time и т.п.).
7. Custom-отчеты по желанию ПМ.
Желаемые вкусности:
1. Интеграция с существующим баг-трекингом. Чтобы при создании ошибки (или запроса на изменение) можно было привязать его к одной из задач. Чтобы время в отчетности можно было привязывать к ошибке, но при этом оно автоматически плюсовалось ко времени, потраченному на задачу.
Заметьте, нигде не фигурирует время старта и время окончания задачи! Все расчеты ведутся от текущего дня (если мы смотрим в будущее) или по фактическим данным (если смотрим назад).
Все задачи считаются независимыми. Естественно, в реальности это не всегда так, и назначение задач по людям ПМ должен стараться делать, учитывая возможные зависимости. Но в системе какого-то спец. механизма для этого нет.
Более того, время окончания одной задачи здесь не столь важно. Важна оценка того, когда будет завершен весь проект. И эта оценка автоматически пересчитывается после каждого изменения (добавление новой задачи или изменение remaining time, создание запроса на изменение или отчета об ошибке и т.п.)
Важно же то, сколько времени будет потрачено (или уже потрачено) на ту или иную задачу. И именно исходя из этих данных, и делаются все оценки и расчеты.
Несомненно, описанная здесь система далеко не идеальна и во многом упрощена, но… как мне кажется, именно что-то подобное могло бы сильно упростить жизнь ПМ-у небольшого проекта.
Теперь собственно вопрос — есть ли реализация подобного взгляда на управление проектами? И имеет ли оно право на жизнь?
Столкнувшись уже несколько раз с необходимостью стать менеджером такого небольшого проекта, решил:
а) поделиться своими мыслями и
б) спросить совета (ведь наверняка я не первый, кто столкнулся с описанным ниже).
Итак, столкнулся я прежде всего вот с чем. Одна из главных (для меня) задач была оценка статуса проекта. Нужно было понять, все ли идет по плану, и если нет, то своевременно обнаружить отклонение от расписания и предвидеть новую дату завершения.
К моему большому удивлению, я так и не смог найти простого решения этой задачи. В компании использовали Microsoft Project, который, на мой взгляд, эту задачу решает очень плохо.
Коротко, почему я счел Microsoft Project и подобные инструменты неподходящими: их ключевой компонент — это диаграмма Ганта. Которая, может быть, и работает для «материальных» проектов типа строительства моста или небоскреба, но для небольшого ИТ-проекта мне показалась применимой слабо.
— Для большинства задач мне не нужно выстраивать зависимости типа «Старт-ту-финиш».
— Более того, для большинства задач последовательность их выполнения может быть любой и меня, как ПМ, она очень мало интересует.
— Если я назначаю без дополнительных телодвижений две задачи продолжительностью 10 дней на единственного человека в проекте, то я хочу сразу же видеть, что проект будет закончен через 20 дней. В Microsoft Project я увижу, что человек будет первые 10 дней загружен на 200 процентов. Если, конечно, «ручками» не подвину задачи.
— Я хочу иметь возможность «на лету» перебрасывать задачи между людьми и изменять их запланированную продолжительность. Сразу же видя, как изменится ориентировочная дата завершения проекта.
— И собственно, я хочу видеть то, что я назвал time tracking.
Еще одна картинка в общую кучу — почему-то довольно много людей для этой задачи использовали и используют… банальный лист в экселе.
Теперь же перейду к тому, как же я вижу этот процесс, и что бы я хотел видеть от системы управления проектами.
Общее:
1. Древовидный список задач.
2. Одна задача — один ответственный.
3. Задачам-«листьям» можно (и нужно) задать оценку времени выполнения.
4. Задачи-«узлы» автоматически суммируют время выполнения всех подзадач.
5. Задачи создаются и распределяются по участникам ПМ-ом.
Отчетность о работе (главное — должно быть ОЧЕНЬ простым — а то или не будут делать, или будут делать формально!):
1. Каждый участник команды ежедневно вносит, сколько часов было потрачено на ту или иную задачу.
2. При этом он видит «remaining time» для этой задачи и может его изменить при необходимости.
3. Когда задача завершена, ее remaining time становится равным нулю. (В идеале, если оценка необходимого времени была сделана исключительно точно, это произойдет само, без изменения remaining time вручную).
Отчеты для ПМ:
1. Ориентировочная дата дедлайна (вначале только исходя из оценок, потом с учетом поправок к remaining time, сделанным участниками). Из расчета, что каждый участник каждый день делает 8 часов работы (в идеале, с поправкой на эффективность, коммуникацию и т.п.) Собственно, ради него все и затевается.
2. Процент выполненных работ на данный момент. Тоже достаточно важный показатель.
3. Изменение даты дедлайна во времени (отражает, например, точность планирования, большие изменения и т.п.).
4. Различные срезы по задачам (потрачено времени, изменение оценки и т.п.).
5. Отклонения от расписания.
6. Проблемные места (большая разница между первоначальным планом и реально потраченным временем, резкие изменения remaining time и т.п.).
7. Custom-отчеты по желанию ПМ.
Желаемые вкусности:
1. Интеграция с существующим баг-трекингом. Чтобы при создании ошибки (или запроса на изменение) можно было привязать его к одной из задач. Чтобы время в отчетности можно было привязывать к ошибке, но при этом оно автоматически плюсовалось ко времени, потраченному на задачу.
Заметьте, нигде не фигурирует время старта и время окончания задачи! Все расчеты ведутся от текущего дня (если мы смотрим в будущее) или по фактическим данным (если смотрим назад).
Все задачи считаются независимыми. Естественно, в реальности это не всегда так, и назначение задач по людям ПМ должен стараться делать, учитывая возможные зависимости. Но в системе какого-то спец. механизма для этого нет.
Более того, время окончания одной задачи здесь не столь важно. Важна оценка того, когда будет завершен весь проект. И эта оценка автоматически пересчитывается после каждого изменения (добавление новой задачи или изменение remaining time, создание запроса на изменение или отчета об ошибке и т.п.)
Важно же то, сколько времени будет потрачено (или уже потрачено) на ту или иную задачу. И именно исходя из этих данных, и делаются все оценки и расчеты.
Несомненно, описанная здесь система далеко не идеальна и во многом упрощена, но… как мне кажется, именно что-то подобное могло бы сильно упростить жизнь ПМ-у небольшого проекта.
Теперь собственно вопрос — есть ли реализация подобного взгляда на управление проектами? И имеет ли оно право на жизнь?
