Оперативні плани Redmine без додаткових плагінів

Прочитавши кілька хороших статей з організації оперативного планування засобами Redmine (наприклад, тут), вирішив поділитися досвідом і написати про те, як реалізовано оперативне планування в нашій компанії.

Під оперативним плануванням я розумію створення приоритезированного переліку завдань для конкретного виконавця на заданий інтервал часу. Відповідно, сумарна оцінка трудомісткості по всіх завдань з переліку повинна приблизно відповідати сумарним робочого часу на заданому інтервалі.

Визначимося з термінологією
Спринт — інтервал часу, на який складається план (термін взятий з Scrum, і сенс його той же самий).
Оперативний план співробітника — перелік завдань, призначених на конкретного виконавця на спринт.

При розробці концепції оперативного планування використовувалися ідеї і поняття Scrum, хоча ми цю методологію не використовуємо.

В першу чергу необхідно зрозуміти — для кого потрібен оперативний план і яка від нього користь?

Оперативний план дозволяє забезпечити роботою працівників на невеликий інтервал часу (ми використовуємо спринт тривалістю 1 тиждень), надати йому доступ до всього горизонту завдань на цей період, що, безсумнівно, підвищує віру співробітників у адекватність, далекоглядність і професіоналізм менеджерів. Альтернатива — призначати завдання на виконавців по одній-дві, по мірі їх появи і готовності до роботи. Це зручно для деяких менеджерів, але не подобається виконавцям.

Досвід застосування оперативних планів показав, що найбільш ефективно їх використання у відокремлених кросспроектных групах (службах), таких, як технічні письменники, група розробки ядра продукту, третя лінія техпідтримки і т. д. При цьому в проектних командах описувана концепція оперативного планування не прижилася, оскільки її основна ідея — візуалізація завантаження та переліку завдань виконавця — не зацікавила проектних менеджерів (вони і так контролюють завантаження людей і пріоритети завдань, комбінуючи гнучкі та жорсткі методи управління, так що додаткове обмеження у вигляді складання переліку завдань на тиждень і слідування їм заважає).

Передумови для успішного застосування оперативних планів
Має сенс впроваджувати оперативне планування, якщо:
  • Група виконавців виконує однотипні спеціалізовані завдання (як на конвеєрі). Приклад — невеликі доопрацювання ЗА заявками користувачів в третій лінії техпідтримки;
  • Завдання не є сверхсрочными (можуть деякий час перебувати в черзі);
  • Пріоритет завдань змінюється рідко;
  • Надважливі завдання, які автоматично стають в початок списку і зрушують інші завдання, приходять рідко;
  • Тривалість завдань зазвичай не перевищує часу спринту (в основному менше).
Виходить, що оперативний план потрібен для
  • Співробітників груп, які працюють з великою кількістю невеликих по тривалості виконання завдань, а самі задачі можуть надходити з різних джерел;
  • Менеджерів начебто технічних директорів і начальників відділів, які хочуть знати, наскільки завантажені співробітники, вірно обрані пріоритети завдань.
Чому для оперативних планів пропонується використовувати Redmine, а не спеціалізований софт зразок MS Projects? Тому, що оперативні плани створюються в чому для виконавців, а не для менеджерів. Крім того, оперативне планування Redmine дозволяє працювати з максимально деталізованими і декомпозированными завданнями. Створити і, головне, підтримувати актуальність такого плану в MS Project складно.

Технічна реалізація
Особливість пропонованої організації оперативного планування допомогою Redmine в тому, що пропонується використовувати тільки настроювані поля і стандартну фільтрацію завдань, при цьому ніяких додаткових плагінів (як платних, так і безкоштовних) встановлювати і вивчати не потрібно.

Необхідно:
  1. Включити талон на виконання завдання в план. тобто в певний спринт. Для цього створюється настроюване поле «Спринт» типу «Список з численними значеннями». Перелік значень — номери тижнів, на кшталт «Тиждень 35», т. к. у нас спринти тижневі (множинність вибору потрібна у випадку, якщо завдання виконується протягом декількох спринтів);
  2. Вказати, скільки часу протягом спринту передбачається витратити на виконання даної задачі (оскільки завдання, наприклад, може мати оцінку трудомісткості 50 гг, а спринт містить всього 40 робочих чч.). Для цього створюється настроюване поле «Оцінка часу на спринт» типу «Ціле» або «З плаваючою крапкою», в залежності від того, як точно ви оцінюєте трудомісткість завдань;
  3. Визначити послідовність виконання завдань. Для цього створюється настроюване поле «Черговість виконання» типу «Ціле». У цьому полі просто ставитися номер завдання у черзі на виконання в рамках поточного спринту, тобто для першого завдання на виконання — 1, для другої — 2 і т. д. Далі відбувається ранжування переліку по цьому полю стандартними засобами Redmine у списку завдань.
Ось так виглядає талон з полями:

image

Так виглядає оперативний план в Redmine:

image

При бажанні його легко можна вивантажити в MS Excel або PDF засобами Redmine:

image

На жаль, як кажуть, «простота вимагає жертв». І в даному випадку ця жертва — незручність збору історії планування на спринти. Наприклад, для відповіді на питання «скільки планували часу на цю задачу в кожному спринті протягом останнього місяця?», доведеться збирати цю інформацію за повідомленнями про зміну відповідних полів в історії зміни талона, т. к. поля «Оцінка часу на спринт» та «Черговість виконання» щотижня буде замінено. Однак досвід показав, що така статистика потрібно вкрай рідко — зазвичай весь аналіз виконання плану відбувається один раз наприкінці спринту (на ретроспективі).

Тепер відповідь на друге питання — яка ж користь від таких оперативних планів?
  • Співробітникам спокійніше і комфортніше виконувати завдання, коли вони бачать перелік на деякий час вперед і знають, що цей перелік буде змінений тільки в крайньому випадку;
  • Менеджерам простіше сформувати такий план на початку спринту (наприклад, раз в тиждень), ніж розподіляти кожну приходить завдання;
  • На складання оперативного плану на тиждень йде 10-15 хвилин на кожного виконавця, що незрівнянно менш трудомістке, ніж актуалізувати аналогічним чином план в MS Project;
  • Розподіл завдань конкретним виконавцям можна делегувати тім ліду, позначивши йому загальний перелік завдань;
  • Підвищується прозорість планування робіт: будь-який працівник (менеджер або виконавець) може зайти в Redmine і переглянути оперативний план іншого співробітника без зайвих питань і бюрократії;
  • Підвищується загальна культура управління: менеджерам і зацікавленим особам доноситься, що оперативний план може коригуватися лише в крайньому випадку з погодження, наприклад, технічного директора. Тому необхідно заздалегідь готувати перелік завдань і визначати їх пріоритети. Не встиг до планування завдань на спринт — чекай наступного розподілу;
Деякий «лайф-хак» при роботі з оперативними планами (з'ясувалося також досвідченим шляхом)
  • У зв'язку з динамікою надходження завдань, можливими помилками в оцінці трудомісткості та іншої непередбаченої головного болю має сенс планувати завдання не на всю тривалість спринту, а залишати деякий буфер часу. У нас цей запас — 8 годин, тобто плануємо 32 чч для тижневого спринту;
  • Першоджерелом плану повинен бути відфільтрований перелік завдань в Redmine (як на другій картинці). Однак для фіксації плану відразу після його створення найкраще вивантажувати його snapshot (в форматі MS Excel або PDF) — аналогічно базового плану MS Project. Далі цей зафіксований оперативний план може бути розіслано зацікавленим особам, а також бути використаний на ретроспективі в кінці спринту;
  • Для зручності роботи з оперативним планом за описаною концепції найзручніше використовувати типи трекерів і схеми переходів з моєї попередній статті.

Описана концепція була розроблена як тимчасова, поки в компанії не впровадиться більш досконала система оперативного планування. Але немає нічого більш постійного, ніж тимчасове — схема успішно працює вже більше року.

Буду радий відповісти на ваші питання і дізнатися, що ваш досвід з оперативного планування.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.