Поговорим о стартапах или так можно ли использовать стандартные движки, темы и дизайн?

Приветствую всех читателей, сегодняшняя статья будет немножко необычной, в том плане, что тема будет поднята не совсем программистская, а скорее ближе к аналитической и бизнесовой. Поговорим мы о том, что же делать при начале своего собственного стартапа в сети Интернет, и попробуем рассмотреть один из самых популярных мифов (или нет?) о дизайне и движке вашего детища. И так, для начала рассмотрим само понятие стартапа, именно в контексте нашей беседы. Это создание веб-сайта или сервиса, который может:

• иметь уникальный функционал, аналогов которого пока не существует, или он сильно разбросан по различным системам. То есть вы задумали что-то такое, чего ещё нет вообще (тип 1).
• реализовывать уже существующий основной функционал, добавляя к нему отдельные возможности, расширяющие или переводящие использование уже известных функций на качественно новый уровень. К примеру, идея digg-сайтов не нова, но к стандартной возможности любому пользователю публиковать свои новости она добавила две функции, которые перевели уровень использования этого стандартного функционала (поста новостей) на качественно новый уровень (тип 2).
• переносит уже существующие функции и/или сервисы в новую для них среду, позволяя открыть ранее не использовавшиеся рынки, например, если раньше выделенные серверы и файловые хранилища были уделом только бизнес-пользователей и корпораций, то сейчас с приходом продуктов вроде Microsoft Home Server или FreeNAS реализует все возможности на уровне пользователя и пригодно к развёртыванию и эксплуатации в домашних условиях (тип 3).
• Агрегатирует функционал из разных, уже существующих источников,выводя новые возможности на основе комбинации существующих сервисов или улучшая использования оных (тип 4).

Конечно, эта классификация не самая полная, но для наших целей вполне сойдёт. А дальше мы сосредоточимся на следующих вопросах:

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

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

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

Рассмотрим это со стороны управленческой, то есть, как руководители или владельцы того самого стартапа, а не программисты (которые, по сути и реальности, все же просто технический персонал). Если ваш проект относится к типу 1 (то есть, вы задумали исключительно уникальный функционал, который взорвёт рынок, или, что ещё лучше, создаст сам этот рынок), то да, по всей видимости, у вас единственный путь - это создавать своё программное обеспечение полностью самостоятельно. И то, так как любой проект, несмотря на уникальность, все же требует много стандартных возможностей, начиная от внутреннего функционала (вроде систем регистрации, доступа к СУБД, шаблонизатора и т.п.), и заканчивая внешними сервисами вроде блога проекта, сайта разработчиков, форума - это все логично отдать на откуп уже проверенным сторонним системам.

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

Например, создавая новостной ресурс с дополнительной функциональность видео и аудио комментариями и рейтингом последний, логичным может быть использование уже зарекомендовавшего себя открытого движка блогов Wordpress, добавив в него несколько сторонних плагинов, реализующих дополнительные функции. Честно скажу, очень много действительно интересных и полезных проектов можно реализовать, просто собирая из кубиков - используя открытые системы, и наращивая при помощи комбинации из нескольких плагинов нужные функции. При этом сама по себе ценность ресурса никак не уменьшается! А вот затраты, особенно временные, существенно, часто на порядки, снижаются, а ведь именно время является главным и самым опасным врагом стартапа и всегда работает против создателей. Ведь даже самые простые расчёты могут обосновать для вас как менеджера проекта разницу в подходах - допустим, при самостоятельной разработке это:

• детальное создание описания функциональности проекта - 1 неделя
• детализация до уровня ТЗ на всю разработку и отдельные модули - 2 недели
• разработка самого проекта - 3 - 10 недель
• тестирование проекта - 1 - 3 недели (могут быть как размазаны по всем сроку разработки, так и ещё дополнительное полное тестирование в конце)
• повторные доработки и исправление багов, разработка дизайна и т.п.

 

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

Конечно, сейчас мне приведут аргумент, будто время, затрачиваемое на разбирание в архитектуре чужой системы чуть ли не равно времени разработки такого решения с нуля самому, и будут в корне неправы. Особенно это выгодно при повторном использовании того же решения в разных проектах, ведь разобравшись один раз, знания никуда не уйдут, а зачастую разбирания это чтение документации и просмотр кода с документированием, а разработка своего решения это совсем уже другой процесс. Кстати, есть и открытые проекты, качество документации которых заставит устыдится даже многих коммерческих разработчиков - посмотрите хоть бы на документацию к РНР фреймворкам типа ezComponents. А ведь как менеджера и владельца бизнеса, вас волнует что? Сроки запуска проекта, размер финансирования, реализуемость первоначального функционала, расширяемость и поддерживаемость в будущем. Вот последний пункт во всей красе как раз и выступает в случае использования готовой системы.

Как вы думаете, сколько программистов могут сопровождать систему на, скажем, Drupal или Wordpress или Joomla? Верно, очень многие, так как комьюнити этих систем очень большое, как в Рунете, так и за рубежом, тогда как ваша собственная разработка, кроме повторения уже сотни раз созданного функционала будет содержать взгляд на мир именно вашего программиста и, в лучшем случае, комментарии и кое-какую документацию. Поэтому при необходимости заменить или просто расширить свою команду разработчиков вы будете искать человека со стандартными знаниями, а он, в свою очередь, будет разбираться только в нюансах вашей разработки и специфики, не погружаясь в недельные разборки с принципами и кодом всей системы.

В общем, что сказать - если подходить к стартапу как к реальному бизнесу, и использовать вместо эмоций и типичного технического мышления критерии экономического характера и оценивать будущие ваши затраты (не только денежные, но и временные и человеческие), то в большинстве случаев вы увидите, что ваша задача вполне укладывается в функционал уже зарекомендовавших себя проектов, требуя для реализации всего лишь отдельных доработок, на которых и стоит сосредоточить все силы отдела разработки, вкладывая средства именно в то, что делаем ваш стартап уникальным. А пользователи, именно пользователи, а не комментаторы, не другие разработчики, не обозреватели новостных сайтов и блогов - приходят на сайт и используют размещённую там информацию, полезную для них, и им, в конечном счёте абсолютно все равно, на основе какого ПО или языка написана эта система. Ну, к примеру, почти каждый пользователь хоть раз посещал проект Wikipedia - и как то, что она создана на основе движка (вернее, её движок используется как свободное ПО и на нем основаны сотни других проектов) MediaWiki, а в основе использует распространённый РНР и СУБД MySQL - как это повлияло на ценность и восприятие информации? Думаю, что никак. И заходя на веб-сайт браузера Mozilla Firefox, мало кто знает, что он построен на базе стандартного движка Drupal - а ведь уж такое сообщество и компания как Mozilla могла бы сделать попутно и свой движок. Но не сделала, направив все усилия на развитие основной инфраструктуры и проектов, которые и являются основной их бизнес-процессов. Но вот почему-то обозреватели и критики любят подходить с критерием оценки проекта как "если он написан на стандартной системе Х, то на него никто не будет поэтому ходить/пользоваться". Какая связь между этими тезисами - никто пока не рассказал.

Более того, именно выбор стандартной системы, в большинстве случаев open-source для запуска стартапа является именно показателем логичности и разумности мышления менеджмента, и показывает, что в основе все же стоят вопросы функционала и качества работы, а не абстрактные тезисы о том, что "лучше хуже, но своё" или банальный "распил" халявных денег не учитывающего специфики инвестора. И лишь в немногих, я специально подчеркну, немногих случаях требования к функциональности проекта определяют необходимость разработчики своего уникального решения. Еще раз, краткий оптимальный план действий:

• Составляем перечень функциональности нашего стартапа
• Анализируем рынок существующих разработок, выбирая список проектов, которые могут стать основой проекта
• Рассматриваем каждый проект в разрезе соответствия нашему "фич-листу", наличие поддержки или комьюнити, качество документации и т.п.
• Стараемся выбрать тот продукт за основу, который больше всего реализует из наших требований, или реализует именно ключевые функции.
• Фокусируем средства и разработчиков на создание дополнений и расширений, доводя сторонний продукт до наших требований, максимально используя стандартный функционал.
• И только в случае отсутствия реальных аналогов или же полной уникальности создаваемого проекта переходим к самостоятельной разработке, которая, кстати, также должна начаться с точно такого же плана, только рассматривать следует уже не готовые продукты, а компоненты и средства разработки - фреймворки, наборы компонент, сервера и сервисы и т.п. сугубо низкоуровневые детали).

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