Лекция 3. Планирование содержания и иерархическая структура работ. Базовый курс.

Лекция 3. Планирование содержания и иерархическая структура работ. Базовый курс.

В прошлом блоке мы договорились: сначала устав, потом всё остальное. Устав есть, спонсор назначен, заинтересованные стороны определены. Теперь начинается самое интересное — переводить «хотелки» заказчика в конкретный список работ. Это называется планированием содержания, и именно здесь, а не потом, прячется дьявол. Потому что «содержание» — это не то, что заказчик говорит словами, а то, что он на самом деле имеет в виду. А эти две вещи, как показывает практика, совпадают далеко не всегда.

Начнём с самого понятия. Содержание проекта — это полный перечень того, что мы делаем. Но есть тонкость: содержание — это не только «что входит», но и «что не входит». По-английски это звучит красиво: project scope и out of scope. И вот out of scope — исключения — это, пожалуй, важнее. Потому что заказчик обычно представляет себе всё, «что может прийти в голову», а договориться надо о конкретном. Если в уставе не написано «вне рамок проекта: мобильное приложение», то через два месяца заказчик скажет: «а давайте ещё сделаем мобильное приложение, это же логично». И вы не сможете ответить, потому что нигде не зафиксировано, что приложение — вне рамок. Фиксируйте исключения! Это спасёт вас от бесконечных «а давайте ещё».

Как формируется содержание? Из требований заказчика. А требования — это самая коварная материя в управлении проектами. Заказчик говорит «сделайте сайт красивым». Что это значит? Для него — «мне должно понравиться», а понравится — это он поймёт, когда увидит. Для вас — не значит ничего. Требование должно быть конкретным: «тёмная цветовая гамма, шрифты без засечек, скорость загрузки не более двух секунд». Если требование нельзя проверить — оно не сформулировано. Вот почему на этапе сбора требований менеджер выглядит как прокурор: задаёт вопросы, переспрашивает, уточняет, записывает. И это правильно. Лучше выглядеть занудой в начале, чем неудачником в конце.

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

После того как требования собраны, начинается магия под названием декомпозиция. Это разбиение большого и страшного проекта на маленькие и понятные части. Инструмент декомпозиции — иерархическая структура работ (ИСР), по-английски Work Breakdown Structure, WBS. Это, по сути, дерево: наверху — проект целиком, ниже — основные разделы, ещё ниже — подразделы, и так до мельчайших работ, которые уже можно поручать конкретному человеку. WBS — это, пожалуй, самый недооценённый инструмент управления проектами. Все гонятся за диаграммой Ганта, а на самом деле корень всего — правильная структура работ. Правильно разбил проект на работы — половину проблем решил.

Как строить WBS? Есть два главных принципа. Первый — правило 100%: верхний уровень должен содержать 100% работ проекта. Если в WBS не попало что-то, что надо сделать, — это гарантированный сюрприз в середине проекта. Второй — независимость элементов: каждую работу нижнего уровня можно поручить одному человеку или одной команде без пересечений с соседями. Если две работы перекрываются — расплывчата ответственность, и потом непонятно, кто виноват. Есть и третий, практический совет: нижние элементы WBS должны быть размером, который можно оценить и проконтролировать. Никто не может оценить «разработку системы». А «разработать модуль авторизации» — могут. Вот это и есть граница декомпозиции.

Сразу оговорюсь о типичных ошибках. Первая — строить WBS под оргструктуру, а не под работу. «У нас будет отдел разработки, отдел дизайна, отдел тестирования» — это не структура работ, это структура людей. Надо делить работу, а не людей. Вторая — путать элементы WBS с этапами. Этапы — это время, WBS — это содержание. Это разные измерения, и их нельзя смешивать. Третья — слишком мелкое дробление: пятьсот задач там, где хватило пятидесяти, и команда тонет в план-фактах. Четвёртая — слишком крупное: руководитель говорит «сделайте модуль», но никто не знает, из чего он состоит. Золотая середина — 3-5 уровней для типового проекта, до уровня, на котором задачи «может оценить тот, кто будет делать», и «не больше 20-40 рабочих часов на задачу».

Зачем нужна такая детализация? Потому что только на нижнем уровне WBS можно правильно оценить время и деньги. Если вы попросите команду оценить «весь проект», вам скажут «не знаю, месяцев шесть, наверное». А если разбить на сорок задач и каждую оценить, получится цифра, которой можно верить. И ещё: WBS — это фундамент для всего остального. Из неё вырастает календарный план (по элементам WBS задачам назначаются сроки), из неё вырастает бюджет (по элементам WBS собирается стоимость), из неё вырастает ответственность (по элементам WBS назначаются ответственные). Нет WBS — нет плана. Есть WBS — есть с чего начать.

Теперь про словарь WBS. Это документ, где каждый элемент дерева описан словами: что именно считается выполненным, что входит, что не входит, кто отвечает. Звучит скучно, но именно словарь WBS снимает большинство споров. Потому что элемент «Установить оборудование» можно понимать по-разному. Установить — это привезти и поставить? Или ещё подключить? Или ещё настроить? Или ещё обучить персонал? Словарь WBS фиксирует: «установить — это привезти, поставить на место, подключить к сетям, проверить запуск. Обучение персонала — отдельная работа, пункт 3.4». Как только такой словарь подписан, эпоха «а я думал, что установка включает обучение» заканчивается.

Часто спрашивают: а когда заканчивать декомпозицию? Ответ простой: когда каждый элемент можно оценить, поручить и проконтролировать. Дальше дробить не нужно — это будет микроуправление, от которого страна и команда устанут. Есть такое правило: если элемент WBS может быть выполнен за 40 часов одним человеком — это хороший размер для планирования. Дальше дробить до «двухчасовых кусочков» не имеет смысла, если только у вас не идёт работа на производственной линии. Для большинства проектов «задача на 2-5 дней» — оптимальный размер: её можно оценить, записать в план и проверить, сделана она или нет.

И отдельно про два подхода к планированию, о которых нельзя не сказать в блоке про содержание: водопад (waterfall) и гибкие методы (agile). Водопад — это классика: сначала требования, потом дизайн, потом разработка, потом тестирование, потом сдача. Всё последовательно, всё зафиксировано, всё по плану. Agile — это когда требования уточняются каждые две недели, и вы каждые две недели отдаёте работающий кусочек продукта. Не буду говорить, что одно лучше другого, потому что это зависит от проекта. Водопад хорош, когда требования понятны с самого начала и менять их дорого: строительство, госзаказ, производство. Agile хорош, когда требования неясны и меняются: разработка нового софта, создание нового продукта. Управлять содержанием и там, и там нужно, просто по-разному — об этом дальше.

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

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

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

Ещё одна вещь, которую забывают на этапе планирования содержания, — критерии приёмки для каждой работы. Как мы поймём, что работа выполнена? Нужно заранее определить, по каким признакам заказчик скажет «да, принято». Для каждой вехи, для каждого крупного результата — критерий приёмки. Сайт — открывается, все страницы работают, скорость — два секунды. Дом — построен, проведены коммуникации, есть акт ввода. Программа — модуль отвечает на все 150 тестов, базы данных сходятся. Если критерии приёмки не определены заранее, на финише начнётся: «это не то, это не так, я думал, будет по-другому». А если определены — спор заканчивается ссылкой на документ.

Домашнее задание после этого блока — построить WBS для своего проекта. Возьмите лист бумаги или доску (да, лучше бумагу, так нагляднее) и нарисуйте дерево. Вверху — проект, ниже — 5-7 основных разделов, внизу — подразделы до уровня «задачи на 2-5 дней». Проверьте себя по правилу 100%: ничего не забыли? Потом составьте словарь WBS: опишите несколько спорных элементов. И подумайте: что из вашего «хочу» на самом деле могло бы быть отнесено к out of scope — к тому, что вы честно выносите за рамки проекта? Умение говорить «это не входит» — это то, что отличает зрелого менеджера от вечного исполнителя чужих желаний.

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