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

Когда нанимать разработчиков становится сложно, сосредоточьтесь на эффективности разработчиков

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

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

Рыбалка в пустом пруду

Пролистывая ленту LinkedIn, я вижу много сообщений об открытых вакансиях, особенно в области разработки программного обеспечения (конечно, здесь сказывается моя отраслевая предвзятость). Компании очень стараются привлечь таланты, но даже если есть преимущества, более чем конкурентоспособная зарплата, высокая роль, во многих случаях это не приводит к увеличению числа кандидатов, не говоря уже о найме.

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

Короче говоря: нехватка инженеров-программистов будет усугубляться, а не улучшаться, и просто надеяться на то, что рекрутинг приведет вас туда, где вы должны быть, чтобы предоставлять свои продукты и услуги, недостаточно.

Это как время: как бы вы ни старались, в сутках не будет больше 24 часов — единственное, что вы можете сделать, это лучше использовать имеющееся в вашем распоряжении время. Так что же вы можете сделать, чтобы ваши программисты и инженеры стали более эффективными и продуктивными (после того, как вы попробовали дополнительный кофе, конфеты и клубный мат)?

Поиск убийц эффективности в программном стеке

Конечно же, это не битье кнутом (попробуйте сделать это с разработчиками, и это будет последнее, что вы когда-либо видели от них),
и если вы уже рассмотрели такие вещи, как рабочая среда, динамика команды, управление временем, стиль руководства и другие «мягкие факторы» (которые заслуживают отдельной статьи в блоге позднее), вам следует перейти к рассмотрению вашего технологического/программного стека, чтобы найти существенных убийц эффективности, с которыми стоит бороться.

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

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

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

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

Так где же вам следует искать потенциал эффективности?

Несколько вопросов, которые помогут вам начать работу по повышению эффективности разработки:

1. Насколько современен ваш технический стек?

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

Это не означает, что используемый вами стек неэффективен в своей работе — на самом деле, я видел много хорошо интегрированных стеков типа legacy, которые работают безупречно и «делают свою работу» — но то, что мы ищем, это эффективность разработчика, поэтому вопрос заключается в следующем: сколько усилий требуется вашей команде разработчиков, чтобы изменить или отладить что-то в вашем стеке? И в этом отношении имеет значение, является ли ваш стек современным (обычно хорошо документированным) или нет.

В качестве примера, за годы работы в туристической отрасли я видел приложения для мэйнфреймов, написанные на COBOL, которые работали на большом количестве MIPS (если вам приходится гуглить это, то вы, вероятно, родились после 1980 года 😉 без заминок.

Однако в случае возникновения проблем или изменения программы старшие (по возрасту и опыту) программисты
должны были приходить с пенсии, чтобы позаботиться об этом, а изменения на хосте не для слабонервных.

Современный, однородный технологический стек является хорошим помощником для эффективной разработки программного обеспечения.

2. Насколько сложен ваш технический стек?

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

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

Например, vue.js и React оба являются отличными front-end фреймворками, но вам следует выбрать один из них.

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

Постарайтесь найти решения, которые не пересекаются в вашем стеке, чтобы все было просто и управляемо.

3. Сколько технического долга возникает со временем?

Технический долг — это остатки работы после того, как что-то было отгружено; классическая религия «мы исправим это позже».
которая почти всегда приводит к тому, что вещи не доводятся до конца и падают вам на ноги спустя годы, когда вы меньше всего этого ожидаете
(и в самый неудобный момент, конечно).

Технический долг может, но не обязательно должен быть показателем недостаточной эффективности. Если ваши команды постоянно сталкиваются с большим его количеством, повышение эффективности может помочь снизить объем технического долга, если руководство будет достаточно умным, чтобы не сокращать время, отведенное на выполнение определенных задач, одновременно.

Помните о техническом долге, так как он съедает вашу эффективность в предоставлении ценности и сокращает время выхода на рынок.

4. Сколько повторяющейся работы выполняют ваши разработчики?

Даже если Фред Тейлор хотел бы, чтобы ваши разработчики снова и снова делали одно и то же, чтобы стать суперэффективными, это не та эффективность, которая вам нужна (а разработчики не любят тейлоризм).

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

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

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

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

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

5. Сколько программных зависимостей приходится контролировать вашей команде?

По мере роста решений растут и зависимости. Если вы используете монолитную систему, это может быстро превратиться в кошмар для поддержки (если это еще не так), но даже в современной микросервисной архитектуре управление зависимостями через API может быть сложным, особенно если у вас есть целый зоопарк API, которые нужно подключать, поддерживать и защищать.

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

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

Подход WunderGraph заключается в автоматическом создании единого API для всех ваших источников данных, поскольку мы считаем, что разработчики не должны беспокоиться об отдельных API.
Фактически, каждый API, которым вам не нужно активно управлять, вернет вашей команде много времени, а если вы умножите это количество на все ваши API, то в итоге получите много времени, которое ваши разработчики смогут потратить на создание ценностей.

Зависимости — это большой рычаг для экономии времени разработки.

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

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

Да, эффективность разработки имеет значение

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

Будет ли это влияние достаточно глубоким, чтобы заменить найм новых разработчиков, зависит от размера команды и уровня неэффективности, но если вы сократите даже 2 часа в неделю от рабочей нагрузки команды из 5 разработчиков, это даст вам более чем однодневную отдачу от разработчиков в неделю. Представьте, что эта команда может сделать за месяц, имея на неделю больше времени на разработку.

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

Это хорошее видение, к которому стоит стремиться.