2 liberon:

Книжки читать - дело, конечно, хорошее. Но чтобы хорошо управлять проектами по разработке ПО - нужен боевой опыт. Так что высказанная Calm идея про пообщаться с более опытными в данной области коллегами, ИМХО, весьма правильна.

По сути вопроса:

Перед Вами сейчас, я так понял, стоит задача оценить косты, сроки и риски.

Для начала было бы правильно изготовить Vision (здесь и далее - артефакты RUP). Для проектов, связанных с кастомной разработкой, Vision состоит из четырех значимых разделов:

- Цели создания системы (список попадающих в границы проекта проблем заказчика с указанием для каждой проблемы: кого она затрагивает, в какой степени / каким образом, как автоматизация позволит решить данную проблему)

- Состав и потребности пользователей (список ролей с описанием выполняемых ролью задач, проблемами и метриками)

- Описание функционала системы (список фич, "вырастающий", по сути, из первых двух разделов; я всегда стараюсь описывать фичи таким образом, чтобы в дальнейшем они трансформировались в use cases, однако прямого соответствия нет: часть фич описывает "размазанный" по всей системе функционал: поддержка многовалютности, например, часть use case'ов появится позже - в ходе анализа и разработки)

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

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

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

Далее стоит формально описать риски. Тут можно, ИМХО, редуцировать стандартный Risk List до таблички с двумя колонками - собственно, риски и mitigation strategy по каждому из рисков.

Исходя из костов, рисков и политики компании в отношении требуемого соотношения риск / доходность, можно определить резервную цену, ниже которой нельзя "падать" при торге с клиентом.

Я ж сказал - все артефакты, на которые я ссылаюсь - RUP. В нем, соответственно, и смотреть %-)

Отличие руповского риск-листа от предлагаемых мною двух колонок:

- impact - на что влияет данный риск. В большинстве случаев - самоочевидно. Некоторые заморачиваются связкой рисков и этапов работ с тем, чтобы по каждому риску потом придумать коэффициенты, на которые множить трудоемкость этапов. Такой подход - ИМХО, не жизнеспособен.
- indicators - как определить, что риск "выстрелил". В большинстве случаев - самоочевидно.
- contingency plan - что делать, если риск "выстрелил". Бесполезно, ИМХО.

--- Это, кажется, называется стоимостью риска?

Типа, да. Проблема в том, что во многих случаях его очень сложно оценить количественно. А есть еще синергия нескольких "выстреливших" рисков.

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

--- Де Марко утверждает...

На каждый чих можно найти кучу утверждений из разных книжек. Книжки пишут люди с разными: опытом, образованием, культурным бэкграундом, степенью вменяемости и т.д.

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

Что касается рисков: их можно условно разделить на внутренние и внешние. Для значительной части внутренних рисков утверждение ДеМарко может быть верным. Для внешних рисков - мероприятия по митигейшну в основном бесполезны: тут нужно увеличивать резервную цену (либо иным образом играться с условиями контракта) или отказываться от проекта.

Уважаемый gafudo,

А Вас не затруднит пояснить, каким образом связан опыт управления людьми уважаемого liberon с задачкой по определению костов, сроков и рисков на пресэйле?