Microsoft Project Как создать свой сайт > Статьи > Почему Microsoft Project нельзя использовать для управления проектами

Почему Microsoft Project нельзя использовать для управления проектами

Сам дом располагался сразу за памятником Кирову, в результате чего
окна квартиры Натальи Викторовны выходили прямо на здание Кировского РУВД,
что, несомненно, должно было оказать положительное влияние на её моральный облик.
«Кошмар на улице Стачек», Андрей Кивинов.
6 января 2007

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

    Когда он заканчивает какую-то функцию, откуда он узнаёт, что делать дальше? Из головы. Он просто знает, что нужно сделать, чтобы закончить проект.


    Через два года Вася стал владельцем-основателем Pushkin Soft, ltd. и занимается продажей пасьянсов. Доходы позволяют нанять второго программиста, Петю, и с удвоенной энергией взяться за следующую версию продукта.

    Сначала Вася с Петей просто обсуждали планы работ устно. Но через некоторое время задач стало больше, возросшее количество клиентов заставило больше отвлекаться на техподдержку и друзьям стало ясно, что держать список работ в голове больше нельзя — постоянно что-то забываешь. Последней каплей стало то, что Вася забыл закрыть период бесплатной раздачи продуктов на сайте компании (по замыслу трёхдневный) и две недели счастливые пользователи могли скачать бесплатную версию. Для решения проблемы была закуплена и повешена на стену огромная доска, на которую теперь записывались все планируемые работы. Выполненные работы стирались и места на доске вполне хватало.

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

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

    Многие первым делом обращаются к Microsoft Project. Мне хотелось бы предостеречь вас от совершения этой ошибки.

Project не поддерживает нужную вам модель данных

    Основные объекты предметной области: задачи и исполнители в Project’е совсем не похожи на действительность разработки программного обеспечения. Значит, вам придётся изворачиваться и придумывать, как запихнуть в это прокрустово ложе нужные вам данные. Это вполне реально и даже немного весело, но заставляет вас делать не очень нужную работу. В этом разделе я попробую описать основные недостатки модели данных Microsoft Project применительно к планированию процесса разработки. Со всеми этими проблемами я сталкивался лично и лично придумывал обходное решение.

  1. Project рассчитан на меньшее количество задач, чем вам нужно. Средний документ, вероятно, содержит меньше ста задач. Для управления проектом это смешная цифра. Для сравнения: в базе задач Apache Foundation более 40 000 записей, в базе Mozilla Foundation — более 360 000. В моём последнем проекте, очень небольшом, общее количество задач за 4 месяца достигло 200. В двухлетнем проекте, в котором участвуют 10-15 человек, количество задач может легко перевалить за 10 000. Я видел, как ведёт себя MS Word на несвойственных для него объёмах (сотни страниц технической документации со схемами) – падения, мистические глюки, тормоза. Лично не проверял, но могу предположить, что с Project’ом ситуация будет похожей.

  2. Project позволит вам случайно поменять ID задачи. Более того, есть целый ряд операций, которые при своём наиболее естественном исполнении ведут к смене ID задач. Будете вводить собственную систему ID/кодов? Будете использовать название и время от времени путать задачи с похожими названиями?

  3. Надо что-то делать с жизненным циклом задачи. Даже в самом простом случае вам придётся иметь дело с циклом “выполнение -> проверка -> доработка -> проверка”. Заметьте, что за разные этапы отвечают разные люди. Как представить это в Project?

    • Можно разбивать каждую задачу на X подзадач – по одной на этап жизненного цикла. Получается громоздко и неудобно, зато относительно точно.
    • Можно назначать задачу сразу всем задействованным исполнителям – разработчику, тестировщику, аналитику, админу и т. д. и добавлять к задаче поле “статус”, чтобы понять, на каком этапе жизненного цикла эта задача находится. Хорошо, а как тогда отслеживать историю изменения статуса (она же не обязательно линейная)? Как понять, что функция возвращается на доработку четвёртый раз, а не первый? Не знаю. В результате и так плохо, и эдак нехорошо.

    Итого: половину информации о проекте удастся внести в Project, вторую половину придётся держать в голове.

Лирическое отступление номер 1. Опасные иллюзии, или В чём отличие строительства дома от создания программного продукта

    В рамках нашего школьного курса по MS Project учебным проектом, который нужно было описать, служила постройка дома. Мы описывали задачи, устанавливали зависимости, находили критический путь, переставляли задачи, оптимизируя общую длительность проекта, считали нагрузку на ресурсы и общую стоимость, снижали ущерб от срыва сроков… В общем, делали в воображаемом проекте всё то, для чего предназначен Porject. Всё тот же учебный проект, с небольшими вариациями, использовался в университетском курсе. Похожие примеры – в половине учебных материалов, лежащих в Сети. Эти примеры выбраны не случайно. MS Project затачивался на определённый тип проектов и именно такие проекты и стараются использовать при обучении.

    Я хочу рассказать вам о нескольких предположениях, заложенных в Project, которые полностью противоречат с действительностью проектов по разработке ПО. Нужно не забывать, что в жизни всё совсем не так, как подразумевает интерфейс Project. Особенно, если вы всё же решитесь использовать его в проекте по разработке софта.

    Итак, самые опасные иллюзии, заложенные в MS Project:

  • Исполнители взаимозаменяемы. В типичном учебном проекте в качестве исполнителей фигурируют 2 каменщика, 4 разнорабочих, сантехник, электрик, 3 маляра и 1,5 землекопа. Исполнителей каждого типа, как правило, несколько. Предполагается, что все исполнители одного типа одинаковы. Вы можете перераспределять их с одной работы на другую, делать одну работу силами нескольких исполнителей для её ускорения и т. д. В разработке программного обеспечения всё не так.
    Все участники проекта уникальны и слабо взаимозаменяемы. Если вы передадите наполовину сделанную Васей задачу Кате – она может потратить несколько дней только на то, чтобы разобраться, да и то, если ей знакомы все задействованные языки, технологии и библиотеки. Project не может хранить информацию об этой зависимости и вам придётся держать её в голове.
    Другой пример – Катя может работать вдвое продуктивнее Пети и втрое продуктивнее Оли (вполне типично даже в небольшой команде). Соответственно, длительность выполнения задачи зависит от того, кто её делает. Это тоже придётся отслеживать вручную.

  • Для частично выполненной задачи можно правдоподобно оценить процент выполнения. Например, идёт отделка комнат, выполнено 60%, осталось 40: мы опережаем план на два дня. Благодать… Жаль, что такие рассуждения применимы только к отделочным работам.
    В разработке софта задача, выполненная на 80% – не выполнена! Выполненная на 99.9% – тоже не выполнена. Сколько времени займёт оставшаяся десятая процента можно узнать только после того, как работа будет закончена и сдана. Часто окажется, что 99,9% в действительности означало только 33,3%.
    Так уж сложилось, что получить правдоподобную оценку степени готовности можно только для некоторых работ, да и то от очень немногих людей. Поэтому здравомыслящий менеджер использует бинарную систему оценки готовности: готово – не готово. Всякие проценты – это, как правило, мишура, отвлекающая от более важных вещей.

  • Зная оценочную длительность всех работ, можно достаточно точно предсказать длительность всего проекта. Это подвид предыдущей иллюзии. Даже если вы можете безошибочно оценить длительность задачи (уже сомнительно), то у вас нет ни малейшего представления о том, сколько времени займёт проект целиком.
    Де Марко пишет, что в абсолютном большинстве случаев срыв сроков вызван непредусмотренными в плане задачами, а не ошибками в оценке длительности предусмотренных. С ним сложно не согласиться. Кроме того, в большинстве коммерческих проектов сроки определяются бизнес-соображениями, а не оценочной длительностью. И ваша задача – не оптимизировать длительность полной реализации плана, а поставить разумный набор функций, который удалось реализовать в срок.
    Кстати, выбором самых приоритетных задач Project тоже не позволит вам управлять. Как, например, исключить задачу из плана, не удаляя её? В issue-tracking’е вы можете использовать wontfix. А в Project?

Issue tracking — специализированные системы для управления задачами в проектах, связанных с разработкой ПО. Этот класс систем эволюционировал из систем отслеживания ошибок (багтреккинга): оказалось, что жизненный цикл исправления ошибки весьма похож на жизненный цикл любой другой задачи, а объединение багтреккинга и планирования позволило иметь в одном месте весь список необходимых работ.

Project не поддерживает совместную работу

    Хорошо, допустим, у вас получается вести актуальный список работ в MS Project. Вероятно, участники проекта слабо владеют телепатией. Значит надо как-то сообщать им о появляющихся задачах, а они, в свою очередь, должны как-то сообщать о сделанных работах. Как?

  1. Можно рассылать задачи в письмах, копируя описания из MS Project. Трудоёмко и совсем не изящно. Теоретически, можно попытаться автоматизировать эту операцию с помощью VBA-скриптов в MS Project. И да поможет вам Бог, если вы на это решились…

  2. Можно сообщать устно. Мало кто способен запомнить все несколько десятков задач, висящих на нём – это просто за пределами человеческих возможностей. Поэтому, когда пройдёт изначальный период хаоса, работать устная раздача заданий будет следующим образом: вы записываете задачу в Project, связываетесь с программистом и рассказываете на словах, что ему нужно сделать; он, находясь в середине выполнения другой задачи, чертыхается, уточняет формулировку, записывает новую задачу себе на листочек или в Outlook, потом пытается мучительно вспомнить, на каком месте текущей задачи он остановился. Через три дня (три недели, три месяца и т. д.), когда дело дойдёт до новой задачи, программист отыщет свои записи и попытается вспомнить, что же имелось в виду. В половине случаев он позвонит вам и спросит ещё раз. В половине оставшихся – не позвонит, но его интерпретация задачи будет заметно отличаться от вашей.
    Каждый раз, когда вы прерываете человека в середине задачи и бросаете на какую-нибудь авральную работу, сцена с менеджером, листочком и телефоном повторяется. Примерно через две недели кто-нибудь потеряет свой листочек с заданиями и они с менеджером будут мучительно пытаться понять, какие же задачи потеряны, а какие – нет. А через некоторое время у одного из участников накроется жёсткий диск, унося с собой в могилу все его данные. После чего операция с диктовкой 40 актуальных задач повторяется.

  3. Использование ICQ, email и прочих средств общения представляют собой вариацию на тему предыдущего пункта. Больше времени уходит на передачу информации, зато отчасти решается проблема чёткости формулировок и появляется возможность посмотреть архив и вспомнить, в чём же состоит задача. Поиск в неструктурированном архиве, тем не менее, занимает уйму времени, поэтому в половине случаев разработчики всё равно предпочтут спросить менеджера.

    Итого: главным инструментом вашей совместной работы над планами станет телефон. Оно вам надо?

Лирическое отступление номер 2. MS Project Server

    Да, у Microsoft есть интранет-продукт Project Server, который, вроде бы, решает задачи совместной работы. Это своего рода веб-интерфейс к проекту. Исполнители могут в любой момент видеть всё дерево проекта в актуальном состоянии и сообщать статус своих задач. Все изменения синхронизируются с главным документом Project, находящимся у менеджера. Все довольны, все танцуют.

    Типа.

    В одном проекте мы, наткнувшись на сложности совместной работы на базе документа, честно пытались пользоваться Project Server’ом. Не получилось. Продукт оставляет ощущение недоделки, скорость работы в локальной сети заметно медленнее, чем большинство хороших issue tracking систем в Интернете (с сервером на другом континенте). Все остальные проблемы уже забылась, но они были и весьма неприятные.

    Так что рекомендую пользоваться Project Server только в качестве эксперимента.

Что-то хорошее

    Чем Project хорош – так тем, что, пользуясь им, нельзя не увидеть “С начала проекта прошло уже два месяца. Осталось полтора, а мы ещё ничего толком не сделали… Вот дерьмо!”. Если ваш инструмент позволяет, заведите себе такой индикатор прошедшего времени и повесьте его туда, где он будет бросаться в глаза.

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

Если не Project, то что?

    Если у вас нет опыта использования Issue Tracking, в небольшом проекте я бы рекомендовал начать с использования Excel. Затраты на установку и обучение минимальны, поэтому вы сможете сосредоточиться на содержательной стороне Issue Tracking’а и понять, какие задачи он должен решать для вас. Через некоторое время вы сможете гораздо более осознанно выбрать Issue Tracking систему, чем выбрали бы с самого начала.

    Во всех остальных случаях просто найдите нормальную Issue Tracking систему и пользуйтесь ей (интересно, а пользуются ли в Microsoft своим Project’ом для планирования процесса разработки?).

Update: из чего выбирать свою первую issue tracking систему

    Приведу небольшой перечень хороших вариантов для выбора в качестве первой issue tracking системы:

  • Trac – очень удобен в использовании, помимо issue tracking’а включает тесно интегрированную с ним wiki. Существует множество плагинов, расширяющих функциональность. Базовая функциональность в области issue tracking не очень богата, в больших проектах с сильно формализованным процессом разработки её может не хватить. Open Source.
    В настоящее время я использую Trac, очень доволен.
  • Jira – многофункциональная issue tracking система. Продуманная поддержка как bugtracking, так и project management функциональности. Весьма удобна в использовании, хотя и не дотягивает в этом показателе до Trac. Коммерческая, цены начинаются от $1200/сервер.
    Мы использовали JIRA около 4 месяцев, довольны всем, кроме цены.
  • Bugzilla – проверенная временем система с достаточной функциональностью, но без особых изысков. Отличная надёжность, масштабируемость и производительность. Open Source.
  • Mantis – ещё одна неплохая система. Open Source.

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

Автор: Александр Лебедев.

Комментарии:

Aceler:
January 6th, 2007 at 03:38
А мы вот пользуемся форумом. Очень оригинально :)
В разделах форума кладем разделы задачи, внутри в качестве тем – подзадачи. Первый пост – описание задачи, затем исполнители кладут свои комментарии и подписываются на свои задачи путем получений ивещений по e-mail… Все просто…. пока.
В дальнейшем планируем использовать bugzilla.

vladimir:
January 7th, 2007 at 02:18
Можете глянуть наше чудо:
***
Демо вход:
login: admin
password: 12345

Прохожий:
January 7th, 2007 at 02:40
Очень поверхностная и плохая статья. Никаких конкретных фактов нет: “Я не знаю, но мне кажется…”, “я не пробовал, но думаю…”… В качестве трекера предложить использовать эксель вообще бред.

Uznick:
January 7th, 2007 at 03:52
Я тут на Хабрахабре дал ссылку на Вашу статью. Думаю, будет интересно почитать отзывы.

Alex Lebedev:
January 7th, 2007 at 10:28
А мы вот пользуемся форумом. Очень оригинально :)
В принципе, вполне пристойно решает задачи совместной работы.
Насчет представления адекватной модели данных сложнее, особенно в случае с форумом. По факту вам придется создавать представлять структуру данных (название, описание, критичность, приоритет, исполнитель, статус и т.д.) в текстовой форме. При вводе данных неудобства почти не проявляются. Но вот как только вам понадобится сделать отчет, например, список выполненных и отданных на тестирование задач – вы в заднице.
В этой связи планирующийся переход на багзиллу можно только поддерживать.

Alex Lebedev:
January 7th, 2007 at 10:52
Re: Прохожий
Я больше полугода пользовался для планирования как Project\’ом, так и Excel’ем, до того как перешел на специализированные Issue Tracking системы. Все изложенные в посте проблемы испытаны на своей шкуре, многие неоднократно. Так что можете поверить, что фактический материал у меня есть.
В качестве трекера предложить использовать эксель вообще бред.
Джоэль Спольски признает эксель хорошим треккером и инструментом планирования. Вот здесь и здесь.
Мой опыт тоже вполне положительный. Так что я не стал бы называть это бредом вне контекста (например, большой и сложный проект с кучей участников)

woofer:
January 7th, 2007 at 02:45
Отличная статья! Спасибо

Владимир:
January 8th, 2007 at 03:51
Отличная статья! Сам пришел к тем-же выводам. В настояшее время для ведения проектов используем связку Mantis + Wiki (Trac изучаем пока).
Не скажу что идеально, но более работоспособно в реальной жизни, чем в MS Project.
К списку причин, почему MSP непригоден для IT сферы, могу добавить еще один:
Как правило компания занимается несколькими проектами сразу, и разработчики тоже заняты в нескольких проектах. Соответственно в действительности существует постоянно меняющаяся система приоритетов на выполнение тех или иных задач разных проектов. Как это отразить в MSP я не придумал.
PS Кстати, еще одна прозаичная причина – цена продукта. Для небольших компаний она выглядит явно завышенной, особенно с учетом перечисленных проблем ;)

Алексей Новиков:
January 8th, 2007 at 06:26
Только вот аргументы какие-то странные порой:
«Лично не проверял, но могу предположить, что с Project’ом ситуация будет похожей.»
Это как «Я Пастернака не читал, но осуждаю». Автор говорит про одну программу и переносит ее недостатки на другую, так можно опуститься до аргументации «микрософт сакс».
«Project рассчитан на меньшее количество задач, чем вам нужно. Средний документ, вероятно, содержит меньше ста задач.»
Почему же в «среднем документе» менее 100 задач? Наверное, не потому, что Project такой нехороший, а потому что пользователи просто не заводили больше. Потому что это им не нужно было.
«В разработке софта задача, выполненная на 80% – не выполнена!»
Если дом построен на 80% или пациент прооперирован на 80%, то тоже не выполнена. Не Project тут виноват. Коли мыслить бинарно, пользуйте только значения 0% и 100%.
«В issue-tracking’е вы можете использовать wontfix. А в Project?»
А в Фотошопе я могу размытие по Гауссу сделать, а в Проджекте никак. Project это не issue tracking!!!

Alex Lebedev:
January 8th, 2007 at 08:17
«В issue-tracking’е вы можете использовать wontfix. А в Project?»
А в Фотошопе я могу размытие по Гауссу сделать, а в Проджекте никак. Project это не issue tracking!!!

Переформулирую.
Планирование должно основываться на реальных данных, иначе это будет планирование какой-то параллельной проекту реальности, которая, как мы помним из геометрии, с проектом не пересечется.
Реальные данные кроме как из issue tracking’а взять негде. Если вместо этого PM будет вбивать “свое понимание ситуации” – дело плохо. Своему пониманию место в голове, а при формальной оценке состояния проекта используют факты.
Соответственно, нужен инструмент, обеспечивающий issue tracking и предоставляющий все необходимые данные. В структурированном виде.
Project на эту роль не годится.
Соответственно, пользуйтесь настоящим issue tracking’ом. Если придумаете как экспортировать данные в Project, можете использовать тот для отчетов.
Dixi.

Miguel:
January 8th, 2007 at 04:18
отличная статья, в целом согласен

Мимо шёл:
January 9th, 2007 at 12:14
Случайно увидел статью. Раз уж не надо регистрироваться, вставлю две копейки.
Ну… вобщем, не впечатляет. “Больше полугода пользовался” – это, конечно, офигенный опыт. Конечно, назвать бредом сивой кобылы рука не поднимется, автор, в общем, старался.
MS Project отлично подходит для проектов от 1 до 20 человек длительностью до 3-4 лет. Проверено в течение 10 лет работы над такими проектами. Рекомендую автору учить матчасть и узнать побольше про MS Project Server, и все остальные примочки для управления проектами, что появились с MS Visual Studio 2005, а потом и VS 2007. Ну, а если ненависть к Майкрософту мешает, тогда, конечно, не надо себя мучать.

Юрий:
January 9th, 2007 at 05:57
хмхм. 8 лет мы используем ms project и года четыре — project server для ведения наших софтверных проектов. И представьте себе – довольны довольны.
Из минусов – неудобный клиентский движок у project server, отмечаться в задачах сложно. и еще порблемы с задачами, которые выполнены наполовину и больше ненужны
Что 10000 задач это много для одного проекта – так создавайте несколько! одна итерация – один проект
То, что люди незаменяемые – не распределяйте задачи “в лоб”. мы практикуем связку “проектный менеджер – дев лид” девлид распределяет задачи и выставляет оценки – ПМ определяет scope, управляет ходом проекта и ведет риски. все довольны

Alex Lebedev:
January 9th, 2007 at 06:23
Из минусов – неудобный клиентский движок у project server, отмечаться в задачах сложно. и еще порблемы с задачами, которые выполнены наполовину и больше ненужны
Насколько все плохо с клиентским движком? Если он работает только в IE и только при идеальном коннекте, то это может сделать его использование в ряде проектов технически невозможным.

Alex Lebedev:
January 9th, 2007 at 06:36
Что 10000 задач это много для одного проекта – так создавайте несколько! одна итерация – один проект.
Историческая информация о ходе проекта бывает, порой, критически важна для оценки ситуации. Вот здесь, например, мужик пытается доказать что содержимое базы issue tracking\’а – самая важная информация, которая есть в проекте:
Let\’s take a brief segue and talk about the huge value that exists in a bug database. In just about every company I\’ve worked at, the only source of measurable truth regarding the product is the bug database. Marketing documents get stale. Test plans become decrepit. Test case databases slowly mutate into the unusable personal to do list of QA. The bug database is the only source of data regarding your product.
Надо сказать, звучит убедительно.
Так вот, храня данные по каждой итерации в отдельном документе, вы обрекаете свой проект на легкую форму склероза (если файлы прошлых итераций не хранятся – то на тяжелую).

Макс:
January 10th, 2007 at 03:39
Статья понравилась, опыт использования issue tracking с 2000 года, как для управления софтверными проектами использовать MS Project не представляю до сих пор :)
Еще про MS Project:
MS Project не является issue tracking т.к. не поддерживает workflow – ключевой функциональности таких системы. Это значит, что нельзя просто создать задачу “Нужно пофиксить багу X”, нужно еще создать подзадачи типа “Менеджер Вася, мы будем это делать?”, “Программист Петя, можно делать”, “Тестировщик Коля, оно работает ?”.
Если этого не сделать, то мы
- не сможем настроить права, чтоб только Петя мог говорить что оно работает.
- не сможем посчитать сколько времени ушло на разработку, а сколько на тестирование
- вообще ничего не можем сказать что сейчас происходит с задачей и кто за нее отвечает именно сейчас.
Ну в общем я согласен, что уж лучше Excel, чем MS Project :-)
По поводу конкретных систем:
1) JIRA доску не заменяет, а дополняет :-) Вот доказательство в виде блога от разработчиков Confluence:
https://fishbowl.pastiche.org/2005/09/28/the_wall_of_death
JIRA хороша для общения с клиентами и для автоматизации business users, но для разработки софта она несколько слабовата в плане security и возможностей настройки workflow.
2) Пара примеров хороших и недорогих коммерческих систем:
- http://www.rmtrack.com/ – гибкая, но простая.
- http://www.trackstudio.ru/ – еще более гибкая, но не столь простая.

Манагер:
January 10th, 2007 at 03:47
У автора нет опыта работы в MSP – это видно с первых строк.

Alex Lebedev:
January 10th, 2007 at 03:49
Спасибо за содержательный комментарий.
Полностью согласен с рассуждениями про workflow. Именно это я и пытался объяснить в параллельном обсуждении на habrahabr.ru.

Alex Lebedev:
January 10th, 2007 at 03:56
JIRA хороша для общения с клиентами и для автоматизации business users, но для разработки софта она несколько слабовата в плане security и возможностей настройки workflow.
Моя позиция в том, что security – это в первую очередь не запреты, а аудит. Почти все системы ведут и отображают историю изменений.
Ну а от отсутствия настроек workflow еще еще никто не умирал, хотя с custom workflow жить, безусловно, приятнее.
Так что все зависит от проекта, ПМа и того, какая именно “разработка софта” имеется в виду.

Макс:
January 10th, 2007 at 03:58
Jira – многофункциональная issue tracking система. Продуманная поддержка как bugtracking так и project management функциональности.
На самом деле никакого отношения Jira (и подавляющее большинство issue tracking) к project management не имеет, а на сайте про project management пишут чтоб завлечь людей, которые про issue tracking не слышали :-)
Подавляющее большинство issue tracking систем:
не умеют делать иерархию задач (work breakdown structure), это ключевое понятие во всем project management: https://en.wikipedia.org/wiki/Work_breakdown_structure A Work Breakdown Structure (WBS) is a fundamental project management technique for defining and organizing the total scope of a project, using a hierarchical tree structure.
Наверное, единственная issue tracking система, понимающая WBS – это TrackStudio.
не умеют указывать произвольный start/finish date. Можно, конечно, кастом-поля использовать, но толку от этого обычно мало.
не умеют устанавливать сложные зависимости между задачами.
Получается интересная ситуация: вроде бы issue tracking и project management – очень близкие понятия, но сделать хороший интегрированный продукт пока ни у кого не получилось.

Макс:
January 10th, 2007 at 04:19
Моя позиция в том, что security – это в первую очередь не запреты, а аудит. Почти все системы ведут и отображают историю изменений.
А знаете какая бага #1 в JIRA Most Popular Issues ? :-) Вот эта, почитайте: https://jira.atlassian.com/browse/JRASERVER-1330
За багу подано 273 голоса, уже 5 год со времени создания скоро пойдет, а она даже не запланирована. И это всего-навсего field-level security.

Alex Lebedev:
January 10th, 2007 at 04:36
А знаете какая бага #1 в JIRA Most Popular Issues ? :-) Вот эта, почитайте:
За багу подано 273 голоса, уже 5 год со времени создания скоро пойдет, а она даже не запланирована. И это всего-навсего field-level security.

Вы меня убедили.
В моих последних проектах разработчиков и тестировщиков немного, а заказчики доступа к tracking’у либо не имеют, либо имеют в режиме read-only, поэтому fine grain security не особо актуальна. Если же к трэккингу имеет доступ много людей, то тонкая настройка безопасности необходима.
Могу предположить, что чаще всего из таких тонких настроек требуется field и row-level security.

Алексей:
January 10th, 2007 at 11:40
Топор нельзя использовать для постройки стен!
Топор (как и Project) всего лишь инструмент (только один из используемых).
Приведенное утверждение можно рассматривать только в связи с:
Какаю стену нужно построить (деревянную, кирпичную, бетонную…).
Как будет происходить строительство (сборка из отдельных бревен, кирпичей, блоков…).
Для чего пытаемся использовать топор (забивание гвоздей, выравнивание поверхности…).
Почти ничего из этого озвучено не было – отсюда разнобой в отзывах. Тот, кто обычно ставит деревянные срубы – категорически не согласен (там топор – один из главных). Тот, кто строит бетонные – согласен на все сто (обтесывать бетон топором – неэффективно).
MS Project, например, прекрасно подходит для визуализации (создания диаграмм, графиков) необходимых при выполнении работы в рамках определенной методики планирования (пример: сетевое планирование). Однако он не единственный инструмент и не реализует полностью ни одну из методик.
Обеспечьте импорт данных из issue-tracking в Project и используйте его для определения критического пути, например. Тут-то он и пригодится.
Не нужно забивать шурупы молотком, а гвозди закручивать отверткой. Тогда не будет и разочарования в свойствах этих инструментов.

Alex:
January 12th, 2007 at 03:50
Team Foundation Server от MS как раз и призван заполнить нишу. И интеграция с MS Project и Excel у него чудесная. Кроме того имеет место интеграция в среду Visual Studio 2005 и довольно сносная встроенная система контоля версий. Jira пользуюсь около полугода, не нравится ввиду предельного неудобства интерфейса, отсутствия возможности интеграции в студию, отсутствия интеграции с системой контроля версий, очень слабая система отчётности.
P.S. Пользуюсь TFS уже год (т.е. начиная с Beta)

Alex Lebedev:
January 12th, 2007 at 04:03
Еще не смотрел не Team Foundation Server, поэтому хотелось бы задать несколько вопросов.
Насколько продукт работоспособен БЕЗ интеграции с Visual Studio и встроенной системы контроля версий?
Каковы возможности интеграции с продуктами не от Microsoft?

Alex:
January 12th, 2007 at 04:08
Единственное, что хотел дополнить про TFS, что он пока ещё сыроват и нестабилен. И конечно, стоимость клиентских лицензий тоже поражает воображение :) Хотя на мой взгляд, это разумная плата за такую беспрецедентную гибкость и расширяемость, которую поддерживает данный программный продукт.

Alex:
January 12th, 2007 at 04:27
По поводу работоспособности без интеграции в студию. Tracking полностью интегирован в студию, т.е. через Web интерфейс (построенный на SharePoint), например, добавить Task невозможно (разве что проходом через Excel или MS Project). Правда есть отдельный продукт, который поставляется с TFS и называется Team Explorer. Team Explorer – это по сути функциональность работы с TFS в IDE Visual Studio. Кроме того полностью открыт API по управлению всем чем только можно в TFS (начиная с управляния задачами и требованиями и заканчивая управлением системой котроля версий) Поэтому уже существуют сторонние продукты позволяющие вынести Tracking в портал.
Существуют миграционные средства для системы контроля версий и видел миграционные средства для задач/требований. И есть ещё интересный продукт Requirements Management от Borland тоже построенный на базе TFS.

Alex Lebedev:
January 12th, 2007 at 05:15
Обычная, увы, история – ты или all-Microsoft, либо борешься с не очень дружественной интеграцией. Впрочем, ситуация с интеграцией, кажется, постепенно улучшается.

Alex:
January 12th, 2007 at 05:30
Слава Богу, они в этот раз всё на Web Services построили :) и не прятали API, так что можно надеяться, что со временем сторонние разработчики подтянутся. Если так дальше пойдёт, то может даже к следующей версии Майкрософт что-нибудь достойное выпустит.

clawfrown:
January 27th, 2007 at 12:03
Автор высказал все наболелое за несколько лет использования Project’а и попыток найти альтернативу. Trac у нас работает уже год, но используется именно как Issue/Bug Tracker..
Однако без полноценного Gantt-чарта планировать как-то тоже не комфортно..
Вот посмотрите сюда: ***
И эта штука имеет левелинг ресурсов и синхронизируется с iCal (типа Outlooc’а упрощенного, без почты и тп.. только календарь с тасками), где каждый исполнитель может просмотреть, поправить задачи как в личном планировщике..
Что сказать: Буду покупать Мак. Имхо, оно того стоит.

Alex Lebedev:
January 27th, 2007 at 09:17
Вот посмотрите сюда: ***
И эта штука имеет левелинг ресурсов и синхронизируется с iCal (типа Outlooc’а упрощенного, без почты и тп.. только календарь с тасками), где каждый исполнитель может просмотреть, поправить задачи как в личном планировщике..
Что сказать: Буду покупать Мак. Имхо, оно того стоит.

Project для Мака… По-моему, это те же яйца, только в профиль. Если наладить импорт данных из треккинга, то можно будет планировать с помощью красивых диаграмм, основываясь на реальных данных. Если пытаться использовать как основу для совместной работы – столкнетесь с теми же проблемами что и в Project’е, потому как продукт не ориентирован на обеспечение совместной работы в нужном масштабе.

pocomaxa:
January 27th, 2007 at 12:43
Отлично!. Давно используем в проекте Trac + SVN и очень рады. Но врага надо знать в лицо, спасибо за статью.

dem:
February 19th, 2007 at 06:53
По поводу Ворда:
Главный документ юзать пробовали?

Sanya Semenov:
February 20th, 2007 at 02:38
Уважаемый Alex Lebedev!
Очень хочетс я поделиться своим опытом использования МС Проджекта. Дело в том, что для строительства ента штуковина тоже ОЧЕНЬ тяжело налазит, требует рядом ОЧЕНЬ боьлшое число доп программ: сметную, учетную по договорам, бюджетную для графика расхода денег и “затратный” вариант.
Проджект не позволяет сделать в графике и план движения денег, и план затрат, имеет ограничения по ведению затрат в валюте.
И ГЛАВНОЕ: строительные проекты основаны на объеме работ. И эти объемы могут корректироваться. В Проджекте нет механизма расчета “от объемов и производительности”. В нем нет поддержки и “технологии работ”. То есть проеконтролировать, что человек по графику не начнет раньше работы по крыше, чем возведет стены – нету. А на 5000 – 15000 работ такое легко может быть.
Так что я прошу вас пересмотреть отношение к МС Проджекту как к программе для строительных проектов.
Мой опыт показывал, что Проджект хорош для ведения разноплановых проектов, офисных проектов, если при этом не ставят задачи управления финансами и бюджетами, согласованиями и т.п.

Ottis:
April 2nd, 2007 at 11:30
борец боксеру наваляет вряд ли…
MSP имеет свои задачи (и выполняет их лучше других). Хотя рассматриваем более дешевые альтернативы.
а трэкер используем TrackPlus
жаль что нет интегрированного средства
зато не путаем тёплое и мягкое

Artem:
April 2nd, 2007 at 06:05
Не могу сказать, что MSP хорошая система.
Но одно точно можно сказать – автор пытался забить гвоздь лазерной пушкой.
Дело в том, что ПРОЕКТ – это нежели иная сущность и мыслится она иначе нежели ISSUE. Как следствие, подход к проектам и наборам issues – разный. Отсюда и “проблемы”, о которых вы пишите в статье.
Пользуемся, конечно, двумя системами. Issues tracking (JIRA, TestTrack Pro) и MSP|MSPserver
Да, MSP|MSPserver – в каких-то кэйзах довольно неудобен, но он имеет
а. Открытую БД
б. API
Не буду говорить об качестве этих пунктов. НЕ идеально.
Однако, в умелых руках может справится с ОЧЕНЬ многими вопросами. Правда, на это требуется время.
По поводу статьи работы с Excel’ем – в MSP список задач позволяет делать все тоже самое, что и в Excel’е (включая и формулы, вычисления), только не нужно лениться.
А именно:
а. Понять что именно нужно и отрефлексировать почему именно это(самое сложное)
б. Настроить соотвествующим образом глобальный шаблон. В сложных случаях(построение ряда отчетов, интеграция) требуется допразработка.
в. Проверить результат.
При необходимости – повторить.
Обычно все проблемы работы с MSP связаны:
а. С багами от микрософта
б. С отсутствиями компетенций тех, кто работает с ним.
в. С отсуствием нормальной документации по проджекту (а точнее подходам к управлению проектами в проджекте).

Artem:
April 2nd, 2007 at 06:07
Кстати, рекомендую обратить пристальное внимание на IBM RPM.

Владимир Иванов:
April 5th, 2007 at 02:54
Думаю многие практикующие менеджеры прочитали это материал улыбаясь.
Конечно на 80% проблемы автора от недостатка опыта как в MS Project, так и в управлении IT-проектами.
Недостаток опыта в MS Project виден по тому как мало критики на MS Project Server. Типа плохой и все. На версию продукта для чайников (MS Project Std) замечания указывают на некоторый опыт работы с продуктом.
Недостаток опыта в управлении IT-проектами заметен в том, что путаются инструменты для отслеживания ПОРУЧЕНИЙ и проектных заданий. А разница есть. Непонятно?
Welcome to microsoftproject.ru

Вадим Геря, PMP, MCP:
October 9th, 2007 at 09:38
Господа !
Указанные здесь примеры и сведения не совсем корректны. Автор поверхностно знает платформу MS EPM 2003 (а тем более 2007) глубоко. Слово ПЛАТФОРМА – означает констуркутор, настраиваемый опытным консультаном под бизнесс Заказчика. Стандарный функционал конечно же беден и это нормально.
С уважением
Вадим Геря

mydim:
November 22nd, 2007 at 02:09
АВТОР ИМХО новичек, книгу по MS Project даже в руках не держал.
Большинство вещей указаных реализовано!
по вопросам обращайтесь на мыло.

Damir Shakirov:
April 25th, 2008 at 12:25
Можно использовать SharePoint 3.0 + MS Project.

Maxim Kramarenko / TrackStudio:
May 21st, 2008 at 11:37
Недостаток опыта в управлении IT-проектами заметен в том, что путаются инструменты для отслеживания ПОРУЧЕНИЙ и проектных заданий. А разница есть. Непонятно?
Мы занимемся разработкой багтрекера и путаница между issue tracking/project management заметна. Я изложил свои соображения тут, согласны ?
http://www.trackstudio.ru/forum/bug-tracking-project-management-issue-tracking-issue-1685.html

Alex Lebedev:
May 22nd, 2008 at 12:26:
Максим, спасибо за комментарий. Я рад, что спустя полтора года тема все еще не потеряла актуальности.
Путаница между понятиями действительно есть, но от нее никуда не деться, потому что во многих случаев управление задачами и есть успавление проектом.
Приятно было читать ваши мысли по ссылке — сразу видно человека, хорошо разбирающегося в теме. Мое видение вопроса несколько отличается, изложу его в отдельной статье как только дойдут руки.

S.Komarov:
May 23rd, 2008 at 01:07
Спасибо за статью. Без неё, после нескольких курсов обучения MSP, и не поняно, а что плохого:-) Мне кажется, что большинство критики к статье идёт от тех пользователей MSP, которые уже привыкли не замечать недостатков и приспособились использовать другие инструменты (включая собственные головы), чтобы эти недостатки обходить. Однако, все эти критики не замечают основой проблемы,изложенной в самом начале: модель данных MSP не соответсвует модели данных в голове у разработчика программ. TFS – как раз и заточена для устранения проблемы с моделью данных, что говорит о том, что и в MS понимают эту проблему, а так же о том, что интегрированного инструмента управления софтверными проектами, пока не существует. Не существует на рынке: вполне возможно, что прелегемоны такого инструмента уже сложились в недрах крупных разработческих компаний.

A. Novik:
June 6th, 2008 at 01:08
Здравствуйте!
Подскажите пожалуйста, что лучше использовать (пока остановили выбор на Project) в строительстве гипермаркетов?
Заранее благодарен.

Max:
July 9th, 2008 at 03:00
В строительстве гипермаркетов скорее всего придется использовать MS Project, т.к. не смотря на все его недостатки у него есть очень полезные фичи, которых нет в современных, так называемых Web 2.0 системах и которые весьма полезны в строительных проектах. Если же главная фича, которая привлекает в проджекте – ганнт чарт, то наши западные друзья же предлагают множество недорогих альтернатив, вот на пример. Вообще тема с проджектом не нова. Вот еще похожая статья.

Вадим Богданов (автор книг по Microsoft Project и управлению проектами):
December 29th, 2008 at 01:55
Коллеги,
очень жаль, что Алексей не разобравшись в функционале продукта утверждает, что в нем нет тех или иных функций.
Вот несколько самых вызывающих “ляпов”:
“Project рассчитан на меньшее количество задач, чем вам нужно.” Вообще-то он рассчитан на 1 млн задач, и для удобства Вы можете использовать вложенные проекты. У моих клиентов видел проекты по 10 000 строк – нормально работает.
“Project позволит вам случайно поменять ID задачи. ” Не позволяет, есть особое поле Unique ID, которое можно вывести в таблицу и которое не меняется программой.
“Исполнители взаимозаменяемы.” В Project Server есть возможность задать многоуровневую и многомерную модель компетенций для анализа возможности замены ресурсов друг другом.
“Для частично выполненной задачи можно правдоподобно оценить процент выполнения. ” Это вопрос не проджекта, а методики планирования. Я 2 года внедрял управление проектами и проджект в крупнейшем разработчике ПО в РФ и в сертификации процессов на уровень СММ 5.0 – могу сказать, что эти вопросы решаются более качественным планированием.
“ДеМарко пишет, что в абсолютном большинстве случаев срыв сроков вызван непредусмотренными в плане задачами, а не ошибками в оценке длительности предусмотренных.” – тут Автор противоречит сам себе, подтверждая, что его проблема в том, как он стоит декомпозицию работ. Если он забывает включтиь туда элементы, это не проблема программы ))
И так далее… Одним словом, проджект тут не причем, вопрос в том, как вы планируете и контролируете ход работ. А матчасть все-же надо учить (issue tracking есть в Project Server с 200-года, странно, что Автор это не заметил).
С уважением,
Вадим Богданов

Tonik:
January 13th, 2009 at 12:17
В строительстве лучше использовать Спайдер Проджект – отечественная разработка. Намного лучше МС Проджект. Используется, например, при планировании строительства объектов для Олимпиады 2014. (Порядка 240 штук).

SergM:
January 30th, 2009 at 01:04
Интересное мнение, хотя и большинство аргументов высосаны из пальца и свидетельствуют об отсутствии промышленного опыта использования MS Project [Server] в IT-проектах. Основываясь на личном опыте, утверждаю, что предположения автора по быстродействию и отсуствию комфорта в коллективной работе не подтверждаются при грамотной настройке сервера. А гипотетические иллюзии, якобы заложенныые в MS Project на самом деле существуют в мозгах автора и не привязаны к конкретному инструменту.

Head of PMO:
February 4th, 2010 at 05:44
Уважаемый автор!
Прочитал ваш труд. Аргументы, приведенные вами, заставляют меня улыбнуться и только.
Подмена понятий. Заголовок гласит “MSP нельзя использовать для управления проектами”. Однако, статья относится только к проектам по разработке software. Некрасиво. Вы забыли, что существует целая куча других проектов.
Фраза “Лично не проверял, но могу предположить…” заставляет меня улыбнуться еще раз. Не проверяли – почему так уверенно говорите?
Вы правы, ID постоянно меняются. Конечно, Microsoft’у следовало назвать это поле “Номер строки”, как в Excel. Но весь мир давно пользуется WBS-кодами для идентификации задач. Это удобней, наглядней и помогает разбираться в большом объеме схожих задач. Вы просто не дочитали книжку по MS Project.
Жизненный цикл задач должен быть подробным, чтобы обеспечить управляемость. Понятие “громоздкость” известна только вам, как руководителю проекта. Участники проекта расписание в целом могут и не увидеть до конца проекта. “Громоздкое расписание” позволяет точно знать, в чьих руках сейчас находится “мячик” и когда это все закончится.
Взаимозаменяемость ресурсов. Просто хохма. Если вы как менеджер доверяете софту замену людей на задачах, то вы – просто технический администратор проекта. Прежде чем заменить одного сотрудника на другого, вы обязаны выполнить весьма трудоемкую процедуру по оценке трудозатрат “новых сотрудников”, добиться согласования их руководителя, убедиться, что расписание останется в рамках и т.п. И только потом нажать Alt+F10 и заменить сотрудников.
Процент выполнения нужен только тогда, когда вы не утруждаете себя “громоздким расписанием” (см.4). Тогда вы заранее должны определить, что означает 50-75-100% для конкретного проекта. Мой совет – детализируйте задачи до 1 недели и отмечайте выполнение по принципу 0-100%.
Длительность проекта – является следствием длительностей задач и сетевого графика. Если у вас по-другому, значит вы не управляете проектом. Попробуйте прийти к инвестору за деньгами и на вопрос “Когда вы рассчитываете закончить проект?” ответить “Не знаю”.
Совместная работа в Microsoft Project требует отдельного разговора. Все можно сделать, если захотеть. Скажу только, что никто не снимал с вас необходимости организовывать взаимодействие людей лично. Забудьте про программу. Займитесь людьми.
Серверная версия. То, что у вас не получилось поставить сервер не говорит, что он плохо работает.

Kent:
February 7th, 2010 at 02:38
автор! Прежде чем рассуждать вобще об управлении проектами изучи стандарт PMBOK. И тогда поймешь, из каких процессов управление проектами состоит и какие задачи решаются с помощью проджекта. У тебя лишь управление проектами сводится к процессам управления выполнением задач


⇓ 

Поделись ссылкой на Seoded.ru с друзьями, знакомыми и собеседниками в соцсетях и на форумах! А сам сайт добавь в закладки! Так победим.

Поделиться ссылкой на эту страницу в:

Полезные ссылки:

Заработай на футбольных ставках Узнай моё мнение о заработке на Форексе

Ещё материалы по этой теме:

Trac — швейцарский нож среди инструментов управления проектом Как зайти на заблокированный сайт cmsTD — панель для мини-сайтов Хакеры атакуют, или Чем опасны социальные сети ЗСД: нам не нужны ваши деньги
основан в 2008 г. © Все права на материалы сайта Seoded.ru принадлежат Алексею Вострову.
Копирование (полное или частичное) любых материалов сайта возможно только с разрешения автора и при указании ссылки на источник.
Ослушавшихся находит и забирает Бабайка!