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

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

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

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

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

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

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

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

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

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

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

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

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

Приручили собак, чтобы они управляли стадом. Человечество только этим и занимается: мы научились выращивать пшеницу, чтобы не зависеть от плодов в лесах, потом одомашнили коров, ибо не набегаешься за ними по всей округе. И так далее, вплоть до стабильной работы с 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.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Альтернативы основным сервисам Google

Потратив полгода изучение аналогов, в июле 2018 года он заявил, что «теперь свободен от Google». Журналист и исследователь Нитин Кока (Nithin Coca) решил полностью отказаться от продуктов Google, заменив их на альтернативные сервисы. В 2011 году он проводил похожий эксперимент ...

Почему средневековая Европа опередила Китай и Ближний Восток в развитии науки и технологий

За пару десятилетий телескопы из Европы добрались до Китая, индийской империи Великих Моголов и Османской империи. В 1608 году Ханс Липперсгей, мастер по изготовлению очков из голландского города Мидделбурга, изобрел телескоп. Следовательно, все четыре цивилизации оказались в равных условиях с ...