Дмитpий Hecтepук

Блог о программировании — C#, F#, C++, архитектура, и многое другое

Про написание проектных планов

7 комментариев

Этот пост про формирование проектных планов. Думаю будет полезно тем, кто получает какие-то RFP и не-микроскопические заказы и не знает как их по-хорошему обрабатывать. Про .Net тут не будет (если только случайно), и про формальные методики оценки тоже.

RFP – что это и как реагировать?

RFP = Request for Proposal. Иначе говоря, вместо того чтобы написать коммерческое предложение, предлагают это сделать вам. Бесплатно. Да-да, я не шучу, потенциальные заказчики думают что время ПМов которые делают проектные планы стоит ровно $0 в час, и ориентируются именно на эту цифру.

Чтобы “обработать” RFP, нужно сначала понять, чего хочет заказчик. Если это понятно очень хорошо, рождается проектный план с фиксированным концом, расписанными рейтами и одной, конечной ценой. Называется это fix-price, то есть цена фиксирована, и если де-факто проект увеличится в 2 раза, никого это не волнует. Другой вариант — это когда из описания вообще ничего не понятно. Elaboration, то есть общение с клиентом, стоит денег, которые непонятно кто должен оплачивать, и все может “утечь в трубу” и в результате не выгореть. Поэтому тут либо называется приблизительная сумма (чтобы было от чего плясать), либо предлагается time & materials (он же Т+М или “почасовая оплата”). В этом случае, заказчик покупает время разработчиков для своих целей. Хорошее сравнение – fix price это как купить сервер, time & materials это как хостинг в облаке.

Ну да что-то я отошел от главной идеи. Так вот, есть у вас RFP – что с ним делать? Во-первых, нужно определить, является ли заказчик неблагонадежным? Главный критерий – насколько сильно вам задерживали деньги? В принципе, для большинства контор, задержать на 2-3 месяца это самое милое дело, вины за собой точно никто не почувствует. Но если больше, то возможно не стоит больше брать контракты, особенно если риск велик. Хотя риск не только в деньгах но еще в таких вещах как банальное недопонимание. А также культура заказчика – ведь если заказчик не привык толком делать ИТ-заказов, у него могут быть какие-то невменяемые, почерпнутые невесть откуда понятия типа “ИТ это рабы” и соответствующий подход. И “попасть” в этом случае очень легко.

Но если вы все-таки решили ответить на RFP и представляете, что нужно писать, то значит что вы составляете проектный план.

Проектный план

Проектный план – это вещь до боли предсказуемая. Во-первых, в плане фигурирует общая инфа о вашей фирме – чем занимаетесь, сколько народу, какие проекты делали и почему они релевантны. Тут можно натыкать картинок и прочей маркетологической фуфни, но заказчик скорее всего 90% проигнорирует, найдя для себя лишь одно предложение с каким-нть полезным для него показателем.

После общефилософской части, идет обзорная часть проекта, то есть описание того как вы – исполнитель – понимаете его. Дальше, практически в строчку, пишутся основные фичи проекта (например “авторизация, поддержка paypal”), дабы заказчик понимал на какие этапы идут средства. Именно тут – а не позже – пишется общая цена как различных этапов так и всего проекта. Да-да, заказчик хочет Gantt-график тоже, но его можно воткнуть потом – его тоже отчасти проигнорируют, т.к. заказчика волнуют время и деньги, а не насколько детально вы все расписали. Детальный план – это обоснование, а также возможность потом спрашивать с исполнителя относительно сроков.

После проектого плана и стоимости, пишутся возможности поддержки (саппорта) проекта. Схемы у всех разные, но нужно писать понятно, чтобы заказчик знал сколько будет стоить поддержать тот или иной проект. Сюда бывает полезно воткнуть также ценники относительно поездок, если они нужны – сколько стоит виза, accomodation и коммандировочные.

Общие советы

Во-первых, на RFP лучше отвечать в течении одного дня. Если в PFP все жутко нечетко и приходится тратить несколько дней на elaboration – это плохой знак. Возможно вы все настолько сильно разжуете все заказчику что он уйдет переосмыслять проект и все – бизнеса нет.

В пропозле лучше писать как можно больше, и в ключевых (к пр. юридических) местах – писать только правду :) Например, если при подписании SLA вдруг выяснится что вы офшор, а заказчик об этом только узнал – будет невесело.

И еще – настоятельно рекоммендую в случае подписания брать деньги за создание проектного плана. По ПМным рейтам. А то бесплатно работать как-то не хочется…

Реклама

Written by Dmitri

12 мая 2010 в 15:10

Опубликовано в Technology

комментариев 7

Subscribe to comments with RSS.

  1. Дмитрий, отличный пост! Спасибо. Думаю очень пригодится начинающим ПМам. В книгах такого не найти.

    Arthur Smirnov

    13 мая 2010 at 12:07

  2. А разве не бывает такого, что цена зависит от рисков. Ну типа: если всё пройдёт успешно и без задержек, то проект будет сделан за месяц и будет стоить 5000$, и вероятность этой ситуации 80%. Однако есть вероятность в 20%, что проект затянется на 1,5 месяца и цена вырастет до 8000$ (например, при использовании новой технологии). Более подробная оценка станет известна через неделю работы.
    Так не бывает?

    • Тут все зависит от risk appetite той или иной фирмы. Большой аутсорсер может идти на больший риск, а может вообще делать проект в ноль или в минус если получит reference. Маленькому же риски не нужны, хотя конечно на 100% от них не избавиться.

      Dmitri

      14 мая 2010 at 11:22

  3. Вообщето, насколько я знаю, сейчас подписывают договора с фиксированной ценой на разработку ядра систем. А на весь рабочий функционал подписываются договора или поэтапно или доп-договора составляются. Зачастую заказчик просто не видит возможностей системы. И это понимание приходит с осознанием этих возможностей. Ну конечно если это не очередной инетмагазин.

    Александр

    14 мая 2010 at 0:41

  4. Я — не PM, а простой программер. Поэтому и предположения мои чисто теоретические.
    А вопрос навеян прочтением книги «Вальсируя с медведями», посвящённой управлению рисками в IT. Авторы призывают по возможности разделять риски с заказчиком.

    • Алексей, дело в том что у нас в Российском аутсорсинге мало кто занимается формальным расчетом рисков. Даже те компании которые метят на CMMI 3 представляют себе риск как нечто абстрактное, “для галочки”. В типичных же случаях принимается быстрое решение да/нет в зависимости от субъективного ощущения того или иного ПМа. В качестве критерия используется обычно CRM (если уже работали с этим клиентом) а также впечатление от RFP плюс собственно от клиента, если удалось с ним пообщаться.

      Dmitri

      14 мая 2010 at 14:57

  5. Кликнул по банеру услуги и попал на http://activemesa.com/. Где меня встретил «жёлтый экран». Наверное надо или исправить или убрать ссылку на услуги.

    Runtime Error

    Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.

    Details: To enable the details of this specific error message to be viewable on remote machines, please create a tag within a «web.config» configuration file located in the root directory of the current web application. This tag should then have its «mode» attribute set to «Off».

    Денис

    19 мая 2010 at 12:30


Оставить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: