Руководитель разработки
6,4
рейтинг
17 сентября 2012 в 11:09

Управление → Использование MS Project для управления проектами по разработке ПО tutorial

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

Небольшое введение


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

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

Перед началом проекта

Перед началом проекта от руководителя проекта обычно требуется ответить на два вопроса:
  1. сколько проект займет времени
  2. сколько проект будет стоить

При этом важно понимать, что никого не интересует ответ вида «не раньше чем через полгода». Требуется как раз оценка сверху.
Примечание. Мне никогда не приходилось иметь дела с явными денежными оценками проекта, и, как я сейчас понимаю, это серьезное упущение. Все проекты, которыми я руководил, исполнялись сотрудниками компании. Команда проекта формировалась на всё время проекта, некоторые специалисты привлекались на определенное время. Фактически, от меня требуется оценка количества требуемых исполнителей, а также сроки их привлечения. Как мне кажется, это достаточно типичная ситуация для компаний, занимающихся разработкой ПО. В итоге все сводится к оценке трудозатрат, которая, с использованием эмпирических формул, превращается в оценку стоимости проекта. Как видим, присутствует прямая зависимость стоимости проекта от его сроков.


В процессе выполнения проекта

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

При завершении проекта

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

Что умеет MS Project


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

Разберем вкратце свойства сущностей.

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

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

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

Как это использовать


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


Подготовка плана

Итак, перед нами лежит техническое задание, и требуется дать ответ на три вопроса:
  1. Сколько времени займет этот проект?
  2. Сколько (и каких) специалистов для этого потребуется?
  3. Какие примерно трудозатраты ожидаются по этому проекту?

Для этого мы готовим прикидочный план выполнения проекта в MS Project. Т.е. просто последовательно выписываем задачи, которые необходимо выполнить. Методика превращения техзадания в набор задач — это отдельная история, я не буду на ней сейчас останавливаться.
Подготовка плана выполняется в несколько этапов:
  1. Готовим список задач
  2. Выставляем зависимости между задачами
    (результат какой задачи необходим для перехода к следующей?).
  3. Назначаем исполнителей задач
  4. Выравниваем загрузку ресурсов
  5. Балансируем то, что получилось

Общие рекомендации

При подготовке плана придерживаемся следующих рекомендаций:
  1. Не используем суммарные задачи для декомпозиции.
    Все задачи помещаем в один линейный список. Сначала это может показаться неудобным,
    но зато избавляет от многих проблем в дальнейшем. Для управления структурой задач
    используем настраиваемые поля (см.ниже).
  2. Очень часто для управления зависимостями задач используют Drag&Drop. Когда задач много это быстро становится неудобно. Я рекомендую в этом случае не использовать перетаскивание, а явное указывать номера задач-предшественников. для этого можно добавить в таблицу столбец «предшественники» и вписывать номера задач вручную.
  3. Срок каждой задачи не должен превышать двух недель.
    Если срок задачи превышает неделю — это уже повод задуматься о её декомпозиции. Я придерживался очень простой методики оценки: примитивная задача — 2 дня, средней
    сложности — 1 неделя, сложная задача — 2 недели. При этом сложных задач не должно быть много. Такой подход дает возможность подготовить оценочный план довольно быстро.
    С одной стороны, полученная оценка, конечно, не будет точной, но, с другой стороны — а какая из них точная? По опытку практического применения могу сказать, что на
    больших проектах погрешности оценок отдельных задач обычно нивелируются, а на малых часто можно (и нужно!) использовать и более точные оценки.
  4. Всеми силами избегаем задач, у которых несколько исполнителей. Для каждой задачи должен быть назначен только один исполнитель. Двух исполнителей имеет смысл назначать
    только если они действительно работают вдвоем (например, вы практикуете парное программирование). В прочих случаях лучше декомпозировать задачу.
  5. При назначении исполнителей руководствуемся их профессией и квалификацией, пока не беспокоясь о равномерности загрузки.
  6. Используем суммарные задачи для разделения задач на этапы. Ставим зависимости между этапами, чтобы они шли последовательно. Разделение на этапы пока достаточно приблизительное.

Список задач, разделенный на этапы
Список задач, разделенный на этапы

Балансировка проекта

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

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

Группировка задач по исполнителям
Группировка задач по исполнителям

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

Дальше начинается магия балансировки. Требуется минимизировать сроки выполнения каждого этапа путем обеспечения более-менее равномерной нагрузки на всех участников проекта. Для этого мы выполняем следующие действия:
  1. Сменить исполнителя задачи.

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

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

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

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

Учет рисков

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

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

С этим планом мы можем:
  1. Назвать сроки выполнения проекта и его этапов. Аргументированно и с высокой степенью
    достоверности.
  2. Оценить примерные трудозатраты по проекту

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

Работа с планом

Когда проект запускается в работу, исходный план, который использовался для оценки, можно использовать и для отслеживания выполнения проекта. От руководителя проекта требуется регулярно выполнять следующие действия:
  1. Выдавать задания исполнителями
  2. Отмечать выполненные задания в плане
  3. Корректировать план в случае значительных отклонений

Выдача заданий исполнителями может выполняться по разному. Можно разбить выполнение на короткие итерации, формировать пул задач на итерацию и по окончании итерации отмечать результаты. Можно сразу озвучить лнителям набор задач на этап, выдать каждому по экземпляру диаграммы Ганта и периодически опрашивать о прогрессе. Можно использовать интеграцию MS Project и TFS и загрузить проект непосредственно в TFS. Суть не в средствах. Главное — это регулярное обновление плана. Я делаю это примерно раз-два в неделю. Это дает возможность достаточно быстро увидеть проблемные участки.
Для определения проблемного участка удобно использовать различные группировки — по исполнителями, по компонентам и др. Часто может оказаться, что проект в целом идет даже с опережением, но в определенном разрезе наблюдается отставание, например один из разработчиков неожиданно уткнулся в серьезную системную проблему, которая привела к отклонениями. Использование только средней метрики не покажет этой проблемы — она всплывет только в конце этапа, когда что либо делать будет уже поздно.

Отслеживание выполнения с группировкой по компонентам
Отслеживание выполнения с группировкой по компонентам

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

Есть другая стратегия — внесение изменений в сроки задач, «выталкивая» невыполненные задачи вперед. При таком подходе для отслеживания отклонений от плана можно использовать другую полезную функцию MS Project — базовый план. Базовый план — это просто сохраненный снимок состояния задач. Его можно сделать в начале проекта. Для сравнения текущего плана с базовым, открываем «диаграмму Ганта с отслеживанием». Для динамичного плана, когда порядок выполнения задач часто меняется, это может оказаться неудобным, поэтому я вставляю в проект контрольные точки, отражающие некоторые важные результаты проекта, и отслеживать отклонения от базового плана только для них.

Диаграмма Ганта с отслеживанием
Диаграмма Ганта с отслеживанием

Управление структурой задач с помощью пользовательских полей


Я категорически рекомендую не использовать суммарные задачи в MS Project для функциональной декомпозиции или категоризации задач. Дело в том, что иерархия задач в MS Project сильно завязана на их последовательность. А часто хочется посмотреть на задачи в разной последовательности, при этом вся структура «рассыпается». Для управления структурой задач я рекомендую использовать Пользовательские поля. MS Project имеет предопределенный набор полей с неопределенным заранее поведением, которые мы можем использовать так, как нам удобно. Например, для разбивки задач по компонентам нужно на основе текстового поля Текст1 создать поле Компонент и задать для него список значений, соответствующий компонентам системы.

Создание пользовательского поля
Создание пользовательского поля

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

Группировка задач по компонентам
Группировка задач по компонентам
Пользовательские поля позволяют разделять задачи по нескольким категориям, например, я разделял задачи по типу работ: Разработка, Тестирование, Документирование.
Упомяну для любопытных, что в MS Project также можно задать правила рисования диаграмм на основе свойств задач. При желании, можно сделать так, что задачи по разным компонентам будут иметь разные цвета, причем цвет будет определяться только свойством задачи, его не нужно задавать вручную для каждой задачи. Такие настройки не требуют написания сриптов, а делаются штатными средствами настройки диаграмм.

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

Завершение проекта


В конце проекта мы получаем план, в котором все задачи выполнены. Обычно я стараюсь сохранять также и исходный план, хотя бы в качестве базового. Честно говоря, на этом этапе от MS Project мало проку, так как интересуют не плановые значения, а фактические. Какие-то решения этой проблемы предлагает MS Project Server, там есть возможность учитывать фактические трудозатраты, но это уже за пределами данной статьи.

Заключение


Я попытался обобщить свой опыт использования MS Project для практического решения задач, которые возникали передо мной, когда я руководил проектами по разработке ПО. Описанная методика не претендует не универсальность, но она, как мне кажется, достаточно проста и логична, при этом позволяет решать практические задачи руководителя проекта.
Использование этого подхода позволило мне успешно и в срок завершить не один проект.
Правда, случались и сбои. Это происходило, как правило, тогда, когда плохо была проведена подготовительная часть проекта, а именно — постановка задачи. Т.е. в результате проекта получалось не совсем то, что требовалось, а понимание этого приходило слишком поздно.

Наверняка я что-то упустил, не стесняйтесь задавать вопросы.
Романов Борис @ganouver
карма
53,0
рейтинг 6,4
Руководитель разработки
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Управление

Комментарии (38)

  • +2
    А я правильно понимаю, что управление проектами в вашем случае не распределённое? Т.е., с проектом работаете только вы, и не более?
    • 0
      Правильнее будет сказать — «управление планом». Да, управление планом — не распределенное. Это мой инструмент, как руководителя проекта. Я могу поделиться им с окружающими в ознакомительных целях, но всю работу с ним веду я один.

      Элементы «распределенности» я как-то использовал — выгружал задачи в TFS и подтягивал оттуда статусы по мере их изменения. Но меня это не сильно понравилось. Связка TFS — Project работает как-то топорно и неудобно, они явно сделали её «для галочки», реально пользоваться этим невозможно. Более того, на одном из семинаров посвященному TFS докладчик явно сказал, что этим функционалом можно пользоваться только в одну сторону: из Project в TFS.
      • 0
        Спасибо.

        Есть ещё вопрос: а есть ли какой-то функционал, позволяющий автоматически сообщать сотрудникам о присвоении задач их изменении? Насколько я понимаю, это можно делать при помощи Project Server, но было бы интересно узнать, чем вы пользуетесь?
        • 0
          Пока народу немного (в пределах 10 человек), хватает еженедельных совещаний :-)
          Т.е. задачи в TFS у человека висят для справки, что-то срочное — можно и сразу сказать, а несрочное — терпит до совещания.
        • 0
          Удобно с помощью ProjectServer и его плагина к Аутлуку. Инструмент работает хорошо, правда выходит отнюдь не бюджетным. (хотя и сам Project штука весьма дорогая)

          Какое-то время использовали это на моей прошлой работе в Украине. На текущей работе менеджер проекта просто раздаёт всем план и на еженедельных совещаниях информирует о задачах на неделю. Хватает. (но это проекты скорее из сферы Lean/CI и инфраструктурных изменений. Небольшая часть — управление разработкой/модификации ПО под эти изменения)
      • 0
        Связка работает прекрасно, если список задач и зависимостей сразу создавать в TFS, а MS Project использовать только для выравнивая загрузки: подгружать задачи в Project, поработать с датами, и потом опубликовать всё обратно в TFS.

        То есть база TFS при этом используется как первичное хранилище задач, а MS Project — только как надстройка, инструмент, предназначенный исключительно для планирования.
        • 0
          А TFS научился указывать зависимости между задачами? я с этой связкой работал году эдак в 2005, тогда в TFS создавать задачи было ужасно неудобно :(
          • 0
            TFS2010 точно научился. Более того, его переучили: там появилось множество разных видов зависимостей, с которыми не сразу разберёшься. Но при экспорте в MS Project, насколько я помню, учитывается только один вид зависимостей — простая последовательность, когда одна задача не может быть начата после завершения предыдущей.
  • 0
    Спасибо. За статью. Полезные советы. Единственно, что проецируя на свои проекты хочу спросить.
    Глядя на снимки вижу, что жизненный цикл вашего демо-проекта можно характеризовать как:
    Стартанули — версия 0.0
    Завершили — версия 1.0

    Ну это понятно, что для наглядности. Поэтому.
    Как обстоят дела с учетом времени отводимое на исправление ошибок? Вы как раз для этого и отводите время «прочие работы»? Как я понимаю вы ж их не добавляете как задачи. А если рассматривается несколько этапов, но каждый этап представляет собой релиз (который допустим рассматривается как законченный продукт). Допустим их будет штук 10 вперед. Вы создаете новый документ для каждого релиза, или продолжаете в текущем? Но тогда как я понимаю, список начнет расти ого-го как, придется долго проматывать…

    Спрашиваю потому, что как то был решил попробовать в альтернативном программном — Planner (в Linux сижу). Первый ваш этап был прошел — оценил сроки стоимость, но потом забросил, как-то все это отслеживать стало неудобно, когда пытался увязать, с текущим состоянием проекта. Redmine тот же именно для отслеживания хода проекта удобней в конечном счете для меня оказался. Но на начальном этапе, при согласовании сроков, согласен — отличное решение.
    • 0
      Это вопрос сложный и даже в чем-то философский. Если начать издалека — то есть два подхода: проектный и процессный.
      Проектный — это когда вы должны за конечное время создать некоторый продукт. Процессный — это когда вы организуете процесс таким образом, чтобы двигаться к некоторой цели.

      То что я описываю — это проектный подход. Релиз (продукт) образуется в конце проекта. Этап — это не обязательно релиз, это просто некоторый промежуточный результат. Обычно в конце этапа можно оценить как движется проект и скорректировать дальнейшие планы. Говорить о версии в начале и в конце тут сложно, потому как на старте может быть некоторый продукт, а в конце — этот же продукт, но «допиленный» под конкретного заказчика, его нужды.

      В такой ситуации исправление ошибок — это либо известные работы, либо фоновые. Например, мы знаем, что в среднем 10% времени у нас уходит на исправление ошибок, и это надо учесть. Можем включить их в «прочие работы» или удлинить на 10% оценки по срокам для остальных задач. Для получения оценок — это неважно. Но если говорить об управлении проектом — то наука рекомендует такие запасы времени вкладывать именно в конечный буфер (прочие работы).
      Другое дело, что вы в начале этапа можете заранее знать, какие ошибки есть и сколько времени у вас займет их исправление. Т.е. это уже не некоторая непредсказуемая фоновая деятельность — а конкретные задачи. Вот и оформлять их надо как задачи.

      Redmine (как и куча других подобных систем — Jira, Trac, TFS и т.п.) ориентирован, в первую очередь, на процесс. Он позволяет организовать командную работу, показывает кому какие задачи назначены, что сделано, а что нет. С его помощью можно оценить что происходит прямо сейчас. Но он совершенно не помогает управлять проектом — т.е. он не помогает обнаружить узкие места проекта, оценить сроки и т.п.

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

      P.S. Это не значит, что я против гибких методологий разработки, просто всегда надо понимать за чей счет банкет.
  • +1
    MS Project и MS Project Server занимаюсь с 2003 версии ещё.

    Отличная обзорная статья, не нашел ни одного разногласия со своим опытом и практикой!

    От себя хочу лишь добавить, что в некоторых случаях всё-таки есть необходимость использовать именно суммарные задачи. Но, действительно, не для «этапного» среза, или, допустим, когда весь блок внутренних задач и все последующие будут зависеть от полного выполнения суммарной задачи. Т.е., например, создание какого-нибудь функционала полностью влияет на все зависимые от этого функционала задачи. Тогда, пожалуй, имеет смысл их сгруппировать, чтобы эту суммарную задачу можно было назначить предшественником. Можно, конечно, предшественником назначать конкретную задачу цепочки, или, например, часто для MileStone (веха) — то, что вы назвали «контрольные точки» — поставить предшественниками все связанные с её выполнением задачи. Обычно такие «вехи» ставятся в конце создания какой-то важной фичи, влияющей на реализацию всего проекта «после» её (вехи) реализации. Т.е., когда, например, нельзя «двигаться» дальше до полной реализации какой-нибудь библиотеки.

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

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

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

    И тогда, если мы можем оперировать «финансовыми» показателями, то к анализу нам доступны не только отклонения трудозатрат, но и отклонения по стоимости. Есть ситуации, когда по трудозатратам мы можем идти «в ногу» со временем, а по стоимости «превышать» или даже «не догонять». Это всё весьма подробно описано даже в справочной системе к Project. Весьма рекомендую ознакомиться, позволит продумать всё, что нужно заложить на первоначальном этапе планирования. В частности срезы нескольких базовых планов могут оказаться весьма кстати (оптимистичные, пессимистичные и т.п., чтобы сравнивать с ними текущий и понимать почему финансовые отклонения случились и куда проект движется).

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

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

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

        Т.е., не чёткий рецепт, а более «обобщённое» направление действий.

        По существу, да, именно — единственный выигрыш «суммарной» задачи это «иерархичность», представления.
        Да, она может быть удобна, но только если «очень осторожно». Так, например, кроме описанных вами неудобств часть встречаются «продвинутые» менеджеры, назначающие суммарным задачам ресурсы и потом удивляющиеся что «план поехал». EPM предлагает использовать так называемую WBS — WorkBound Structure — метод Декомпозиции Задач. Т.е., определяя ключевые цели как задачи, мы начинаем декомпозицию до самых мелких структур, которые могут быть исполнены за 1-2 дня (конечно, есть исключения). Декомпозиция предполагает иерархию.
        Но, при этом, следует Подчеркнуть, что в этом «методе» есть важнейший аспект, касающийся, скажем так, названий. Работы обозначаются действием, а milestone обозначается «артефактом». Т.е. цель выполнения работ: создать сущность. Например (скорее всего не совсем удачно) — разработать библиотеку N декомпозируется на:

        1. создание ядра библиотеки
        2. создание функции 1
        3. создание функции NNN


        Milsetone всей декомпозиции тогда называется «Библиотека AwesomeName»

        И, в этом случае, когда над таким Milestone «возвышается» суммарная задача с % выполнения и % освоения бюджета, тогда «спонсору» проекта всё очень даже становится заметно: проценты как минимум должны совпадать с базовым планом, т.е. должно быть освоено сколько должно быть по плану :)

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

        «А почему для реализации библиотеки AwesomeName командой было потрачено в два раза больше денег? „


        Ответы могут быть разными, но они, по крайней мере, всегда будут четкими, например:

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


        :)
        • +1
          В общем, несмотря на преимущества, я для себя решил избегать суммарных задач для декомпозиции.
          Связано это с тем, что функциональная декомпозиция и зависимости для распределения по календарю — это вещи существенно разные. Поскольку суммарные задачи — единственное средство управления последовательностью выполнения для наборов задач, то я их использую для разделения на этапы. А для декомпозиции приходится использовать другие средства, хорошо, что они есть :)
    • 0
      Как у свежих Project Server со стабильностью?
      В позапрошлом проекте использовали Project и Project Server 2003. Менеджеры формировали план и назначали ресурсам задачи в MS Project, публиковали на сервер, далее ресурсы отчитывались в своих задачах каждый день через Web интерфейс, если надо то корректировали estimate и прочее. В результате проект жил и развивался весьма наглядно. Но вот стабильностью Project Server не отличался. Раз в неделю рестарт сервера — это стабильно (30 разработчиков + 5 менеджеров). А если как-то хитро-циклично задачи зацепишь друг за друга (сейчас не помню точный кейз, но помниться, я его все таки нашел) то падал чуть не при каждом пуке, пока их назад не разведешь. А как сейчас с этим?
      • 0
        В общем, не могу точно сказать, что я видел подобные ситуации в 2010.
        В 2007 да, были проблемы, но с постепенными выходами SP они решались.

        Мы от 2007 отказались в пользу 2010 на том моменте, когда из проблем осталась только зависавшая очередь заданий, и это вполне «лечилось» запуском спец. скрипта на СУБД. Если я не ошибаюсь это SP3.

        Именно Project Server 2010 (не MS Office Project 2010) лично я последний раз использовал в начале 2011 годаю
        В последнее время я слегка сменил профиль. Но, я продолжаю общаться с бывшими коллегами, имею возможность получить FeedBack. Никаких существенных Issue от них не поступает, т.е., пользуясь «информацией из проверенных источников» могу сказать, что «все вроде бы нормально».

        Только, пожалуйста, не воспринимайте как «мопед не мой, я просто разместил объяву»

        Можно даже говорить, что один раз освоившись с PMBOK, вам уже будет не так важен инструментарий.
  • 0
    Спасибо за обзор.

    Скажите, а в вашей работе какие задачи по разработке чаще встречаются — однотипные (сайты-визитки «под копирку», бизнес-автоматизация с фиксированным набором решений, веб-интерфейсы к базам данных) или разноплановые (приходит внешний заказчик и говорит, что теперь мы будем делать native приложение под android для offline работы с его медицинским каталогом)?
    • +1
      У меня обычно вариант промежуточный. Есть некоторый базовый продукт и на его основе делаются прикладные решения под некоторые частные задачи. Начиналось все как раз с проекта по созданию этого продукта. Не сказать, что задачи совсем разноплановые, но и не скажешь, что под копирку.
      • 0
        Я в целом поменьше вашего руковожу разработкой, чуть больше пяти лет. Но что успел заметить: если разработка не совсем типовая (сайты там, автоматизация), то значительная часть задач не имеют такого состояния как «трудоемкость» вообще. То есть я вижу задачу «сделать для отдела тестирования в отладочном режиме лог со стороны android» — и я без понятия, сколько это займет времени. Можно на вскидку предположить что человекодень — записать файл в локальную песочницу дело нехитрое, ну и найти относительно простой способ тестировщикам этот файл с устройства снять. А потом в процессе разработки «неожиданно» оказывается, что доступа в песочницу у тестировщиков нету, нужно им на компьютеры ставить сертификаты и писать мануал как это все устанавливать и настраивать, в процессе тестового развертывания «неожиданно» оказывается что сертификаты не всегда ставятся — потому что код для windows который сертификат импортирует писал один индус, а код OpenSSL который со стороны android toolchain этот сертификат генерирует — другой индус и у них разное понимание внутреннего мировоззрения «ASN.1»… Итого две недели на практике (пример, естественно, вымышленный — есть куча настоящих, но их в двух словах не расскажешь). И такое случается довольно часто, когда из-за того, что мы что-то делаем «в первый раз» (а иногда даже «в первый раз — и на stackoverflow об этом тоже никто ничего не знают») достаточно простые «на первый взгляд» задачи могут неожиданно увеличить свою трудоемкость на порядок, породить из себя дюжину подзадач или вообще переродиться, полностью изменив дальнейшую разработку (… а вот тут, через три месяца, мы неожиданно понимаем, что на реальных данных репликация для данной базы у нас работать не будет… ).

        Случаются ли у вас такие ситуации? Насколько часто?
        • 0
          И такое случается. Не скажу, что часто, но бывает.

          На мой взгляд, основная причина такого явления — недостаточное внимание постановке задачи. Утверждение, что это займет «неизвестно сколько времени» говорит, в первую очередь, о недостаточно проработанной постановке задачи — ровно то, о чем я писал в самом конце. Т.е. в постановке задачи осталось много недосказанностей. Недосказанность может возникать из-за того, что постановка недостаточно детальна (сочли, что все просто и так ясно), или из-за большого количества неизвестных величин (какие-то факторы, которые заранее неизвестны и их влияние непредсказуемо). Неучтенные факторы — это может быть и недостаточно налаженная инфраструктура, недостаточная квалификация разработчиков в новой для них области, ненадежная технология и т.п. Все это — риски. В промышленной разработке принято уделять внимание уменьшению влияния рисков. Для этого есть отдельный отдел, занимающийся инфраструктурой, новые технологии используются только после того, как кто-то набьет на них шишки и опишет их на stackoverflow и т.п.

          С опытом приходит способность смотреть на задачи пытливым взором и отмечать те, в которых нас ждут грабли. На такие задачи обычно закладывают дополнительные буфера времени, «на всякий случай». На самом деле, их обычно не так уже много. Гораздо опаснее те задачи, где за внешне простой формулировкой кроется большая работа. Вот определять их гораздо сложнее. Последний раз я капитально влетел на пару месяцев с задачей, которая оценивалась в три недели :-)
          • 0
            или из-за большого количества неизвестных величин (какие-то факторы, которые заранее неизвестны и их влияние непредсказуемо)


            Вот тут-то и беда, что таких задач очень много — из-за молодости отрасли в целом и ее бурного развития в частности. Соответственно от инструмента хочется как минимум деление на исследовательскую стадию и стадию разработки (которая после исследовательской стадии может и не наступить), какое-то минимальное управление рисками. А когда из инструментов только автобалансировка — становится непонятно зачем это вообще надо? Типовые проекты по изготовлению сайтов планировать? Так это и в экселе замечательно планируется. А для действительно сложных проектов значительная часть задач вида «тут надо предварительно покапать и разведать местность. В зависимости от выкопанного пойдем разными путями».

            Не нравится мне Project для управления IT проектами. ИМХО, все-таки специфика рисков, частое размножение / перерождение задач и слишком сильно специализированные ресурсы (Вася хорошо знает C++ но плохо Boost, а Петя знаком с Boost, но уровень C++ у него хуже) отличают эту область от остальных. Нужны специальные инструменты. А нету О_О.
            • +1
              Вы то мне и нужны!
              Я в последнее время работаю как раз в области управления проектами. И как раз сейчас стартую проект по разведыванию местности для создания планировщика проектов для разработчиков. Потому как у меня устойчивое ощущение, что его не хватает. Project, действительно, изрядно неудобен, а реальных альтернатив не видно :-( Вот хочется сделать в этом месте что-то хорошее, полезное и, по возможности, бесплатное. Мне очень не хватает аудитории, с которой можно было бы обсудить пожелания, потребности к подобной программе.
              Можно будет через какое-то время обратиться с вопросами?
              • 0
                Можно, личка к вашим услугам.
  • 0
    Автору спасибо. Не могу удержаться чтобы не задать вопрос.
    Дело в том, что тоже руковожу проектами. Правда специфика — проекты идут по конвееру. Поэтому идеальным решением была бы возможность создавать связанные проекты. Т.е. чтобы можно было программистов/дизайнеров делить между проектами да еще и с привязкой к календарю.
    В свое время я так и не нашел таких возможностей в MS Project, хотя очень хотелось. Это я плохо искал или данный инструмент действительно не рассчитан на мою задачу? Может кто подскажет другой инструмент для этой задачи?
    • 0
      Нет, эту возможность действительно весьма сложно найти. При соединении с Project Server эта функциональность как бы «в базовой поставке» (к тому же там используется другая версия MS Office Project, а именно Professional).

      Для «обычного» MS Office Project Standard при ответе на ваш вопрос необходимо использовать две функции MS Project:
      1. Общий пул ресурсов.
      2. Вставка проекта в проект.

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

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

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

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

    • 0
      Извините, ответ не туда написал :(
      Он вот здесь habrahabr.ru/post/151593/#comment_5146824

    • 0
      А не пробовали Jire по методике Kanban? Вроде как раз для конвеерных проектов.
  • +1
    Плюс к уже описанному варианту с MS Project можно воспользоваться следующими:

    1. Каждый проект создвавать и вести в MS Project, а межпроектные проблемы отслеживать в программах, которые позволяют просматривать
    несколько mpp одновременно. Например, LiveProject ProjectsView. И контролировать загрузку исполнителей.

    2. Использовать online сервис с нужной функциональностью типа Jira (с соотвествующим плагином) или LiquidPlanner.
  • 0
    Жаль, нет облегченной и более дешевой версии Project «для домашнего использования».
    • +1
      Как же нет?
      Аналогов у Project огромное количество.

      Навскидку из википедии:

      ru.wikipedia.org/wiki/GanttProject
      ru.wikipedia.org/wiki/OpenProj

      К тому же для самого Project есть trial версия ( 30 запусков ).
      Да, и если Вы, к примеру, студент, то получить Project можно несколькими более дешевыми способами.
      Вплоть до «бесплатных» например, по программе MSDNAA (academic alliance).

      • 0
        Не аналогов, а именно самого Project. А альтернативными путями не всегда удается воспользоваться, скажем, заочникам софт не положен.
        • +2
          Ну а для чего заочнику нужен MS Project? Для учёбы — маловероятно (я реально не смог придумать применения. А что придумал — покроется пробной версией на 60 дней). Для работы — в таком случае учебная лицензия и так не подходит. Ну а менеджер проектов может и раскошелиться на рабочий иснтрумент или выбрать альтернативу.

          Есть и on demand сервисы — www.microsoft.com/project/en-us/on-demand-hosting.aspx
          • 0
            Для личных проектов, фриланса и тому подобного. В шаблонах от МС даже строительство дома есть, например. В общем-то, любую подлежающую декомпозиции деятельность можно планировать там. Мне кажется, облегченная (безо всяких tfs и подобного хардкора) версия вполне могла бы найти своего клиента.
            • +1
              Ну так Project Standard — и есть облегчённая версия. Не нужен постоянно — найдите подходящий вариант on demand. Если хочется именно этот продукт. Есть ведь и альтернативы.

              Плюс многие простые проекты запросто планируются и в электронных таблицах, у нас так часто делают в Excel, потому как диаграмму ганта удобно «рисовать» и если есть один-два десятка задач, то этого вполне хватает.
            • +1
              Если для фриланса советую посмотреть на www.microsoft.com/bizspark/
      • +1
        «К тому же для самого Project есть trial версия ( 30 запусков )»
        не так — 60 дней. technet.microsoft.com/en-US/evalcenter/ee404758.aspx (собственно, и на офис, и на визио также 60 дней — совсем неплохо)
        • 0
          Спасибо за инфу!

          Последний раз просто видел триал 2007 Project, где было всё полнофункционально но на 30 запусков только.

          Если там есть 2 месяца, то это очень даже хорошо :)
    • 0
      А нужен именно Project? или аналогичная программа, которая помогает решать какие-то задачи?
      Если верно второе, то мне было бы интересны Ваши ожидания от такой программы.

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