Почему в России все еще не умеют заниматься аутстаффингом разработчиков

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

С чем приходится сталкиваться на практике, и как получить рабочие руки, а не проблемы — рассказывает Андрей Лядков, фаундер агентства Staff-Hub.

Аутсорсингом в формате “Аутстафф” мы начали заниматься еще тогда, когда эту услугу так никто не предоставлял, но потребность у рынка в аренде разработчиков и программистов уже была. Приходилось объяснять, что же это такое, что это за формат и как это работает в части «аренды разработчиков», впоследствии те, кто работал в модели T&M, сказали, что это тоже самое и они уже 100 лет занимаются аутстаффингом )

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

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

Данная статья — не учебник для новичков, но, опираясь на свой опыт, постараюсь «подсветить» те моменты, которые помогут обойти часть граблей, разложенных на пути любой компании, выходящей на рынок аутстафф-услуг. Мы всегда обращаем внимание наших партнеров на это, ведь само понимание возможных рисков — это почти готовый ответ на вопрос: «Что делать, чтобы не было проблем».

Аутстафф — не просто хедхантинг

Модель IT Аутстаффинга — это не «отдал специалиста, и дальше это проблемы клиента», а для агентства это не «купил сотрудника подешевле, продал подороже». Мало подобрать специалиста, и предоставить его клиенту. Да, технические функции контроля и планирования разработки делегируются на сторону клиента. Но мотивация, трудовая дисциплина, hr-менеджмент — остаются в зоне ответственности исполнителя.

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

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

Это бизнес, а не случайный проект

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

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

Результат: сотрудник в стрессе, компания несет репутационные потери, а клиент теряет время на онбординг нового разработчика. Чтобы этого избежать, важно заниматься внутренними hr-процессами и менеджментом специалиста, быть с ним в контакте, вовлеченным в его проблематику.

Какие проблемы могут возникнуть при решении компании предоставлять специалистов в аутстафф? Вот некоторые из них:

  • предыдущий опыт и отраслевая экспертиза в IT-сфере чаще всего неприменимы;
  • портфолио реализованных проектов не работает, нужна квалификация и компетенции конкретных разработчиков;
  • аутстафф ведется в формате «white label», а значит и поддержку основной разработке аутстафф обратно не даст;
  • процессы, отлаженные для внутренней продуктовой разработки, не работают в аутстаффе;
  • сам специалист становится значимой единицей услуги, его ценность как конкретного исполнителя для клиента возрастает;

Подготовка к проекту

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

Особенности, которые надо заранее проговорить со специалистами:

  • у специалиста возникает два руководителя, с одним он решает все технические и проектные вопросы, с другим все организационные;
  • объяснить особенности white label;
  • объяснить, что это в принципе нормальное развитие отрасли, и умение работать в таком формате сейчас такой же полезный навык, как и понимание процессов классической разработки;
  • возможны дополнительные требования от службы безопасности, компания и сам специалист должны быть к этому готовы;

В противном случае — сотрудник может не понять или даже испугаться, и просто откажется работать в новом для него формате.

Перед стартом проекта, надо быть готовым к ряду проблем:

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

У клиента при этом свои фобии, с которыми надо работать, особенно если у него слабый или отсутствующий опыт в аутстафе:

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

Этап подключения — онбординга на стороне клиента недостаточно

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

Трудностей на онбординге меньше не становится, разработчикам все еще нужна помощь и поддержка:

  • подключение и поиск места в новой команде — это стрессовая ситуация для специалиста;
  • к специалисту могут быть предъявлены чуть бОльшие требования, а он по незнанию может испугаться дополнительной ответственности;
  • на момент подключения ставятся акценты на навыках специалиста, которые для него не приоритетны, например fullstack разработчик больше любит работать с беком, а в проекте на него рассчитывают как на фронтенд;
  • процесс подключения может затянуться, а специалист, оставленный без внимания из-за бюрократических проектных моментов, не находит себе места;

У клиента тоже ряд проблем, которые требуют проработки:

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

Очень важно на этапе подключения настроить инструментарий коммуникаций и заранее собрать первичную информацию по специалистам. Для этого мы в Staff-Hub проводим целый комплекс мероприятий:

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

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

Этап реализации проекта

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

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

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

Например, со специалистами:

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

С клиентами тоже немало рисков и трудностей:

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

Как следствие у компании предоставляющей услугу:

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

В Staff-Hub мы используем VMCRM в своей повседневной работе для систематизации управления кадрами в процессе сопровождения проекта. Роль «сигнализации», предупреждающей о необходимости вмешательства, выполняют еженедельные отчеты от специалиста обратная связь от тимлида клиентов 1-2 раза в месяц — опрос загруженности, удовлетворенности и планов работ.

Этап завершения

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

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

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

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

Кроме того, надо уметь убеждать сотрудника “дописать до точки”. Иначе есть риски, что время, потраченное им на “обучение”, но не переведенное потом в реализацию задачи, может быть оспорено.

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

Подводя итоги

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

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

Важно понимать, что системные решения позволяют решать проблемы заранее, а не пытаться купировать их «на лету» по мере возникновения.

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

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

0
22 комментария
Написать комментарий...
Konstantin Chelovechkov

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

Ответить
Развернуть ветку
Андрей Лядков
Автор

факультативно этим точно лучше не заниматься.

Ответить
Развернуть ветку
Victor Pomortseff

Просто это не универсально. У нас вот тоже ситуация, где все это не проходит. Я очень сильно сомневаюсь, что Вы сможете "подогнать" нам разработчика, имеющего высокий уровень экспертизы в разработке под IBM i, знающий тонкости RPG, DB2, MQ да еще к тому же знакомого с MiSys Equation.
Все-таки, когда речь идет о продуктовых компаниях (или IT подразделениях крупных компаний), более эффективны штатные разработчики, которые "в теме" по предметной области, используемой платформы и технологического стека.

Ответить
Развернуть ветку
Андрей Лядков
Автор

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

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

В вашей ситуации совершенно не важно из какого источника вы будете брать +1 специалиста, если не от «соседа» но вы наверное либо будете обучать с джунов либо переучивать консольщиков.

Есть ли практика что ребята на аутстаффинге работают годами? Такая практика есть.

Можно ли найти и переобучить парня с инженерным подходом? можно.

Можно ли это сделать бесплатно без косвенных расходов? Нет.

Готов ли именно ваш бизнес двигать планы и time to market, ругаясь на низкие темпы отдела разработки при этом ограничивая и нежилая тратить экстра бюджеты на дополнительные инструменты и риски, возможно.

Ответить
Развернуть ветку
Александр Ковалёв

Виктор, сказали бы вы это мне, то через час подписали бы свою увольнительную! 

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

Ответить
Развернуть ветку
Victor Pomortseff
 Вам не эксперт нужен, а DevOps- инженер

Ну Вам, конечно, лучше знать кто нам нужен...

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

Откуда такие глубокомысленные выводы?

Я уже публиковал упрощенную схему нашей системы. Есть Core слой, он работает на платформе IBM i и есть три слоя Service Mesh. Там другие платформы, более традиционные стеки технологий.

"Прямого" контакта Core с более верхними слоями нет. Только через ESB шину (вебсервисы, которые "дергаются" извне и  через jt400 вызывают соответствующие им сервисмодули на Core, которые возвращают ответ в виде резалтсетов) или через очередь MQ (на нашей стороне, на "той" стороне это WBI или JMS).

Я работаю на уровне Core. Т.е. разработка под IBM i. На уровне непосредственной работы с системными API, DB2 (как SQL, так и noSQL) и MQ API. "Готовых" разработчиков, кто знает эту систему в стране крайне мало - я знаю три банка, включая наш, кто на ней работает, пару вендоров, кто умеет под нее писать, ну может еще несколько других контор. Подготовка человека, с ней незнакомого до уровня когда он может решать несложные типовые задачи по прописанному ТЗ занимает 1.5-3 месяца. Полноценный разработчик, способный решать нетривиальные задачи с максимальной эффективностью формируется за полтора-два года (основано на опыте нашей команды) - это уже человек, которые не просто уверенно работает в терминале и знает основные языки разработки, но и понимает тонкости работы системы - группы активации, работу с заданиями, встроенный SQL (статические/динамические запросы), знает когда эффективнее использовать SQL, а когда noSQL, обработка исключительных ситуаций, поиск ошибок по joblog и dump, умение цепляться системным отладчиком на работающее фоновое задание с помощью srvjob и т.д. и т.п.
Это не говоря уже о том, что для эффективного решения задачи приходится вникать в ее предметную область (у каждой команды она своя - есть система расчетов, а есть карточки клиентов, а еще есть комплаенс с его поиском совпадений со списками росфина, есть пластиковые каты, и есть лимиты, тарифы, кассовый модуль и еще еще очень много чего) - прежде чем что-то делать нужно понять как оно работает, что с чем связано.
Это не так просто объяснить тому, кто не сталкивался со столь "низким" уровнем разработки. Это бесконечно далеко от распостраненной нынче мобильной и вебразработки. И намного ближе к системному программированию по стилю.

Ответить
Развернуть ветку
Александр Ковалёв

Всё выше перечисленное легко поймёт и за намного меньший срок тольковый DevOps-инженер.

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

И говоря о "намного быстрее" я имею ввиду в эмпиречески выявленные 3 недели. И говоря про "любого" я говорю об программистах на C/C++, Rust и некоторые компилируемых языках программирования, включая JavaScript с поправкой на backend-исполнение на JVM. 

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

И к слову, Виктор, в этой цепочки вы слабое звено. Прощайте, на пенсии будете эту историю рассказывать. 

Ответить
Развернуть ветку
Victor Pomortseff

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

Как думаете,  сколько у нас программных объектов, таблиц, индексов на уровне Core?

Думаю, что не разглашу особой тайны.
У нас порядка 30 тысяч программных объектов, 15 тысяч таблиц и индексов.
Порядка 3 млрд транзакций в день, около полтора терабайт изменений в таблице.
Порядка 10 тысяч процессов работают одновременно.

Уровень Core обслуживает около 60-ти других систем ("внешних" по отношению к Core).

НА уровне Core работает более сотни разработчиков по разным направлениям (командам). 

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

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

И девопсы у нас есть, но они занимаются своим делом. 

И  основной язык у нас - RPG. Некая современная альтернатива коболу. Язык для коммерческих расчетов (возможность как прямой, noSQL, работы с таблицами, так и интеграция SQL запросов в код программы на RPG, типы данных с фиксированной точкой, мощные функции работы с временем, датами, строками и т.п.). Хотя некоторые низкоуровневые вещи пишем на С/С++, там, где это эффективнее. Есть концепция ILE - интегрированная языковая среда, позволяющая собирать программный объект из модулей на разных языках (условно - одну функцию пишем на RPG, другую на С/С++ и потом собираем все это в одну программу где из RPGшной функции вызываем Сшную и наоборот).

Плюс IBM i не похожа ни на одну другую систему (если интересно - Ф.Солтис "Основы AS/400" - AS/400 старое название IBM i). Вот совсем. Там даже файловая система иначе устроена. Там нет файлов в привычном понимании (есть, но это другое - там "все есть объект" и файл это просто один из типов объектов, к примеру, программа - это не файл).

И много сущностей, к примеру, те же группы активации, аналогов которых в других системах просто нет.

И разработчик должен знать и понимать как все это работает и как всем этим эффективно пользоваться.

Простой пример (чтобы понимать насколько там все другое). Есть программа. В она работает с таблицами на уровне noSQL (т.е. открыть таблицу - работать с ней - закрыть таблицу). В ней есть какие-то глобальные или статические переменные.

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

Обработка исключений тоже немного сложнее чем в других системах. Исключения того же С++ работают только на языковом уровне. Блоки try - catch не поймают системное исключение. Их надо ловить или через signal или установкой специального #pragma exeption_handler

Плюс еще наши "нефункциональные требования" связанные с эффективностью.

И Вы хотите сказать что все эти тонкости разработчик с улицы за три недели может освоить? Да он неделю минимум потратит только на то, чтобы научится в терминале работать (референс по командам CL - язык системных команд - 2300 страниц талмуд, а не зная этих команд хотя бы на базовом уровне там вообще делать нечего). А еще RPG учить.

Так что не надо говорить о том, в чем не понимаете ровным счетом ничего.

Ответить
Развернуть ветку
Александр Ковалёв

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

Для компании вы приносете не пользу, а сплошной вред. И если не я вас бы уволил, то точно сделали это по моей рекомендации. Либо вы саббатируете работу DevOps и рефакторинг архитектуры, когда сам Бог велел детально задокументировать, убрать излишние костыли и стандартизировать протоколы обмена данными, чтобы не мастерить очередные костыли, когда "лишь бы работала и нам пофиг". 

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

Ответить
Развернуть ветку
Victor Pomortseff

И еще раз. Вашей "квалификации" хватает только на то, чтобы вешать лапшу на уши "акулам бизнеса". Лезть в разработку и архитектуру высоконагруженных систем Вам категорически не надо.
Уровень ядра автоматизированной банковской системы банка из топ-10 немножко сложнее Вашего понимания. Ваш уровень - типовые сайты, которые лепятся из типовых компонентов. И понять, что в разработке бывают и другие аспекты, увы, вне Вашей фантазии. Вы даже не пытаетесь понять (или не способны понять) что Вам говорят. Бубните заученные фразы про девопс.
К счастью, у нас таких не держат. Потому все и работает.

P.S. Для саботировать проверочное слово саботаж. А саббатировать - это какой-то нелепый англицизм от sabbath (достаточно интересное слово, кстати - это может быть шабаш у ведьм, воскресенье в христианской терминологии или суббота - "шабат" - в иудаизме). Какое значение Вы имели ввиду остается загадкой.

За сим позвольте откланятся.

Ответить
Развернуть ветку
Александр Ковалёв

Смотри внимательномо по сторонам, чтобы тебе однажды не пришлось на собственной шкуре узнать, что такое путинская пенсия, падонок!

Ответить
Развернуть ветку
Victor Pomortseff
 Если вопрос о применимости модели аутстаффинга на вашем, например, проекте?

Нет. Нам проще обучить своих разработчиков с нуля. Т.е. берется человек с "общим" опытом разработки и погружается в особенности нашей платформы и инструментов. Обычно на это уходит 1.5-2 месяца (до момента, когда человек начинает решать несложные боевые задачи). Через полтора-два года это уже вполне самостоятельный разработчик, как минимум уровня миддл.

У нас обязателен "испытательный срок" 3 месяца. Фактически это обучение и тест сработается человек с командой или нет.

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

У нас, как правило, берется или стажер (6 месяцев 20 часов в неделю) с нулевым опытом. Предложение о переходе в штат принимается по результатам работы. Возможно, до истечения стажировки (как минимум один случай знаю в нашей команде, сам этого человека "вел", удивительно способный парень, сейчас уже очень крепкий и самостоятельный разработчик, сегодня как раз "юбилей" у него - 2 года с начала стажировки у нас, в штат перешел через 4 месяца).

Или разработчик с опытом в других областях, на других платформах (сам такой - 25+ лет опыта под Win, основная часть - области связанные в промавтоматизацией, удаленным мониторингом объектов и т.п.) и "переучивается" под наши задачи и платформу.

Готов ли именно ваш бизнес двигать планы и time to market, ругаясь на низкие темпы отдела разработки при этом ограничивая и нежилая тратить экстра бюджеты на дополнительные инструменты и риски, возможно.

Почему-то есть стереотип - в "неайтишной компании" квалификация отделов разработки ниже чем в "айтишных". Фактически же у нас достаточно большое IT подразделение. Очень многоплановое - разработка идет по многим направлениям: сайт, мобильное приложение, Pega, WBI, middle слой (вебсервисы и т.п.), core уровень (IBM i). 

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

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

Ответить
Развернуть ветку
Андрей Лядков
Автор

Все верно ДИТ он такой, но не значит, что он не использует данные инструменты ;)

Ответить
Развернуть ветку
Victor Pomortseff

У нас не использует. И не будет использовать. Просто смысла нет. Разработчик у нас "входит в силу" после примерно 2-х лет работы. Т.е. это уже человек на фактически постоянной работе. И зачем нам использовать дополнительных посредников, если можно искать самим и готовить самим?

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

И да. У нас у все два руководителя - административный и функциональный. Т.е. есть руководитель подразделения и есть руководитель направления. Это разные люди с разным функционалом.

Ответить
Развернуть ветку
Рулон Обоев

А разве аутстафинг по закону не запрещен, не?

Ответить
Развернуть ветку
Андрей Лядков
Автор

Все нормально с этим. Тут речь о модели, а не фактическом кадровом решении аутстафа. Можно в личном статью личного блога посмотреть, если интересно.

Ответить
Развернуть ветку
Андрей Петушков

Запрещён.

Ответить
Развернуть ветку
Александр Ковалёв

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

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

Ответить
Развернуть ветку
Victor Pomortseff

Но Вы-то прочитали умную книжку и знаете что именно нужно, да? Всегда и везде. Даже там, чего в глаза не видели.

Ответить
Развернуть ветку
Александр Ковалёв

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

Ответить
Развернуть ветку
Victor Pomortseff

Вы круты! Сами от себя вне себя, да? Главное за щеками следите - а то лопнут от важности.

Ответить
Развернуть ветку
Валерий Сурженко

Работа в таком формате выгоднее чем держать программиста. Нам надо пару раз в год допиливать СРМ, держать в штате не выгодно брать FL.ru абы кого страшно, поэтому работаем с проверенной компанией ambaha.com Руководитель Роман подключал своих программистов по 50 баксов в час. Да по мне с нынешнем курсом дороговато но зато есть гарантия, что самописную СРМ не порушат

Ответить
Развернуть ветку
Читать все 22 комментария
null