КУРС ПО УПРАВЛЕНИЮ ПРОЕКТАМИ
Урок 4. Реализация
Переходим к действию: что делать, если все идет не по плану, как контролировать сроки запуска и объем задач, которые нужно выполнить.
Если что-то идет не по плану, часто проектный менеджмент заканчивается и начинается хаос. Это признак неопытного руководителя проекта и негибкой системы работы. Если это ваш первый проект, хаос неизбежен, но со временем несложно научиться его контролировать. В этом уроке мы обсудим, как выстраивать системную работу в условиях неопределенности, быть гибким и флексить скоуп задач (что это значит — узнаете из урока).
Вася выяснил, что для работы клуба нужно зарегистрироваться в администрации и договориться со студсоветом о выделении средств на операционные расходы и аудиторий для занятий. Ещё Вася узнал, что студсовет перераспределяет бюджет на семестр вперед на ближайшем заседании через два дня, Надо прийти на заседание с презентацией про идею дебат-клуба, и быстро уведомить администрацию.
Системы для проектов, в которых ничего не понятно
В прошлом уроке мы обсудили, как прогнозировать и контролировать работу в предсказуемых проектах. К сожалению, чаще всего проектная работа проходит вслепую, без стандартов, законов и лучших практик. Особенно часто это касается разработки принципиально нового программного обеспечения или дизайна, ещё интернет-маркетинга и запуска онлайн-сервисов. В таких проектах нужно быть гибким, постоянно собирать обратную связь, и никто точно не знает, каким будет результат. Зато все знают, какую проблему решает проект и какую пользу нужно донести до аудитории.
Итеративные методы
В IT существуют два классических подхода к управлению проектами — каскадный и итерационный. Первый — более старый, каскадный (еще говорят Waterfall или Водопад) — это система управления проектами, которая была стандартом в мире IT до начала двухтысячных. По принципу Водопада шла разработка большинства классических приложений и операционных систем. Водопад предполагает цепочку взаимосвязанных процессов, выстроенных в определенном порядке. Переходить к следующей стадии нельзя, пока не выполнили предыдущую. Принцип похож на PERT и метод критического пути из прошлого урока.
Проблема Водопада — отсутствие гибкости. При таком подходе сложно собирать обратную связь и создавать прототипы. Даже на первую рабочую версию программы по Водопаду нужно потратить всё доступное время и ресурсы. В итоге проекта может получиться программа, которой неудобно пользоваться. Она будет готова функционально, но не подойдёт большинству пользователей и не поможет решить их проблемы.
Посмотрите пример диаграммы проекта, построенную по принципу водопада
Недостатки каскадной модели управления выявили в 70-х и придумали новую систему разработки. Она продолжает эволюционировать до сих пор, но основа всех моделей — работа итерациями. То есть, небольшие шаги к результату с постоянной обратной связью от клиента или аудитории. В конце каждого шага получается полноценный и работоспособный продукт или самостоятельная функциональная часть продукта. В следующем шаге её улучшают и добавляют новые работающие элементы. Так получается быстро создать рабочий прототип и постепенно доводить его до максимального качества.
Сравнение гибкого подхода и Водопада
Так, Васе в своем проекте важно постоянно общаться с членами клуба и получать от них отзывы — что проходит хорошо, а что нужно доработать, чтобы они не бросили занятия. Также ему следует общаться со спикерами, чтобы понять, как сделать их выступления более комфортными, информативными и полезными. Если Вася не будет общаться с администрацией, спикерами и участниками клуба, у него не получится сделать хороший проект и на мероприятия никто не будет ходить.
Дополнительный материал
Почитайте статью про историю и философию Agile. Она определяет не только подход к планированию, но и подход к работе в команде.
Каскадная модель
В каскадной модели этапы следуют одни за другим: сначала готовим требования, потом проектируем, и так до последнего этапа.
Преимущества каскадной модели:
☞ Контроль над временем и бюджетом
☞Предсказуемое распределение усилий и ресурсов во время работы
☞ Независимость процессов: разработка не начнется без дизайна и аналитики, каждый процесс может выполнить отдельный подрядчик.
☞ Не требует участия и контроля стейкхолдеров, регулярных циклов тестирования с клиентами.
☞ Удобно отчитываться за каждый этап работы по отдельности.
☞ Фокус на проекте: главное, чтобы все процессы прошли эффективно, завершились вовремя и затратили предсказуемое количество ресурсов.
Пример проекта для которого актуальна каскадная модель — строительство дома. В этом случае все этапы известны заранее и значительных изменений быть не должно. Работа идет последовательно: план здания, подготовка, стройка, отделка.
Итеративная модель
В итеративной модели этапы идут по кругу и влияют друг на друга
Преимущества итеративной модели:
☞ Быстрый результат — прототип или минимально рабочая версия
☞ Концентрация на самом важном и регулярная переоценка приоритетов
☞ Возможность менять требования к проекту в любое время
☞ Снижение рисков: ошибки на всех стадиях проекта быстро выявляются на тестировании
☞ Эффективная работа с обратной связью от всех стейкхолдеров: результаты согласуются регулярно, не только в конце проекта.
☞ Фокус на продукте: главное, чтобы всё работало и результат нес пользу вне зависимости от изначальных требований
Пример проекта для которого актуальна итеративная модель — интернет-магазин. В этом случае можно быстро запустить первую версию, сделать первые продажи, получить обратную связь от клиентов и на её основе дорабатывать проект.
Дополнительный материал
Посмотрите лекцию Олега Ткаченкова о разнице между гибкими методологиями и классическим водопадным планированием.
Гибкость
Постепенно итеративные методы проектного менеджмента начинают эволюционировать и обрастать новыми артефактами. Самый часто применяемый сегодня набор методов, основанных на итерациях, объединяется под ярлыком agile, то есть, «гибкий». Основное нововведение гибких методов разработки — выстраивание доверительных отношений с заказчиком. Постепенно Agile превратился в философию.
Подробнее в Agile Manifesto 2001 года — сборнике правил и канонов гибкой разработки.
В этом уроке мы обсудим элементы гибких систем, которые помогут эффективнее работать в любых непредсказуемых проектах. Чтобы пользоваться ими, не нужна команда из дизайнеров и программистов и амбициозные задачи по разработке инновационного ПО. Agile-практики подойдут и для одиночной работы: помогут упростить планирование, структурировать работу и разделить её на небольшие шаги-итерации. Есть три признака, по которым можно определить, что реализацию проекта можно контролировать по гибким методам:
У вас нет детальных требований к результату или вы уверены, что требования будут меняться.
В вашем проекте нужен быстрый результат или хотя бы прототип результата, который будет работать и нести ключевую ценность.
Для получения качественного результата в проекте нужно участие аудитории: клиентов, партнеров, заказчиков.
Бэклог
Бэклог — это список требований к результату проекта, который на самом деле проще представить как список задач. Вы создаете списки, подобные бэклогу, когда планируете день. Список требований отличается от обычного списка дел форматом и степенью детализации. Чаще всего бэклог содержит перечень возможностей и функциональных особенностей продукта, технических заданий и целевых изменений, не конкретных задач. Словом, отвечает на вопрос «чем можно заниматься в моем клубе дебатов» а не на вопрос «что мне сделать завтра».
Бэклог обычно создаёт и ведёт product owner — владелец продукта. Это роль в команде, которая по канонам гибких методологий разработку, представляет из себя соединяющее звено между клиентом и командой, выполняющей проект. Владелец продукта лучше всех знает, что нужно клиенту или больше всех исследует, что нужно аудитории. Так или иначе, это человек, у которого есть видение результата. В нашем случае вы — product owner проекта, вам и решать, что пойдёт в бэклог.
Владелец продукта — человек, у которого есть видение продукта. Он знает, что нужно клиенту, и может донести это до команды.
Владелец продукта — это не всегда руководитель проекта. Например, если клуб дебатов значительно вырастет, то Вася будет заниматься выходом в новые университеты, работой с командой, управлением и решением проблем. А у продукта клуба — образовательной программы — может появится свой «владелец», который отвечает только за этот блок, но знает его от и до. Соответственно, ему проще описывать и контролировать задачи для образовательной части, он «владеет» этим блоком лучше других.
Проще говоря, в маленьком проекта руководитель проекта и владелец продукта могут быть одним и тем же человеком, а вот в большом у одного руководителя проекта может быть несколько product owner’ов, которые отвечают за разные продукты в рамках одного проекта.
В команде из трех человек Вася сам будет владельцем продукта — будет общаться и с участниками клуба, и с волонтерами, чтобы понимать, как развивать образовательную программу. Но если команда сильно вырастет, то может появится другой владелец продукта, а Вася останется руководителем всего проекта.
Дополнительный материал
Почитайте статью о роли и задачах владельца продукта. Из статьи узнаете, что это не просто набор обязанностей, но и специфический взгляд на работу.
Спринт
Спринт — это отрезок времени, за который создаётся самостоятельная и несущая пользу часть проекта. Каждый спринт — это мини-проект, который состоит из цели, плана по её достижению, работы и результата. Если весть проект, выстроенный по гибким методикам, это сериал, то съёмка одной серии — это спринт.
Спринтами удобно работать, потому что они помогают фокусироваться на чем-то одном: скажем, брать в работу на всю неделю ограниченное количество приоритетных задач и не распыляться на всё остальное. Спринт может быть дольше или короче недели, но скорее всего, работая в одиночку, планировать неделями будет удобнее всего. Каждый Спринт состоит из трёх последовательных мероприятий: планирования спринта, самой работы и ретроспективы спринта. Все события обязательны к выполнению и исключительно в таком порядке.
Планирование, работа, ретроспектива — три обязательные составляющие спринта.
Во время планирования мы определяем задачи, которые пойдут в этот спринт, и желаемый результат. Не рекомендуем добавлять новые задачи в текущий спринт, лучше перенесите их на будущее. Работаете только над теми задачи, которые определили во время планирования. Ретроспектива — это рефлексия работы. Посмотрите, чего удалось добиться? Какие изменения стоит внести в процесс? Что не получилось? Какая нужна помощь?
Например, вы установили длину спринта в неделю. Это подходящая длительность для индивидуальной работы: за неделю можно сделать достаточно, чтобы получить самостоятельный результат. Например, написать контент-план или подготовиться к мероприятию. На первый спринт вы берете в работу какие-то идеи из бэклога, например, организовать открытый урок по дебатам.
Неделю за неделей вы рефлексируете над результатами и анализируете, что получилось, а что — нет. Спринты позволяют мыслить итерациями: каждый раз нужно подвести итог и что-то поменять, чтобы результат получался лучше. Например, в следующий раз вы запланируете открытый урок в другой аудитории, потому что в этой было тесновато.
Схема связи между бэклогом, работой спринтами и итерационным развитием
Борд
Когда требования из бэклога попадают в работу, они рождают задачи. Задачи в гибких методологиях бывают в трех основных состояниях: «надо сделать», «делаю» и «сделано». Чтобы визуализировать процесс движения задач из состояния в состояние, придумали записывать их на карточки и двигать по пробковой доске. Борд (от английского board — доска) сегодня можно сделать и виртуальным, но принципы остаются одни и те же.
Экспериментируйте с количеством состояний и создавайте для себя несколько бордов с задачами разного масштаба. Например, можно завести отдельную доску для задач по созданию постов для социальных сетей, там подойдут состояния: есть концепция поста → есть текст → есть картинка и текст → пост поставлен на таймер → пост вышел.
Сторипоинты
Люди плохо оценивают длину в метрах и время часах без измерительных приборов. Если вы попросите 5 разных людей оценить длину самолета в метрах, то получите большой разброс в результатах. Особенно, если у испытуемых перед глазами нет самолета, вокруг которого можно обойти и осмотреться. С другой стороны, люди хорошо оперируют небольшими числами и схожим образом строят относительные прогнозы. Например, мы все сходимся во мнении о том, что 1 — это мало, 10 по сравнению с 1 — это много, а 5 — где-то посередине.
В гибких методологиях столкнулись с тем, что люди по-разному оценивают сложность задач, тем более таких, с которыми пока не сталкивались. Чтобы решить эту проблему, придумали систему, в которой трудозатраты на задачу оцениваются количественными значениями — сторипоинтами, которые ощутимо отличаются друг от друга. Чаще всего используют цифры 1, 2, 3, 5, 8 и 13, где 2 — самая простая задача, 13 — самая сложная.
Для сторипоинтов часто используют Числа Фибоначчи, посмотрите статью о них на Постнауке.
Проверить почту, нет ли ответа от администрации. 1 — потому что это не требует времени и сил, но нужно не забыть.
Отнести бумажное заявление на бронирование аудитории. Объявление готово, задача на 10 минут.
Провести короткую встречу с волонтерами, узнать статус по текущим делам. Задача на 30 минут.
Подобрать 10 групп, где можно разместить анонс мероприятия. Договориться о публикации новости. Задача на полтора часа.
Составить программу и подготовить план для следующих 5 мероприятий. Задача на 5–6 часов.
Составить полноценную программу на год для защиты в администрации. Задача на 2 дня.
Выберите удобные значения для сторипоинтов и заведите привычку оценивать все выполненные задачи. Если у вас, допустим, не будут использоваться 1 и 13 — отбросьте их и оценивайте только значениями 2, 3, 5 и 8. Помните, сторипоинты — не количество часов, а относительная мера усилий, потраченных на задачу. Не все задачи, оцененные вами в 3 сторипоинта должны занимать одинаковое время, но все должны быть примерно одинаковой сложности. Оценивая свои задачи по такой системе, вы узнаете вашу производительность и сможете лучше предсказывать, сколько сил уйдет на конкретную работу.
Допустим, у вас бывают задачи сложностью в 2, 3, 5 и 8. Через полтора месяца наблюдений вы выяснили, что за неделю вы нарабатываете на 25 сторипоинтов. Значит, будущие недели можно распланировать, исходя из того, что в неделю получится успеть четыре совсем сложных задачи по 8 или, например, успеть впритык 5 задач по 5.
Дополнительный материал
Олега Ткаченкова рассказывает о фреймворке Scrum — одного из самых популярных форматов гибкой организации работы.
Сроки и флекс
Нужно уметь адаптироваться к обстоятельствам, не теряя контроля над проектом. Хорошая система планирования совмещает в себе элементы критического пути и гибкого итерационного подхода. Существует концепция работы FFF — fix time, fix budget, flex scope. Дословно значит — фиксируем время, фиксируем бюджет, оставляем гибкими возможности. Flex часто не переводится, поэтому можно говорить просто — «флексим» возможности.
Подход FFF — это не про сознательное занижение планки, а про подготовку максимума из того, что запланировано, в рамках фиксированных сроков и ресурсов. Вы четко закрепляете время готовности критических задач, а если видите, что времени не хватает, начинаете упрощать и отбрасывать некритичное, чтобы успеть. В теории пофлексить можно в любом проекте, если у вы понимаете, что не успеете. Надо только придумать, как. Вот несколько способов с примерами из потенциально актуальных задач для дебатного клуба.
О флексе и проектах пишут в Советах Бюро Горбунова. Бюро — это дизайн студия, вокруг которой есть сообщество менеджеров, дизайнеров и редакторов.
Сделать систему статичной
Представим, что все в проекте можно упростить до двух видов систем: статических и динамических. В первых ничего нельзя менять после того, как вы с ними закончили, а во вторых — можно. Например, работа с волонтером
Динамичная система
Обсудить с волонтером, чем он хочет заниматься, составить план задач на несколько месяцев. Волонтер может заболеть, может передумать участвовать в проекте или, наоборот, предложить взять больше ответственности. Его участие в проекте динамично.
Статическая система
Найти волонтера и поручить ему конкретную задачу. Потом просто проверить выполнение. В системе практически нет динамики: волонтер или выполнит задачу, или нет, больше никаких переменных нет.
Динамические системы всегда более трудоемкие в производстве. Чтобы флексить, отказывайтесь от них или упрощайте. Продумайте зависимость от других факторов или сделайте полностью статическими. Если Васе для дебатного клуба потребуется сайт, проще сделать статичный лендинг на одну страницу, чем сайт с расписанием, которое менялось бы через какую-то динамическую систему.
Дополнительный материал
Почитайте, как в Бюро Горбунова подходят в FFF, как это помогает в работе и как выглядит на реальных проектах.
Снизить управляемость
Управляемость — это характеристика, которая показывает, как аудитория сможет влиять на отдельные элементы в системах проекта. Чем управляемость выше — тем сложнее проект. Не возводите функциональность в абсолют — можно оставить только один, самый главный инструмент контроля и убрать все остальные, чтобы сэкономить время.
Например, в дебатном клубе нужно разработать образовательную программу, которая готовит к соревнованиям. Можно сделать ее очень гибкой и управляемой для участников или статичной:
Управляемая программа
Предложить несколько предметов на выбор, вечернюю и дневную форму обучения или вообще онлайн-курсы. Пусть выбирают то, что им будет удобно.
Низкая управляемость
Есть только одна версия программы, которая будет распространяться на всех участников. Единственный инструмент контроля — согласиться или отказаться ее посещать.
Кажется, что если программа будет статичной, то она никого не заинтересует. Но на самом деле, если программа будет полезной и поможет эффективнее вести переговоры, участники равно будут ходить в любое время, жертвуя своим удобством. Статичность проекта не нанесет ему вреда, но позволит запуститься намного быстрее.
Например, страница пользователя Вконтакте — система с высокой управляемостью. Можно задавать настройки приватности, добавлять много информации разного характера. Но все начиналось с очень простого функционала, потому что на старте такое количество функций не было важно. Если планируете проект, начните со статичного и негибкого решения и дорабатывайте его по ходу.
Начинайте со статичного решения, чтобы показать ему клиентам и понять, как двигаться дальше.
Уменьшить глубину проработки
В любом проекте можно найти задачи, глубина проработки которых мало затронет ключевые функции проектного результата. С одной стороны, глубиной жертвовать опасно, потому что она показывает качество работы: в хорошем проекте результат чист до мелочей, все элементы и системы работают одинаково хорошо. С другой стороны, целевая аудитория не будет изучать все детали. Если ключевые системы проработаны глубоко — не так важно, что второстепенные отличаются по качеству.
Предположим, что дебатный клуб запланировал серию открытых образовательных мероприятий. Про каждое нужно рассказывать в социальных сетях и Вася хочет подготовить разные афиши — с фотографиями спикеров, временем и датой. Их несложно сверстать в Фотошопе, но Вася поздно понимает, что у него совсем не будет времени на каждую афишу. Чтобы пофлексить и успеть выдать результат, он может уменьшить глубину проработки — сделать один шаблон с логотипом дебатного клуба и на его основе подготовить все афиши. Они будут выглядеть проще и скучнее, зато они будут в срок.
Убрать в гараж
На балонах и в гаражах люди хранят ненужное или неприятное глазу. Старые вещи, которые жалко выбросить, велосипед, который достают раз в год или какие-нибудь отделочные материалы, которые остались с ремонта. В проектах иногда полезно завести свой «гараж» и убирать туда все, что в текущей итерации выглядит плохо.
Представим, что для сайта дебатного клуба Вася изначально хотел сделать отдельную страничку с фотографиями, ФИО и краткой биографией всех членов дебатной команды. Из-за того, что с сайтом работы оказалось куда больше, чем он думал, за эту страничку он взялся в последнюю очередь и сильно не успевает.
Неудачное решение
Оставить кривую страницу как есть. Понадеяться, что никто не будет туда заглядывать.
Спрятали в гараж
Сделать pdf-файл со всей информацией и выложить его на сайт, спрятав в разделе «контакты» за кнопкой «скачать инфо о команде».
Заменить решения
Когда не остается способов замаскировать пробелы в проекте, остается только отказываться от систем, которые не готовы в срок. Это самое болезненное и, по сути, уже постепенно выходит за рамки флекса. Если Вася не успевает организовать образовательные мероприятия и отказывается от них, страдает вовлеченность участников и в клуб ходит мало студентов. Это плохо влияет на весь проект и потенциально ведет к краху.
Последний рубеж перед полным отказом от кусков работы — замена решений. Очную образовательную программу, на которую нет времени и ресурсов, можно заменить онлайн-курсом. Краткий учебный курс Вася напишет за неделю, разместить в интернете текстовые документы, дополнит материалами с Ютуба и книгами на английском, вышлет студентам по почте. Это позволит удерживать вовлеченность на приемлемом уровне, хотя и будет несолидно. На первое время такая система будет приносить результат, а в следующей итерации, например, в будущем году, Вася доделает очную программу, договорится со спикерами и сделает все на уровень лучше.
Мастерский флекс — это тот, который не наносит вред проекту, но помогает закончить в срок, придет не сразу. Нужно быть готовым отступить от идеалов и фокусироваться на самом важно, а в первые разы это очень болезненно. Оставайтесь объективными, не тратьте время впустую и не привязывайтесь к своим идеям. Так искать гибкие компромиссы будет легче. Ваша задача не сделать проект хуже, а подстроится под ограничения и добиться максимального результата.
Закрепим
1
Есть проекты, у которых высокий уровень неопределенности. Для них вместо стандартных поступательных систем проектной работы придумали итеративные.
2
Итеративные методы позволяют чаще запрашивать обратную связь и адаптировать проект под стейкхолдеров, аудиторию или обстоятельства.
3
Гибкие методы или Agile-методы подойдут вашему проекту, если вы уверены, что требования к результату будут меняться и вам нужен быстрый прототип.
4
В рамках Agile есть много инструментов для планирования и работы. Используйте бэклог, чтобы систематизировать задачи перед стартом проекта. Работайте короткими отрезками-спринтами, отмечайте сделанное на борде, оценивайте сложность в сторипоинтах.
5
Ничего никогда не идет по плану, поэтому готовьтесь к тому, что выполнить все задуманное не получится — просто не хватит времени. Учитесь флексить.
6
Есть много способов флексить — упрощать, отказываться от лишнего или осознанно недоделывать, чтобы улучшить в будущих итерациях. Например, можно перейти к статическим системам или снизить управляемость.
7
Флексить — болезненно, сложно и плохо. Но чаще всего флексить лучше, чем отказываться от каких-то частей проекта. Заменяйте решения на более простые, если совсем не успеваете.
Проверьте себя
Помогите Васе спланировать первую итерацию дебатного клуба в небольшой игре. Двигайтесь по неделям, учитывайте новые вводные, расставляйте приоритеты и следите за сроками.