Привет, Хабр! Я Федор, ProductOwner в Росгосстрахе. В молодости будучи школьником, еще задолго до появления всяких «Вкусно — и точка», я какое-то время работал в Макдоналдсе. И тогда, конечно, даже не задумывался, что этот опыт окажется полезен в моей дальнейшей карьере в айти. Казалось бы, что общего у фаст-фуда и разработки продукта?
Но, думаю, сегодня ни для кого не секрет, насколько круто с точки зрения управления построена работа в «самом популярном ресторане быстрого питания». Внешний хаос на деле оказывается мощной системой разделения ответственности, которой позавидует любой тимлид.
Как устроена работа в фаст-фуде
Это выверенная до секунды система, где у каждого своя четкая роль.
Фритюр — готовим картошку и закуски;
Гриль — жарит котлеты;
Сборщики бургеров — удивительно, но собирают бургеры.
Кассиры — принимают и выдают заказы;
Менеджеры — контролируют работу (не вмешиваясь в процесс).
Никто не прыгает между ролями и не пытается объяснить товарищу, как лучше сделать. И что мы получаем, если переложим этот принцип на процесс разработки? А то, что каждый студент на своей, возможно, первой работе, сам того не зная, уже вовсю применяет SOLID.
Например, испортить картошку фри практически невозможно потому что все процессы стандартизированы и доведены до автоматизма:
При нажатии на кнопку в корзинку для фритюра упадет точно запрограммированное количество картошки;
Через 30 секунд картошку нужно встряхнуть, а еще через 2,5 минуты повесить на специальный крючок стекать масло;
В конце высыпать картошку и один раз посолить специальной солонкой, из которой высыпается ровно 20 г. соли.
Это именно то, к чему сегодня стремятся большинство компаний, — стандартизация и автоматизация процессов. И одним из самых эффективных способов достижения такого результата является развитие направления DevTools.
Что общего у фастфуда и DevTools?
DevTools (от англ. Development tools) — это набор стандартизированных и внутренних «своих» решений, которые убирают лишние действия и тем самым ускоряют работу или разработку.
DevTools призван унифицировать любое взаимодействие с определенным компонентом и дать понятный для пользователя интерфейс.
В итоге мы имеем такую картину.
Фаст фуд | DevTools |
Четкое разделение ролей — фритюрщик не делает бургеры, кассир не жарит котлеты. | Чёткие зоны ответственности модулей, сервисов и команд. |
Алгоритмы шагов — каждый знает последовательность действий, нет импровизации. | Скрипты, пайплайны CI/CD, шаблоны кода. |
Инструменты с фиксированными параметрами — спецсолонка на 20 г соли, диспенсер напитков, таймер фритюра. | CLI-инструменты, IDE-плагины, API с валидированными входами. |
Минимум человеческого фактора — качество и вкус одинаковые вне зависимости от смены. | Стабильный результат кода или сборки, независимо от разработчика. |
Скорость и поток — параллельная работа множества людей без конфликтов. | Автоматизация и параллельные процессы в разработке. |
Ключевые преимущества мне видятся такими:
Повышение эффективности команд за счет готовых решений;
Снижение порога входа для новых сотрудников;
Стандартизация процессов разработки;
Улучшение качества кода и продуктов;
Сокращение времени на рутинные задачи.
Для технической поддержки РГС это направление очень ценно. У нас в уже есть своя «фритюрница» в виде Портала Управления (о нем я, кстати, писал вот тут), где сотруднику не нужно использовать с десяток разных программ, он может работать в одной системе, у которой под капотом уже зашиты все необходимые функции и алгоритмы. Нет необходимости ходить в несколько учетных систем для поиска и копаться в документации очередного сервиса для взаимодействия с данными.
Работа по рецепту: почему это удобно?
Конечно, мы можем внедрять различные, уже готовые решения, но, как правило, они не покрывают 100% боли и требуют либо долгосрочной доработки под требования, либо поверх одного решения надстраивать еще несколько.
Без унифицированного решения вместо фритюра мы имеем 10 видов сковород для каждого случая, 5 видов масла для готовки, 6 различных мест хранения ингредиентов и далее, далее, далее…
Казалось бы, кто вообще станет работать в таком бардаке? Но попробуйте заглянуть как-нибудь из-за спины сотрудника технической поддержки, как он решает ту или иную задачу… Там можно увидеть и не такое.
Кто-то из коллег для доступа в БД использует DB Beaver, кому-то ближе pgAdmin/Ssms/Toad, другим — SQL Developer, а третьи жить не могут без VSC (Visual Studio Code) и хотят поставить туда еще сотню плагинов – в результате ни о какой стандартизации ПО речи не идет. С другой стороны, можно возразить: а какая разница, если человек выполняет свою работу?
Как раз эту проблему и решает DevTools. С его помощью можно определить единый инструмент для доступа в БД и единые алгоритмы для решения задач, а также предоставить свой собственный внутренний инструмент, в котором все лучшие практики уже будут зашиты в одну форму или даже кнопку.
