Почему гибкий штат — это будущее разработки
Сначала разработка была ин-хаус, потом появился аутсорс, что будет дальше? Есть исследования, которые подтверждают, что следующее звено эволюции в работе над ИТ-проектами — это elastic staffing, или гибкий штат. В основе этого подхода лежит простая идея: для каждого проекта нужен свой набор людей.
Одна ИТ-команда не сможет создать приложение для фитнеса и портал госуслуг так же эффективно, как две более специализированные команды.
Но сегодня рынок разработки в большинстве случаев работает по старой модели: компания либо использует внутренние ресурсы, либо идёт к подрядчику, ресурсы которого фиксированы. Мы в Skipp (сервис разработки IT-продуктов) хотим познакомить вас с принципами гибкого штата и объяснить, почему такой подход выгоднее традиционного.
Что значит работа с гибким штатом?
Когда подрядчик с гибким штатом получает задачу, он участвует в обсуждении и берёт на себя роль технического партнёра, кофаундера. Это необходимо, чтобы лучше разобраться, какую задачу хочет решить клиент и какую команду нужно собрать.
Такой подрядчик не ограничивает себя и заказчика существующими ресурсами, а исходит из потребностей проекта. Например, если внутри компании нет людей с опытом написания серверной части для маркетплейсов, то подрядчик найдёт опытного исполнителя на фрилансе.
Наконец, работа в гибком штате не предполагает, что специалист подключён к проекту от начала до конца. Тестировщик подключается только тогда, когда появляется потребность в контроле качества, а дизайнер отключается, когда заканчивает ревью фронтенда.
Получается, что разработка по принципу гибкого штата — это работа с подрядчиком, который не просто принимает ТЗ и пишет код, а включается в задачу и вместе с клиентом создаёт решение. Затем он ищет подходящих специалистов и руководит процессом:
Почему это выгоднее, чем традиционная разработка?
1. Можно работать удалённо
В гибком штате сотрудникам необязательно находиться в одной комнате. Они могут быть из разных стран и часовых поясов и работать так, как им удобно. Главное, чтобы они держали связь с командой и добивались поставленных задач.
Работа из дома становится популярной и общепринятой. При этом, согласно исследованиям, неумение контролировать удалённых работников — главная проблема, по которой ИТ-компании отказываются от услуг фрилансеров и аутсорсеров. Так что чем раньше бизнес научится управлять распределённой командой, тем лучше.
В нашей компании Skipp все команды распределённые: сотрудники работают удалённо, часто из разных городов. Мы занимаемся разработкой, помогаем клиентам от идеи до создания полноценных ИТ-сервисов, поэтому часто ищем людей со специфическим бэкграундом. Таких проще найти, если не ограничивать поиск географией.
Один проджект-менеджер за время работы в Skipp успел пожить в Сочи и в Питере, дизайнер жил в США, были клиенты из Италии. Для работы с гибким штатом мы сделали собственную платформу для отслеживания задач и проектов, так что рабочая коммуникация не страдает от распределённой географии.
2. Продакт-менеджеры компетентнее — риски ниже
По прогнозам экспертов, рост популярности распределённых команд приведёт к возникновению нового поколения проджектов и продактов — креативных, гибких, работающих и над продуктом, и над бизнес-процессами одновременно.
Это логично: продакт — главный сотрудник в гибком штате. Он получает задачу, обсуждает её и набирает разработчиков под каждый проект. Работа с гибким штатом усиливает менеджеров, позволяет быстро набирать компетенции и насмотренность.
Компании, которые ведут разработку гибким штатом, продают не человеко-часы разработчиков, а интеллектуальный продукт — опыт продактов в области найма, их понимание бизнес-процессов и умение соотнести задачу клиента с технологиями.
Благодаря такому менеджменту подрядчик становится не исполнителем, а партнёром. Он помогает клиенту доработать идею и подбирает команду, поэтому разделяет ответственность за качество. Из-за более гибкого менеджмента в проекте снижаются риски.
Один из наших клиентов — кофаундеры b2b-маркетплейса для благотворительных организаций Sirius. Через этот сервис компании поддерживают благотворительные проекты. Мы помогли им доработать идею и сделали прототипы. Кофаундеры привлекли инвестиции, затем мы занялись разработкой.
Это был поворотный проект: мы окончательно убедились в эффективности модели гибкого штата и важности продакта с опытом в разных индустриях. Менеджеры в гибком штате быстрее набирают опыт, их ценность растёт, так что в решающий момент они могут определить исход проекта.
Сначала фаундеры Sirius полгода работали с разработчиками напрямую, но проект отставал от графика. Как только присоединился опытный продакт, работа пошла в несколько раз быстрее. Мы подключили две параллельные команды и уложились в срок.
3. Бюджет расходуется эффективнее
В традиционном подходе задачу передают штатным сотрудникам — даже если им не хватает знаний, или, наоборот, они слишком квалифицированы. В гибкий штат набирают специалистов с тем уровнем и компетенциями, которые нужны в проекте. То есть, разработчики будут с релевантным опытом и насмотренностью, и, скорее всего, смогут справиться с задачей быстрее, чем среднестатистический специалист.
В гибкий штат на проект берут только тех сотрудников, которые нужны прямо здесь и сейчас. Они отключатся от проекта, когда их задача закончится, поэтому на недогруженных задачами людей не придётся каждый месяц тратить бюджет. Компания, которая сделает вам гибкий штат, сама найдёт аутсорсеров, если это будет выгодно, или обратится на биржу к конкретному фрилансеру и оплатит ему только нужное количество часов.
В том же американском исследовании ИТ-команд с гибким штатом выяснили, что подобные проекты расходуют бюджет на персонал на 30% эффективнее, чем в ин-хаус разработке. Фрилансеров ищут по компетенциям под конкретный проект, он идёт быстрее, люди всегда заняты, на персонал в среднем уходит меньше.
Часто в Skipp приходят клиенты, которые провели уже несколько циклов разработки с аутсорсерами, а продукт всё ещё не работает как надо. Обычно нам удаётся сделать работающий продукт быстрее и за меньше денег, чем уже было потрачено на неработающий. Например, наш клиент LawApp распустил всю команду разработки и вместо штата нанял Skipp, потому что получалось выгоднее.
4. Работа распределяется равномернее: нет бессонных ночей и кранча в конце проекта
Гибкий штат состоит из опытного продакта, который вместе с клиентом поставил задачу, а также из набранных им разработчиков-фрилансеров, которые уже работали на похожих проектах. В итоге мы получаем команду, которая хорошо понимает риски и представляет итоговый вид результата.
Это помогает распределить задачи эффективнее и может избавить от классической проблемы кранча — ситуации, когда ощутимая часть работы делается за последние пару дней, потому что только сейчас команда полностью погрузилась в задачу и выявила все подводные камни.
Ещё одно исследование подтверждает, что фрилансеры в принципе могут более эффективно управлять работой и закрывать проекты, чем штатные менеджеры. Иногда проблема даже не в опыте, а в том, что внутри штата могут сформироваться сложные взаимоотношения. Конфликт между менеджерами за повышение может привести к тому, что оба плохо справятся задачами: перегрузят проекты лишним или изменят утверждённый дизайн в последний момент. Когда проектом руководит человек со стороны, у него нет конфликта интересов.
Однажды в Skipp обратился проект, где раньше были проблемы со сроками разработки: по разным причинам команде часто приходилось закрывать задачи в последний момент, они не справлялись. Когда продакты Skipp подключились к процессу, работа стала идти равномернее: за счёт правильной декомпозиции задач и приоритезации бэклогов уже второй релиз происходит день в день по плану, команда два месяца работает без срыва сроков.
5. Специалистам комфортнее работать
Важное преимущество гибкого штата помимо скорости и экономичности — положительная обратная связь от работников. По сути, это разработчики, менеджеры и дизайнеры на фрилансе, которые присоединяются к проекту через посредника. Их берут в гибкий штат, только если они подходят по профилю и опыту, а, значит, они получают больше удовольствия от работы: не нужно терпеть скучные задачи или доучиваться, чтобы приносить пользу.
Гибкий штат — это будущее разработки:
По статистике того же американского исследования ⅔ проектов с фиксированным штатом заканчиваются проблемами: клиент либо не получает результата, либо он появляется позже, обходится дороже или не соответствует требованиям. В проектах с гибким штатом ситуация намного лучше и вот почему:
- В такой модели можно быстро научиться управлять распределёнными командами. Сотрудники могут работать удалённо, даже жить в разных странах. Это новая норма, и гибкий штат помогает адаптировать к ней бизнес.
- Продакт-менеджеры в гибком штате быстрее набирают компетенции и опыт, качество управления растёт, снижаются риски. В проектах реже срывают сроки или не получают запланированную функциональность.
- Бюджет на персонал расходуется эффективнее, потому что людей нанимают под конкретные задачи и на ограниченный срок, а не на весь проект.
- Благодаря опытным продактам работа распределяется равномернее, проекты более предсказуемы, у команды меньше бессонных ночей.
- Сотрудникам комфортнее в гибком штате, потому что они превращаются во фрилансеров: могут выбирать проекты, оценивать стоимость своей работы, управлять графиком.
Клёво: 5 лет получаешь высшее айтишное образование, чтобы потом иметь стабильность заработка на уровне шабашника-плитоукладчика. А если у тебя чуть менее мейнстримовая специализация - то месяцами между проектами сидишь на дошике.
Так выживут только HR-ы, менеджеры и юристы.
К слову хорошие плитоукладчики сейчас зарабатывают на уровне айтишников, а то и больше. Заказывали как-то ремонт, человек пришел, все сделал за два дня, взял 35 000р. А у него и при этом очередь из заказчиков))
А качество? Как повезет?) Если не повезло - он переделывать будет?
Плиточник пришел, как можно быстрее все сделал - и сразу мозг насилует - яв се сделал, дай денег, я все сделал,дай денег.
Как только дал - все. Пропал и больше ты его не увидишь.
Хороший профессионал из рук в руки передается, он ценит свою репутацию, а за счет узкой специализации он руку набил так, что уже просто физически не может сделать плохо.
Это да. У меня тоже есть телефоны хороших мастеров. Работы расписаны на пару месяцев вперед
У фрилансера с каким-никаким кругом знакомств может быть несколько проектов с неполной загрузкой одновременно - так он равномернее распределяет риски потери работы, чем сотрудник в штате.
Само собой, чтобы не умереть от голода при таких раскладах нельзя принимать кабальные договоры о неконкурировании в течение пяти лет после увольнения и прочими изобретениями эффективных менеджеров.
надо было не образование получать а учиться.
Как показывает практика, лучше всего продвигаются троечники, которые сразу начинают мутить бизнес ещё с универа. А отличники постоянно ловят баттхерты от того, что коммерческий инжиниринг - это совсем не то, чему учили
я не за практику я за себя привык отвечать.
Если вы ставите стабильность на первое место, то зарплата у вас на последнем, так во всех сферах, где больше зарабатывают там меньше стабильности.
Как правило, чем меньше зарплата тем меньше и стабильность.
Учителя и врачи не соврут. Не сходил на субботник- все, тебе конец .
А чем выше зарплата тем больше и свобода.
Расскажите это CEO
Клёвая система. Я буду шабашить на проектах,переходить из фирмы в фирму,из проекта в проект.
Главное свою часть выполнить.
А потом,когда придут баги от заказчиков (тестировщик все не сможет выловить)- то..Фигаро уже там! Ищите меня!)))
И да, стабильность уровня строителя плиточника. Фигак фигак и в продакшн. И к следующему заказчику.
Насчёт счастья фрилансера- да, когда заказы и бабло есть,счастье есть. Потом клиент мудак или деньги кончились-опа,депрессия.
Повторить много раз.
И конечно,тут никаким ТК РФ и не пахнет. Одни сплошные ипешники.
Комментарий недоступен
Так и платить то будут только за "прямо сейчас". А потом пошел вон. Соотвественно, где экспертиза то будет? У бедного едиснтвенного продакта?
Схема хороша для каких-то типичных потоковых разработок. Да и то, с ньюансами.
С другой стороны, если тут говорят о том,что вся-вся разработка в будущем станет такой, то фрилансеры всего мира могут например объединиться в союз и выставлять единые рейты (по квалификациям).
А то интересно получается - мы тебя наняли на 2 часа работы, а потом ищи новую работу? Где и как этот разработчик будет развиваться в таком случае? Денег будет хватать впритык.
Спасибо за комментарии. Понимаем ваш опыт. Готовим материал об участии разработчиков в таких проектах. Есть много интересных тем для обсуждения)
Не вижу разницы с аутсорсом, у нашей компании вроде был подрядчик из Индии который так себя продавал. Но по факту если проект не совсем мелочь, то с ним надо жить чтобы начать его нормально понимать, знать проблемные места, знать где что лежит. Аутсорсерам же остаётся только пинговать ин хаус людей и делать задачи их руками в половине случаев. Если ещё сделать не просто аутсорс а акцент на текучке кадров как рекламируется в статье то страшно представить во что это выльется.
И подбор специалистов прям точно нужного формата (не слишком сеньор и чтобы именно это область уже знал) по щелчку пальцев тоже звучит нереально
То, что аутсорс делает задачи руками инхаус-команды - это кажется справедливое мнение.
Кажется, что построить процессы работы с аутсорсингом - история про совместные трудозатраты обоих партнеров.
А вот про подбор, что думаете, если нет ограничения по локациям хайринга специалистов, если они не ограничены, разве не проще попасть в цель?
В хорошем случае подберут такого же специалиста который грамотно себя продаст и подгонит резюме. И это будет стоить
Технологии очень быстро меняются, их очень много похожих в одной области и чтобы сотрудники обучались чему-то в процессе по мне норма, а вот навязчивое желание чтобы все всё знали наперед не совсем здоровое и симптом плохого менеджмента, во всяком случае в айти. Многие толковые кампании наоборот обращают внимание не на строгое соответствие знаний на данный момент а на способность мыслить и решать проблемы в первую очередь
Клёво
Интересно, а как с гибким штатом не в разработке? Будет такое работать в маркетинге / на стройке / в салоне красоты?
Пока айтишники только думают про это, на стройке эта система внедрена уже давно.
Все круто, осталось только найти способ привлекать хороших фрилансеров, стандартизировать и контролировать их работу ((
Возможно его и не существует. Но попробовать можно
Вот это особенно порадовало. Вы никогда не сталкивались с реальностью
А почему вы так думаете? Можете, пожалуйста, рассказать.
Я не думаю. Я - знаю! (с)
Вы никогда в реальности не найдёте ресурсы, которые у вас сложатся в красивый паззл. Это просто картинка, ничего не имеющая общего с реальностью.
Как вы будете искать эти ресурсы? Как будете проверять компетенции? Вас точно не кинут? Все разработчики надёжные и проверенные? Вопросов миллион
Skipp существует два года, наши кейсы можно посмотреть на сайте skipp.dev.
1) Все бы ничего, но потом ты читаешь литературу про Теорию Ограничения Системы и понимаешь, что проблема даже не в ресурсах, а в планировании.
2) Про более опытных продактов - с чего это вдруг? Мне кажется, что вы даже сами себе противоречите, потому что в одном человеке собрать универсального бойца, который понимает все, пусть даже базовые, аспекты разработки и при этом компетентен в бизнесе и стратегии, - ОЧЕНЬ сложно. Проще всегда держать 2 людей. Тот, что больше про бизнес и тот, что больше про разработку.
3) Про то, что не будет сорванных дедлайнов - хехе:))
Ну, при этом в целом с тезисом про распределенные команды я наверное спорить не стал бы, но аргументация довольно спорная. Мы опять ищем таблетку от всего. Скорее всего будут штатные команды и 1 на подхвате для тушения пожаров и помощи в узких местах.
Спасибо вам, все пункты по делу, на самом деле.
1) Всё так. Неправильное планирование, выражаясь языком теории, идёт тут как ограничение парадигмы, когда менеджеры строят процессы исходя из фиксированных ресурсов в штате вместо того, чтобы подойди к вопросу открыто и нанимать специалистов под каждую задачу. Например, в начале прототипирования проекта у дизайнеров вал работы, а в конце - ее почти нет, но никто не будет из-за этого увольнять человека из штата. Поэтому парадигма традиционного подхода в разработке и найме и будет этим самым узким местом системы.
2) Очень сложно, но возможно. Посмотрите вокруг – всё больше проектных менеджеров вырастают из PM-ов и разбираются и в метриках, и в разработке, и методологиях управления. Скоро это будет универсальным набором знаний для любого проекта, во всяком случае мы верим, что это наиболее выигрышная комбинация по скиллам у людей будущего. Что же касается настоящего, то наши продакты попадают на проекты исходя из отрасли и специализации. Если нужен проект в сфере интернета вещей, то мы привлекаем специализированного продакта именно с таким опытом.
3) Ну тут без лирики. Просто заранее видим кризисную ситуацию и быстро подтягиваем доп ресурс, "донанимаем" ещё одного человека на бэкэнд или привлекаем еще одного тестировщика.
Штатные команды будут закрывать в себе ценную для бизнеса экспертизу, сохранение и обслуживание которой внутри компании обосновано. Все остальные задачи дешевле, быстрее и спокойнее делать с помощью распределённых команд.
Я перед написанием очередного сервиса примерно также расписываю как все будет офигенно.
Skipp существует уже два года. Наши кейсы можно найти на сайте skipp.dev
Так и я не первый год программирую
Сферическая разработка в вакууме.
Отпишитесь через год, когда столкнётесь с реальной жизнью.
А можете рассказать нам пожалуйста про реальную жизнь? Год - это много, не думаю, что стоит ждать
Вот так вот сразу и про жизнь? Мы ж даже с тобой не выпили ни разу.
Год - это очень мало.
-
Можно, только в большинстве случаев это не эффективно, а зачастую банально невозможно по различным причинам. Кастрированные каналы коммуникации, психологические проблемы некоторых разработчиков от удаленки и далее по списку. Удаленка хороша, когда вы делаете что-то примитивное, а потраченные полдня на котов в интернете никто и не заметит. Тогда да, тащиться куда-то, чтобы потом там рассматривать полдня котов, выглядит сомнительной идеей.
Бюджет расходуется эффективнееВы же должны понимать, что если такая тема станет массовой - это же рай для FAANGов и близких по масштабу контор. Огромный рынок высококвалифицированных специалистов, готовых на многоденяк и корпоративные плюшки вместо беготни между шабашками. Всех хороших они заберут себе. Конторы помельче, которые заботятся о качестве продуктов, также будут хороший костяк держать при себе. А остальные будут переплачивать за объедки со стола, чтобы вырвать хоть сколько-нибудь качественного специалиста. Это работает в областях с планированием, вроде нефтянки какой-нибудь или мореплавания. Набрал команду и они за отведенный срок делают работу от забора до обеда. А условные разработчики прогнозируемо плодят только баги. Вы можете подумать "ну вот одни чуваки напишут, а потом индусы сядут поддерживать и фиксить баги". И так до первого бага или фичи, которые не потребуют перелопатить половину проекта вверх ногами потому что кто-то когда облажался при планировании архитектуры или не закладывал какую-то возможность. И вот уже ваши индусы идут на помойку и снова нужна команда хороших разработчиков. И еще сотне контор нужна. И вот вы опять переплачиваете.
Работа распределяется равномернее: нет бессонных ночей и кранча в конце проектаЕсть сроки, не укладываешься - неустойки и бесплатная работа. Не хочешь работать бесплатно в неоплаченное время - привет кранчи. А в офисе "ну сорян, я не смог, менеджер не придумал как покрыть мою немощь силами других, нужен месяц". И этот месяц будет оплачиваемым, а все издержки на работодателе.
Специалистам комфортнее работатьЧто может быть комфортного в совмещении должности менеджера самого себя и непосредственно своей специальности? Это же офигеть как комфортно жить с горизонтом планирования жизни до конца проекта, да еще и со всеми минусами ИПшной разработки: страховка здоровья на тебе, больничные нафиг, отпуска - отдохнешь неоплачиваемо между заказами. Красиво.
Для обеих стороны минусы очевидны, плюсы видны только в идеальном мире.
Комментарий недоступен
Статья написана теоретиком, никогда не сталкивавшимся с реальностью.
Очень вредная статья
Типичный аутсорс - взяли чела, отработал, ушел, сидим ждем новый проект и потом подбираем нового чела? :)))
вы не понимаете, это другое...
Спасибо, я понимаю, это то самое.
Если я правильно понял статью, тут взят идеал документации и качественного кода. Где для проекта сделан линтер. Где все четко по архитектуре, куча UML. И как указали выше, «как на стройке», все блоками и стандартно, ни шага в сторону. Система «четких» грейдов - похожа на утопию, тут если ты по маркетплейсам спец, то все это твоё кредо по жизни, ибо по грейду ты только к этому заточен. А как же развиваться? Может разраб смог не только в этом хороший продукт сделать. профдеформация?! Не, не слышали! Будет всюду типовые технологии и решения ибо париться не надо, и это проверенный путь для «гибкого» архитектора.
В итоге, рост только за свой счёт, все будут только думать о грейдах и как к ним прийти. Нетиповые задачи не решишь, так как такого грейда нет. Психологию и выгорание на полку. Ты, машина, хардкодный ИИ, с 2000 итераций по одной теме. Экономия понятна, но она для клиента - и тут логично этим светят, иначе, никто, ничего, не купит. А так как у клиента нет компетенций то и проверить работу тоже нельзя, что с этим сделать? Ничего! Круто. Ещё много чего можно тут рассказать, где-то я возможно утрирую, так как тут тоже не все кейсы расписаны, но.... Спорно! Господа! Спорно!
Автор статьи явно не следит за рынком вакансий, если говорит о "будущем развитии". Не скажу за ситуацию лет 10 назад, но уже лет 5 назад, когда менял работу, примерно 30% находимых мною вакансий были чисто проектными. То есть устроился, поработал на проекте 9 месяцев - всё, досвидули.
Если речь идет про не-айти компании, которым нужно что-то разработать для себя - это вполне хорошая стратегия. Тем более многие работают условно так нанимая фрилансеров на блоки проектов. Получается дешевле и выгоднее. Но все-равно надо иметь своего внутреннего сильного разработчика, который будет держать всю информацию вместе. Сам он может ничего и не писать, но должен грамотно давать задачи фрилансерам, проверять работу и скапливать инфу.
Если речь про айти-компании, скорее нужно больше постоянных сотрудников, которые не могут "просто уйти завтра потому, что новая задача не нравится",
Мне не зашел посыл, что люди-гвозди. Понятно, что мебельными гвоздями пол не собрать. И вот вам гибкий сервис по подбору гвоздей под ваш проект.
Дело в том, что в ИТ мы, как правило, имеем дело со сложными (запутанными) системами, где, зачастую, качество взаимодействие людей важнее чем экспертность, и не всегда команда топовых экспертов, которые вчера пришли в проект, будет жечь быстрее-выше-сильнее команды которая завалила/вывезла вместе уже не один проект.
Собественно про это доктор Такман 55 лет назад писал.
Всё так, Идея не нова. Проблем может и не быть, если репутацию не испортите.
Вопрос в том, сколько вы в себя вместите.
Вот у меня команда дизеров, и сам я Дизер. Специализируемся на HR-сервисах, сложных, запутанных, часто legacy. В итоге кто-то на фултайм забучен год, два, другие на часовой, но по-сути тоже на фултайм.
Приходят заказы, а спецов, за которых я бы лично ответил уже нет... пока не вырастим своих сеньоров и Лидов новых, брать больше не можем, иначе, взяв непроверенного сотрудника и кинуть к топам в компанию, можно сильно испортить репутацию и всё закончится 🤷.
Поэтому и вопрос: сколько вы сможете такими подписками набрать заказов, за которые сможете действительно отвечать, как за свои 🙃
Конечно будущее, ведь разработчиков можно кинуть, получив деньги от заказчика ) Собственно так skip и делает, на своём Горьком опыте убедился