PMsoop: Главы 0 – 2: От Идеи до Предложения

Глава №0: Сначала была Идея!

В ролях – потенциальный Заказчик

Артефакты – нет

Суть – потенциальный Заказчик рождает Идею проекта

Идея  - первична. На этом можно было бы и закончить, но…

А все начинается с того, что в некоторый неизвестный (нам) момент времени кому-то в голову приходит некоторая идея: “А что, если …”. Дальнейшие варианты различны:

- Сделать фирме сайт-визитку и увеличить продажи в Х раз

- Оптимизировать надоевшую выписку справок посредством…

- Новый поисковик сделать лучше Гугла!

- Внедрить хитрую систем документооборота и поувольнять лишних сотрудников

- Сделать сайт для любимой собачки

- Завести себе вычурный (или не очень) блог

- Открыть порносайт и зарабатывать на рекламе

- …

Сколько есть людей – столько есть идей, в общем-то.

Суть любой идеи в том, что её воплощение подразумевает получение некоторой выгоды, ясной автору. Это очень важный момент, который окажет огромное влияние на всю судьбу будущего проекта. Впрочем, не будем забегать вперед.

Глава №1: А вот потом было слово

В ролях – потенциальный Заказчик (возможно в нескольких лицах), который постепенно превращается в Заказчика

Артефакты – первичное описание задачи проекта

Суть – автор идеи (возможно с соавторами) формирует первичное описание задачи проекта

После того, как на свет появилась (пока только в голове у автора) новая идея, произойти может разное. 90% (на правах ИМХО) идей вскорости будут забыты, но нас они не интересуют (хотя сколько там наверное замечтельных, блестящих идей которые могли бы сделать мир лучше… или угробить его окончательно).

В случае, если идея автором не забыта – идея начинает обретать форму в словах и образах. В некоторых случаях автор обсуждает идею с коллегами/партнерами/друзьями/женой/итп. В некоторых случаях автор исследует альтернативы и конкурентные продукты. В некоторых случаях мечтает и придумывает все в одиночестве. По результату этого, безусловно, творческого процесса еще 90% (ИМХО снова) оставшихся идей так и не получают шанса на воплощение. Но займемся все-таки теми идеями, перспективность которых прошла эту тяжелую проверку.

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

Далее, в результате разнообразных процессов, которые мы не будем тут затрагивать, автор идеи (сам либо с соавторами/коллегами/инвесторами) определяет бюджет, который он (они) готовы потратить на воплощение идеи в жизнь. В процессе обсуждения идеи, особенно с инвесторами, в некоторых случаях первичное описание идеи обрастает различными подробностями, как функциональными так и техническими, сроками, условиями платежей и т.п. Тем не менее, мы его называть будем все также – первичное описание задачи проекта (ПОЗП) – ибо это и есть первая информация о проекте которая попадёт в руки к Разработчику.

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

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

Глава №2: Поиск партнёра

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

Артефакты – первичное описание задачи проекта, первичные предложения от разработчиков

Суть – Заказчик представляет ПОЗП потенциальным разработчикам, которые анализируют и оценивают задачу, и формируют предложение по разработке. Заказчик выбирает конкретного разработчика для выполнения задачи

Итак, у Заказчика есть ПОЗП и некоторый бюджет. Следующий  шаг – найти разработчика который выполнит поставленную задачу в указанных условиях. Шаг этот очень важный, и очень не простой. Впрочем, обо всем по порядку.

Существуют множество разных способов, которыми Заказчики и Разработчики находят друг друга. Не все они они просты и очевидны, некоторые вообще с трудом объяснимы современной наукой. Вот только некоторые наиболее типичные из них:

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

- Заказчик обращается к разработчикам, которые ему посоветовали друзья/партнеры/конкуренты/доброжелатели/итп

- Заказчик объявляет тендер на разработку ПО

- Заказчик размещает информацию о проекте на сайтах-аукционах проектов типа elance.com, guru.com, freelancer и т.п.

- Заказчик использует Гугл (или другой источник информации) и рассылает предложение о сотрудничестве тем разработчикам которые ему понравились

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

Потенциальный разработчик получает от Заказчика первичное описание задачи проекта и представление о его бюджете.  В исключительно редких случаях происходит следующее – разработчик сообщает Заказчику свою готовность реализовать поставленную задачу в описанных условиях  и обозначает готовность начать работы через ХХ времени. Вероятность такого события равна вероятности того, что Заказчик напишет идеальное ТЗ и предложит к нему реальный бюджет и сроки, либо вероятности найти очень голодного/неоптыного разработчика.

В 99% (имхо) остальных случаев задача проекта нуждается в разъяснениях и уточнениях, а бюджет (вместе со сроками) нуждается в длительном и акуратном согласовании с выясненной задачей. Некоторые мысли о том, почему так случается:

- ПОЗП является очевидным и понятным с первого прочтения только для его автора, который “варится” в этой “теме” уже некоторое время.  Посторонний человек, которым на данном этапе является представитель разработчика, ответственный за установление контактов с новыми Заказчиками, не воспринимает Идею проекта так же как её автор.

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

-  Заказчик и Разработчик “говорят на разных языках”. Я  не имею ввиду вариант например англоязычного заказчика и русского разработчика (про это будет дальше), речь идет о профессиональной специфике. Часто проекты бывают связаны с профессиональной деятельностью заказчика, и редко бывает чтобы разработчик хорошо знал область проекта.

- Разные культуры мышления и общениянакладывают отпечаток на восприятие одних и тех же слов в тексте. Лингвисты меня поймут..

- Разные языки общения = трудности перевода.

Теперь рассмотрим что и как обычно происходит на стороне Разработчика после получения первичной информации от Заказчика:

- Представитель разработчика, ответственный за установление контактов с новыми Заказчиками (далее – sales-manager, сейлз), изучает присланную документацию

- В случае, если задача проекта неочевидна – задаёт Заказчику уточняющие вопросы. Это продолжается до тех пор, пока сейлз не сформирует своё понимание задачи проекта, которое как кажется (сразу уточню – сейлзу и заказчику) соответствует понимаю заказчика

- Далее сейлз отправляет уточнённое ПОЗП со своими комментариями на оценку ответственным лицам компании-разработчика (в некоторых случаях селз может оценить затраты на разработку проекта сам – все зависит от структуры компании и т.п.)

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

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

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

- Готовое предложение отправляется Заказчику

В некоторых случаях история на этом не заканчивается, например:

- Заказчик присылает вопросы – а почему так дорого выходит? а нельзя сделать не на ПХП на на Java, он слышал что так будет лучше?

- Сейлз консультируется с оценщиками и отвечает

- Заказчик предлагает – а давайте будем делать не все что я сначала хотел, а вот тот кусок делать пока не будем?

- Сейлз консультируется с оценщиками, корректирует оценку и отвечает

- Заказчик спрашивает – ….. ну и так далее

По результату Заказчик получает некоторое количество предложений по разработке, из которых ему теперь предстоит выбрать того самого, единственного Разработчика, который воплотит его Идею в суровую материальную (информационную) форму. Эту сложную и иногда печальную (по статистике около 70% проектов не выходят дальше обсуждения предложений) фазу жизни будущего проекта описывать не буду.

Важным моментом на этапе “выбора партнёра” является понимание обеими сторонами что как ПОЗП, так и пердложение по разработке не являются точными документами, им предстоит множество изменений, уточнений и других таинственных превращений, которые приведут и к изменениям бюджета, и к изменениям сроков, до того как проект выйдет в жизнь. Не стоит думать, что выбрав разработчика и согласившись заплатить сумму, указанную в предложении по разработке, Заказчик “уже почти купил” свою идею в материальной форме. Разработка ПО – это не товарное производство а скорее опытно-контструкторское, поэтому обе стороны должны быть готовы к конструктивному сотрудничеству и принятию изменений, про которые будет рассказано в следующих главах.

Для дальнейшего рассмотрения примем, что Заказчик таки выбрал себе Разработчика и они вместе, веселые и полные оптимизма, готовятся к старту нового проекта.