Опубликовано: 15 мар 2020
Дисклеймер: у меня самого не было бизнеса подобного, тому о которых я пишу здесь, поэтому данная статья — это скорее взгляд со стороны, а не изнутри.
Онлайн бизнес привлекает многих — для кого-то это возможность выйти в область, где успех предприятия в наибольшей степени зависит от качества вашего продукта, а именно от способности реализовать интеллектуальный потенциал вашей команды, не от ваших связей, политических склонностей или скажем конкретной локации. Если вы предлагаете пользователям что-то уникальное, это естественным образом становится частью вашего бренда, вашего сайта.
В таких основных преимуществах и лежит на мой взгляд первый подводный камень — как бизнесмен вы создаете что-то не материальное, поэтому вам нужно хорошо представлять, в чем заключается то, чем вы обладаете и как защитить данную свою собственность. Если вы стартап и вкладываете средства в небольшое количество сотрудников, в кокой-то момент, если не предусмотреть системы "логирования знаний" может оказаться так, что в вашем продукте разбирается только один или два человека. В этом есть некие риски для устойчивого развития.
Поможет понимание того, каким образом и где хранится код вашего продукта, как хорошо он документирован, ну и естественно, кто отвечает за какие составляющие вашего кода, его сохранность и за поддержку устойчивой работы приложения. На рынке есть различные инструменты помогающие организовывать процессы в онлайн проектах, Git(Hub|lab), Jira, Confluence и т. д. В некоторых облачных сервисах, (например IBM Cloud) процессы непрерывной разработки, и разворачивания приложений (CI/CD), уже являются наглядным и прозрачным пайплайном внутри облачной экоситемы. Думаю, постепенно к этому придут и наши облачные провайдеры. Прозрачность процессов хранения и разворачивания кодов я бы рассматривал, как необходимую составляющую онлайн стартапа.
Второй важный момент, непроработка которого может привести к закрытию проекта — это правильная оценка как своих финансовых возможностей (инвесторы, свои сбережения), так и понимание величины предстоящих в обозримом будущем затрат, ну и как компенсация, возможных доходов. Да, это здорово, когда в голове есть крутая идея, некий свой "Avito" или даже "ВК", но возможно в некой новой области, который действительно будет пользоваться успехом у пользователей, если будет выведен на орбиту. Но нужно предвидеть, что по ходу его реализации может выясниться, что "крутой фреймворк на фронтенде" или "специфическая БД в бекенде" или дополнительные необходимые интеграции со сторонними API потребуют настолько же крутых и дорогостоящих исполнителей и соответственно незапланированные затраты. На своем скромном опыте скажу в качестве примера: при всей моей любви к тому же React-у (для кого-то это Angular, Vue), если бы я начинал делать свой продукт, я скорее всего обошел бы в начале его стороной (если была бы такая возможность, иногда бизнес требования четко диктуют выбор фреймворка). Я практически уверен, что пользовательский опыт от этого не пострадал бы. Но решение на начальном этапе было бы экономичнее и устойчивее.
Следующий момент — по мере возможности регулируйте атмосферу в вашем коллективе. Под этим подразумевается следующие — вы возможно еще этого не знаете, но как правило если взять, к примеру маркетологов и программистов-инженеров — это достаточно разные по типу мышления и видению проекта люди, иногда до противоположного. Ну т. е. то, что хорошо маркетологу, программисту может быть плохо. К примеру, маркетологи с удовольствием навесят на ваш сайт как можно больше рекламных пикселей и снипетов, что будет правильным с точки зрения маркетинга (наверное), но с точки зрения инженера — это все сторонние скрипты, работающие на его детище, которые могут тормозить сайт, следить за пользователями, и от которых он с удовольствием бы избавился.
Следующее — развитие, донабор команды. Старайтесь принимать участив в интервью ключевых специалистов. Если у вас есть замечательный талантливый коммерческий директор, все же наверное не стоит ему полностью отдавать подбор, скажем, директора по маркетингу, или да, даже аналитика. Аналитик может перед интервью зайти на ваш сайт и оценить его, как положительные, так и возможно отрицательные стороны. Ни каждому понравится, что кандидат нашел недостатки в области, за которую он отвечает. Правильное решение было бы конечно просто обсудить данные моменты и сфокусироваться скорее на профессиональных качествах кандидата, но иногда бывает и по другому, что в принципе тоже понятно.
Ну и конечно же хотелось бы сказать про веб аналитику — очень важно в самом начале закладывать правильный сбор данных, правильные метрики. Поскольку именно на основе этих данных будут приниматься решения о следующих шагах на пути развития проекта. К примеру, на старте у вас может быть период закрытого доступа, когда вы тестируете, дорабатываете свой сервис, открыв его только сообществу "подписчиков". И определение времени, когда ваш сервис готов к публичному доступу, т.е когда он приобрел достаточную эффективность, вы будете делать на основе собираемых вами данных. Поэтому так важно обеспечить правильную аналитику с технической и стратегической точки зрения. В том числе некую гибкость и универсальность, позволяющую быстро развертывать отслеживание необходимых показателей, скажем, новых фитчей или новых маркетинговых активностей и т. п.
Если вы Ecommerce проект, то важно с самого начала правильно развернуть предлагаемые популярными системами аналитики (например, Google Analytics, Яндекс Метрика) все возможности отслеживания маркетинговых воронок и ассортимента покупок через соответствующие модули расширенной торговли (Enhanced Ecommerce), доступные, как в Google Analytics, так и в Яндекс метрике. Это позволит вам получать хороший набор Ecommerce отчетов. И хотя они не смогут, ответить на все вопросы, но дадут очень хорошее основание для понимания того, что в плане торговли происходит у вас на сайте.
Другой тенденцией современной веб-аналитики на мой взгляд будет разворачивание in-house решений со стороны сервера. Это вызвано тем, что ряд браузеров уже давно активно борется с кросс-доменным отслеживание пользователей и с нарушением приватности их данных, что приводит к потере заметной части аналитических данных. Мы бесспорно должны уважать выбор пользователей в сторону блокировки пикселей и трекеров, но иногда для бизнеса бывает критично важным знать, как минимум сколько пользователей в точности воспользовалось той или иной фитчей предлагаемого сервиса. В таком случае serverside аналитка — это похоже единственное решение. Да, аналитика со стороны сервера конечно не сможет и не должна полностью заменить привычную аналитику — слишком много технологий от гигантов, двигателей современного интернета завязано на javascript и браузерах, но она может помочь решить определенные задачи и получить компании некую уверенность в тех данных, которые она имеет.
Другим важным шагом является создание маркетингового или же аналитического хранилища данных (DWH). Именно DWH позволит вам объединять данные с разных источников, гибко к ним обращаться, решать практически любые BI задачи. Я, как правило, разворачиваю DWH на базе Google BigQuery. Если у вас есть заинтересованность в данном стеке, вы можете связаться со мной через email в футере — буду рад обсудить имеющиеся задачи.