Была как-то передачка на ТВ: простые люди должны были рассказывать свои бизнес-идеи инвесторам, а те, заседая в кожаных креслах, выбирать лучшие и вливать в них свои капиталы. Отличный шанс для начинающих бизнесменов, казалось бы.
Однако инвесторы жаловались. Суть жалоб сводилась к следующему: "У них нет видения бизнеса. Ни расчетов, ни плана, ни даже представления о том, как они свою трижды гениальную разработку будут продавать. Они приносят нам не бизнес-идеи, а просто - идеи".
В этом проблема то ли русской ментальности, то ли кровь всех "идейных" слишком горяча, чтобы строить скучные графики и считать цифры. Но такая проблема есть вообще везде и во всем, аналогичная ситуация - и в разработке ПО.
Вообще можно увидеть два рода потребностей в программном продукте: назовем их определяющая и дополняющая.
Определяющая - это если сам продукт - конечный инструмент, который будет приносить прибыль (обычно он сложен в реализации: интернет-магазин виртуальных подарков, веб-сервис, приложение для социальной сети, игра и т.п.). То есть он и будет выполнять главную функцию по зарабатыванию денег.
Дополняющая - если продукт является "продолжением" бизнеса. Например, интернет-магазин как дополнение к реальному магазину или корпоративный сайт с каталогом товаров. Тогда программный продукт - посредник между бизнесом и клиентом.
А теперь к тонкостям.
Группа заказчиков с потребностью в "дополняющем" проекте.
Какие материалы нужно предоставить разработчику, чтобы рабочий процесс пошел гладко:
| Что нужно знать разработчику | Зачем ему это знать |
|---|---|
| Четко сформулированные цели проекта | Это - отправная точка. В зависимости от целей будет меняться и предлагаемое решение. |
| Исчерпывающая информация о деятельности компании: отрасль, выпускаемая продукция, кто конкуренты, в чем преимущества компании, в чем недостатки, каталог продукции. | Чем большей информацией располагает разработчик, тем выше шанс, что структура и дизайн программного продукта уже при первом согласовании будут утверждены - так как они создавались на основе достоверных данных, а не догадок. |
| Каков бюджет проекта. | Бюджет влияет на всё. При большом бюджете у студии есть возможность выделить на разработку больше ресурсов, и, соответственно, реализовать больше возможностей. Заказчику на заметку: эффективное продвижение и реклама тоже стоят денег, на это нужно закладывать суммы, которые обычно превышают стоимость разработки. |
| Кто целевая аудитория. | Конечный продукт должен вызывать у потребителя положительные эмоции - а этого возможно достичь только зная, какова целевая аудитория. |
Если заказчик хочет дополнить свой бизнес интернет-сайтом или начать продавать товары в интернете, то, как правило, у него есть представление о том, каким образом это принесет ему дополнительную прибыль. Деловые люди любят деловой подход, всё-таки.
Однако и здесь вся работа в один прекрасный момент может встать из-за того, что заказчик забыл предоставить номенклатуру продукции, а менеджер этого, в свою очередь, не заметил.
Всё гораздо сложнее со второй группой.
Группа заказчиков с потребностью в "определяющем" проекте.
Очень часто бывает так: в офис влетает человек с горящими глазами и хочет "сделать игру, в которой всё было бы зашибись". Это более, чем настораживает. Заметно, что у человека нет видения целостной картины бизнеса, один сплошной набросок.
Итак, почему одного желания не достаточно:
| Что нужно знать разработчику | Зачем ему это знать |
|---|---|
| Четко сформулированные цели проекта. | Чтобы знать, в каком направлении работать. Разработчиков в данном случае больше интересует вопрос "как это приносит прибыль" (следующий пункт). |
| Каковы способы монетизации проекта. Зависит от типа продукта. Проведите предварительный анализ конкурентов, выясните, как можно заработать на подобных вещах. | Этот пункт добавляет конкретики в первый. Необходимо, опять же, для взаимопонимания. |
| Каков бюджет проекта. Обязательно складывается из бюджета на реализацию + бюджета на продвижение. | Цель разработчика - не просто сдать проект и забыть о нем. Важно, чтобы сделанной работой можно было гордиться. А цель заказчика - не положить новое приложение на дальнюю полку, а активно использовать в целях бизнеса и зарабатывать на нем. |
| Документ с подробным описанием будущего продукта. Или, как вариант, можно работать поэтапно и начать с примерного наброска - составление техзадания и прототипирование, в таком случае, студия берет на себя. | Чтобы не пришлось "на ходу" придумывать функционал. |
| Кто целевая аудитория | Важно по той же причине, что и для "дополняющих". |
В случае с "определяющими" проектами - на лицо сильный крен именно в сторону "идеи", а не реализации. То есть здесь большая ответственность ложится на плечи самого заказчика: разработать концепцию его будущего приложения, функциональную документацию, подробно описать, как продукт будет приносить доход (указать способы монетизации).
Ведь если студия разрабатывает просто "сайт для бизнеса" - то, в случае недоукомплектованности брифа фактами, их можно и домыслить, основываясь на собственном опыте в аналогичных проектах.
Если же задание на разработку сложного продукта (игры, приложения) ограничивается классическим "можно грабить корованы", то о какой реализации можно говорить? Кстати, такие примеры сыплются на нас с завидной частотой, взять хотя бы этот:
"Я хотел бы создать одно приложение "КубикрафТ" Например: посетители думают что это такое, но зайдя в игру они понимают что это игра мечты (такая как лего) в этой игре вы можете: стать квадратным, менять внешность, создавать оружия: дробовик, огнемет, мачете и другие… Ночью идет кровопролитие, а днем строительство! Также там есть: троли, зомби, акулолюди, свиньи, лошади, собаки! В общем мир квадратов!"
Традиционная аналогия на десерт
Идеи как зерна. Их можно хранить на сыром складе в холщовом мешке и в результате получить мешок испорченных зерен. Их можно засеять в неблагодатную почву в неподходящее время - и получить вялые всходы. Или можно сделать всё по правилам и через полгода снять отличный урожай.
И.Репин. Лев Николаевич Толстой на пашне. 1887. ГТГ, Москва
Не ограничивайтесь идеями - давайте им возможность развиваться, вкладывайте в них свое время, тщательно готовьтесь к запуску разработки, прежде чем подписать договор. Не забывайте, что мало вылить завершенный продукт на сервер - нужно привлекать аудиторию, поддерживать ее интерес, заниматься рекламой.
Одним словом - заказчик просто обязан сам непрерывно работать над проектом: до разработки, во время разработки и по ее завершению.