Comments 38
А я правильно понимаю, что управление проектами в вашем случае не распределённое? Т.е., с проектом работаете только вы, и не более?
Правильнее будет сказать — «управление планом». Да, управление планом — не распределенное. Это мой инструмент, как руководителя проекта. Я могу поделиться им с окружающими в ознакомительных целях, но всю работу с ним веду я один.
Элементы «распределенности» я как-то использовал — выгружал задачи в TFS и подтягивал оттуда статусы по мере их изменения. Но меня это не сильно понравилось. Связка TFS — Project работает как-то топорно и неудобно, они явно сделали её «для галочки», реально пользоваться этим невозможно. Более того, на одном из семинаров посвященному TFS докладчик явно сказал, что этим функционалом можно пользоваться только в одну сторону: из Project в TFS.
Элементы «распределенности» я как-то использовал — выгружал задачи в TFS и подтягивал оттуда статусы по мере их изменения. Но меня это не сильно понравилось. Связка TFS — Project работает как-то топорно и неудобно, они явно сделали её «для галочки», реально пользоваться этим невозможно. Более того, на одном из семинаров посвященному TFS докладчик явно сказал, что этим функционалом можно пользоваться только в одну сторону: из Project в TFS.
Спасибо.
Есть ещё вопрос: а есть ли какой-то функционал, позволяющий автоматически сообщать сотрудникам о присвоении задач их изменении? Насколько я понимаю, это можно делать при помощи Project Server, но было бы интересно узнать, чем вы пользуетесь?
Есть ещё вопрос: а есть ли какой-то функционал, позволяющий автоматически сообщать сотрудникам о присвоении задач их изменении? Насколько я понимаю, это можно делать при помощи Project Server, но было бы интересно узнать, чем вы пользуетесь?
Пока народу немного (в пределах 10 человек), хватает еженедельных совещаний :-)
Т.е. задачи в TFS у человека висят для справки, что-то срочное — можно и сразу сказать, а несрочное — терпит до совещания.
Т.е. задачи в TFS у человека висят для справки, что-то срочное — можно и сразу сказать, а несрочное — терпит до совещания.
Удобно с помощью ProjectServer и его плагина к Аутлуку. Инструмент работает хорошо, правда выходит отнюдь не бюджетным. (хотя и сам Project штука весьма дорогая)
Какое-то время использовали это на моей прошлой работе в Украине. На текущей работе менеджер проекта просто раздаёт всем план и на еженедельных совещаниях информирует о задачах на неделю. Хватает. (но это проекты скорее из сферы Lean/CI и инфраструктурных изменений. Небольшая часть — управление разработкой/модификации ПО под эти изменения)
Какое-то время использовали это на моей прошлой работе в Украине. На текущей работе менеджер проекта просто раздаёт всем план и на еженедельных совещаниях информирует о задачах на неделю. Хватает. (но это проекты скорее из сферы Lean/CI и инфраструктурных изменений. Небольшая часть — управление разработкой/модификации ПО под эти изменения)
Связка работает прекрасно, если список задач и зависимостей сразу создавать в TFS, а MS Project использовать только для выравнивая загрузки: подгружать задачи в Project, поработать с датами, и потом опубликовать всё обратно в TFS.
То есть база TFS при этом используется как первичное хранилище задач, а MS Project — только как надстройка, инструмент, предназначенный исключительно для планирования.
То есть база TFS при этом используется как первичное хранилище задач, а MS Project — только как надстройка, инструмент, предназначенный исключительно для планирования.
А TFS научился указывать зависимости между задачами? я с этой связкой работал году эдак в 2005, тогда в TFS создавать задачи было ужасно неудобно :(
TFS2010 точно научился. Более того, его переучили: там появилось множество разных видов зависимостей, с которыми не сразу разберёшься. Но при экспорте в MS Project, насколько я помню, учитывается только один вид зависимостей — простая последовательность, когда одна задача не может быть начата после завершения предыдущей.
Спасибо. За статью. Полезные советы. Единственно, что проецируя на свои проекты хочу спросить.
Глядя на снимки вижу, что жизненный цикл вашего демо-проекта можно характеризовать как:
Стартанули — версия 0.0
Завершили — версия 1.0
Ну это понятно, что для наглядности. Поэтому.
Как обстоят дела с учетом времени отводимое на исправление ошибок? Вы как раз для этого и отводите время «прочие работы»? Как я понимаю вы ж их не добавляете как задачи. А если рассматривается несколько этапов, но каждый этап представляет собой релиз (который допустим рассматривается как законченный продукт). Допустим их будет штук 10 вперед. Вы создаете новый документ для каждого релиза, или продолжаете в текущем? Но тогда как я понимаю, список начнет расти ого-го как, придется долго проматывать…
Спрашиваю потому, что как то был решил попробовать в альтернативном программном — Planner (в Linux сижу). Первый ваш этап был прошел — оценил сроки стоимость, но потом забросил, как-то все это отслеживать стало неудобно, когда пытался увязать, с текущим состоянием проекта. Redmine тот же именно для отслеживания хода проекта удобней в конечном счете для меня оказался. Но на начальном этапе, при согласовании сроков, согласен — отличное решение.
Глядя на снимки вижу, что жизненный цикл вашего демо-проекта можно характеризовать как:
Стартанули — версия 0.0
Завершили — версия 1.0
Ну это понятно, что для наглядности. Поэтому.
Как обстоят дела с учетом времени отводимое на исправление ошибок? Вы как раз для этого и отводите время «прочие работы»? Как я понимаю вы ж их не добавляете как задачи. А если рассматривается несколько этапов, но каждый этап представляет собой релиз (который допустим рассматривается как законченный продукт). Допустим их будет штук 10 вперед. Вы создаете новый документ для каждого релиза, или продолжаете в текущем? Но тогда как я понимаю, список начнет расти ого-го как, придется долго проматывать…
Спрашиваю потому, что как то был решил попробовать в альтернативном программном — Planner (в Linux сижу). Первый ваш этап был прошел — оценил сроки стоимость, но потом забросил, как-то все это отслеживать стало неудобно, когда пытался увязать, с текущим состоянием проекта. Redmine тот же именно для отслеживания хода проекта удобней в конечном счете для меня оказался. Но на начальном этапе, при согласовании сроков, согласен — отличное решение.
Это вопрос сложный и даже в чем-то философский. Если начать издалека — то есть два подхода: проектный и процессный.
Проектный — это когда вы должны за конечное время создать некоторый продукт. Процессный — это когда вы организуете процесс таким образом, чтобы двигаться к некоторой цели.
То что я описываю — это проектный подход. Релиз (продукт) образуется в конце проекта. Этап — это не обязательно релиз, это просто некоторый промежуточный результат. Обычно в конце этапа можно оценить как движется проект и скорректировать дальнейшие планы. Говорить о версии в начале и в конце тут сложно, потому как на старте может быть некоторый продукт, а в конце — этот же продукт, но «допиленный» под конкретного заказчика, его нужды.
В такой ситуации исправление ошибок — это либо известные работы, либо фоновые. Например, мы знаем, что в среднем 10% времени у нас уходит на исправление ошибок, и это надо учесть. Можем включить их в «прочие работы» или удлинить на 10% оценки по срокам для остальных задач. Для получения оценок — это неважно. Но если говорить об управлении проектом — то наука рекомендует такие запасы времени вкладывать именно в конечный буфер (прочие работы).
Другое дело, что вы в начале этапа можете заранее знать, какие ошибки есть и сколько времени у вас займет их исправление. Т.е. это уже не некоторая непредсказуемая фоновая деятельность — а конкретные задачи. Вот и оформлять их надо как задачи.
Redmine (как и куча других подобных систем — Jira, Trac, TFS и т.п.) ориентирован, в первую очередь, на процесс. Он позволяет организовать командную работу, показывает кому какие задачи назначены, что сделано, а что нет. С его помощью можно оценить что происходит прямо сейчас. Но он совершенно не помогает управлять проектом — т.е. он не помогает обнаружить узкие места проекта, оценить сроки и т.п.
На мой взгляд, это вообще большая дыра гибких методологий. Понятно, что управление проектом дело непростое, но Agile подход не предлагает решения этой проблемы, а делает вид что её нет. Мягко и незатейливо происходит подмена проектной деятельности процессной, а все остальное — чистый маркетинг, призванный убедить нас, что так и надо.
P.S. Это не значит, что я против гибких методологий разработки, просто всегда надо понимать за чей счет банкет.
Проектный — это когда вы должны за конечное время создать некоторый продукт. Процессный — это когда вы организуете процесс таким образом, чтобы двигаться к некоторой цели.
То что я описываю — это проектный подход. Релиз (продукт) образуется в конце проекта. Этап — это не обязательно релиз, это просто некоторый промежуточный результат. Обычно в конце этапа можно оценить как движется проект и скорректировать дальнейшие планы. Говорить о версии в начале и в конце тут сложно, потому как на старте может быть некоторый продукт, а в конце — этот же продукт, но «допиленный» под конкретного заказчика, его нужды.
В такой ситуации исправление ошибок — это либо известные работы, либо фоновые. Например, мы знаем, что в среднем 10% времени у нас уходит на исправление ошибок, и это надо учесть. Можем включить их в «прочие работы» или удлинить на 10% оценки по срокам для остальных задач. Для получения оценок — это неважно. Но если говорить об управлении проектом — то наука рекомендует такие запасы времени вкладывать именно в конечный буфер (прочие работы).
Другое дело, что вы в начале этапа можете заранее знать, какие ошибки есть и сколько времени у вас займет их исправление. Т.е. это уже не некоторая непредсказуемая фоновая деятельность — а конкретные задачи. Вот и оформлять их надо как задачи.
Redmine (как и куча других подобных систем — Jira, Trac, TFS и т.п.) ориентирован, в первую очередь, на процесс. Он позволяет организовать командную работу, показывает кому какие задачи назначены, что сделано, а что нет. С его помощью можно оценить что происходит прямо сейчас. Но он совершенно не помогает управлять проектом — т.е. он не помогает обнаружить узкие места проекта, оценить сроки и т.п.
На мой взгляд, это вообще большая дыра гибких методологий. Понятно, что управление проектом дело непростое, но Agile подход не предлагает решения этой проблемы, а делает вид что её нет. Мягко и незатейливо происходит подмена проектной деятельности процессной, а все остальное — чистый маркетинг, призванный убедить нас, что так и надо.
P.S. Это не значит, что я против гибких методологий разработки, просто всегда надо понимать за чей счет банкет.
MS Project и MS Project Server занимаюсь с 2003 версии ещё.
Отличная обзорная статья, не нашел ни одного разногласия со своим опытом и практикой!
От себя хочу лишь добавить, что в некоторых случаях всё-таки есть необходимость использовать именно суммарные задачи. Но, действительно, не для «этапного» среза, или, допустим, когда весь блок внутренних задач и все последующие будут зависеть от полного выполнения суммарной задачи. Т.е., например, создание какого-нибудь функционала полностью влияет на все зависимые от этого функционала задачи. Тогда, пожалуй, имеет смысл их сгруппировать, чтобы эту суммарную задачу можно было назначить предшественником. Можно, конечно, предшественником назначать конкретную задачу цепочки, или, например, часто для MileStone (веха) — то, что вы назвали «контрольные точки» — поставить предшественниками все связанные с её выполнением задачи. Обычно такие «вехи» ставятся в конце создания какой-то важной фичи, влияющей на реализацию всего проекта «после» её (вехи) реализации. Т.е., когда, например, нельзя «двигаться» дальше до полной реализации какой-нибудь библиотеки.
Кроме того, есть в методологии MS EPM да и вообще PMBOK в целом такой аспект как «план для спонсора», в котором обычно как раз отражены наши MileStone. Достижение этих «указателей» позволяет говорить о выполнении проекта.
Есть ещё целый ряд «продвинутых» возможностей планирования, которые можно исследовать\учитывать.
Но это больше касается сравнения плана в «денежном» выражении. Т.е., если мы назначим на задачи плана реальные или гипотетические финансовые затраты возможности планирования и анализа возрастают на порядок.
Немного в сторону: в Project можно назначить несколько финансовых срезов, т.е., «себестоимость», «для заказчика», «для белой бухгалтерии», «для черной бухгалтерии» и т.п.
И тогда, если мы можем оперировать «финансовыми» показателями, то к анализу нам доступны не только отклонения трудозатрат, но и отклонения по стоимости. Есть ситуации, когда по трудозатратам мы можем идти «в ногу» со временем, а по стоимости «превышать» или даже «не догонять». Это всё весьма подробно описано даже в справочной системе к Project. Весьма рекомендую ознакомиться, позволит продумать всё, что нужно заложить на первоначальном этапе планирования. В частности срезы нескольких базовых планов могут оказаться весьма кстати (оптимистичные, пессимистичные и т.п., чтобы сравнивать с ними текущий и понимать почему финансовые отклонения случились и куда проект движется).
Да, этого немножко не было описано, но в Project есть три ключевых возможности предопределенного распределения соотношения «длительность-трудозатраты». И это очень важно, т.к. отражает многообразие стилей планирования.
Следует весьма учитывать, что длительность !== трудозатраты. В этом плане афоризм, в котором девять женщин не родят за один месяц очень отражает суть. При неверном целеполагании этих настроек в фазе первоначального планирования Project может «считать», что это допустимо, и, таким образом, потом придется многое переделывать.
Кроме того, ещё, советую, сохранять «версии» самого файла. SVN или другая трекалка будет идеальным дополнением.
Спасибо ещё раз за статью :)
Отличная обзорная статья, не нашел ни одного разногласия со своим опытом и практикой!
От себя хочу лишь добавить, что в некоторых случаях всё-таки есть необходимость использовать именно суммарные задачи. Но, действительно, не для «этапного» среза, или, допустим, когда весь блок внутренних задач и все последующие будут зависеть от полного выполнения суммарной задачи. Т.е., например, создание какого-нибудь функционала полностью влияет на все зависимые от этого функционала задачи. Тогда, пожалуй, имеет смысл их сгруппировать, чтобы эту суммарную задачу можно было назначить предшественником. Можно, конечно, предшественником назначать конкретную задачу цепочки, или, например, часто для MileStone (веха) — то, что вы назвали «контрольные точки» — поставить предшественниками все связанные с её выполнением задачи. Обычно такие «вехи» ставятся в конце создания какой-то важной фичи, влияющей на реализацию всего проекта «после» её (вехи) реализации. Т.е., когда, например, нельзя «двигаться» дальше до полной реализации какой-нибудь библиотеки.
Кроме того, есть в методологии MS EPM да и вообще PMBOK в целом такой аспект как «план для спонсора», в котором обычно как раз отражены наши MileStone. Достижение этих «указателей» позволяет говорить о выполнении проекта.
Есть ещё целый ряд «продвинутых» возможностей планирования, которые можно исследовать\учитывать.
Но это больше касается сравнения плана в «денежном» выражении. Т.е., если мы назначим на задачи плана реальные или гипотетические финансовые затраты возможности планирования и анализа возрастают на порядок.
Немного в сторону: в Project можно назначить несколько финансовых срезов, т.е., «себестоимость», «для заказчика», «для белой бухгалтерии», «для черной бухгалтерии» и т.п.
И тогда, если мы можем оперировать «финансовыми» показателями, то к анализу нам доступны не только отклонения трудозатрат, но и отклонения по стоимости. Есть ситуации, когда по трудозатратам мы можем идти «в ногу» со временем, а по стоимости «превышать» или даже «не догонять». Это всё весьма подробно описано даже в справочной системе к Project. Весьма рекомендую ознакомиться, позволит продумать всё, что нужно заложить на первоначальном этапе планирования. В частности срезы нескольких базовых планов могут оказаться весьма кстати (оптимистичные, пессимистичные и т.п., чтобы сравнивать с ними текущий и понимать почему финансовые отклонения случились и куда проект движется).
Да, этого немножко не было описано, но в Project есть три ключевых возможности предопределенного распределения соотношения «длительность-трудозатраты». И это очень важно, т.к. отражает многообразие стилей планирования.
Следует весьма учитывать, что длительность !== трудозатраты. В этом плане афоризм, в котором девять женщин не родят за один месяц очень отражает суть. При неверном целеполагании этих настроек в фазе первоначального планирования Project может «считать», что это допустимо, и, таким образом, потом придется многое переделывать.
Кроме того, ещё, советую, сохранять «версии» самого файла. SVN или другая трекалка будет идеальным дополнением.
Спасибо ещё раз за статью :)
Про суммарные задачи.
Сложности возникают, когда реализация этого самого функционала размазывается на несколько этапов. Причем сначала кажется, что все ок, а потом одну задачку добавили, потому вторую — и привет. Когда анализируешь загрузку человека (группируя по исполнителям), видишь, что его первая задача начинается через полгода, а почему — не видно. Потому как суммарные задачи по умолчанию не попадают в просмотр по группировкам. А если их включить — такая каша образуется… В общем, я не рекомендую :-) Если очень хочется такие цепочки сделать то вместо суммарной — добавить milestone после всех задач данной функциональности и все остальное отстраивать от негою
Сложности возникают, когда реализация этого самого функционала размазывается на несколько этапов. Причем сначала кажется, что все ок, а потом одну задачку добавили, потому вторую — и привет. Когда анализируешь загрузку человека (группируя по исполнителям), видишь, что его первая задача начинается через полгода, а почему — не видно. Потому как суммарные задачи по умолчанию не попадают в просмотр по группировкам. А если их включить — такая каша образуется… В общем, я не рекомендую :-) Если очень хочется такие цепочки сделать то вместо суммарной — добавить milestone после всех задач данной функциональности и все остальное отстраивать от негою
Да да, всё верно. Просто хотел сказать, что в Project, несмотря на всю гибкость, всё таки есть определенная «методология» планирования и контроля. На всякий случай, чтобы не быть неправильно понятым: "методика" и "методология".
Т.е., не чёткий рецепт, а более «обобщённое» направление действий.
По существу, да, именно — единственный выигрыш «суммарной» задачи это «иерархичность», представления.
Да, она может быть удобна, но только если «очень осторожно». Так, например, кроме описанных вами неудобств часть встречаются «продвинутые» менеджеры, назначающие суммарным задачам ресурсы и потом удивляющиеся что «план поехал». EPM предлагает использовать так называемую WBS — WorkBound Structure — метод Декомпозиции Задач. Т.е., определяя ключевые цели как задачи, мы начинаем декомпозицию до самых мелких структур, которые могут быть исполнены за 1-2 дня (конечно, есть исключения). Декомпозиция предполагает иерархию.
Но, при этом, следует Подчеркнуть, что в этом «методе» есть важнейший аспект, касающийся, скажем так, названий. Работы обозначаются действием, а milestone обозначается «артефактом». Т.е. цель выполнения работ: создать сущность. Например (скорее всего не совсем удачно) — разработать библиотеку N декомпозируется на:
Milsetone всей декомпозиции тогда называется «Библиотека AwesomeName»
И, в этом случае, когда над таким Milestone «возвышается» суммарная задача с % выполнения и % освоения бюджета, тогда «спонсору» проекта всё очень даже становится заметно: проценты как минимум должны совпадать с базовым планом, т.е. должно быть освоено сколько должно быть по плану :)
Естественно, это повод для полемики, т.к. невозможно на первоначальном этапе предугадать что будет.
Но, вся «крутость» и управления ситуацией тогда сводится к тому, что мы можем видеть «изменения» и опираться на их причины в финансовом выражении. И тогда уже можно задавать вопрос типа:
Ответы могут быть разными, но они, по крайней мере, всегда будут четкими, например:
:)
Т.е., не чёткий рецепт, а более «обобщённое» направление действий.
По существу, да, именно — единственный выигрыш «суммарной» задачи это «иерархичность», представления.
Да, она может быть удобна, но только если «очень осторожно». Так, например, кроме описанных вами неудобств часть встречаются «продвинутые» менеджеры, назначающие суммарным задачам ресурсы и потом удивляющиеся что «план поехал». EPM предлагает использовать так называемую WBS — WorkBound Structure — метод Декомпозиции Задач. Т.е., определяя ключевые цели как задачи, мы начинаем декомпозицию до самых мелких структур, которые могут быть исполнены за 1-2 дня (конечно, есть исключения). Декомпозиция предполагает иерархию.
Но, при этом, следует Подчеркнуть, что в этом «методе» есть важнейший аспект, касающийся, скажем так, названий. Работы обозначаются действием, а milestone обозначается «артефактом». Т.е. цель выполнения работ: создать сущность. Например (скорее всего не совсем удачно) — разработать библиотеку N декомпозируется на:
- создание ядра библиотеки
- создание функции 1
- …
- создание функции NNN
Milsetone всей декомпозиции тогда называется «Библиотека AwesomeName»
И, в этом случае, когда над таким Milestone «возвышается» суммарная задача с % выполнения и % освоения бюджета, тогда «спонсору» проекта всё очень даже становится заметно: проценты как минимум должны совпадать с базовым планом, т.е. должно быть освоено сколько должно быть по плану :)
Естественно, это повод для полемики, т.к. невозможно на первоначальном этапе предугадать что будет.
Но, вся «крутость» и управления ситуацией тогда сводится к тому, что мы можем видеть «изменения» и опираться на их причины в финансовом выражении. И тогда уже можно задавать вопрос типа:
«А почему для реализации библиотеки AwesomeName командой было потрачено в два раза больше денег? „
Ответы могут быть разными, но они, по крайней мере, всегда будут четкими, например:
“Возникли непредвиденные ситуации, рабочая группа на этапе планирования не была осведомлена о планах конкурентов, мы вынуждены были сменить стратегию и для того, чтобы уложиться в длительность этой задачи привлекли дополнительные ресурсы. Вместе с тем данный перерасход бюджета позволяет сократить энергозатраты и длительность на завершающих этапах, и снизить их рисковую составляющую „
:)
В общем, несмотря на преимущества, я для себя решил избегать суммарных задач для декомпозиции.
Связано это с тем, что функциональная декомпозиция и зависимости для распределения по календарю — это вещи существенно разные. Поскольку суммарные задачи — единственное средство управления последовательностью выполнения для наборов задач, то я их использую для разделения на этапы. А для декомпозиции приходится использовать другие средства, хорошо, что они есть :)
Связано это с тем, что функциональная декомпозиция и зависимости для распределения по календарю — это вещи существенно разные. Поскольку суммарные задачи — единственное средство управления последовательностью выполнения для наборов задач, то я их использую для разделения на этапы. А для декомпозиции приходится использовать другие средства, хорошо, что они есть :)
Как у свежих Project Server со стабильностью?
В позапрошлом проекте использовали Project и Project Server 2003. Менеджеры формировали план и назначали ресурсам задачи в MS Project, публиковали на сервер, далее ресурсы отчитывались в своих задачах каждый день через Web интерфейс, если надо то корректировали estimate и прочее. В результате проект жил и развивался весьма наглядно. Но вот стабильностью Project Server не отличался. Раз в неделю рестарт сервера — это стабильно (30 разработчиков + 5 менеджеров). А если как-то хитро-циклично задачи зацепишь друг за друга (сейчас не помню точный кейз, но помниться, я его все таки нашел) то падал чуть не при каждом пуке, пока их назад не разведешь. А как сейчас с этим?
В позапрошлом проекте использовали Project и Project Server 2003. Менеджеры формировали план и назначали ресурсам задачи в MS Project, публиковали на сервер, далее ресурсы отчитывались в своих задачах каждый день через Web интерфейс, если надо то корректировали estimate и прочее. В результате проект жил и развивался весьма наглядно. Но вот стабильностью Project Server не отличался. Раз в неделю рестарт сервера — это стабильно (30 разработчиков + 5 менеджеров). А если как-то хитро-циклично задачи зацепишь друг за друга (сейчас не помню точный кейз, но помниться, я его все таки нашел) то падал чуть не при каждом пуке, пока их назад не разведешь. А как сейчас с этим?
В общем, не могу точно сказать, что я видел подобные ситуации в 2010.
В 2007 да, были проблемы, но с постепенными выходами SP они решались.
Мы от 2007 отказались в пользу 2010 на том моменте, когда из проблем осталась только зависавшая очередь заданий, и это вполне «лечилось» запуском спец. скрипта на СУБД. Если я не ошибаюсь это SP3.
Именно Project Server 2010 (не MS Office Project 2010) лично я последний раз использовал в начале 2011 годаю
В последнее время я слегка сменил профиль. Но, я продолжаю общаться с бывшими коллегами, имею возможность получить FeedBack. Никаких существенных Issue от них не поступает, т.е., пользуясь «информацией из проверенных источников» могу сказать, что «все вроде бы нормально».
Только, пожалуйста, не воспринимайте как «мопед не мой, я просто разместил объяву»
Можно даже говорить, что один раз освоившись с PMBOK, вам уже будет не так важен инструментарий.
В 2007 да, были проблемы, но с постепенными выходами SP они решались.
Мы от 2007 отказались в пользу 2010 на том моменте, когда из проблем осталась только зависавшая очередь заданий, и это вполне «лечилось» запуском спец. скрипта на СУБД. Если я не ошибаюсь это SP3.
Именно Project Server 2010 (не MS Office Project 2010) лично я последний раз использовал в начале 2011 годаю
В последнее время я слегка сменил профиль. Но, я продолжаю общаться с бывшими коллегами, имею возможность получить FeedBack. Никаких существенных Issue от них не поступает, т.е., пользуясь «информацией из проверенных источников» могу сказать, что «все вроде бы нормально».
Только, пожалуйста, не воспринимайте как «мопед не мой, я просто разместил объяву»
Можно даже говорить, что один раз освоившись с PMBOK, вам уже будет не так важен инструментарий.
Спасибо за обзор.
Скажите, а в вашей работе какие задачи по разработке чаще встречаются — однотипные (сайты-визитки «под копирку», бизнес-автоматизация с фиксированным набором решений, веб-интерфейсы к базам данных) или разноплановые (приходит внешний заказчик и говорит, что теперь мы будем делать native приложение под android для offline работы с его медицинским каталогом)?
Скажите, а в вашей работе какие задачи по разработке чаще встречаются — однотипные (сайты-визитки «под копирку», бизнес-автоматизация с фиксированным набором решений, веб-интерфейсы к базам данных) или разноплановые (приходит внешний заказчик и говорит, что теперь мы будем делать native приложение под android для offline работы с его медицинским каталогом)?
У меня обычно вариант промежуточный. Есть некоторый базовый продукт и на его основе делаются прикладные решения под некоторые частные задачи. Начиналось все как раз с проекта по созданию этого продукта. Не сказать, что задачи совсем разноплановые, но и не скажешь, что под копирку.
Я в целом поменьше вашего руковожу разработкой, чуть больше пяти лет. Но что успел заметить: если разработка не совсем типовая (сайты там, автоматизация), то значительная часть задач не имеют такого состояния как «трудоемкость» вообще. То есть я вижу задачу «сделать для отдела тестирования в отладочном режиме лог со стороны android» — и я без понятия, сколько это займет времени. Можно на вскидку предположить что человекодень — записать файл в локальную песочницу дело нехитрое, ну и найти относительно простой способ тестировщикам этот файл с устройства снять. А потом в процессе разработки «неожиданно» оказывается, что доступа в песочницу у тестировщиков нету, нужно им на компьютеры ставить сертификаты и писать мануал как это все устанавливать и настраивать, в процессе тестового развертывания «неожиданно» оказывается что сертификаты не всегда ставятся — потому что код для windows который сертификат импортирует писал один индус, а код OpenSSL который со стороны android toolchain этот сертификат генерирует — другой индус и у них разное понимание внутреннего мировоззрения «ASN.1»… Итого две недели на практике (пример, естественно, вымышленный — есть куча настоящих, но их в двух словах не расскажешь). И такое случается довольно часто, когда из-за того, что мы что-то делаем «в первый раз» (а иногда даже «в первый раз — и на stackoverflow об этом тоже никто ничего не знают») достаточно простые «на первый взгляд» задачи могут неожиданно увеличить свою трудоемкость на порядок, породить из себя дюжину подзадач или вообще переродиться, полностью изменив дальнейшую разработку (… а вот тут, через три месяца, мы неожиданно понимаем, что на реальных данных репликация для данной базы у нас работать не будет… ).
Случаются ли у вас такие ситуации? Насколько часто?
Случаются ли у вас такие ситуации? Насколько часто?
И такое случается. Не скажу, что часто, но бывает.
На мой взгляд, основная причина такого явления — недостаточное внимание постановке задачи. Утверждение, что это займет «неизвестно сколько времени» говорит, в первую очередь, о недостаточно проработанной постановке задачи — ровно то, о чем я писал в самом конце. Т.е. в постановке задачи осталось много недосказанностей. Недосказанность может возникать из-за того, что постановка недостаточно детальна (сочли, что все просто и так ясно), или из-за большого количества неизвестных величин (какие-то факторы, которые заранее неизвестны и их влияние непредсказуемо). Неучтенные факторы — это может быть и недостаточно налаженная инфраструктура, недостаточная квалификация разработчиков в новой для них области, ненадежная технология и т.п. Все это — риски. В промышленной разработке принято уделять внимание уменьшению влияния рисков. Для этого есть отдельный отдел, занимающийся инфраструктурой, новые технологии используются только после того, как кто-то набьет на них шишки и опишет их на stackoverflow и т.п.
С опытом приходит способность смотреть на задачи пытливым взором и отмечать те, в которых нас ждут грабли. На такие задачи обычно закладывают дополнительные буфера времени, «на всякий случай». На самом деле, их обычно не так уже много. Гораздо опаснее те задачи, где за внешне простой формулировкой кроется большая работа. Вот определять их гораздо сложнее. Последний раз я капитально влетел на пару месяцев с задачей, которая оценивалась в три недели :-)
На мой взгляд, основная причина такого явления — недостаточное внимание постановке задачи. Утверждение, что это займет «неизвестно сколько времени» говорит, в первую очередь, о недостаточно проработанной постановке задачи — ровно то, о чем я писал в самом конце. Т.е. в постановке задачи осталось много недосказанностей. Недосказанность может возникать из-за того, что постановка недостаточно детальна (сочли, что все просто и так ясно), или из-за большого количества неизвестных величин (какие-то факторы, которые заранее неизвестны и их влияние непредсказуемо). Неучтенные факторы — это может быть и недостаточно налаженная инфраструктура, недостаточная квалификация разработчиков в новой для них области, ненадежная технология и т.п. Все это — риски. В промышленной разработке принято уделять внимание уменьшению влияния рисков. Для этого есть отдельный отдел, занимающийся инфраструктурой, новые технологии используются только после того, как кто-то набьет на них шишки и опишет их на stackoverflow и т.п.
С опытом приходит способность смотреть на задачи пытливым взором и отмечать те, в которых нас ждут грабли. На такие задачи обычно закладывают дополнительные буфера времени, «на всякий случай». На самом деле, их обычно не так уже много. Гораздо опаснее те задачи, где за внешне простой формулировкой кроется большая работа. Вот определять их гораздо сложнее. Последний раз я капитально влетел на пару месяцев с задачей, которая оценивалась в три недели :-)
или из-за большого количества неизвестных величин (какие-то факторы, которые заранее неизвестны и их влияние непредсказуемо)
Вот тут-то и беда, что таких задач очень много — из-за молодости отрасли в целом и ее бурного развития в частности. Соответственно от инструмента хочется как минимум деление на исследовательскую стадию и стадию разработки (которая после исследовательской стадии может и не наступить), какое-то минимальное управление рисками. А когда из инструментов только автобалансировка — становится непонятно зачем это вообще надо? Типовые проекты по изготовлению сайтов планировать? Так это и в экселе замечательно планируется. А для действительно сложных проектов значительная часть задач вида «тут надо предварительно покапать и разведать местность. В зависимости от выкопанного пойдем разными путями».
Не нравится мне Project для управления IT проектами. ИМХО, все-таки специфика рисков, частое размножение / перерождение задач и слишком сильно специализированные ресурсы (Вася хорошо знает C++ но плохо Boost, а Петя знаком с Boost, но уровень C++ у него хуже) отличают эту область от остальных. Нужны специальные инструменты. А нету О_О.
Вы то мне и нужны!
Я в последнее время работаю как раз в области управления проектами. И как раз сейчас стартую проект по разведыванию местности для создания планировщика проектов для разработчиков. Потому как у меня устойчивое ощущение, что его не хватает. Project, действительно, изрядно неудобен, а реальных альтернатив не видно :-( Вот хочется сделать в этом месте что-то хорошее, полезное и, по возможности, бесплатное. Мне очень не хватает аудитории, с которой можно было бы обсудить пожелания, потребности к подобной программе.
Можно будет через какое-то время обратиться с вопросами?
Я в последнее время работаю как раз в области управления проектами. И как раз сейчас стартую проект по разведыванию местности для создания планировщика проектов для разработчиков. Потому как у меня устойчивое ощущение, что его не хватает. Project, действительно, изрядно неудобен, а реальных альтернатив не видно :-( Вот хочется сделать в этом месте что-то хорошее, полезное и, по возможности, бесплатное. Мне очень не хватает аудитории, с которой можно было бы обсудить пожелания, потребности к подобной программе.
Можно будет через какое-то время обратиться с вопросами?
Автору спасибо. Не могу удержаться чтобы не задать вопрос.
Дело в том, что тоже руковожу проектами. Правда специфика — проекты идут по конвееру. Поэтому идеальным решением была бы возможность создавать связанные проекты. Т.е. чтобы можно было программистов/дизайнеров делить между проектами да еще и с привязкой к календарю.
В свое время я так и не нашел таких возможностей в MS Project, хотя очень хотелось. Это я плохо искал или данный инструмент действительно не рассчитан на мою задачу? Может кто подскажет другой инструмент для этой задачи?
Дело в том, что тоже руковожу проектами. Правда специфика — проекты идут по конвееру. Поэтому идеальным решением была бы возможность создавать связанные проекты. Т.е. чтобы можно было программистов/дизайнеров делить между проектами да еще и с привязкой к календарю.
В свое время я так и не нашел таких возможностей в MS Project, хотя очень хотелось. Это я плохо искал или данный инструмент действительно не рассчитан на мою задачу? Может кто подскажет другой инструмент для этой задачи?
Нет, эту возможность действительно весьма сложно найти. При соединении с Project Server эта функциональность как бы «в базовой поставке» (к тому же там используется другая версия MS Office Project, а именно Professional).
Для «обычного» MS Office Project Standard при ответе на ваш вопрос необходимо использовать две функции MS Project:
1. Общий пул ресурсов.
2. Вставка проекта в проект.
Общий пул это проект, в котором заполнено лишь одно представление «Лист Ресурсов».
Этот «лист» подключается ко всем проектам, в которых необходимо использовать разделение ресурсов.
При этом в видна общая нагрузка.
Т.е., чтобы посмотреть полную нагрузку всех ресурсов нужно на конкретном компьютере открыть все файлы проектов, в которых участвует этот конкретный общий пул. По крайней мере для 2007 так было нужно.
Для того, чтобы не делать монотонную работу проще всего каждый новый проект вставлять в некий «общий» глобальный проект. В Project можно подключить один проект в другой.
При этом, сам проект вставляется как суммарная задача. И, конечно, становится возможно для вставленного проекта использовать те же возможности, что и для суммарных задач.
Да, для редактирования вставленного проекта проще, конечно, использовать не общий проект, а открыть конкретный файл. И, по идее, при открытии общего проекта «пересчет» назначений происходит автоматически.
Чтобы это всё работало «более-менее быстро» лучше использовать хороший компьютер и держать в сводном проекте только те проекты, которые действительно актуальны сейчас.
Надеюсь, так же очевидно, что в этом конкретном случае делать «базовые» планы общего проекта и использовать его для стандартных целей планирования, а не для анализа и построения отчетов — занятие бессмысленное.
Для «обычного» MS Office Project Standard при ответе на ваш вопрос необходимо использовать две функции MS Project:
1. Общий пул ресурсов.
2. Вставка проекта в проект.
Общий пул это проект, в котором заполнено лишь одно представление «Лист Ресурсов».
Этот «лист» подключается ко всем проектам, в которых необходимо использовать разделение ресурсов.
При этом в видна общая нагрузка.
Т.е., чтобы посмотреть полную нагрузку всех ресурсов нужно на конкретном компьютере открыть все файлы проектов, в которых участвует этот конкретный общий пул. По крайней мере для 2007 так было нужно.
Для того, чтобы не делать монотонную работу проще всего каждый новый проект вставлять в некий «общий» глобальный проект. В Project можно подключить один проект в другой.
При этом, сам проект вставляется как суммарная задача. И, конечно, становится возможно для вставленного проекта использовать те же возможности, что и для суммарных задач.
Да, для редактирования вставленного проекта проще, конечно, использовать не общий проект, а открыть конкретный файл. И, по идее, при открытии общего проекта «пересчет» назначений происходит автоматически.
Чтобы это всё работало «более-менее быстро» лучше использовать хороший компьютер и держать в сводном проекте только те проекты, которые действительно актуальны сейчас.
Надеюсь, так же очевидно, что в этом конкретном случае делать «базовые» планы общего проекта и использовать его для стандартных целей планирования, а не для анализа и построения отчетов — занятие бессмысленное.
А не пробовали Jire по методике Kanban? Вроде как раз для конвеерных проектов.
Плюс к уже описанному варианту с MS Project можно воспользоваться следующими:
1. Каждый проект создвавать и вести в MS Project, а межпроектные проблемы отслеживать в программах, которые позволяют просматривать
несколько mpp одновременно. Например, LiveProject ProjectsView. И контролировать загрузку исполнителей.
2. Использовать online сервис с нужной функциональностью типа Jira (с соотвествующим плагином) или LiquidPlanner.
1. Каждый проект создвавать и вести в MS Project, а межпроектные проблемы отслеживать в программах, которые позволяют просматривать
несколько mpp одновременно. Например, LiveProject ProjectsView. И контролировать загрузку исполнителей.
2. Использовать online сервис с нужной функциональностью типа Jira (с соотвествующим плагином) или LiquidPlanner.
Жаль, нет облегченной и более дешевой версии Project «для домашнего использования».
Как же нет?
Аналогов у Project огромное количество.
Навскидку из википедии:
ru.wikipedia.org/wiki/GanttProject
ru.wikipedia.org/wiki/OpenProj
К тому же для самого Project есть trial версия ( 30 запусков ).
Да, и если Вы, к примеру, студент, то получить Project можно несколькими более дешевыми способами.
Вплоть до «бесплатных» например, по программе MSDNAA (academic alliance).
Аналогов у Project огромное количество.
Навскидку из википедии:
ru.wikipedia.org/wiki/GanttProject
ru.wikipedia.org/wiki/OpenProj
К тому же для самого Project есть trial версия ( 30 запусков ).
Да, и если Вы, к примеру, студент, то получить Project можно несколькими более дешевыми способами.
Вплоть до «бесплатных» например, по программе MSDNAA (academic alliance).
Не аналогов, а именно самого Project. А альтернативными путями не всегда удается воспользоваться, скажем, заочникам софт не положен.
Ну а для чего заочнику нужен MS Project? Для учёбы — маловероятно (я реально не смог придумать применения. А что придумал — покроется пробной версией на 60 дней). Для работы — в таком случае учебная лицензия и так не подходит. Ну а менеджер проектов может и раскошелиться на рабочий иснтрумент или выбрать альтернативу.
Есть и on demand сервисы — www.microsoft.com/project/en-us/on-demand-hosting.aspx
Есть и on demand сервисы — www.microsoft.com/project/en-us/on-demand-hosting.aspx
Для личных проектов, фриланса и тому подобного. В шаблонах от МС даже строительство дома есть, например. В общем-то, любую подлежающую декомпозиции деятельность можно планировать там. Мне кажется, облегченная (безо всяких tfs и подобного хардкора) версия вполне могла бы найти своего клиента.
Ну так Project Standard — и есть облегчённая версия. Не нужен постоянно — найдите подходящий вариант on demand. Если хочется именно этот продукт. Есть ведь и альтернативы.
Плюс многие простые проекты запросто планируются и в электронных таблицах, у нас так часто делают в Excel, потому как диаграмму ганта удобно «рисовать» и если есть один-два десятка задач, то этого вполне хватает.
Плюс многие простые проекты запросто планируются и в электронных таблицах, у нас так часто делают в Excel, потому как диаграмму ганта удобно «рисовать» и если есть один-два десятка задач, то этого вполне хватает.
Если для фриланса советую посмотреть на www.microsoft.com/bizspark/
«К тому же для самого Project есть trial версия ( 30 запусков )»
не так — 60 дней. technet.microsoft.com/en-US/evalcenter/ee404758.aspx (собственно, и на офис, и на визио также 60 дней — совсем неплохо)
не так — 60 дней. technet.microsoft.com/en-US/evalcenter/ee404758.aspx (собственно, и на офис, и на визио также 60 дней — совсем неплохо)
А нужен именно Project? или аналогичная программа, которая помогает решать какие-то задачи?
Если верно второе, то мне было бы интересны Ваши ожидания от такой программы.
Если верно второе, то мне было бы интересны Ваши ожидания от такой программы.
Sign up to leave a comment.
Использование MS Project для управления проектами по разработке ПО