?

Log in

Концепция Базовых Тикетов - Денис Митрофанов
May 4th, 2010
07:27 pm

[Link]

Previous Entry Share Next Entry
Концепция Базовых Тикетов
В основе возможностей qTrack лежит определенная концепция (методология) управления задачами и проектами.
Я уже писал про внутренние (скрытые) сообщения, которые позволяют не дублировать сущности и вести скрытые обсуждение между членами команд в том же тикете (задаче), где ведется обсуждение между командами - внешние (открытые) сообщения.

Другая важная составляющая концепции (которая также усиливает эффект скрытых сообщений) - принцип: 1 задача = 1 тикет.

Наверное не многие слышали про Структурную Декомпозицию Работ (WBS) - если говорить проще, то это просто иерархический список всех работ проекта.
Но при этом почти каждый хорошо знает про диаграмму Ганта. В теории управления проектами WBS и Гант примерно равнозначны. Но использование того или иного инструмента зависит от типа проекта. Например, в строительстве крайне важны сроки и четкая последовательность поставок, причем это реально критично (в отличии от IT-проектов) - если привезти бетон, которых будет некуда заливать он просто застынет, а если привести окна со стеклами на этапе котлована, то от них ничего не останется. Поэтому Гант (или сетевой график) действительно важный инструмент для проектов строительства.

Почему-то в IT-проектах тоже очень любят Ганта, хотя диаграмма редко бывает актуальной и еще реже работы соответствуют плану. Это вовсе не значит, что в IT-проектах не нужно планирование. Но зачастую ему уделют неоправданно много времени и сил, пытаясь внести на диаграмму Ганта все задачи. Это практически бесполезно. На Ганте достаточно отметить ключевые вехи проекта и ответственность сторон (Заказчик-Подрядчик), так, чтобы список задач занимал пол-листа A4.

Но проект состоит из десятков и сотен задач - что же делать с ними?
Как раз здесь приходит на помощь Структурная Декомпозиция Работ. Суть в том, что все работы разбиваются на максимально атомарные задачи (мы рекомендуем 4-12 часов специалиста), например, в случае с сайтом 1 задача = 1 функциональная страница.

Такой подход позволяет адекватно оценивать прогресс выполнения работ - не абстрактные 80% готово, а вполне конкретные - выполнено 40 задач из 50. Но еще больший эффект можно получить, если задачи разбить на итерации (например, объем работ на одну итерацию = 1 неделе работы) и сдавать Заказчику не весь проект сразу, а итерационно. Тогда состояние проекта будет уже не выполнено 40 задач из 50, а принято заказчиком (хотя скорее всего уже будет не 40,а сильно меньше.)

Думаю теперь становится ясно, что 1 тикет это 1 задача из WBS и зачем в одном тикете нужно работать и Исполнителю и Заказчику.

Итого, какие бонусы мы получаем от такого подхода:
- четкое понимание текущего состояния проекта и отклонение от планов, понимание, "что осталось сделать для сдачи этапа работ" (и получения оплаты)
- значительно уменьшение эффекта 20/80 (когда на последние 20% надо 80% ресурсов)
- снижение рисков в отношениях с заказчиком (сдача работ начинается в самом начале)
- актуальное состояние требований (по каждой задаче видно какой была изначальная постановка, что и почему изменилось в процессе выполнения задачи
- спрямление отношений Заказчик-Исполнитель без потери контроля

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

(Leave a comment)

My Website Powered by LiveJournal.com