Прототип — убийца IT-стартапов

Suicide-Bunny-Death-HD

Источник картнки

В разных командах, в разных стартапах (и не только) мне много раз встречалась ситуация, когда техническая часть разработки заходила в тупик. Причем по функционалу, графики, балансу все работает хорошо. Аудитории нравится, проект вроде бы идет к успеху но в какой-то момент ломается, захлебывается в потоке новых пользователей и, на этом его жизнь в лучшем случае мучительно тянется, превращаясь в череду исправлений и переработок, в худшем — заканчивается. Почему так происходит многим матерым инвесторам, у которых так сдох не один проект, наверное уже понятно. Но другим — еще нет и, самое страшное, что это совершенно непонятно самим стартаперам и их «фаундерам». Почему «фаундерам» в кавычках? Об этом я расскажу в этом посте.

Важно: далее по тексту я говорю не о всех 100% проектов. Бывают исключения, но они встречаются примерно так же часто, как и гениальные люди.

Фаундер и прототип

Нам нужен прототип!

Как часто приступают к разработке IT-продукта, будь то игра, приложение, сайт или что-то еще? Очень часто так: «Давайте сделаем прототип!» и «Нам нужен прототип, пощупать как оно будет!». Что происходит дальше? Дальше прототип работает. Его развивают, улучшают, дополняют фишками и функционалом. Прототип из прототипа становится уже проектом. Даже нет, не проектом, а Проектом. Проектищем! Его показывают заказчику, заказчик доволен, ведь работает! Не обманули хитрые стартаперы, делают, правильно деньги используют!

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

И все уже вроде как забыли, что на самом-то деле они развивают прототип. Я ничего против прототипа не имею, но давайте посмотрим, что же такое — прототип? Вики дает следующий ответ:

Прототипи́рование (англ. prototyping) — быстрая «черновая» реализация базовой функциональности для анализа работы системы в целом. После этапа прототипирования обязательно следуют этапы пересмотра архитектуры системы, разработки, реализации и тестирования конечного продукта.
Прототипирование, по мнению некоторых разработчиков, является самым важным этапом разработки. На этапе прототипирования малыми усилиями создается работающая система (возможно неэффективно, с ошибками, и не в полной мере). Во время прототипирования видна более детальная картина устройства системы. Применяется в машино— и приборостроениипрограммировании и во многих других областях.

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

 

Javad_alizadeh_surreal-Surreal_suicide

Отсутствие архитектуры стартапа

Часто окрыленная успешной работой прототипа не останавливается, не исследует досконально результат работы прототипа, не делает нагрузочное тестирование. Но, самое главное, никто не описывает архитектуру проекта. Зачем, ведь все и так работает! Просто добавь воды найми новых сотрудников и вперед, на завоевание мира! Если же архитектура есть в голове технического директора (или лид-программиста), то вообще все очень плохо: без внешнего воздействия она не будет написана и задокументирована никогда.

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

Безусловно, не исключены случаи, когда в вашей команде — гениальный программист и он сразу построил прототип как надо, который можно развивать дальше. Такое бывает. Но каковы шансы, что это ваш случай? Я бы оценил такую вероятность как крайне низкую. Цифр давать не буду на всякий случай, но, даже если вероятность 50 на 50 — вам нужны такие риски? Вы готовы построить свой бизнес, свой проект на словах незнакомого, часто — наемного человека, который ничего в общем-то не потеряет (работа не в счет, это вообще не проблема в наше время и в нашей индустрии)? Если готовы, то можете уже закрывать эту статью и проходить дальше.

 

snowman-suicide

Архитектура не задокументирована

Когда нет остановки и анализа, полноценная и подробная документация не пишется. Она сейчас кажется излишней, в одном разговоре даже была названа «ненужной бюрократией». Тут опять можно услышать слова типа «Зачем она нужна, если и так все работает? Давайте не тратить время и деньги инвестора и будем развивать то, что уже работает!». Мысль о том, что деньги и время будут таким образом как раз выброшены в мусорное ведро (или куда подальше и похуже) многим «фаундерам» в голову не приходит.

Про то, чем грозит отсутствие документации я писал ранее, поэтому повторю тут кратко и немного с другой стороны, с технически-управленческой. Когда приходят новые люди, обычно им надо понять, как что работает, как что устроено. В случае с программистами при отсутствии документации они могут узнать, как работает проект двумя способами: А) погрузиться в код и посмотреть, как что устроено; Б) вербально, общаясь с тем, кто его писал.

В случае А программист (или программисты) должен обладать способностью хорошо (именно хорошо, а не абы как) разбираться в чужом коде. Он должен обладать усидчивостью, упорством и высокой ответственностью для того, чтобы именно изучать код, а не читать, например, ЖЖ в это время. Кроме того, есть ли гарантии, что код хорошо задокументирован? Может ли прототип кода быть хорошо задокументирован, каковы шансы, что это — так? Я тоже поставил бы на то, что шансы невелики. Кроме того, разбор чужого кода требует много времени. Если он не задокументирован, то времени потребуется в разы больше. Думаю, что в некоторых случаях эта задача будет вообще не реализуемой без документации.

Вариант Б, в случае вербального общения с тем, кто писал прототип, тратится время и его, и новых программистов. Причем, каждый раз как будет нанят программист, это время будет тратиться заново. Снова и снова. В клинических случаях, введение в курс дела будет перекладываться на тех, кто уже немного разобрался в том, как все устроено и превратится в испорченный телефон. Шансы на то, что этот человек разобрался в архитектуре лучше того, кто ее создавал, каковы? Спросите себя, готовы ли вы поставить $5000 прямо сейчас на то, что в вашей команде так все и будет?

Тем временем новый сотрудник нанят и должен работать. Иногда он должен пройти испытательный период и выдать что-то полезное (или хотя бы показать, что он в деле). Обычный вариант развития событий — новый человек еще толком не понимает, что как работает, но начинает работать. Да, ему даются небольшие задачи, чтобы он «вошел в рабочий режим». Потом побольше, побольше и, постепенно, он разбирается в проекте и что как работает, становится полноценной честью команды… в идеале. В жестокой реальности он часто выдает говнокод код низкого качества, известный также как макароны. Потому что, опять же, делать надо, как делать — непонятно и снаружи может быть все хорошо и красиво, а внутри…

Здесь мы тоже можем проверить риски подхода «за борт и поплыли» задав следующие вопросы:

  1. Каковы шансы на то, что вы будете нанимать только таких программистов, которые идеально разбираются в чужом коде?
  2. Каковы шансы на то, что код, в котором им придется разбираться, легко понятен и хорошо задокументирован?
  3. Каковы шансы на то, что ваш собственный архитектор не запутался где-то по дороге и не превратил архитектуру в пастообразный набор символов?
  4. Каковы шансы на то, что ваш программист-архитектор хорошо и подробно передаст знания всем нанимаемым программистам?

Просто оцените шансы каждого пункта. Можно дальше будет даже не считать результирующие риски — и так будет все понятно.

 

"Фаундер"

Фотография «фаундера», пребывающего в розовом мире

Неумение осознать свои проблемы

Когда наступает час Х и релиза не случается, находятся очень важные и серьезные причины, почему так случилось. Называются самые разные вещи: сложность разработки, принятые по пути решения, требующие много времени, обстоятельства непреодолимой силы, болезни, отпуска, отключение электричества… Список этот бесконечен. Наверняка каждый инвестор его может легко дополнить еще сотней-другой подобных причин. Но на самом деле, за всеми этими причинами, кроются совсем другие: отсутствие документации, плана, макаронная архитектура, разрозненность команды. Но самая главная причина — это менеджмент и управление разработкой, которые привели к такому результату.

Здесь наступает самый страшный момент: решение как быть дальше. От этого решения зависит, на самом деле, дальнейшая жизнь проекта. Решений два: затягивать разработку, выклянчивать еще время и деньги из инвестора и тянуть резину, пока можно. Об этом я писал в предыдущей статье, «Менеджеры из Ада«. Тут я хочу привести цитату из одного обсуждения, спасибо моему боевому товарищу за великолепное и точное описание такого решения: «Это все равно, что ходить по пустыне, самому не зная куда и зачем».

Второе решение — «фаундер» будет честным с самим собой, командой и инвестором. Он проанализирует ситуацию объективно, признает свои ошибки, выделит основные проблемы в проекте. Далее он из «фаундера» попробует стать фаундером, если найдет решение, выработает план команда будет следовать этому плану. Если нужно остановиться, прекратить разработку и наконец-то создать архитектуру, выбросив, например, 60% кода — то он должен уметь это принять и не позволить развивать проект дальше (ведь тогда придется переписывать уже не 60% кода, а может 65% или 70%; чем дальше — тем больше). Еще он должен осознать, что текущая ситуация — это заслуга его и только его, что это есть результат его эффективного управления. Без понимания этого ничего не изменится и нужно такого «фаундера» менять (как это сделать — см. «Менеджеры из Ада«).

 

founder

Иллюстрация того, что надо делать с эффективным менеджером

Что делать и как с этим бороться

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

    1. Перед началом работы над прототипом иметь документацию, по которой будет создаваться прототип. Как ее писать и с чего начать, я писал тут;
    2. Перед началом работы иметь документацию по архитектуре проекта. Да, это значит, что программист-архитектор не должен ничего программировать вообще до тех пор, пока не будет описано то, как работает будущий проект, из каких сущностей состоит и как они взаимодействуют, какие требуются ресурсы и многое другое. Должны быть диаграммы взаимодействий сущностей, которые наглядно покажут всем, что должно получиться в итоге;
    3. Составить бэклог (список всех ключевых задач) проекта, а затем вместе сесть и разбить ключевые задачи на подзадачи. Сильная детализация тут не нужна, но такой план перед началом разработки должен быть. И не важно, какой это проект — стартап с нуля, или уже в разработке и нужно нормализовать/улучшить его работу;
    4. Обсудить с командой (если она есть) предлагаемую архитектуру и выяснить все риски, задавая программисту неудобные вопросы. «Что будет, если ты вдруг уволишься?», «Что будет, если вдруг придет 1000 человек сразу?», «Какие потребуются специалисты в течение года и какие задачи они будут выполнять?» и так далее. Если программист «плывет», не может четко и быстро ответить на подобные вопросы, отправлять его на доработку предлагаемой архитектуры и поиск ответов на заданные вопросы.

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

 

Напоследок

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

Как обычно, комментарии, вопросы, замечания об ошибках и опечатках приветствуются. Да, и я честно старался сделать эту статью не такой большой, как некоторые предыдущие; вроде бы получилось. Однако часть о достижении технологической сложности проекта придется отложить до какой-нибудь следующей статьи. Всем спасибо за прочтение, здорово, что вы меня читаете (и иногда даже делитесь ссылками на эти материалы!) 🙂

 

 


Похожие статьи:

Прототип — спаситель разработки:  статья о том, как правильно работать с прототипами.

 



Мысли на тему “Прототип — убийца IT-стартапов” (12)

  1. Minimo on 30.08.2013 at 12:19 пп ответил:

    Узнал в многих моментах свою компанию 🙂
    Очипятка: «В а жестокой реальности…».

    • Анти on 30.08.2013 at 12:24 пп ответил:

      Да, беда. Надо давать читать своим инвесторам/руководству, если узнаете в этой статье свою команду. Может быть еще не поздно 🙂

      За опечатку спасибо, сейчас поправлю.

  2. При том, что статья в целом здравая, она основывается не на каких-то, уже известных в наше время вещах, а, скорее, на интуиции и опыте. А ведь не является секретом, что документация по имплементации, действительно, зачастую не нужна. Причиной этого являются два фактора — (1) стратегия clean code делает код документацией (2) непрерывный рефакторинг сводит к нулю ценность документации по конкретной имплементации, поддержание актуальной документации становится по усилиям сравнимо с собственно разработкой. Далее по самому процессу. Упущен один из наиболее важных моментов современной разработки — непрерывный рефакторинг. Странно слышать, что архитектор не должен ничего разрабатывать, пока он не сделает документацию по архитектуре. Каким образом можно этого достичь? Что будет описывать такая документация? Архитектуру сферического коня в вакууме? Архитектура точно также подлежит рефакторингу, как и код. Конечно, в несравнимо меньшем масштабе, то есть можно предположить, что основные архитектурные идеи проживут в проекте достаточно долго. Тем не менее, если, грубо говоря, какой-то DDD субдомен на этапе разработки оказался очевидно состоящим из двух разных субдоменов, нужно менять архитектуру, а не молиться на неё, как на скрижали. Плюс, если архитекрутная документация предполагает выбор инфраструктуры и фреймворков, то всё это должно выбираться исходя из потребностей самого проекта. А часто бывает невозможно понять заранее с большой долей определённости, какая будет инфраструктура, какой фреймворк годится в том или ином случае, т.к. масштабы их применения могут быть переоценены, недооценены и так далее. Тут-то и нужен прототип, чтобы можно было сделать spike и на нём что-то обкатать, в том числе и архитектурные моменты. Конечно, что-то надо изначально в команде обсудить и на бумаге нарисовать. Но big model upfront — это не lean, это против lean и даже крупные предприятия со своей косностью начинают понимать этот момент. Архитектура проекта — такая же живая и изменяющаяся материя, как и код в проекте, как и сам проект. Фактически, если из статьи убрать стенания про архитектуру и документацию, то вывод можно сделать простой — стартапы проваливаются из-за отсутствия рефакторинга. Это проблема не только стартапов. Достаточно посмотреть на крупные системы, чтобы понять всю косность их архитектуры и кода. Причины те же самые — зачем менять, если оно работает. «Лучший способ обанкротиться — внедрить новые технологии» и так далее — мы слышим это от менеджмента каждый день. Косность, большая или малая — вот что может убить или задушить любой проект. Это, кстати, немало касается и работников. Часто талантливые амбициозные разработчики видят косность системы, предлагают какие-то изменения, натыкаются на глухую стену «и так работает» и предпочитают найти другое место работы. Тут у стартапов больше пространства для манёвра и надо его использовать и не таким образом, что заставить всех писать массу документации, которая после первого же рафакторинга придёт в негодность, а внедрять актуальные методы разработки, смотреть, как делают свои проекты передовые компании, читать блоги и книги, отказаться от «идей на коленке», отказаться от «напишем всё сами» в пользу изучения имеющихся open source средств и инструментов и так далее. Но и самое главное — непрерывный рефакторинг. Так победим 🙂

    • Анти on 31.08.2013 at 2:06 пп ответил:

      Отличный и здравый коммент. Однако, я не вижу тут противоречий: я ведь ни в коем случае не говорю, что прототип не нужен. Он нужен, он очень очень нужен (а иногда — и несколько). Но рефакторить прототип, особенно если это — прототип на выброс, которые делается на может быть каком-то совсем другом фреймворке/пишется на другом языке? Вот про что я говорю, в первую очередь: что часто авторы не могут понять, где закончился прототип и когда надо затормозить. Рефакторинг имеет смысл только если вы уже перешли во торую фазу — непосредственную разработку… или она была запланирована заранее. И вот тут я не соглашусь, что продуманная архитектура и план того, как все будет делаться, не нужны.

      Касательно того, что могут быть расхождения с задуманным и выявленным в процессе: для того прототипы и делаются, чтобы понять — будет ли задуманное работать так, как надо, или выбранные методы не соотетствуют целям. В идеале, мое видение четкой разработки — определяются задачи, выбираются способы их решения, планируется способ достижения цели и все это документируется. Далее делается прототип и затем — стоп. Оценка, если по скраму, то большая ретроспектива, анализ результатов. После этого принятие решения, куда и как двигаться дальше, коррекция документации. И только после этого рефакторинг, и то только в том случае, если прототип может быть развит дальше и не делается clean версия с нуля (и с учетом выявленных проблем).

      В общем, я не верю в то, что можно сделать нормальный конкурентноспособный продукт без хорошей документации. Все самые серьезные фейлы, которые я видел, были как раз по этой причине. «Мы крутые программисты, мы сделаем все без лишней бюрократии и документации, у нас вся архитектура в голове!». Затем один из них перейдет в другую компанию/улетит на Гаити/пропадет без вести — и привет, крутые кодеры, ищите говночерпателя на разбор незадокументированного кода. Хотите продать долю в бизнесе и вам говорят, «покажите документацию нашему отделу аналитики» — добро пожаловать в кранч, когда все все бросят и начнут писать документацию по тому, что они уже год как забыли. Решили через год сравнить то, что было запланировано и то, что сделано — упс, а как, никто ведь не вел документацию. Есть еще множество причин, по которым документация нужна, в том числе и те, которые описаны в статье. Так что в R&D без документации я не верю. Шансы есть, но зачем многократно повышать риски? В общем, можно доки считать бюрократией, а можно их превратить в инструмент, полезный в самых разных ситуациях. Кому как работать — каждому решать самому.

      • Я знаю софтверную компанию, которая живёт своим продуктом (довольно успешно), документации к которому на уровне «для девелопера» нет. Возможно, есть документация архитектуры. Вообще документация архитектуры необходима ровно в той степени, что архитектура — это и ест документация. Это то, чего нельзя записать напрямую в код, это определяющее направление развития самого кода каждого компонента и всей системы как кооперации компонентов и иначе, чем в документе это описать невозможно, тут я согласен полностью. Просто с документацией надо знать меру, в вашей статье несколько напряг акцент на «придёт новый разработчик и ему придётся разбираться в коде, а так прочитал документацию и готово, можно в бой» (ну, я утрирую). Если взять почти любой open source проект, то девелоперской документации там почти никогда нет. Люди приходят, изучают код и вносят вклад. И эти проекты весьма успешны. Документация там есть только для пользователей этого проекта. Как я писал выше — clean code и agile-практики типа парного программирования и peer review решают проблемы ввода новых разработчиков в проект эффективнее документации. Если просуммировать:
        — Визуализация архитектуры возможна только в виде документации
        — Архитектура и дизайн (системный) важны не менее, а то и более, чем имплементация
        — Архитектура и импемелнация в равной степени являются живой средой, подверженной непрерывному рефакторингу

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

        • Анти on 31.08.2013 at 3:10 пп ответил:

          Ну да, в целом о том и речь. Название просто слишком в душу западает, похоже, и сбивает с толку.

    • Хммм. А как же continuous documenting и прочая живая документация? Она ж дешевле

      • Анти on 01.09.2013 at 9:46 дп ответил:

        Считаю, что одно другое не исключает и, более того, документация по ходу разработки необходима, неизбежна и будет составлять от первоначальной (в «правильном» случае) как минимум 80%.

        Но по поводу выгоды в деньгах — очень много проектов не развалились бы в определенный момент, если бы знали, куда двигаются. Я навскику могу назвать десяток игр и не-игр, с бюджетами от $300к до нескольких миллионов, которые умерли по моему мнению именно потому, что не потратили 2-3 месяца на предпродакшен и планирование. В итоге, ппроекты постоянно мутировали, развивались то в одну, то в другую сторону и болтались между самыми разными финальными целями. Можно искать причины в другом, но я оцениваю причины подобных провалов именно в этом.

  3. Pingback: Прототип - спаситель разработки | Gamedis.ru

  4. Pingback: Тайное искусство блоггеров-джедаев, или как они управляют вашим мозгом | Gamedis.ru

  5. Pingback: Прототип — спаситель разработки | MGDC.ru

  6. 2222222 on 01.01.2014 at 7:08 пп ответил:

    правильнее называть прототип макетом

    макет — то что заранее нерабочее
    прототип — это такая suboptimal draft частичная реализация какой-то идеи или задачи (летает один раз, приземляется на воздушный мат)

    макет можно и в фотошопе рисовать, многие им сильно увлекаются
    прототип — всех «бесит» что нельзя показать как действительно круто он работает

    классическое деление на ноль
    что-то более менее рабочее нельзя сделать сразу
    либо танк фанерный, либо нерабочий, либо жди пока сделаем (альфу для демонстрации)

    у военных все давно решено кстати

Добавить комментарий

Навигация