Нередки случаи, когда крупные компании с собственным штатом ИТ-специалистов, в попытках определиться с формализацией функциональных бизнес-требований к будущей ИТ-системе, привлекают к работе внешних консультантов. Почему? Потому что приходят к пониманию, что сами, без посторонней помощи, этого сделать не смогут. Ведь в вопросе выбора наиболее подходящей системы крайне важны как независимая экспертиза, так и наличие дорожной карты внедрения. Попробуем разобраться, какие ключевые моменты стоит учесть для формализации требований и как это лучше сделать.
1. Нужна ли ИТ стратегия?
Я убежден в том, что руководство компании должно обладать видением развития информационных технологий на горизонт Поскольку последнее время ИТ все больше сплетено с бизнесом, то иметь это видение только в голове одного человека обычно не очень удобно и стратегия должна быть изложена на «бумаге». Наш опыт показывает, что самый удобный способ — это формат презентации.
Что есть стратегия? В первую очередь это — целевая укрупненная архитектура решений и портфель проектов для достижения поставленных бизнес целей. Важно — это живой документ, который меняется.
Зачем нужны бизнес требования?
2. Делать самим или приглашать кого-то?
Мы последовательные сторонники того, что автор и идеолог ИТ-стратегии — это CIO компании. Привлечение сторонней компании — только помощь, но не замена. Безусловно, все можно сделать силами своей команды, но тут всегда есть риск того, что если раньше в подобных работах не было опыта, то качество может оказаться недостаточным. Я видел ИТ-стратегии, списанные с рекламных буклетов кого-то из вендоров — понятно, что толк от этого нулевой. В то время как контракт с интегратором на разработку ИТ-стратегии позволяет получить быстрый доступ к экспертам разных направлений и сформировать разные сценарии развития ИТ.
Но с другой стороны, мне довелось видеть и очень достойные материалы, подготовленные полностью силами сотрудников компании. Поэтому этот вопрос по большей части упирается в возможность объективной оценки собственных возможностей.
3. Что первично — система или стратегия?
Они взаимосвязаны. Разрабатывать стратегию, не опираясь на то, какого класса системы доступны — интересная работа, но имеющая, скорее, академическую ценность. Если для автоматизации определенных бизнес-процессов уже выбрана какая-то система, то этот факт должен существенным образом учитываться.
Например, вы выбрали SAP ERP. Это значит, что у вас должно быть две интеграционных шины — SAP PI для работы внутри SAP и интеграции и отдельная шина для всей остальной интеграции. Конечно же, не имея SAP, планировать две шины странно. Другой пример — 10 лет назад в России были недоступны SCM-решения, и даже проектировать что-то было бессмысленно, но, с другой стороны, тогда был Excel.
4. Определение ключевых проблем в бизнес-процессах
Сбор информации о наличии проблем и пожеланий к автоматизации являются важнейшим критерием для составления ИТ-стратегии проекта. Как правило, это реализуется путем интервьюирования и анкетирования участников процессов, анализа имеющейся статистики и наблюдения за процессами.
Но помимо сбора проблем их важно подтвердить или доказать, что тот или иной момент является ключевой проблемой, а не частным случаем. Это позволит оценить потенциал эффективности будущего проекта и конкретного бизнес-процесса после его автоматизации, рассчитать окупаемость вложений на внедрение того или иного решения. От вашей причастности к сотрудникам компании, либо участникам команды, которая будет реализовывать проект, по весьма понятным причинам нередко страдает объективность выявления проблем. Будучи внутри команды очень сложно оценить процесс со стороны.
5. Формирование портфеля проектов
Эту часть ИТ-стратегии очень часто недооценивают. Нередко развертывание ИТ-решений планируют исходя из удобства ИТ, но не учитывают в полной мере требования бизнеса, аргументируя тем, что если делать не по правилам, то придется «переделывать». Неприятная правда в том, что переделывать придется постоянно.
Бизнес-среда настолько сильно и быстро меняется, что разрабатываемая система может устареть еще до того, как ее успели внедрить. Поэтому сейчас фокус и приоритет получают проекты, которые дают понятный ROI, причем быстро. Или переводят качество управления на более высокий уровень.
Например, слияние двух банков потребовало перехода одного из банков на АБС другого, что повлекло за собой примерно годичную заморозку развития систем. Под мощнейшим давлением бизнеса сотрудники из ИТ пошли на «неправильную» архитектуру — они внедрили интеграционную шину и связали в режиме онлайн две АБС. После этого организация приобрела еще несколько банков, их также быстро подключили. Но когда бизнес устоялся, всех постепенно, но «правильно» перевели на единую АБС.
Другой проект — в крупном дистрибьюторе с широкой сетью филиалов и распределительных центров. После запуска в головной организации ERP-системы остро встал вопрос получения управленческой отчетности, но ИТ-команда настаивала прежде перевести все филиалы и дочерние организации с «1С» на единую ERP-систему, и лишь после этого заниматься новым решением для аналитики. В итоге бизнес настоял (и не пожалел) на том, чтобы строить аналитическую систему параллельно с тиражированием ERP-решения на филиалы и делать временные интеграции аналитического хранилища и «доживающих» конфигураций «1С». А переход на единую ERP-систему осуществлялся более постепенно.
Поэтому в каждом отдельном случае «правильное» решение может быть своим. А значит, несмотря на то, своими силами будут определены требования к системе, либо с привлечением внешних консультантов, от наличия стратегии развития корпоративных ИТ существенным образом зависит и успешность реализации будущего проекта.
Автор статьи — директор по бизнес-приложениям компании КРОК.
Источник: www.itweek.ru
С чего начать составление технического задания на разработку сайта: формирование требований
Формирование технического задания на разработку определяет не только качество сайта, но и измеримые бизнес-показатели, которые он будет приносить. До разработки технического задания заказчику стоит сначала подготовить, а потом сопоставить бизнес-требования и видение, касающееся функциональности. Такой подход обеспечивает четкое бюджетирование проекта, расчет правильного срока выполнения: разработчику не придется вносить бесконечные правки или переделывать сайт. Мы рассказываем о том, что такое функциональные и бизнес-требования, как их собрать, почему это необходимо сделать до составления технического задания на разработку сайта.
Функциональные требования
Функциональные требования определяют особенности проекта, которые должен реализовать специалист по разработке. Речь идет о логике работы, наборе функций. В них описаны аспекты работы в то время, когда пользователь совершает какое-либо действие – от регистрации до подписки на новостную рассылку. Например, заказчику необходим интернет-магазин, наделенный определенным набором функций: наличие личного кабинета, возможности оплаты, программы лояльности, многое другое.
Стоит разделить функциональные и нефункциональные требования. Последние – атрибуты, необходимые площадке для стабильной работы, но не связанные с основным набором функций. Выделим основные нефункциональные требования:
- производительность сайта. Это может быть скорость загрузки страниц или время отклика на какое-то действие;
- уровень удобства. Параметр определяет уровень комфорта для пользователей: интуитивность меню, расположение кнопок, время, затраченное на поиск информации, другие;
- безопасность. Решает проблему кражи персональных данных, атак хакеров, защиты от вирусов. Небезопасные площадки не любят поисковые системы, а пользователи стараются обходить их стороной;
- совместимость (адаптивность). Фактор, определяющий корректность отображения страниц на разных устройствах, в браузерах. Частичное отображение изображения на телефоне, растянутый текст в Google Chrome – всего этого быть не должно;
- локальная адаптация. Актуальна для компаний, сайты которых работают в нескольких странах. Проводится добавление разных валют, перевод на языки пользователей (с возможностью переключения на подходящий автоматически или вручную), внедрение часовых поясов, иного.
Нефункциональных требований много – это могут быть визуальные элементы (изображения или шрифты), а также все относящееся ко внешней оболочке площадки, удобству для пользователя (UI/UX соответственно). Определить разницу между функциональными и нефункциональными блоками просто: первые – это классическая телега с колесами, вторые – кузов легкового автомобиля BMW, дополненный подсветкой, другими элементами. Доминирующее количество клиентов платят за престижность BMW, но в это же время ожидают от машины работоспособности. Функциональные требования определяют содержимое, остающееся незаметным для пользователей, а с нефункциональными посетители сайта взаимодействуют постоянно.
Бизнес-требования
Бизнес-требования – задачи, которые будет решать сайт. Они понятны руководителю компании, который не должен углубляться в техническую часть процесса разработки. В эту группу входят:
- сведения о бизнесе: название, год основания, опыт работы, ниша, товарные знаки, преимущества перед конкурентами, списки клиентов;
- сведения о целевой аудитории. Разработчик и предприниматель должны понимать, кем является клиент: возраст, пол, семейное положение, страна, регион, вкусы, привычки, бюджет, иные. На этапе сбора сведений нужно попробовать мыслить как клиент: зачем посещается сайт, что нужно купить, получить или узнать. На основе этих данных формируются решения, удовлетворяющие боли потребителя;
- цель разработки. Заказчик должен определить, какие результаты он хочет получить на финише разработки. За основу стоит брать измеримые бизнес-показатели, например, расширение базы клиентов, повышение продаж, поиск инвесторов.
Для решения любой задачи доступно несколько способов, важна первичная расстановка приоритетов, акцентов. Например, компания хочет создать сайт для повышения присутствия в интернете, позиционирования: при разработке акцент будет делаться на престижность, комфорт, изобилие элементов айдентики. Если цель – получение измеримой прибыли, то заказчик должен видеть все возможности достижения такого результата.
Почему функциональные и бизнес-требования так важны
Важность обусловлена большим количеством задач, решаемых с помощью правильных требований:
- улучшают коммуникацию между разработчиком и заказчиком сайта: все отлично понимают друг друга;
- предупреждают недопонимание, в том числе на этапе фактической разработки;
- сокращают срок работы над проектом, что обусловлено четкостью, отсутствием потребности в уточнениях, доработках по ходу реализации;
- обеспечивают существенную экономию бюджета. Четкие задачи помогают получить прозрачное ценообразование, не опасаться размытой стоимости разработки. Заказчик уверен, что цена не изменится на каком-то из этапов или после воплощения проекта в жизнь;
- помогают прогнозировать результаты. Измеримые задачи дают уверенность разработчику: он видит, что, как, когда нужно делать. Они предупреждают отступление от технического задания, выход за запланированные временные или бюджетные рамки;
- предупреждают ошибки, поэтому не нужно будет их устранение.
Наличие функциональных и бизнес-требований – фактор, предопределяющий успешность проекта. Разработчики не будут креативить или ссылаться на неточное ТЗ, а заказчик будет знать, какой результат получит в итоге.
Как выполняется сбор данных, кто этим занимается
Заказчик, хорошо представляющий финишный результат разработки, производит сбор данных самостоятельно. Именно он точно знает, какие товары или услуги будет продавать, какие инструменты целесообразно привлечь для продвижения, кто его целевая аудитория и какие боли она имеет. Сбор данных для функциональной части – задача, делегируемая маркетологам и представителям IT-отдела. Особое внимание отводится главной странице сайта, отвечающей за максимальную конверсию. На этом этапе привлекаются сотрудники из клиентского сервиса или отдела продаж, которые могут предоставить основные вопросы клиентов, инструменты для проработки возражений.
Если заказчик – представитель малого или среднего бизнеса, не располагающий структурными кадровыми подразделениями, лучше привлечь к работе профильное агентство. Сотрудники агентства изучат конкурентов, а потом сформируют релевантную digital-стратегию. Еще одной решение – заказ услуги под ключ, когда все этапы проекта курирует компания по разработке сайтов. Для сбора данных используются следующие методы:
- бриф для сбора первичной информации на разработку сайта;
- интервьюирование;
- работа с документами, отражающим особенности бизнеса заказчика. Проводится изучения спецификаций, инструкций;
- привлечение представителя заказчика, защищающего интересы бизнеса;
- проведение мозговых штурмов, коллегиальных совещаний.
Все данные фиксируются в документе, который ложится в основу технического задания на разработку. Документ лишен технической информации и по содержанию напоминает бриф, включает 4 раздела:
- бизнес-требования, имеющие приоритете перед другими. Регламентируют цель проекта, задачи;
- дизайнерские особенности. Обеспечивают приятный визуал будущего сайта – от цветового ансамбля до стиля. Перекликаются с элементами айдентики компании, идеями заказчика;
- права доступа. Раздел определяет возможности, права доступа пользователей: просматриваемая информация, добавление и редактирование данных. По сути происходит установка ограничений для повышения безопасности данных: редакторы работают исключительно с контентом, менеджер по продажам – с базой заказов или клиентов, бухгалтер – с отчетами, другой финансовой информацией. Пользователь не сможет увидеть информацию, которая прямо не относится к полю его деятельности;
- потребности посетителей площадки. Специалисты разрабатывают путь юзера на сайте, для больших проектов составляется карта CJM.
В создании документа принимают участие все специалисты, которые будут работать над проектом, заказчик или его уполномоченные представители. Нередко клиенты не могут четко передать свое видение, они хотят «как вот здесь или вон там». Детализация каждого этапа помогает разработчикам создать сайт, отвечающий видению, сформулированному в подсознании у заказчика.
Обзор распространенных ошибок
Самая распространенная ошибка – размытые ожидания, которые не отображают суть цели или задачи. Нужно ставить четкие и выполнимые задачи, понятные и для заказчика, и для разработчика. Необходимо сохранять баланс между размытостью и чрезмерной детализацией, а также избегать субъективизма и иных проблем, которые направят команду по ложному пути.
Техническое задание не должно быть перегружено лишними деталями, в противном случае разработчик потратит много времени сначала на изучение, потом – на реализацию. Например, заказчик указывает «Все страницы должны загружаться быстро» – это размытая формулировка, которую нужно заменить измеримым показателем: «Скорость загрузки страницы – до 3 секунд. Сохранение работоспособности при суточной посещаемости 50 тыс.». Некоторые требования – ориентировочные, ведь многие элементы нужно проверять, тестировать, чтобы выявить самые эффективные решения.
В заключение
Подготовка функциональных и бизнес-требований должна выполняться до создания технического задания. Стоит привлечь разносторонних специалистов, чтобы не упустить технические, маркетинговые и другие аспекты, важные для бизнеса. Задачи должны быть максимально конкретизированными, лишенными воды, неточных формулировок и показателей, не являющихся измеримыми.
Заказчику нужно принимать личное участие в подготовке информационной базы, что защитит его от лишних трат, срывов сроков и создания сайта, не отвечающего одному или нескольким ключевым параметрам. Для представителей малого и среднего бизнеса оптимальным решением остается обращение в веб-агентство. Его представители выполнят работу под ключ – от сбора первичных данных до запуска и продвижения ресурса.
Источник: vebrost.ru
