Владимир: Егор, привет.
Егор: Всем привет.
Владимир: Как обычно начинается стартап? Я так понимаю, твой тезис в том, что необходимо разработку отдавать на аутсорсинг, а не строить внутри команды?
Егор: Мой тезис, во-первых, в том, что разработчиков нужно сразу много, потому что мы наблюдаем такую картину на многих континентах, во многих странах (мы работаем на несколько рынков). Во многих странах одна и та же идея начинает взрастать абсолютно в разных командах, ее разрабатывают разные люди без какой-либо связи между собой. И бывает так, что мы видим одновременно 5-6 проектов, которые начинаются одновременно.
Владимир: Очень похожих проектов, да?
Егор: Да, и поэтому те люди, у которых есть «карманный» разработчик, или когда разработчик сам начинает стартап, сразу проигрывают в скорости, потому что у них просто не хватает мощностей. Если вы реально верите в идею, если есть стартап, который вы можете поставить, то стоит нанять команду профессионалов для того, чтобы быть первым, выиграть в скорости, не теряя в качестве. Потому что вам нужно будет поддерживать этот темп еще долгое время. Сейчас мы живем в таком мире, что любая идея, любой программный продукт очень быстро меняется, он должен адаптироваться к рынку. Поэтому даже после того, как вы выпустили проект на рынок, вам нужно какое-то время (довольно длительное) еще гнаться, бежать в том же темпе, для того, чтобы адаптироваться к изменениям, ведь гипотезы, которые вы выдвигаете в самом начале, не всегда бывают верные.
Владимир: На 99 %, наверное?
Егор: Да, люди очень редко попадают с первого раза, и на это надеяться не стоит, энергии и запаса у вас должно сразу хватить на то, чтобы не только выйти в рынок, но и стать там конкурентными, успешными и выйти в безубыточность.
Владимир: Здесь есть сразу несколько «но» с точки зрения экономики и экономии бюджета. Люди думают, что, во-первых, сторонняя разработка будет намного дороже и, во-вторых, когда ты отдаешь что-то сторонним разработчикам, многие считают, что с этой командой нужно будет работать всегда, с ними уже не попрощаться.
Егор: Не совсем так. Начну с первого: сторонняя разработка намного дороже. Есть очень интересный график, его часто показывают на разных IT-конференциях, нишевых программах. Это график зависимости стоимости исправления ошибки от времени, за которое она была найдена. Если вы исправляете ошибку на этапе проектирования, она вам стоит 10 центов, если вы исправляете после релиза, когда уже продукт вышел к пользователям, то она вам стоит 10000 долларов. Это очень быстрорастущий график, поэтому, когда вы начинаете что-то сами, у вас очень высок риск, что большую часть этих вещей вы сделаете неправильно, и эти ошибки потом исправлять будет больнее. Опять же, если ваш продукт выстрелит. Если вы заранее не верите, что продукт выстрелит, то это правило не действует.
Владимир: Если ты отдаешь аутсорс разработки какой-то команде, есть мнение у людей, которые занимаются проектами, стартапами и разработкой, что потом от этой команды никуда не деться, придется с ней всю жизнь идти. И они должны это поддерживать, потому что тебе самому не разобраться в коде, который написал чужой разработчик, так ли это?
Егор: Это так. На уровне разработчиков есть джуниор, мидл и синьор. На уровне джуниор и мидл это действительно так, людям сложно копаться в чужом коде. Чаще всего к вам приходит новая команда и говорит, что все будет переписывать на свой язык. По-другому просто нельзя, и они вас в этом смогут убедить. Но на самом деле ситуация несколько иная, потому что в большинстве продуктов, которые реально развиваются, у которых есть рынок, и они выходят в плюс, срок жизни любого кода небольшой – 3-5 лет. За это время продукт полностью перерабатывается, особенно молодые продукты, которым не так много лет. Поэтому важен не сам код и наследие, которое вы получили от предыдущей команды разработчиков, а способность вашей команды быстро менять ваш продукт вместе с его кодом – под меняющийся рынок, под ваши новые амбиции, новые цели, маркетинговые гипотезы. Вне зависимости от того, где и как вы разработали первую часть продукта, ваша команда инхаус должна быть способна переработать его в ноль за три года. Иначе вы будете терять большое количество времени и денег, ведь сейчас разработка инхаус– не самая дешевая история. Минимальная команда стоит примерно 1 млн. в месяц. В этом отношении вы будете просто терять деньги. Команда должна работать быстро с любым кодом – чужим или вашим.
Владимир: Я делаю один образовательный проект - это видеообразование от знаменитостей. Конечно, в идеале хотелось бы к себе привлечь технического специалиста, который будет курировать разработку нашего продукта. Как ты считаешь, это правильный подход или нужно нанять студию или вашу команду для того, чтобы они сделали MVP, то есть минимальный продукт, который будет жизнеспособен, и дальше уже думать о приеме человека в команду со-основателей?
Егор: Да, наверное, мы не обойдемся без саморекламы, потому что если говорить про типовые студии и про типовую студийную разработку конвейерную, естественно, ответ – стоит! Стоит взять к себе в команду со-основателя, стоит взять технического директора, стоит держать это под контролем, потому что те люди, которые работают над вашим проектом, по сути, не вовлечены в него ни морально, ни духовно. Они приходят на работу и им не важно, какой проект делать - ваш или чужой. Есть студии, как наша, которые пошли по иному пути. Студии, которые дают не разработку по принципу times in material, то есть не продают часы-разработку, а которые продают команду, формируют и сопровождают проект целиком.
Владимир: На корпоративы приглашают ваших разработчиков, которые сидят в другом офисе?
Егор: Да, пригласили в Бразилию на корпоратив, но люди, к сожалению, не были способны вовремя туда добраться. В этом отношении такой подход гораздо более эффективный, то есть вы получаете студийную разработку с большим опытом и количеством наработок, с высокой скоростью, кроме этого вы получаете команду, заинтересованную в вашем продукте, как в своем, и в этом случае технический директор абсолютно не нужен.
Владимир: Давай поговорим о подходе к разработке, особенно на подходе стартапов к разработке. Насколько важно быстро тестировать и делать разработку?
Егор: Колоссально отличаются разработки и стартапы у крупных корпоратов или среднего бизнеса. Стартап живет в условиях сильных неопределенностей. Они не знают, какая из их идей реально подтвердится рынком, какая понравится пользователям, поэтому скорость проверки этих гипотез должна быть максимальная. В этом отношении типовой подход к разработке, который используют корпорации, студии, combain разработка, когда задача проектируется довольно длительное время, потом разрабатывается, тестируется, принимается и только потом выходит – в этом отношении неприемлема для стартапа, потому что теряется время, деньги, теряется конкурентное преимущество. Я сторонник того, что для любых стартапов необходимо использовать гибкие методики разработки – такие, как Scrum. Это поход, при котором формируется проектная команда из эрудированных подготовленных людей, каждый из которых в состоянии самостоятельно решать свои задачи, у них коллективно ставится основная задача – успешно выпустить определенную функциональность проекта на рынок, чтобы она понравилась пользователям, отвечала каким-то базовым функциональным требованиям. Но в первую очередь чтобы получить feedback (обратную связь), очень быстро на основе этого приступить к следующей итерации. Это итеративный подход к разработке, где короткими этапами разрабатываются огромные по масштабу продукты вне зависимости от того, насколько ваш продукт сложный, насколько много в нем задействовано сервисов, насколько сложная у него архитектура. Любой проект можно разделить на этапы, любую задачу можно декомпозировать. Такой подход позволит вам не уйти далеко в своих затратах по неверному пути, не сделать и не потратить деньги на что-то, что встретят пользователи не так, как вам бы хотелось. Это позволит делать короткими шагами только то, что нравится вашим пользователям, только то, что принесет вам деньги этих пользователей и окупит ваш продукт.
Владимир: Я правильно понимаю, что в рамках такого подхода очень много изменений налету. Насколько это подходит для аутсорс разработки, ведь люди не рядом и у вас есть технические задания, договора и т.д. Насколько гибко это можно делать с вами?
Егор: Мы целиком решили этот вопрос. У нас представитель заказчика и его команда являются частью проектной команды, которая формируется для производства. Они постоянно вовлечены на каждой итерации, на планировании, демонстрационных митингах. Они все вместе участвуют, обсуждают. Начиная от дизайнеров и разработчиков, заканчивая инвесторами проектов – все высказывают своевременно свои замечания. Самое главное, что наш подход не совсем наш, приписывать его себе было бы слишком оптимистично, этот подход позволяет быстро показать людям, которые уверены в своей правоте и могут увести проект «не туда» в какое-то время, негативную реакцию пользователей на эти идеи. В противном случае, при типовом подходе очень часто бывает ситуация из-за того, что какой-то участник команды очень сильно продвигает свою идею, и она потом оказывается неэффективной, деньги потом уходят в трубу.
Владимир: Многие люди идут по пути фрилансеров. Даже люди из СНГ бывшего.
Егор: По пути найма фрилансеров?
Владимир: Да, по пути найма фрилансеров. Это дешево, нормальные портфолио, удобная оплата при помощи WebMoney, KIWI-кошелька или биткоина. Почему ты считаешь, что это не подходящий вариант?
Егор: Это идеальные люди. Им можно вообще не платить. Я сейчас расскажу одну историю. Я очень часто за свою жизнь обращался к фрилансерам, и один раз у нас был проект, у которого действительно горели сроки, нужно было сдать вовремя. Так получилось, что разработчик пропадает, и нам необходимо обратиться к фрилансерам, чтобы закрыть этот проект, но риски были колоссальные. Мы понимали, что нам нужно срочно сдать его в срок – проект был достаточно большой. Мы обратились не к одному фрилансеру, мы наняли 23.
Владимир: Как быстро вы их наняли?
Егор: Это несложно при наличии большого количества площадок и довольно оперативном подходе. К концу проекта осталось три человека, каждый из которых сделал порядка 60% проекта. Из этих кусков мы собрали 100 %. Все остальные просто исчезли, у них сломалась кошка, заболела нога.
Владимир: Это самое популярное: отключили электричество, сломалась нога…
Егор: Да, сразу везде. И это, по-моему, очень хороший пример, который идеально иллюстрирует суть фриланса. Если сроки вообще не важны, вы можете обращаться к такого рода исполнителям, но когда речь идет о быстром темпе, когда нужно быстро предоставить конкурентное решение для выхода на новый этап инвестиций, для выхода в рынок, – это абсолютно неприемлемо, потому что один к двадцати, что ваши сроки выполнят. И в этом отношении люди должны сидеть только в офисах.
Владимир: У вас все инхаус?
Егор: Да, у нас есть региональные офисы в Краснодаре, в Новороссийске. Люди сидят в офисах, они всегда на связи. Когда проектная команда большая, там не получается схалтурить, ты всегда на виду. У тебя каждый день митинги, каждый день тебя спрашивают, какие проблемы, что случилось, что ты будешь делать завтра. Ты не можешь ответить на этот вопрос, если у тебя ничего не сделано за прошедший день. В этом отношении мы очень много внимания уделяем такого рода контролю, чтобы люди не пропадали, не провисали, чтобы не было дней у людей, когда они просто ничего не делали. Они все время должны быть в темпе, в каком-то режиме, дисциплина очень важна в этом отношении, потому что быстрая разработка требует высокого уровня дисциплины.
Владимир: Как ты относишься к разработке на дому? Многие компании это практикуют, когда сотрудники получают зарплату, трудовая книжка лежит в компании, но работают удаленно.
Егор: Очень здорово. У нас в компании и в других компаниях, в которых я работал, практикуется такая история. Единственное, что когда проект действительно интересный, разработчики и специалисты сами не хотят работать дома, им интересно прийти и обсудить его. Быть в коллективе. Если проект живет, проект горячий, его интересно делать. Мы стараемся формировать команды только из тех людей, которым интересен данный проект. В этом случае они сами стремятся в офисы, не хотят работать дома, только если им не пришлось переехать в другую страну или другой город.
Владимир: Если у команды, которая запускает стартап, нет большого опыта в запуске диджитал продуктов, как быть?
Егор: В этом отношении в продуктовой команде, которая занимается развитием вашего продукта, обязательно должен быть этот человек. Он по-разному называется в разных методологиях. В Scrum он называется Product owner – это человек, который представляет интересы ваших будущих пользователей. Дело в том, что это действительно самый важный человек в проекте, потому что только от реакции ваших пользователей на ваш продукт зависят будущие финансовые показатели, любые другие показатели, которые вы закладываете в свой стартап как основные. Если такого человека с самого начала развития продукта нет, то, когда проект выйдет на рынок, вы получите очень много негатива. Этот человек – самый важный и главный человек в проекте.
Владимир: Это только про UX и UA?
Егор: Начиная с UX и UA и заканчивая любыми другими метриками, которые позволяют вашим пользователям быстро найти продукт, быстро найти документацию по нему, быстро разобраться, для чего он нужен. Это человек, который отвечает за все – от привлечения до ретеншн.
Владимир: Насколько полно должен принимать участие маркетолог, который дальше будет продвигать продукт, в начале и в разработке?
Егор: В первую очередь это человек, который отвечает за ретеншн (это возврат пользователей), чтобы они лояльно относились к вашему продукту, потому что, когда вы привлекаете пользователей, у них еще нет продукта. Вы привлекаете их не продуктом, а чаще всего рекламой, какими-то статьями. В «Пиратах Карибского моря» он говорит: «У меня нет ключа, у меня есть рисунок ключа». Вот вы привлекаете пользователя рисунком ключа, а не самим ключом. Поэтому для того, чтобы привлекать пользователей, не нужно сильно разбираться в продукте. Но обязательно человек должен быть в команде, должен знать обо всех фичах, которые разработаны, уметь грамотно о них рассказать пользователю. Владелец продукта – это человек, у которого больше продуктовое мышление, он думает, как пользователи лучше воспримут продукт, лучше про него расскажут, какая будет продуктовиральность. Потому что у стартапов, которые имеют высокую виральность, есть все перспективы. В этом отношении, если вам удастся найти точку, где ваш продукт станет виральным, и своевременно разработать необходимую функциональность – это даст колоссальную экономию на дальнейших этапах.
Владимир: Как правильно подойти к разработке, ничего не забыть и получить хороший результат?
Егор: Во-первых, стоит обратить внимание на то, какая у вас длина итерации и насколько быстро вы получаете обратную связь от пользователей. Конечно же, есть продукты, которые вы технически не сможете выпустить, пока не будет минимального функционала, и это может занять какое-то время (3-6 месяцев) в зависимости от сложности продукта, но чаще всего любой продукт через 2 месяца после начала разработки должен выйти к людям. Они должны сказать первое «фи», и вы уже на основании этого должны продолжать разрабатывать. Еще более важны итерации, когда у вас аутсорс-команда, потому что вы сами должны видеть, что происходит, как можно чаще давать обратную связь, потому что идея во всей полноте находится только у вас в голове. Для того, чтобы передать эту идею, многие приступают к написанию длинных ТЗ, большого количества документации. Они думают, что если мы напишем 120 страниц документации – все будет хорошо, все прочитают и сразу поймут. Но нужно понимать, что это документация не реального проекта, а того, что у вас в голове. Реальный проект может быть совсем другим, и он понравится пользователю, если будет хорошая конкурентоспособность. Это будет другой продукт, не такой, как у вас в голове. И начинать менять его стоит гораздо раньше, до того, как вы его целиком прописали и даже спроектировали у себя в голове.
Владимир: То есть усложнять не стоит?
Егор: Да, усложнять не стоит. Маленькие шаги, короткие итерации. Вы находитесь в режиме колоссальной неопределенности. Чем чаще вы будете сверяться с картой, с окружающей средой, тем больше шансов, что вы придете туда, куда нужно.
Владимир: Как выбрать, по какому пути идти? Каким образом спланировать бюджет и времязатраты?
Егор: В общих чертах у вас должна быть продуктовая команда, единственная цель которой – выпуск и продвижение вашего продукта, качественного продукта на рынок. Еще лучше, если эта команда является частью еще большей технической компании, например, студии, у которой есть большое количество наработок. У многих студий есть для большей части проектов уже 60-70% готового кода. Это значит, что вы экономите эти деньги и время. Если у вас есть собственная команда, выделенная под вас, и она является частью чего-то большего, с большой технической поддержкой, есть все шансы стать будущим единорогом.