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

Большой бизнес может позволить себе все прелести SAP или Microsoft Dynamics AX. Со всей их громоздкостью, космической стоимостью внедрения и безграничными затратами на поддержку. Для малышей есть «Битрикс24», «Мегаплан» и прочий amoCRM — простые, дешевые, не гибкие и с трудом интегрируемые решения. Посередине — несколько никому не известных в России зарубежных программ. А в остальном — тишина.

HHI хотели создать ERP-конструктор — достаточно функциональный и гибко настраиваемый под нужды среднего бизнеса и в меру простой, чтобы это можно было сделать без привлечения армии консультантов, разработчиков и внедренцев. Прямо целая ERP-система — это в любом случае сложная история, поэтому начать хотели с малого, с CRM. И с конструктора для этой CRM.

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

 

ЕХАЛ АЙТИ ЧЕРЕЗ АЙТИ

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

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

Вы уже понимаете, к чему мы клоним? Чтобы было совсем понятно, оценим плюсы и минусы такого проекта.

Плюсы:

• Круто. Амбициозно, но круто, и поучаствовать в таком проекте, конечно, хотелось. Задача, которую пытались решить HHI, была более чем актуальна. А возможности корпорации, под крылом которой образовался стартап, позволяли довести дело до конца.
• ТЗ на 100 страниц. Практически на любой вопрос «а как это будет работать?» мы могли найти ответ в техзадании.

Минусы:

• Высокая степень неопределенности. HHI понимали, что невозможно сделать все и сразу, а мы не понимали, что же тогда из всего перечисленного нужно делать.
• ТЗ на 100 страниц. Вообще-то большая часть этого документа рассказывала о том, как — в техническом смысле — реализовывать функциональность системы. Но кому и зачем может понадобится эта функциональность, оставалось только гадать. Плюс вообще-то feature list был не так уж и велик, зато хорошо закопан в глубинах ТЗ.

 

Процесс

СТРАШНО, НО ДЕЛАТЬ НАДО

На старте мы не могли даже определить фронт работ. Во-первых, ТЗ называлось «частичное техническое задание», что подразумевало его изменение по ходу пьесы. Во-вторых, заказчик рассчитывал выпустить «минимально жизнеспособный продукт» с начальным набором возможностей. А вот какие именно возможности войдут в MVP — не знал никто.

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

А КАК ЖЕ АНАЛИТИКА?

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

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

Мы нашли потенциальных пользователей, поговорили с ними и попытались выяснить, на какой уровень директор или начальник готов погрузиться, чтобы настраивать систему управления. Большинство респондентов сказали, что они все равно привлекут системного администратора или просто «прошаренного» в компьютерной теме сотрудника — такие вещи не делаются в одиночку. Это нас успокоило. Значит, настройка системы может быть в меру сложной, и равняться мы можем на продвинутого компьютерщика.

В интервью мы могли получить общие ответы на общие вопросы. Но вряд ли кто-то смог бы перечислить нам все свои требования к конструктору ERP или CRM такого плана. Именно к конструктору, не к самой системе. Осталось изучать ТЗ, раскапывать в нем то, что имеет отношение к интерфейсам, формировать объектно-информационные модели.

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

Несуществующие пользователи несуществующей системы. Да, мы сделали это. Вот она, великая сила науки социологии и её качественных методов.

РИСУЕМ

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

Мы так пишем, как будто это было просто. А вы пробовали обсуждать интерфейсы с программистами? Ага, всё правильно понимаете.

 

У проекта была еще одна особенность. Заказчик хотел не просто прототипы, а графдизайн. Причем работа дизайнера была, по большому счету, разовая — отрисовать элементы, из которых программисты смогут дальше собирать дизайн самостоятельно. Нанимать человека в штат в таком случае смысла нет.

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

Когда процесс пошел, заказчик взял общение с дизайнером на себя.

Результат

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

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

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

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

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

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

 

Подробнее на сайте.