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