Автоматизированный бардак: как навести порядок в управлении проектами
11 Ноя 2020, 16:02

Автоматизированный бардак: как навести порядок в управлении проектами

Бизнес-консультант Константин Коптелов на вебинаре от Worksection рассказал, что и как нужно делать для того, чтобы навести порядок в управлении проектами и избавиться от хаоса, который там творится. 

Управление проектом и бизнесом 

Обычно управление проектом выглядит как хаос — ты начни что-то делать, а дальше природа подскажет, как и что. Хаос и бардак очень быстро надоедает нашему руководству, потому что оно не понимает, как этим управлять. Проектные менеджеры тоже очень часто выгорают, потому что непонятно, что с этим делать. 

Тут приходит светлая мысль: давай что-нибудь внедрим. KPI, CRM, крутые системные подходы типа Agile и т.д. Обычно это внедряется быстро и безоперационно. Но всегда получаются хоть какие-то полезные результаты. 

Створіть ефективні PR стратегії разом з експертами Foundation Coffee Roasters, TWID, БФК Gulliver та ще понад 90 провідними брендами!

12 грудня на GET Business Festival дізнайтесь, як розробити ефективні PR-стратегії, підвищити впізнаваність бренду та залучити нових клієнтів через сучасний маркетинг і співпрацю з лідерами думок.

Забронювати участь

Почему?

При автоматизации бардака мы почти всегда получаем автоматизированный бардак. Если сейчас ваши сотрудники создают с какой-то скоростью вам проблемы и головную боль, то автоматизация работы просто увеличит головную боль. Просто теперь они будут ее создавать не за час, а за минуту.

Ни к чему хорошему нас это не приведет. 

Что делать? 

Первый шаг — провести инвентаризацию. Нужно, как минимум, навести порядок. Часто, когда я прихожу на консультацию в компанию, замечаю, что есть один большой котел, и туда валится все подряд. Когда начинаешь читать список того, чем компания занимается (задач, проектов) там просто напихано вообще все. В одном списке на одном уровне находятся и маленькие задачи и большие проекты. Оно все смазано в одну сплошную кучу. 

Поэтому сначала мы все это выписываем одним списком, чтобы оно было не в голове, а на бумаге. 

Следующий шаг — мы начинаем все раскладывать по полочкам. Для того, чтобы это сделать — нужно определиться с терминологией. На самом деле я заметил, что большинство проблем в бизнес-коммуникациях возникают в этих блоках, которые казались очевидными. Все, где есть маркер «очевидно» — нужно прояснить. Ведь у всех очевидные разные вещи.

Например, вы приходите к клиенту и он спрашивает: когда будет готов макет? А вы отвечаете, что макет будет во вторник. На самом деле, клиенты думает, что во вторник в 9 утра макет лежит уже у него на почте, а у вас в голове, что во вторник в 23:00 вы что-нибудь отправили, по поводу чего нужны какие-то правки.

Определимся с терминами 

Задача 

Задача — это все, что требует действий от 10 минут и до 6 часов. Если задача требует больше 6 часов, то лучше ее разделить на подзадачи.

Потому что если у вас есть большие куски — не всегда понятно, есть ли движение и прогресс, а также были ли совершены адекватные движения, чтобы реализовать задачу.

Задания/вехи

Проекты у нас состоят из этапов/вех, которые потом дробятся на задачи и подзадачи. Зачем они нужны? Во-первых, так проще планировать, ведь эти этапы остаются такими же, а задачи могут меняться. Во-вторых, легче отслеживать прогресс. 

KPI/Метрики проекта 

То, как мы понимаем движение проекта.

Проект 

Это что-то, у чего есть начало и конец. Одна из частых ошибок, что я замечаю, — когда проекты называются клиентом.

Клиент/группа проектов 

Допустим у нас есть такая компания, и для нее мы думаем, что мы делаем и в рамках каких-то кусков, чтобы можно было сказать, что вот оно завершено. Например, создаем сайт и должны привлечь на него клиентов. 

Частая ошибка, которая бывает, — когда все смешивается в один котел. Но у нас отдельное обязательство по каждому проекту, отдельный календарь и даже отдельные иногда команды. Когда это все смешано и случилась проблема в одном проекте — клиент недоволен полностью всей работой. Для того, чтобы это разделять, мы даем каждый проект отдельно, плюс получаем поэтапность. Эта завершенность хорошо влияет на всех — нас, сотрудников и клиента. 

Прописываем паспорта проектов 

Мы все выписали, разложили по коробочкам, разобрались с терминологией и смотрим на проекты, которые выписали, и начинаем выписывать паспорта. 

Паспорт — это документ, который носит функцию, которая помогает понять, что это за проект и что с ним делать, когда он закончится, помогает заморозить и разморозить проект максимально бесшумно. 

Acceptance Criteria — как мы понимаем, когда проект завершится? 

Например, мы едем в Одессу и мы видим по навигатору точку, что находимся в Одессе и понимаем, что приехали. 

Как мы понимаем, что мы привлекли клиенту 20 тысяч пользователей? Мы заходим в Google Analytics и видим 20 тысяч пользователей. Чем больше внимания вы уделите этому в начале проекта, тем легче потом вам будет жить. 

Как мы понимаем, что проект движется? 

Это KPI и метрики. Acceptance Criteria помогают нам, когда проект уже завершен. Но от них мало пользы, когда мы движемся по проекту. В это время нам нужны какие-то координаты. Финальный критерий поездки в Одессу — прибытие в Одессу. Но по пути нам это ничего не дает, мы не знаем, туда ли мы едем, нужно ли ускориться и т.д. Никакой координации мы не получаем. Метрики помогают нам это понять. 

Казалось бы эти показатели похожи на Acceptance Criteria. Но в случае метрик — это та история, которую мы можем регулярно отслеживать по ходу движения критерия, а в случае Acceptance Criteria мы видим это только в конце. 

По тем проектам, где вам не удается создать метрики, поставьте себе вот такой светофор. Его стоит делать по трем показателям. Тут три блока — бюджет, сроки и настроение клиента. 

Этот набор очень хорошо работает для тех типов проектов, где тяжело прописать KPI. 

Бизнес-задачи и вехи 

Самый главный вопрос, который мы должны себе задать: а какую бизнес-задачу этот проект решает?

Что мы хотим сделать? Это важно, потому что проект по ходу работы, скорее всего, будет меняться, но бизнес-задача остается до конца проекта. Она дает нам понимание, как лучше разрабатывать проект. 

Приходит клиент и ставит задачу. Мы с ним пытаемся нарисовать план действий, приходим к ТЗ. А потом все идет не по плану, и, чтобы этого не было, мы стараемся думать вехами. 

У нас есть два плана реализации проекта. Первый — жесткий. Когда мы прописали полностью конкретное ТЗ, дальше разбили на его этапы, и даем этапы клиенту по мере выполнения. Здесь нужно все максимально прописывать. 

Второй — гибкий. Клиент что-то нарисовал, мы придумали, как максимально быстро реализовать эту бизнес-задачу. И дальше просто улучшаем.

Итоги

  1. До автоматизации наведите порядок
  2. Определитесь с критериями приемки, метриками прогресса, точками аварийной остановки
  3. Всегда и на всех уровнях помните про бизнес-задачу, которую решаем
  4. Делайте регулярные сверки 

Кавер: Unsplash

Расскажите друзьям про новость