вот, пытаюсь что-то найти по сабжу в форумах, и всюду натыкаюсь — "об этом в книгах не пишут..., большинство составляют плохие планы..." и т.д. и т.п.
Понятно, что все приобретается с опытом, но эффективность обучения и приобретения опыта — также важна.
С чего тогда начать, может есть какие-то отправные точки, принципы, литература и т.д.?
Можно, конечно, перечитать все посты Гапертона сотоварищи, и попытаться выкристаллизовать оттуда знания. Но этот способ подходит, имхо, более опытным товарищам в этом деле, уже имеющим более общую картину.
Буду признателен за любые подсказки, хотелось бы также услышать мнение вышеупомянутых товарищей
а давай для начала определимся: что означает "хороший" план проекта? По каким критериям (и с каким весом/приоритетом этих критериев) оценивается его "хорошесть"?
Здравствуйте, Vlad_SP, Вы писали:
V_S>а давай для начала определимся: что означает "хороший" план проекта? По каким критериям (и с каким весом/приоритетом этих критериев) оценивается его "хорошесть"?
также задавался этим вопросом, но намеренно не стал выкладывать свою точку зрения, т.к. это определение веорятно является частично и ответом на вопрос.
коль уж употребляют словосочетание "хороший план", значит, под этим подразумевают что-либо конкретное — вот это также хотелось бы услышать
Здравствуйте, dmoz, Вы писали:
D>Добрый день всем,
D>вот, пытаюсь что-то найти по сабжу в форумах, и всюду натыкаюсь — "об этом в книгах не пишут..., большинство составляют плохие планы..." и т.д. и т.п. D>Понятно, что все приобретается с опытом, но эффективность обучения и приобретения опыта — также важна. D>С чего тогда начать, может есть какие-то отправные точки, принципы, литература и т.д.?
D>Можно, конечно, перечитать все посты Гапертона сотоварищи, и попытаться выкристаллизовать оттуда знания. Но этот способ подходит, имхо, более опытным товарищам в этом деле, уже имеющим более общую картину.
D>Буду признателен за любые подсказки, хотелось бы также услышать мнение вышеупомянутых товарищей
Слушай, зачем _все_ посты читать, а? Читать надо не посты Гапертона, а его блог . И не все — а вполне достаточно трех штук.
Gaperton's comprehensive guide for mastering project plans:
А вообще — я сейчас работаю (вернее, уже несколько дней собираюсь взяться) над статьей по планированию, которая долна исчерпывающим образом закрыть тему хороших планов, и над программой семинара. Сейчас уже вроде материала накопилось для этого достаточно. Главное — чтобы терпения и силы духа хватило.
G>Слушай, зачем _все_ посты читать, а? Читать надо не посты Гапертона, а его блог . И не все — а вполне достаточно трех штук.
G>Gaperton's comprehensive guide for mastering project plans:
G>Как составлять планы, или "декларативное планирование" G>http://gaperton.livejournal.com/16087.html
G>Оценка трудозатрат при разработке ПО G>http://gaperton.livejournal.com/20165.html
G>Эффективный MS Project. The missing tutorial. G>http://gaperton.livejournal.com/19205.html
G>А вообще — я сейчас работаю (вернее, уже несколько дней собираюсь взяться) над статьей по планированию, которая долна исчерпывающим образом закрыть тему хороших планов, и над программой семинара. Сейчас уже вроде материала накопилось для этого достаточно. Главное — чтобы терпения и силы духа хватило.
О, большое спасибо,
удачи Вам и силы духа! будем ждать
Здравствуйте, dmoz, Вы писали:
D>Добрый день всем,
D>вот, пытаюсь что-то найти по сабжу в форумах, и всюду натыкаюсь — "об этом в книгах не пишут..., большинство составляют плохие планы..." и т.д. и т.п. D>Понятно, что все приобретается с опытом, но эффективность обучения и приобретения опыта — также важна. D>С чего тогда начать, может есть какие-то отправные точки, принципы, литература и т.д.?
А литературы по составлению хороших планов я не встречал. Даже принципы нормально нигде не излагаются, чтоб сразу и в одном месте. А они есть, и достаточно простые.
1) План должен учитывать риски, приводя к выполнению приоритетов при как можно более быстром снижении "кривой риска". Собственно — план, это ваш ответ на риски и приоритеты в условиях ограниченных ресурсов. Старые методологии, такие как PERT, исходят из другой посылки. PERT разработан для оборонных проектов, где ресурсы можно считать неограниченными, и весь фокус — успеть за счет параллелизма плана раньше, чем СССР, причем — любой ценой. Отсюда все и акценты в общем-то неплохой и разумной методологии PERT, так странно ложащиеся на реалии современной коммерческой разработки.
2) Составление плана тесно связанно с конструированием процесса работ, по сути план — это прогноз работы некоторого процесса. И составление хорошего плана требует глубокого понимания этого "технологического процесса", но составление отличного плана — требует навыков кастомизации процесса. О чем речь: процесс разработки инженерного изделия надо понимать как процесс внесения и устранения ошибок. Менеджмент — суть контроль качества. Суть технологического процесса в нашем случае — это ваши предположения касательно ошибок, которые мы вносим, и запланированные способы их отлова.
3) Другими словами, правильный подход при составлении плана — от тестирования, которое надо понимать не в узком смысле, но широко. Именно процедуры верификации разного рода структурируют план, задают вам задачи и позволяют надежно контролировать их закрытие. Каждая задача в плане должна включать в себя активности по тестированию. Как вы проверяете, что задача закрыта? Экспертным заключением разработчика? Если у вас есть задачи по "дизайну", то их закрытие должно сопровождаться процедурой контроля качества, как любая другая — надо провести перекрестное review с целью поиска ошибок. Планы, которые не составлены по этому принципу, имеют обыкновение бодро доходить до 90% готовности, и затягиваться на неопределенный срок. Почему так?
А что, вы думаете, происходит с ошибками в тех задачах, для закрытия которых не прописана внятная процедура контроля? Ничего особенного, вы просто откладываете их исправление на поздний этап. Вплоть до интеграции. А там эти ошибки существенно дороже как в обнаружении, так и в диагностике, и в исправлении.
4) То есть, каждая задача в плане должна быть единицей тестирования, даже если речь не идет о программном коде. То есть, задача формулирует не активность, она скорее сформулирована декларативно, в терминах критерия ее завершения. Это приводит нас к функциональному подходу в составлении планов, который еще дальше все упрощает. Что вы доставляете в результате, и что будут тестировать тестеры на системном тесте? Какая функциональность видна пользователю, ценна, и ее можно протестировать? Фичи. То есть, по сути, фичлист является во многом исходником для составления плана.
5) Однако есть еще один момент, который играет при групповой разработке, и является надежными признаком подразбиения на задачи. Это межчеловеческое взаимодействие. Точки этого взаимодействия, когда передается эстафетная палочка, надо резать задачами и снабжать надежными процедурами контроля качества. Многие планы можно декомпозировать по этому признаку — это еще один источник ограничения.
6) Итак, фичлист у нас есть. Теперь, примем во внимание дизайн и архитектуру системы, выполним быстрое предварительное проектирование с единственной целью — определить, какие фичи мы можем проверять независимо. У фичей, внимание, есть приоритет и ценность для пользователя. А у их реализации — риск. Таким образом, теперь вы в состоянии определить порядок работ. Видите? Для составления хорошего плана необходимо предварительное проектирование, иначе вы не получите достаточного количества информации. Теперь, когда она у вас есть, вы принимая все эти факторы и ограничения во внимание, выбираете оптимальный порядок реализации фич. Если для реализации фич требуются общие работы, вы группируете их. Если для реализации многих фич требуются инфраструктурные работы, вы вводите "системные фичи", и заводите для них задачи, которые тестируете отдельно. Или же, разумным будет "приклеить" эти работы к одной из простых фич, пустить это вперед, и отладить их вместе.
7) Здесь я говорил о задачах-фичах. Однако, не забываейте о межчеловеческом взаимодействии и процессных элементах. Процессные элементы тесно связаны с человеческим взаимодействием. Скажем, если много людей должны договориться относительно некоторой вещи, которая общая для них, и от которой зависят их дальнейшие работы, необходимо выделить задачу на дизайн. И в качестве контроля качества поставить инспекцию краткого материала, фиксирующего договоренность.
8) В качестве общего процессного подхода рекомендуется взять RUP-оский цикл решения проблем, когда вы подходите к ней в три этапа. перечисляю критерии их завершения
— Пришли к общему пониманию, что мы хотим сделать.
— Пришли к пониманию, как это надо делать.
— Сделали первую версию, доступную для тестирования
— Закончили.
Обратите внимание на этот цикл. Тестирование — итеративный процесс. Однако в планах итерации закладывать нежелательно. Обратите внимание, как отражена итеративность тестирования в цикле RUP — она взята в "скобки" — начало-конец. Так и вам следует обходится с любой циклической активностью.
Второй момент. Обратите внимание, как я формулирую критерии выхода. Не наличие документов, не наличия кода, ни дизайнов с архитектурами я не проверяю. С одной стороны, такой взгляд на вещи позволит вам сконцентрироваться на сути, с другой, делает данный шаблон процесса совершенно универсальным.
Вот, примерно все про разработку плана. Вопросов оценки трудозатрат я не касаюсь, они, в принципе, конспективно изложены в презентации из соседнего поста.
Еще, достаточно часто задают вопросы про то, как анализировать риски. Обыкновенно, речь идет о рисках на уровне группы. Здесь важно понять один момент, который все упрощает и формирует единый правильный подход при работе над планом. Я говорил, что план строится от ошибок и процедур их отлова, так? А также он должен учитывать "риски", и снижать их кривую? Так вот, ошибки и риски — явления одной природы. Собственно, ошибка это один из того набора рисков, с которыми вы имеете дело. Это по сути своей одно и тоже. Обнаруженная ошибка — это материализованный, сыгравший риск, с высокой вероятностью, но относительно низкой стоимостью. Наличие ошибок — это риск потенциальный.
Ваш план нужен затем, чтобы "закрыться" от неопределенности, которая составляет собой основу и природу рисков. Не будь этой неопределенности, вам не нужны были бы процедуры контроля, и было бы достаточно учитывать только приоритет, value работ в условиях ограниченных ресурсов.
Итак, угол зрения, под которым я предлагаю вам взглянуть на ваш план — это ваш ответ списку рисков. Отсюда следует и одна из процедур проверки плана — он дожен адекватно адресовать все известные риски. С этой точки зрения ваш процесс разработки, ваши процедуры контроля качества, и ваш подход — все служит и подчинено одному простому принципу. Обеспечение результата в условиях наличия неопределенности.
Во-первых план проекта это не только ИСР ( иерархическая структура работ ) о которой вы рассказываете в своем разделе о планировании.
ИСР это только 10% от всех планов которые проекту положено иметь, если мы говорим о качественном планировании.
Во-вторых методика создания ИСР подробно описана в PMBoK ( там десяток страниц этому посвящено — приводить все здесь не буду, кому интересно не поленитесь почитайте ), не нужно придумывать велосипед. Декомпозиция осуществляется по любым удобным критериям ( фазы проекта, артефакты проекта и т.д. ) не нужно замыкаться только на артифактах. Возможно подойдет для какого-то частного случая.
Декомпозиция делается как правило до уровня одного ответственного, зачастую более детально планировать не рационально.
В-третьих пожелал бы поменьше воды писать, сбивает с толку и вызывает небольшое отторжение ( время жалко наверное ). Если оставить смысл текст можно уменьшить раза в 2-3. Это мое мнение, возможно кому-то наоборот нравится.
G>Оценка трудозатрат при разработке ПО G>http://gaperton.livejournal.com/20165.html
Здесь вообще не понятно что вы хотели рассказать. Презентацию желательно все-таки представить в тексте, слайдшоу без комментариев не понятно.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Gaperton, Вы писали:
Еще раз спасибо, Вы в нескольких постах дали много пищи для изучения и осмысления.
Жаль, что нельзя отблагодарить как-то кроме скромного плюса, радует то, что не только мне это будет полезно
G>>Как составлять планы, или "декларативное планирование" G>>http://gaperton.livejournal.com/16087.html
P>Можно покритиковать ?
Нужно.
P>Во-первых план проекта это не только ИСР ( иерархическая структура работ ) о которой вы рассказываете в своем разделе о планировании. P>ИСР это только 10% от всех планов которые проекту положено иметь, если мы говорим о качественном планировании.
Во-первых, я рассказываю не про иерархическую структуру работ (это WBS, так?). Она не иерархическая, и не работ. Но конечно, в итоге вы сможете получить хороший WBS, с чем у многих проблемы.
Во-вторых, я не ставил себе цели дать исчерпывающее описание всего процесса ведения проекта. За этим, как мы, знаем, можно обратиться к PMBoK .
В третьих, именно структура работ, является не тем артефактом, который иметь положено, но тем — который иметь необходимо, даже если мы ведем внутреннюю разработку. Это один из важнейших элементов.
P>Во-вторых методика создания ИСР подробно описана в PMBoK ( там десяток страниц этому посвящено — приводить все здесь не буду, кому интересно не поленитесь почитайте ), не нужно придумывать велосипед. Декомпозиция осуществляется по любым удобным критериям ( фазы проекта, артефакты проекта и т.д. ) не нужно замыкаться только на артифактах. Возможно подойдет для какого-то частного случая.
Эту часть PMBoK я читал, спасибо. Нет там никакой внятной методики создания плана, только общие рассуждения, что его можно десятком способов строить. Нельзя пользуясь этим руководством составить нормального плана.
А вот вы мой пост не читали, а если читали, то ничего не поняли, потому что там идет речь совсем не о том, что декомпозиция строится на артефактах. Она строится на декларативно сформулированных ЦЕЛЯХ (надо разницу объяснить подробно?), которые могут быть сформулированы как угодно, в том числе и на внешние события, и никакая она не иерархическая — граф произвольный, там не делается разницы между отношениями предок-последователь и задача-подзадача (последнего отношения в природе в чистом виде вообще не существует, оно только в голове авторов концепции WBS существует).
Этот подход, который излагаю я, имеет больше общего с Management By Objective, и с "событиями" из теории сетевого планированием, чем с секцией PMBoK про WBS, если вам интересны параллели с классикой.
P>Декомпозиция делается как правило до уровня одного ответственного, зачастую более детально планировать не рационально.
P>В-третьих пожелал бы поменьше воды писать, сбивает с толку и вызывает небольшое отторжение ( время жалко наверное ). Если оставить смысл текст можно уменьшить раза в 2-3. Это мое мнение, возможно кому-то наоборот нравится.
Если оставить тот смысл, который поняли вы — наверное.
G>>Оценка трудозатрат при разработке ПО G>>http://gaperton.livejournal.com/20165.html P>Здесь вообще не понятно что вы хотели рассказать. Презентацию желательно все-таки представить в тексте, слайдшоу без комментариев не понятно.
Здесь я рассказываю про две простые техники.
1) Оценка интервала завершения работ, объясняю чем она хороша, и что за ней стоит (а за ней стоит теория вероятности). Затем показываю, как корректно оценить размеры буферов для всего проекта используя среднеквадратичное отклонение, и как для этого надо модифицировать формулы PERT.
2) Как можно не особо напрягаясь применить софтверные метрики для проверки точности прогнозов. Какие бывают метрики, что за ними стоит, какие наблюдаются закономерности, и как ими можно пользоваться.
Здравствуйте, dmoz, Вы писали:
D>Буду признателен за любые подсказки, хотелось бы также услышать мнение вышеупомянутых товарищей
Для опредления качества планирования необходимо ввести метрики, например следующие :
— % отклонении ( стоимость/срок/содержание) от базового плана
— количество и объем модификаций базового плана
— количество задач по которым реальные трудозатраты были > или < 40% от планируемых
— количество сработавших рисков которые не были учтены в плане управления рисками
Для составления качественного плана проекта есть процесс подробно описанный в PMBoK.
Приведу только несколько основных тезисов которые на мой взгяд важны :
— для тех кто считает что план это только диаграмма ганта — план проекта помимо каледнарного графика работ как правило включает в себя следующие планы : управления рисками, управления качеством, управления коммуникациями, поставками и т.д. см PMBoK
— декомпозиция работ осуществляется до уровня одного ответственного
— детализация работ осуществляется всей командой проекта на этапе планирования
— оценка трудозатрат проводится экспертным методом либо на основании метрик предыдущего типового проекта.
— в план закладывается резерв 20% в случае типового проекта, 40% и более в случае инновационного проекта. Делается для того чтобы в случае неправильной оценке трудозатрат работ конечный срок не изменился, не требовалась постоянная перестановка и оптимизация работ.
— план оптимизируется в соотвествии с матрицей которая определяется на этапе инициации проекта ( фиксируем/оптимизируем/принимаем — стоимость/содержание/срок )
Здравствуйте, dmoz, Вы писали:
D>Еще раз спасибо, Вы в нескольких постах дали много пищи для изучения и осмысления. D>Жаль, что нельзя отблагодарить как-то кроме скромного плюса, радует то, что не только мне это будет полезно
Отчего ж нельзя . Можно .
...один из клиентов знаменитого дореволюционного адвоката Федора Никифоровича Плевако, будучи очень ему признателен за то, что Плевако выручил его из какой-то беды, сказал: "Не знаю даже, как вас отблагодарить". На что адвокат ответил: "Не беспокойтесь. С тех пор как изобретены деньги, проблема выражения благодарности перестала быть чересчур затруднительной".
Шучу я, не надо меня благодарить . Общение на РСДН — а именно, ответы на вопросы, позволяет мне сконцентрироваться, напрячь мозг, учится, и лучше понять собственные мысли, поскольку умение хорошо объяснить требует высшего уровня понимания темы, большего, чем применить. Примерно, как находишь в задачнике интересную задачку, и решаешь ее. Иногда выходит хорошо, иногда — не очень. Так что это я должен говорить вам спасибо.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, pashzhel, Вы писали:
Отвечу частично на ваши вопросы цитатами из вашей же статьи.
G>Во-первых, я рассказываю не про иерархическую структуру работ (это WBS, так?). Она не иерархическая, и не работ. Но конечно, в итоге вы сможете получить хороший WBS, с чем у многих проблемы.
...Открыл MS Project, потому как слышал, что именно в нем, родимом, составляются планы. Открыл, попытался составить план, в попытках его составить получил мозговую травму, выяснив, что "пальцы не печатают", а мозг сопротивляется совершению над собой насилия, и закрыл MS Project обратно...
Глядя на приглашение к составлению иерархического плана, которое являет собой MS Project и прочие тулы, мозг с непривычки погружается в пустоту. Казалось бы — просто. Берем задачу, бьем ее на подзадачи.
Уже из контекста понятно во вступлении что вы хотите рассказать как делать иерархический план работ. Хотя я бы рекомендовал пользоваться общепринятой терминологией и быть более аккуратным в терминах.
G>Во-вторых, я не ставил себе цели дать исчерпывающее описание всего процесса ведения проекта. За этим, как мы, знаем, можно обратиться к PMBoK .
Как составлять планы, или "декларативное планирование"
Вообще чтобы не сбивать с толку лучше в самом начале сказать об этом что речь идет не о том как делать такой важный пакет документов как план проекта, а только о методике получения задач для плана проекта.
G>В третьих, именно структура работ, является не тем артефактом, который иметь положено, но тем — который иметь необходимо, даже если мы ведем внутреннюю разработку. Это один из важнейших элементов.
Вообще если речь идет о качественном планировании, то положено иметь не только ИСР. И я вроде бы нигде не отрицал необходимости ИСР.
P>>Во-вторых методика создания ИСР подробно описана в PMBoK
G>Эту часть PMBoK я читал, спасибо. Нет там никакой внятной методики создания плана, только общие рассуждения, что его можно десятком способов строить. Нельзя пользуясь этим руководством составить нормального плана.
Не согласен. Там описан способ более детально чем в вашем примере. Да там нет таких узкоспециализированных слов "инсталлятор", "программный компонент". Но принцип построения путем декомпозиции там описан не хуже чем в вашем случае. И любой человек может подменить общие понятия частными.
К тому же дан более общий взгляд на проблему.
G>А вот вы мой пост не читали, а если читали, то ничего не поняли, потому что там идет речь совсем не о том, что декомпозиция строится на артефактах. Она строится на декларативно сформулированных ЦЕЛЯХ (надо разницу объяснить подробно?), которые могут быть сформулированы как угодно
Это важно. Мы будем планировать в терминах целей, и артефактов.
Как составить план? Внимание, господа, магия. Включаем воображение.
Ставим артефакты в столбик слева — сверху вниз. Рисуем цели справа от них — слева направо, по зависимостям. Теперь я скажу не совсем точную фразу — но в ней суть. Пересечение целей и артефактов дадут вам задачи.
Во-первых написали бы уж тогда не как составить план, а как получить задачи которые будут участвовать в плане.
Во-вторых, вообще не нужно этих выдумок, как правило "сложностью" является выбор — что выбрать в качестве первого уровня декомпозиции. Что это будет, фазы проекта ( проектирование/разработка/тестирование/внедрение ) или лучше взять что-то другое , в PMBoK об этом написано более чем подробно, с картинками.
Из PMBoK
В итоге может создаваться несколько разных видов структуры:
• Использование основных результатов поставки и подпроектов в качестве
первого уровня декомпозиции, как показано на рис. 5-6.
• Использование подпроектов, как показано на рис. 5-6, где подпроекты
могут разрабатываться сторонними организациями. Например, в
некоторых областях приложения может быть определена и разработана
ИСР проекта, состоящая из нескольких частей (например, сводная ИСР
проекта с несколькими подпроектами в рамках ИСР, на которые могут
быть заключены контракты со сторонними организациями). В таких
случаях продавец разрабатывает вспомогательную иерархическую
структуру работ по контракту в рамках работ, включенных в условия
контракта.
• Использование фаз жизненного цикла проекта в качестве первого уровня
декомпозиции, а результатов поставки проекта – в качестве второго
уровня, как показано на рис. 5-7.
• Использование разных подходов в каждом ответвлении ИСР, как показано
на рис. 5-8, где тестирование и оценка являются фазой, самолет –
продуктом, а обучение – сопутствующей услугой.
G>Здесь я рассказываю про две простые техники.
Ну вот сам рассказ желательно изложить ( в блоге ).
Здравствуйте, pashzhel, Вы писали:
P>Здравствуйте, dmoz, Вы писали:
D>>Буду признателен за любые подсказки, хотелось бы также услышать мнение вышеупомянутых товарищей
P>Для опредления качества планирования необходимо ввести метрики, например следующие : P>- % отклонении ( стоимость/срок/содержание) от базового плана P>- количество и объем модификаций базового плана P>- количество задач по которым реальные трудозатраты были > или < 40% от планируемых P>- количество сработавших рисков которые не были учтены в плане управления рисками
Метрики звучат внушительно. Ты забыл сказать, как их применять после того, как они собраны, то есть зачем их надо собирать. Ну, допустим, у нас получилось 20 задач, по которым реальные трудозатраты больше 40% от планируемых. Что дальше делать будем?
P>Для составления качественного плана проекта есть процесс подробно описанный в PMBoK. P>Приведу только несколько основных тезисов которые на мой взгяд важны : P>- для тех кто считает что план это только диаграмма ганта — план проекта помимо каледнарного графика работ как правило включает в себя следующие планы : управления рисками, управления качеством, управления коммуникациями, поставками и т.д. см PMBoK
Сам факт наличия данных артефактов никак не повышает качества основного плана, который выпоняется в виде schedule, и определяет порядок работ. Кроме того, как учит нас практика agile, как минимум 60% софтверных проектов вполне переживут без всего перечисленного, им это только на пользу пойдет, а не во вред. Писать всю эту хренотень для проекта, скажем, внутренней автоматизации банка, или разработки продукта в небольшой динамичной компании будет только сумасшедший. А вот каледарный план, составленный с учетом рисков — не повредит.
P>- декомпозиция работ осуществляется до уровня одного ответственного P>- детализация работ осуществляется всей командой проекта на этапе планирования
Негусто для инструкции.
P>- оценка трудозатрат проводится экспертным методом либо на основании метрик предыдущего типового проекта.
А я думал, что хотя бы COCOMO II упомянете, или функциональные точки. Что, не пишут про это в PMBoK? Впрочем, для какого-нибудь строительства вполне подойдут и метрики типового проекта.
P>- в план закладывается резерв 20% в случае типового проекта, 40% и более в случае инновационного проекта. Делается для того чтобы в случае неправильной оценке трудозатрат работ конечный срок не изменился, не требовалась постоянная перестановка и оптимизация работ.
О как лихо в PMBoK орлы буфера на учет проектных рисков закладывают. Раз — и плюс двадцать процентов. Очень точный учет риск-плана, ничего не скажешь . См PERT и CPM.
P>- план оптимизируется в соотвествии с матрицей которая определяется на этапе инициации проекта ( фиксируем/оптимизируем/принимаем — стоимость/содержание/срок )
Это, судя по всему, толковая штука, и тоже силно поможет. Без матрицы план никак не отоптимизировать.
P>Для тех кому лень искать PMBoK или читать на английском есть русский перевод : http://pmbok.narod.ru/pmbok2004_rus.zip
А вот за это спасибо.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, pashzhel, Вы писали:
P>>Здравствуйте, dmoz, Вы писали:
D>>>Буду признателен за любые подсказки, хотелось бы также услышать мнение вышеупомянутых товарищей
P>>Для опредления качества планирования необходимо ввести метрики, например следующие :
G>Метрики звучат внушительно. Ты забыл сказать, как их применять после того, как они собраны, то есть зачем их надо собирать. Ну, допустим, у нас получилось 20 задач, по которым реальные трудозатраты больше 40% от планируемых. Что дальше делать будем?
Будем проводить анализ под различными "углами" чтобы понять причину. Например может оказаться просто что задача оценивалась одним специалистом, соотвественно на будущее будем знать что он завышает или занижает оценку. Это как самый простой случай.
Основной смысл это ответить на вопрос автора, что значит хороший план, а именно то что качество какого-либо продукта ( плана в данном случае ) можно определять метриками и соответственно оптимизировать его на основе их анализа.
P>>Для составления качественного плана проекта есть процесс подробно описанный в PMBoK. P>>Приведу только несколько основных тезисов которые на мой взгяд важны : P>>- для тех кто считает что план это только диаграмма ганта — план проекта помимо каледнарного графика работ как правило включает в себя следующие планы : управления рисками, управления качеством, управления коммуникациями, поставками и т.д. см PMBoK
G>Сам факт наличия данных артефактов никак не повышает качества основного плана, который выпоняется в виде schedule, и определяет порядок работ. Кроме того, как учит нас практика agile, как минимум 60% софтверных проектов вполне переживут без всего перечисленного, им это только на пользу пойдет, а не во вред. Писать всю эту хренотень для проекта, скажем, внутренней автоматизации банка, или разработки продукта в небольшой динамичной компании будет только сумасшедший. А вот каледарный план, составленный с учетом рисков — не повредит.
Чем больше вещей учтено на этапе планирования тем он качественнее. Все 8 планов придуманы не просто так, они как раз охватывают те "вещи" которые нужно бы учитывать. В простых проектах ими можно пренебречь.
P>>- декомпозиция работ осуществляется до уровня одного ответственного P>>- детализация работ осуществляется всей командой проекта на этапе планирования G>Негусто для инструкции.
Это не инструкция, это тезисы. Более детально в PMBoK ).
P>>- оценка трудозатрат проводится экспертным методом либо на основании метрик предыдущего типового проекта. G>А я думал, что хотя бы COCOMO II упомянете, или функциональные точки. Что, не пишут про это в PMBoK? Впрочем, для какого-нибудь строительства вполне подойдут и метрики типового проекта.
Для IT тоже подойдут если проект типовой. Например если нам известно что разработка инсталлятора во всех подобных проектах занимала от 4 до 8 часов то что нам мешает в плане указать 8 ч.
P>>- в план закладывается резерв 20% в случае типового проекта, 40% и более в случае инновационного проекта. Делается для того чтобы в случае неправильной оценке трудозатрат работ конечный срок не изменился, не требовалась постоянная перестановка и оптимизация работ.
G>О как лихо в PMBoK орлы буфера на учет проектных рисков закладывают. Раз — и плюс двадцать процентов. Очень точный учет риск-плана, ничего не скажешь . См PERT и CPM.
Ну если жизнь так складывается что если едешь туда где ни разу небыл нужно денег с запасом в 3 раза больше брать. А если в очередной раз на работу идешь и знаешь что на дорогу и обед тебе 200 рублей нужно, то берешь вровень и спокоен.
То же и для проекта. Это не орлы в PMBoK плохие, а жизнь такая.
PERT тут не причем, точнее эта прибавка уже делается к результатам полученых по PERT и другим методикам. Просто из жизни получилась такая эмпирическая цифра 20% и 40+%.
P>>- план оптимизируется в соотвествии с матрицей которая определяется на этапе инициации проекта ( фиксируем/оптимизируем/принимаем — стоимость/содержание/срок ) G>Это, судя по всему, толковая штука, и тоже силно поможет. Без матрицы план никак не отоптимизировать.
Без матрицы оптимизации просто не понятно по какому параметру можно оптимизировать ( стоимость/срок/содержание). Всегда его нужно указать и согласовать еще до начала проекта.
Интересно, все эти настройки, как я понимаю, исключительно локальные. Т.е. если проект открыть на другом компе с дефолтными настройками, то тот же Auto Leveling будет показывать чушь? Фактически проект нельзя будет никому послать. Или все ок и я не прав?
Здравствуйте, pashzhel, Вы писали:
P>Отвечу частично на ваши вопросы цитатами из вашей же статьи.
Хм.. Все не читал и в подробности не вдавался, но художественная резьба по цитатам у тебя как-то совсем плохо получается.
P>
P>Глядя на приглашение к составлению иерархического плана, которое являет собой MS Project и прочие тулы, мозг с непривычки погружается в пустоту. Казалось бы — просто. Берем задачу, бьем ее на подзадачи.
P>Уже из контекста понятно во вступлении что вы хотите рассказать как делать иерархический план работ.
Ключевое слово здесь "являет собой MS Project и прочие тулы", таким образом, из контекста понятно, что "иерархический план" предлагают MS Project и прочие тулы, из чего совсем не следует желание Гапертона рассказывать именно про это.
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, Gaperton, Вы писали:
G>>Эффективный MS Project. The missing tutorial. G>>http://gaperton.livejournal.com/19205.html
O>Интересно, все эти настройки, как я понимаю, исключительно локальные. Т.е. если проект открыть на другом компе с дефолтными настройками, то тот же Auto Leveling будет показывать чушь? Фактически проект нельзя будет никому послать. Или все ок и я не прав?
Хм. Интересно, я об этом не подумал, и не проверял. Если план не менять, а только смотреть, то все должно быть по идее ок, так как автоматический leveling срабатывает тока на изменения. Второй вопрос — сохраняются ли эти настройки в проекте. Я не знаю. Но это просто выяснить.
). Если оставить смысл текст можно уменьшить раза в 2-3. Это мое мнение, возможно кому-то наоборот нравится. 
Мы уже победили, просто это еще не так заметно...
