Все персонажи и события являются вымышленными. Любое совпадение с реально живущими или когда-либо жившими людьми случайно.
- Господи, мы все умрем! Все умрем! Теперь точно умрем!
- Успокойся. Что случилось?
- У нас такой бэклог, такой бэклог. Нам нужно больше разрабов.
- Сколько?
- Восемь. Нет, девять! А десять можно?
- Ну, так наймите. Мне их что ли нанимать?
- Директор по людям не может! Говорит бюджет скрипит и зарплаты у нас ниже рынка.
- Так, б***ь, ко мне в кабинет этого дармоеда! Это все? Тогда давай, иди – пиши код.
…
- Вот так, Сашуля, я живу который год. Успокаиваю, утираю всем сопли и подтираю ж**у.
Зачастую, после стадии MVP и получения инвестиций в раунде, продукт развивается достаточно хаотично. В большей степени ориентируясь на те контракты, которые удается подписать с потенциальным заказчиком, пусть даже на невыгодных для бизнеса и самого продукта условиях. Это объясняется и желанием нарастить выручку, и стать заметным игроком на рынке, и отсутствием опыта, и огромными амбициями стартаперов.
Как правило, в первые несколько лет продаваемый IT-продукт достаточно сырой и требует больших доработок. Чем больше контрактов и проектов заключается, тем больше и разнообразнее накапливается задач к работе. Вместе с ростом задач, растет опыт и вариативность решений, применяемые для каждого конкретного заказчика.
Исторически так сложилось, что проекты и программное обеспечение развиваются (как правило) без привязки к будущим продажам и системе управления самой разработкой. Будучи сложным продуктом – IT-продукты/услуги демонстрируют многомерность и вариативность своих возможностей исключительно при проектном подходе, что означает (как минимум на первых этапах развития компании) невозможность массового подхода к внедрению и продаже IT-продуктов/услуг. В том числе из-за этого, требуется большое количество часов высококлассных специалистов и экспертов. Этим во многом и объясняется продажа IT через энтерпрайз решения и индивидуальный подход.
Если говорить метафорически, то с каждой новой продажей ПО от основного ствола дерева отделяется новая ветка, растущая и развивающаяся в своем темпе и на своих условиях. Чем больше таких энтерпрайз проектов – тем больше веток и тем больше требуется людей, чтобы ухаживать за старыми ветками и обслуживать новые.
Из-за такого подхода, добавляя новую фичу или устраняя баг в основном продукте, есть вероятность возникновения проблемы в некоторых ответвлениях и реализуемых ранее проектах. Для его устранения требуются дополнительные ресурсы от тестировщиков до разработчиков, в зависимости от сложности возникшей проблемы.
- Все упало!
- Где упало?
- * *****!
- Что упало?
- Вообще все!!
- Заказчик орет, ничего не работает!
Силы команды направляются на восстановление работоспособности ПО, в рамках конкретного проекта. Новые проекты и продукты ждут, все остальные заказчики тоже ждут. Степень аларма может колебаться от «некритичного» до «огонь-пожар-горим».
С одной стороны, такой индивидуальный подход к управлению проектами и развитием компании способствует формированию аврального режима (или если говорить в рамках терминологии моей предыдущей книги, то режим называется «нам п****ц»), внутри которого люди на регулярной основе преодолевают препятствия, достигают результатов и живут в постоянном хаосе и стрессе. Этот режим в целом характерен для компаний, находящихся на начальной стадии своего развития. Однако для последующего роста (выручки, числа заказчиков, проектов, сотрудников и т.д.) требуется изменение пропорций в режимах управления с преобладанием рутинного режима (или «раз-два-три-повтори»).
Из-за особенностей рынка, а именно большой емкости и регулярно растущего спроса на IT-продукты (в том числе ввиду ухода зарубежных игроков и амбициозных задач для IT-сектора со стороны государства) – число заказчиков будет расти и для их обслуживания при текущей системе производства IT-продуктов будут требоваться огромные ресурсы, которых ввиду ограниченности рынка труда в требуемом количестве прямо сейчас нет.
Кроме того, индивидуальный проектный подход (при котором каждый проект развивается параллельно основному продукту/услуге) предполагает увеличение штата, а следовательно приводит к росту нагрузки на ФОТ. Даже с учетом привилегий и государственной поддержки в виде льготного налогообложения – речь идет о высоких постоянных издержках, уменьшающих рентабельность IT-бизнеса и при неумелом менеджменте, сводящих ее, фактически к 0. Даже если представить, что рынок труда разработчиков, тестировщиков и прочих – резиновый, наем и раздутие штата не решит проблему, т.к. с ростом проектов будет регулярно требоваться расширение числа высоко экспертного и дорогостоящего персонала (почти как сложные проценты и геометрическая прогрессия). Именно поэтому, подход с ответвлениями новых проектов экономически оправдан до определенной стадии развития компании и в конечном итоге, должен представлять собой либо минимальное число таких веток с фокусом на основной ствол, либо пересаживание ветки отдельно и передачи прав на ее обслуживание кому-то другому.
И если раньше бюджеты заказчиков позволяли продавать им IT-продукты по завышенной цене, не беспокоясь о комплексным подходом к ценообразованию, а на рынке присутствовало полтора землекопа небольшое количество игроков, то начиная с этого года ситуация изменилась и продолжает меняться. Кроме того, что происходит сокращение бюджетов у потенциальных заказчиков (потребителей рынка IT) крупные компании для обеспечения себе дальнейшего роста поглощают IT-стартапы и продают их продукцию под своим брендом (все тот же CTM, но теперь в IT). Это означает, что на IT рынке будет появляться все больше сильных игроков и компаний, которые раньше не претендовали на долю большого и жирного IT-пирога.
Для конечных потребителей это означает благодать. Внутри самого IT-рынка рост конкуренции и появления сильных игроков, в конечном итоге приведет либо к пересмотру бизнес-процессов внутри действующих на рынке IT-компаний, либо к их уходу (из-за роста издержек и невозможности конкурировать в т.ч. по цене и качеству с новыми, более сильными игроками).
Одним из ключевых решений, связанных с невозможностью роста новых проектов и обслуживанием старых, является работа по сокращению технического долга и появление в работе разработки… волшебного слова – МИКРОСЕРВИСЫ.
В переводе с технического языка на экономический, подход к микросервисам означает изменение технологии производства IT продукта таким образом, чтобы максимально упростить сложность каждой отдельной операции и действия. Это позволит привлекать к работе над операциями по «новой технологии» менее экспертный персонал, а значит снизятся издержки и повысится управляемость.
Адам Смит с его примером про булавки потирает руки, глядя как его подход к углублению уровня разделения физического труда адаптируют к интеллектуальному продукту. С физическим продуктом дело обстояло достаточно просто. Сначала один человек (суперэксперт – кузнец) полностью выполнял все операции по изготовлению булавки и в день производил только 1 булавку. Потом технологию раздробили на простые операции, привлекли менее квалифицированную рабочую силу (женщин, детей или кого-то из руко**пых, готовых работать за еду) и стали производить в день 100 булавок. Кроме того, что выросла производительность, сократилась себестоимость на производство 1 булавки, еще и отпала зависимость и потребность в дорогих и редких специалистах.
Дальше – больше (особенно больше после НТР), подход стали применять в других технологиях и производствах (автомобилестроение, самолетостроение, производство электроники, выпекание булочек и т.д.). С ростом и развитием IT-рынка пришла очередь менять технологию производства IT-продуктов, заменяя в конечном итоге дорогих и редких разработчиков, менее дорогими и редкими. А с учетом уменьшения численности населения в России и сокращением доли трудоспособного населения (только в период с 2010 по 2021 годы показатель снизился с 61,5% до 56% в среднем по стране), а также с учетом тренда life long learning (вот совпадение-то!) – переучивать придется многих и брать тех, что дают.
- Скажи, пожалуйста, какая цель внедрения микросервисов? – спрашиваю у директора по технике.
- Ну вот смотри, сейчас наши разработчики – это универсальные солдаты. Они могут все. Написать код любой сложности, выполнить практически любую задачу из бэклога, с учетом их грейда, разумеется. А с появлением микросервисов и внедрением этого подхода в нашем ПО, мы сможем привлекать менее универсальных солдат. Понимаешь?
Это кажется логичным и понятным. И безусловно у данного подхода в настоящий момент имеются проблемки с реализацией ввиду того, что изменение технологии производства интеллектуального продукта:
во-первых сложнее с технической точки зрения и требуется не только комплексный подход к ее реализации, но и системное изменение всех бизнес-процессов компании;
во-вторых, излишняя рутинизация приводит к усложнению процесса производства интеллектуального продукта, росту бюрократизации и вызывает отторжение у разработчиков;
в-третьих, переход на микросервисы возможен в случае, когда компания достигает определенной зрелости и имеет потенциал к росту.
В противном случае, это красивое слово представляет собой слив бюджета и ресурсов, с последующим накапливанием негативного опыта к данной инициативе. А как известно негативный опыт – хуже отсутствия опыта. Отсюда и скептицизм, и недоверие: «Видали мы ваши микросервисы. Просто модное слово, за которым ничего нет».
Если отбросить тот факт, что микросервисы удастся реализовать на первых этапах не всем, а на формирование и внедрение данного подхода к работе потребуется время, то у разработчиков и всех причастных к IT-отрасли еще есть время пожить в парадигме «Всегда будет так как сейчас».
Сам по себе подход к организации производства IT-продуктов/услуг с помощью микросервисов представляет собой всего лишь переход к формированию пула стандартизированных операций (большей его части) и более рутинному формату работы. Это позволит управлять растущими продажами и оптимизировать себестоимость, что в конечном итоге позволит повысить рентабельность бизнеса и радовать важных акционеров, которым так мечтают продать свои идеи и бизнесы молодые стартаперы.
С учетом аврала в бэклоге, огромную нагрузку и непрекращающиеся запросы в сторону разработки, переход на микросервисы будут продавать как сверхблагодать, чудочудное и диводивное.
- Вы забудете о бесконечных запросах!
- Вам станет легче жить!
- Вы сможете просто кодить!
С учетом активной стимуляции пассивного поведения персонала внутри IT-отрасли (особенно разработки), рутинизация производства IT-проектов (переход на микросервисы, где это возможно и целесообразно) усилит существующий тренд «травоядных мужчин» среди мужского населения, обладающих умственными способностями.
А вот это уже печально, но судя по всему – неизбежно.
ПС Обложка - кадр из сериала "Пацаны", режиссер Ф. Сгриккиа, С. Бойд, С. Шварц, Ф. Туа...
