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

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

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


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

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

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

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

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


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

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

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

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

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

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


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

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


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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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