Не взлетит. Руководство как сжечь миллион на MVP
- -
- 100%
- +
Давайте добавим еще немного суровой, неприкрытой реальности. Ниже — классический шорт-лист тех вещей, о которых вы в своей фаундерской эйфории даже не задумывались, но они все равно придут за вашими деньгами.
Облака, которые вам гарантированно не по карману.
«AWS — это дешево и масштабируемо», вы определенно где-то прочитали в интернете. Дааа, охотно верю. Ровно до тех пор, пока весь ваш продукт представляет собой статичный лендинг на три картинки, сиротливо лежащий в S3-бакете. Но стоит вам дрожащей рукой нажать кнопку «Деплой в продакшен», как в начале следующего месяца вам прилетает инвойс на пять тысяч долларов. За что? Почему? Никто в компании понятия не имеет. Мигрировать на другое облако? Поздняк, это еще дороже. Оптимизировать архитектуру? Некому, ваши вайб-кодеры умеют только копипастить из Чата ГПТ.
В итоге вы просто покорно платите, потому что отдавать по пять штук баксов ежемесячно тупо проще, чем попытаться понять, какая именно скрытая метрика минусует ваш бюджет.
Лицензионный ад, или плати за воздух.
Вы наивно полагали, что софт для разработки покупается один раз и навсегда? Добро пожаловать в прекрасный мир подписочной модели, где вы не владеете вообще ничем. Приготовьтесь каждый год отстегивать по пятьсот долларов за профессиональные IDE для каждого инженера, кормить Фигму еще на пару сотен за каждого причастного к дизайну и отдавать почти тысячу долларов в год за корпоративный Слак исключительно ради того, чтобы ваши бездельники могли лепить кастомные анимированные эмодзи в рабочих чатах. Сюда же поверх ложится годовая лицензия на тяжелый Фотошоп, просто потому что вашему дизайнеру «так привычнее и надо для вдохновения». Самое смешное, что половиной из этого оплаченного софта ваша команда не воспользуется ни разу, но счета будут приходить строго по расписанию.
DevOps, или плата за абсолютное ничегоделие (Dolce far niente).
Менеджмент упорно не понимает, за что этому человеку отваливают денеги, ведь со стороны он выглядит как самый ленивый персонаж в офисе, который просто пьет кофе и меланхолично смотрит в монитор (если он ходит в офис вообще). Но математика здесь парадоксальная: если ваш девопс круглосуточно суетится, с красными глазами чинит сервера, вручную перезапускает контейнеры перенастраивает CI или Графану (Grafana) — поздравляю, у вас на проекте катастрофа. Нормальный DevOps-инженер инвестирует интеллект в то, чтобы один раз настроить автономную экосистему, которая бесперебойно живет в сети, сама масштабируется при наплыве пользователей, автоматически реанимирует себя в случае сбоев и работает вообще без его участия. Вы платите ему оклад именно за то, чтобы он сидел сложа руки. И если в вашем проекте от него наступила идеальная, звенящая тишина — это значит, что ваш невидимый страж на бэкграунде гениально выстроил автоматизацию. Но стоит вам сэкономить на этом «бездельнике», и первый же косяк упавшей инфраструктуры выставит вашему бизнесу брутальный счет. Нет продукта в сети = нет продукта в принципе.
Юристы как узаконенное вымогательство.
Правильное оформление юридического лица, NDA, кабальные договоры, пользовательские соглашения, политики обработки персональных данных, патенты и превентивная защита от патентных троллей — всё это стоит баснословных денег. Нанятый вами адвокат будет с умным видом брать по триста долларов за час своей неспешной работы, чтобы в конце недели выдать вам гениальное заключение: «Нет, ребятки, называть ваше приложение iCoolApp нельзя, корпорация Apple засудит вас за две секунды». Ирония в том, что Apple про вас даже не знает, но триста долларов в час платите именно вы, а не Тим Кук.
Маркетинг, или искусство тратить.
На старте вам внушат, что без агрессивного продвижения, пиара и поисковой оптимизации ваш продукт — просто невидимый цифровой труп. Вы соглашаетесь и вступаете в игру. Что вы получаете на выходе? Помпезный корпоративный сайт за пять тысяч долларов, который не генерирует ни единой продажи. Поисковое SEO-продвижение за две штуки баксов в месяц, которое выведет вас на первую страницу Гугла примерно через год, когда компания уже трижды обанкротится. Трендовую видеорекламу в Тиктоке, которую лениво пролистали боты и которую не увидел ни один реальный живой человек.
И, конечно же, наемный топ-маркетолог, который за пару недель спустит ваш рекламный бюджет на десять тысяч долларов, после чего покажет фокус со своим исчезновением, бросив на прощание: «Ну а что вы хотели? Зато мы прокачали узнаваемость бренда, а прямые продажи вообще не входили в мои KPI»
Обучение персонала, или «вы и так дураки, но давайте доплатим».
Курсы повышения квалификации, модные тренинги личной эффективности и сертифицированные Agile-интенсивы — это лучший способ добровольно слить деньги в никуда.
Что вы получаете на выходе за свои кровные пять тысяч долларов? Красивую глянцевую бумажку в рамочке. А в придачу — проектного менеджера, который теперь на полном серьезе считает себя Scrum-коучем, и сеньор-разработчика, который после двухдневного вебинара в ультимативной форме требует немедленно переписать весь ваш работающий монолит на Go, иначе он потеряет ментальную связь с профессией.
Тестирование, или почему баг — это ваш новый финансовый долг.
Повторяйте за мной: QA — это не опция для богатых стартапов, это ваша единственная подушка безопасности перед лобовым ударом об стену. Без дотошного тестировщика весь ваш продукт гарантированно развалится на куски в день релиза. Математика здесь простая и жестокая: каждый вовремя найденный на этапе разработки баг экономит вам кучу денег. Но каждый баг, который просочился на прод и был обнаружен реальным пользователем, — это не просто ошибка. Это выставленный вам счет на сумму, которая способна загнать вашу компанию в кассовый разрыв.
Служба поддержки: за ваши же деньги вас будут искренне ненавидеть.
Как только продукт увидит свет, вам придется нанять людей, которые будут круглосуточно принимать ушаты помоев. Разгневанные пользователи начнут писать, звонить и яростно спамить во все каналы. «У меня ничего не работает!», «Где, блядь, эта кнопка?!», «Верните мои деньги, твари!». Вы будете ежемесячно платить зарплату саппорту только ради того, чтобы слушать, как клиенты хамят вашей компании в два часа ночи, обрывают телефоны по пять раз в день и шлют проклятия вперемешку с юридическими угрозами. Привыкайте, для ИТ-бизнеса это абсолютно штатный режим функционирования.
Бухгалтерия как узаконенный и легальный грабеж. Приготовьтесь отдавать минимум штуку баксов в месяц толковому бухгалтеру просто за то, чтобы вас не посадили. Налогами в этой индустрии облагается вообще всё, что шевелится, а за то, что не шевелится — придется заплатить пошлину. Вы будете регулярно получать абсурдные штрафы от налоговой просто потому, что ваш ленивый менеджер в каком-то отчете «поставил галочку не в том поле». А еще вам придется часами безрезультатно доказывать собственному главбуху, почему ящик элитного виски для пятничного тимбилдинга — это «расходы на стратегическое развитие человеческого капитала», а не ваша личная прихоть.
Канцелярия, бытовуха и прочая офисная номенклатура. Разноцветные стикеры для Agile-досок — это скрытый наркотик для вашей команды. Без них современные айтишники физически не способны сгенерировать ни одной мысли. Цветные маркеры, маркерные доски, бумага для принтера, салфетки, туалетная бумага, питьевая вода и печенюшки.
На эти «бытовые мелочи» у вас будет стабильно улетать по триста-четыреста долларов в месяц. Попробуйте ради эксперимента сэкономить и купить чай попроще — в офисе сразу начнутся стоны о том, что в таких скотских условиях «код не пишется и вообще ничего не работает».
Непредвиденные расходы — единственная постоянная статья вашего бюджета.
Запомните: Что-то обязательно сломается. Кто-то обязательно исчезнет. Кто-то обязательно придумает «ещё одну фичу за вчера».
И это не сбой системы. Это и есть глубинная суть информационных технологий. Форс-мажор в этой индустрии — не досадное исключение из правил, а ваш ежедневный, базовый режим работы.
Добро пожаловать в суровую реальность коммерческой разработки софта.
Именно поэтому любой успешный, прибыльный запуск ИТ-продукта на рынке — это не чудо, не гениальность менеджмента и не божественное провидение. Это всегда чудовищно дорогая случайность, методичная и дисциплинированная работа над преодолением полосы препятствий.
DREAM TEAM
Запомните: комплектование галеры всегда начинается с одного-единственного человека — с Техлида.
Без него у штурвала вашей разработки будет находиться либо случайный пассажир с купленным дипломом, либо звенящая пустота.
Правильный Техлид — это не тот персонаж, который на ежедневных утренних стендапах устраивает TED Talk. Это не болтун с горящими глазами, умеющий виртуозно вешать инвесторам лапшу на уши про блокчейн-революцию и квантовое будущее. Техлид — это циничный, хладнокровный хирург. Он смотрит на ваш кривой, скопипащенный из чат-бота код и, не моргнув глазом, достает скальпель. Он не цокает сочувственно языком — он молча чинит. Он принципиально не ведется на сиюминутную технологическую моду, он просто вовремя останавливает внутрикомандный идиотизм.
Если вы с гордостью несете ему в переговорку очередную гениальную мысль в духе: «Слушай, а давай срочно бахнем в проект смарт-контракты, генеративный ИИ и что-нибудь из Web3!» — правильный Техлид должен посмотреть на вас с такой глубокой, экзистенциальной скорбью, чтобы вам самому стало хоть немного стыдно за свое техническое слабоумие.
Он на молекулярном уровне знает великую истину: идеальный код — это тот код, которого пока вообще не существует в природе. Потому что прежде чем писать терабайты символов, нужно сесть и четко понять, нахрена они вообще нужны твоему бизнесу. Его главный супернавык — это ювелирный баланс между «так правильно и красиво по канонам архитектуры» и «так надо сделать прямо сейчас на костылях, потому что дедлайн был еще вчера. Потом исправим».
Техлид — это твой единственный живой буфер между работающим продуктом и неминуемой гибелью проекта от feature creep (бесконтрольного раздувания фич), фатальных багов, синдрома непризнанного гения у джунов и продуктовика-гуманитария, который на ночь начитался Хабра и теперь с пеной у рта требует развернуть отдельный микросервис под каждый всплывающий попап на сайте.
Настоящих, трушных Техлидов на рынке критически мало. Практически все, кого вы встретите на собеседованиях это китайские подделки с накрученным опытом. Перепутаете, поведетесь на красивое резюме и получите обычную говорящую голову в оверсайз-футболке с надписью «Senior». Этот персонаж будет с академическим, умным видом методично разрушать вашу кодовую базу, сливать сроки и называть этот откровенный саботаж «правом на инженерную свободу».
Но если вам крупно повезёт и вы умудрились нанять того кто вам действительно нужен, у вас появляется уникальный исторический шанс сжечь свой инвесторский бюджет не впустую, а хотя бы с толком.
Запомните раз и навсегда: Техлид — это не статусная декорация для зум-митингов и не просто «самый старший разработчик по выслуге лет». Это единственный вменяемый человек в вашей конторе, который молча берет и делает правильно, пока вся остальная команда бесконечно спорит в чатах, меряется мемами в курилке и усердно пьет третий за утро латте на кокосовом молоке. (Или, судя по качеству их кода, там в чашках уже давно плещется чистый коньяк?).
Кровавый кастинг в дурдоме: Как нанять тех, кому на тебя насрать
Любая, даже самая гениальная, прорывная бизнес-идея остается просто сотрясением воздуха и красивой болтовней для инвесторов до тех пор, пока не появится команда, способная превратить этот бред в стабильно работающий софт. И ровно в этот момент на тлеющих руинах твоих фаундерских иллюзий начинается настоящее, первосортное трэш-реалити-шоу: с кастингами, взаимными проклятиями, нервными срывами менеджмента и сомнительными персонажами, которых тебе по дружбе притащил «один очень надежный знакомый».
Вообще, переход в любой новый проект — это всегда локальный, внутренний кризис. Вокруг тебя материализуются новые лица со своими странностями, на кофе-поинтах звучат чужие шуточки, формируются группировки «своих», а на заднем плане маячат люди, при взгляде на которых в голове пульсирует единственный вопрос: «Мама дорогая, а это вообще кто и зачем их сюда пустили?». А учитывая, сколько жизни мы добровольно сжигаем на работе в процессе создания продукта, хочется не просто уныло пялится в экран ноутбука, а хотя бы, чтоб было интересно тут находиться.
Мне в свое время крупно, просто сказочно повезло: в собственном проекте я умудрился получить абсолютный карт-бланш и сам лично решал, кого из кандидатов брать к себе в команду, а кого не брать. Звучит как фаундерская мечта из пабликов про внезапный успех, правда?
Только вот суровая производственная практика быстро засунула эту мечту в глубокое темное место. Выяснилась банальная вещь: абсолютная свобода выбора — это ни разу не гарантия коммерческого успеха и даже не страховка от убытков. Одно дело — собрать вокруг себя группу приятных, эрудированных собеседников для высокоинтеллектуальных разговоров по пятницам и распития крафтового пива. И совсем другое — запустить с этой интеллигентной, ранимой тусовкой жесткую боевую разработку, когда дедлайн закончился еще в прошлом квартале.
Перед нами мгновенно разворачиваются три основных задачи:
Заманить в проект ментально адекватных разработчиков. Не случайных людей с улицы и не амбициозных мечтателей из телеграм-чатов в духе «ищу тиммейта для создания убийцы Uber на чистом энтузиазме».
Ввести их в реальный курс дела. Настроить онбординг так, чтобы новые сотрудники не сидели неделями, тупо пялясь в монитор с выражением лица «Господи, за что мне эта жизнь?».
Синхронизировать вектор движения. Заставить всех грести в одном направлении. В противном случае каждый потащит архитектуру в свою сторону, и вместо управляемой лодки у вас получится увлекательная гребля на месте.
Но это в общем. А в частности, мы ждём, что с новыми людьми должны приходить: компетенции, знания, желание работать, поучаствовать в новой для себя истории, и, в качестве бонуса, прицепом идут завышенные эго-ожидания, нереализованные амбиции, бессмысленные междоусобные конфликты, непреодолимое желание переписать весь проект с нуля по собственным лекалам и вечный, тотальный дефицит личной ответственности за результат. Именно в этой невидимой зоне и тонут перспективные ИТ-продукты.
Просто потому, что эффективная команда — это не аккуратный, стерильный список сотрудников. Это живой, дико капризный, шумный и временами токсичный организм. И если ты не умеешь с ним работать — готовься встречать почти управляемый хаос.
У каждого наивного фаундера в голове крутится одна и та же фантазия: нанять элитных, автономных инженеров. Чтобы они зашли в проект, молча взяли твое кривое ТЗ, переварили его внутри своих гениальных черепных коробок и выдали на выходе безупречный работающий софт. Желательно еще, чтобы у них был релевантный опыт именно в твоей узкой нише.
Настоящие, трушные специалисты не ищут работу на Хедхантере. Это работа с мылом в заднице бегает за ними по всему интернету, умоляя взять миллион рублей в секунду и ДМС со стоматологией. И этот факт напрочь ломает классическую менеджерскую парадигму. Забудьте про разбор тысячи резюме от отчаявшихся выпускников онлайн-курсов «Войти в айти за две недели». Тут нужен точечный хантинг и индивидуальное вылизывание контактов в Твиттере или Линкедине.
Более того — эти капризные твари выбирают, с кем им работать, а не наоборот. Ты не заманишь их ни раздутой зарплатой, ни опционами, ни приторной HR-блевотиной в духе «мы тут одна большая дружная семья» и «у нас уникальная ламповая атмосфера». Если твой стартап с порога выглядит как горящий филиал Кащенко, элитный инженер просто развернется и уйдет. Они не голодают. Они дико разборчивые. И никакие мировые кризисы, санкции, пандемии или биржевые качели этого не меняют. В эпоху турбулентности хорошие специалисты становятся только еще более высокомерными и капризными. И да, как ни странно, это нормальное состояние рынка.
Конечно, скорость формирования команды на старте- вопрос жизни и смерти. Но упаси тебя бог торопиться и хватать первого попавшегося, который согласился на твои условия здесь и сейчас. В перспективе этот компромисс сожрет твой проект изнутри, превратив ПО в легаси-помойку.
Немного реальной статистики, от которой хочется выйти в окно
Давайте обратимся к цифрам из нашего личного производственного ада. Как-то раз мы отчаянно искали бэкенд-разработчика со специфическим стеком и прямыми руками. Внимание, следите за руками и за тем, как тает твой бюджет:
Скрининг: Отсмотрели 100 резюме, из которых 50% отправились в шредер сразу, потому что авторы путали Java с JavaScript.
Первая волна: Сделали 50 приглашений на первичный созвон. Половина кандидатов ушла в глухое радиомолчание, треть написала «я передумал», остальные сказали, что-то вроде: «У меня уже на руках оффер от Яндекса на триллион денег, чао».
Воронка: Кое-как назначили 20 собеседований. До технического и культурного интервью дожили единицы, остальные отвалились на этапе «расскажите о своем худшем факапе» (видимо, худшим факапом было само появление на этом созвоне).
Финал: С горем пополам сформировали и направили 3 оффера. И мы начинаем молиться, чтобы хотя бы один согласился нажать кнопку «Принять».
Итог: Молились мы хреново. Получили 2 официальных отказа и один классический игнор. Кандидаты просто испарились.
На весь этот ментальный мазохизм мы бесследно спустили около трех месяцев чистого времени. Три месяца — это тебе кажется много? Пха! Я лично приходил на проекты, где нужного специалиста горько и безуспешно искали по 6—9 месяцев. Почти год, чувак! Да-а-а, корпоративный трудоголизм иногда даёт свои незабываемые плоды.
Какой из этого вывод? Если у тебя есть кэш, не пытайся строить из себя великого рекрутера. Нахер внутренний HR-отдел, который умеет только постить мемы в корпоративный канал. Сразу нанимай нормальное, ИТ-кадровое агентство, у которого уже есть готовая, прогретая база контактов нужных тебе психопатов. Да, услуги агентства стоят дорого. Но скорость подбора и фильтрации кандидатов окупает эти траты в первые же недели, спасая твою нервную систему от неминуемого инфаркта.
Кровавые процессы
Итак, допустим, чудо произошло. Ты занес чемодан денег ИТ-агентству, вылизал профили нужных кандидатов и каким-то чудом решил задачу номер один — нанял классных инженеров. Проблема решена?
Прямо сейчас перед тобой в полный рост встает вторая, куда более кровавая задача: как организовать процессы так, чтобы эти высокооплачиваемые примадонны смогли взаимодействовать друг с другом, а не перерезали друг друга в первую же неделю спринта.
Ведь какая главная фишка у топовых специалистов? Правильно — каждый из них обладает абсолютно непогрешимой, единственно верной и отлитой в граните точкой зрения по любому общему вопросу. Каждый этот комнатный Наполеон точно знает, как правильно разворачивать инфраструктуру, какими паттернами писать код, как тестировать систему и в каком именно порядке строить продукт. Уступить коллеге в техническом споре или, упаси бог, согласиться на противоположное мнение для такого кадра соизмеримо с личным геополитическим поражением и клеймом позора на всю оставшуюся жизнь.
Кейс из палаты мер и весов. На одном из моих проектов устроили невинное, казалось бы, общее обсуждение: «Коллеги, а давайте решим, как мы будем работать с Git и ветками». Первые двадцать минут всё шло чинно-благородно: каждый эксперт важно извергал в пространство свое уникальное видение рабочего процесса. Но затем кто-то неосторожно, слишком громко хмыкнул в ответ на аргументы оппонента. Завязался спор на повышенных тонах.
Итог? Полтора часа. Пятнадцать взрослых, дипломированных мужиков с совокупной зарплатой в несколько миллионов рублей в месяц просто орали друг на друга, пытаясь доказать, чей подход к ветвлению репозитория более каноничен. Полтора часа оплаченного бизнесом времени улетели в трубу просто потому, что эго каждого участника не помещалось в комнату.
Стремление выбрать лучшее архитектурное решение из лучших, конечно, теоретически заслуживает уважения. Но давайте посмотрим на факты: ваш стартап с вероятностью в 90% закроется нахер уже через год из-за того, что у инвестора кончатся деньги. И вся эта ваша великая священная война за названия веток в Гитхабе не будет иметь вообще никакого значения в масштабах вселенной. Разве оно того стоит? Ну серьезно, ребята.
В таких условиях решать вопросы стандартными методами фасилитации и «демократического голосования» — это чистой воды утопия. Если дать этой банде свободу слова, они будут бесконечно рефлексировать, мериться авторитетами и топить проект в бесконечных дискуссиях.
Что делать? Правильный ответ — никто, блядь, не знает. Любой, кто продает вам на курсах «универсальную формулу построения кросс-функциональных команд», — обычный инфоцыган. Никакой серебряной пули не существует в природе. Всё индивидуально ровно в той степени, в какой люди уникальны и разнообразны в своих девиациях, а создание коммерческого ПО — это чистой воды творческий процесс, а не сборка табуреток на конвейере.
Тем не менее есть пара административных ломов, которыми можно вскрыть эту ситуацию и, как минимум, сэкономить время.
Вариант первый — классическая диктатура. На сцене материализуется сильный, авторитарный лидер, чей авторитет в команде безусловен и не оспаривается. Дальше события развиваются по двум сценариям. Либо вождь благосклонно выслушивает каждого придворного инженера и сам выбирает финальный вектор, либо он вообще никого не слушает и директивно спускает сверху приказ: что, как и в каком порядке делать. Все остальные беззвучно слушаются и повинуются.
Но спешу вас расстроить: оба сценария — так себе решения с точки зрения эффективности. Попытка играть в демократию и устраивать голосование большинства — это заведомо проигрышный, импотентский подход, потому что толпа (даже состоящая из сеньоров) никогда не гарантирует выбор технически верного решения. С другой стороны, если врубить глухого тирана, можно легко прохлопать позицию какого-нибудь тихого интроверта, чье предложение в данный конкретный момент могло бы спасти ваш проект от кассовой катастрофы.
Вариант второй — сеанс цивилизованной бюрократии. Это организованное совещание, где у тебя, наша куколка лучшего менеджера, внезапно есть жесткий регламент, вменяемый модератор, строгий порядок и план. Не так, как вы привыкли делать в своих стартапах: «Ой, пацаны, тут созрел вопросик, какой мини-пылесос для клавиатуры купить в офис, давайте срочно созвонимся на полтора часа всей компанией и перетрем». Нет.
Нормальная процедура выглядит так:
— Заранее готовится четкий спектр вопросов и предлагаемые варианты решения.
— Весь этот материал принудительно рассылается команде с требованием ознакомиться до созвона, а не во время него.
— Команда собирается в Зуме, где модератор сразу задает жесткие правила игры и темп дискуссии.
— Высказываются строго по очереди. Любые попытки перебить оппонента, съехать на личности и превратить совещание в колхозный базар пресекаются модератором на корню.
— Организатор фиксирует мнения, собирает их в кучу, аргументированно поддерживает или разносит позицию каждого спикера отдельно, после чего единолично принимает финальное решение.
При таком подходе ваши капризные инжинеры хотя бы будут пребывать в иллюзии, что их экспертное мнение кому-то важно, а сама процедура обсуждения имеет человеческий вид и не вызывает желания немедленно обновить резюме на Хедхантере.