Kyiv IT Outsourcing Forum 2017 — встигни купити Early Bird квитки до 1 травня!

Best practice по планированию работ. Опыт проектного менеджера

Прежде всего я хотел бы представиться — меня зовут Игорь Думбур, я профессиональный руководитель проектов. Имею опыт в реальном секторе экономики с выскобюджетными промышленными high tech проектами в строительном консалтинге, а также в коммерческой разработке ПО (fixed price, time and material и dedicated team модели).

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

Каждый менеджер проектов сталкивается с вызовами, связанными с декомпозицией и планированием работ, а также с выдерживанием сроков по релизам, промежуточным билдам и прочим ключевым датам. В этой статье я предлагаю рассмотреть два case-study, которые я взял из собственного опыта.

Сase study 1: Структурная схема работ (WBS)

В компании-разработчике кастомного Web-based ПО и мобильных приложений я руководил проектом по созданию небольшого сайта, основной функционал которого позволял пользователям просматривать открытые вакансии и присылать свои резюме на открытые позиции. Это case-study кратко проведет вас по процессу создания структурной схемы работ для этого проекта, WBS (Work Breakdown Structure).

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

Выделяем основные компоненты

Первый шаг который я предпринял — назначение Planning meeting’a со своей проектной командой. Проектная команда состояла из необходимых для этого проекта специалистов: дизайнер, frontend разработчик, backend разработчик и тест-инженер. Я пояснил команде, что цель нашего митинга — создание основной структурной схемы работ, чтобы представить и разбить на составляющие все основные компоненты сайта, которые нам необходимо зарелизить в MVP версии.

Совместно с командой мы разбили сайт на высокоуровневые компоненты — основные группы страниц сайта и привязанные к ним виды работ. Основная модель структуры получилась примерно такая:

  • Компоненты и субкомпоненты веб-сайта:
    • Design;
    • Content;
    • Frontend;
    • Backend;
    • Testing;
    • Deployment;
    • Прочие работы;
  • Основная project management документация.

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

В процессе создания WBS я использовал специальную систему идентификации элементов структурной схемы работ. Название каждого элемента включало в себя:
— Название высокоуровневого компонента (группы страниц сайта);
— Названия суб-компонента (конкретные страницы сайта);
— Название конкретного вида работы (например Frontend).

Разбиваем на сегменты

Я попросил Настю, нашу тестировщицу, нарисовать на доске несколько сегментов. Каждый сегмент представлял основной высокоуровневый компонент сайта, подписанный соответствующим образом. Дальше мы с командой начали разбивать высокоуровневые компоненты на более мелкие. Как только команда приходила к консенсусу по поводу каждого низкоуровневого компонента — я клеил на доску стикер в определенный сегмент. Вот на что наша WBS стала похожа через некоторое время:

Разбивая высокоуровневые компоненты на более мелкие, команда использовала метод деление на 2, так как любую работу довольно сложно разложить на более чем две составляющие, но делить на 2 все умеют отлично. Таким образом, мелкие работы в составе крупного компонента размножаются методом деления=).

Также мы с командой использовали метрику «правило шести-восьми часов». То есть никакая отдельная работа не должна занимать меньше 6-ти часов и больше 8-ти часов работы определенного специалиста. Хотя, с этим можно экспериментировать в зависимости от сложности и масштаба проекта, а также вида задачи.

Проверяем целостность

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

Спустя два раунда декомпозиции, мы с командой создали детальную WBS, которая отражала все основные компоненты сайта, а также вспомогательные работы. После этого я перенес нашу WBS с доски в Redmine, а также создал файлик проекта в Google Gantter (принятые на тот момент в компании project management tools).

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

Сase study 2: График работ

После того, как мы создали WBS, настало время сетевой диаграммы работ, PND (Project Network Diagram). А точнее, ее простейшей формы, которая была достаточна для нашей цели — определение срока, в который релиз MVP версии сайта выйдет в жизнь. Для этого мы с командой собрались на следующий раунд митинга по планированию работ.

Устанавливаем связи

Для получения ответа на извечный вопрос менеджмента: «Когда будет готово???», нам предстояло разобраться:
— С каких именно элементарных работ из нашей WBS мы собираемся стартовать?
— Когда мы с ними стартуем?
— Какие работы должны следовать после тех, с которых мы начнем, и по какой цепочке все пойдет дальше?
— Как разные задачи из WBS связаны между собой логически (связи «предшественник — последователь»)?
— Какие работы мы можем безболезненно выполнять параллельно?

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

Как только все работы были увязаны в ходе наших обсуждений, я установил соответствующие зависимости в Google Gantter файле (который я сделал на этапе составления WBS). Таким образом, перенося зависимости работ и эстимейты в Google Gantter, я получил возможность понять предварительную минимальную продолжительность выполнения работ по MVP версии нашего сайта, а также предварительный критический путь по работам проекта.

Корректируем график работ

Однако до того, как я смог получить четкое представление о дате релиза и промежуточных билдов, я должен был откорректировать график работ, принимая во внимание некоторые очень важные вещи:
— Зависимости, исходящие извне (инпуты от высшего менеджмента, например: «Игорь, этот сайт должен быть готов к числу „N“, т.к. мы ведем переговоры с потенциальными работодателями и мы договорились начинать работать с MVP с этой даты» и другая важная информация);
— Наличие ресурсов (члены проектной команды не были доступны 8 часов в день, т.к. в компании была принята матричная организационная структура, и каждый из ребят был задействован на нескольких проектах);
— Риски, связанные с проектом, которые могут повлиять на сроки сдачи (а их масса: риск болезни членов команды, пропущенные работы, неадекватные эстимейты и прочее);
— Учет календаря проекта (выходные, праздники и прочие возможные помехи);
— Учет персональных календарей членов команды.

Остановлюсь более подробно на двух последних пунктах:

Учет календаря проекта. Календарь проекта описывает, когда работа может быть выполнена. Например, с 10:00 утра до 19:00 вечера. Ничего особенного. Но представьте, что в силу определенных причин заказчик затребовал, чтобы рабочие часы на его проекте были приняты с 8:00 по 15:00 pacific time. Или это заказчик из Израиля, где пятница должна быть выходным. Таким образом, заказчик задает рабочее время календаря проекта. Теперь прибавим к этому праздники, принятые в компании выходные дни, и это еще больше ограничит рабочее время проекта. Обращать внимание на календарь проекта нужно обязательно, если вы хотите знать реальную дату получения того или иного результата. Ваш проект может закончится гораздо позже, если праздники, выходные и прочее нерабочее время повлияет на его ход.

Учет календаря ресурсов. Ваша проектная команда живет не только вашим проектом. У них есть отпуски, назначения к врачу, болеющие дети и прочее. Вдобавок, члены вашей команды могут работать также на параллельных проектах, как было в моем случае. Когда вы составляете график проекта, эти вещи нужно держать в голове. График ресурсов берет во внимание параллельные проекты, личные праздники и отпуски членов вашей проектной команды. Скорее всего, это повлияет на общую продолжительность проекта (но не повлияет на трудозатраты). Представьте себе, что один из ключевых разработчиков был отправлен к заказчику on-site, чтобы выполнить свою часть работы с рабочими часами, скажем, с 8.00 до 16.00 pacific time. В этом случае заказчик задал конкретному разработчику его персональный календарь, который вам нужно будет учесть (это 100% повлияет на срок сдачи проекта, или спринта).

Оцениваем результат

На последующем этапе остается только оценить влияние рисков (что не входит в содержание этой статьи, так как это совсем другая история=)).

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

В результате мы получили реалистичные даты окончания ключевых работ, выявили работы, требующие повышенного внимания (так как они лежат на критическом пути проекта), а также даты разработки MVP версии сайта в целом.


Надеюсь, эта статья будет вам полезна на ваших проектах. Если возникли вопросы — прошу обращаться. Добавлю также, что данные методики разработки WBS, превращения ее в PND и увязки в график проекта были обкатаны не на одном проекте, как в сфере разработки софта, так и в проектах по инженирингу и строительству large scaled промышленных объектов.

Удачных релизов и билдов, коллеги! =).

73 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Очень жду Вашу статью по рискам!

Конечно. Как будет время — сразу напишу. Приятно пообщаться с профессионалом. Хоть и не принимающим во внимание контекст кейсов )

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

Я там откомментил по поводу ревью дезайна. Конструктивная критика с вашей стороны была, теперь нужно разобраться с проблемой. Может я реально что-то упускаю. Посоветуйте, как быть.

Описал смотрите ниже, вариантов несколько, есть из чего выбрать :).

Немного о себе, я любитель разработки софта и любитель проектного управления 7 лет работы в роли руководителя проектов в области разработки софта(от микроконтроллеров до e-Commerce сайтов).17 лет в индустрии, насмотрелся всякого.

50-60 задач в плане. Первого плана неплохо. Но к профессионалу, есть вопросы.
Своей структурой WBS вы вводите людей в глубочайшее заблуждение. Объясняю:
Backend, FrontEnd и Content это не компоненты, а типы работ, даже скорее типы ресурсов для выполнения работ. Можно, конечно, и так делать... Однако, узлы иерархической структуры работ(ИСР) (WBS-components) --- не просто группировка работ по компонентам, которые составляют части целого, а еще и точки, где аккумулируется часть бюджета, учитывается время и закладываются рисковые буфера, и управленческие резервы. Компонент может иметь отдельный источник финансирования, или исполняться сторонней компанией или быть другим проектом. ну это так к слову. А теперь давайте все вмести представим выполнение компонента Backend сторонней компанией в этом проекте... О, как!... сколько зависимостей и сложностей сразу рисуется. Получается сторонняя компания должна реализовать ВСЕ функции сайта. Как-то так-то.

Минус вашей структуры: Если заказчик отказался от какой либо страницы или раздела сайта вам нужно «выпиливать» работы из разных узлов ИСР(WBS), но это мелочь.... И пересчитать бюджет(время, затраты, пересчитать буфера) всего проекта. На плане с 50 работами ---- это ерунда 2 минуты времени, а на 500(3-4 месячный проект)? на 5000(да есть и такие планы)?
Но главное, компонент(не работы, а компонент) проходит приемку заказчиком, то что вы будете сдавать? Ну, вы понимаете нелепость сдачи компонента Frontend или Content при такой структуре, ПМ загоняет себя в угол либо все либо ничего! Ни какой сдачи по частям.
Как профессионал, вы в курсе на самом верху иерархии стоит конечный продукт, а дальше его части, ответьте на вопрос: «Сайт состоит из разделов и страниц или из Frontend, BackEnd, Прочих работ?»

При хорошо продуманной WBS можно выкинуть один из компонентов сайта всеми работами, и рисковыми буферами, и финансированием и общая структура не пострадает.

По опыту структура WBS сайта должна быть такой. Пример, раскрывающий идею
Project A
|
------------------------------------------------------------------------------------------------------------------------------------
|  |  | |
Site Testing Deployment Project Management
|
---------------------------------------------------------------
|  |  |  | |
Landing About Ipmressum Header Footer
Page us

Landing Page, About us, Ipmressum, Header, Footer Содержат работы по Backend, Frontend, Content.
Конечно сейчас начнут возражать, а где мол, дизайн а где багофикс, --- это отдельная тема для беседы. В общем, зависит от проекта, куда включать дизайн, либо в структуру компонентов, либо выделять отдельным компонентом на уровне с сайтом или как часть сайта. (Многогранен мир)

Преимущество: Заказчик захотел новый раздел. Вы делаете новый компонент, и рисуете под сайтом. Заказчик, не хочет тестирования, ну деньги закончились. а сайт хочет, выпилили тестирование и дело с концом.

Ошибок на самом деле в плане много. Но одна, про которую молчать не могу ---- это ослепительный компонент Service Task. Я такие компоненты называю своим именем «ПОМОЙКА для списывания временнЫх затрат.» или более дипломатично «Дальше мы не придумали структуру, сюда спишем все подряд».
Итак давайте взглянем детально Service Tasks. И как он достигнет выполнения 100% и что получит заказчик в конце?

1. Setup for new developer --- а если несколько разработчиков, а почему заказчику надо это показывать, и почему он за это должен платить? т.е. Палюбому надо засетапить девелопера чтобы сделать компонент. Окай.
Конечно зависит от проекта, но можно было выделить компонент «Training» например.
2. Маrkup review:Design --- что-то мне подсказывает что попытка нарисовать компонент дизайн была.. но мнение демократии «здравого смысла» команды программистов взяло вверх над волей ПМ-а. Бывает. Что делать с дизайном см. выше.
3. Test server setting — а почему здесь а не в Quality Assurance??????
4. Release #1 --- хм.... существительное... или глагол. Все таки глагол? потому что есть время на эти «Роды» 1.67h. Существительное было бы вехой(milestone). Понятно что при такой WBS положить эту задачу кроме как в «помойку» не куда. Не пилить же компонент «Administror lazy bastrad work» :)
5. Teamplates refactoring ---- шаблоны, т.е много.наверняка к чему-то относились? К сайту, к контент странице, к landing page, к закоголовку, к хвосту(footer). Все в одну помойку, а куда же еще?! Это работа фронтенда, если я правильно помню, а может совместная с беэкндом. Пойди тут разбери теперь.

Что будем сдавать заказчику по итогу:
Засетапленого девелупера одна штука, Пересмотренный макет, 1.67 часов процесса родов, процесс установки тестового сервера при этом сам сервер не даем, процесс переделки шаблонов.
Резонный вопрос, а заказчику все это надо?

Анализируйте, думайте, пробуйте. и все у вас получиться, не со второго так с третьего раза.

диаграмму форматирование убило пишу списком пример моего WBS
1.Project A
....
1.1 Site
1.1.1 Landing Page
1.1.2 About us
1.1.3.Ipmressum
1.1.4 Header
1.1.5 Footer

1.2 Testing
...
1.3 Deployment
...
1.4 Project Management
...

Здравствуйте Михаил! Спасибо за такой обширный коммент. У уж было надеялся что обсуждение оляглось, но «опять скрепит потертое седло ©»)) Читая ваш коммент, я испытал целый спектр эмоций, но в итоге пришел к выводу, что вы очень занятой человек и внимательно посмотрели только на скриншот графика работ. Однако в то же время, мы с вами находимся on the same page, т.к. написали (я в статье, а вы в комменте) по сути об одном и том же.
Итак, давайте по-порядку:
1. Моя статья рассматривала ПОДХОД к декомпозиции и планированию на основе PERT применительно к разработке софта, а не единственно-правильный способ построения WBS по web проектам. Это нужно четко понимать. Подход. Это ключевое.
2.

Своей структурой WBS вы вводите людей в глубочайшее заблуждение. Объясняю:
Backend, FrontEnd и Content это не компоненты, а типы работ, даже скорее типы ресурсов для выполнения работ.
Спасибо большое за обьяснение. Однако если посмотреть в статью, можно обанаружить следующиее take.ms/6Dbai. По поводу точки
3.
Однако, узлы иерархической структуры работ(ИСР) (WBS-components) --- не просто группировка работ по компонентам, которые составляют части целого, а еще и точки, где аккумулируется часть бюджета, учитывается время и закладываются рисковые буфера, и управленческие резервы. Компонент может иметь отдельный источник финансирования, или исполняться сторонней компанией или быть другим проектом. ну это так к слову. А теперь давайте все вмести представим выполнение компонента Backend сторонней компанией в этом проекте... О, как!... сколько зависимостей и сложностей сразу рисуется. Получается сторонняя компания должна реализовать ВСЕ функции сайта. Как-то так-то.

В данном конкретном РЕАЛЬНОМ кейсе контекст был следующий:
— Заказчик: внутренний проект компании
— источник финансирования: собственные средства компании
— ресурсы: собственные разработчики компании
— обьем: MVP версия по согласованному минимальному набору функционала с дизайном который уже был утвержден (монолит, не подлежащий изменениям в данном КОНКРЕТНОМ контексте).
Исходя из такого конекста, я выбрал планировать WBS по deliverables (коими являлись как раз компоненты take.ms/6Dbai, или по вашему take.ms/lTrL6, аккумулирующие все о чем вы говорили (что было отражено в Redmine, т.к. все таски были собраны в свои контейнерные milestones представляющие конкретные компоненты с кол-вом estimated time and spent time). А график работ я решил делать по видам работ, т.к. MVP в данном КОНКРЕТНОМ контексте являлся монолитным обьемом и я волен выбирать способ построения графика работ так как МНЕ удобно для КОНКРЕТНОГО случая. В возможных конекстах которые описали вы — наверняка график работы строился бы по-другому, но это тоже зависило бы от ситуации.
3.
Минус вашей структуры: Если заказчик отказался от какой либо страницы или раздела сайта вам нужно «выпиливать» работы из разных узлов ИСР(WBS), но это мелочь.... И пересчитать бюджет(время, затраты, пересчитать буфера) всего проекта. На плане с 50 работами ---- это ерунда 2 минуты времени, а на 500(3-4 месячный проект)? на 5000(да есть и такие планы)?
Но главное, компонент(не работы, а компонент) проходит приемку заказчиком, то что вы будете сдавать? Ну, вы понимаете нелепость сдачи компонента Frontend или Content при такой структуре, ПМ загоняет себя в угол либо все либо ничего! Ни какой сдачи по частям.
Как профессионал, вы в курсе на самом верху иерархии стоит конечный продукт, а дальше его части, ответьте на вопрос: «Сайт состоит из разделов и страниц или из Frontend, BackEnd, Прочих работ?»
При хорошо продуманной WBS можно выкинуть один из компонентов сайта всеми работами, и рисковыми буферами, и финансированием и общая структура не пострадает.
Возвращаемся к пункту 2, там все раскрыто. Мой контекст — мои решения. Но приятно поговорить с профи, который понимает что такое декомпозиция. Правда, тут таких не много.
4.
Landing Page, About us, Ipmressum, Header, Footer Содержат работы по Backend, Frontend, Content.
Конечно сейчас начнут возражать, а где мол, дизайн а где багофикс, --- это отдельная тема для беседы. В общем, зависит от проекта, куда включать дизайн, либо в структуру компонентов, либо выделять отдельным компонентом на уровне с сайтом или как часть сайта. (Многогранен мир)
Преимущество: Заказчик захотел новый раздел. Вы делаете новый компонент, и рисуете под сайтом. Заказчик, не хочет тестирования, ну деньги закончились. а сайт хочет, выпилили тестирование и дело с концом.
В МОЕМ контексте, дизайн уже был. Багофикс тоже был, как без него. Вы сами в данном фрагменте говорите о том, что включение этих моментов в структуру зависит от проекта (т.е. от контекста) и мир реально многогранен. Вы предлагаете сделать смешанное представление WBS (и это тоже неплохой вариант, на усмотрение PM’a в зависимости от контекста), т.е. представить WBS в смешанном виде, как deliverables (копоненты) и как виды работ (например тестирование, которое не хочет заказчик и которое нужно выпилить, т.е. убрать сразу целый вид работы). И deliverables и виды работ в таком случае будут жить вместе и никто не пострадает (разве что ваша психика, когда кто-то будет комментить ваш профессиональный контекстно-зависимый подход и говорить
Ошибок на самом деле в плане много.

5.
Ошибок на самом деле в плане много. Но одна, про которую молчать не могу ---- это ослепительный компонент Service Task. Я такие компоненты называю своим именем «ПОМОЙКА для списывания временнЫх затрат.» или более дипломатично «Дальше мы не придумали структуру, сюда спишем все подряд».
Итак давайте взглянем детально Service Tasks. И как он достигнет выполнения 100% и что получит заказчик в конце?
Еще раз. Service tasks это контейнер для вспомогательных работ, которые были ЗАПЛАНИРОВАНЫ исходя из СУЩЕСТВУЮЩЕГО контекста, но не относились непосредственно ни к одному из deliverables. Но каждая из этих работ была реально необходима, т.к. она блокировала совершенно конкретные работы, которые относились к какому-либо из deliverables непосредстенно.
6.
1. Setup for new developer --- а если несколько разработчиков, а почему заказчику надо это показывать, и почему он за это должен платить? т.е. Палюбому надо засетапить девелопера чтобы сделать компонент. Окай.
Конечно зависит от проекта, но можно было выделить компонент «Training» например.
Да, надо было засетапить. Реально. Исходя из контекста — надо было показывать и за это нужно было платить. Нужно было показать, что исходя из ресурсной ситуации у нас есть конкретный кейс с сетапом нового вертальщика и это требует календарного времени и соответственно это вплияет.
7.
2. Маrkup review:Design --- что-то мне подсказывает что попытка нарисовать компонент дизайн была.. но мнение демократии «здравого смысла» команды программистов взяло вверх над волей ПМ-а. Бывает. Что делать с дизайном см. выше.
Возвращаемся к контексту. Дизайн был. Маrkup review:Design — обязательная задача по ревью верстки дизайнером и выдача замечаний для правки. Хорошая практика, кстати.
8.
3. Test server setting — а почему здесь а не в Quality Assurance??????
Потому что эта работа делалась не тестировщиком, а devops’ом и это инфраструктурная задача. В данном конкретном контексте. Что вы делаете и куда суете такие таски — сугубо ваше дело. Или нет?)
9.
4. Release #1 --- хм.... существительное... или глагол. Все таки глагол? потому что есть время на эти «Роды» 1.67h. Существительное было бы вехой(milestone). Понятно что при такой WBS положить эту задачу кроме как в «помойку» не куда. Не пилить же компонент «Administror lazy bastrad work» :)
Возвращаемся к пункту 5.
10.
5. Teamplates refactoring ---- шаблоны, т.е много.наверняка к чему-то относились? К сайту, к контент странице, к landing page, к закоголовку, к хвосту(footer). Все в одну помойку, а куда же еще?! Это работа фронтенда, если я правильно помню, а может совместная с беэкндом. Пойди тут разбери теперь.
Это относилось ко всему сайту. Работа для backend разработчика, в данном случае. Работа пошла в контейнер для работ, которые относятся к сайту в общем и/или не относятся напрямую к конкретному deliverables.
11.
Что будем сдавать заказчику по итогу:
Засетапленого девелупера одна штука, Пересмотренный макет, 1.67 часов процесса родов, процесс установки тестового сервера при этом сам сервер не даем, процесс переделки шаблонов.
Резонный вопрос, а заказчику все это надо?
Сдаем заказчику согласованный обьем (возврат к пункту 3). Не больше, ни меньше. Монолитный согласованный обьем МVP версии.
12.
Анализируйте, думайте, пробуйте. и все у вас получиться, не со второго так с третьего раза.
Спасибо. Постараюсь. В свою очередь посоветую вам читать материалы внимательно, выделать что именно является целевой информацией в материале (т.е. выделять главное, красную линию. в данном случае это пункт 1 моего коммента), не писать разгромных комментов для ситуаций, контекст которых вам до конца не ясен и самое главное — не думать, что вы умнее всех.
Немного о себе, я любитель разработки софта и любитель проектного управления 7 лет работы в роли руководителя проектов в области разработки софта(от микроконтроллеров до e-Commerce сайтов).17 лет в индустрии, насмотрелся всякого.
безусловно, заслуживает уважения. Но все же лучше разобраться в контексте, а затем излагать истины, с которыми я, кстати говоря, полностью согласен, т.к. смотрю на вещи в том же ключе.

Ваши подходы к составлению календарного плана действительно достойны уважения, к составлению календарного плана вопросов нет. Хорошая работа. Учет проектного календаря, календари ресурсов, доступность ресурсов и внешние ограничения --- все верно. Всё как «книжка пишет». Используете PERT для создания календарного плана, ваш выбор. Как по мне так лишний шаг, обычно достаточно задать последовательность работ прямо в ganter или ms project, но если вам и команде так удобно то вопроса нет, любой работающий инструмент хорош. Лично я использовал PERT для буферизации рисков и трех точечной оценки.

Вы пишете статью, о том как производить декомпозицию работ. Это основной посыл, так гласит заголовок. И делаете явную ошибку в первом же абзаце. Вас читают люди без опыта. И считают, такой подход правильный. А потом эти люди(лиды, програмисты, QA, QA лиды), приходят к ПМ-у и морочат голову не корректной WBS с извращенной точкой зрения. Единственная моя цель указать на явную ошибку.

Я понимаю, что вы выделили ключевые практические результаты(deliverablies) , на своей доске, хороший подход. Только почему они не нашли отображения в WBS и календарном плане? А книжки как раз пишут об обратном. (и не только книжки)

(....я волен выбирать способ построения графика работ так как МНЕ удобно для КОНКРЕТНОГО случая...)
Увы, нет. Вы опять вводите людей в заблуждение. Да, WBS вы вбираете или строите для каждого проекта индивидуально. График работ рекомендуется делать таким образом чтобы он повторял структуру WBS и отображал практические результаты(deliverablies) в противном случае вам нужно вести двойной учет или делать дополнительные трансформации над данными учета, и вам очень повезет, если ваши учетные системы позволяют это сделать автоматически. Ваш выбор конечно, тут не поспоришь.
Ваша апелляция к внутреннему проекту и внутреннему финансированию неуместна, проект есть проект стандарт, есть стандарт. Есть здравый смысл, наработки других компаний, практический опыт. А вы на весь свет трубите про практику, которая приняты у вас в компании, как о лучших подходах. Если у вас принято делать декомпозицию таким образом, кто я такой что бы давать оценки и раздавать советы. Но люди должны получать не искаженную информацию!
Единственный аргумент который работает в вашем случае, что о такой структуре вы договорились с заказчиком, не важно, внутренний или внешний, и по такой структуре вы будете отчитываться. Другие аргументы не работают.
В противном случае вас ждет увлекательный мир математики, ручной обработки отчетов, двойного учета, с неизбежным вопросам «а почему расхождение в N часов из прошлого периода???!!!!» при составлении отчета о ходе проекта. Если вам так удобно выбор безусловно ваш! Как руководитель вы несете ответственность и за свои решения тоже.

Простите, но давайте людям правдивую и правильную информацию. Правильный и грамотно составленный WBS помогает. Не корректный, это боль для всей команды без исключения, боль которую вы собственноручно создаете (... мне так удобно...) .

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

Моя статья рассматривала ПОДХОД к декомпозиции и планированию на основе PERT применительно к разработке софта, а не единственно-правильный способ построения WBS по web проектам

Более бредового ничего не слышал (... подход к декомпозиции через PERT...) в Ригу через Горловку на карете впереди лошади.
PERT --- это из управление расписанием, а WBS --- это из области управления объемом работ. Скажите, по теории и на практике, что делается сначала? Определяется объем работ или составляется расписание? Не учите людей бредовым подходам!

Ваш личный пиар удался, вы привлекли внимание к своей персоне, поздравляю.

С удовольствием прокомментирую))
1.

Как по мне так лишний шаг, обычно достаточно задать последовательность работ прямо в ganter или ms project, но если вам и команде так удобно то вопроса нет, любой работающий инструмент хорош. Лично я использовал PERT для буферизации рисков и трех точечной оценки.
Обычно, достаточно. Но дело в том, что моя точка зрения на последовательность работ может не совпадать с реально-возможной, а также инпутами от команды. Потому мы делаем это вместе. Лично я использую PERT всегда, когда мне нужно определить даты ключевых событий. Начиная от двухстадийного проектирования завода, заканчивая сайтиком как в примере.
2.
Вы пишете статью, о том как производить декомпозицию работ. Это основной посыл, так гласит заголовок. И делаете явную ошибку в первом же абзаце.
Тут не понял. Статья называется «Вest practice по ПЛАНИРОВАНИЮ РАБОТ». Составление WBS это первый основной кейс этого планирования. Никакой ошибки не вижу.
3.
А потом эти люди(лиды, програмисты, QA, QA лиды), приходят к ПМ-у и морочат голову не корректной WBS с извращенной точкой зрения. Единственная моя цель указать на явную ошибку.
Никакой ошибки нет, есть только ваше мнение. Да и ситуации такой не будет, если планировать работу вместе с командой, или снабдить команду простыми методическими указаниями по декомпозиции (снабжал ребят своего многуважаемого подрядчика вот такой штукой, как пример take.ms/yUlBl , take.ms/Ll1rW
4.
Я понимаю, что вы выделили ключевые практические результаты(deliverablies) , на своей доске, хороший подход. Только почему они не нашли отображения в WBS и календарном плане? А книжки как раз пишут об обратном. (и не только книжки)
В WBS они как раз нашли отражение. Еще раз повторюсь, что мне лично было удобнее делать календарный план посмотрев на WBS с другой точки зрения. Проще говоря, WBS одна и это понятно. Это набор задач которые нужно выполнить, чтобы получить промежуточные и финальные цели. Представьте себе их в виде списка с такими аттрибутами для каждой позиции, как deliverable и work type. Я могу группировать эти данные как по одному аттрибуту, так и по другому. Задачи в остаются те же, их последовательность остается та же. А как я их сгруппирую в Ганнт чарте — мое дело, исходя из ситуации и здравого смысла. В данном случае чтобы считать время по компонентам (читайте, бюджет) — все сгруппировано в Redmine по deliverables. Это для начальства. Но график является моим личным инструментом для вычисления сроков по ключевым событиям и он лучше читался с WBS группированной по видам работ / типам задач.
5.
График работ рекомендуется делать таким образом чтобы он повторял структуру WBS и отображал практические результаты(deliverablies) в противном случае вам нужно вести двойной учет или делать дополнительные трансформации над данными учета, и вам очень повезет, если ваши учетные системы позволяют это сделать автоматически. Ваш выбор конечно, тут не поспоришь.
Вы правы. Рекомендуется. И так и нужно делать, в контексте, если график работ является «общественным» артефактом и/или артефактом по которому ведется учет. В данном контексте — весь учет в Redmine/Jira/Youtrack. В IT не видел еще ни одну компанию, которая бы пользовалась учетом, скажем, в MS Project (ну правда, не встречал. Дорого, неудобно). Хотя встречал систему котрую сделали в одной большой фарм-компании. Совместили MS Project Server с Jira. В этом случае вы совершенно правы, двойной учет и оргомный головняк. Но это уникальный случай.
6.
Ваша апелляция к внутреннему проекту и внутреннему финансированию неуместна, проект есть проект стандарт, есть стандарт. Есть здравый смысл, наработки других компаний, практический опыт.
Я опирался на здравый смысл, т.к. читать график в котором работы сгруппированы по deliverables take.ms/lr3tB было не так удобно, как читать график сгруппированный по work types take.ms/RjtC4. Мой инструмент, мой артефакт. Мое решение.
7.
Единственный аргумент который работает в вашем случае, что о такой структуре вы договорились с заказчиком, не важно, внутренний или внешний, и по такой структуре вы будете отчитываться. Другие аргументы не работают.
В противном случае вас ждет увлекательный мир математики, ручной обработки отчетов, двойного учета, с неизбежным вопросам «а почему расхождение в N часов из прошлого периода???!!!!» при составлении отчета о ходе проекта. Если вам так удобно выбор безусловно ваш! Как руководитель вы несете ответственность и за свои решения тоже.
Совершенно согласен. Потому учет ведется через таск-трекеры, а не через Gantter for google drive. Необходимое условие для избегания головняка — чтобы WBS была актуальна. За этим, увы, приходится следить.
8.
Простите, но давайте людям правдивую и правильную информацию. Правильный и грамотно составленный WBS помогает. Не корректный, это боль для всей команды без исключения, боль которую вы собственноручно создаете (... мне так удобно...) .
Согласен. Одноко моя WBS составлена корректно и внесена в таск-трекинговую систему. Каждый таск заасайнен на исполнителя, проэстимирован и трекается ежедневно с логированием spent time. В Redmine. Члены команды работали над последовательностью вместе, каждый знает какой тикет у него в работе и какой следующий. Gantter — как инструмент ОПРЕДЕЛЕНИЯ СРОКОВ под которые мы с командой подписываемся.
9.
Я еще раз рекомендую вам пересмотреть свой взгляд и на Service Tasks в часности. И подумать куда все эти задачи можно положить, а их можно и нужно положить в компоненты. Если бы ваши практические результаты были в плане, то такой вопрос отпадает сам собой.
Подумаю над этим. Если это будет удобно и полезно — обязательно запихну их в компоненты)
10.
Моя статья рассматривала ПОДХОД к декомпозиции и планированию на основе PERT применительно к разработке софта, а не единственно-правильный способ построения WBS по web проектам
Более бредового ничего не слышал (... подход к декомпозиции через PERT...) в Ригу через Горловку на карете впереди лошади.
PERT --- это из управление расписанием, а WBS --- это из области управления объемом работ. Скажите, по теории и на практике, что делается сначала? Определяется объем работ или составляется расписание? Не учите людей бредовым подходам!
Еще раз продублирую фразу, только поставлю акцент на слове «планированию»:
Моя статья рассматривала подход к декомпозиции и ПЛАНИРОВАНИЮ на основе PERT применительно к разработке софта
Таким образом, PERT является техникой для оценки времени выполнения проекта (его части). Т.е. речь идет про планирование. Которое, конечно же, невозможно сделать без декомпозиции обьема работ и оценки продолжительности этих работ. Статья называется «Вest practice по ПЛАНИРОВАНИЮ работ». Первым идет кейс по созданию WBS, вторым идет кейс про сетевое и календарное планирование (основа — PERT). Что тут бредового?
11.
Не учите людей бредовым подходам!
— т.е. по вашему, PERT это бредовый подход? Я думаю вы не это хотели сказать, уверен. А у людей есть мозг, чтобы думать и отличать берд от полезных вещей.
12.
Ваш личный пиар удался, вы привлекли внимание к своей персоне, поздравляю.
Возможно. И если это так — то и благодаря вам в том числе=)) Уверен, если бы мы встретились в жизни — наверняка бы нашли общий язык. Во всяком случае, это пока лучший срач в комментах за время жизни моей статейки. И в любом случае, не смотря на возможные различия во взглядах — всегда готов пожать вам руку, коллега.

Ведёте себя как корпоротивный тролль,
Акцентируете внимание на деталях и инструментах, которые не представляют, лично для меня, и мало интереса для аудитории, отстаиваете «ваше мнение» «ваш кейс» тыкаете мне моим мнением, хотя я привел достаточно аргументов в пользу своего, вырываете фразы из контекста. От этого очень сложно вести осмысленный диалог.
Ваша «статейка», так вы её назвали, к сожалению, не тянет на best practice, достойный кандитат корпоративный бложик.
Вам указывают на ошибку\спорный момент, а вы воспринимаете как возможность затеять"срач в каментах" . невежливо, некрасиво. WBS всегда было и будет камнем преткновения особенно в разработке ПО, особенно у начинающих, но в конце-концов каждый находит свой путь.

встретились в жизни — наверняка бы нашли общий язык
Навряд ли. И тем не менее жду статьи о рисках. Интересна ваша точка зрения в конкретном случае.

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

Признаю, я ошибся.

Моя статья рассматривала ПОДХОД к декомпозиции и планированию на основе PERT
«подход к декомпозиции И планированию». Вот эту часть я прочитал не верно.
по поводу бредовой идеи беру свои слова назад.

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

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

Задачи в остаются те же, их последовательность остается та же. А как я их сгруппирую в Ганнт чарте — мое дело, исходя из ситуации и здравого смысла. В данном случае чтобы считать время по компонентам (читайте, бюджет) — все сгруппировано в Redmine по deliverables. Это для начальства. Но график является моим личным инструментом для вычисления сроков по ключевым событиям и он лучше читался с WBS группированной по видам работ / типам задач.
Да, вы так решили, что вам так удобно, это ваше право.

Да,я в вами не согласен, это мое мнение. Две формы отчета. разные срезы. Нести в массы эту идею пагубно. Не вижу проблем вести в Гантере такой же WBS который вы ведете в Redmine, а если нужен отчет типам работ всегда можно сделать через типы ресурсов. Для чего может понадобиться --- проверка загрузки ресурсов и расчет необходимого количества людей. Для расчета календарной даты подойдет и WBS. Расчет календарной даты по типам работ ну зачем? что это дает? На какой вопрос отвечает? Определить когда закончатся все работы по Фронтенду или Бекэнду? для чего? с какой целью? Что вы себе нафантазировали, Людей с толку сбиваете.
Нет, повода делать и сопровождать две разные структуры с одними и теми же задачами. (Слукавил, уже бегущий проект в котором уже сложно что-то поменять). Я понимаю что у вас в проекте 10 стараниц 60 задач и работы часов на 500-900. И человек у вас в команде 3-7. Обновление плана у вас нанимает 15 минут ручном режиме. Вы можете позволить себе роскошь вести структуру для себя и для начальства. Но когда у вас часов N уходит на то что бы составить недельный отчет на 20-30 человек в ручном режиме, Вы быстро остудите пыл в поддержании двух структур. И станет непозволительной роскошью тратить два раза по N часов. для себя и для начальства.

Ваш личный график(план-календарь) выпилите из статьи и смотрите в него лично ибо портит он хорошую идею статьи. Лучше покажите как сделана структура в Redmine, будет вам респект и уважуха. А может и то и другое одновременно.

Успокойтесь, пожалуйста. Да, ваш конкретный случай, ваш контекст, ваше видение, ваше мнение и все такое ваше... теперь внимательно прочитайте, что вы пишите....

Еще раз. Service tasks это контейнер для вспомогательных работ, которые были ЗАПЛАНИРОВАНЫ исходя из СУЩЕСТВУЮЩЕГО контекста, но не относились непосредственно ни к одному из deliverables. Но каждая из этих работ была реально необходима, т.к. она блокировала совершенно конкретные работы, которые относились к какому-либо из deliverables непосредстенно.

(...ни к одному из deliverables....)
Не надо обобщений.
Задача относиться к дизайну, но которого все таки был deliverable. О чем вы и пишите ниже

Возвращаемся к контексту. Дизайн был. Маrkup review:Design — обязательная задача по ревью верстки дизайнером и выдача замечаний для правки. Хорошая практика, кстати.

Да, это хорошая практика. Здорово, что вы это понимаете. Время двигаться дальше.
Ревью относиться к дизайну, если можно сделать с этой задачей значит к остальным применимо. Если вы не видите как сейчас, возможно, на следующем проекте вы сможете исправить ошибки.
Конечно, если регламент ведения проектов позволяет сливать задачи, которые вы не можете определить в конкретные категории или результаты в одну «помойную яму» --- это явно НЕ best practices.. Не надо такое людям такое советовать.
А так в целом неплохо, про сase study 2 читайте ниже.
P.S. для самоутверждения не отвечать на каждую строчку, комментария уже лет 10 как не модно.
P.S. для самоутверждения не отвечать на каждую строчку, комментария уже лет 10 как не модно.
Я не ориентируюсь на моду). Мода — это не мое...увы.
А ревью дизайна относится ко всем компонентам вместе. Вот давайте рассмотрим кейс вместе. Может вы что-то дельное посоветуете. Исходные данные:
1. Есть WBS по разработке сайтика, построенная по компонентам. Каждый компонент — это страница сайта. Всего около 10 предположим.
2. В каждый компонент входит конкретная работа, к примеру Component name:Design, Component name:Frontend итд.
2. Необходима задача для дизайнера на ревью верстки. Примерно 3 часа.

Куда бы вы ее засунули?

«Реаью верстки» чего? Сразу простите вопрос.

Зависит от длительности работ и композиции
Вариант 1
10 работ по ревью в каждом компоненте,
А дизайнеру сделал бы еще чек лист на 10 пунктов каждая из которых страница
Ну это так что бы дизайнер не путался что он проверил а что нет.

Вариант 2
одна работа под сайтом, или в компоненте дизайн я бы сделал дизайн компонентом. (Но опять же от ситуации)
И дизайнеру чеклист из 10 пунктов в описании к задаче. или отдельно. Зависит от условий работы.

Левел изи.

По моей практике именно дизайнеры начинают компановку WBS поэтому проблем с идентификацией работ у нет нет.

Если рассматривать случай вашего проекта,
То логично положить задачу в компонент дизайн и снабдить её листом проверки(чеклист).
Как доставить чеклист по назначению я тут не советник.

Ответьте на вопрос.
Без ревью страница считается законченой?
И вы сами получите ответ куда ложить задачу, вот алгоритм
Если ответ на вопрос: НЕТ!
делаем 10 задач под каждый компонент 3часа=180минут/10 задач = 18 минут на задачу.
Если ответ на вопрос:ДА!
вопрос 2: Считается ли дизайн сайта законченым без ревью?
Если ответ на вопрос 2: НЕТ
Пишем 3 часовую задачу ревью в компонент дизайн, и прописываем к ней DOD или чеклист, нужное выбрать по вкусу или настроению ПМ. Точнее смотреть в Плане Управления Проектом.
Если ответ на вопрос 2:ДА
Мы что-то сделали не так. Проверить cвериться с WBS Dicrionary, и требованиями. найти дефект и устранить.

Да кстати, 3 часа задача, а как это ложиться в ваше утверждение

Также мы с командой использовали метрику «правило шести-восьми часов». То есть никакая отдельная работа не должна занимать меньше 6-ти часов и больше 8-ти часов работы определенного специалиста
Я полагаю мы рассматриваем гипотетический случай, на примере вашего проекта.

Хотелось бы посмотреть на план проекта 4000 часов и дедлайном в 4 месяца в котором есть backend, frontend, iOs, Android, QA, BA, Design и активности в виде Meetings, CodeReview, Refactoring, Unit Tests, Continuous Integration.

P.S. Такие микропланы как у автора не панацея а самообман. Давно наблюдается уход от планов в сторону фиксированных затрат, сроков и не фиксированных фич. А дедлайны достигаются увеличением ресурсов и сверкой итеративно по burndown chart или % инкриза.

Есть пример проекта по разработке мобильного приложения под Android и IOS в сумме чуть меньше 3000 часов по fixed price контракту (можем обсудить отдельно, если желаете).
Также добавлю, что проект в 4000 часов с дедлайном в 4 месяца планируется немного по-другому, но на таком проекте составить еще более необходимо, чем на любом другом (есть фикс дедлайн, не дай Бог фиксированный бюджет и оооочень много рисков). Но принцип тот же — декомпозиция, увязывание в PND, назначение ресурсов, оптимизация PND и переход к календарным планам (исходя из условий задачи, дедлайнов и необходимых результатов). Подход описанный в статье легко масштабируется на любой размер проекта (где-то ниже уже писал об этом), т.к. этот подход классический и основан на математике и технике PERT (кстати, впервые был применен при разработке ракетной системы Polaris и оснащения ей субмарин, т.е. уровень масштабирования подхода вы, наверное, можете себе представить). План проекта в таком случае будет значительно более высокоуровневый и меня уже не слишком будут интересовать микроработы на уровне отдельной команды (для этого есть PM более низкой иерархии или тимлиды, пларирующие более низкий уровень работ в масштабах вверенных им юнитов/команд, и идующие потом по burndown chart’aм или как им там будет удобно, т.к. общая картина им не обязательна и часто не интересна). Меня будут интересовать отдельные дедлайны по отдельным высокоуровневым пакетам работ (в вашем случае это могут быть как компоненты мобильного приложения по отдельности, так и пакеты в которые входит несколько компонентов, или как вы решите исхдя из требований к финальным результатам и их кондиции). Т.е. весь вопрос в масштабировании подхода.

И еще хотел уточнить по поводу

P.S. Такие микропланы как у автора не панацея а самообман. Давно наблюдается уход от планов в сторону фиксированных затрат, сроков и не фиксированных фич. А дедлайны достигаются увеличением ресурсов и сверкой итеративно по burndown chart или % инкриза.
. Я не совсем понял, что имелось в виду и как могут сосуществовать фиксированные затраты и сроки рядом с нефиксированными фичами. По поводу движения дедлайнов увеличением ресурсов — эта тема старая как мир и отлично раскрыта множеством уважаемых авторов, как современных, так и древних классиков (как Фредерик Брукс, например). Подход конечно работает, но в зависимости от задач. К примеру если копать котлован — то как правило работает. А если рожать ребенка — то девять мам всеравно не родят одного малого за 1 месяц)).
Давно наблюдается уход от планов в сторону фиксированных затрат, сроков и не фиксированных фич.
Имелось ввиду, что затраты-сроки фиксированы, а скоуп — нет. Т.е. мы за месяц и 100 гривен сделаем не весь продукт, а столько, сколько успеем, не подписываясь на конкретное содержание.

Если я не прав в трактовке, то я тоже не понял, о чем речь =)

Когда я проходил тренниг в УПМА ( academy-pm.com.ua ), то при более простой задаче посложнее была сетевая диаграмма PERT...

Очень интересная статья, поддерживаю по поводу рисков. Хотелось бы узнать более подробно. как оценивание, что учитываете. спасибо

На последующем этапе остается только оценить влияние рисков (что не входит в содержание этой статьи, так как это совсем другая история=)).
это секрет судя по всему :)

Да нет. Просто это тянет на отдельную статью и плюс все зависит от контекста, т.к. подходы к оценке рисков для проектов по Time and Material отличаются, скажем, от оценки рисков по Fixed Price модели. Потому, это довольно широкая тема, которая зависит от конекстов (и от этого становится еще шире))

По оценке рисков в Agile проектах очень круто предподносит материал Сергей Поваляшко (был на его тренингах по этой теме). Очень толково и по существу. Перепечатывать его материал в своих статьях не рискну, т.к. будет плагиат и как следствие — плохая карма.

это тянет на отдельную статью
Вот и тема для следующей статьи :)

Только пусть пишет ее аккуратнее, без провокационных вбросов и безапеляционности. Указывает рамки, в которых его подходы работают.

Интересная статья и логичное разложение всего роуд мапа. Мне было бы интересно узнать, как бы вы посоветовали управлять рисками(не уложиться в срок) если к примеру, разработчик смотрит на задачу и говорит: «задача очень сложная для технологии А, которой я владею, я могу решить, но очень криво. Я знаю или слышал, что технология Б может все решить проще и качественней, но мне надо время, чтоб с ней разобраться. Я еще не знаю, решит ли она точно нашу проблемму, возможно и нет». Тоесть вы понимаете, что а) код будет фиговый и его сможет поддерживать только человек, его писавший или б) новая технология возможно решит проблемму, а возможно время будет потрачено впустую. Есть ли возможность или имеет ли смысл обьяснять заказчику ситуацию и пытаться продать ему время, затраченное на R&D, аргументируя это тем, что в будущем код будет проще поддерживать? Думаю вопрос не актуален для маленьких команд но актуален для проектов продолжительностью год и дальше.

Думаю, что заказчику нужно ОБЯЗАТЕЛЬНО попытаться продать время на ресерч и уведомить его о возможных вариантах, т.е. с ресерче и без. При этом лучше заранее подготовить ориентировочные «плюсы» и «минусы» этих подходов, желательно хотя бы ориентировочно выраженные в долларах США (или какая там актуальная валюта). Оба варианта рискоемкие, но заказчик должен быть проинформирован и он должен принять решение, а не вы за него. Я не знаю точного конекста, который вы имели в виду, но в контексте проекта по Agile методологии — я бы сделал именно так, т.к. видел другие варианты и это были фейлы.

При этом лучше заранее подготовить ориентировочные «плюсы» и «минусы» этих подходов
Из какого кармана это оплачивать будете? Попросите программиста подготовить оное в субботу-воскресение, понятно без оплаты в двойном размере.

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

Название каждого элемента включало в себя:
— Название высокоуровневого компонента (группы страниц сайта);
— Названия суб-компонента (конкретные страницы сайта);
— Название конкретного вида работы (например Frontend).
Можно подробнее? До этого субкомпоненты это дизайн, Frontend, Backend. Здесь это «конкретные страницы сайта», а Frontend — название конкретного вида работ.

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

Всё красиво, вот только северный пушной зверек обычно прячется в гантовских диаграмах. Вы уже научились предсказывать будущее?
Не, с ними все хорошо, когда известна скорость выработки болванок станком, но с типичными програмерскими задачами всё хуже. Никогда не знаешь точно, сколько займет та или другая задача. И в результате все эти гантовские картинки гроша ломаного не стоят. Предполагаешь, что 3 дня, а оказывается, что 3 недели или вообще несколько месяцев.
Вот отсюда и вытекает потребность в итеративных подходах. Когда ты имеешь примерный набор задач (и их последовательность), что нужно сделать, но задачи определяются на ближайший период времени не дольше 2-3 недель. И уже в зависимости от успехов в них определяешь, что делать дальше.

Предполагаешь, что 3 дня, а оказывается, что 3 недели или вообще несколько месяцев.
это порочный подход. Именно поэтому было выбрано правило дробить до 8 часов как минимальный обьем. При таком подходе у разработчиков работа в начале делается в голове до того, как они к ней приступают, т.к. чтобы дать эстимейт на задачу ее нужно осознать. Безусловно работает не всегда и есть риски отдельных работ затянуться. Но эти риски известны и с ними нужно работать. По поводу 2-3 недель — подход тоже работает. Я написал про это в каком-то из комментов ниже)

У меня большие сомнения, что можно с точностью до 8 часов спрогнозировать задачу, которая будет выполнятся через 3-4 месяца.
Все это приводит к тому, что finish уплывает далеко за горизонт

Это не всегда просто и как правило не нужно. Но, если есть требования, как функциональные так и архитектурно-значимые — удается нормально планировать задачи с приблизительным обьемом в 16 часов работы. Плюс если задача будет выполняться через 3-4 месяца, то оценивается обычно весь пакет (например большой компонент системы с запасом, к примеру точность может составлять −10% + 30%) и детализировать уже методом набегающей волны ближе к делу. На самом деле есть много подходов, в этой статье я не рассматривал долгосрочные проекты. Про это могу написать отдельную статью (есть хороший опыт).

Плюс если задача будет выполняться через 3-4 месяца, то оценивается обычно весь пакет
Не работает. Например оказывается, что входные данные настолько зашумлены, причем случайным шумом (не белым, розовым или подобными), что типичные алгоритмы не работают и надо искать пути. Или железо менять, или придумывать, как избавиться от шума или как в этих шумках выделить нуджное или как учесть этот шум и т.п. Подобных проблем возникает море.
Спрогнозировать можно, только если точно такая задача уже делалась.
Могу сказать, что синтез русской речи делался (в известной конторе) именно на чистом итеративном походе, хотя для начальства вначале были нарисованы красивые графики, на которые тут же и забили. Как сейчас модно говорить делалось спринтами по 2-3 недели и выбирались задачи по приоритету в этот текущий момент времени. За 2 года сделали. Понятно, что не случайно всё делалось, общий план последовательности крупных работ был заранее продуман.

Работает)) Делали проект по fixed price (была спека, API definition и все такое до начала разработки). Я заложился по срокам на возможные риски (которые также оценили). Попадали в сроки, все было нормально. Думаю, это зависит от проекта и его предметной области. Так что может быть по-разному. Но на интервале до 2х месяцев эта метода себя полностью оправдывает. Не говоря уже о проектах реального сектора экономики.

Думаю, это зависит от проекта и его предметной области.
Именно и то, что великолепно работает в одной будет не работать в дургой.
Да, я тоже люблю диаграммы Ганнта, но с ними не так всё просто и часто они не возможны толком, разве что отразить последоовательность крупных частей большой задачи. Вот то, что сейчас делаю вообще от них отказался. TODOList больше подходит (единственное, нет в нем возможности зависимость задач друг от друга делать).

Ну все же от меня требовали сроки. И к сожалению, я не знаю другого способа кроме планирования, чтобы иметь дело с этим take.ms/HTfmq когда от меня требуют сроки =)

Да, посему рисуешь фикцию для требователей, они всё одно дальше красивых картинок ничего смотреть не будут. А проект делаешь уже по другому. И вот именно 2-3 недельные этапы очень помогают. Всегда можешь показать, какие улучшения появились. Требователям же важно обычно только одно, знать что «процесс идет и все в работе».

Фикцию стараюсь не рисовать. Нет смысла, т.к. все равно не попаду в даты и еще и обманщиком буду. Но перед тем как озвучить дату, я планирую работу по методике описанной выше, плюс закладываю влияние рисков. И в 80% случаев попадаю в эту дату, или чуть раньше. И примерно в 20% попадаю за эту дату, но не на много и всегда имею возможность оценить насколько мы опаздываем и переиграть ситуацию. По поводу требователей — вы правы, но в моем случае их интересовали даты, т.к. требователи не редко дают обещания своим требователям и очень неловко себя чувствуют потом, когда фикция вскрывается. А уж как я бы себя чувствовал в этом случае — даже не фантазировать. Никто не любит «этих разговоров». Особенно их не люблю я))

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

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

Но многих проектах сам проект большая неопределенность. Правда в Украине они редки. Да — это чаще всего НИОКРы.

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

Илья, это несколько другая история. Тут описана методика, которая работает в условиях, что :
1. Обьем MVP версии известен и утрясен
2. Клиенту/менеджменту нужны конкретные даты.

После запуска MVP версии проект начинает развиваться по привычным Agile подходам с итеративной разработкой. Но опять же, спринты продолжительностью от 2х недель — также можно / удобно планировать по такой методике. Если требования меняются в середине спринта — то у проекта проблемы и тут вопросы нужно решать уже вообще по-другому.

В общем же случае с ситуацией, когда

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

Да, полностью согласен :) Вот этого в статье и не хватало:

Илья, это несколько другая история. Тут описана методика, которая работает в условиях, что :
1. Обьем MVP версии известен и утрясен
2. Клиенту/менеджменту нужны конкретные даты.
3. Клиент адекватный и понимает, что он хочет и получит.
Если требования меняются в середине спринта — то у проекта проблемы и тут вопросы нужно решать уже вообще по-другому.

Если? Покажите мне хоть один проект, где этого не происходит )

Кейс: заказчик не хочет Agile разработку, т.к. считает, что это высасывание его денег. Он решил действовать по-другому: "Я закажу у этих ребят бизнес-анализ как отдельный скоуп, пойму что мне нужно и что я получу (в этом скоупе он получает прототип и спеку), а затем оценю бюджет и приблизительный срок по этому обьему (!!! очень важный момент). И только потом закажу реализацию (и возможно, даже по Agile методике, но с известным обьемом это превртиться в Waterfall из спринтов). Американские коллеги изображают этот подход примерно так take.ms/QZy44

Корень зла кроется вот в этом отношении «заказчик-исполнитель». Как только «исполнитель» начнет делить риски «заказчика» — тут и начинается аджайл )

Эм, ну waterfall и waterfall. А причем тут best practice?

Причем тут Waterfall?)) Это методика планирования без привязки к методологии.

Вы спланировали строгую последовательность работ с привязкой ко времени, это не waterfall? Причем с действительно высокой детализацией

Кейс: планируется спринт. В бэклоге есть вполне определенные фичи, которые нужно поставить. Продолжительность 3 недели. Клиенту кровь из носа нужны 2 билда, каждый из которых будет содержать определенный функционал (первый- промежуточный, второй «товарный»). В конце спринта — демо инвесторам/другое ключевое для клиента событие. Вам нужно определить реалистичные даты по билдам, при этом понимать у кого и когда будет овертайм (если будет) и вообще, вы влазите с этим обьемом и с этими ресурсами в эти 3 недели, или нет? Выходит что методология работы в общем — из семейства Agile, но каждый спринт — это мини Waterfall. Данная методика — масштабируется (с соответствующими упрощениями/усложнениями) на любой обьем работы, который остается более-менее неизменным в единицу времени. Будь то спринт в 2-3 недели, MVP версия на 2 месяца, или fixed price проект на 3000 часов. Суть — в упорядочивании хаоса там, где его есть смысл упорядочить. Думаю, это разумно. Вы согласны с такой постановкой?

Безусловно, я вообще не адепт Agile, и вполне нормально отношусь к каскадной модели . И решение активно вовлекать в планирование разработчиков оцениваю сугубо положительно.

Просто это уже 3я публикация за два месяца (не на доу, в инете вообще), когда waterfall преподносится как что то новое и замечательное

Илья, я понял Вашу точку зрения и согласен с ней. Однако вынужден заметить, что Waterfall это подход к разработке ПО где все стадии протекают последовательно (и его тоже существует несколько разновидностей). В статье же описывается методика планирования, а не методология. Т.е. это только сходство с Waterfall’ом, но это все же разные вещи.

По моим наблюдениям, очень часто waterfall путают с так называемым plan-driven подходом. Автор, скорее, говорит именно о втором — никто же, например, не запрещает заложить в Gantt чарте регулярные демонстрации заказчику и сессии перепланирования?

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

Если, конечно, не сводить agile исключительно к extreme programming или kanban :)

Как же, ведь упоминались слова MVP и даже Бэклог!

Хороша стаття.

После коллективного обсуждения и согласия по последовательностям выполнения работ, наша PND начала обретать форму:
Якщо не помиляюсь, то здається українською PND називається сітковим графіком, чи ні?
В результате мы получили реалистичные даты окончания ключевых работ, выявили работы, требующие повышенного внимания (так как они лежат на критическом пути проекта), а также даты разработки MVP версии сайта в целом.
А в Google Gantter відразу показується і критичний шлях, і ключові роботи? (просто ніколи ним не користувався). До речі, часом не знаєте, чи є якісь хороші CRM/Task management рішення, які відразу й будують такі календарні графіки та показують яка частина робіт була виконана?

1. Да, эта диаграмма называется именно

сітковим графіком
=)
2. В
Gantter for Google Drive
на календарном графике отображается критический путь проекта (нужно поставить галочку в одном из меню). Если работы увязаны между собой правильно — это дает реальную картину.

Я добавил вехи. Заполнил ресурсы. У ресурсов есть стоимость чел/час. Как посмотреть стоимость реализации проекта общую теперь ? Как посмотреть отдельно за каждую веху? Спасибо заранее.

В Gantter’e каждая суммарная задача (т.е. та задача которая является контейнером для более мелких) — суммирует продолжительность, трудоемкость и стоимость всех подзадач. Самой высокоуровневой задачей является сам проект (он должен быть в самом верху списка задач и все задачи в проекте должны быть его дочерними задачами). Он суммирует все данные по работам которые в него войдут и даст примерную картинку по планируемым трудозатратам, продолжительности и деньгам. Нужно только включить в меню View отображение колонок, отвечающих за стоимость и трудозатраты take.ms/tezBk. Короче говоря, Gantter это урезанный Microsoft Project, но в веб-версии и бесплатный.

Ок, дякую) Часом незнаєте, чи є щось на зразок Asana/Redbooth, де можна автоматично такі графіки будувати? або чи можна Gantter for Google Drive інтегровувати із подібними рішеннями?

Только не Google Gantter, а Gantter for Google Drive.

Подписаться на комментарии