Техническое задание к бизнес плану

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

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

С чего начинать создание любой автоматизированной системы или информационного сервиса? С дизайна, с брифа, с прототипов, с опросов людей на улицах? А может быть, с написания грамотного технического задания по ГОСТ 34.602-89? Убежден, что на сегодняшний день грамотно составленный бизнес-план способен принести вам куда больше пользы, чем формальное написанное Техзадание по устаревшим канонам. И вот почему:

Допустим, ранее обязательным разделом в любом ТЗ являлось описание всех подлежащих автоматизации функций: ввод информации, хранение данных, электронный документооборот, конструктор отчетов и так далее…

Кажется, что именно эти вещи — ключевые в любой автоматизированной системе, а потому подлежащие автоматизации и алгоритмизации любой ценой. Также долгое время считалось, что чем больше и сложнее создается система — тем лучше будет предприятию. И вот уже в любой АРМ, CRM, сайт или приложение — запихивалось как можно больше разнообразных функций.

А уж про обилие всевозможных генерируемых отчетов даже вспоминать не хочется — иной раз, для того чтобы сформировать и проанализировать все ежедневные отчеты, исправно создаваемые системой, — руководитель (по нашим подсчетам) должен был бы работать по 27,5 часов в сутки. Зато сам текст Техзаданий от этого выглядел внушительно, и на приемке информационной системы будущее казалось светлым и радужным.

Печальное же всегда начиналось через пару месяцев после ввода подобной системы в рабочую эксплуатацию:

• внезапно оказывалось, что 90% всех функций никто не пользуется (не научились, нет желания или просто неудобны — не важно),

• что конечным исполнителем открыто саботируется (в простонародии: игнорируется) своевременный ввод всех данных, отчего электронные отчеты все сильнее начинают расходится с реальной картиной мира.

• и все это добивается однозначными выводами, что с вводом новой системы на выполнение тех же самых операций стало затрачиваться БОЛЬШЕ человеко-часов, чем ранее (с учетом найма администраторов, модераторов, операторов и прочего персонала системы — которые напрямую никак не влияют на рост продаж, лишь поддерживая жизнедеятельность бездушной машины).

Проблема в том, что описав в Техническом задании все как положено — вновь ничего не было сказано о самом главном. Но что же главное?

Сегодня любой видеоблог на Ютубе теоретически полностью подпадает под определение информационной системы. Так, у видеоблога могут быть понятные цели и задачи, и он успешно автоматизирует сам процесс донесения информации до большого числа пользователей по всему миру. А значит, по действующим нормам, созданию любого канала на YouTube должно предшествовать написание качественного стостраничного технического задания.

Но каковы здесь технические требования к оборудованию пользователей? Ограничения к пропускному каналу? К квалификации обслуживающего персонала? К приемке видеоблога в тестовую, а затем в рабочую эксплуатацию?

Очевидно, что половина ТЗ здесь будет просто лишней “водой”. А вот что реально необходимо продумать, так это: описание целевой аудитории, исследования потребностей, swot-анализ конкурентов; а также прогноз по прибыли, по ежедневным трудозатратам, по тематикам и рубрикам, по форме подачи, по срокам сдачи сценариев.

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

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

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

Сейчас, когда месяц работы команды из 3-4 экспертов информационных технологий стоит от 500 тысяч рублей и выше, — автоматизация каждой функции, каждый новый экран, кнопка, функция — должны быть экономически аргументированы.

Автоматизировать все “в лоб” сегодня могут себе позволить только самые богатые компании, всем же остальным просто необходимо уметь выстраивать качественный бизнес-план, исследуя потенциальную прибыль от каждой кнопки. Да, сегодня ни одна кнопка без денежного обоснования существовать просто не может — и лучшим подспорьем для проектирования любой новой системы должен быть качественный бизнес-план.

Конечно, показатели назначения присутствовали в Технических Заданиях и раньше. Например, фраза “обеспечить стопроцентную достоверность информации в базе” применительно к правам владения той или иной музыкальной композицией — звучит эффектно. Но не эффективно, поскольку пока абсолютно неясно, какие именно усилия по формированию этого самого обеспечения могут поспособствовать окупаемости проекта.

Что же делать? Для начала необходимо определить необходимые для проекта ресурсы, оценить, какие из них уже есть у вас и какие будут нужны дополнительно.

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

Итак, в нашем случае, ресурсами будут эксклюзивные данные о людях и компаниях, которые в данный момент обладают авторскими правами на те или иные композиции. Сейчас в едином месте такой информации нет, а значит начинать проектировать мобильное приложение нужно не с экрана авторизации юзера через Facebook, а с парсера, который ежесуточно будет собирать информацию из сотен разрозненных источников и приводить ее к единому формату. Ну, или создавать отдел менеджеров на окладах, которые будут выискивать все эти данные вручную и лично отвечать за актуальность данных, внесенных в google-таблицу.

Определившись с начальными и необходимыми ресурсами, а также их форматом, приступаем:

Шаг 1: Выбор единицы измерения проекта

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

Обратное верно еще больше: если проект, ТЗ, дизайн-концепция, прототипы ничего не могут сказать о своем денежном потенциале — тогда такой проект нужно смело называть благотворительным. И это абсолютно нормально, разумеется, если и бюджет на его разработку выделит в итоге профильный государственный фонд, а не ваш личный карман.

В нашем примере определяющей метрикой являлось количество платных подписок в месяц. Платная подписка определяет саму возможность доступа к эксклюзивной информации. В ежемесячных подписках отдельно должно считаться число новичков и продлений тарифа.

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

Шаг 2: Ссылка на проведенные исследования

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

Но исследовать нужно не только платежеспособность и потребности аудитории, но и уровень дополнительной нагрузки, который вы ей предлагаете. Так, ранее я уже неоднократно писал (rb.ru/opinion/demotivation/), что любые попытки автоматизации труда горничных в номерах или монтеров пути на перегоне всегда гарантированно снижали качество главной работы.

Это происходило и будет происходить всегда, поскольку, отвлекаясь на экраны и кнопки интерфейса, — исполнитель на 20-30% всего рабочего времени — в итоге выпадал из процесса работы.

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

Шаг 3: Планируемые расходы и выручка

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

• Расходы на разработку

• Расходы на персонал

• Расходы на продвижение и рекламу

• Порог окупаемости

• Ожидаемая прибыль

Полученные здесь цифры зачастую заставляют крепко задуматься над первоначальной концепцией.

Шаг 4: Наличие возможностей на ходу сменить курс

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

Заключение

Конечно, в интернете можно нагуглить примеры проектов, прославившихся без классических бизнес-планов, без ТЗ по ГОСТу и на голом энтузиазме своих гениальных создателей. Твиттер, покемоны, чат “Рулетка” — спору нет. Но…

Но большинство из нас — не гениальны. Большинство из нас — не выигрывало в лоторею миллион долларов. А значит, мы просто обязаны тщательно “постелить соломки” в первую очередь в денежном вопросе, планируя и обдумывая именно финансовое обоснование каждого будущего требования или просто “хотелки” к создаваемой системе. И тогда шансы создать современный качественный продукт, приносящий пользу, а не просто пробивший гигантскую брешь в вашем бюджете — многократно увеличиваются.

ОТ редакции: расскажите какие самые странные технические задания получали вы? А пока двайте вспомним какие статьи Сергей Немеров писал для нашего блога — это «Словарь юзабилити» и о требованиях к юзабилити мобильного сайта