- PVSM.RU - https://www.pvsm.ru -
Доброго всем времени суток!
После успеха предыдущей нашей публикации, мы долго думали, кого попросить написать следующую статью — кто будет тем, кому придется спорить за популярность со статьей про секс. Выбор пал на технического директора 404Group Романа Друзягина, который расскажет про запуск проекта с точки зрения «технички».
«Про “старт-апы”, их начало, развитие и окончание не написал разве что только совсем ленивый человек, настолько эта тема актуальна и популярна. Проекты появляются и исчезают десятками каждый день, что наглядно позволяют увидеть сервисы, подобные Kickstarter. Отдавая дань моде, хочу поделиться некоторым опытом и взглядом на рынок “старт-апов”, сформировавшимся в результате многолетней деятельности по запуску и выращиванию Интернет-проектов в стенах нашей компании. Многие из этих проектов ждал печальный исход, причем, нередко еще на самом старте.
Материал, представленный в этом очерке, не претендует на звание истины, но хорошо отображает реальную ситуацию в среднестатистическом “старт-апе” и типичные проблемы, которые в нем возникают. Поскольку я являюсь представителем технической профессии, то и взгляд мой будет именно с позиции “технички”. Что обычно делают правильно и не правильно, и к каким результатам для проекта это может привести в последствии?
Компания 404 Group и люди, ее учреждающие, занимаются инвестированием в Web-проекты уже с добрый десяток лет. В 70% случаев идея придумывается внутри представителями “правящей верхушки” и запускается в развитие. Остальные 30 процентов приходится на перспективные продукты, которые мы приглашаем сотрудничать к нам в организацию. Не важно, каким из двух путей проект оказывается в стенах компании, дальше игра ведется на равных.
У проекта есть команда (“технари” и “менеджеры”) во главе с одним-двумя руководителями, которые целиком и полностью отвечают за выставляемые проекту цели. В обмен, компания предлагает команде все свои ресурсы: финансовые инвестиции в оговоренных ключевыми участниками размерах, офисные удобства с печеньками и приставками, операционную поддержку (финансисты, юристы, секретари, HR и другие специалисты), технические компетенции (опытные инженеры, DBA, системные администраторы) и другие мощности, которые у компании имеются для реализации проекта.
По какому пути развития пойдет проект и будет ли он успешен, уже зависит от его команды. За годы практики удалось выделить несколько типовых сценариев, по которым развивается тот или иной продукт. С опытом мы научились, насколько это возможно, корректировать курс движения проекта, если мы видим, что он вступил на “скользкую дорожку”. А некоторые и вовсе не берем под крыло компании как заведомо проигрышные “черные дыры”, в которые деньги и иные ресурсы будут только утекать.
Сценарий №1, наиболее перспективный: проект ориентируется на результат, придерживается философии “ship fast & often” или, выражаясь более привычным языком, “х**к и в продакшн”. Приверженцы такого подхода стремятся максимально быстро вывести на рынок работающий продукт, начать его активно развивать и улучшать, основываясь на обратной связи от потребителей. В проекте крайне редко применяются специфические методологии или способы разработки. Нанимаются разработчики с приемлемым уровнем компетентности, а работа над “фичами” происходит по принципу внезапной постановки “немедленных” задач, которые желательно сделать ко вчерашнему дню. Такая модель является максимально жизнеспособной, посколько с наибольшей долей вероятности обеспечивает возможность продемонстрировать учредителям реальные рост и развитие, осуществляемые на их деньги. Ключевая проблема такого сценария — недостаточно внимательное отношение к качеству продукта, что может привести к серьезным рискам, угрожающим проекту в целом.
Сценарий №2: проект ориентируется на качество. Такие проекты делаются программистами, которым надоедает быть наемным исполнителем и хочется попробовать сделать что-то свое. Начинание благородное, но очень часто уставший от постоянной борьбы с “багами” и рутиной специалист принимает крайне опасное для проекта решение все учесть и предусмотреть заранее. Много времени уделяется правильной архитектуре, и недостаточно — проработке коммерческой составляющей, а именно, как проект будет приносить деньги.
В Web-проектах учесть все практически невозможно. Стремясь решить эту задачу, команда не замечает полной растраты инвесторских денег, и проект бесславно погибает. Многолетний опыт подсказывает, что творчески настроенный менеджер способен придумать задачу, которая настолько перпендикулярна текущему состоянию архитектуры, что для ее внедрения потребуются недели, а то и месяцы переделок. Понятное дело, что на практике приходится к прибегать менее приятным методам и жертвовать качеством в угоду скорости.
Сценарий №3: проект ориентируется непонятно на что. Такие проекты часто являются мертворожденными еще на старте. У людей, его придумавших, в головах имеется непонятная каша из технологических и коммерческих идей, которая не выстраивается во что-то конкретное. Cтроятся грандиозные стратегические планы, рисуется большой “фиче-лист”. По мере разработки этот список свободно корректируется, дополняется и расширяется. Если темпы разработки все-таки успевают догнать и перегнать темп генерации новых идей раньше чем у команды закончятся деньги, то собранное воедино “поделие” оказывается совершенно непригодным: функциональные элементы не согласованы и слабо сочетаются друг с другом в единый user experience; “юзабилити” — на нуле; при всем видимом богатстве возможностей, пользователь совершенно не понимает чем себя занять, и как это все пойдет ему на пользу. В результате, когда проект выходит на финишную прямую, становится ясно, что запускать продукт в таком виде нельзя.
Парочка примеров из практики, чтобы не быть голословным.
На практике получился серьезный over-engineering, который обязал команду поддерживать сложную многозвенную архитектуру практически на каждой задаче. Особенно критичным это стало в тот момент, когда мы поняли, что темп решения в таких условиях неприемлим, и мы банально не в состоянии угнаться за конкурентами. У них, в собранной “на коленке” системе интеграция партнера занимает полндя, у нас — половина недели, в лучшем случае. Гонка была проиграна, проект был закрыт.
Каков же рецепт успешного проекта? Не трудно догадаться, что наиболее высокой вероятностью стать успешным обладает продукт, развивающийся по первому сценарию. Тем не менее, чтобы не обрести коммерчески успешный, но технологически несостоятельный проект, нужно принять неколько компромиссов, которые готовы соблюдать как сотрудники техотдела, так и представители коммерции.
Почему в этой статье нет примеров технически успешного, работающего проекта? Такие в природе крайне редко встречаются. Если продукт действительно работает и зарабатывает деньги, в нем всегда будут проблемы: большое количество срочных задач, недостаток рабочих рук для их решения, криво запрограммированные модули и стойкое желание программистов все переписать с нуля, ежедневно возникающие баги, месяцами ожидающие своей очереди, отказы в обслуживании, кризисы коммерческого характера, требующие быстро-быстро что-нибудь подпилить за полдня. Все это команде придется каждый день разгребать, и при этом как-то успевать развивать продукт.
Автор: Johhhney
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/93370
Ссылки в тексте:
[1] Источник: http://megamozg.ru/post/17150/
Нажмите здесь для печати.