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

Сначала в двух словах о проекте, с позиций которого я сегодня рассматриваю вопрос из заголовка. Не буду называть конкретных названий, чтоб не раздражать администрацию Хабра из-за несанкционированной рекламы, кому интересно, с легкостью найдет всю информацию. Итак, это молодая компания, которая получила контракт на разработку некоей промышленной системы. Промышленная система в данном случае предполагает сбор данных от различного промышленного оборудования, их обработку и выдачу рекомендаций различными способами (от верещания сирены до API). Тема на сегодняшний день очень модная — это Интернет вещей (IoT), большие данные, машинное обучение и все такое. На момент моего прихода в проект, команда уже была. За счет естественной текучки, она конечно меняется и я постепенно привожу ее к своим требованиям, но во многом приходится жить с тем, что досталось в наследство.

Причем про наследство я в данном случае говорю не в плане "плохой/хороший чувак", а в плане их привычек, стиля, стека, ожиданий и т.д. И вот с какими проблемами я сразу же столкнулся.

Насущные проблемы

Специализация по коду

За каждым разработчиком были закреплены определенные задачи, в другие он не лез. Вот такой диалог был обычным делом в самом начале:

• Надо сделать такие-то изменения в модуле X.
• Это код Пети (Васи, Маши, в общем, другого разработчика).
• Но Петя в отпуске.
• Ну дождемся.
• Мы не можем ждать, у нас система в нерабочем состоянии, у нас спринт заканчивается, у нас сроки горят.

Где-то месяц ушел на то, чтоб объяснить коллегам, что код, который они пишут в рамках своих служебных обязанностей, им уже не принадлежит, а принадлежит компании. И у нас не должно быть "кода Пети", а должен быть только код компании. И любой разработчик должен иметь возможность вносить изменения в любой модуль.

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

Специализация на круге задач

Значительная часть команды мне сразу обозначила свои предпочтения в виде:

• Я специализируюсь на бэкенде, мне фронтенд совсем не нравится, я не хочу им заниматься.

(Подобрав с полу челюсть) У нас здесь институт благородных девиц или коммерческая организация, у которой вполне бизнесовые конкретные задачи? Где я вам сейчас фронтендера найду под одну страничку?

Производство "велосипедов"

До моего прихода, команда несколько месяцев делала некие компоненты системы. Мой беглый взгляд на результаты их труда выявил сразу же такие прблемы.

1. Абсолютно все, что они делали, уже давно реализовано и лежит бесплатно под открытой лицензией в интернете. Просто потому что разработчики специализируются на Java-программировании, просто никому не пришло в голову поискать готовое. Что сказали делать, то и делали.
2. Все, что они делали, содержало серьезные ошибки. Нет, оно работало на разовых запросах, но нагрузочное тестирование приводило к отказу баз данных. Просто, как у Cassandra, так и у ClickHouse есть особенности. Работа с ними в Postgress-стиле для них губительна. Ну это просто следствие. Если бы взяли готовое, то и ошибок бы было меньше.

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

Дефицит компетенций

Мы находимся в боевых условиях. Это не игрушки, это работающий бизнес. Задачи падают такие, что не всегда есть специалисты по ним. Но решать их надо. В общем, определенный класс задач мне просто некому было поручать. В итоге пришлось их решать самому. И это мне очень сильно не нравится, потому что без меня работа по этим направлениям встанет.

Анализируем это

Что хочется сказать в целом по сложившейся ситуации на момент моего прихода в команду.

1. Специализация внутри команды была доведена до абсурда. Причем мне коллеги как раз и доказывали про то, что есть разделение труда и все такое.
2. Принятые решения на базе идеи о разделении труда, фактически заблокировали развитие проекта. Фактически была патовая ситуация, когда вся разработка встала.

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

Точнее даже не так. Нам нужно воспитать в разработчиках навык, который на Западе именуется как problem solving. Т.е. из людей, которые просто делают поставленные им сверху задачи в Жире с 9 до 18, нам нужно получить людей, которые нацелены на конечный результат, который получит заказчик и за который компания получит оплату.

Именно problem-solving feature в разработчике и является для компании ценностью. Не способность 5 способами написать цикл в Java 7, а способность быстро и эффективно решать бизнесовые постановки.

Решения и планы

Итого, цель известна, немного опишу те решения, которые были приняты и дальнейшие планы.

Запрет на владение кодом, перераспределение задач

Пришлось долго объяснять людям, что личного кода у нас нет. Вплоть до того, что тоталитарными методами пришлось перераспределять задачи, требуя от людей знакомиться с чужим кодом.

Обучение

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

Парное программирование

Очень хорошо подходит для передачи компетенций и решения сложных задач. Постоянно так разрабатывать бессмысленно, но для некоторых задач вполне эффективно. В основном команда нормально отнеслась к такому подходу. Но есть и те, кто наотрез отказывается работать в такой форме.

Инструктаж

Время от времени просто рассказываю и показываю новые и классические малоизвестные инструменты. Например, пришлось объяснять про DDD, а потом на ревью отправлять на доработку код, чтоб добиться разделения моделей по назначению.

Стресс-тестирование

Нет, я не ору и не ругаюсь. Здесь стресс в другом состоит. Дается задача на совершенно незнакомую тему и смотрю как человек реагирует. Зачем я это делаю? Прежде всего — это демонстрация что их ждет в дальнейшем. Еще раз напомню: тематика проекта IoT, BigData, ML. По всем не существует готовых специалистов с 20-летним опытом. Всем членам команды придется каждый день обучаться новым вещам. Тут у нас выбора нет: либо коллеги станут problem-solving разработчиками, либо они поймут, что не тянут и выберут себе другое направление карьеры. Тут просто вопрос вопрос выживания компании.

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

Новые люди

Сейчас мы набираем людей в команду. Как вместо ушедших, так и дополнительно. И, признаться, я не исключаю, что кто-то из команды не выдержит и уйдет. Сейчас приходится просматривать много резюме кандидатов и я хочу сразу обозначить критерии, по которым я выбираю с кем готов общаться. Если я вижу у крутого разраба в стеке только классику (Java, Spring, SQL), то резюме сразу идет в отказ. Каким бы он молодцом ни был, если он за годы работы программистом так и не опробовал что-то из модернового стека, то очевидно, что новые темы не для него.

Итого, я смотрю на наличие знаний чего-то из NoSQL, микросервисы, альтернативные языки (Scala, Kotlin) и т.д… Если будет присутствовать ультрамодерн в виде NewSQL, Serverless и пр., то это даже лучше. Возможно мы ни с чем из этого стека никогда не будем работать, но знание подобных инструментов демонстрирует способность человека развиваться и осваивать новые инструменты. Также интересен опыт участия в стартапах. Именно в стартапах развиваются problem-solving навыки.

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

Вводится Kotlin вместо Java

Котлин — это прежде всего одна из степеней защиты от консервативных разработчиков. Если человек освоил Котлин, то это уже само по себе знак его способности обучаться. С другой стороны, Котлин и вправду эффективнее Java

Еще один гвоздь ...

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

Но сейчас у нас новая реальность. Как только возникает однотипная работа, под которую можно заточить профессионализм, сразу возникает возможность АВТОМАТИЗАЦИИ. И, каким бы ни был профессионалом наш дровокол, вместо него проще поставить автомат по колке дров стоимостью от 20 тыс рублей до 2 миллионов. И ни с каким автоматом профессионализм человека конкурировать не способен.

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

Заключение

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

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

PS: Новые ребята, которые уже приходят в команду, меня очень радуют. Задачу, от которой отказался опытный Java-разработчик (потребовал 3 недели), новичок с опытом работы в 1 год решил за 2 дня.