Платформа
В любой софтверной компании, которая перерастает определённый уровень (несколько лет работы и 10+ разработчиков, примерно), со временем, начинает выделяться такая штука, как «платформа» — набор фреймворков, библиотек, базовых инфраструктурных вещей, которые являются общими для всей компании и используются повсеместно. Например, некая абстракция для доступа к хранилищам данных. Или более высокоуровнево — сервис управления пользовательскими данными и авторизацией.
Такую платформу пытаются делать «правильно» и «вылизывают» до совершенства, внедряя всякие технологичные вещи.
Продукт
На базе этой платформы и строятся продукты компании, которые приносят денег (или, по крайней мере, обслуживают пользователей, если вы Uber). Продукт, при разработке, часто ставит требования к платформе (которая, сама по себе, не имеет смысла), платформа это дело реализует, в меру своих возможностей, и вся компания бодро двигается дальше.
Продукт делают так быстро, как могут. Потому что от этого зависит прибыль (или другие показатели, её заменяющие). Поэтому тут чик-чик и в «продакшен», не всегда есть время на технологичность и правильность.
Проблема
Такую схему взаимодействия и организации команд я видел во всех компаниях, где работал, и во многих компаниях, куда проходил «собесы». Названия могут варьироваться, но суть остаётся той же: в тылу сидят люди, которые «пилят» танчики и отправляют их на фронт, где идёт вся движуха.
Платформенные разработчики имеют свои метрики и свои интересы (и к тому же не склонны сами пользоваться своей платформой), а у продуктовых разработчиков нет времени разбираться: нужно выкатывать «фичи» быстрее и быстрее. Стратегия против тактики, долговременное планирование против краткосрочных задач.
Человек есть человек, поэтому, со временем, вокруг платформы выстраивается забор с колючей проволокой и вышками, внутрь пускают только по визам, а сами визы рассматривают и выдают очень долго. Люди снаружи (продукт) смотрят на всё это безобразие, плюют и решают строить свои собственные танчики. Пусть иногда без башен, гусениц или без заднего хода, зато могущие ехать в бой и приносить пользу прямо сейчас и здесь.
В итоге, платформа всё дальше отдаляется от реальных пользователей и начинает жить сама по себе, а продукт всё больше становится нагромождением «техдолга» от краткосрочных решений.
Руководство всё это видит и издаёт эдикт «Подружить платформу с продуктом, выпилить "костыли" и сделать красивое решение». Что, по факту, превращается в ещё один бесполезный кусок платформы, который является компромиссом и не подходит никому. Да и, к тому же, устаревает ещё до момента выкатки в «прод».
Решения для команд
- 1. Ротировать инженеров: платформенных отправлять в бой, чтобы хлебнули лиха, а продуктовых — в тыл, чтобы использовали там свой боевой опыт. Вроде, идея хорошая. Но люди имеют склонность очень быстро «переобуваться». И вот уже вчерашние апологеты консистентности и коррекции сегодня, как ни в чём не бывало, лепят «костыли» абы работало, потому что им (внезапно!) нужно продукт выкатывать, а не городить красивые абстракции.
- 2. Формировать кроссфункциональные команды из инженеров обоих типов, которые бы, в синергии, могли усидеть на двух стульях. Уже получше, но тоже имеет склонность скатываться в локальные экстремумы.
- 3. Ещё можно всё бить на супермикросервисы, которые теперь начинают не дружить ещё и друг с другом. Но я в такой парадимге не жил. Могу только предположить, что там политики в 10 раз больше, чем в первых двух вариантах.
Решения для человека
Я очень много проработал именно в платформенной разработке. Оглядываясь назад, могу однозначно сказать, что лучше бы я занимался продуктами и проектами. Удалённость от заказчика и минимальное взаимодействие с бизнесом притупляют чувство реальности, отдаляют работу от результата, размывают ощущение вклада в общее дело и, часто, демотивируют.
Все лавры получают продуктовые «разрабы», которые «вытащили» проект и «отсатисфачили» «кастомёра», а не кучка тыловиков, которые только мешали своим вахтёрством делать вещи.
Кому-то может быть интересно сидеть и пилить красивые абстракции, но, во-первых, их и так испоганят проектные ребята, а во-вторых, почему бы не делать то же самое на проекте? :)
Автор: rozho)))k.