Предпроектное исследование и бизнес план
Что бывает без предпроектного обследования?
В свое время мне пришлось заниматься разработкой и продажей систем для составления маршрутов транспорта: на карту выводятся точки с заказами, обводишь их мышью и размещаешь в машины. Обращается к нам одна компания с просьбой продать приложение. Не один месяц мы пытались выяснить, зачем же им подобная система нужна, в результате продали им «коробку», очень уж они просили. Затем решила данная компания привлечь нас для внедрения. И тут выяснилось, что в первую очередь им нужна была функциональность для учета топлива, которая в нашей системе отсутствовала от слова совсем.
А бывает, присоединяешься к проекту в ходе разработки системы, изучаешь документацию по проекту и уже разработанную функциональность. И в какой-то момент приходит осознание: есть интерфейс, программа что-то делает, а вот ответить, зачем она разрабатывается, какие бизнес-задачи решает, какие показатели должны быть достигнуты, никто из проектной команды не способен. Можно ли таким образом создать систему, отвечающую запросам заказчика?
Иными словами, еще до составления Технического задания следует провести обычно небольшое (это как когда) исследование и ответить на ряд вопросов.
Основные вопросы, на которые отвечает обследование
Как говорится, вам надо понять, ЧТО, ГДЕ, КОГДА. А именно:
- С какой целью ведется разработка, какую выгоду извлечет заказчик.
- Какова предлагаемая бизнес-схема, процесс, который будет автоматизирован с помощью создаваемой системы.
- Каковы основные пользовательские функции системы.
Зачем нужно писать, почему недостаточно обсудить и проговорить?
Составление документа позволяет сформулировать мысль на совершенно ином качественном уровне, чем при устном обсуждении. В разговоре неохваченными остаются многие детали, часть информации забывается и позже упускается из виду. А бумага сохраняет все мысли.
Да, составление документов — дело кропотливое и иногда неприятное, но оно того стоит. Мысль ценна только тогда, когда она сформирована, а сформирована она тогда, когда сформулирована на бумаге.
Что должно содержать в себе предпроектное обследование?
Обычно под предпроектным обследованием имеют в виду изучение бизнес-процессов предприятия. Об этом написано много статей и книг. Но к сожалению, простого изложения процессов недостаточно.
Результатом исследования может быть целый пакет документов (часть из них приведена в конце статьи). Центральным (и, к сожалению, часто единственным) документом у меня обычно является документ «Концепция системы». Этот документ мы и обсудим в настоящей статьей.
Разрабатывая собственную структуру Концепции, я взял за основу отчет, подготавливаемый согласно ГОСТ 34 на стадии «Формирование требований к АС» (см. стандарт РД 50-34.698-90 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»). Но при этом внес свои дополнения.
«Концепция системы» может содержать 2, а иногда и 30 страниц. Все зависит от постановки задачи. «Концепция», как правило, согласовывается с высшим руководством заказчика, и только на основании этого можно разрабатывать Техническое задание.
Цель создания (модернизации) системы
Под целью создания я понимаю именно бизнес-цели. «Автоматизировать» — это не цель. Добавить функцию — тоже не цель. И «оптимизировать» — не цель. Например, сидит сотрудник и пару часов в день он может поспать прямо на рабочем месте (реальный случай, кстати). И кто-то просит автоматизировать его деятельность. Зачем? Чтобы он четыре часа спал?
За несколько лет анализа десятков проектов удалось определить только пять возможных целей создания (модернизации) системы:
- Организуется новый бизнес (например, онлайн-система заказов). Понятно, что, если бизнес планируется осуществлять через Интернет, без разработки не обойтись.
- Снижение операционных расходов. Классический случай, когда в результате автоматизации сокращается персонал или удается с помощью более качественного планирования сделать больше с меньшими затратами.
- Повышение качества внутренних процессов. Также классический случай. Например, если при поиске новых клиентов менеджеры постоянно забывают кому-то позвонить, теряют информацию о лиде, то имеет смысл внедрить CRM.
- Снижение рисков при зависимости от ключевых сотрудников (этаких «золотых гвоздей»). Бывает, что из-за низкого уровня автоматизации и запутанности процессов ряд операций могут выполнить 1-2 сотрудника, увольнение (или болезнь) которых может поставить крест на всем бизнесе. А найти и научить новых займет не один месяц.
- Выполнение внешних требований. Например, появился новый закон, или имеется требование контрагента, что у вас должен быть внедрен электронный документооборот или контроль за работой мобильных сотрудников.
Понятно, что цель желательно сделать осязаемой. Если мы хотим снизить расходы, то насколько и за счет чего. Если организуем новый бизнес, то надо понимать хотя бы примерный объем операций и количество операторов. Если повышаем качество процессов, следует очертить круг проблем и предложить решение.
Идея системы
В случае, если документ «Концепция» получается достаточно объемным, имеет смысл вначале кратко изложить самую суть системы, ее идею. Например, вы хотите создать какую-либо специализированную социальную сеть (ходите по музеям и делитесь впечатлениями). Я бы вначале описал потребность в общении между посетителями, а затем кратко — суть: разрабатывается мобильное приложение, в котором пользователь может написать свои впечатления от того или иного экспоната.
Сравнение старого и нового
Самым эффективным способом понять суть создаваемой системы — идти как бы от противного.
Для этого необходимо:
- кратко описать существующие процессы;
- указать на их недостатки;
- предложить новую схему, устраняющую описанные недостатки.
Цель данного раздела — именно обосновать необходимость внедрения новой схемы. Подробное описание бизнес-процессов лучше вынести в отдельный документ. Здесь мы концентрируемся на недостатках и предложениях.
На чем собираемся зарабатывать
Если разрабатывается приложение, с помощью которого планируется зарабатывать деньги, то обязательно нужно определить методы заработка: размещение рекламы, платная подписка, платные услуги, взимаемый процент и т.д. Выбранный способ (или способы) может сильно повлиять на разрабатываемую функциональность.
Заинтересованность сторон
Если для функционирования создаваемой системы необходимо участие других организаций, то обязательно нужно решить, как их привлечь к работе, заинтересовать. Иными словами, сначала выстраиваем всю бизнес-цепочку, потом уже все остальное.
Описание автоматизируемых процессов
Цель данного раздела — дать общее, но полное представление о процессе. Например, вы разрабатываете интернет-магазин. Очевидно, что нужен каталог, корзина, интеграция с банком-эквайером и доставка. Но вот вопросы возврата, отказа при доставке, отказа поставщика, неожиданного отсутствия товара на складе могут ускользнуть от вашего внимания. Лучше продумать все возможные варианты заранее и решить, что из этого будет автоматизироваться, а какие случаи происходят так редко, что лучше их «разгребать» в ручном режиме.
Для описания не обязательно приводить схемы. В общем случае обычный текстовый сценарий намного более полно раскрывает сущность действий.
Юридическое обеспечение
Нередко после создания системы оказывается, что в использующие приложение люди или организации нарушают закон. Поэтому вначале надо найти юридически чистую схему, а затем уже вырабатывать технические решения.
Перечень функций
Документ «Концепция» — это не Техническое задание, поэтому описываются бизнес-функции, верхний уровень. Нет никакого смысла на данном этапе говорить об авторизации и работе с профилем пользователя. Но дать общее представление о функциональности надо обязательно.
Требования к безопасности
Если вы разрабатываете финансовую систему или систему, содержащую строго конфиденциальные данные, то необходимо привести перечень стандартов безопасности. Например, требования к шифрованию хранимых или передаваемых данных. Не забывайте и о все ужесточающихся требованиях к обработке и хранению персональных данных.
Выбор варианта реализации системы
Иногда в зависимости от потребностей необходимо определить вид приложения (веб-приложение, нативное), платформу (Windows, Linux), общую архитектуру (один сервер или несколько кластеров), взять ли типовую систему и доработать или вести разработку с нуля. Для этого необходимо сравнить предлагаемые варианты и выбрать наиболее подходящий.
Другие документы предпроектного исследования
Как мы уже говорили выше, результатом хорошего, серьезного предпроектного исследования, проводимого не одну неделю целой командой, является целый пакет документов. Вот некоторые из них:
- Концепция системы (документ, который мы обсуждали в настоящей статье).
- Маркетинговое исследование.
- Технико-экономическое обоснование.
- План проекта, включая расчет трудоемкости и ресурсный план.
- План маркетинговых мероприятий.
- Смета проекта.
- План возврата инвестиций.
- Предварительное штатное расписание.
- Архитектура системы.
- Концепция безопасности (в случае большого объема описания меры безопасности можно вынести в отдельный документ.
- Презентации для заказчика, потенциальных инвесторов и потенциальных клиентов.
Заключение
В статье мы очень бегло пробежались по основным разделам предпроектного обследования. Почему бегло? Потому что такое обследование — крайне творческое занятие. Главное, чтобы при прочтении концепции сложилось полное понимание, как это должно работать. А в остальном два документа с результатами исследования могут никак не быть похожими друг на друга. Соответственно и перечень разделов в вашем документе может сильно отличаться от приведенного выше.
Читайте другие статьи автора:
- Разработка Технического задания по ГОСТ 34 легко и просто.
- Секреты удачного проектирования ИС (информационной системы) на примере строительства больницы.
- Некоторые заметки по проектированию информационных систем.
Источник
Я часто слышу фразу «Сколько будет стоить такой-то сервис?» — чистую идею, которая ничем не подкреплена. Приходится сообщать стартаперу, что нельзя просто так взять и сделать продукт. Потому что идея без предварительного анализа спроса ничего не стоит. А чтобы проверить, выживет ли она в реальном продукте, нужно потратить время и деньги и сделать предпроектное исследование. Некоторые отказываются, но это ошибка.
Почему это важно? Стартапер часто не обращает внимания на степень нужности продукта другим людям. Ему просто нравится идея и процесс, поэтому он будет бесконечно делать проект. В этом причина огромного числа полудохлых бизнесов на грани выживания.
Перед тем, как бросаться проектировать или разрабатывать сервис, необходимо оценить риски и принимать решение о том, надо ли действовать вообще, и уточнить направление.
Чтобы проверить жизнеспособность идеи, я предлагаю провести кабинетное исследование. В таком исследовании важно понять, есть ли вообще жизнь в этой отрасли — деньги и перспективы. Чтобы узнать это, я анализирую отрасль и определяю:
1. Сколько проектов открывалось в мире в этой отрасли последние 5 лет — растёт тренд или падает.
2. Сколько миллионов долларов в год вкладывается в эти проекты — растёт тренд или падает.
Причем не стоит разделять мировую экономику и российскую, потому что полную статистику можно собрать только из общего анализа отрасли. Рынок программных продуктов сам по себе глобален.
Методика
Методика такого кабинетного исследования сводится к сбору и анализу данных о проектах из указанной заказчиком отрасли на ресурсах типа Crunchbase. После занудного, рутинного, но важного анализа нескольких сотен проектов статус отрасли становится ясен.
Недавно ко мне обратился клиент с идеей разработки сервиса по автоматизации сбора гифок для соцсетей. Берясь за исследование, я был уверен, что приду к тому, что денег в отрасли нет и отговорю делать проект.
Количество компаний и их возраст на момент инвестиций
В ходе исследования выяснилось, что дела обстоят ровно наоборот. Выяснив, что сервисы в аналитике smm набирают популярность, и объем среднего раунда растет, я понял, что отрасль перспективна. Дальше стал смотреть, какие именно сервисы растут в прибыли и увидел то, о чём можно было догадаться и безо всякого исследования: сервисы, которые используют технологии машинного обучения и обработки больших данных. Они интенсивно растут и имеют показатель выручки на сотрудника в год больше ста тысяч долларов.
Тенденция по количеству новых компаний, открывшихся в отрасли в течение последних 5 лет, чётко показывает, что происходит — увеличивается ли спрос на продукты, интересна ли сфера инвесторам. В первую очередь стоит смотреть, сколько денег вкладывается в эти компании и какого они возраста.
Выросло количество компаний в отрасли и сократился срок, в который они привлекают первые инвестиции.
На графике видно, что компании, которым всего 1 год получили в 2018 году 15 раундов инвестиций.
Это значит, что интерес инвесторов к отрасли вырос, и стало легче привлечь средства.
Динамика привлечения инвестиций
В итоге при исследовании количества новых компаний на рынке и привлечённых ими денег, становится понятно — стоит ли идти в конкретную сферу.
Количество компаний растет, а средний объем раунда сохраняется.
Я стал анализировать информацию более детально и увидел, что средний объем привлечённых средств в последнем раунде примерно одинаков, а количество компаний, получивших последний раунд, выросло в два раза с 2014 по 2017 год:
- В 2017-м компании, основанные в 2016-м, получили раунд 15 раз, а основанные в 2017-м году получили раунд 7 раз.
- В 2016-м компании, основанные в 2015-м получили 13 раз, а основанные в 2016-м получили раунд 7 раз.
- В 2015-м компании, основанные в 2014-м получили раунд 13 раз, а основанные в 2015-м получили раунд 2 раза.
- В 2014-м компании, основанные в 2013-м получили 5 раз, а в 2014-м получили раунд 4 раза.
В итоге исследования я пришёл к тому, что если двигаться в сторону сервиса smm-аналитики с технологией машинного обучения, то получить раунд и хорошую прибыль будет легче, потому что эта отрасль понятна и актуальна для инвесторов.
После уточнения идеи продукта стоит не только изучить финансы и перспективу отрасли в мировом масштабе, но и сделать кое-что более приземлённое. В начале я упомянул о том, что идея сама по себе может быть никому не нужна. Для того, чтобы понять, есть ли у людей запрос на продукт, я провожу исследовательское интервью.
Любой проект решает какую-то проблему. Задача интервью — выяснить у реальных людей из потенциальной целевой аудитории продукта, какая у них проблема. Причем важно не просто поговорить о том, что «болит», а о том — что «болит» именно сейчас, в текущий момент времени.
Обычно после 10-го интервью ответы начинают повторяться и можно увидеть конкретное направление развития, способы упрощения идеи и проектирования пилотной версии продукта.
Предприниматели готовы вложить в разработку проекта миллионы рублей, но часто пренебрегают подобными исследованиями, хотя они стоят на порядок дешевле и повышают вероятность успеха проекта.
Приятно воплощать свои идеи, но не всякая идея будет пользоваться успехом у пользователей. Чтобы убедиться, что ваш проект будет интересен и провести предпроектное исследование, напишите нам. За 10 лет мы запустили 40 сложных программных продуктов для частных инвесторов, крупных бизнесов и государственных организаций. Поможем и вам: WB—Tech Consulting.
Источник
Сергей Нужненко darkboatman, ведущий системный аналитик SuperJob, делится опытом запуска IT-проектов с точки зрения аналитика.
По итогам выступления на прошедшем митапе у меня получается серия заметок, в которых я постараюсь, освободившись от ограничения форматом выступления, обсудить с вами принципы выполнения предпроектных задач и покажу несколько примеров из жизни.
Это пригодится представителям заказчика, системным, бизнес-аналитикам, менеджерам проектов, другим участвующим в запуске ИТ-проектов, итераций или спринтов.
Под предпроектом мы понимаем все задачи, которые надо выполнить до момента получения согласия всех сторон, утверждения бюджета, а главное — понимания, что мы делаем и зачем, а также каким способом, то есть кого надо привлечь и кому позже надо будет ставить задачу. Эти задачи одинаковы как для большого проекта, так и для короткой двухнедельной итерации.
Мы знаем, что, во-первых, хорошая постановка задачи — это половина решения, а, во-вторых, не столь важно, насколько продуктивно ты что-то делаешь, если при этом делаешь не то, что нужно. Системной предпроектной работе уделяется удручающе мало внимания. Подавляющее число обсуждений, книг и статей посвящено тому, что делать внутри проекта, или поиску продукта во взаимодействии с рынком. В серой зоне оказывается переход от понимания, что надо продавать, к самой работе.
Задачи предпроекта
Что нужно сделать для того, чтобы построить ИТ-систему или сервис?
Вот список больших задач, которые так или иначе решаются для любой системы:
- Понять наличие проблемы или возможности
- Выявить ожидаемую пользу (эффект) качественно или количественно
- Понять «образ решения» (концепцию или vision) и его стоимость
- Выделить бюджет в деньгах или натуральных ресурсах
- Определить виды ресурсов, объемы работ и начать их заказ
- Определить основание для приемки (как мы узнаем, что работа сделана)
- …
- (Здесь унылый список работ по проектированию, планированию, разработке, развертыванию, внедрению и т.п., который сегодня останется за рамками нашего обсуждения)
- …
- Приемо-сдать результат
- Измерить эффект
- Подтвердить возврат финансовых вложений
Подчеркнутые пункты мы будем называть «предпроект».
Предпроект (хоть он и не всегда так называется) может выполняться в разных условиях: на систему в целом, на подсистемы или на каждую фичу продукта.
Все указанные задачи могут выполняться годы, месяцы или пролетать за неделю в рамках подготовки сессии планирования спринта, могут сопровождаться различным количеством бумаги и разными схемами взаимодействия участников.
Однако перед тем, как мы начнем фиксировать цели, пресловутые 4 параметра проектного треугольника — формулировать обязанности участников проекта, назначать внешние статус-митинги с участием спонсора и расчехлять другие общеупотребимые инструменты проектного управления — необходимо полностью выполнить задачи предпроекта:
1) Понять сроки и стоимость
2) Допродать систему:
- Показать заказчику понимание его целей
- Показать пользователям решение их проблем
- Успешно завершить торг за бюджет
3) Создать основание для приемки (контракт на объем и качество результата, называемое так же «техническое задание»)
4) Определиться с ресурсами: видами, этапами, сроками, объемами работ и источниками ресурсов
Без этого ничего (хорошего) не выйдет.
Трудности
Все проблемы, о которых пойдет речь ниже, развиваются на заведомо неблагоприятном фоне, общем для всех предпроектов.
Надо быстро определиться со стоимостью системы на фоне высокой неопределенности.
Идет торг за бюджет и сроки — это конфликт, изначально заложенный в любой предпроект.
Заказчик хочет Сhrysler Escalade, денег есть на ГАЗ 69, но нужен ему Renault Logan. Бывает, что при этом поставщик решений хочет продавать яхты и самолеты, но реально может сделать только надувную лодку, а сейчас пойдет искать, у кого купить Logan.
Проект еще не «продан» и идет борьба за его запуск.
Обзор проблем и решений
Мы расположили частые проблемы предпроекта по мере роста зрелости заказчика и других участников ИТ-проекта:
1) «Письмо Дяди Фёдора»
2) Не учтены полный ЖЦ и структура как системы, так и финансового актива
3) Не учтены задачи предпроектной фазы
- Избыточная детализация требований
- Не представлены объем и достаточное деление системы
- Не проявлено понимание целей заказчика
- Нет основания приемки результата
4) Выбран неверный режим коммуникации требований
Обзор предлагаемых решений, о которых мы более детально поговорим в следующих разделах:
Кроме этого необходимо помнить о базовых принципах, которые мстят за невнимание к себе. Среди них:
- Понимание сути ИТ-системы и ее жизненного цикла
- Понимание взгляда на систему как на финансовый актив
- Понимание, что такое конус неопределенности и как его использовать
- Понимание основ оценки
- Понимание полного состава задач предпроектной фазы, невыполнение которых обрекает нас в лучшем случае на отказ от запуска проекта, в худшем — на мучения в заведомо провальном проекте, а в еще худшем — на кармические долги за мертворожденные ИТ-системы
Краткий обзор закончен, к деталям перейдем в следующих заметках серии.
Источник