Наш опыт эффективного подключения в качестве внешней ИТ-разработки

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

В каких случаях бизнес обращается за усилением команд?

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

Почему так происходит?

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

Для некоторых проектов команд из джунов и мидлов вполне достаточно, особенно если доля джунов невысока и есть время на их усиленный контроль и обучение. Но надо учитывать, что джун покажет хороший результат через 9–12 месяцев. До этого времени он будет тормозить команду: пока кто-то из более квалифицированных коллег его обучает, основная работа будет простаивать, и это придется учитывать при распределении задач (если в этот момент с обучающего спрашивать по стандартным нормативам, то он будет демотивирован и попросту сгорит на работе). Ситуация выравнивается как раз месяцев через девять. Но когда команда выходит на “проектную мощность”, обученных джунов и мидлов необходимо еще как-то удержать в компании, правда, это тема отдельного разговора. Однако если подготовиться к решению этих проблем, заложив время и ресурсы, схема с джунами и мидлами вполне работоспособна.

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

Например, мы как подрядчик научились сравнительно быстро масштабировать команды заказчиков, попутно решив проблемы мотивации и удержания специалистов уровня senior/middle через процессы, заложенные в основу нашей удаленной команды.

Сергей Марина

В каких проектах мы эффективны?

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

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

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

Сергей Марина

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

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

Важную роль для нас играют языки и технологии, применяемые на проекте. Немногие готовы осознанно заниматься развитием старой (legacy) системы. В теории можно собрать команду и из таких специалистов, и мы умеем их находить быстро и без потери в качестве. Но чтобы не уронить свою репутацию на рынке труда, стараемся участвовать в проектах, где применяются современные языки и технологии. Наш основной технологический стек по разработке – Java, Kotlin, JavaScript/TypeScript, Python. По тестированию – Java, Kotlin, Python, JavaScript.

Еще один важный момент – мы не работаем с горящими сроками.

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

Сергей Марина

К примеру, в сентябре 2017 года к нам обратилась крупная российская компания с предложением поработать на проекте с дедлайном в конце года. Несмотря на выгодное финансовое предложение, мы отказались от участия, поскольку проект был действительно масштабный, и после его анализа мы поняли, что «9 женщин не родят ребенка за 1 месяц». При этом переговоры об удаленном взаимодействии вместо приглашения наших сотрудников в офис заказчика и увеличении сроков ни к чему не привели. Наш опыт подсказывал, что это провальный проект, независимо от того, как решится вопрос с увеличением проектной мощности.

Несколько слов о практике

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

Кейс №1 – увеличение скорости выполнения автотестов более чем в два раза

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

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

Кейс №2 – опережение согласованного плана

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

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

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

Кейс №3 – ускорение создания и поддержки автотестов

Наши специалисты участвовали в тестировании продукта, предназначенного для операторов сотовой связи. Изначально клиент пришел к нам с задачей разработки и последующей поддержки тестового фреймворка для REST API. Мы подключили к проекту специалистов по Robot Framework, которые привели тест-кейсы к общему шаблону (Preconditions-Test-Postconditions) и расширили возможности Robot Framework дополнительными библиотеками, в том числе самописными – на Python. В общей сложности они написали более 1500 автотестов, увеличив тестовое покрытие с 5–10% до 70–80%.

Техническая статья одного из участников проекта (ссылка).

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

Автор: Сергей Марина (Максилект)

Наши статьи по теме:

Все статьи

Связаться с нами

Мы свяжемся с вами в течение 24 часов.