пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ. пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ. пїЅпїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ. пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ!

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

� рулить проектом соответственно не буду. А вот проблемку решить, надо.
Видимо, надо создавать нормальный проектный офис. вести базу проектов, статистику по проектам и т.п.

Но как спланировать проект сегодня?

Если в Вашей проектной команде нет людей, имеющих опыт разработки программных продуктов (в данной предметной области, с данными инструментами), то никакой проектный офис Вас не спасет. Попытки определять сроки работ исходя из количества строк кода, которого необходимо написать или что-то в этом роде - на мой взгляд, полная ерунда.
Состав и сроки раобт будут зависеть от многих факторов: степени определенности требований к системе, модели разработки, преполагаемой архитекутры системы, используемого инструментария, опыта программистов работы в команде, необходимости дальнейшего сопровождения/развития программы и пр. � если эти факторы не учитывать при планировании, то Ваш план поплывет на вторую неделю работы.

Устанавливать сроки проекта на основании интуиции - вредно!

Разработка любого ПО должна начинаться с изучения потребностей заказчика (предпроектного обследования), составления ТЗ и т.п. В конечном итоге все работы по проекту должны быть выражены в человеко-часах. � уже после анализа доступности человеческих ресурсов и сопоставления результатов этого анализа с трудоемкостью проекта можно выйти на срок окончания проекта... Не иначе...

Быть может...Мы не пишем софт под заказ. Это коробочный продукт, хотя сильно ситуация сей факт не меняет. Просто софт - высокоинтеллектуальный САПР и работы достаточно уникальны. Как измерить трудоемкость?

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

Максим, может мы Вас не так понимаем? У меня складывается ощущение, что Вы просто не знаете с чего начать планирование. �ли Вы желаете найти ответ на какой-то конкретный вопрос?

Подписываюсь!

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

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

Даже отсутствие накопленной статистики может быть компенсировано умением программеров оценивать свои силы - главное, чтобы работы в проекте были разбиты на кванты.

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

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

А вообще, лично я для себя решил, что есть некоторый предел в первоначальной проработке плана, за который выходить не стоит. Можно потратить кучу времени и сил, но ситуация все равно развернется по-иному. Лучше эти силы потратить на анализ рисков и механизмов компенсации этих рисков, чтобы иметь возможность своевременно вернуть процесс в управляемое русло.

Некоторые РМ по разработке софта говорят о том, что пданирование такого проекта должно занимать около 30 % времени от всего проекта. А некоторые рекомендуют вооще планирование рассматривать как отдельный проект

Какова технология разбиения работ на кванты. Где об этом прочесть?

спасибо

Мы каждый раз идем одни и тем же путем: любой проект разбивается на такие работы, которые далее уже неделимы. Это один из вариантов. �ногда мы останавливаемся на работах, требующих для выполнения 8 человеко-часов (т.е. один человеко-день).

В общем, информацию по этому вопросу можно задав в поимковике словосочетание "декомпозиция работ".

Категория Декомпозиции работ мне известна.

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

это очевидно, но не так уж сложно оценить и саму сумму, если известны слагаемые.

Спасибо