Регистрация   E-Mail     Пароль   
Портал «Профессионал управления проектами»

123

Алексей
12 февраля 2004 г., 13:18
Как мне ремонтировать автомобили, ...
если я в них не разбираюсь.
Если большая часть работ в проекте абсолютно новые, то риск срыва такого проекта весьма велик. Как я понимаю, предложения вроде "не браться за рисковый проект" или "обратиться к профессионалам" здесь не рассматриваются.
Принципиальных вариантов два:
1. Понимая рискованность затеи заложиться хороший резерв по времени, бюджету и пр.
2. Выделить подготовительный этап на детальную проработку плана. Пощупать все новые области, чтобы оценки хотя бы немного соответствовали действительности. Нужно постараться крупные задачи разбить на составляющие - так проще оценить трудозатраты.
Но все это из области общих советов.
Максим, менеджер по качеству
12 февраля 2004 г., 14:06
В программировании то я точно не разбираюсь
И рулить проектом соответственно не буду. А вот проблемку решить, надо.
Видимо, надо создавать нормальный проектный офис. вести базу проектов, статистику по проектам и т.п.

Но как спланировать проект сегодня?
Алексей
12 февраля 2004 г., 15:25
Причем здесь проектный офис?
Если в Вашей проектной команде нет людей, имеющих опыт разработки программных продуктов (в данной предметной области, с данными инструментами), то никакой проектный офис Вас не спасет. Попытки определять сроки работ исходя из количества строк кода, которого необходимо написать или что-то в этом роде - на мой взгляд, полная ерунда.
Состав и сроки раобт будут зависеть от многих факторов: степени определенности требований к системе, модели разработки, преполагаемой архитекутры системы, используемого инструментария, опыта программистов работы в команде, необходимости дальнейшего сопровождения/развития программы и пр. И если эти факторы не учитывать при планировании, то Ваш план поплывет на вторую неделю работы.
Kirill, System Technologies, Зам. финансового директора
16 февраля 2004 г., 11:04
Планирование в проектах по выпуску программного продукта -
Устанавливать сроки проекта на основании интуиции - вредно!

Разработка любого ПО должна начинаться с изучения потребностей заказчика (предпроектного обследования), составления ТЗ и т.п. В конечном итоге все работы по проекту должны быть выражены в человеко-часах. И уже после анализа доступности человеческих ресурсов и сопоставления результатов этого анализа с трудоемкостью проекта можно выйти на срок окончания проекта... Не иначе...
Максим, менеджер по качеству
16 февраля 2004 г., 14:52
Вредно?
Быть может...Мы не пишем софт под заказ. Это коробочный продукт, хотя сильно ситуация сей факт не меняет. Просто софт - высокоинтеллектуальный САПР и работы достаточно уникальны. Как измерить трудоемкость?
Алексей
16 февраля 2004 г., 15:25
Разработку любого высокоинтеллектуального продукта ...
можно разбить на простые и понятные работы, объем и продолжительность которых при определенных навыках и с достаточной точностью всегда можно определить.
У нас, например, тоже высокоинтеллектуальных софт (мы разрабатываем программы автоматизации банковской деятельности), но я не могу сказать, что здесь требуются какие-то уникальные методики.

Максим, может мы Вас не так понимаем? У меня складывается ощущение, что Вы просто не знаете с чего начать планирование. Или Вы желаете найти ответ на какой-то конкретный вопрос?
Kirill, System Technologies, Зам. финансового директора
16 февраля 2004 г., 15:58
Разработку любого высокоинтеллектуального продукта ...
Подписываюсь!

Аналогичная ситуация и в нашей компании - софт не пишется под заказ, но это не значит, что нет заказчика (заказчик может быть и внутри компании (например, отдел маркетинга)).

Kirill, System Technologies, Зам. финансового директора
16 февраля 2004 г., 16:01
Все зависит от уровня зрелости организации
Согласен с тем, что МНОГОЕ зависит от уровня зрелости организации, но не все. В самом начале нашего пути (собственный пример ближе) мы все равно пытались разбивать работы по проектам на неделимые кванты - это давало поразительные результаты - проект из 2-х месячного превращался в 6-ти месячный. Это очень помогает.

Даже отсутствие накопленной статистики может быть компенсировано умением программеров оценивать свои силы - главное, чтобы работы в проекте были разбиты на кванты.
Алексей
16 февраля 2004 г., 19:25
Никто Вам не даст рецептов как сделать оценку ...
исполнителя более реальной. Лучше программиста (если конечно он достаточно квалифицирован и опытен) оценить трудоемкость может только другой программист, более опытный, чем первый. Вы же можете лишь подумать о том, как компенсировать в случае чего негативное развитие плана.
Мысли вслух:
1. Составить несколько вариантов плана: пессимистичный, оптимистичный, вероятный;
2. Дать программеру время на "потыркаться" сейчас, чтобы он смог сформировать свое мнение о трудоемкости задачи как можно раньше.
3. Дать оценить трудоемкость той же задачи другому, не менее опытному, программеру (он может акцентировать внимание на неочевидных проблемах).
4. Подумать о вариантах мотивации программера, чтобы его оценки были более продуманы, а работа соответствовала ранее высказанным оценкам.
5. Подумать о методах компенсации негативного развития плана (временной резерв, сверхурочная работа, дополнительные ресурсы, отказ от второстепенных работ и пр.).

Конечно все это можно делать только по ограниченному перечню работ, иначе надорветесь.

А вообще, лично я для себя решил, что есть некоторый предел в первоначальной проработке плана, за который выходить не стоит. Можно потратить кучу времени и сил, но ситуация все равно развернется по-иному. Лучше эти силы потратить на анализ рисков и механизмов компенсации этих рисков, чтобы иметь возможность своевременно вернуть процесс в управляемое русло.
Максим, менеджер по качеству
17 февраля 2004 г., 10:08
Может Вы и правы
Некоторые РМ по разработке софта говорят о том, что пданирование такого проекта должно занимать около 30 % времени от всего проекта. А некоторые рекомендуют вооще планирование рассматривать как отдельный проект
Максим, менеджер по качеству
17 февраля 2004 г., 10:18
Кванты?
Какова технология разбиения работ на кванты. Где об этом прочесть?

спасибо
Kirill, System Technologies, Зам. финансового директора
17 февраля 2004 г., 21:33
Вряд ли есть единая технология...
Мы каждый раз идем одни и тем же путем: любой проект разбивается на такие работы, которые далее уже неделимы. Это один из вариантов. Иногда мы останавливаемся на работах, требующих для выполнения 8 человеко-часов (т.е. один человеко-день).

В общем, информацию по этому вопросу можно задав в поимковике словосочетание "декомпозиция работ".
Максим, менеджер по качеству
18 февраля 2004 г., 10:35
Это меняет суть
Категория Декомпозиции работ мне известна.
Kirill, System Technologies, Зам. финансового директора
18 февраля 2004 г., 10:45
Это меняет суть
Если Вы знакомы с декомпозицией работ, то наверняка Вам известно, что оценить трудоемкость одной работы легче, чем оценить трудоемкость группы работ, неразделенных между собой...
Максим, менеджер по качеству
18 февраля 2004 г., 10:57
Несомненно
это очевидно, но не так уж сложно оценить и саму сумму, если известны слагаемые.
Максим, менеджер по качеству
19 февраля 2004 г., 10:18
Дело известное
Спасибо
Пожалуйста, авторизуйтесь или зарегистрируйтесь для добавления сообщений в этот форум.