Ведення процесу

3 years ago
Eugene Kasinskyy
1 minute

Нотатки

  • по суті має бути одна сутність проекту. різні інструменти мають лише показувати ту сутність у різних розрізах (майндмап, епіки, сторі, нотатки, кейси – це все має збігатись. це мають бути однакові сутності. Не можна плодити зайві сутності)

1. Річні плани

Майнд мап проекту

Мінімально звертаємось до цього документу раз на місяць при плануванні спринтів і підбитті підсумків минулого спринту. А можна і частіше (2-4 рази на міс)

2. Помісячні плани

Редмайн: погодинне трекання часу всіх учасників команди, епіки-підепіки, сторі. Помісячний зріз фактично витраченого часу команди у розрізі задач та епік.

Рухаємось в форматі спринтів, один спринт – один місяць.

При плануванні спринта:

  • відкриваємо загальні плани на рік,
  • відкриваємо бек-лог,
  • відкриваємо задачі з попередніх принтів, які ще не закрили

В процесі спринта

  • переконуємось, що всі епіки і значущі таски мають правильну структуру опису:
    • В чому суть задачі?
    • Для чого?
    • Як виміряти успіх?
    • Які кроки реалізації?
    • Опціонально: Оцінка часу (Години: дуже орієнтовно. За можливістю розбито по підзадчам)

При закритті спринта:

  1. дивимось які задачі планували,
  2. перевіряємо, що саме встигнули зробити, (по статусу verified & closed)
  3. що не встигли зробити,
  4. скільки часу витратили на задачі,
  5. що фактично пророблено за витрачений час (в кожній задачі, в яку затрекано час має бути записано, що саме зроблено за цей час. Навіть, якщо задача не закрита – проміжні результати мають бути вписані в задачу)
  6. наскільки не вписались у плани
  7. що було погано? причини, які стали на заваді виконанню задач. (чи можемо ми внести правки у процес, щоб неуспішні кейси не повторились)
  8. де час був витрачений неефективно?
  9. що було ЗБС (що варто відмітити і частіше використовувати в роботі)
  10. перевіряємо чи не забули затрекати час (затреканий час це ж ЗП),
  11. перевіряємо чи час затреканий у правильні: проекти, епіки, сторі
  12. якщо є посилання на зовнішні документи (таблиці) то вкладаємо копію таблиці файлом в тіло задачі і підписуємо, щоб було видно дату актуальності файлу

3. TimeLine проекту і кейси

сутність перша – Лінія життя проекту (уявляємо що ведемо щоденник проекту.

сутність друга – збираємо кейси успіху чи неуспіху. Наче ведемо внутрішній блог.

Принципово важливо не забути жодного важливого етапу.

Як це перевіряється??????

  • всі важливі етапи у нас мають бути описані в майндмапах
  • на всі важливі задачі ми витрачаємо якийсь час, тому є записи у редмайні)

Який процес?

  1. на щомісячних нарадах кожен співробітний розповідає над чим працював місяць і чого досянув. ПМ записує тези і формує з них перелік короткий.
  2. В результаті для кожного проекту вийде 12 місячних звітів на рік. І в кожному місячному звіті буде перелік дій кожного працівника.
  3. В кінці року – підсумовуючий результат. Timeline за рік (без поділу на місяці і учасників)

Які атрибути кейсів?

  • назва
  • короткий опис
  • мета? нащо ми цю роботу планували і робили
  • КПІ успіху (як ми знатимемо, що нам вдалось)
  • ROI (які ресурси ми витратили
    • Години і гроші. Час на виконання задачі Ново, час команди замовника, час підрядників, наші прямі витрати на цю задачу, оплати підрядникам і т.п.
    • що ми отримали на виході
  • історія опціонально (що робили, скільки часу витратили, які прикольні моменти були, як факапи були, вставляємо корисні скріншоти)
  • де ми кейси описуємо? (база знань, трекер)
  • що вважати кейсом? мінімальна к-ть годин (можливо треба таку умову, наприклад “десятки годин”)
  • скільки часу витрачати на оформлення кейсу?? (ХЗ, головне наразі трекати)

Нащо потрібні кейси?

  • для звітності перед замовником. Щоб замовник чітко бачив які ми молодці, а не дофантазовував сам.
  • для пошуку нових клієнтів. (це можуть бути кейси на нашому сайті, статті, історї для “зацепки” нових клієнтів, бо легко продати сказавши: “оо, ми точно вашу задачу уже віиконали недавно, маємо досвід, подивіться які ми ефктивні”)
  • найголовніше, для менеджера при проектуванні. Коли менеджер при плануванні епіки-задачі розуміє що треба буде описувати кейс, він наперед формує показники успішності в думає яке має бути ROI. а далі в процесі виконання задачі лише звіряється з проектом. Це дає змогу отрмувати добре спроектовані задлачі, а такі задачі значно легше виконувати. у них більше ефективність
  • навчання персоналу. нові люди можуть просто перечитати кейси попередників і успадккувати досвід
  • для масштабування бізнесу (для упаковки до продажі для майбутніх статей у пресі) так як на старті НОВО ми шукали кейси ЛОгастеру і витрачали на то купу часу. і то не все згадали
  • для приємних спогадів і ностальгії (в ідеалі кожен бізнес требе буде подати у вигляді вікі сторінки, де нумерованим деревоподібним списком будуть показані всі етапи які пройшов цей бізнес). Можна одразу у базі знань почати вести таке дерево для кожного проекту (і в ідеалі, це дерево має бути дуже подібним до майнд-мапу. Тотожнім)
  • для історій успіху (для публічних виступів, лекцій, майбутніх бізнес-контрактів, найму персоналу)
  • Приклади кейсів
    • Ново
      • Дропнутий домен
      • Лід Єлоджик

4. Профілактично

  • проходитись по проектам в пошуку “забутих задач” (зайве створено, дублі, не валідні задачі, не проставлена версія, не вірні статуси, по суті сплітнута задача, а зробили дублів і т.п.). пеіродичність раз у квартал.