1
Управление Проектом / Re: Декомпозиция задач в MsProject
« : 04 Декабря 2011, 21:42:56 »
Просто хотелось у практиков спросить, кто как обычно ведет.
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
2
Управление Проектом / Re: Декомпозиция задач в MsProject
« : 04 Декабря 2011, 21:33:02 »
Аналитики, тестировщики и разработчики распределены по отделам.
Но при старте проекта все принадлежат команде проекта, т.е. подчиняются РМ и линейному руководитель, но все же фактически закреплены за Проектом.
Но при старте проекта все принадлежат команде проекта, т.е. подчиняются РМ и линейному руководитель, но все же фактически закреплены за Проектом.
3
Управление Проектом / Декомпозиция задач в MsProject
« : 03 Декабря 2011, 21:35:21 »
Простой вопрос к тем, кто пользуется Прожектом:
Как вы обычно делаете делаете декомпозицию работ: по задачам или направлениям деятельности?
Пример:
1. Декомпозиция по задачам:
Задача 1
Аналитика
Разработка
Тестирование
Задача 2
Аналитика
Разработка
Тестирование
2. Декомпозиция по направлению деятельности:
Аналитика
Задача 1, Задача 2, ...
Разработка
Задача 1, Задача 2, ...
Какой вариант более корректен для анализа затрат и курирования направлений?
Или это дело вкуса?
Как вы обычно делаете делаете декомпозицию работ: по задачам или направлениям деятельности?
Пример:
1. Декомпозиция по задачам:
Задача 1
Аналитика
Разработка
Тестирование
Задача 2
Аналитика
Разработка
Тестирование
2. Декомпозиция по направлению деятельности:
Аналитика
Задача 1, Задача 2, ...
Разработка
Задача 1, Задача 2, ...
Какой вариант более корректен для анализа затрат и курирования направлений?
Или это дело вкуса?
4
Управление Проектом / Re: План управления проектом
« : 21 Июня 2011, 21:07:02 »
Спасибо!
В принципе пришла к аналогичным выводам, в том числе и после переписки с вами.
Благодарю за помощь
В принципе пришла к аналогичным выводам, в том числе и после переписки с вами.
Благодарю за помощь
5
Управление Проектом / Re: План управления проектом
« : 20 Июня 2011, 23:36:18 »
Уважаемый Водолей!
Большое вам спасибо за ваш развернутый ответ!
Каша у меня в голове есть и еще какая (не обидно, что вы это говорите).
Я действительно не занимаюсь управлением проектами, просто иногда читаю некоторые книжки и статьи.
А вот теперь возникает новая доработка системы с этим же заказчиком: новый договор, новый менеджер, новая команда, новый список работ, а также новые проблемы с инициацией проекта (сбор команды, протоколы и т.д.) и, полагаю, новые заморочки со сдачей.
Каша в моей голове возникла в силу двух причин:
- отсутствие формального документа вида "План управления проектом" при первом договоре
- непонимание, чем является доработка системы. С одной стороны, вроде как новый проект (он же имеет все стадии проекта - от инициации до закрытия). С другой стороны, какой же он новый? Вроде как этап этого же проекта. НО: Проект - явление временное и завершается, как я понимаю, тем что все работы сданы (а это впрочем также определяется договорами)
Нашла образец плана управления проектом.
так вот там есть такие приложения:
* План управления содержанием (вот они работы из договора)
* План обеспечения проекта персоналом (вот тут прописываются участники проекта, а они могут меняться на следующем витке развития продукта)
* План управления поставками (в том числе и поставщиками, а они могут меняться как раз при заключении нового договора)
* План управления бюджетом (финансирование по договору)
* Закрытие проекта
В общем, много завязано, как ни страно, на бюджеты и сроки
Опять же возращаюсь к понятию включения в план описания общих, устоявшихся процедур фирмы, и более изменчивых планов по управлению содержанием, ресурсами, бюджетом.
Устав однако иногда вытекает из ТЗ
Кстати, уважаемый Водолей.
А если бы вы закрыли договор, сдали акты, подписали протоколы и т.д.
А потом заказчик предложил вам новый договор, с новым бюджетом и новым ТЗ.
Причем ТЗ это было явно на "развитие комплекса" (написание нового функционала)
В договоре прописал бы новые этапы сдачи по доработке.
Для вас это был бы новый проект? А для него нужен план управления ПРОЕКТОМ (именно этим проектом, а не проектами компании)?
Наверно, стоит тогда делать отдельные планы, которые стандартны для всех проектов и отдельные планы (план управления содержанием проекта; план управления расписанием; план управления стоимостью)
А план управления проектов делать как композция "индивидуальных" планов + "общих" планов
Большое вам спасибо за ваш развернутый ответ!
Каша у меня в голове есть и еще какая (не обидно, что вы это говорите).
Я действительно не занимаюсь управлением проектами, просто иногда читаю некоторые книжки и статьи.
Цитировать
План управления проектом (Project Charter) пишется для того, чтобы знать как управлять НОВЫМ проектом.Проблема в том, что старый проект сдан, потому как
Цитировать
"менеджер будет иметь головную боль по закрытию договора (акты, сверки, платежи, протоколы, договоренности и много всякой ерунды)". Собственно говоря, все протоколы и акты подписаны, договор закрыт (и все этапы, прописанные в договоре, сданы).
А вот теперь возникает новая доработка системы с этим же заказчиком: новый договор, новый менеджер, новая команда, новый список работ, а также новые проблемы с инициацией проекта (сбор команды, протоколы и т.д.) и, полагаю, новые заморочки со сдачей.
Каша в моей голове возникла в силу двух причин:
- отсутствие формального документа вида "План управления проектом" при первом договоре
- непонимание, чем является доработка системы. С одной стороны, вроде как новый проект (он же имеет все стадии проекта - от инициации до закрытия). С другой стороны, какой же он новый? Вроде как этап этого же проекта. НО: Проект - явление временное и завершается, как я понимаю, тем что все работы сданы (а это впрочем также определяется договорами)
Нашла образец плана управления проектом.
так вот там есть такие приложения:
* План управления содержанием (вот они работы из договора)
* План обеспечения проекта персоналом (вот тут прописываются участники проекта, а они могут меняться на следующем витке развития продукта)
* План управления поставками (в том числе и поставщиками, а они могут меняться как раз при заключении нового договора)
* План управления бюджетом (финансирование по договору)
* Закрытие проекта
В общем, много завязано, как ни страно, на бюджеты и сроки
Цитировать
при этом план не ограничивается сроками, ресурсами и т.п. Это этап выполнения ограничивается этими факторами.Я думаю план управления проектом содержит, можно так выразиться, "операционные" планы (куда входят план управления содержанием) и более "фундаментальные" планы (план управления качеством, коммуникациями). Вот последние никак не ограничиваются сроками и ресурсами.
Цитировать
Существует интересная особенность, что проект и договор могут находиться в любом ...э... "соотношении": может быть один договор и много проектов, но может быть и наоборот.Спасибо за замечание. Вещь очевидная, а сразу в голову не приходит.
Цитировать
могут появиться другие договоры и подпроекты (или просто проекты).Вот это интересней. Может разработка продукта - проект, а доработка системы - подпроект.
Цитировать
А план может быть, грубо говоря, один на всю жизнь.смущает название "План управления ПРОЕКТОМ". Особенно с ремаркой, что проект есть предприятие временное, имеющие завершение.
Опять же возращаюсь к понятию включения в план описания общих, устоявшихся процедур фирмы, и более изменчивых планов по управлению содержанием, ресурсами, бюджетом.
Цитировать
Поэтому целесообразно иметь один план для управления всей совокупностью проектов и подпроектов, причем независимо от количества договоров :о)))А PMBOK в качестве входов для плана управления проектом выделяет такой документ как Устав проекта.
Устав однако иногда вытекает из ТЗ
Кстати, уважаемый Водолей.
А если бы вы закрыли договор, сдали акты, подписали протоколы и т.д.
А потом заказчик предложил вам новый договор, с новым бюджетом и новым ТЗ.
Причем ТЗ это было явно на "развитие комплекса" (написание нового функционала)
В договоре прописал бы новые этапы сдачи по доработке.
Для вас это был бы новый проект? А для него нужен план управления ПРОЕКТОМ (именно этим проектом, а не проектами компании)?
Наверно, стоит тогда делать отдельные планы, которые стандартны для всех проектов и отдельные планы (план управления содержанием проекта; план управления расписанием; план управления стоимостью)
А план управления проектов делать как композция "индивидуальных" планов + "общих" планов
6
Управление Проектом / Re: План управления проектом
« : 20 Июня 2011, 20:31:01 »
Предположим, я захочу закрепить новые способы коммуникации (фиксирование требований в системе управления).
Меня не этот вопрос волнует.
Буду конкретнее. Есть проект, который формально завершен (ПМИ сдано, акты подписаны).Потенциально есть договор на доработку.
Плана по управлению НЕТ.
Интересно, если его писать "с нуля":
* включать ли в него этапы, которые уж прошли. Читала, что есть такой раздел, как "Основные этапы проекта". Или писать в него прошедшие этапы уже бессмысленно? Пишутся только этапы по новому договору?
* иногда план управления проектом включает в себя разделы "Общая информация" (где указывают менеджера) или Матрицу ответственности. В новом договоре появлюются новые роли, новое перераспределение обязанностей. Поэтому я и написала про изменение структуры команды.
Вопрос проще:
Заключение договора = новый проект = новый план по управлению проектом
ИЛИ договор по развитию продукта НЕ РАВНО новый проект = модификация существующего плана
Просто я путаюсь - закрытие работ по договору есть ли закрытие проекта?
Если по логике, то план управлени ПРОЕКТОМ создается для проекта, а проект и продукт есть разные вещи.
То есть, новый договор = новый проект = новый план
Да, он на 80% может быть копией предыдущего, но опять же...включает новый план по управлению содержанием работ, новый план по управлению рисками, новый план по управлению изменениями.
А вот некоторые части могут и не меняться (План управления качеством и т.д.) и браться "шаблонно" из других планов.
Просто план управления проектом, как я понимаю, состоит из вспомогательных планов.
Но создается он при старте очередного договора, который определяет ресурсы и задачи.
Просто для меня проект всегда ограничивался сроками, ресурсами и, соответственно, план для него тоже.
Где я ошибаюсь?
p/s/
Вопросы могу не понимать, потому что не менеджер проектов и имею весьма упрощенные знания в данной области.
Ограничены пролистыванием PMBOK
Меня не этот вопрос волнует.
Буду конкретнее. Есть проект, который формально завершен (ПМИ сдано, акты подписаны).Потенциально есть договор на доработку.
Плана по управлению НЕТ.
Интересно, если его писать "с нуля":
* включать ли в него этапы, которые уж прошли. Читала, что есть такой раздел, как "Основные этапы проекта". Или писать в него прошедшие этапы уже бессмысленно? Пишутся только этапы по новому договору?
* иногда план управления проектом включает в себя разделы "Общая информация" (где указывают менеджера) или Матрицу ответственности. В новом договоре появлюются новые роли, новое перераспределение обязанностей. Поэтому я и написала про изменение структуры команды.
Вопрос проще:
Заключение договора = новый проект = новый план по управлению проектом
ИЛИ договор по развитию продукта НЕ РАВНО новый проект = модификация существующего плана
Просто я путаюсь - закрытие работ по договору есть ли закрытие проекта?
Если по логике, то план управлени ПРОЕКТОМ создается для проекта, а проект и продукт есть разные вещи.
То есть, новый договор = новый проект = новый план
Да, он на 80% может быть копией предыдущего, но опять же...включает новый план по управлению содержанием работ, новый план по управлению рисками, новый план по управлению изменениями.
А вот некоторые части могут и не меняться (План управления качеством и т.д.) и браться "шаблонно" из других планов.
Просто план управления проектом, как я понимаю, состоит из вспомогательных планов.
Но создается он при старте очередного договора, который определяет ресурсы и задачи.
Просто для меня проект всегда ограничивался сроками, ресурсами и, соответственно, план для него тоже.
Где я ошибаюсь?
p/s/
Вопросы могу не понимать, потому что не менеджер проектов и имею весьма упрощенные знания в данной области.
Ограничены пролистыванием PMBOK
7
Управление Проектом / Re: План управления проектом
« : 19 Июня 2011, 23:10:00 »
Изменились: состав команды, менеджер проекта. Бюджет и сроки по доработке соответствуют новому договору
8
Управление Проектом / Re: План управления проектом
« : 19 Июня 2011, 20:51:46 »
Имею в виду план управления проектом
План-график насколько я помню только его часть (помимо плана управления рисками, коммуникациями, персоналом и т.д.)
С план-графиком вопросов в принципе нет. Есть общий на проект + по итерациям (вехам)
План-график насколько я помню только его часть (помимо плана управления рисками, коммуникациями, персоналом и т.д.)
С план-графиком вопросов в принципе нет. Есть общий на проект + по итерациям (вехам)
9
Управление Проектом / План управления проектом
« : 19 Июня 2011, 18:23:14 »
Здравствуйте, форумчане!
Интересует ответ на следующий вопрос:
Кто-нибудь писал план управления проектом?
Если проет завершен, но стартует проект по доработке системы, то пишется новый план по управлению или создается новая редакция существующего плана?
С одной стороны, если есть доработка проекта, то речь идет о неком продолжении проекта.
С другой стороны, проект - "ограниченное во времени целенаправленное изменение отдельной системы с установленными требованиями к качеству результатов, возможными рамками расхода средств и ресурсов и специфической организацией."
Получается, если новый договор (читай - новый менеджер проекта, новая команда, новое ТЗ), то и план управления другой, даже если речь идет всего лишь о развитии системы?
Вопрос прагматичный: раньше плана по управлению проекта не было, возникло желание написать.
Понятно, что от ответа зависит описывать ли моменты предыдущего проекта или освящать только аспекты по новому договору.
Интересует ответ на следующий вопрос:
Кто-нибудь писал план управления проектом?
Если проет завершен, но стартует проект по доработке системы, то пишется новый план по управлению или создается новая редакция существующего плана?
С одной стороны, если есть доработка проекта, то речь идет о неком продолжении проекта.
С другой стороны, проект - "ограниченное во времени целенаправленное изменение отдельной системы с установленными требованиями к качеству результатов, возможными рамками расхода средств и ресурсов и специфической организацией."
Получается, если новый договор (читай - новый менеджер проекта, новая команда, новое ТЗ), то и план управления другой, даже если речь идет всего лишь о развитии системы?
Вопрос прагматичный: раньше плана по управлению проекта не было, возникло желание написать.
Понятно, что от ответа зависит описывать ли моменты предыдущего проекта или освящать только аспекты по новому договору.
10
Примеры / Re: Система - актор?
« : 25 Мая 2011, 20:59:06 »
Да...отвратительный пример
Понятно, что созданный документ можно:
* Отредактировать и сохранить
* Закрыть, не сохраняя
* Сохранить пустым
Пошла учить мат.часть (читать книгу по UML)
Понятно, что созданный документ можно:
* Отредактировать и сохранить
* Закрыть, не сохраняя
* Сохранить пустым
Пошла учить мат.часть (читать книгу по UML)
12
Примеры / Система - актор?
« : 22 Мая 2011, 20:56:26 »
Помогите разобраться со следующим вопросом.
Есть система, которая позволяет пользователю
- сформировать документ
- сохранить документ
- посмотреть документ
- подписать документ
- отправить документ на рассмотрение
- принять документ для рассмотрения
Для пользователя прециденты понятны:
- создание документа
- сохранение
- редактирование
- просмотр
- подписание (завизировано)
По логике системы, если для документа предусмотрено внешнее рассмотрение, то после подписания в своем отделе система автоматически осуществляет отправку по внешнему маршруту.
Вопрос: Следует ли ВИ "Отправка документа на рассмотрение" рассматривать как расширение прецидента "Подписание документа" для актора-пользователя или есть свой вариант прецидентов, где актор - система?
Есть система, которая позволяет пользователю
- сформировать документ
- сохранить документ
- посмотреть документ
- подписать документ
- отправить документ на рассмотрение
- принять документ для рассмотрения
Для пользователя прециденты понятны:
- создание документа
- сохранение
- редактирование
- просмотр
- подписание (завизировано)
По логике системы, если для документа предусмотрено внешнее рассмотрение, то после подписания в своем отделе система автоматически осуществляет отправку по внешнему маршруту.
Вопрос: Следует ли ВИ "Отправка документа на рассмотрение" рассматривать как расширение прецидента "Подписание документа" для актора-пользователя или есть свой вариант прецидентов, где актор - система?
13
Системный Анализ и Требования / Re: Примеры в ТЗ
« : 22 Мая 2011, 15:28:41 »
Спасибо за ответы! Use case с сохранением был приведен для демонстации сути моего вопроса.
Он тривиален. Просто не хотелось приводить пример длинного кейса, дабы не путать читающих пост.
Ведь и эскизы экранных форм не принято писать в ТЗ (не тех.проект).
Но насколько я знаю не возбраняется привести их в приложениях с оговоркой, что в процессе проектирования возможны изменения в дизайне.
Ну не просто бывает заказчику без экранных форм и примеров.
Он тривиален. Просто не хотелось приводить пример длинного кейса, дабы не путать читающих пост.
Техническое задания первую очередь является документом соглашения между заказчиком и разработчиком. Коли оно пишется. Весьма странно будет выглядеть контракт, в котором будут приведены примеры. Примеры они и есть примеры, они не могут охватить всех ситуаций.Это понятно. А так ли плохо, что в ТЗ - вариант использования, а в приложениях - примеры отдельных сценариев.
Ведь и эскизы экранных форм не принято писать в ТЗ (не тех.проект).
Но насколько я знаю не возбраняется привести их в приложениях с оговоркой, что в процессе проектирования возможны изменения в дизайне.
Ну не просто бывает заказчику без экранных форм и примеров.
14
Системный Анализ и Требования / Re: Примеры в ТЗ
« : 21 Мая 2011, 23:20:13 »
IDA пишет, что приводить примеры в ТЗ бессмысленно.
Я-то как раз боюсь, что если не писать конкретные примеры, то могут возникнуть недопонимания.
Вопрос именно в том, насколько корректно писать ПРИМЕР (с детализацией вводимых данных):
Вот так писать можно (вымышленный сценарий):
Вариант использования "Сохранение документа"
Сценарий
1. Пользователь пытается сохранить документ
2. Система отображает окно сохранения документа
3. Пользователь вводит наименование документа и подтверждает операцию сохранения
4 Система сохраняет документ
Альтернативный сценарий 1
2. Если документ сохранен ранее, то он сохраняется без вопросов под тем же именем.
Альтернативный сценарий 2
На шаге 3 пользователь ввел некорректное наименование документа
Система сообщает о невозможности сохранения документа
А можно ли привести потом пример:
Пример "Сохранение документа. Ошибка ввода"
1. Пользователь пытается сохранить документ
2. Система отображает окно сохранения документа
3. Пользователь вводит наименование "// ..@@"
4. Система сообщает о невозможности сохранения документа: "Имя документа некорректно. Сохранение невозможно".
Пример выдуман, но суть в том, а корректно ли вообще писать примеры в ТЗ.
Что можно писать варианты использования ясно.
Я-то как раз боюсь, что если не писать конкретные примеры, то могут возникнуть недопонимания.
Вопрос именно в том, насколько корректно писать ПРИМЕР (с детализацией вводимых данных):
Вот так писать можно (вымышленный сценарий):
Вариант использования "Сохранение документа"
Сценарий
1. Пользователь пытается сохранить документ
2. Система отображает окно сохранения документа
3. Пользователь вводит наименование документа и подтверждает операцию сохранения
4 Система сохраняет документ
Альтернативный сценарий 1
2. Если документ сохранен ранее, то он сохраняется без вопросов под тем же именем.
Альтернативный сценарий 2
На шаге 3 пользователь ввел некорректное наименование документа
Система сообщает о невозможности сохранения документа
А можно ли привести потом пример:
Пример "Сохранение документа. Ошибка ввода"
1. Пользователь пытается сохранить документ
2. Система отображает окно сохранения документа
3. Пользователь вводит наименование "// ..@@"
4. Система сообщает о невозможности сохранения документа: "Имя документа некорректно. Сохранение невозможно".
Пример выдуман, но суть в том, а корректно ли вообще писать примеры в ТЗ.
Что можно писать варианты использования ясно.
15
Системный Анализ и Требования / Re: Примеры в ТЗ
« : 16 Мая 2011, 19:42:55 »
Противоречивые советы)
Но все равно спасибо
Но все равно спасибо