Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 31
Это иезуитство — рассуждать, почему программеры не могут вести проект разработки в MS Project.
Да просто потому, что для этого есть совсем другие инструменты. А уж эти инструменты вполне можно интегрировать с Project, например, для портфельного управления, как это делает TFS или другие системы поддержки цикла разработки.
>MS Project имеет очень много способов сделать процесс планирования и мониторинга сложным и невыносимым и по сравнению с необходимыми трудозатратами приносит довольно мало реальной пользы.
Сдаётся мне, вы просто не умеете его готовить.
Да просто потому, что для этого есть совсем другие инструменты. А уж эти инструменты вполне можно интегрировать с Project, например, для портфельного управления, как это делает TFS или другие системы поддержки цикла разработки.
>MS Project имеет очень много способов сделать процесс планирования и мониторинга сложным и невыносимым и по сравнению с необходимыми трудозатратами приносит довольно мало реальной пользы.
Сдаётся мне, вы просто не умеете его готовить.
А уж эти инструменты вполне можно интегрировать с Project
А в чём value от Project'а тогда будет?
Сдаётся мне, вы просто не умеете его готовить.
Был бы благодарен за детальный разбор описанных в тексте проблем, а не за ответ на единственную фразу из summary.
А в чём value от Project'а тогда будет?
Сдаётся мне, вы просто не умеете его готовить.
Был бы благодарен за детальный разбор описанных в тексте проблем, а не за ответ на единственную фразу из summary.
>А в чём value от Project'а тогда будет?
Я же написал — портфельное управление проектами.
Можно добавить расчет стоимости, агрегированных показателей и т.д.
>Был бы благодарен за детальный разбор описанных в тексте проблем
Суть описаных проблем в том, что MS Project — это инструмент, который надо изучать. Мне кажется, тут нечего обсуждать. Это всё равно, что наезжать на какой-нибудь скриптовый или динамический язык, что там нет жесткой типизации, а это путает непрофессиональных пользователей.
Мне кажется, имело бы смысл рассматривать именно такой ракурс: кто из специалистов должен пользоваться и владеть MS Ppoject, а кому достаточно отмечать в своей среде разработки поставленную ему задачу как выполненную с указанием фактических затрат.
Я же написал — портфельное управление проектами.
Можно добавить расчет стоимости, агрегированных показателей и т.д.
>Был бы благодарен за детальный разбор описанных в тексте проблем
Суть описаных проблем в том, что MS Project — это инструмент, который надо изучать. Мне кажется, тут нечего обсуждать. Это всё равно, что наезжать на какой-нибудь скриптовый или динамический язык, что там нет жесткой типизации, а это путает непрофессиональных пользователей.
Мне кажется, имело бы смысл рассматривать именно такой ракурс: кто из специалистов должен пользоваться и владеть MS Ppoject, а кому достаточно отмечать в своей среде разработки поставленную ему задачу как выполненную с указанием фактических затрат.
Good point насчёт project portfolio management, это важная тема. А какие процессы управления портфелем поддерживает связка TFS + Project + Project Server? Я тут с готовностью признаюсь в невежестве, мы в нашей компании portfolio management ведём в некоем внутреннем самописном инструменте и альтернатив ему никогда не искали.
Навскидку, может ли мне эта связочка ещё помочь сделать следующее:
Я подозреваю, что Microsoft должен обеспечивать какую-то интеграцию со своими ERP из семейства Dynamics.
Навскидку, может ли мне эта связочка ещё помочь сделать следующее:
- Управлять загрузкой пула ресурсов. Кто в компании есть, что он умеет, чем он занят, сколько он стоит. Тупо глобальный список ресурсов Project Server умел ещё в 2002й версии, но я там честно говоря не помню, был ли там «внутренний рейт» (сколько стоит человек компании) в отличие от «внешнего рейта». Ну и всё остальное, типа «человек запланирован на проект X» и т.д.
- Управлять пайплайном. Какие проекты на нас надвигаются, кто там нужен и как мы их будем делать. Интеграция с CRM (мы используем MS Dynamics CRM) очень желательна.
- Управлять финансами. Какие у меня плановые показатели основных финансовых метрик и каковы актуальные (на уровне проекта и аккаунта как минимум)? Поддержка инвойсинга тоже очень бы не помешала.
- Управлять портфельными рисками.
- Всё, что связано с HRM, я опускаю, это мало кто умеет (тут мы кстати опять же CRM используем).
Я подозреваю, что Microsoft должен обеспечивать какую-то интеграцию со своими ERP из семейства Dynamics.
Полностью поддерживаю.
Мы рисуем всё в MS Project, а потом импортируем как User Story в TFS, а дальше подправляем экспортируя в Excel и после исправлений закидываем большим куском обратно в TFS.
Понятное дело, что скрестить SVN/GIT/Mercurial или ещё 100500 — не реально, а прикрутить к этому всему ещё и трэкинг — не простая задача.
У нас менеджеры работают с Excel'ем и Project'ом, программисты с задачами в TFS, тестеры с Test Lab'ом, который тоже есно связан с TFS… итд.
Мы рисуем всё в MS Project, а потом импортируем как User Story в TFS, а дальше подправляем экспортируя в Excel и после исправлений закидываем большим куском обратно в TFS.
Понятное дело, что скрестить SVN/GIT/Mercurial или ещё 100500 — не реально, а прикрутить к этому всему ещё и трэкинг — не простая задача.
У нас менеджеры работают с Excel'ем и Project'ом, программисты с задачами в TFS, тестеры с Test Lab'ом, который тоже есно связан с TFS… итд.
Проведите такой же детальный разбор использования Microsoft Team Foundation Server для планирования и ведения минимально сложных софтверных проектов.
Я не имею личного опыта использования TFS и слышал про него диаметрально противоположные оценки. В компании, где я работаю, был опыт успешного исполнения проектов с использованием TFS, но у меня недостаточно данных, чтобы понять, помогал в тех командах TFS или мешал. В компании мы продвигаем в качестве стандартного инструмента либо Jira+Greenhopper, либо TFS. Я лично всегда рекомендую Jira+Greenhopper, но если менеджер проекта и команда настаивают на TFS, я обычно не сопротивляюсь.
TFS очень удобная штука, хоть и требует бОльших ресурсов.
У нас 3 сервера, которые обеспечивают нам работу: База данных TFS (MS SQL), Веб сервер (Sharepoint & TFS Web), Test Lab, иногда появляются ещё доп. сервера как сборки проектов.
И о чудо, это всё работает вместе.
Падает билд — сразу же открывается задача в TFS «Упал билд»,
Тестеры закончили очередную проверку — вот тебе целая пачка разного рода задач.
Нужна аналитика? Вот тебе и отчёты по проекту, большенство уже из коробки идёт.
Нужно что-то массово изменить — экспорт в MS Project & Excel, исправления и потом импорт.
Да, работать с RoR, PHP, и прочими non-msft продуктами там действительно ооочень сложно, мы пробовали фрэшовые проекты там держать — не самая удачная идея была. А весь MSFT stack — там живёт как в раю.
У нас 3 сервера, которые обеспечивают нам работу: База данных TFS (MS SQL), Веб сервер (Sharepoint & TFS Web), Test Lab, иногда появляются ещё доп. сервера как сборки проектов.
И о чудо, это всё работает вместе.
Падает билд — сразу же открывается задача в TFS «Упал билд»,
Тестеры закончили очередную проверку — вот тебе целая пачка разного рода задач.
Нужна аналитика? Вот тебе и отчёты по проекту, большенство уже из коробки идёт.
Нужно что-то массово изменить — экспорт в MS Project & Excel, исправления и потом импорт.
Да, работать с RoR, PHP, и прочими non-msft продуктами там действительно ооочень сложно, мы пробовали фрэшовые проекты там держать — не самая удачная идея была. А весь MSFT stack — там живёт как в раю.
Мы делали так: в TFS набрасывали все задачи со явными зависимостями, а MS Project использовали для распределения загрузки.
В MS Project 2010 впервые появились реально две полезные вещи, немного повернувшие его лицом к софтверным проектам:
1) Планировщик работы группы, визуально показывающий последовательность задач, назначенных на каждого человека, и
2) Ручное планирование (когда искуственный интеллект спит)
Это позволяло использовать такую схему: создавать в TFS все задачи (с оценками трудозатрат, но без указания сроков), потом подкачивать их в MS Project, там двигать задачи в планировщике, выравнивая нагрузку, и потом публиковать всё это обратно в TFS.
Диаграмма Гантта при этом использовалсь как побочный продукт для отчётов, передаваемых начальству. А файл mpp не использовался вовсе: вся актуальная информация хранилась в TFS.
Учитывая, что все остальные 99% наворотов Project при этом просто не использовались, наверное, было бы неплохо иметь вместо него облегченный инструмент как надстройку над TFS. Может, такой и появится (если уже не появился).
В MS Project 2010 впервые появились реально две полезные вещи, немного повернувшие его лицом к софтверным проектам:
1) Планировщик работы группы, визуально показывающий последовательность задач, назначенных на каждого человека, и
2) Ручное планирование (когда искуственный интеллект спит)
Это позволяло использовать такую схему: создавать в TFS все задачи (с оценками трудозатрат, но без указания сроков), потом подкачивать их в MS Project, там двигать задачи в планировщике, выравнивая нагрузку, и потом публиковать всё это обратно в TFS.
Диаграмма Гантта при этом использовалсь как побочный продукт для отчётов, передаваемых начальству. А файл mpp не использовался вовсе: вся актуальная информация хранилась в TFS.
Учитывая, что все остальные 99% наворотов Project при этом просто не использовались, наверное, было бы неплохо иметь вместо него облегченный инструмент как надстройку над TFS. Может, такой и появится (если уже не появился).
>О том, что мы рекомендуем использовать, будет рассказано в отдельной статье.
«Мы»- это кто?
«Мы»- это кто?
Спасибо за статью. Работал когда-то с MS Project на уровне юниора для отслеживания больших не программных и частично программных продуктов. Ад и ужас.
Имея за плечами большой опыт успешного применения MS Project для управления именно софтверными проектами, совершенно не могу согласиться с такой абсолютистской оценкой автора. Оценка скорее эмоциональная, чем практическая.
Я согласен с тем, что MS Project откровенно плохо приспособлен для управления часто изменяющимися проектами. Но, честно говоря, я не знаю другого инструмента, который бы имел сравнимую функциональность.
Я успешно применял MS Project для планирования и отслеживания хода выполнения проекта. Я никогда не рассматривал его как инструмент совместной работы. Файл MS Project — это моя личная модель проекта. Изменения в него вношу только я. Я могу отдельным людям показывать отдельные выжимки из него, может быть использовать верхнеуровневые диаграммы Ганта в качестве отчетов начальству. Но сам файл проекта — это мой персональные инструмент как руководителя проекта. Отслеживание выполнения задач осуществляется другими средствами. Тут назывались Jira, TFS — это не суть важно. Перенести несколько задач в эти системы и раз в неделю отмечать как что движется — это не напряжно. Зато узкие места проекта становятся видны сразу же, а не в конце этапа.
P.S. если кому-то интересно, могу поделиться своей методологией использования MS Project для управления софтверными проектами.
Я согласен с тем, что MS Project откровенно плохо приспособлен для управления часто изменяющимися проектами. Но, честно говоря, я не знаю другого инструмента, который бы имел сравнимую функциональность.
Я успешно применял MS Project для планирования и отслеживания хода выполнения проекта. Я никогда не рассматривал его как инструмент совместной работы. Файл MS Project — это моя личная модель проекта. Изменения в него вношу только я. Я могу отдельным людям показывать отдельные выжимки из него, может быть использовать верхнеуровневые диаграммы Ганта в качестве отчетов начальству. Но сам файл проекта — это мой персональные инструмент как руководителя проекта. Отслеживание выполнения задач осуществляется другими средствами. Тут назывались Jira, TFS — это не суть важно. Перенести несколько задач в эти системы и раз в неделю отмечать как что движется — это не напряжно. Зато узкие места проекта становятся видны сразу же, а не в конце этапа.
P.S. если кому-то интересно, могу поделиться своей методологией использования MS Project для управления софтверными проектами.
Было бы очень интересно ознакомиться с методологией.
ок, постараюсь до конца недели замутить пост, для комментария слишком много текста получается ;-).
С некоторым опозданием от обещанного срока :-) но написал :-)
habrahabr.ru/post/151593/
habrahabr.ru/post/151593/
Согласен с автором.
За долие годы руководства разработкой у меня даже накопился некий теорикрафт по данному вопросу. Он частично совпадает с описанным в статье, но есть еще ряд высокоуровневых выкладок, которыми я пытаюсь выделить причины — почему оно в MS Project имнно так. Вкратце мои выкладки выглядят следующим образом:
1. Разработка софта — она очень разная. Технологии, инструменты и проблеммы, которые характерны для поточной автоматизации бизнеса внешним заказчикам практически не пересекаются с технологиями, инструментами и проблеммами в области, например, написания драйверов. Или разработки игр. Или создания веб страничек. Или создания коробочных продуктов.
2. Если напрячься и попробовать выделить нечто общее, что присуще большинству софтовых проектов и что отличает их от других областей, то вырисовывается нулевая цена копирования. Тоесть если что-то сделано один раз, то в большинстве случаев это же второй раз делать не нужно — достаточно скопировать существующее решение. Это очень грубая зарисовка, и из нее есть миллион исключений, начиная от «лицензия на 1С очень дорогая, давайте для наших скромных нужд напишем то же самое, но только то что нам нужно — выйдет дешевле» и заканчивая «у них там ноу-хау, которое позволяет обрабатывать звук в реальном времени в десять раз быстрее, чем у нас. Нужно повторить». Но в общем случае можно утверждать, что лицензия на существующее решение стоит дешелвле чем разработка такого же, а ноу хау реально мало — потому как патенты открыты, да и reverse engeneering софта дело не то чтобы очень сложное.
3. Технологии очень быстро меняются. Примерно раз в пять лет.
4. Нулевая цена копирования и быстрая смена технологий приводят к тому, что разработчики каждый раз делают что-то новое. Безусловно, также как и для нулевой цены копирования, тут есть миллион исключений — начиная от изготовления сайтов-визиток, где каждый последующий ничем не отличается от предыдущего, и заканчивая интеграцией какого-нибудь SAP для автоматизации бизнеса, где инструменты и подходы давно и надежно заморожены. Но в общем случае у нас на проекте нет людей которые именно это уже делали больше одного раза.
5. То, что значительная часть задач делается в первый раз, без накопленного опыта и проверенных решений, приводит к повышенным рискам. Если бригада строителей строит дом — то она до этого построила уже двадцать домов, отучилась в соответствующем ПТУ и ознакомилась с опытом старших товарищей. У них, за редким случаем, не будет сюрпризов. Если мы пишем клиет вконтакте под Android — то мы скорее всего первый раз пишем клиент вконтакте и первый или второй раз пишем под android :).
6. Разработка программ — очень широкая область. Умения топового веб разработчика могут пересекаться с умениями топового разработчика драйверов менее, чем на 20 процентов. Поэтому, в отличие от традиционных управленческих задач, у нас нету «строитель — одна штука». У нас есть программисты с разными наборами скиллов в сотнях областей и разными областями интересов, где они готовы изучать что-то новое. Соответственно срок и риски по задаче, если ее дать разным разработчикам, могут отличаться на порядок.
Последние два пункта приводят к тому, что задачи, которыеми мы управляем, в большинстве случаев нифига не характеризуются такими привычными категориями как «сложность в человекочасах» и «выполнено». У задачи просто отсутствует «объективная сложность» — в зависимости от набора умений разработчика одна и та же задача может выполняться как день, так и неделю. Во-вторых, так как мы на острие прогресса ползем по минному полю, то здачи естественно и регулярно порождают из себя другие задачи, неожиданно разваливаются на несколько несвязанных задач, отменяются (потому что оказалось, что так это сделать нельзя) и мутируют (потому что оказалось, что это надо делать по другому).
Microsoft Project хрошо приспособлен к управлению строительством домов и рытьем траншей. Но он не приспособлен к управлению строительством домов на Юпитере, по технологии Хищников командой Чужих :(.
Если кто считает что я где-то ошибся в выкладках — буду очень благодарен за комментарии.
За долие годы руководства разработкой у меня даже накопился некий теорикрафт по данному вопросу. Он частично совпадает с описанным в статье, но есть еще ряд высокоуровневых выкладок, которыми я пытаюсь выделить причины — почему оно в MS Project имнно так. Вкратце мои выкладки выглядят следующим образом:
1. Разработка софта — она очень разная. Технологии, инструменты и проблеммы, которые характерны для поточной автоматизации бизнеса внешним заказчикам практически не пересекаются с технологиями, инструментами и проблеммами в области, например, написания драйверов. Или разработки игр. Или создания веб страничек. Или создания коробочных продуктов.
2. Если напрячься и попробовать выделить нечто общее, что присуще большинству софтовых проектов и что отличает их от других областей, то вырисовывается нулевая цена копирования. Тоесть если что-то сделано один раз, то в большинстве случаев это же второй раз делать не нужно — достаточно скопировать существующее решение. Это очень грубая зарисовка, и из нее есть миллион исключений, начиная от «лицензия на 1С очень дорогая, давайте для наших скромных нужд напишем то же самое, но только то что нам нужно — выйдет дешевле» и заканчивая «у них там ноу-хау, которое позволяет обрабатывать звук в реальном времени в десять раз быстрее, чем у нас. Нужно повторить». Но в общем случае можно утверждать, что лицензия на существующее решение стоит дешелвле чем разработка такого же, а ноу хау реально мало — потому как патенты открыты, да и reverse engeneering софта дело не то чтобы очень сложное.
3. Технологии очень быстро меняются. Примерно раз в пять лет.
4. Нулевая цена копирования и быстрая смена технологий приводят к тому, что разработчики каждый раз делают что-то новое. Безусловно, также как и для нулевой цены копирования, тут есть миллион исключений — начиная от изготовления сайтов-визиток, где каждый последующий ничем не отличается от предыдущего, и заканчивая интеграцией какого-нибудь SAP для автоматизации бизнеса, где инструменты и подходы давно и надежно заморожены. Но в общем случае у нас на проекте нет людей которые именно это уже делали больше одного раза.
5. То, что значительная часть задач делается в первый раз, без накопленного опыта и проверенных решений, приводит к повышенным рискам. Если бригада строителей строит дом — то она до этого построила уже двадцать домов, отучилась в соответствующем ПТУ и ознакомилась с опытом старших товарищей. У них, за редким случаем, не будет сюрпризов. Если мы пишем клиет вконтакте под Android — то мы скорее всего первый раз пишем клиент вконтакте и первый или второй раз пишем под android :).
6. Разработка программ — очень широкая область. Умения топового веб разработчика могут пересекаться с умениями топового разработчика драйверов менее, чем на 20 процентов. Поэтому, в отличие от традиционных управленческих задач, у нас нету «строитель — одна штука». У нас есть программисты с разными наборами скиллов в сотнях областей и разными областями интересов, где они готовы изучать что-то новое. Соответственно срок и риски по задаче, если ее дать разным разработчикам, могут отличаться на порядок.
Последние два пункта приводят к тому, что задачи, которыеми мы управляем, в большинстве случаев нифига не характеризуются такими привычными категориями как «сложность в человекочасах» и «выполнено». У задачи просто отсутствует «объективная сложность» — в зависимости от набора умений разработчика одна и та же задача может выполняться как день, так и неделю. Во-вторых, так как мы на острие прогресса ползем по минному полю, то здачи естественно и регулярно порождают из себя другие задачи, неожиданно разваливаются на несколько несвязанных задач, отменяются (потому что оказалось, что так это сделать нельзя) и мутируют (потому что оказалось, что это надо делать по другому).
Microsoft Project хрошо приспособлен к управлению строительством домов и рытьем траншей. Но он не приспособлен к управлению строительством домов на Юпитере, по технологии Хищников командой Чужих :(.
Если кто считает что я где-то ошибся в выкладках — буду очень благодарен за комментарии.
Я считаю ошибкой думать, что MS Project должен что-то делать за нас. Это — просто инструмент. Он работает по определенным правилам. Если понимать и использовать эти правила, то есть возможность получать от этого инструмента немалую пользу, а именно — разгрузить мозг, составив модель проекта в виде плана в MS Project, внося изменения в модель понимать, как они скажутся на проекте в целом. MS Project окажется очень плохим инструментом, если целиком полагаться на его встроенную «автоматику» — она, действительно, не всегда очевидна. Также не всегда удобно пользоваться некоторыми очевидными возможностями, например, вложенные задачи — это просто кошмар! :-)
Э… А какое это отношение имеет к моему комментарию? O_O
>>согласен с автором
А, понял. Поясню свою позицию. MS Project, конечно, никому ничего не должен. Но как инструмент он решает нам ряд задач. Позиция автора в том, что задачи, для решения которых создан MS Project и задачи, которые встают перед нами при управлении проектами по разработке — это очень разные задачи.
Тоесть вы предлагаете использовать MS Project для какого-то «моделирования», а для планирования проекта другие решения? А зачем тогда MS Project? Насколько я знаю, любое специализированное решение для планирования и управления разработкой ПО способно по текущим данным строить «модели» любой степени детализированности.
разгрузить мозг, составив модель проекта в виде плана в MS Project, внося изменения в модель понимать, как они скажутся на проекте в целом
Тоесть вы предлагаете использовать MS Project для какого-то «моделирования», а для планирования проекта другие решения? А зачем тогда MS Project? Насколько я знаю, любое специализированное решение для планирования и управления разработкой ПО способно по текущим данным строить «модели» любой степени детализированности.
Так моделирование — это есть планирование. Модель проекта (читай — план) в MS Project позволяет руководителю видеть что происходит в проекте и что (теоретически) будет происходить.
MS Project — ужасно неудобный инструмент. Чтобы его успешно использовать — нужно быть чертовски аккуратным. НО! к сожалению, это единственный известный мне доступный инструмент с подобной функциональностью. Другие инструменты, которые более простые в использовании, не обладают аналогичной функциональностью. Собственно, про это автор также пишет.
Для себя я выработал ряд достаточно механистичных правил, которые позволяют получать от MS Project реальную пользу и по минимуму сталкиваться с его недостатками. Я планирую написать пост про это в ближайшее время.
Мне очень интересно, какое решение порекомендует автор в последующих постах, буду ждать.
MS Project — ужасно неудобный инструмент. Чтобы его успешно использовать — нужно быть чертовски аккуратным. НО! к сожалению, это единственный известный мне доступный инструмент с подобной функциональностью. Другие инструменты, которые более простые в использовании, не обладают аналогичной функциональностью. Собственно, про это автор также пишет.
Для себя я выработал ряд достаточно механистичных правил, которые позволяют получать от MS Project реальную пользу и по минимуму сталкиваться с его недостатками. Я планирую написать пост про это в ближайшее время.
Мне очень интересно, какое решение порекомендует автор в последующих постах, буду ждать.
Всем порочащим на MS рекомендую сходить к экспертам Luxoft на курсы по Project. Там учат те, кто рулил не хилыми проектами по проектированию софта. Расскажут: что, как и зачем.
А продолжения статьи так и не появилось? Или автор просто взял небольшую паузу для написания? ;)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Microsoft Project delenda est