Нам не нужны кодеры, нам нужны инженеры-разработчики
Источник
Возможно, вы уже замечаете, что в IT-отрасли — новый кризис. Речь идёт не о том, что скоро разработчики будут заменены нейросетями. Программисты по-прежнему будут нужны, однако работать они станут совсем иначе.
Дело — в узком разделении труда. Когда-то оно началось — и пошло-поехало: разработчики мобильных приложений, контент-разработчики, специалисты по API, аналитики, тестировщики. Каждый погружён в свою узкую сферу и экспертно владеет темой. Каждого довольно легко заменить, и это несильно влияет на общий процесс.
Но сейчас глубокая специализация начинает тормозить IT-производство. По крайней мере, на себе мы это почувствовали и многое стали менять — оказалось, что правильно и вовремя. Сейчас я об этом расскажу.
Разработчик или инженер-разработчик?
Если рассматривать конкретно нашу организацию в финтехе, то нам нужны инженеры, которые нацелены на то, чтобы решать проблемы заказчиков и совместно с бизнесом зарабатывать деньги, упрощая процессы и архитектуру. В этом — суть профессии, и написание кода уже не должно быть главным в ней. Разработчики становятся инженерами и экспертами предметной области, которую разрабатывают. Их цель — обеспечивать эффективность IT-производства, а не просто делать свою работу ради работы.
Мы не можем позволить себе тормозить перед очередными заборами из серии «Эта работа моя, а вот эта — не моя», или «Получите продукт, который мы вам сделали, и разбирайтесь с ним сами. Да, и тестировать его — тоже не наше дело».
Нет, так дальше не пойдёт!
Инженеру-разработчику уже мало быть экспертом в своей предметной области. Теперь надо быть полностью вовлечённым в продуктовую разработку — во все её части. Надо понимать, где, что и почему, понимать смыслы. Разработчик должен принимать участие в предварительных исследованиях, проектировании, раннем моделировании бизнес-процессов, а затем — и в воплощении их в жизнь. Для этого надо постоянно учиться, расширять свой кругозор, в том числе и в смежных сферах.
Я считаю, что такой подход должен стать стандартом в сфере разработки, и именно так мы сможем справиться с проблемами, которые всё сильнее нам угрожают.
И, как иногда говорят, если вам кажется, что надо что-то менять, то вам не кажется.
Проблемы разработки
Нужен инженер, а не кодер.
Сейчас сложно найти или воспитать людей, которые готовы отвечать за всю цепочку разработки продукта. Реальная проблема — это кодеры, которые ждут постановки и стремятся уйти от коммуникаций с людьми. Как пример — тестировщик, который хочет стать автоматизатором и поменьше общаться. Но сам продукт, код, тестирование — это всё «побочный» эффект коммуникации, как говорил известный инженер Эрик Эванс. Код перестаёт быть активом. Только в коммуникации с бизнесом можно понять и тем более объяснить, как эта штука работает.
Инженер с широким кругозором, который ориентируется в архитектуре, в инструментах DevOps, во всём, что рядом с разработкой, может в этом разобраться. С одной стороны — понять, как твой продукт работает, как он попадает на пром, как он там крутится в контейнерах, какие метрики нужно с него снимать. А с другой — знание и стремление познать архитектуру предоставляет возможность понять, как этот продукт работает в архитектурном ландшафте организации.
Упрощай работу и не усложняй задачу
Часто разработчики не понимают, зачем они что-то разрабатывают. Как этот модуль, который они разрабатывают, может повлиять на общую систему или, скажем, на её производительность?
Неосведомлённость, нежелание разобраться в том, как работает сложная распределённая система в корпорации, приводят к неудачным архитектурным решениям и усложнениям. Даже в таких простых случаях, когда, например, нужно реализовать бизнес-процесс, который состоит из четырёх шагов. И тут разработчик начинает задумываться, а вдруг бизнес-процесс потом станет сложнее, а вдруг мы ещё что-то добавим. И вместо того, чтобы реализовать бизнес-процесс как есть, добавляет оркестратор.
Часто встречаются ситуации, когда люди пишут код, снимая с себя ответственность, перекладывая её на коллег, аналитиков, тестировщиков и кого угодно просто потому, что им самим сложно понять или не хочется углубляться в задачу. Это, в свою очередь, приводит к созданию усложнённой архитектуры — так называемой IT-коррупции, когда трудно понять, как всё работает, и все знания — только у держателей экспертизы.
Более профессиональным является подход YAGNI (You aren’t gonna need it), или «Вам это не понадобится». Т. е. необходимо отказываться от избыточной функциональности, в которой нет непосредственной надобности. Вот забавный пример, который я услышал от коллег: если ты оставил мобильного разработчика без дела, то он обязательно реализует новый архитектурный паттерн для мобильной разработки.
Профессиональный подход — это стремление к простоте, чтобы оставить после себя понятную систему, которая реализована эффективно и которую нетрудно поддерживать. Бизнесу очень важно, чтобы всё было сделано быстро, качественно и недорого.
В известном анекдоте говорится, что «одновременно сделать быстро, качественно и недорого невозможно. Выбирайте любые два пункта». На самом деле это уже не совсем так: профессионалы, инженеры-разработчики, как показывает практика, вполне способны разработать продукт качественно и недорого. И при этом быстро, не усложняя решения, соблюдая стандарты разработки и используя существующие наработки — нужно только захотеть так сделать. А для этого необходима прозрачность процессов производства и передачи экспертизы.
У нас в команде используются принципы APO (Avoid Premature Optimization) и KISS (Keep It Smoll and Simple, или, как иногда перефразируют, — Keep It Simple, Stupid). Надо реализовать то, что нужно сейчас, и сделать это максимально просто. Простота системы декларируется в качестве основной ценности. И, прежде чем дорабатывать или оптимизировать свой «кусок», надо разобраться, что уже разработано, что можно сделать или как это сделано, чтобы не повторять ошибок. Современный подход заключается в следующем: ты учишься на том, что уже создано у коллег или в других организациях.
Фрагментация и низкая эффективность разработки
Мы об этом редко говорим, но, в сущности, это катастрофа. Как сейчас происходит разработка? Бизнес-аналитики ставят задачу, а дальше начинают работать системные аналитики, которые анализируют систему и архитектуру, прорабатывая это решение… А всё это время разработчики сложили лапки и сидят, ждут, когда до них доползёт эта задача. Т. е., хотя у нас сегодня на рынке идёт Agile-трансформация, но чаще всего мы получаем Waterfall, упакованный в Agile-стримы. Всё это увеличивает Time to Market, уменьшая вовлечённость разработчиков. И опять выстраиваются этакие мини-заборчики внутри команды. Ты приходишь к разработчику и говоришь: «Вы тут всё сделали неправильно, здесь ошибки!» И получаешь в ответ: «В этом виноваты аналитики, мы тут ни при чём». И это постоянно повторяется.
Чтобы этого не было, уже на ранней стадии в проработку задачи должны вовлекаться специалисты из разных предметных областей и даже команды департаментов. Потому что, когда они все вместе садятся и начинают продумывать, как эта штука должна работать, часто можно найти ещё более эффективный путь.
Отсутствие включённости в общий процесс — это реальная проблема, она серьёзно влияет на эффективность работы. Разработчики хотят оставаться в своих узких «клетках», концентрируясь на собственных скиллах и не желая расширять кругозор.
Сейчас мы стараемся продвигать T-shaped-культуру, когда разработчики являются экспертами в своей узкой нише, но разбираются и в других областях. Они не то что пробуют себя в разных ролях, а обогащают свою экспертизу новыми знаниями, беря на себя более широкий спектр задач.
Вход в профессию и пирамида роста
Я считаю, что внедрением стандарта можно добиться больших успехов, чем привлечением мегаспецов. Сегодня большая часть задач для своего выполнения не требует суперкрутых экспертов и глубочайшего знания в узких предметных областях. Нужно иное! Нам не хватает правильного стандарта разработки, чтобы мы могли эффективно работать и при этом нам не требовалось бы много времени на погружение в него.
И мы, кстати, сейчас как раз разрабатываем такой стандарт. Он должен опираться на лучшие инженерные достижения в проектировании и разработке продуктов. Стандарт, при использовании которого в мейнстрим-разработке можно было бы обходиться без суперпрофи. Гораздо полезнее в этих условиях разработчики, которые разбираются в нескольких предметных областях, и пусть не так круто, но смотрят широко.
При работе по стандарту новичкам тоже легче ориентироваться и быстрее развиваться в профессии. Они будут учиться и расти, постепенно углубляться в конкретные области, оставаясь при этом в понимании общих смыслов и целостной картины. И ясно видеть свои перспективы.
Мы чётко определяем, что должен уметь начинающий разработчик и какие задачи ему доступны. Расписываем, что делает джун, что — мидл, кто менторит мидлов, кто разбирается в архитектуре. Всё это показано на пирамиде роста и создаёт прозрачную карьерную лестницу.
Повышение уровня инженерной культуры
Мы трансформируем инженерную культуру в банке, ориентированную на разработчиков (Developer Centric). Помогаем им наладить сотрудничество с междисциплинарными командами, включая дизайнеров, специалистов по анализу данных и экспертов в разных областях. Формируем стандарты профессии и разработки, стараемся создать структуру, позволяющую ускорить разработку за счёт применения ранее созданного кода, стандарта и построения пирамиды обучения. Мы видим своих сотрудников как Fullstack-разработчиков, которые понимают систему полностью: всё, что в ней происходит, — от интерфейса пользователя до бэкенда. Сейчас мы развиваем DevOps-культуру и активно применяем её к бэкенду, чтобы расширять компетенции разработчиков. Также прокачиваем компетенции тестирования, коммуникации с бизнесом, с коллегами, с бизнес-аналитиками, с системными аналитиками и так далее.
Значение стандартизации
Большая часть кода, который мы пишем, не требует для своего создания многолетнего опыта. При разработанном стандарте разработчики могут использовать уже готовые шаблоны и готовые куски кода. После введения стандартизованных правил наша кодовая база может использоваться повторно, поскольку многие задачи несильно отличаются друг от друга. В конце концов, мы же создаём не программное обеспечение для марсохода.
Мы стараемся создать эффективно работающий стандарт продуктовой разработки, который можно будет использовать не только внутри нашей компании, но и более широко — в любой другой IT-компании, которая разрабатывает продукты, интегрирующиеся друг с другом.
Сейчас у нас принят инженерный подход по принципу API-First, при котором API — это наш продукт. В какой-то степени это тоже стандартизация работы. Это означает профессиональное отношение к разрабатываемому продукту, с заботой о потребителе: делать максимально качественный, продуманный API и следить, чтобы этот API работал на всех стендах и никому не приносил проблем.
Такой принцип разработки относится и к зоне коммуникаций, поскольку мы стараемся облегчить дальнейшее взаимодействие с нашим продуктом. В частности, за счёт применения ранее разработанных образцов кода, которые другие разработчики могут посмотреть и использовать у себя.
Опираясь на наш опыт, кодовую базу и руководства, созданные на основе опыта лучших инженеров нашей компании, мы сможем быстрее разрабатывать бизнес-функционал. При этом мы будем оставаться людьми, которые понимают, как всё это работает.
Инженерная культура
Чтобы создать эффективную команду разработчиков, надо понять их мыслеполагание и обучить их, но прежде всего надо подобрать таких людей, которые готовы выйти за круг своих привычных действий и перестать быть спринг-программистами. И давайте уже избавимся от образа разработчика как какой-то «биомашины», которая получает на вход некое проработанное бизнес-требование и спецификацию, а на выходе отдаёт код. Нужно находить таких людей, которые готовы и разрабатывать, и тестировать, чтобы самостоятельно всё проверить. Которые способны без тестировщиков удостовериться в качестве своей работы и нести ответственность за свой продукт. Людей, которые способны самостоятельно задеплоить в продакшен своё решение, используя Blue-Green Deployment для минимизации риска, и удостовериться, что всё сделано качественно. Нам нужны SRE-инженеры, мы занимаемся их развитием. Нам нужны инженеры-разработчики. И это не наш уникальный подход, примерно так же создают эффективные команды в Netflix или Google.
Чтобы эффективно работать, надо основательно влезть вглубь задачи. Для примера: был такой безумный кейс, когда люди из команды разработчиков, чтобы создавать сложные биржевые приложения, какое-то время сами работали брокерами. То есть они хорошо понимали, чем они занимаются, и очень эффективно всё сделали. Это круто! Так раньше делали и мы: не было же никакой гранулярности. Многие разрабы говорят, что скучают по этому, потому что вся эта гранулярность мешает работать.
Психология разработчиков должна измениться. Теперь важно не делать разработку ради разработки, а вести бизнес вместе с заказчиком. Отвечать за результат, за сроки и быть готовым нести ответственность, не деля её между командами.
Для этого нужна профессиональная зрелость IT-сообщества, чтобы разработчики иначе понимали свою роль, а для этого нужна большая работа, чтобы не останавливаться после разработки кода. К примеру, вот выкатил я свой API, после чего протестировал его и поставил на мониторинг, чтобы, если он отвалится и начнут страдать мои потребители, команда первой узнала об этом и приняла меры. А на случай сбоя у меня в команде разработаны процессы, чтобы люди сразу пришли, починили, откатили и т. д.
Нейросети в разработке
Бум нейросетей привёл к разработке моделей-помощников программиста, которые способны писать кодовую базу. Появление таких технологий даёт дополнительный толчок процессу, в результате которого деятельность разработчиков должна ускориться. Я говорю молодым сотрудникам: «Если ты хочешь остаться просто кодером, то уже скоро тебя заменит какой-нибудь ChatGPT или YandexGPT. И произойдёт это довольно быстро». Теперь нужны инженеры, которые являются экспертами, понимающими, как работают система и сеть, как деплоить, настраивать и конфигурировать. Зная всё это, инженер может правильно задавать и верифицировать промпты для нейронки. Лишь понимая, чего хочу получить от модели, я смогу правильно поставить задачу такому цифровому помощнику и получить правильный код.
Более того, я могу обучать такие модели, вводя в них свои стандарты разработки. Как пример: модель выдаёт мне код по моему промпту, я его немного подправляю в соответствии с используемыми у нас стандартами, и следующий код, который мне выдаст модель, будет лучше, поскольку искусственный интеллект продолжает обучаться. Я прошу цифрового помощника написать мне тест, и модель мне его выдаёт. Я его также подправляю, и со временем модель делает код всё лучше и лучше.
Но, чтобы это происходило, нужен инженер, который способен правильно поставить задачу исходя из всего комплекса данных, а на основании этого — выдать нужный промпт.
Каким я вижу инженера-разработчика
Я выделил для себя девять пунктов, которые определяют разработчиков, какими я их хотел бы видеть у себя в команде. Итак, это:
1. Профессионализм. Профессионал — это человек с опытом, с одной стороны, и разработчик, опирающийся на лучшие инженерные практики, с другой. Понимающий разницу между идеальным и тем, что должно работать. Человек, который постоянно развивается и не менее постоянно использует существующие практики. Наше ремесло требует непрерывных тренировок, повторений, и здесь мы в чём-то похожи на профессиональных спортсменов.
2. Целеполагание. Разработчики часто относятся к своему коду как к ценности, пишут его, чтобы писать. Но разработка — это побочный эффект коммуникации, и её цель — достижение бизнес-результата. Разработчик должен быть экспертом в предметной области и при этом выходить за её рамки, становясь экспертом бизнес-домена, в котором он работает. Разработчик должен понимать, зачем он пишет код.
3. Ответственность. Разработчик должен отвечать за результат. Он должен быть вовлечённым в общий процесс. Это парадигма принципа API First, который мы продвигаем у себя в банке. API — это продукт, за который ты отвечаешь, который тщательно продумываешь и представляешь потребителю. Заботишься о нём. Отвечаешь за то, что получилось, за приложения, сроки и не боишься этого.
4. Сложность. Это наш враг. Инженер-разработчик должен соблюдать несколько принципов дизайна: KISS (Keep It Simple, Stupid), YAGNI (You Aren«t Gonna Need It) и APO (Avoid Pemature Optimization), то есть не усложняй код, не делай того, что не понадобится, и избегай преждевременной оптимизации.
5. Выход за рамки. Когда мы говорим об инженере, то имеем в виду способности и изобретательность. Инженер-разработчик — это человек, который вовлечён во все процессы жизненного цикла разработки. Он нацелен на решение задачи и способен выйти за рамки, не зацикливаясь на каком-то инструменте. Кстати, язык — это тоже инструмент. Это когда бэкенд-разработчик выходит за рамки, изучая мобильную разработку и нагрузочное тестирование, или когда мобильный разработчик изучает принципы дизайна и колористики.
Выходя за свои рамки, инженер становится более гибким и всегда может привнести что-то из одной области разработки в другую.
Это принцип T-shape, который мы развиваем у себя в банке, когда человек является экспертом как минимум в одной области, но при этом разбирается во многих других и может свободно поддерживать общение.
6. Инициативность. Это способность и желание инженера выходить из своей уютной среды, готовность помочь решить проблемы, которые возникают в работе команды. Понимание того, где возникают «узкие места» в производстве и желание помочь решить эти проблемы — это черты хорошего разработчика. Сейчас на вес золота — профессиональные люди, которые проявляют инициативу.
7. Коммуникации. Умение общаться с бизнесом, умение общаться с коллегами — важнейшее качество инженера-разработчика. Это помогает разрабатывать решение, взаимодействовать внутри команды, между командами и лучше понимать друг друга. Необязательно быть мегаспикером. Просто необходимо понимать, что разработчику важно общаться с заказчиком, ведь это делается для него. Хорошему специалисту нужно уметь слушать, по крайней мере, так же, как уметь говорить, писал в своей книге Ли Якокка.
Секрет успеха в разработке сегодня заключается в умении понять точку зрения другого человека и смотреть на вещи и с его, и со своей точки зрения. Основополагающий принцип — спрашивай, а не предполагай. Важно уметь просто проговаривать. Нет глупых вопросов, и не бойтесь показаться дураком. Ну, конечно, если вы не докучаете повторными вопросами об одном и том же.
8. Технологии. Это инструмент, и он не может быть ценностью. Это инструмент, который уместно или, наоборот, неуместно использовать в определённых ситуациях. Всегда надо думать, как эту задачу можно решить более простым и лучшим способом. Возможно, нам не нужен здесь сложный движок бизнес-процессов, как Camunda или CQRS, DDD. Наверное, можно просто писать на верхнеуровневом языке — таком, как Java в императивном стиле. И задача будет решена проще, и дорогой инструмент не занесёшь в решение. Иногда будет лучше «сделать свой велосипед», если это будет проще, в том числе и с точки зрения поддержки в дальнейшем.
Этот вопрос неоднозначный, и правильность решения всегда зависит от ситуации и уровня инженера: где-то этот «велосипед» нужен, где-то — нет. Я сторонник меньше использовать «велосипед» и больше опираться на Open Source. Именно на те решения, которые распространены в мировом сообществе, используемые в том числе нашими западными коллегами.
9. Развитие. Мы учимся на опыте, на правильных примерах, в общении с классными коллегами-инженерами. Без развития человек отстаёт и теряет карьерные возможности. При этом важно не только потреблять, но и отдавать, т. е. передавать свой опыт. Учить — это определённый вызов для себя: передавая опыт, начинаешь понимать свои сильные и слабые стороны. Когда кого-то учишь, растёшь и сам.
Когда я добиваюсь цели, начинаю обесценивать этот опыт, потому что я его уже получил. Но надо возвращаться в эти моменты и учить людей, которые на минус одном уровне. Это позволяет не потерять полученный опыт. Когда я общаюсь с людьми на разном уровне, то понимаю, что у всех, с одной стороны, учусь, а с другой — могу принести больше пользы, передавая свои знания. Даже у джунов можно чему-то научиться!
