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

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

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

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

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

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

Нова економічна реальність: які тренди визначатимуть ринок у 2025 – досвід TERWIN, Arcelor Mittal, Kvertus, BRAVE1, Starlight media, ГК «Молочний альянс» та 40 провідних управлінців та державних діячів.

11 квітня на Business Wisdom Summit дізнайтеся, як розширювати партнерства, зміцнювати довіру до бренду та виходити на міжнародні ринки. Реальні стратегії та досвід компаній, які вже зробили цей крок.

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

Почему?

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

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

Что делать? 

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

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

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

Например, вы приходите к клиенту и он спрашивает: когда будет готов макет? А вы отвечаете, что макет будет во вторник. На самом деле, клиенты думает, что во вторник в 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

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