Малые бизнесы имеют очень ограниченный набор ресурсов – как человеческих так и финансовых, что определяет их рамки работы и вынуждает действовать максимально эффективно. Под эффективностью понимается решение проблемы в минимальные сроки с минимальными издержками и трудозатратами[2].
Выбор правильных инструментов разработки – одна из ключевых частей продукта, так как в действительности в стартапах главный акцент уделяется поиску рынка, захват его доли или создание спроса, привлечение пользователей, поиск рабочей бизнес-модели, а не программирование/создание прототипа[7].
В жизненном цикле продукта можно выделить несколько частей: до запуска, поиск устойчивой бизнес модели/валидация, масштабирование.
В данной работе рассматривается только техническая сторона разработки и её организация, специфика которой меняется в зависимости от этапа жизни продукта.
1. Начальная разработка
Важный этап становления проекта, на котором закладывается программная основа продукта. Так как на этом этапе, как правило существует лишь не проверенная идея, работоспособность которой требуется доказать. Это даёт несколько важных следствий, определяющих стиль работы команды разработки:
- Сократить время разработки до минимально возможного, чтоб доставить продукт на рынок как можно быстрее. Для этого необходимо предотвратить избыточное проектирование[1];
- Спроектированная система должна быть максимальной простой, при этом достаточно гибкой, т.к. следующий этап с очень большой долей вероятности[2] продукт будет изменён для соответствия запросам рынка;
- Минимизация издержки на ПО и инфраструктуру;
- Использование средств разработки с которыми хорошо знакома команда, или как минимум, средств зарекомендовавших себя для решения подобных задач, которые должны заметно сократить время на разработку, увеличивая гибкость.
В качестве серверной инфраструктуру, если таковая необходима, стоит обратить внимание на облачную инфраструктуру[3], которая по сравнению с обычными серверами обслуживается не пользователями, а опытными сетевыми администраторами. Следует выделить несколько основных типов облачных услуг.
IaaS(Infrastructure as a Service, инфраструктура как cервис) предоставляет собой набор обслуживаемых виртуальных(реже – физических) машин, с высокой скоростью подключения к интернету, системами раннего предупреждения отказов аппаратного обеспечения, резервным копированием(за дополнительную плату), возможностью подключения различных типов постоянных хранилищ данных(SSD, HDD, и тд), выбором необходимого количества ядер процессора и выделяемой памяти. Наиболее крупными представителями таких сервисов являются: AWS EC2, Digital Ocean, Microsoft Azure.
Также в аренду предоставляются виртуальные машины, с предустановленным программным обеспечением, которые поддерживаются системными администраторами облака. Они занимаются обеспечением непрерывной работы, установкой обновлений безопасности, поддержкой сетевой связанности. Разработчики могут обращаться к этим серверам посредством публичного API. Наиболее популярные представители: AWS ElastiCache, AWS DynamoDB, AWS RDS, MongoLab, Microsoft Azure CDN, Microsoft Azure Redis Cache, SendGrid;
PaaS(Platform as a Service, платформа как сервис) – это виртуальные машины, которые выполняют пользовательские приложения в изолированной среде в контейнерах, предаствляющих API. Администраторы занимаются вопросами безопасности, своевременного обновления ПО, а так же горизонтальным масштабированием в зависимости от нагрузки. Представителями являются: Google App Engine, Microsoft Azure Cloud services, Heroku, nodejitsu, AWS Elastic Beanstalk;
SaaS(Software as a service, ПО как сервис) – готовые продукты, работающие на ресурсах в облаке, абсолютное большинство которых доступно через веб-браузер. В настоящее время практически все популярные приложения представляют собой SaaS cервисы. Например: Gmail, Yandex Mail, Google Docs, Asana, BitBucket.
Надо отметить, что все крупные облачные провайдеры предоставляют API, позволяющий автоматизировать процессы управления услугам. Важным преимуществом облачных провайдеров, особенно PaaS является модель оплаты: она начисляется в зависимости от используемых мощностей. В случае с веб-приложениями оплата может происходить за запросы к страницам сайта, времени исполнения запросов к БД и другим метрикам.
Таким образом, для увеличения скорости разработки и уменьшения издержек следует воспользоваться облачной инфраструктурой, однако стоит помнить, что по мере увеличения нагрузки стоимость будет возрастать и со временем на этапе масштабирования станет во много раз больше содержания собственной инфраструктуры. Во избежания таких проблем в будущем стоит избегать vendor lock-in[4] – проблемы, возникающей из-за сильной привязки к закрытым API поставщика услуг, например AWS DynamoDB.
Большинство серверных приложений можно запустить на ОС Linux, поддержка которой есть даже в облаке Microsoft Azure. Эта ОС является относительно безопасной и стабильной[6], благодаря большому вниманию со стороны сторонних разработчиков открытого программного обеспечения, поддержки многих крупных игроков рынка, таких как Google, Amazon, Twitter, Facebook, Oracle, IBM и многих других.
В общем случае большинство задач можно решить открытыми технологиями, в зависимости от задачи: PHP, java, python, scala, nodejs, groovy. Последние, в свою очередь имеют большое количество сторонних библиотек, позволяющие быстро делать прототип минимальными усилиями, по сравнению, например, с java2ee, благодаря простому синтаксису и динамической типизации, что в прочем, может быть источником проблем в будущем.
Автоматическое тестирование продукта – важный этап разработки, который молодые программисты предпочитают игнорировать с одной стороны, а профессионалы, проработавшие в крупных корпорациях, напротив делают слишком большой, непозволительный для стартапов акцент. По мнению автора стоит придерживаться принципа тестировать только те части, которые а) являются критическими для продукта, без которых он не состоится как продукт; б) сложно воспроизвести в вручную. Такими частями могут быть: регистрация пользователя, получение оплаты, работа с API, математические вычисления. При использовании языков с динамической типизацией стоит уделить дополнительное внимание тестированию.
Деление задач, их постановку, проверку необходимо вести в системах управления проектами, такие как Asana, GitHub issues, YouTrack, Jira, и другие. Это поможет всегда правильно понимать объем работы команды, прогресс и производительность членов команды. Также это служит хорошей базой знаний.
Для версионирования и синхронизации кода используют системы контроля ревизий. Так, например, git, распределённая система контроля версий прочно завоевавшая популярность[5] среди программистов всего мира на различных языках. В качестве альтернативных можно назвать hg, svn. BitBucket и GitHub являются git-хостингам и позволяют командам хранить код, вести базовый учёт ошибок и постановку задач, накапливать wiki-базу знаний.
Для обеспечения высокой производительности команды необходимо выработать у команды простые правила создания тикетов, не обременённых бюрократической составляющей с одной стороны, но имеющую достаточную информацию для решения проблемы/реализации функционала с другой.
2. Этап поиска устойчивой бизнес модели
На данном этапе команда тестирует гипотизу проекта. С технической стороны это выглядит как итеративное изменение конечного вида внешнего проекта, активный сбор информации о действиях, ключевых метрик и способах использования продукта пользователями, а так же корректировка продукта в на основе собранных данных. Процесс повторяется циклически до достижения ожидаемого результата.
Поскольку критическим ресурсом является время итерации(время между релизами) необходимо упростить процесс тестирования и разворачивания новых версий ПО на рабочих серверах с предварительным тестированием на тестовом. Таким образом реализуется схема непрерывной доставки(Continuous Integration, CI). Как и в случае с постановкой задач стоит избегать излишней бюрократизации процесса. Автор предлагает следующую схему
Стадия бета тестирования позволяет на ранних этапах отловить ошибки, чтоб предотвратить их попадание в релиз в рабочее окружение. Бета-тестировщиками могут быть как сама команда так и пользователи сервиса. При достаточной квалификации команды следует воспользоваться подходом staged rollout[7], который заключается в последовательной раскатке новой версии продукта на не большую часть пользователей. Этот подход позволяет уменьшить количество ошибок, если таковые имеются, которые могут затронуть всю пользовательскую базу.
В качестве систем непрерывной доставки можно воспользоваться свободным ПО jenkins CI или коммерческими продуктами, такими как JetBrains TeamCity или Atlassian Bamboo. Эти системы позволяют автоматизировать весь процесс, который, как правило инициируется отправкой изменений в систему контроля ревизий.
Система самостоятельно забирает изменения, выполняет тесты и в случае успешного их прохождения разворачивает продукт на тестовом сервере, после чего успешно успешной апробации бета-тестерами он может быть выгружен на рабочий сервер.
Так как сбор статистики это отдельная, достаточно большая задача разумно воспользоваться различными сторонними облачными системами, в зависимости от типа продукта можно выделить основные популярные инструменты:
- для веб приложений: Google Analytics, Yandex Metrika, Spring Metrics, KISSmetrics, Piwik и многие другие. Последний является так же свободным ПО и может быть установлен на собственный сервер компании. Это может быть актуально если собираемая статистика имеет чувствительные пользовательские данные, такие как информация о финансовых транзакциях;
- для мобильных приложений: Flurry, Google Analytics, MixPanel и другие. Эти системы позволяют отслеживать пользовательские события, генерируемые программным кодом для отслеживания последовательности действия пользователя.
Помимо аналитики сценариев использования сервиса необходимо своевременно обнаруживать програмные ошибки во время выполнения приложений на устройствах пользователей. Это возможно с помощью таких сервисов как Crashlytics, newrelic, getsentry, которые предоставляют удобный интерфейс с подробным описаниям типов ошибок, их группировке, частоте их возникновения по различным версиям продукта, программному и аппаратному окружению.
3. Этап масштабирования
Когда рынок продукта найден, портрет потребителей сформирован и найдены каналы продвижения наступает бурный этап роста. С технической точки это как правило означает, что продукт зафиксировал набор функционала на некоторое время и фокус разработчиков переключается на его поддержку и обеспечение стабильной работы на большом количестве пользователей.
На данном этапе проявляются технические долги[8] – следствие частых изменений в програмном продукте во время продуктовых экспериментов. Подготовить продукт к массовой аудитории можно:
- переработав всю существующую кодовую базу с расчётом на большую нагрузку и стабильность;
- реализовать все с нуля, т.к на этом этапе есть относительно чёткое представление о требованиях к системе, сценариях использования пользователям, что позволяет спроектировать правильную архитектуру.
Задача техническая команды взвесить трудозатраты на различные варианты и выбрать наиболее оптимальный вариант. Если на этапе начальной разработки был выбран PaaS в качестве места размещения приложения может быть разумно найти альтернативы, так как в общем случае при предсказуемо высокой нагрузке стоимость будет значительно выше.
Как правило рост продукта подразумевает увеличение штата компании – какой бы путь решения технических долгов компания не выбрала необходимо учитывать необходимость найма новых технических сотрудников, которые могут иметь меньше опыта с предметной областью, поэтому необходимо поддерживать общепринятый стиль кода, вести документацию и базу знаний.
Заключение
В настоящее время доступное большое количество инструментов и подходов для различных стадий разработки программных продуктов массового использования, которые помогают сократить издержки на разработку, запуск и поддержку нового продукта благодаря использованию новых технологий и активному использованию сторонних сервисов, что позволяет сконцентрироваться непосредственно на эффективном построении продукта.
Библиографический список
- Overengineering [Электронный ресурс]. Режим доступа: http://en.wikipedia.org/wiki/Overengineering
- Rip Empson, What Makes A Startup Successful? Blackbox Report Aims To Map The Startup Genome Posted, [Электронный ресурс]. URL: http://techcrunch.com/2011/05/28/what-makes-a-startup-successful-blackbox-report-aims-to-map-the-startup-genome/
- Luis M. Vaquero, A break in the clouds: towards a cloud definition, ACM SIGCOMM Computer Communication Review archive Volume 39 Issue 1, 2009. 50-55
- Satzger, B. “Winds of Change: From Vendor Lock-In to the Meta Cloud”, Vienna Univ. of Technol., Vienna, Austria, 69-73
- James Mckay, “Are there any statistics that show the popularity of Git versus SVN?”, Programmers Stack Exchange [Электронный ресурс]. Режим доступа http://programmers.stackexchange.com/a/150791/153661
- Pam Baker, Is Linux Really More Secure than Windows? [Электронный ресурс]. Режим доступаhttp://www.esecurityplanet.com/trends/article.php/3933491/Is-Linux-Really-More-Secure-than-Windows.htm
- Max Marmer, Ertan Dogrultan, Startup Genome Report, [Электронный ресурс]. Режим доступаhttps://s3.amazonaws.com/startupcompass-public/StartupGenomeReport1_Why_Startups_Succeed_v2.pdf
- Linus Petersson, Hampus Nilsson, “How to Manage Technical Debt in a Lean Startup”, Chalmers University of Technology, University of Gothenburg, 37-38, [Электронный ресурс]. Режим доступа http://publications.lib.chalmers.se/records/fulltext/216789/216789.pdf