Как мне ремонтировать автомобили, ...
если я в них не разбираюсь.Если большая часть работ в проекте абсолютно новые, то риск срыва такого проекта весьма велик. Как я понимаю, предложения вроде "не браться за рисковый проект" или "обратиться к профессионалам" здесь не рассматриваются. Принципиальных вариантов два: 1. Понимая рискованность затеи заложиться хороший резерв по времени, бюджету и пр. 2. Выделить подготовительный этап на детальную проработку плана. Пощупать все новые области, чтобы оценки хотя бы немного соответствовали действительности. Нужно постараться крупные задачи разбить на составляющие - так проще оценить трудозатраты. Но все это из области общих советов. В программировании то я точно не разбираюсь
И рулить проектом соответственно не буду. А вот проблемку решить, надо. Видимо, надо создавать нормальный проектный офис. вести базу проектов, статистику по проектам и т.п. Но как спланировать проект сегодня? Причем здесь проектный офис?
Если в Вашей проектной команде нет людей, имеющих опыт разработки программных продуктов (в данной предметной области, с данными инструментами), то никакой проектный офис Вас не спасет. Попытки определять сроки работ исходя из количества строк кода, которого необходимо написать или что-то в этом роде - на мой взгляд, полная ерунда.Состав и сроки раобт будут зависеть от многих факторов: степени определенности требований к системе, модели разработки, преполагаемой архитекутры системы, используемого инструментария, опыта программистов работы в команде, необходимости дальнейшего сопровождения/развития программы и пр. И если эти факторы не учитывать при планировании, то Ваш план поплывет на вторую неделю работы. Планирование в проектах по выпуску программного продукта -
Устанавливать сроки проекта на основании интуиции - вредно! Разработка любого ПО должна начинаться с изучения потребностей заказчика (предпроектного обследования), составления ТЗ и т.п. В конечном итоге все работы по проекту должны быть выражены в человеко-часах. И уже после анализа доступности человеческих ресурсов и сопоставления результатов этого анализа с трудоемкостью проекта можно выйти на срок окончания проекта... Не иначе... Вредно?
Быть может...Мы не пишем софт под заказ. Это коробочный продукт, хотя сильно ситуация сей факт не меняет. Просто софт - высокоинтеллектуальный САПР и работы достаточно уникальны. Как измерить трудоемкость?
Разработку любого высокоинтеллектуального продукта ...
можно разбить на простые и понятные работы, объем и продолжительность которых при определенных навыках и с достаточной точностью всегда можно определить.У нас, например, тоже высокоинтеллектуальных софт (мы разрабатываем программы автоматизации банковской деятельности), но я не могу сказать, что здесь требуются какие-то уникальные методики. Максим, может мы Вас не так понимаем? У меня складывается ощущение, что Вы просто не знаете с чего начать планирование. Или Вы желаете найти ответ на какой-то конкретный вопрос? Разработку любого высокоинтеллектуального продукта ...
Подписываюсь!Аналогичная ситуация и в нашей компании - софт не пишется под заказ, но это не значит, что нет заказчика (заказчик может быть и внутри компании (например, отдел маркетинга)). Все зависит от уровня зрелости организации
Согласен с тем, что МНОГОЕ зависит от уровня зрелости организации, но не все. В самом начале нашего пути (собственный пример ближе) мы все равно пытались разбивать работы по проектам на неделимые кванты - это давало поразительные результаты - проект из 2-х месячного превращался в 6-ти месячный. Это очень помогает. Даже отсутствие накопленной статистики может быть компенсировано умением программеров оценивать свои силы - главное, чтобы работы в проекте были разбиты на кванты. Никто Вам не даст рецептов как сделать оценку ...
исполнителя более реальной. Лучше программиста (если конечно он достаточно квалифицирован и опытен) оценить трудоемкость может только другой программист, более опытный, чем первый. Вы же можете лишь подумать о том, как компенсировать в случае чего негативное развитие плана.Мысли вслух: 1. Составить несколько вариантов плана: пессимистичный, оптимистичный, вероятный; 2. Дать программеру время на "потыркаться" сейчас, чтобы он смог сформировать свое мнение о трудоемкости задачи как можно раньше. 3. Дать оценить трудоемкость той же задачи другому, не менее опытному, программеру (он может акцентировать внимание на неочевидных проблемах). 4. Подумать о вариантах мотивации программера, чтобы его оценки были более продуманы, а работа соответствовала ранее высказанным оценкам. 5. Подумать о методах компенсации негативного развития плана (временной резерв, сверхурочная работа, дополнительные ресурсы, отказ от второстепенных работ и пр.). Конечно все это можно делать только по ограниченному перечню работ, иначе надорветесь. А вообще, лично я для себя решил, что есть некоторый предел в первоначальной проработке плана, за который выходить не стоит. Можно потратить кучу времени и сил, но ситуация все равно развернется по-иному. Лучше эти силы потратить на анализ рисков и механизмов компенсации этих рисков, чтобы иметь возможность своевременно вернуть процесс в управляемое русло. Может Вы и правы
Некоторые РМ по разработке софта говорят о том, что пданирование такого проекта должно занимать около 30 % времени от всего проекта. А некоторые рекомендуют вооще планирование рассматривать как отдельный проект
Кванты?
Какова технология разбиения работ на кванты. Где об этом прочесть?спасибо Вряд ли есть единая технология...
Мы каждый раз идем одни и тем же путем: любой проект разбивается на такие работы, которые далее уже неделимы. Это один из вариантов. Иногда мы останавливаемся на работах, требующих для выполнения 8 человеко-часов (т.е. один человеко-день). В общем, информацию по этому вопросу можно задав в поимковике словосочетание "декомпозиция работ". Это меняет суть
Категория Декомпозиции работ мне известна.
Это меняет суть
Если Вы знакомы с декомпозицией работ, то наверняка Вам известно, что оценить трудоемкость одной работы легче, чем оценить трудоемкость группы работ, неразделенных между собой...
Несомненно
это очевидно, но не так уж сложно оценить и саму сумму, если известны слагаемые.
|