Вы хотите создать IT стартап. У вас ещё ничего нет и вы находитесь на распутье. Пойдёшь налево — сделаешь продукт с вероятностью 5%, зато идеальный. Пойдёшь направо — сделаешь продукт с вероятностью 95%, но за него будет немножко стыдно.
Для корпорации лучше ничего не выпускать чем выпустить фигню какую-то. Для стартапа — наоборот, лучше выпустить фигню какую-то чем ничего. Стартапер должен выбирать правую дорожку, и людей в команду подбирать тех, кто выбирает правую дорожку. Даже простых программистов - копателей.
Вы думаете что написание кода — это написание кода, и всё равно для стартапа или для корпорации этот код пишется? Думаете секрет успеха — взять самого талантливого разработчика из гугла и он всё сделает в лучшем виде? Проблема в том что они привык ходить по левой дорожке. А вам надо по правой.
Левая дорожка:
- надо писать по стандартам корпорации, не отходить от них, люди должны быть взаимозаменяемы и код писать в едином стиле, по согласованной архитектуре, используя принятые технологии
- надо делать идеально
- склонность к оверинжинирингу (предусмотреть все возможные развитие событий)
- нет экономии ресурсов (времени, железа)
- низкая степень неопределённости
- работают по чёткому ТЗ, есть бизнес-аналитики и тестировщики
- есть лиды, архитекторы, старшие товарищи которые подскажут и поревьюят код => самостоятельность не нужна, а иногда и вредна
- глубокие знания, небольшая часть большой системы
- винтик системы и ему с этим ОК
Правая дорожка:
- надо делать быстро
- не заморачиваться над "качеством" (в кавычках т.к. качество слева обычно иллюзорно, это внутренние ощущения красоты которые не всегда верны и понимаемы другими)
- не заниматься преждевременной оптимизацией
- можно делать что угодно, рамок нет
- склонность к быдлокодерству
- надо экономить ресурсы (время, железо)
- позволяет себе делать не 100% что ему говорят, а допустим 95, способен оценить что это будут за 5% и взять за это ответственность
- умеет быстро делать proof of concept, должен уметь выделить важное, остальное отбросить
- "если вы выпустили продукт за который вам не стыдно, то вы запустили его поздно"
- не факт что результат его работы будет вообще кому-то нужен
- высокая степень неопределённости
- нет тех, на кого можно опереться или спросить => важна самостоятельность
- широкие знания, т.к. отвечаешь за всё
Соответственно если вы ищете человека в стартап, то те качества вашего кандидата, которые для корпорации будут негативными, для вас будут позитивными. Ваш разработчик не будет стараться делать идеально, будет работать на скорость. И не будет страдать если проект не полетит и результат его труда выкинут, он изначально принимал этот риск и делал работу исходя из него, не вкладывал много ресурсов, старался не заморачиваться, как можно скорее выдать результат чтобы протестировать гипотезы. А ещё он не будет вам говорить "без ТЗ результат ХЗ".
Хоть где-то здесь есть такие причины как:
- нечистый код
- некрасивый дизайн и фронтенд
- не выдержали наплыва пользователей и сложились (это то чего боятся разработчики поэтому делают сразу архитектуру "масштабируемой", занимаются преждевременной оптимизацией)
- сделали монолит вместо микросервисов
- не использовали docker или kubernetis
- написали продукт на PHP а не на модном нынче Go
- разработчик не умел "в асинхронщину"
?
Есть пункт "плохой продукт", но сделать хороший продукт — это задача фаундера или продакта, а не программиста. Задача программиста — реализовать ту идею, которую придумали другие. И на их общей стороне есть задача как можно быстрее найти и устранить несоответствия между ожиданиями и тем что получается.
Зато в этом списке есть такие пункты как:
- закончились деньги (возможно по причине найма большой команды разработки или того что они слишком долго делали и в итоге не успели сделать, ведь команда разработки всё это время просила есть)
- не та команда и дисгармония в команде (разные ценности и подходы, например потому что фаундер стартапер а разрабочик — типичный корпоративный пассажир)
- несвоевременный продукт (слишком долго делали)
- перегорел (то же самое, пока они там свои IDE расчехляли и проектировали микросервисную архитектуру, фаундеру уже всё надоело)
Возвращась к исходному — от продукта и от кода должно быть немножко стыдно, и это несёт в себе наименьшие риски для бизнеса. В корпорациях же ситуация обратная, лучше ничего не сделать чем то, за что будет стыдно и что подкосит бренд.
Забавно, прямо во время написания этой статьи Михаил Табунов написал пост как раз в тему, не только к коду относится эта логика, но и к маркетингу:
Возможно почитав данную статью вы решили что в вашем случае всё иначе потому что ... (список причин) ..., а значит вы не будете выбирать между правой и левой дорожкой, а с вероятностью 95% вы сделаете идеальный продукт.
А кто осознанно выбирает правую дорожку, со всеми её плюсами и минусами — welcome.