Многие стартапы создаются не для того, чтобы жить долго и счастливо, принося прибыль владельцам.
Зачастую целью основателей и инвесторов является продажа бизнеса через 3-5 лет.
А что входит в понятие «бизнес»?
- Бренд, репутация и положение на рынке
- Оборот и доходы
- База активных клиентов
- Программный продукт или сервис
Есть множество методик. позволяющих оценить стоимость бренда. Еще проще измерить оборот, доходы и количество клиентов компании.
А вот с продуктом намного сложнее.
Дело в том, что продукт должен быть отторгаемым от исходной команды разработчиков.
То есть, если все текущие программисты по какой-либо причине одномоментно напишут заявление об уходе, должна быть возможность нанять новую команды (причем недорогую, т.е. не состоящую сплошь из высококлассных дорогих специалистов), быстро обучить и продолжить выпуск программного продукта.И вот именно такие продукты пофигисты, энтузиасты и хакеры создавать не умеют. Я за время работы на ниве развития стартапов видел плачевные результаты работы всех трёх социальных групп и сейчас постараюсь обосновать почему каждую их них нельзя подпускать к архитектуре продукта.
Disclaimer: в качестве рядовых разработчиков и исследователей все эти люди (даже пофигисты) могут быть полезны. Энтузиасты предложат новые возможности, хакеры выяснят как их лучше реализовывать, пофигисты засядут за кодирование. Но если вы сделаете кого-то из них ответственным за проектирование и развитие продукта, то произойдёт вот что.
Пофигисты
Тут всё просто. Пофигистов не интересует будущее продукта, а зачастую и его настоящее.
Наёмного пофигиста волнует регулярная выплата заработной платы. Пофигиста-основателя — получение гранта от инвестора.
Ему важно, чтобы всё работало сейчас, а что будет завтра… Это уже не его дело.
При этом пофигисты — не бездельники, они честно отрабатывают оплаченное время. Беда только в том, что именно отрабатывают.
Код, создаваемый такими мастерами внешне выглядит стройно и в первые 10 минут производит хорошее впечатление. Ровно до тех пор, пока не начнешь с ним разбираться.
Я, например, в одной программе нашел два варианта отправки приветственных писем после регистрации в личном кабинете. Если регистрируешься через web-сайт и используется веб-сервис, то письмо конструируется на лету из набора строк, при этом учитывается язык пользователя (т. е. письмо приходит на английском или на русском языке).Понятно, что писали код два человека и каждому хотелось как можно проще сделать свою работу. Проектную документацию никто не вёл, целиком за продукт никто не не отвечал.
А когда регистрируешься через интерфейс самого личного кабинета, то текст письма целиком считывается из файла. И язык пользователя уже не учитывается — только русский.
При этом сам продукт формально работал, но стоимость его дальнейшей разработки становится достаточно высокой.
То есть наше приложения становится похоже вот на такой домик:
Здание вроде стоит, но необходимы постоянные подпорки.
Хакеры
Казалось бы, хакеры — элита среди программистов. Способны создать такие системы, которые обычные программисты не сделают и всей командой.
А потом покупатели компаний, в которых хакеры отвечали за создание продукта, смотрят в код и хватаются за голову.Масштабируемая платформа? Нет, не слышали. Модульная архитектура? А это ещё зачем?
Приложения, которые создают хакеры походи на картины художников абстракционистов. Вместо носа торчит ухо, глаз во лбу, цвет кожи синий, а творец объясняет — «я так вижу».
Есть задача — хакер напишет код, задачу решающий. Появится другая потребность — хакер приляпает к первому куску кода второй. Потом третий. А потом код проекта превращается в лабиринт.
Это код сделанный пофигистами можно в конце-концов понять (построить диаграмму классов, расписать взаимодействие, сделать документацию, выбросить лишнее), а в коде хакера разберется только сам хакер.
Продукты, которые пишут хакеры, похожи на вот такие дома:
Хаотическое нагромождение конструкций. Чтобы поддерживать такой продукт необходим специалист не меньшей степени гениальности, чем автор.
Энтузиасты
Эти ребята — абсолютные антиподы пофигистов. Их подводит не лень, а излишнее усердие.
Сделать простую систему? Давайте придумаем для неё супер архитектуру! (Сделать садовый туалет? Давайте зальем бетонный фундамент на 5 метров глубиной!)В итоге подобной гигантомании получается объемная система, для поддержки которой требуется огромная командадорогих и разноплановых специалистов.
Будем использовать Java EE! — Зачем Java EE, там где с головой хватает PHP? Стоимость специалистов и требование к ресурсам несопоставимо.
Сделаем потрясающий интерфейс! — а давайте вначале сделаем работающий интерфейс. Стартапу надо зарабатывать деньги.
А оно надо потенциальному покупателю стартапа?
Если вместо такого чуда построить обычную многоэтажку, то она будет и симпатичней и удобней.
Кто же должен отвечать за разработку продуктов в стартапах?
Конечно практики.
Только они найдут наиболее эффективный способ построения функционала продукта.
Только они создадут код, который станет отторгаемым и который сможет дорабатывать и поддерживать любая, независимая от основателей. команда.
Только такой код станет интеллектуальным капиталом компании.
После праздников я напишу какие критерии и отличительные признаки такого кода и как его лучше всего создавать.
Всех с наступающим праздником!