Почему гибкий штат — это будущее разработки

Сначала разработка была ин-хаус, потом появился аутсорс, что будет дальше? Есть исследования, которые подтверждают, что следующее звено эволюции в работе над ИТ-проектами — это elastic staffing, или гибкий штат. В основе этого подхода лежит простая идея: для каждого проекта нужен свой набор людей.

Одна ИТ-команда не сможет создать приложение для фитнеса и портал госуслуг так же эффективно, как две более специализированные команды.

Но сегодня рынок разработки в большинстве случаев работает по старой модели: компания либо использует внутренние ресурсы, либо идёт к подрядчику, ресурсы которого фиксированы. Мы в Skipp (сервис разработки IT-продуктов) хотим познакомить вас с принципами гибкого штата и объяснить, почему такой подход выгоднее традиционного.

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

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

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

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

Почему это выгоднее, чем традиционная разработка?

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

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

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

Один проджект-менеджер за время работы в Skipp успел пожить в Сочи и в Питере, дизайнер жил в США, были клиенты из Италии. Для работы с гибким штатом мы сделали собственную платформу для отслеживания задач и проектов, так что рабочая коммуникация не страдает от распределённой географии.

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

Это логично: продакт — главный сотрудник в гибком штате. Он получает задачу, обсуждает её и набирает разработчиков под каждый проект. Работа с гибким штатом усиливает менеджеров, позволяет быстро набирать компетенции и насмотренность.

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

Благодаря такому менеджменту подрядчик становится не исполнителем, а партнёром. Он помогает клиенту доработать идею и подбирает команду, поэтому разделяет ответственность за качество. Из-за более гибкого менеджмента в проекте снижаются риски.

Один из наших клиентов — кофаундеры b2b-маркетплейса для благотворительных организаций Sirius. Через этот сервис компании поддерживают благотворительные проекты. Мы помогли им доработать идею и сделали прототипы. Кофаундеры привлекли инвестиции, затем мы занялись разработкой.

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

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

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

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

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

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

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

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

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

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

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

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