О некоторых ошибках в планировании ИТ проектах. Преждевременное масштабирование

Этот пост для тех, кто планирует запустить небольшие проекты, примерно от 5 до 100 млн. рублей. Обобщая 10 летний опыт разработки и поддержки проектов, обозначу основные, возможно, очевидные моменты, которые важно учитывать стартапам и заказчикам ИТ продуктов.

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

Заказчик всегда смотрит в будущее, когда проект уже раскручен, популярен и приносит хороших доход. Однако не стоит пропускать этапы становления. Всем известна диаграмма жизненного цикла, все понимают что, есть период бурного роста, поэтому хотят "стартовать" как бы с середины этого периода. Но гугл так просто не обманешь. Лучше придержать "хотелки", которые будут актуальны для проекта в лучшем случае только через полгода-год.

Обращаю внимание при планировании набора функций для пилота продукта на несколько моментов.

Основной вопрос для В2С проекта — это трафик. Вам нужно учесть, что получить даже 100 тыс. посещений в месяц займет определенное время. Для поисковиков новый домен около 1 года будет в "песочнице". То есть при вводе поисковых запросов при любой SEO оптимизации проект не будет на первых страницах, без прямой рекламы. По началу какой бы супер крутой проект не был органических переходов будет очень мало. Важно понимать доступный бюджет и длительность "вливаний".

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

— проводить длительную работу по внедрению,

— закладывать время на обучение персонала,

— регулярно собирать обратную связь,

— настроить работу поддержки в режиме 7\24.

Все это требует значительных затрат трудовых и финансовых ресурсов.

В целом узнаваемость бренда и доверие тоже формируется со временем.

Преждевременное усложнение продукта — это дорого и долго. Наиболее явные затраты при преждевременном масштабировании:

— для более сложной ИТ инфраструктуры дороже будет стоить хостинг, ресурсы, на которых он будет размещаться.

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

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

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

Все это, безусловно, потребуется, когда продукт вырастет и "оперится".

Закладываете бюджет на эти истории в течение нескольких лет.

Призываю разделять на планирование на этапы, когда в минимально доступный срок вы придете к клиенту (это и внутренние сотрудники, отделы, для которых создается новая "фича") с продуктом. На следующих этапах расширяйте базовый набор функций. Назовите это закрытым алфа- или бета- тестированием, но приходите к вашему клиенту как можно раньше. Очень важна обратная связь для правильного развития продукта.

Для В2С и В2В продумайте пилот с минимальным набором и сразу выход в продажи. Сделайте 1-3 функции, но очень качественно, чтобы они работали идеально, без сбоев, так как нужно клиентам. После этого после анонсов и "прогрева" аудитории идите продавать и устанавливать, выявлять новые "хотелки". Попираясь в каких-то вопросах на обратную связь можно выстраивать приоритеты для второго этапа развития.

Бывает так, что всем не понравилось, обычно все новое вызывает настороженную реакцию. Проанализируйте обратную связь, попросите детализировать, что именно не понравилось. Возможно, пользователь не смог разобраться сходу, как сделать привычные ему операции, или ему не хочется переносить всю информацию с похожих ресурсов, которыми он сейчас пользуется. У вас появятся "живые" отзывы, которые вы уже учтете при выборе стратегии развития.

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