Консалтинговые ИТ-компании сегодня являются естественными конкурентами фрилансеров, независимых команд, традиционных студий и аутсорсинговых студий. Начиная свой бизнес, мы хорошо это понимали. Часто сталкиваемся с тем, что и клиенты и коллеги не всегда понимают разницу. Ссылаясь на то, что итогом работы как разработчиков, так и консалтеров является условный продукт с заранее предопределенным набором свойств. Для многих является аксиомой шутка про то, что консалтеры отличаются от остальных лишь количеством нулей в проектных бюджетах.
Здесь постараемся объяснить, почему наши услуги, как правило, дороже, в чем особенности консалтинг-бизнеса в ИТ и чем качественно отличаются услуги консалтинга от услуг аутсорсеров и фрилансеров на примере создания приложений для спорта. Опишем этапы, которые проходит проект в нашей компании, и расскажем, зачем эти этапы нужны.
Проблема цены и почему многим нужен консалтинг
Услуги консалтеров зачастую дороже, чем независимых команд, фрилансеров, студий и даже крупных аутсорсинговых компаний. Любая компания свыше 10 человек, как правило, имеет офис, бухгалтерию, налоги — а цены консалтеров выше, чем у самостоятельных команд. Студии, агентства и крупные аутсорсинговые компании также обременены такими расходами, но не продают нишевую экспертизу, так как постоянно работают с разными сегментами и погружаются в них исключительно в рамках требований отдельных проектов.
Как строится работа со студиями и независимыми командами?
(под спойлер) Наверняка существуют студии и команды, которые действуют иначе, но наиболее распространенная практика, судя по отзывам и опыту наших клиентов, такая, как мы описали далее.
Приходя в низкопрофильные студии, заказчик сталкивается с массой проблем: он должен сам разработать ТЗ, принести подходящий дизайн или проанализировать референсы для того, чтобы объяснить дизайнеру студии, что он хочет с точки зрения UI и визуальной составляющей. Бизнес требования в таких ситуациях заказчик тоже определяет сам, а это ещё один кусок аналитической работы. Такая работа обычно проводится поверхностно, студии ждут от клиента уже сформированных бизнес-требований, чтобы на их основе разработать системные.
При этом заказчики, в том числе в нашем спортивном сегменте, не всегда обладают достаточными ресурсами и временем. В этот момент возникает дилемма курицы и яйца. Как итог, непонятное ТЗ, забытые бизнес-требования, которые начинают регулярно возникать уже в процессе разработки (значит замедляют процесс), отсутствие нишевых знаний, которые нужны для того, чтобы понять очевидные для заказчика, но неочевидные для команды требования. ИТ составляющая спортивного клуба — это, как правило, 6-7 сайтов и ворох ИТ систем для их обслуживания, которыми обычно управляет всего 1 менеджер. Зачастую, у него банально нет времени готовить требования и знать технические тонкости интеграции с билетной системой или другими сервисами.
Что делаем мы?
Консалтеры стремятся закрыть все эти вопросы и минимизировать “геморрой” заказчика по этим поводам. И именно это оправдывает их стоимость. В этом смысле консалтинговое бюро экономит много времени, так как в большинстве случаев хорошо представляет бизнес-задачи, особенности дизайна, которые можно выгодно применить, боли ЦА и оптимальные пути решения существующих проблем. Мы сами готовим артефакты системного и бизнес-анализа, формируем ТЗ, разрабатываем дизайн и дальше создаем приложение. Чтобы оставаться “в теме” и поддерживать актуальность своей экспертизы, мы стараемся сохранять превалирование спортивных проектов в нашем портфеле.
Когда речь о клиенте из спорта, мы уже знаем, как интегрировать системы, с которыми работает команда, в единую и удобную инфраструктуру. Обычно речь про несколько сайтов и приложений. Типичны и проблемы уже существующих у команды продуктов:
Во-первых, много сайтов. Основного и юниорского состава, билетный сайт, магазин с мерчем и т.д.
Во-вторых, целый зоопарк систем с низкой или нулевой интеграцией (магазин на битриксе, “билетка” на Яндексе или инфотехе, а CRM, какой-нибудь Мегаплан. Также бывают ситуации, когда мобильные приложения работают отдельно от сайтов или имеют ошибки синхронизации.
В-третьих. Проблемы с ведением постоянных новостей и актуализацией другого контента. А тут такое, как снег на голову, и откуда начинать писать ТЗ неясно.
Редкий ІТ-менеджер способен подготовить полноценное ТЗ и артефакты бизнес-анализа по всем этим вопросам. Поэтому обычно задания по изменению, созданию и интеграции спортивных приложений, подготовленные заказчиками, не выходят за сухие нормы ГОСТ, чрезмерно абстрактны и редко выходят за рамки примитивных шаблонов, а порой и вовсе отсутствуют.
Нишевая экспертиза
Ещё более глубокий консалтинг подразумевается тогда, когда требуется нишевая экспертиза. Безусловно, хорошая студия сможет написать код для мобильного приложения спортивного клуба не хуже, чем это сделают в консалтинговом бюро. Она также сможет предложить лучшие практики в разработке, но там вряд ли будут заниматься аналитической работой.
Когда хоккейный клуб приходит к консалтерам с нишевой экспертизой за приложением, у представителя клуба, в первую очередь, спросят, из какой лиги клуб, а не на каком фреймворке они хотят сделать приложение. Дело в том, что требования напрямую зависят от аудитории. Есть клубы с историей, такие как “ЦСКА” и “Динамо”, а есть молодые команды. Аудитория принципиально разная и от неё зависит всё, начиная от дизайна и функций, заканчивая конкретным техническим решением, архитектурой, требованиями к надежности и отказоустойчивости.
У первых цель — выиграть кубок “Гагарина”. Они не хотят создавать инфоповоды, им просто важно освещать свою деятельность. У вторых — популярность спортивного бренда — одна из основных задач приложения. Третьи работают на имидж, например, академии и детские школы, большинство из которых продают или планируют продавать франшизы.
И эти цели также накладывают отпечаток как на функциональность, так и на особенности UI. Обычные студии не понимают этих различий и не могут, например, рассказать заказчику, нужен ли клубу календарь выездных встреч в приложении, нужны ли функции программы лояльности и т.д. Зачастую, студии работают по шаблонам наиболее известных спортивных приложений, попросту слепо копируя их функциональность или заимствуя дизайн. Консалтеры действуют иначе – изучают рынок в поисках новых походов, причем не только в спорте, но и в приложениях из сферы FMCG, обслуживания B2C клиентов. Заимствуют лучшие практики, адаптируя их для спорта.
Нишевая экспертиза позволяет предотвратить ненужные траты клиента, но клиент, иногда, смотрит не так далеко. Однажды к нам обратились представители образовательного учреждения и попросили оценить проект сайта, в котором было очень много излишеств, таких, например, как кастомная CMS. Зная потребности таких клиентов, мы рекомендовали отказаться от сотрудничества и сделать сайт на банальном вордпрессе. Так клиент сэкономил 70% бюджета, получив идентичный результат.
Особенности нашей работы
Мы всегда работаем по SCRUM. Это касается не только методологии разработки, но и организации других этапов, начиная от анализа и заканчивая выпуском готового продукта. Мы используем двухнедельные спринты. В рамках спринта применяются стандартные встречи: sprint planning, daily scrum, sprint review, sprint retro.
Анализ
К нам приходит клиент, описывает то, что он хочет разработать на первичном глубинном интервью, мы проводим предварительную оценку и показываем смету. Как правило, нас спрашивают: “А почему так дорого?”, и мы начинаем долго объяснять: предлагаем план-решение, показываем, с кем работали, объясняем, для чего нужна экспертиза и чем отличаются результаты, какие делали продукты. Клиент понимает, за что платит, и мы продолжаем, или прощаемся, если он не готов принимать наши аргументы в защиту цены, такое тоже бывает.
Первый спринт позволяет глубже изучить, что именно хочет клиент. Иногда бывает так, что заказчик просто показал приложение и сказал: “Я хочу также как у…”, и приводит в пример сайт Juventus. Естественно, это не дает информации о требованиях, и на первом спринте они уточняются. Составляем брифы и проводим дополнительные интервью, выясняем, что именно понравилось в референсе, на сколько функции референса соответствуют его пониманию продукта и т.д. Мы строим разговор таким образом, чтобы выявить максимум потребностей, объяснить ценность или бесполезность тех или иных требований в конкретном кейсе.
Часто такие интервью не касаются технических вопросов и посвящены не столько спорту, сколько бизнесу. Например, в домашних сериях есть матчи, которые хорошо продаются, а есть низкомаржинальные события. Потом мы проводим мозговой штурм, у нас появляется доска Miro (Diagram Flow) c вопросами, которые относятся к технической части и точкам касания клиента, затем там же описывается ІТ-архитектура при помощи Data Flow и составляется список основных эпиков.
Также дополнительно создаются следующие артефакты анализа:
Vision & Scope
SRS (Software Requirement Specification)
Use Cases
На их основе впоследствии формируется ТЗ по ГОСТ 34.602.89.
Дизайн
Перед созданием полноценного дизайна мы делаем скетчи в Figma, используем Fig Jam, которые дают представления о базовых моментах в UX. Впоследствии они утверждаются заказчиком. Сопоставляя список эпиков и эскиз, мы формируем Feature list. После этого мы разрабатываем полноценный UI Kit и макет дизайна страниц. Они также утверждаются заказчиком и в дальнейшем являются эталоном для проведения дизайн ревью. При подготовке первого брифа мы выявляем боли клиента в ИТ, прогнозируем технические проблемы, а также выясняем, на чем клиент намерен делать акцент в работе с болельщиками.
Планирование разработки
Когда все требования выяснены, данные проанализированы, а макеты дизайна утверждены, мы переходим к созданию Customer journey map для клиента. На этом этапе бюджет проекта может быть рассчитан более точно, так как у нас есть четкие представления об объеме функций, который мы хотим реализовать. Также на этом этапе формируется матрица ответственности, отображающая, сколько ресурсов потребуется со стороны клиента на техническую поддержку системы, маркетинг и контент. Функции и свойства продукта формулируются в виде user story, которые разбиваются на отдельные задачи, формирующие бэклог спринта. Все задачи распределяются на диаграмме Ганта.
Разработка, тестирование
Как я уже упомянул, мы работаем в рамках SCRUM, короткими итерациями по две недели. На протяжении каждого спринта мы поддерживаем тесную связь с заказчиками, чтобы оперативно реагировать на изменения в требованиях. В процессе разработки возникает ещё несколько значимых артефактов. Test Design с Process flow для QA, составленный для всех функций продукта, ОПЭ (опытно-промышленная эксплуатация) — документ для приёмки работ по продукту. При наличии сложной логики у функций, мы иногда оформляем блок-схемы.
Такие этапы как деплоймент и введение продукта в эксплуатацию не имеют отличий и особенностей в сравнении с традиционными аутсорсинг-разработчиками.
В сухом остатке
Основное отличие консалтинга — опора на экспертизу, в первую очередь, нишевую, как в нашем случае. Фактически, консалтеры конкурентоспособны на рынке благодаря тому, что их экспертиза востребована, а возможности по избавлению заказчика от необходимости в лишних движениях значительно выше. Если в традиционных компаниях команды больше всего фокусируются на технических вопросах, то для консалтера первоочередным будут бизнес-требования. Можно констатировать, что ИТ-консалтинг имеет смысл в тех ситуациях, где не подходят шаблонные решения, необходимо понимание целевой аудитории продукта на уровне участников комьюнити, а неудача проекта влечет за собой высокие риски. На самом деле, мы твердо уверены, что в спорте — это 95% всех кейсов. Каждый клиент мыслит по-своему и хочет отличаться, что напрямую соответствует целям маркетинга, спортивного, в частности — сделать уникальное предложение, которого нет у конкурентов.
