G
Gustav
Команда форума
Администратор
- Сообщения
- 26.410
- Лайки
- 51.221
Как делать проекты, не стреляя себе в ногу
Советы по управлению проектами от бывшего руководителя отдела разработки агентства Friends Moscow Петра Фомичёва.
Про управление людьми очень хорошо сказал Егор Волков из компании Greensight: «Люди всегда всё портят. Они обещают и не делают. Или делают, но не так. Или так, но не то. Или то, но долго. Было бы здорово как-нибудь так построить бизнес, чтобы без людей».
Но без людей пока никак. И в бизнесе они ключевое место занимают, и проекты они же делают. Поэтому мне бы хотелось поделиться кое-каким опытом: последние четыре года я провёл в агентстве Friends Moscow, которое делает рекламу и рекламу классную. Я руководил отделом разработки и ведения digital-проектов.
Далее по тексту вы найдёте небольшие правила и порядок действий, который я вывел, воюя с обстоятельствами на всех фронтах и очень часто им проигрывая.
Материал вряд ли пригодится опытным суперменеджерам, которые и так всё знают назубок — я описываю очень простые, лёгкие и понятные правила, которые можно применять где угодно.
Заметки относятся к разработке сайтов, приложений и прочих цифровых проектов, но если применить немного фантазии, они легко адаптируются к любой ситуации.
Я обещаю, что не будет сложных инструментов — всё будет просто.
Энтропия? Я что, читаю vc.ru ради умных слов?
Энтропия — это то, что разрушает все наши замыслы. Чтобы попасть на тренировку к 10:00, мне надо встать хотя бы в 8:30. Я уверенно ложусь спать в 1 час ночи — без тени сомнений, что завтра в 10 тренер будет ругаться за то, что я опять пил на выходных и поэтому бью троечку слишком медленно. Всё спланировано, и Google Home готов разбудить меня вовремя. Угадайте, кто незаметно для себя во сне отключает будильник?
Или другой пример — вы собираетесь в отпуск с девушкой, уже всё готово и куплены билеты, но вдруг она звонит и говорит, что вам нужно расстаться. Внешний фактор разрушает все ваши дальнейшие планы.
Вселенная целиком и полностью полагается на энтропию — это базовый элемент, она повсюду. И всё, что мы можем делать, — лишь стараться уменьшать элементы случайности.
Человечество только этим и занимается: мы научились выращивать пшеницу, чтобы не зависеть от плодов в лесах, потом одомашнили коров, ибо не набегаешься за ними по всей округе. Приручили собак, чтобы они управляли стадом. И так далее, вплоть до стабильной работы с 9 до 17 с часовым перерывом на веганский обед.
Менеджер проекта управляет людьми — а ничего более энтропичного, пожалуй, не существует. Помимо энтропии, которая создаётся людьми, есть множество внешних факторов, словно сговорившихся сбить вас с пути.
Тут мы приходим к двум важным пунктам:
Учимся рисовать
Как это обычно случается — к вам приходит коллега, заказчик или друг и произносит сакральную фразу: «Слушай, я тут подумал, и мне пришла в голову идея...». После следует описание, которое может быть любым: от продуманного плана до полного фарша из мыслей.
Если у вас нет шанса спастись и пойти кормить соек с лучшей девушкой в этом городе — с этой секунды для вас начинается проект.
Сначала необходимо разобраться, что же мы делаем — уточнить цель. Умные дяди в крутых книжках называют это «собрать требования заказчика». Заказчиком для нас выступает тот, кто хочет достичь цели — это можем быть даже мы сами, если проект личный. Заказчиков может быть много, например, целый бизнес-юнит крупной корпорации. Но всё же обычно, это от двух до пяти человек.
Применительно к digital-проектам я крайне редко встречал ситуацию, в которой бы заказчик представлял себе финальный результат в подробностях. Обычно вводные выглядят как «мы хотим сайт и чтобы там всё летало». Есть отличный способ организовать любое количество заказчиков и буквально за несколько часов зафиксировать требования к проекту.
Надо «всего лишь» собрать их в одной комнате, где есть большая доска и фломастеры. С этой секунды мы можем начать проектирование.
Для этого мы рисуем наш сайт или приложение по экранам, начиная с самого первого, и вместе с заказчиками представляем, как он должен работать. После мы связываем все экраны стрелочками. Мы рисуем каждую кнопку, каждый слайдер и каждый блок текста, а также то, куда он ведёт. Отдельно прописываем, почему он здесь. Очень важный момент тут ровно один — мы представляем, как проект должен работать.
На этом этапе мы не занимаемся UX-проектированием, мы не рисуем дизайн — мы всего лишь в визуальной форме записываем всю функциональность, которая должна быть у проекта.
Важно пресекать желание участников поразмышлять над цветами кнопок: мы должны несколько часов представлять себе, как всё должно работать, и нарисовать структуру функциональности, но не более того. Вас не должна отпугивать призрачная лёгкость этого метода — на самом деле вытянуть из заказчиков все важные функции и ничего не забыть, а также разложить это по полочкам в их головах не так уж просто.
Я проделывал этот простой трюк со всеми: с креативными командами, в крупных корпорациях, в стартапах на начальной стадии, и всегда люди выходили с ясной картинкой проекта в голове. Он превращался из миража в понятную структуру.
И если мы всё сделали правильно, то в конце подобной «детской» сессии проектирования у нас на руках окажется большой и некрасивый мокап проекта, в котором учтены пожелания всех заинтересованных сторон. Не страшно, что он выглядит как наскальная живопись — мы скоро это исправим.
Делаем крутое ТЗ
Техническое задание критически важно. Думаю, после этой фразы поклонники Agile уже начали собирать валежник для костра, чтобы меня сжечь, но тут всё просто: есть продукты, в которых итерационная разработка является необходимостью, а есть проекты, где нужно получить конкретный результат в конкретный срок и не более того. Надо знать, где и что корректно применять.
Техническое задание в моём понимании — это лишь формальное описание цели, которую мы хотим достигнуть. Оно может выполняться в любой удобной для вас форме. Я предпочитаю презентацию и интерактивный прототип, которые сопровождает документ с подробностями, но вы вольны использовать другие методы, лишь бы они скрепляли все стороны одной целью: и заказчиков, и ваших разработчиков, и самое главное — вас самих.
Это вам больше всех надо знать, куда же мы хотим приплыть, потому что за это вам платят деньги.
Расскажу простой пример: в самом начале карьеры меня подключили к созданию внутреннего проекта. Туда позвали очень хорошую студию, и я по неопытности решил, что ребята сделают всё сами — они же одни из лучших специалистов на рынке. Поэтому я решил отказаться от написания ТЗ и почти всё фиксировал на словах.
Загадка: сколько реализовывался проект, на который было отведено 3 месяца?
Ответ: провальный проект без ТЗ, но с очень крутой студией вместо трёх месяцев занял полтора года, и при этом не вся функциональность была реализована.
Я начинаю написание ТЗ с того, что беру фотографии мокапов из сессии проектирования и с помощью Sketch перевожу их в картинки. Можно немного поработать, чтобы они были красивые, можно забить, главное, чтобы в конце появился тот же самый набор экранов, которые были до этого нарисованы на бумажках.
После этого я создаю из них интерактивный прототип в Invision. Это нужно, потому что заказчикам обычно проще воспринимать интерактивную форму.
Помимо интерактивного прототипа я делаю большую презентацию, в которой структура следующая: одно изображение экрана, после — несколько страниц с описанием каждого элемента и того, что он делает. В конце идёт отдельный блок про серверную часть: в ней фиксируются важные элементы, связанные с быстродействием, безопасностью и прочими требованиями.
В финале я создаю формальное ТЗ в виде документа, который полностью копирует презентацию по смыслу. Его можно сделать приложением к договору.
После этой нудной работы у нас появляется полноценное описание цели. Три элемента — интерактивный прототип, презентация и текстовый документ — не дают шанса сказать кому-то из заинтересованных сторон оставаться непонятым — выбирай для осознания максимально удобный вариант.
Погоди. А где разработчики?
Очень хороший вопрос, который неплохо бы почаще задавать себе людям в агентствах. Дело в том, что до сих пор мы ни разу не привлекали разработчиков к процессу уточнения цели. Это очень и очень плохо — есть высокая вероятность, что всё нами сделанное не имеет никакого смысла, потому что это нельзя реализовать из-за бюджетных, временных или технических ограничений.
Я поклонник двух мыслей:
Кстати, вы можете поменять слово «разработчики» на «инженер» или «технический специалист» — смысл от этого не поменяется. Кто руками делает проект, тот и должен быть на всех этапах.
Небольшой подитог этих страниц:
Итак, вы сделали классную документацию и утвердили её со всеми. Настало время распланировать, что вы будете делать, чтобы достичь цели. После фиксирования цели попробуем уменьшить энтропию.
Если бы я мог нарисовать график правильной загруженности менеджера, то он выглядел бы как-то так:
Можете заметить, что во время планирования менеджер очень и очень занят — не меньше, чем на запуске. Это этап самый важный, потому что он напрямую влияет на количество сна у всей команды во время разработки и запуска. Если плохо спланировать проект, готовьтесь к весёлой прогулке по горящему лесу, где не только всё вокруг будет полыхать, но и ваша пятая точка круглые сутки будет близка к температуре плавления стали.
Я лично проходил через несколько проектов, где спать приходилось по два часа в день в течение месяца, и могу точно сказать — это всё из-за неграмотного планирования. Даже больше: грамотное планирование и средняя по профессионализму команда дадут лучший результат, чем плохое планирование и топовая команда.
Что нам надо сделать:
Это метод «от общего к частному», где схема строится от глобальных элементов к самым маленьким. PMBoK описывает несколько случаев декомпозиции: по процессам и по элементам. Честно говоря, мне ни разу не приходилось расписывать процессы с помощью декомпозиции, а вот функциональность — постоянно.
Для digital-проектов я обычно делаю две декомпозиции: одна описывает элементы, вторая описывает функции и логику. Можно разбить на фронтенд и бэкенд — тоже удобно. Главное правило — мы всегда начинаем с самого глобального элемента, например с «Главной страницы», и дальше идём вниз по элементам, строя большое дерево, где они все связаны.
Чтобы начать, мы берём прототип из предыдущего этапа и начинаем его раскладывать на составляющие части. Да, именно так просто: сначала записываем экраны, потом все экраны делим на блоки, потом все блоки на элементы. Вопрос — до какого момента нам следует это делать? Так ведь можно декомпозировать сайт до уровня такта процессора.
Ответ — настолько точно, чтобы мы могли каждый элемент поручить кому-то. В моём примере я знаю, какие вещи мне требовать с дизайнера (все составляющие Elements), что требовать с копирайтера (всё, что относится к Content — Text), что — от клиента (Content — Graphics). Лично мне неплохо бы вместе с программистами разобраться с логикой.
Та же декомпозиция будет чуть позже помогать нам проверять работу разработчиков на этапе приёмки — по ней удобно проходиться и чекать, что все элементы на сайте присутствуют.
Зачем это делать? Неочевидный плюс в том, что мы сами лучше начинаем понимать весь объём работ. Очевидный плюс — разделение на мелкие кусочки всего проекта помогает нам сделать хороший тайминг.
Когда пилот управляет самолётом, у него есть приборная панель, которая сообщает ему о состоянии судна. Когда менеджер проекта управляет ходом работ, у него есть тайминг, который сообщает ему всю необходимую информацию о текущем статусе проекта. Тайминг строится на основе декомпозиции и порядка работ, которые мы зафиксировали с командой.
Хорошо и правильно, когда тайминг подключён к таск-трекеру и из него видны все необходимые нам параметры: текущий статус задач, текущий этап, расход средств, загрузка ресурсов и прочее.
Я использую связку Instagantt и Asana, потому что Asana является нашим штатным таск-трекером, а Instagantt подключается к нему. В моём случае нет смысла контролировать такие метрики, как расход часов и загрузку ресурсов, так что нас всё устраивает. Решений для таймингов и таск-трекеров — вагон и маленькая тележка, выбирайте то, которое подходит вам.
Чтобы построить тайминг, мы берём все элементы из декомпозиции и заносим в таск-трекер. После расставляем ответственных, проверяем, что они согласны со сроками, и строим нашу диаграмму Ганта.
У нас получается большое полотно, в котором все элементы связаны друг с другом и им назначены ответственные. Удостоверьтесь, что все — и заказчик, и разработчики, и любые подрядчики согласны с этим таймингом. Это важно — все должны подписаться под ним.
Если ваши исполнители считают, что не уложатся в сроки — лучше обсудите с ними этот вопрос, потому что они точнее знают собственную производительность. Я не считаю правильным продавливать исполнителей по срокам или деньгам — в моей практике я выбираю их сам, следовательно, должен доверять их экспертизе. Всегда можно договориться о каких-то компромиссных решениях — например, сделать промежуточную сборку результата и показать её клиенту.
Все работы в тайминге должны быть связаны друг с другом — иначе это не диаграмма Ганта. Её плюс как раз в том, что она учитывает порядок работ: например, бэкенд можно начинать параллельно с дизайном, и он от него никак не зависит, но вот писать код фронтенд раньше получения макетов невозможно. Так что свяжите их корректно.
Как закончили с таймингом, можно переходить к очень полезной вещи — к риск-карте. Конечно, для стандартных проектов её можно не делать, но для любых проектов, где есть серьёзные риски, — это обязательно.
Риск-карта — это таблица, в которой указываются все риски, разбитые по категориям, их шанс случиться, урон для проекта, а также план по их нейтрализации.
Чтобы заполнить риск-карту, нужно собрать вашу команду и начать вместе с ней писать все возможные риски в рамках разумного. Начать можно с технических рисков, которые есть на любом сложном проекте, продолжить организационными (например, кто-то заболел). Прописывать шансы падения метеорита на Москву или высадки инопланетян в Нью-Йорке не стоит — это форс-мажоры.
Когда все риски записаны, мы назначаем им вероятность и урон. Вероятно, для этих элементов есть специальные формулы расчёта, но я устанавливаю эти числа субъективно.
После того как мы назначили степени для каждого риска, команда должна выработать планы А и Б (можно В и Д, лишним не бывает) для нивелирования этого риска. Все планы заносятся в таблицу. Мы получаем список рисков, отсортированный по степени урона проекту, и детальное описание планов по уменьшению степени влияния риска на проект.
Тайминг и риск-карта — это живые документы. Вы должны постоянно обращаться к ним, проверяя, как идёт проект и в каком статусе находятся риски. Это ваша панель управления — работайте с ними постоянно. Если появляются новые риски — заносите их в таблицу, если тайминг отклоняется от реального плана — обновите его и посмотрите, как вы будете компенсировать изменения.
На этом этапе у нас есть все составляющие хорошего плана:
Обо всём этом — во второй части, которую я напишу через неделю.
Советы по управлению проектами от бывшего руководителя отдела разработки агентства Friends Moscow Петра Фомичёва.
Про управление людьми очень хорошо сказал Егор Волков из компании Greensight: «Люди всегда всё портят. Они обещают и не делают. Или делают, но не так. Или так, но не то. Или то, но долго. Было бы здорово как-нибудь так построить бизнес, чтобы без людей».
Но без людей пока никак. И в бизнесе они ключевое место занимают, и проекты они же делают. Поэтому мне бы хотелось поделиться кое-каким опытом: последние четыре года я провёл в агентстве Friends Moscow, которое делает рекламу и рекламу классную. Я руководил отделом разработки и ведения digital-проектов.
Далее по тексту вы найдёте небольшие правила и порядок действий, который я вывел, воюя с обстоятельствами на всех фронтах и очень часто им проигрывая.
Материал вряд ли пригодится опытным суперменеджерам, которые и так всё знают назубок — я описываю очень простые, лёгкие и понятные правила, которые можно применять где угодно.
Заметки относятся к разработке сайтов, приложений и прочих цифровых проектов, но если применить немного фантазии, они легко адаптируются к любой ситуации.
Я обещаю, что не будет сложных инструментов — всё будет просто.
Энтропия? Я что, читаю vc.ru ради умных слов?
Энтропия — это то, что разрушает все наши замыслы. Чтобы попасть на тренировку к 10:00, мне надо встать хотя бы в 8:30. Я уверенно ложусь спать в 1 час ночи — без тени сомнений, что завтра в 10 тренер будет ругаться за то, что я опять пил на выходных и поэтому бью троечку слишком медленно. Всё спланировано, и Google Home готов разбудить меня вовремя. Угадайте, кто незаметно для себя во сне отключает будильник?
Или другой пример — вы собираетесь в отпуск с девушкой, уже всё готово и куплены билеты, но вдруг она звонит и говорит, что вам нужно расстаться. Внешний фактор разрушает все ваши дальнейшие планы.
Вселенная целиком и полностью полагается на энтропию — это базовый элемент, она повсюду. И всё, что мы можем делать, — лишь стараться уменьшать элементы случайности.
Человечество только этим и занимается: мы научились выращивать пшеницу, чтобы не зависеть от плодов в лесах, потом одомашнили коров, ибо не набегаешься за ними по всей округе. Приручили собак, чтобы они управляли стадом. И так далее, вплоть до стабильной работы с 9 до 17 с часовым перерывом на веганский обед.
Менеджер проекта управляет людьми — а ничего более энтропичного, пожалуй, не существует. Помимо энтропии, которая создаётся людьми, есть множество внешних факторов, словно сговорившихся сбить вас с пути.
Тут мы приходим к двум важным пунктам:
- Любой проект преследует цель. Это может быть отпуск, запуск сайта, продукта или просто печать плакатов. Проект нужен, чтобы достичь цели.
- Достижению цели будет мешать примерно всё. Бюджетные, временные, технические ограничения, а также внутренние, которые создают люди, неизменно участвующие в процессе.
Вам необходимо зрегистрироваться для просмотра ссылок
, но у меня будет короче, понятнее и ближе к реальности.Учимся рисовать
Как это обычно случается — к вам приходит коллега, заказчик или друг и произносит сакральную фразу: «Слушай, я тут подумал, и мне пришла в голову идея...». После следует описание, которое может быть любым: от продуманного плана до полного фарша из мыслей.
Если у вас нет шанса спастись и пойти кормить соек с лучшей девушкой в этом городе — с этой секунды для вас начинается проект.
Сначала необходимо разобраться, что же мы делаем — уточнить цель. Умные дяди в крутых книжках называют это «собрать требования заказчика». Заказчиком для нас выступает тот, кто хочет достичь цели — это можем быть даже мы сами, если проект личный. Заказчиков может быть много, например, целый бизнес-юнит крупной корпорации. Но всё же обычно, это от двух до пяти человек.
Применительно к digital-проектам я крайне редко встречал ситуацию, в которой бы заказчик представлял себе финальный результат в подробностях. Обычно вводные выглядят как «мы хотим сайт и чтобы там всё летало». Есть отличный способ организовать любое количество заказчиков и буквально за несколько часов зафиксировать требования к проекту.
Надо «всего лишь» собрать их в одной комнате, где есть большая доска и фломастеры. С этой секунды мы можем начать проектирование.
Для этого мы рисуем наш сайт или приложение по экранам, начиная с самого первого, и вместе с заказчиками представляем, как он должен работать. После мы связываем все экраны стрелочками. Мы рисуем каждую кнопку, каждый слайдер и каждый блок текста, а также то, куда он ведёт. Отдельно прописываем, почему он здесь. Очень важный момент тут ровно один — мы представляем, как проект должен работать.
На этом этапе мы не занимаемся UX-проектированием, мы не рисуем дизайн — мы всего лишь в визуальной форме записываем всю функциональность, которая должна быть у проекта.
Важно пресекать желание участников поразмышлять над цветами кнопок: мы должны несколько часов представлять себе, как всё должно работать, и нарисовать структуру функциональности, но не более того. Вас не должна отпугивать призрачная лёгкость этого метода — на самом деле вытянуть из заказчиков все важные функции и ничего не забыть, а также разложить это по полочкам в их головах не так уж просто.
Я проделывал этот простой трюк со всеми: с креативными командами, в крупных корпорациях, в стартапах на начальной стадии, и всегда люди выходили с ясной картинкой проекта в голове. Он превращался из миража в понятную структуру.
И если мы всё сделали правильно, то в конце подобной «детской» сессии проектирования у нас на руках окажется большой и некрасивый мокап проекта, в котором учтены пожелания всех заинтересованных сторон. Не страшно, что он выглядит как наскальная живопись — мы скоро это исправим.
Делаем крутое ТЗ
Техническое задание критически важно. Думаю, после этой фразы поклонники Agile уже начали собирать валежник для костра, чтобы меня сжечь, но тут всё просто: есть продукты, в которых итерационная разработка является необходимостью, а есть проекты, где нужно получить конкретный результат в конкретный срок и не более того. Надо знать, где и что корректно применять.
Техническое задание в моём понимании — это лишь формальное описание цели, которую мы хотим достигнуть. Оно может выполняться в любой удобной для вас форме. Я предпочитаю презентацию и интерактивный прототип, которые сопровождает документ с подробностями, но вы вольны использовать другие методы, лишь бы они скрепляли все стороны одной целью: и заказчиков, и ваших разработчиков, и самое главное — вас самих.
Это вам больше всех надо знать, куда же мы хотим приплыть, потому что за это вам платят деньги.
Расскажу простой пример: в самом начале карьеры меня подключили к созданию внутреннего проекта. Туда позвали очень хорошую студию, и я по неопытности решил, что ребята сделают всё сами — они же одни из лучших специалистов на рынке. Поэтому я решил отказаться от написания ТЗ и почти всё фиксировал на словах.
Загадка: сколько реализовывался проект, на который было отведено 3 месяца?
Ответ: провальный проект без ТЗ, но с очень крутой студией вместо трёх месяцев занял полтора года, и при этом не вся функциональность была реализована.
Я начинаю написание ТЗ с того, что беру фотографии мокапов из сессии проектирования и с помощью Sketch перевожу их в картинки. Можно немного поработать, чтобы они были красивые, можно забить, главное, чтобы в конце появился тот же самый набор экранов, которые были до этого нарисованы на бумажках.
После этого я создаю из них интерактивный прототип в Invision. Это нужно, потому что заказчикам обычно проще воспринимать интерактивную форму.
Помимо интерактивного прототипа я делаю большую презентацию, в которой структура следующая: одно изображение экрана, после — несколько страниц с описанием каждого элемента и того, что он делает. В конце идёт отдельный блок про серверную часть: в ней фиксируются важные элементы, связанные с быстродействием, безопасностью и прочими требованиями.
В финале я создаю формальное ТЗ в виде документа, который полностью копирует презентацию по смыслу. Его можно сделать приложением к договору.
После этой нудной работы у нас появляется полноценное описание цели. Три элемента — интерактивный прототип, презентация и текстовый документ — не дают шанса сказать кому-то из заинтересованных сторон оставаться непонятым — выбирай для осознания максимально удобный вариант.
Погоди. А где разработчики?
Очень хороший вопрос, который неплохо бы почаще задавать себе людям в агентствах. Дело в том, что до сих пор мы ни разу не привлекали разработчиков к процессу уточнения цели. Это очень и очень плохо — есть высокая вероятность, что всё нами сделанное не имеет никакого смысла, потому что это нельзя реализовать из-за бюджетных, временных или технических ограничений.
Я поклонник двух мыслей:
- Менеджер проекта, если он руководит разработкой, должен уметь кодить. Он не должен уметь писать продакшн-код, но он должен находиться на уровне, когда сам может залезть в документацию к API, посмотреть методы и что-то уточнить. Менеджер должен не только понимать, как строится разработка и что значит писать код, но и осознавать, как мыслят программисты: это значительно улучшит коммуникацию с ними. Я полностью понимаю компании, когда они нанимают менеджеров проектов с техническим образованием. И не очень понимаю те организации, которые сажают в кресла проект-менеджера кого ни попадя.
- Разработчиков нужно привлекать к обсуждению и планированию проекта как можно раньше. Не стоит думать, что разработчики дураки и ничего не понимают в бизнес-задачах — чем раньше они начнут помогать продумывать техническую сторону вопроса, тем больше времени будет сэкономлено на следующих шагах. Круто, если вы можете приглашать хотя бы одного программиста на сессии проектирования и советоваться с ним в процессе написания документации. Имея такую возможность, пользуйтесь ей постоянно. К сожалению, во многих компаниях это невозможно, поэтому смотри пункт первый — вы должны сами разбираться в технической области ровно настолько, сколько требуется для принятия взвешенных решений о функциональности.
Кстати, вы можете поменять слово «разработчики» на «инженер» или «технический специалист» — смысл от этого не поменяется. Кто руками делает проект, тот и должен быть на всех этапах.
Небольшой подитог этих страниц:
- Очень важно зафиксировать цель настолько точно, насколько это возможно. Добивайтесь этого всеми возможными методами.
- Проведите сессию проектирования со всеми заказчиками — от вас не убудет.
- Пишите такую документацию, которая была бы понятна даже ребёнку, и дублируйте её в разных форматах — от простейшего к формальному. Это ваша работа убедиться в том, что все всё поняли и со всем согласны.
- Приглашайте разработчиков на любой из этих этапов, если это возможно, и пользуйтесь их советами.
Итак, вы сделали классную документацию и утвердили её со всеми. Настало время распланировать, что вы будете делать, чтобы достичь цели. После фиксирования цели попробуем уменьшить энтропию.
Если бы я мог нарисовать график правильной загруженности менеджера, то он выглядел бы как-то так:
Можете заметить, что во время планирования менеджер очень и очень занят — не меньше, чем на запуске. Это этап самый важный, потому что он напрямую влияет на количество сна у всей команды во время разработки и запуска. Если плохо спланировать проект, готовьтесь к весёлой прогулке по горящему лесу, где не только всё вокруг будет полыхать, но и ваша пятая точка круглые сутки будет близка к температуре плавления стали.
Я лично проходил через несколько проектов, где спать приходилось по два часа в день в течение месяца, и могу точно сказать — это всё из-за неграмотного планирования. Даже больше: грамотное планирование и средняя по профессионализму команда дадут лучший результат, чем плохое планирование и топовая команда.
Что нам надо сделать:
- Декомпозицию проекта. Она разделит нашего огромного слона на множество мелких кусочков для удобства употребления в пищу.
- Нормальный тайминг, который будет сообщать нам о статусе проекта, а не являться бронзовой статуей нашему разгильдяйству.
- Риск-карту, которая поможет нам определиться с узкими местами и понять, как мы будем их решать.
- Опционально — посчитать бюджет и сделать смету. Не во всех компаниях это требуется, а где требуется — всё по-разному выглядит, поэтому оставим этот момент за бортом. Думаю, вы и сами знаете, как вам выделяют ресурсы.
Это метод «от общего к частному», где схема строится от глобальных элементов к самым маленьким. PMBoK описывает несколько случаев декомпозиции: по процессам и по элементам. Честно говоря, мне ни разу не приходилось расписывать процессы с помощью декомпозиции, а вот функциональность — постоянно.
Для digital-проектов я обычно делаю две декомпозиции: одна описывает элементы, вторая описывает функции и логику. Можно разбить на фронтенд и бэкенд — тоже удобно. Главное правило — мы всегда начинаем с самого глобального элемента, например с «Главной страницы», и дальше идём вниз по элементам, строя большое дерево, где они все связаны.
Чтобы начать, мы берём прототип из предыдущего этапа и начинаем его раскладывать на составляющие части. Да, именно так просто: сначала записываем экраны, потом все экраны делим на блоки, потом все блоки на элементы. Вопрос — до какого момента нам следует это делать? Так ведь можно декомпозировать сайт до уровня такта процессора.
Ответ — настолько точно, чтобы мы могли каждый элемент поручить кому-то. В моём примере я знаю, какие вещи мне требовать с дизайнера (все составляющие Elements), что требовать с копирайтера (всё, что относится к Content — Text), что — от клиента (Content — Graphics). Лично мне неплохо бы вместе с программистами разобраться с логикой.
Та же декомпозиция будет чуть позже помогать нам проверять работу разработчиков на этапе приёмки — по ней удобно проходиться и чекать, что все элементы на сайте присутствуют.
Зачем это делать? Неочевидный плюс в том, что мы сами лучше начинаем понимать весь объём работ. Очевидный плюс — разделение на мелкие кусочки всего проекта помогает нам сделать хороший тайминг.
Когда пилот управляет самолётом, у него есть приборная панель, которая сообщает ему о состоянии судна. Когда менеджер проекта управляет ходом работ, у него есть тайминг, который сообщает ему всю необходимую информацию о текущем статусе проекта. Тайминг строится на основе декомпозиции и порядка работ, которые мы зафиксировали с командой.
Хорошо и правильно, когда тайминг подключён к таск-трекеру и из него видны все необходимые нам параметры: текущий статус задач, текущий этап, расход средств, загрузка ресурсов и прочее.
Я использую связку Instagantt и Asana, потому что Asana является нашим штатным таск-трекером, а Instagantt подключается к нему. В моём случае нет смысла контролировать такие метрики, как расход часов и загрузку ресурсов, так что нас всё устраивает. Решений для таймингов и таск-трекеров — вагон и маленькая тележка, выбирайте то, которое подходит вам.
Чтобы построить тайминг, мы берём все элементы из декомпозиции и заносим в таск-трекер. После расставляем ответственных, проверяем, что они согласны со сроками, и строим нашу диаграмму Ганта.
У нас получается большое полотно, в котором все элементы связаны друг с другом и им назначены ответственные. Удостоверьтесь, что все — и заказчик, и разработчики, и любые подрядчики согласны с этим таймингом. Это важно — все должны подписаться под ним.
Если ваши исполнители считают, что не уложатся в сроки — лучше обсудите с ними этот вопрос, потому что они точнее знают собственную производительность. Я не считаю правильным продавливать исполнителей по срокам или деньгам — в моей практике я выбираю их сам, следовательно, должен доверять их экспертизе. Всегда можно договориться о каких-то компромиссных решениях — например, сделать промежуточную сборку результата и показать её клиенту.
Все работы в тайминге должны быть связаны друг с другом — иначе это не диаграмма Ганта. Её плюс как раз в том, что она учитывает порядок работ: например, бэкенд можно начинать параллельно с дизайном, и он от него никак не зависит, но вот писать код фронтенд раньше получения макетов невозможно. Так что свяжите их корректно.
Как закончили с таймингом, можно переходить к очень полезной вещи — к риск-карте. Конечно, для стандартных проектов её можно не делать, но для любых проектов, где есть серьёзные риски, — это обязательно.
Риск-карта — это таблица, в которой указываются все риски, разбитые по категориям, их шанс случиться, урон для проекта, а также план по их нейтрализации.
Чтобы заполнить риск-карту, нужно собрать вашу команду и начать вместе с ней писать все возможные риски в рамках разумного. Начать можно с технических рисков, которые есть на любом сложном проекте, продолжить организационными (например, кто-то заболел). Прописывать шансы падения метеорита на Москву или высадки инопланетян в Нью-Йорке не стоит — это форс-мажоры.
Когда все риски записаны, мы назначаем им вероятность и урон. Вероятно, для этих элементов есть специальные формулы расчёта, но я устанавливаю эти числа субъективно.
После того как мы назначили степени для каждого риска, команда должна выработать планы А и Б (можно В и Д, лишним не бывает) для нивелирования этого риска. Все планы заносятся в таблицу. Мы получаем список рисков, отсортированный по степени урона проекту, и детальное описание планов по уменьшению степени влияния риска на проект.
Тайминг и риск-карта — это живые документы. Вы должны постоянно обращаться к ним, проверяя, как идёт проект и в каком статусе находятся риски. Это ваша панель управления — работайте с ними постоянно. Если появляются новые риски — заносите их в таблицу, если тайминг отклоняется от реального плана — обновите его и посмотрите, как вы будете компенсировать изменения.
На этом этапе у нас есть все составляющие хорошего плана:
- У нас есть отличное ТЗ, которое со всеми согласовано и всеми принято.
- У нас есть декомпозиция проекта, которая разделила его на много мелких частей.
- Каждый элемент, полученный во время декомпозиции, добавлен в таск-трекер и тайминг, зафиксирован за исполнителем и ждёт своего часа.
- А риск-карта позволяет нам управлять рисками проекта и понимать, какие неожиданные ситуации ждут нас в будущем.
Обо всём этом — во второй части, которую я напишу через неделю.
