Peter Fomichev
6 633
Блоги

Как делать проекты, не стреляя себе в ногу

Советы по управлению проектами от бывшего руководителя отдела разработки агентства Friends Moscow Петра Фомичёва.

Поделиться

В избранное

В избранном

Про управление людьми очень хорошо сказал Егор Волков из компании Greensight: «Люди всегда всё портят. Они обещают и не делают. Или делают, но не так. Или так, но не то. Или то, но долго. Было бы здорово как-нибудь так построить бизнес, чтобы без людей».

Но без людей пока никак. И в бизнесе они ключевое место занимают, и проекты они же делают. Поэтому мне бы хотелось поделиться кое-каким опытом: последние четыре года я провёл в агентстве Friends Moscow, которое делает рекламу и рекламу классную. Я руководил отделом разработки и ведения digital-проектов.

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

Далее по тексту вы найдёте небольшие правила и порядок действий, который я вывел, воюя с обстоятельствами на всех фронтах и очень часто им проигрывая.

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

Заметки относятся к разработке сайтов, приложений и прочих цифровых проектов, но если применить немного фантазии, они легко адаптируются к любой ситуации.

Я обещаю, что не будет сложных инструментов — всё будет просто.

Энтропия? Я что, читаю vc.ru ради умных слов?

Энтропия — это то, что разрушает все наши замыслы. Чтобы попасть на тренировку к 10:00, мне надо встать хотя бы в 8:30. Я уверенно ложусь спать в 1 час ночи — без тени сомнений, что завтра в 10 тренер будет ругаться за то, что я опять пил на выходных и поэтому бью троечку слишком медленно. Всё спланировано, и Google Home готов разбудить меня вовремя. Угадайте, кто незаметно для себя во сне отключает будильник?

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

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

Человечество только этим и занимается: мы научились выращивать пшеницу, чтобы не зависеть от плодов в лесах, потом одомашнили коров, ибо не набегаешься за ними по всей округе. Приручили собак, чтобы они управляли стадом. И так далее, вплоть до стабильной работы с 9 до 17 с часовым перерывом на веганский обед.

Менеджер проекта управляет людьми — а ничего более энтропичного, пожалуй, не существует. Помимо энтропии, которая создаётся людьми, есть множество внешних факторов, словно сговорившихся сбить вас с пути.

Тут мы приходим к двум важным пунктам:

  1. Любой проект преследует цель. Это может быть отпуск, запуск сайта, продукта или просто печать плакатов. Проект нужен, чтобы достичь цели.
  2. Достижению цели будет мешать примерно всё. Бюджетные, временные, технические ограничения, а также внутренние, которые создают люди, неизменно участвующие в процессе.

Все действия, которые описываются ниже, решают всего две задачи: они максимально уточняют и фиксируют цель, а дальше они уменьшают энтропию, которая грозится разорвать в клочья все наши планы. Большая часть этих действий подробно описана в стандарте PMBoK, но у меня будет короче, понятнее и ближе к реальности.

Учимся рисовать

Как это обычно случается — к вам приходит коллега, заказчик или друг и произносит сакральную фразу: «Слушай, я тут подумал, и мне пришла в голову идея...». После следует описание, которое может быть любым: от продуманного плана до полного фарша из мыслей.

Если у вас нет шанса спастись и пойти кормить соек с лучшей девушкой в этом городе — с этой секунды для вас начинается проект.

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

Применительно к digital-проектам я крайне редко встречал ситуацию, в которой бы заказчик представлял себе финальный результат в подробностях. Обычно вводные выглядят как «мы хотим сайт и чтобы там всё летало». Есть отличный способ организовать любое количество заказчиков и буквально за несколько часов зафиксировать требования к проекту.

Надо «всего лишь» собрать их в одной комнате, где есть большая доска и фломастеры. С этой секунды мы можем начать проектирование.

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

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

Важно пресекать желание участников поразмышлять над цветами кнопок: мы должны несколько часов представлять себе, как всё должно работать, и нарисовать структуру функциональности, но не более того. Вас не должна отпугивать призрачная лёгкость этого метода — на самом деле вытянуть из заказчиков все важные функции и ничего не забыть, а также разложить это по полочкам в их головах не так уж просто.

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

Я проделывал этот простой трюк со всеми: с креативными командами, в крупных корпорациях, в стартапах на начальной стадии, и всегда люди выходили с ясной картинкой проекта в голове. Он превращался из миража в понятную структуру.

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

Делаем крутое ТЗ

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

Техническое задание в моём понимании — это лишь формальное описание цели, которую мы хотим достигнуть. Оно может выполняться в любой удобной для вас форме. Я предпочитаю презентацию и интерактивный прототип, которые сопровождает документ с подробностями, но вы вольны использовать другие методы, лишь бы они скрепляли все стороны одной целью: и заказчиков, и ваших разработчиков, и самое главное — вас самих.

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

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

Загадка: сколько реализовывался проект, на который было отведено 3 месяца?

Ответ: провальный проект без ТЗ, но с очень крутой студией вместо трёх месяцев занял полтора года, и при этом не вся функциональность была реализована.

Я начинаю написание ТЗ с того, что беру фотографии мокапов из сессии проектирования и с помощью Sketch перевожу их в картинки. Можно немного поработать, чтобы они были красивые, можно забить, главное, чтобы в конце появился тот же самый набор экранов, которые были до этого нарисованы на бумажках.

После этого я создаю из них интерактивный прототип в Invision. Это нужно, потому что заказчикам обычно проще воспринимать интерактивную форму.

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

Бесконечная презентация о том, как должен работать проект.

В финале я создаю формальное ТЗ в виде документа, который полностью копирует презентацию по смыслу. Его можно сделать приложением к договору.

Кусочек ТЗ для проекта с видеотрансляцией. Дальше его используют в качестве приложения к договору

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

Погоди. А где разработчики?

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

Я поклонник двух мыслей:

  1. Менеджер проекта, если он руководит разработкой, должен уметь кодить. Он не должен уметь писать продакшн-код, но он должен находиться на уровне, когда сам может залезть в документацию к API, посмотреть методы и что-то уточнить. Менеджер должен не только понимать, как строится разработка и что значит писать код, но и осознавать, как мыслят программисты: это значительно улучшит коммуникацию с ними. Я полностью понимаю компании, когда они нанимают менеджеров проектов с техническим образованием. И не очень понимаю те организации, которые сажают в кресла проект-менеджера кого ни попадя.
  2. Разработчиков нужно привлекать к обсуждению и планированию проекта как можно раньше. Не стоит думать, что разработчики дураки и ничего не понимают в бизнес-задачах — чем раньше они начнут помогать продумывать техническую сторону вопроса, тем больше времени будет сэкономлено на следующих шагах. Круто, если вы можете приглашать хотя бы одного программиста на сессии проектирования и советоваться с ним в процессе написания документации. Имея такую возможность, пользуйтесь ей постоянно. К сожалению, во многих компаниях это невозможно, поэтому смотри пункт первый — вы должны сами разбираться в технической области ровно настолько, сколько требуется для принятия взвешенных решений о функциональности.

Вы зададите резонный вопрос — у нас нет разработчиков в штате, они все на аутсорсе, как же быть? Но неужели вы считаете, что в аутсорс-компаниях работают нелюди? Велика вероятность, что там сидят точно такие же профессионалы, как вы, и они заинтересованы в результате не меньше вашего, поэтому с радостью подключатся к обсуждению и внесению правок. Если нет — задумайтесь о смене аутсорсера.

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

Небольшой подытог этих страниц:

  • Очень важно зафиксировать цель настолько точно, насколько это возможно. Добивайтесь этого всеми возможными методами.
  • Проведите сессию проектирования со всеми заказчиками — от вас не убудет.
  • Пишите такую документацию, которая была бы понятна даже ребёнку, и дублируйте её в разных форматах — от простейшего к формальному. Это ваша работа убедиться в том, что все всё поняли и со всем согласны.
  • Приглашайте разработчиков на любой из этих этапов, если это возможно, и пользуйтесь их советами.

Ахиллесова пята всех проектов

Итак, вы сделали классную документацию и утвердили её со всеми. Настало время распланировать, что вы будете делать, чтобы достичь цели. После фиксирования цели попробуем уменьшить энтропию.

Если бы я мог нарисовать график правильной загруженности менеджера, то он выглядел бы как-то так:

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

Я лично проходил через несколько проектов, где спать приходилось по два часа в день в течение месяца, и могу точно сказать — это всё из-за неграмотного планирования. Даже больше: грамотное планирование и средняя по профессионализму команда дадут лучший результат, чем плохое планирование и топовая команда.

Что нам надо сделать:

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

Декомпозиция выглядит так:

Это метод «от общего к частному», где схема строится от глобальных элементов к самым маленьким. PMBoK описывает несколько случаев декомпозиции: по процессам и по элементам. Честно говоря, мне ни разу не приходилось расписывать процессы с помощью декомпозиции, а вот функциональность — постоянно.

Для digital-проектов я обычно делаю две декомпозиции: одна описывает элементы, вторая описывает функции и логику. Можно разбить на фронтенд и бэкенд — тоже удобно. Главное правило — мы всегда начинаем с самого глобального элемента, например с «Главной страницы», и дальше идём вниз по элементам, строя большое дерево, где они все связаны.

Декомпозиция какого-то старого проекта. Здесь от глобального элемента Landing page исходят следующие области: “Elements”, перечисляющая все элементы на страницы, “Content”, перечисляющая все элементы контента, и “Mechanics”, включающая в себя особые элементы логики. Я делаю декомпозицию в XMind, но это олдскул, и есть облачные решения.

Чтобы начать, мы берём прототип из предыдущего этапа и начинаем его раскладывать на составляющие части. Да, именно так просто: сначала записываем экраны, потом все экраны делим на блоки, потом все блоки на элементы. Вопрос — до какого момента нам следует это делать? Так ведь можно декомпозировать сайт до уровня такта процессора.

Ответ — настолько точно, чтобы мы могли каждый элемент поручить кому-то. В моём примере я знаю, какие вещи мне требовать с дизайнера (все составляющие Elements), что требовать с копирайтера (всё, что относится к Content — Text), что — от клиента (Content — Graphics). Лично мне неплохо бы вместе с программистами разобраться с логикой.

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

Зачем это делать? Неочевидный плюс в том, что мы сами лучше начинаем понимать весь объём работ. Очевидный плюс — разделение на мелкие кусочки всего проекта помогает нам сделать хороший тайминг.

Когда пилот управляет самолётом, у него есть приборная панель, которая сообщает ему о состоянии судна. Когда менеджер проекта управляет ходом работ, у него есть тайминг, который сообщает ему всю необходимую информацию о текущем статусе проекта. Тайминг строится на основе декомпозиции и порядка работ, которые мы зафиксировали с командой.

Хорошо и правильно, когда тайминг подключён к таск-трекеру и из него видны все необходимые нам параметры: текущий статус задач, текущий этап, расход средств, загрузка ресурсов и прочее.

Я использую связку Instagantt и Asana, потому что Asana является нашим штатным таск-трекером, а Instagantt подключается к нему. В моём случае нет смысла контролировать такие метрики, как расход часов и загрузку ресурсов, так что нас всё устраивает. Решений для таймингов и таск-трекеров — вагон и маленькая тележка, выбирайте то, которое подходит вам.

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

Упс, похоже, что-то идёт не так — таски горят красным! Да и ещё ни один не зафиксирован за исполнителем — совсем беда

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

Если ваши исполнители считают, что не уложатся в сроки — лучше обсудите с ними этот вопрос, потому что они точнее знают собственную производительность. Я не считаю правильным продавливать исполнителей по срокам или деньгам — в моей практике я выбираю их сам, следовательно, должен доверять их экспертизе. Всегда можно договориться о каких-то компромиссных решениях — например, сделать промежуточную сборку результата и показать её клиенту.

Все работы в тайминге должны быть связаны друг с другом — иначе это не диаграмма Ганта. Её плюс как раз в том, что она учитывает порядок работ: например, бэкенд можно начинать параллельно с дизайном, и он от него никак не зависит, но вот писать код фронтенд раньше получения макетов невозможно. Так что свяжите их корректно.

Как закончили с таймингом, можно переходить к очень полезной вещи — к риск-карте. Конечно, для стандартных проектов её можно не делать, но для любых проектов, где есть серьёзные риски, — это обязательно.

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

Очень много do nothing — похоже, мы изрядно ленивы

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

Когда все риски записаны, мы назначаем им вероятность и урон. Вероятно, для этих элементов есть специальные формулы расчёта, но я устанавливаю эти числа субъективно.

После того как мы назначили степени для каждого риска, команда должна выработать планы А и Б (можно В и Д, лишним не бывает) для нивелирования этого риска. Все планы заносятся в таблицу. Мы получаем список рисков, отсортированный по степени урона проекту, и детальное описание планов по уменьшению степени влияния риска на проект.

Тайминг и риск-карта — это живые документы. Вы должны постоянно обращаться к ним, проверяя, как идёт проект и в каком статусе находятся риски. Это ваша панель управления — работайте с ними постоянно. Если появляются новые риски — заносите их в таблицу, если тайминг отклоняется от реального плана — обновите его и посмотрите, как вы будете компенсировать изменения.

На этом этапе у нас есть все составляющие хорошего плана:

  • У нас есть отличное ТЗ, которое со всеми согласовано и всеми принято.
  • У нас есть декомпозиция проекта, которая разделила его на много мелких частей.
  • Каждый элемент, полученный во время декомпозиции, добавлен в таск-трекер и тайминг, зафиксирован за исполнителем и ждёт своего часа.
  • А риск-карта позволяет нам управлять рисками проекта и понимать, какие неожиданные ситуации ждут нас в будущем.

Мы, наконец, доделали нашу панель управления. Но как мы будем использовать всё это? Может ли менеджер после планирования уезжать в отпуск — ведь график загруженности тонко намекает на это? Разорвут ли обстоятельства наш проект?

Обо всём этом — во второй части, которую я напишу через неделю.

И если вдруг у вас есть желание предложить мне работу, то можно писать в Facebook или на почту: lastfreeusername@yandex.ru.

{ "author_name": "Peter Fomichev", "author_type": "self", "tags": [], "comments": 42, "likes": 64, "favorites": 135, "is_advertisement": false, "section_name": "blog", "id": "41104", "is_wide": "" }
{ "is_needs_advanced_access": false }

Комментарии Комм.

Популярные

По порядку

0

Прямой эфир

Подписаться на push-уведомления
[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } } ]