Менеджеру, ответственному за запуск нового сервиса, или владельцу стартапа сложно выбрать подходящую IT-компанию по двум причинам.
Во-первых, часто они не понимают, что у них не просто сложный сайт, а продукт.
Во-вторых, под названием «IT-компания» скрываются разные организации: веб-студии с упором на креативный дизайн, разработчики сайтов на CMS, разработчики сайтов на фреймворках, интеграторы, разработчики продуктов и т.д.
Поэтому, обратившись в несколько компаний, вы получаете совершенно разные КП, сроки и стоимость.
Мы в SVK.Digital уже 25 лет создаем продукты, которые добиваются успеха. В статье расскажем, как понять, что у вас IT-продукт, и объясним, какую экспертизу искать у подрядчика, чтобы создать успешный продукт.
Как понять, что вы разрабатываете продукт, а не просто сложный сайт?
Итак, во-первых, важно определиться, действительно ли ваша задача требует особой экспертизы. Для этого разберемся, что такое продукты, и чем они отличаются от сайтов.
Сайт — инструмент маркетинга, который доносит информацию до посетителей и вы как потребитель читаете эту информацию. Например, это новостные сайты, википедия, блоги, сайты с обзорами и рейтингами компаний.
Продукт — сервис, в результате использования которого вы получаете какую-то ценность или выполняете некую работу. Например, покупаете товары или отправляете письмо по email, или сохраняете пароли, или бронируете апартаменты. То есть не только изучаете контент, но и взаимодействуете с продуктом.
Почему для продуктовой разработки не подойдет обычная веб-студия?
Продукты создаются совсем не так, как сайты. Поэтому для их разработки нужны компании, у которых есть необходимые специалисты, экспертиза и владение методологиями. Рассмотрим шесть причин:1. Выделенная команда, которая будет работать только с вашим продуктом
Успех любого проекта зависит от команды. Обычно она состоит из представителей заказчика и IT-подрядчика.
Представители подрядчика и заказчика объединяются в единую продуктовую команду, а понятия «клиент» и «исполнитель» исчезают. Такой команде нужно время, чтобы погрузиться в продукт, изучить рынок и модели поведения потребителей. Это возможно сделать качественно, только если команда работает с одним продуктом.
Подход, когда мы отдаем нескольких сотрудников под проект называется «выделенная команда». По сути вы получаете собственный IT-отдел, который занимается созданием и развитием продукта. Просто он сидит не у вас в офисе.
А специфика веб-студий, которые разрабатывают сайты, в том, что сотрудники делают до шести-семи проектов одновременно. Проектная команда пришла, сделала сайт и ушла. Создать успешный продукт при таком подходе невозможно. Люди просто не успеют погрузиться в детали, которые нужно учесть.
2. Методология, позволяющая быстро тестировать гипотезы
В небольших проектах используется так называемая каскадная модель. По ней мы делаем задачи последовательно: собираем требования, готовим дизайн и далее начинаем разработку. Это возможно, когда проект небольшой и понятный. Можно с первого дня написать техническое задание, а после — только реализовывать его по шагам.В продуктовой разработке слишком велика зона неизведанного, ТЗ на всю систему написать нельзя, поэтому там используют иной подход — HADI-циклы. В ходе них команда выдвигает гипотезу, реализует ее, замеряет данные и после — делает выводы: либо утверждает и масштабирует ее, либо отказывается.
В продуктах тестировать гипотезы нужно постоянно. Как минимум, чтобы продукт дошел до MLP*. А для этого придется внедрять разные фишки и смотреть, что находит отклик у аудитории. Это невозможно без отработанной схемы внедрения фич.
*Что такое MLP и почему термин MVP устаревает?
MVP (minimum viable product) — версия продукта с минимальным функционалом для тестирования идеи. Например, Notion изначально был очень простым визуально и имел мало функций, но для теста гипотезы и получения инвестиций в 2016 году этого было достаточно.
Недавно в противовес MVP появился термин MLP (minimum lovable product) — минимальный функционал продукта, который понравится пользователям. Сейчас мы чаще используем этот термин. Так как при текущем перенасыщении рынка качественными решениями недостаточно собрать минимальный функционал. Люди не будут пользоваться чем-то недостаточно хорошим. А значит — не получится проверить гипотезу, пока у вас только MVP.
Из-за постоянных тестов, доработок функционала и поисков удачных решений, уровень хаоса в продуктовой разработке высок. Важно найти команду, которая достаточно опытна, чтобы выдержать это.
3. Высокий уровень инженеров для создания новых решений на рынке
При разработке сайтов или интернет-магазинов можно подглядеть решения и технологии у конкурентов. Некоторые фичи делались много раз, а поэтому часть приемов получится позаимствовать.В продуктовой разработке все иначе. Часто приходится решать задачи, которые никто не решал раньше. Здесь важно, чтобы у команды было фундаментальное понимание того, как работают технологии. Нужны инженеры, которые смогут подбирать и тестировать технологии до тех пор, пока не найдут работающее решение. То есть в продуктовой разработке много исследовательской работы.
Например, когда мы создавали игровую платформу для Smart TV, PartyStation, мы делали движок видеоквизов.
В 2020 году мы делали это одним из первых на рынке, поэтому вынуждены были изучать какие-то смежные решения в разных индустриях: Netflix, «КиноПоиск», Figma и др. У них были отдельные пазлы того решения, которое нам было нужно. И в итоге нам удалось собрать с этих пазлов свое единое решение. Подробнее о том, как создавали PartyStation, в кейсе.
А для билетной системы «Профтикет» мы первыми создавали интерактивные системы залов, просто понимая фундаментально, как это может работать. Подробнее в кейсе.
4. Автоматическое тестирование
Продукт постоянно изменяется и пишется постепенно, а не от начала до конца. Из-за высокой связанности блоков продукта и сложности системы, часто возникают проблемы. Например, приходят новые программисты, создают функционал, а он ломает фичи, которые раньше работали исправно. Скажем, разработчики дописывают изменения в приеме платежей, а страдает пробитие чеков. В результате оказывается: вы не можете отправлять покупателям подтверждение покупки.Чтобы не допускать таких проблем, при продуктовой разработке весь код покрывается автоматическими тестами. Применяется система — SI/CD (автоматизированного деплоя). Процесс релизов происходит так:
→ Покрываем весь проект автоматическими тестами.
→ Когда релиз готов, проект проходит несколько сотен автоматических тестов, подготовленных заранее.
→ Получаем отчеты, что новый функционал протестирован и не нарушит ранее созданных функций.
→ Тестировщик принимает решение, можно ли выкатывать его.
→ DevOPS-инженер осуществляет автоматическую раскатку платформы до актуальной версии, в которой не сломаются никакие функции.
То есть система деплоя, так называемая система развертывания очередного релиза, гораздо сложнее чем у обычных сайтов, а сами релизы приходится делать чаще.
Сложнее и требования к другим инструментам:
- репозиторию — хранилищу исходного кода;
- средствам одновременной работы над кодом;
- инструментам контроля версий и инструментам резервного копирования.
В общем, то, как организована работа и тестирование, сильно влияет на успех продукта.
5. Подробное документирование
Продукт, постоянно меняется и усложняется. Если документации нет, а вся информация хранится в голове разработчиков, вы попадете в зависимость от так называемого Bus factor. Это метафора, которая гласит: если ключевого члена команды собьет автобус, у вас не останется знаний о проекте. Конечно, речь не про смерть в прямом смысле слова. Тем не менее, это то, что может случиться при увольнении коллеги, если знаний о проекте нет «на бумаге».При этом веб-студии не привыкли к подробному документированию проектов, потому что в разработке сайтов таких проблем нет. Они не меняются постоянно, а еще — в них нет огромного количества интеграций с другими сервисами. Даже спустя годы новые сотрудники, скорее всего, разберутся, как все работает и что нужно сделать, чтобы внести изменения в проект, ничего не сломав.
6. Экспертиза в привлечении инвестиций на IT-рынке
Создать продукт — только половина успеха. Часто его нужно поставить на баланс компании, чтобы получить патент или внести в реестр российского ПО.Или иногда стартапу нужно помочь оформить идеи, чтобы податься на получение гранта. У нас, например, был такой опыт: наш парольный менеджер BearPass получил грант от Фонда содействия инновациям. Поэтому мы понимаем, как это делать.
Или когда уже идея протестирована и продукту нужно расти, встает вопрос привлечения инвестиций и тогда собирается питч-дек — краткая презентация, которая дает потенциальным инвесторам представление о бизнес-плане, особенностях продукта и перспективах.
Или, например, если стратегией продукта является его продажа, то в этом случае продуктовая команда должна понимать, как это отражается на процессах: нужно аккуратно регистрировать интеллектуальную собственность, торговые знаки, так как всё это будет увеличивать стоимость продукта при продаже.
Если рядом с заказчиком команда, которая сталкивается со всем этим не впервые, то клиенту будет проще и он будет иметь больше шансов на привлечение инвестиций.
Как подобрать компании в тендер для разработки продукта
В поиске подрядчика есть несколько правил:1. Нужно убедиться, что вы отобрали в тендер компании, у которых есть опыт работы с продуктами. Главный вопрос, который стоит задавать любому, кого вы берете в тендер: «А какие продукты вы сделали?». И смотреть именно на них, а не на сайты или интернет-магазины. Ведь методология разработки там иная.
2. Когда увидите портфолио, не берите его на веру. Стоит найти контакты людей, которые владеют продуктом и поговорить с ними. В процессе разговора может выясниться, что, например, проекты делала совсем не эта студия, а в портфолио они появились обманом.
3. Обязательно проведите собеседование. На нем стоит выяснить, какую команду вам выделят и по какой методологии она собирается работать.
При соблюдении этих правил, вы, получите более-менее похожие коммерческие предложения с сопоставимыми ценами. И уже из них сможете выбрать подрядчика, которому доверяете больше.
Выводы
Определитесь, какой IT-проект вы планируете. Если это сайт или даже несложный интернет-магазин — подойдет веб-студия без специфического опыта. Если речь про продукт, с помощью которого люди будут решать определенные задачи, то стоит поискать команду с опытом в продуктовой разработке.Еще отличный вариант - своя команда в штат. Но только если у руководителя есть опыт работы со стартапами. Если нет, то вы получите все те же проблемы, что с неопытной командой на аутсорсе, только цена у такого проекта будет еще выше. Нужно будет нанять около семи человек и тратить примерно 3 млн в месяц. То есть проект будет стоить 18 млн при минимальном полугодовом цикле разработки.
В общем, если не хотите брать на себя таких обязательств, обращайтесь к нам в компанию по продуктовой разработке.
