Доброго всем времени суток!
После успеха предыдущей нашей публикации, мы долго думали, кого попросить написать следующую статью — кто будет тем, кому придется спорить за популярность со статьей про секс. Выбор пал на технического директора 404Group Романа Друзягина, который расскажет про запуск проекта с точки зрения «технички».
«Про “старт-апы”, их начало, развитие и окончание не написал разве что только совсем ленивый человек, настолько эта тема актуальна и популярна. Проекты появляются и исчезают десятками каждый день, что наглядно позволяют увидеть сервисы, подобные Kickstarter. Отдавая дань моде, хочу поделиться некоторым опытом и взглядом на рынок “старт-апов”, сформировавшимся в результате многолетней деятельности по запуску и выращиванию Интернет-проектов в стенах нашей компании. Многие из этих проектов ждал печальный исход, причем, нередко еще на самом старте.
Материал, представленный в этом очерке, не претендует на звание истины, но хорошо отображает реальную ситуацию в среднестатистическом “старт-апе” и типичные проблемы, которые в нем возникают. Поскольку я являюсь представителем технической профессии, то и взгляд мой будет именно с позиции “технички”. Что обычно делают правильно и не правильно, и к каким результатам для проекта это может привести в последствии?
Компания 404 Group и люди, ее учреждающие, занимаются инвестированием в Web-проекты уже с добрый десяток лет. В 70% случаев идея придумывается внутри представителями “правящей верхушки” и запускается в развитие. Остальные 30 процентов приходится на перспективные продукты, которые мы приглашаем сотрудничать к нам в организацию. Не важно, каким из двух путей проект оказывается в стенах компании, дальше игра ведется на равных.
У проекта есть команда (“технари” и “менеджеры”) во главе с одним-двумя руководителями, которые целиком и полностью отвечают за выставляемые проекту цели. В обмен, компания предлагает команде все свои ресурсы: финансовые инвестиции в оговоренных ключевыми участниками размерах, офисные удобства с печеньками и приставками, операционную поддержку (финансисты, юристы, секретари, HR и другие специалисты), технические компетенции (опытные инженеры, DBA, системные администраторы) и другие мощности, которые у компании имеются для реализации проекта.
По какому пути развития пойдет проект и будет ли он успешен, уже зависит от его команды. За годы практики удалось выделить несколько типовых сценариев, по которым развивается тот или иной продукт. С опытом мы научились, насколько это возможно, корректировать курс движения проекта, если мы видим, что он вступил на “скользкую дорожку”. А некоторые и вовсе не берем под крыло компании как заведомо проигрышные “черные дыры”, в которые деньги и иные ресурсы будут только утекать.
Сценарий №1, наиболее перспективный: проект ориентируется на результат, придерживается философии “ship fast & often” или, выражаясь более привычным языком, “х**к и в продакшн”. Приверженцы такого подхода стремятся максимально быстро вывести на рынок работающий продукт, начать его активно развивать и улучшать, основываясь на обратной связи от потребителей. В проекте крайне редко применяются специфические методологии или способы разработки. Нанимаются разработчики с приемлемым уровнем компетентности, а работа над “фичами” происходит по принципу внезапной постановки “немедленных” задач, которые желательно сделать ко вчерашнему дню. Такая модель является максимально жизнеспособной, посколько с наибольшей долей вероятности обеспечивает возможность продемонстрировать учредителям реальные рост и развитие, осуществляемые на их деньги. Ключевая проблема такого сценария — недостаточно внимательное отношение к качеству продукта, что может привести к серьезным рискам, угрожающим проекту в целом.
Сценарий №2: проект ориентируется на качество. Такие проекты делаются программистами, которым надоедает быть наемным исполнителем и хочется попробовать сделать что-то свое. Начинание благородное, но очень часто уставший от постоянной борьбы с “багами” и рутиной специалист принимает крайне опасное для проекта решение все учесть и предусмотреть заранее. Много времени уделяется правильной архитектуре, и недостаточно — проработке коммерческой составляющей, а именно, как проект будет приносить деньги.
В Web-проектах учесть все практически невозможно. Стремясь решить эту задачу, команда не замечает полной растраты инвесторских денег, и проект бесславно погибает. Многолетний опыт подсказывает, что творчески настроенный менеджер способен придумать задачу, которая настолько перпендикулярна текущему состоянию архитектуры, что для ее внедрения потребуются недели, а то и месяцы переделок. Понятное дело, что на практике приходится к прибегать менее приятным методам и жертвовать качеством в угоду скорости.
Сценарий №3: проект ориентируется непонятно на что. Такие проекты часто являются мертворожденными еще на старте. У людей, его придумавших, в головах имеется непонятная каша из технологических и коммерческих идей, которая не выстраивается во что-то конкретное. Cтроятся грандиозные стратегические планы, рисуется большой “фиче-лист”. По мере разработки этот список свободно корректируется, дополняется и расширяется. Если темпы разработки все-таки успевают догнать и перегнать темп генерации новых идей раньше чем у команды закончятся деньги, то собранное воедино “поделие” оказывается совершенно непригодным: функциональные элементы не согласованы и слабо сочетаются друг с другом в единый user experience; “юзабилити” — на нуле; при всем видимом богатстве возможностей, пользователь совершенно не понимает чем себя занять, и как это все пойдет ему на пользу. В результате, когда проект выходит на финишную прямую, становится ясно, что запускать продукт в таком виде нельзя.
Парочка примеров из практики, чтобы не быть голословным.
Каков же рецепт успешного проекта? Не трудно догадаться, что наиболее высокой вероятностью стать успешным обладает продукт, развивающийся по первому сценарию. Тем не менее, чтобы не обрести коммерчески успешный, но технологически несостоятельный проект, нужно принять неколько компромиссов, которые готовы соблюдать как сотрудники техотдела, так и представители коммерции.
Почему в этой статье нет примеров технически успешного, работающего проекта? Такие в природе крайне редко встречаются. Если продукт действительно работает и зарабатывает деньги, в нем всегда будут проблемы: большое количество срочных задач, недостаток рабочих рук для их решения, криво запрограммированные модули и стойкое желание программистов все переписать с нуля, ежедневно возникающие баги, месяцами ожидающие своей очереди, отказы в обслуживании, кризисы коммерческого характера, требующие быстро-быстро что-нибудь подпилить за полдня. Все это команде придется каждый день разгребать, и при этом как-то успевать развивать продукт.
После успеха предыдущей нашей публикации, мы долго думали, кого попросить написать следующую статью — кто будет тем, кому придется спорить за популярность со статьей про секс. Выбор пал на технического директора 404Group Романа Друзягина, который расскажет про запуск проекта с точки зрения «технички».
«Про “старт-апы”, их начало, развитие и окончание не написал разве что только совсем ленивый человек, настолько эта тема актуальна и популярна. Проекты появляются и исчезают десятками каждый день, что наглядно позволяют увидеть сервисы, подобные Kickstarter. Отдавая дань моде, хочу поделиться некоторым опытом и взглядом на рынок “старт-апов”, сформировавшимся в результате многолетней деятельности по запуску и выращиванию Интернет-проектов в стенах нашей компании. Многие из этих проектов ждал печальный исход, причем, нередко еще на самом старте.
Материал, представленный в этом очерке, не претендует на звание истины, но хорошо отображает реальную ситуацию в среднестатистическом “старт-апе” и типичные проблемы, которые в нем возникают. Поскольку я являюсь представителем технической профессии, то и взгляд мой будет именно с позиции “технички”. Что обычно делают правильно и не правильно, и к каким результатам для проекта это может привести в последствии?
Вместо лирического отступления
Компания 404 Group и люди, ее учреждающие, занимаются инвестированием в Web-проекты уже с добрый десяток лет. В 70% случаев идея придумывается внутри представителями “правящей верхушки” и запускается в развитие. Остальные 30 процентов приходится на перспективные продукты, которые мы приглашаем сотрудничать к нам в организацию. Не важно, каким из двух путей проект оказывается в стенах компании, дальше игра ведется на равных.
У проекта есть команда (“технари” и “менеджеры”) во главе с одним-двумя руководителями, которые целиком и полностью отвечают за выставляемые проекту цели. В обмен, компания предлагает команде все свои ресурсы: финансовые инвестиции в оговоренных ключевыми участниками размерах, офисные удобства с печеньками и приставками, операционную поддержку (финансисты, юристы, секретари, HR и другие специалисты), технические компетенции (опытные инженеры, DBA, системные администраторы) и другие мощности, которые у компании имеются для реализации проекта.
По какому пути развития пойдет проект и будет ли он успешен, уже зависит от его команды. За годы практики удалось выделить несколько типовых сценариев, по которым развивается тот или иной продукт. С опытом мы научились, насколько это возможно, корректировать курс движения проекта, если мы видим, что он вступил на “скользкую дорожку”. А некоторые и вовсе не берем под крыло компании как заведомо проигрышные “черные дыры”, в которые деньги и иные ресурсы будут только утекать.
Три типичных сценария развития “старт-апа”
Сценарий №1, наиболее перспективный: проект ориентируется на результат, придерживается философии “ship fast & often” или, выражаясь более привычным языком, “х**к и в продакшн”. Приверженцы такого подхода стремятся максимально быстро вывести на рынок работающий продукт, начать его активно развивать и улучшать, основываясь на обратной связи от потребителей. В проекте крайне редко применяются специфические методологии или способы разработки. Нанимаются разработчики с приемлемым уровнем компетентности, а работа над “фичами” происходит по принципу внезапной постановки “немедленных” задач, которые желательно сделать ко вчерашнему дню. Такая модель является максимально жизнеспособной, посколько с наибольшей долей вероятности обеспечивает возможность продемонстрировать учредителям реальные рост и развитие, осуществляемые на их деньги. Ключевая проблема такого сценария — недостаточно внимательное отношение к качеству продукта, что может привести к серьезным рискам, угрожающим проекту в целом.
Сценарий №2: проект ориентируется на качество. Такие проекты делаются программистами, которым надоедает быть наемным исполнителем и хочется попробовать сделать что-то свое. Начинание благородное, но очень часто уставший от постоянной борьбы с “багами” и рутиной специалист принимает крайне опасное для проекта решение все учесть и предусмотреть заранее. Много времени уделяется правильной архитектуре, и недостаточно — проработке коммерческой составляющей, а именно, как проект будет приносить деньги.
В Web-проектах учесть все практически невозможно. Стремясь решить эту задачу, команда не замечает полной растраты инвесторских денег, и проект бесславно погибает. Многолетний опыт подсказывает, что творчески настроенный менеджер способен придумать задачу, которая настолько перпендикулярна текущему состоянию архитектуры, что для ее внедрения потребуются недели, а то и месяцы переделок. Понятное дело, что на практике приходится к прибегать менее приятным методам и жертвовать качеством в угоду скорости.
Сценарий №3: проект ориентируется непонятно на что. Такие проекты часто являются мертворожденными еще на старте. У людей, его придумавших, в головах имеется непонятная каша из технологических и коммерческих идей, которая не выстраивается во что-то конкретное. Cтроятся грандиозные стратегические планы, рисуется большой “фиче-лист”. По мере разработки этот список свободно корректируется, дополняется и расширяется. Если темпы разработки все-таки успевают догнать и перегнать темп генерации новых идей раньше чем у команды закончятся деньги, то собранное воедино “поделие” оказывается совершенно непригодным: функциональные элементы не согласованы и слабо сочетаются друг с другом в единый user experience; “юзабилити” — на нуле; при всем видимом богатстве возможностей, пользователь совершенно не понимает чем себя занять, и как это все пойдет ему на пользу. В результате, когда проект выходит на финишную прямую, становится ясно, что запускать продукт в таком виде нельзя.
Парочка примеров из практики, чтобы не быть голословным.
- Пример №1: крупная рекламная сеть
Это была честная и хорошая попытка сделать успешный продукт, который при этом будет технологически качественным и избавленным от проблем, имевшихся в других проектах компании, достигших коммерческого успеха. На старте наняли несколько высококвалифицированных инженеров, купили много серверов, придумали архитектуру, больше полугода “пилили” и готовились к старту.
На практике получился серьезный over-engineering, который обязал команду поддерживать сложную многозвенную архитектуру практически на каждой задаче. Особенно критичным это стало в тот момент, когда мы поняли, что темп решения в таких условиях неприемлим, и мы банально не в состоянии угнаться за конкурентами. У них, в собранной “на коленке” системе интеграция партнера занимает полндя, у нас — половина недели, в лучшем случае. Гонка была проиграна, проект был закрыт. - Пример №2: маленькая, но гордая социальная сеть
На старте: желание сделать что-то большое и светлое. В силу специфики способы монетизации не обозначены конкретно. Нанятые самые отважные и смелые самураи, составлен глобальный “фиче-лист”. На практике: разброд и шатание, “фичелист” растет, архитектура проекта существует исключительно в голове архитектора, на любые вопросы идет ответ, что “все очень сложно”, идут месяцы, из реальных показателей крутится еле-еле работающая регистрация.
Спустя полгода такой работы, состав разогнан, привлечены нормальные инженеры из числа экспертов головной компании, система спроектирована за 2-3 недели и собрана за несколько месяцев по замороженному “фичелисту”. Нужны эти “фичи” или нет, уже никто не думает, важно собрать и показать, учредители крайне недовольны. На выходе — продукт, который не согласован и преисполнен функциями, слабо связанными между собой, что катастрофично для социальной сети. Еще 3 месяца уходит на повторное проектирование UI, модификации и правки. Проект выпущен, работает, но “выхлоп” нулевой из-за слабо отработанной коммерческой стратегии. Итог: проект заморожен.
Каков же рецепт успешного проекта? Не трудно догадаться, что наиболее высокой вероятностью стать успешным обладает продукт, развивающийся по первому сценарию. Тем не менее, чтобы не обрести коммерчески успешный, но технологически несостоятельный проект, нужно принять неколько компромиссов, которые готовы соблюдать как сотрудники техотдела, так и представители коммерции.
- Компромисс №1: выбор и эксплуатация технологий
Прежде всего, не имеет значения, какие технологии (языки программирования, СУБД, сервера приложений, Web-сервера и проч.) и методологии вы используете. Нужно выбирать экономически выгодные решения. Что-то популярное и традиционное (PHP, MySQL/PostgreSQL) обеспечивает возможность найма из широкого пула кандидатов по приемлимым ценам. Вы конечно можете написать ваше приложение на Erlang, но потом замучаетесь искать адекватного специалиста, который не просит при этом запредельные деньги.
Во-вторых, очень важно эксплуатировать выбранные технологии и методологии системно. Не поленитесь завести правила и guidelines по написанию и структурированию кода, оформлению комментариев. Введите практику code review и заставляйте ваших программистов системно выдерживать эти требования. Успех проекта заключается не в правильной архитектуре (которая все равно в какой-то момент станет неправильной), а в системности его поддержки командой. Когда все программисты пишут код в едином стиле, затраты на вникание программиста в суть задачи, написанной другим разработчиком, сильно снижаются, что в целом увеличивает эффективность работы техотдела в разы. Не пренебрегайте правилами и регламентами, они являются чуть ли не самым важным аспектом процеса разработки.
И никогда-никогда не слушайте отговорки программистов о том, что они не могут писать аккуратный код в быстром темпе. Это абсурдное заявление и признак лени или некомпетентности. Стилистическое оформление и культура кодирования — это тренируемый навык, у хороших программистов присутствующий на уровне мышечной памяти. Тренируйте своих программистов и позволяйте им расслабляться. - Компромисс №2: отказ от универсальности
Следующим неотъемлимым компромиссом является сознательный отказ делать универсальную архитектуру. Как говорил один мой коллега, никогда не удавалось застать тот момент, когда очередной проект переходит из состояния „сразу сделать все правильно“ в состояние „изначально все было сделано неправильно“. Это неизбежно, и вы с этим столкнетесь. Примите тот факт, что в вашем проекте будут неоптимальные решения и “костыли”.
Придумайте, как ни парадоксально это звучит, регламент внедрения таких решений, документируйте их. Как правило, именно такими решениями реализуется самая критичная для бизнеса логика. Наличие такой документации в разы более ценно, чем красивые комментарии в коде, автоматически преобразуемые каким-нибудь инструментом в красивую HTML-страницу с документацией по методам класса. Их никто никогда не читает. А, поскольку в интенсивно развивающемся проекта поддерживать 100% документацию практически невозможно, сразу правильно направьте усилия ваших программистов и требуйте описывать те проблемы, которые действительно того требуют. - Компромисс №3: забота о безопасности
Практика показывает, что даже самые опытные программисты частенько имеют очень поверхностные представления о безопасности Web-продукта. Какие существуют типовые векторы для атак и как их может эксплуатировать злоумышленник? Как от них обезопаситься? Как правильно работать с базой данных, чтобы избежать потери или кражи информации? Разработчик может не знать ответы на эти вопросы или же не уделять им должного внимания, поскольку для программиста самым ключевым аспектом выполняемой работы является его код.
На самом деле, самым важным ресурсом любого Интернет-проекта являются данные. Техотдел о них не думает, потому что код — это ядро системы, а представители коммерции не думают, потому что обладают ограниченными техническими компетенциями и голова у них болит по другим поводам. Понимание и осознание важности данных появляется в тот момент, когда ресурс подвергается атаке со стороны конкурентов, как в том печальном анекдоте про админов, которые еще не делают “бекапы” и уже их делают.
Убедитесь, что в вашей команде есть хотя бы один человек (крайне желательно, занимающий позицию технического лидера), который донесет это до всей команды, выработает нужные практики написания безопасного кода, будет контролировать их системное поддержание, наладит правильную процедуру резервирования и проверки восстановления данных. Я неоднократно наблюдал успешные проекты, которые “взламывали” с помощью крайне тривиальных уязвимостей. Целенаправленный аудит совершенно разных продуктов выявлял однотипные проблемы: отсутствие фильтрации входных параметров, незащищенные формы для загрузки изображений и др. Это все — банальные глупости, которые можно предотвратить, только осознанно лишь уделяя внимание вопросу безопасности.
Запомните, данные — важнее чем код! Код можно написать новый, а потерянные данные так просто уже не собрать.
Подводя итоги
Почему в этой статье нет примеров технически успешного, работающего проекта? Такие в природе крайне редко встречаются. Если продукт действительно работает и зарабатывает деньги, в нем всегда будут проблемы: большое количество срочных задач, недостаток рабочих рук для их решения, криво запрограммированные модули и стойкое желание программистов все переписать с нуля, ежедневно возникающие баги, месяцами ожидающие своей очереди, отказы в обслуживании, кризисы коммерческого характера, требующие быстро-быстро что-нибудь подпилить за полдня. Все это команде придется каждый день разгребать, и при этом как-то успевать развивать продукт.