Многие стартапы создаются не для того, чтобы жить долго и счастливо, принося прибыль владельцам.
Зачастую целью основателей и инвесторов является продажа бизнеса через 3-5 лет.

А что входит в понятие «бизнес»?
  • Бренд, репутация и положение на рынке
  • Оборот и доходы
  • База активных клиентов
  • Программный продукт или сервис

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

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

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

Тут всё просто. Пофигистов не интересует будущее продукта, а зачастую и его настоящее.
Наёмного пофигиста волнует регулярная выплата заработной платы. Пофигиста-основателя — получение гранта от инвестора.
Ему важно, чтобы всё работало сейчас, а что будет завтра… Это уже не его дело.
При этом пофигисты — не бездельники, они честно отрабатывают оплаченное время. Беда только в том, что именно отрабатывают.

Код, создаваемый такими мастерами внешне выглядит стройно и в первые 10 минут производит хорошее впечатление. Ровно до тех пор, пока не начнешь с ним разбираться.
Я, например, в одной программе нашел два варианта отправки приветственных писем после регистрации в личном кабинете. Если регистрируешься через web-сайт и используется веб-сервис, то письмо конструируется на лету из набора строк, при этом учитывается язык пользователя (т. е. письмо приходит на английском или на русском языке).
А когда регистрируешься через интерфейс самого личного кабинета, то текст письма целиком считывается из файла. И язык пользователя уже не учитывается — только русский.
Понятно, что писали код два человека и каждому хотелось как можно проще сделать свою работу. Проектную документацию никто не вёл, целиком за продукт никто не не отвечал.
При этом сам продукт формально работал, но стоимость его дальнейшей разработки становится достаточно высокой.

То есть наше приложения становится похоже вот на такой домик:



Здание вроде стоит, но необходимы постоянные подпорки.

Хакеры

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

Есть задача — хакер напишет код, задачу решающий. Появится другая потребность — хакер приляпает к первому куску кода второй. Потом третий. А потом код проекта превращается в лабиринт.

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

Продукты, которые пишут хакеры, похожи на вот такие дома:



Хаотическое нагромождение конструкций. Чтобы поддерживать такой продукт необходим специалист не меньшей степени гениальности, чем автор.

Энтузиасты

Эти ребята — абсолютные антиподы пофигистов. Их подводит не лень, а излишнее усердие.
Сделать простую систему? Давайте придумаем для неё супер архитектуру! (Сделать садовый туалет? Давайте зальем бетонный фундамент на 5 метров глубиной!)
Будем использовать Java EE! — Зачем Java EE, там где с головой хватает PHP? Стоимость специалистов и требование к ресурсам несопоставимо.
Сделаем потрясающий интерфейс! — а давайте вначале сделаем работающий интерфейс. Стартапу надо зарабатывать деньги.
В итоге подобной гигантомании получается объемная система, для поддержки которой требуется огромная командадорогих и разноплановых специалистов.
А оно надо потенциальному покупателю стартапа?



Если вместо такого чуда построить обычную многоэтажку, то она будет и симпатичней и удобней.

Кто же должен отвечать за разработку продуктов в стартапах?
Конечно практики.
Только они найдут наиболее эффективный способ построения функционала продукта.
Только они создадут код, который станет отторгаемым и который сможет дорабатывать и поддерживать любая, независимая от основателей. команда.
Только такой код станет интеллектуальным капиталом компании.

После праздников я напишу какие критерии и отличительные признаки такого кода и как его лучше всего создавать.

Всех с наступающим праздником!

Комментарии (9)


  1. AlexTest
    19.02.2016 22:14
    +1

    Дело в том, что продукт должен быть отторгаемым от исходной команды разработчиков.
    Из вашей статьи совершенно непонятно — как этого можно достигнуть, предполагаю, что надо нанять «хороших» разработчиков — верно? Но вы написали только про «плохих» разработчиков и ничего не написали про «хороших» — какие они по вашему, где их брать, и какая у них будет цена по сравнению с «плохими»?


  1. AndrewIg
    19.02.2016 22:35

    Про это я планирую написать на следующей неделе. В понедельник или вторник.


  1. dkukushkin
    19.02.2016 22:42
    +1

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

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


    1. AndrewIg
      19.02.2016 22:52
      -2

      В качестве рядового члена команды — да. При этом их нужно очень хорошо контролировать и очень чётко формировать задачу.

      Хакер — как разведчик в армии. Он элита пехоты. У него специфичная и очень важная роль, но армия из одних разведчиков проиграет армии обычных пехотинцев (да, это моё оценочное суждение :))

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

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


      1. GarryC
        20.02.2016 13:32

        Армия из разведиков не проиграет армии из обычных пехотинцев, посокльку армию разведчиков не может себе позволить не одно государство в мире. А вот полк разведчиков проиграет, поскольку "Бог на стороне больших батальонов".


  1. edogs
    20.02.2016 01:00
    +1

    Создать!=СделатьУспешным!=Продать.
    Красивая картинка из практиков действительно нужна на этапе продажи.
    Так же как белая бухгалтерия и бизнес-план.
    В остальном же если это действительно стартап, а не просто очередной ИМ реселлящий алиэкспресс, то от этих 3 групп не убежать никуда, иначе до этапа продажи оно просто не долетит.


  1. Chmyaf
    20.02.2016 06:49

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


  1. AndrewIg
    20.02.2016 09:51

    Имелась в виду поддержка любой командой, а не обязательно основателями.

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


    1. Chmyaf
      20.02.2016 11:56

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