Стартапы (особенно ИТ стартапы) и экономика стартапов

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

Как это на самом деле. За очень редкими исключениями. Цинично, и по существу. Хитрый финансист, не желающий, свой, не сильно праведно заработанный капитал вкладывать  «в долгую», организовывает структуру, которая рекламируется, как фабрика стартапов. Суть её работы: вы приходите с любой хернёй, которая может никому и не нужна, показываете, как это можно впарить обывателю-дураку, верящему в чудо/банкиру недоумку/спекулянту на таких же недоумках. Набираете рабов, которые за призрачную морковку на горизонте с надписью «доля в прибыли» в кратчайшие сроки и в адских условиях кодят/пилят/паяют неведомую фигню. Если это кодинг, то обязательно нужны все внешние карго-культовые атрибуты типа Аджайла/Скрама, и портрета Джобса во всю стену, закрывающего дыры и отвалившуюся штукатурку.  Обязателен внешний антураж в виде выступлений на технологических конференциях для таких же рабов, которые в результате начинают думать, что прогрессивные стартаперы это они и есть, а не тот ушлый манагер, который их продал организатору фабрики стартапов. Т.к. рабы далеко не безграмотны и чаще всего реально владеют определенными технологиями, им всегда есть о чем поговорить.  Плюс спонсором этого шоу обычно является тот самый владелец фабрики. В силу закона больших чисел 99% таких стартаперских затей проваливаются, не успев сделать вообще ничего, но неплохо собрав денег, в том числе и со сторонних инвесторов-лохов «в рост и перспективу». Часть на каком-то этапе обязательно палится на откровенном кидалове инвесторов, тогда это объявляется, как очищение святых прогрессивных рядов от недобросовестных конкурентов. Если сварганенная фигня может быть хот как-то применена на практике, компанию начинают судорожно и с массой подтасовок готовить к продаже на бирже, что торжественно обзывается «выходом на IPO», и как-то до сих пор прокатывает с массой пустышек. Они же, при стабильно убыточной работе, становятся далее предметом торга и дальнейших спекуляций для тех, кого не пустили «в нефть/металлы». В плюсе: организатор фабрики, наёмный или добровольный погонщик рабов, кстати, часто искренне считающий себя инноватором, изобретателем и идеологом этого конкретного стартапа. В минусе – все остальные. Что на выходе: сгоревшие разработчики, которые вполне могли принести реальную пользу, работая в другом нормальном месте, создавая хоть что-то ценное. Отвратительного качества продукты и сервисы, к которым по-хорошему нужно сразу прикладывать многомиллионные иски за несоответствие заявленным качествам, но толератно-тактичное общество это жрёт, приговаривая «мы за прогресс, надо потерпеть, дальше будет лучше, но не сразу». Самое плохое: стиль работы на выгорание становится примером для многих работодателей (вот, они же смогли?) и, что ещё хуже, возводится в культ: «только так работают профессионалы». Для нормальных профи на своём месте становится упрёком: вы не горите на работе. Колоссальный отток капиталов, которые могли финансировать длинные ценные проекты в эту короткую спекулятивную кухню. Кончится это наверняка пузырём, как в своё время доткомы. Второй существенный минус. Появляется желание поиграть в стартап. Как у бизнеса, который хочет казаться прогрессивным, финансируя неведомо что, так и у не прибитых никуда разрабов и затейников с менеджерской хваткой. Пока пилится продукт зарплаты могут быть очень даже неплохими. На выходе в лучшем случае велосипед среднего качества, в обычном – «не взлетело, это был риск, закрываем».

Итого: пора заканчивать толерантно относится к обману потребителя и инвестора и перестать воспевать «феномен стартапов». Это просто создание ещё одного рынка пустышек, которое добром не кончится.

Методология разработки AGILE*.  Продуктовый подход в инсорсе

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

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

Уже долгие годы замечаю интересную тенденцию, что те 1С-ники, с которыми меня столкнула работа, делятся весьма чётко на душных мудаков тихушников и классных спецов нормальных людей по одному простому признаку: постоянные они сотрудники или наёмные из внешней компании. Как-то вот не складывается работа на окладе в больших компаниях у инициативных и порядочных (это важно!)  специалистов-разработчиков 1С. Уходят в аутсорс. Достоверно не знаю, как обстоит дело у разработчиков на других платформах и языках, но не думаю, что разница принципиальна.

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

У работника по найму в разработке на окладе всегда есть периоды, когда загрузка падает до минимальной. У более-менее людей с совестью (ого, совесть в 21-м веке) это вызывает некоторый дискомфорт. Деньги идут, отдачи нет. У людей, которые не сильно профессиональны, но существенно менее совестливы такие периоды вызывают дискомфорт тоже, но по другой причине. Появляется страх сокращения, а идти особо и некуда, т.к. квалификация невысока. Естественное разделение. Вот оно откуда.. Ушлые менеджеры, которые чаще всего совестью не обременены, нашли выход, как убрать дискомфорт и угрозу своему существованию и как снять напряжение у оставшихся, не сбежавших «специалистов». В инсорсе в результате нехитрых манипуляций сознанием Заказчика, т.е. владельца компании, тоже вводится и насаждается понятие Продукта. Бинго! Вместо выполнения конечной задачи с конечными сроками теперь можно бесконечно долго пилить одно и тоже, навешивая не всегда нужную функциональность, меняя технологии (все сейчас в контейнерах и на S3, нам тоже критически важно туда и именно сейчас, кто опоздал, тот проиграл!). Бизнесу не надо показывать окончательные сроки, боль дедлайна размазывается на мелкие боли. Защищать стоимость Проекта не надо. Проекта же нет. Главная задача этого подхода: исчезновение даты окончания разработки и передачи результата в эксплуатацию. Как-нибудь сами, навсегда. Разработка становится вечной, зарплата всегда оправдана. Выгода вторичная: баги и косяки всегда имеют обоснование: мы пилили фичу срочно, в следующем спринте исправим. Минусы: разработка ведётся оставшимися ресурсами, которые приняли такую ситуацию, как должное. Многим их них стыдно, но они никогда в этом не признаются: «Это же мэйнстрим, все так работают, мы прогрессивные Скрумщики, а не какие-то замшелые ватерфоллисты.» Бизнес видит, что концов уже не найти, остальные коллеги по несчастью смирились тоже, управленческий строй поддерживает всячески миф о прогрессивности и эффективности Продуктового подхода. Гибкие методологии разработки тут подходят идеально, их распиаренная популярность великолепно закрывает вопрос совестью и сомнения у того, кто это банкет транжирства оплачивает. На выходе: стоимость владения такими инструментами в разы, иногда на порядки выше, чем покупка немодного готового адаптированного решения. Инструмент (Продукт) никогда не работает так, как это нужно заказчику, эффективность низкая, а значит и себестоимость того, чем бизнес это безобразие оплачивает тоже растёт.

Итого. Я предполагаю, что пора честно наконец признать: Продуктовый подход и гибкие методологии разработки не являются волшебным стандартом, который надо проталкивать везде. В большинстве случаев от Продуктового подхода вреда гораздо больше, чем пользы.

И последнее на сегодня, DevOps**-ерское безумие

Плюсы: иногда это работает. Как великолепно описано в книге «корпорация Феникс» работать с мудаками нельзя. Если на стороне разработки сидят ленивые ортодоксальные ботаны, которым нормально ввалить в файловую структуру миллион файлов: «а что такого, код же красивый», а на стороне инфраструктуры сидят динозавры, накатывающие ось на железо, за ещё и вручную через GUI, то явно что-то идёт не так.

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

Минусы. Это не то, что в жизни.  Сейчас мне скажут, что это же и есть DevOps! В книге всё же расписано, и непрерывное тестирование, и непрерывная доставка изменений, и подготовка сред выполнения, как кода самими разработчиками. Все разбираются досконально во всём, все такие лапочки, что только порадоваться можно. А когда задолбало покупать серваки стойками, то все дружно ушли в облако и настало счастье. Фигак и занавес.

Так вот это оптимистичное описание ничего общего не имеет с реальной жизнью и с тем, что нынче называют DevOps подходом. На практике обычно появляется кучка (или один-два) разрабов, которые узнали, что «DevOps-ам много платят» и они решили по верхам (иногда и глубоко) пройтись по модным темам, типа K8S, Helm, Terraform. Даже ничего не понимая, и не считая нужным понимать, что базы не в воздухе размещены и живут, а на дисках, не по воздуху приходят, а по сети, не в вакуум, а на вычислительную ноду, которая будь хоть сто раз вложенно виртуализирована, один чёрт работает на процессоре с какой-то своей специфичной архитектурой и особенностями. Что тупо добавить памяти не всегда приводит к росту скорости. (Про NUMA они наверняка вообще никогда не слышали.)

Эти «девопсы» начинают неплохо, пока всё живёт по-старому, на настроенной специалистами платформе, потом потихоньку начинают городить дичь, перестают быть вменяемыми при общении с другими профессионалами и в случае неизбежных факапов всегда находят на что свалить сорванный SLA. На тяжёлое наследие легаси, разумеется. И старое железо, от которого пора избавиться..

В чем же проблема? А она в том, что нельзя любого «многостаночника» автоматически называть девопосом, на девопса нельзя выучиться «с нуля». Должен быть багаж и опыт за спиной, и желательно не узко прикладной.  Нельзя такому «девопсу» отдавать безраздельную власть над проектом и уж тем более над инфраструктурой. Специалисты сетевики, как ни странно, очень даже нужны. Как и системные инженеры, и DBA со знанием особенностей СУБД. Надо перестать платить конские деньги просто за знание модных технологий и стеков, начать считать TCO и понимать, что подход «смасштабируемся, если что, горизонтально» чаще всего изначально неправильный. В общем, тут не столько по вред DevOps, а про вред модных шарлатанов. И недобросовестную эксплуатацию модного термина. Но так недалеко и до того, что рациональные вещи скоро тоже будут хейтить только за то, про них какой-то реальный  адекватный DevOps положительно высказался.

Ну и последнее, про «все в облака!». Хоть здесь наконец-то мировой разум немного пришёл в себя, вывесил лозунг «Cloud repatriation!» и пошёл верным путём, в гибриды.

Итого: на надо «всё в девопс». Чаще всего вам это не нужно, либо не по карману. А то, что по карману не является тем, чем названо.

А что Вы считаете вредным и требующим адекватной и справедливой реакции общества?

Добра всем, жить своим умом, разума и процветания!
*) Agile — это группа методик для гибкого управления проектами в команде разработки. Рабочий процесс при таком подходе разбивается на небольшие временные промежутки, их еще называют спринтами
**) DevOps — это не конечная чётко определённая цель, это движение, по которому идёт вся компания. Это способ разработки программного обеспечения. DevOps — это когда люди, технологии и процессы объединяются ради одной миссии — клиент-ориентированности.