21 жовтня – JS Conference 2017 у Києві. Як уникнути критичних помилок при створенні нового проекту?
×Закрыть

Изменения на рынке аутсорсинг услуг, и их влияние на компании и сотрудников

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

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

Сегмент «Бизнес-решения» отличался тем, что заказчик осознавал свою бизнес потребность, но не знал, при помощи какой технологии/технологического решения он сможет ее удовлетворить. В данном сегменте работали приемы консалтинговых компаний, когда все начинается с анализа бизнеса заказчика, после чего предлагается несколько вариантов технологических решений, один из которых впоследствии реализовывался внутренними ресурсами вендора либо нишевой компанией по субподряду.

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

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

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

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

В результате чего возрастает конкуренция среди компаний, предоставляющих услуги по моделям сегмента «люди». Так как рынок труда один для всех игроков и качественно изменить специалистов за неделю-месяц невозможно — качество предложения у всех игроков примерно одинаковое. Единственной плоскостью для конкуренции остается цена (оно же рейт).

Рейт состоит из зарплаты специалиста, «маржи» компании и прямых/косвенных затрат на содержание рабочего места специалиста + ведение бизнеса (менеджмент и т.д.) также знакомых всем нам как оверхед (overhead). Таким образом, при конкуренции в плоскости «цена» маленьким компаниям расти гораздо проще, ввиду возможности предложить более низкий рейт при той же зарплате за счет меньшего оверхеда (в компании в 20 человек CEO заплатил себе 10 000 долл в месяц зарплаты и на этом оверхед закончился. В компании в 500 человек на зарплату non-billable людям уйдет гораздо больше. Соответственно оверхед будет гораздо выше).

Средние и большие компании сталкиваются с необходимостью лавировать в гораздо более сложных условиях. Non-billable (за которых не платит заказчик) менеджерский персонал является ключом к росту, так как количество сотрудников не позволяет управлять ими напрямую и для этого требуется определенная организационная структура. Таким образом, текущее количество менеджеров является своего рода enablerом для дальнейшего роста компании. С другой стороны, количество подчиненных, которыми может управлять эта менеджерская структура, не является константой, а, скорее, является неким диапазоном (например, от 500 до 1500 человек). При этом в случае, когда у нас на менеджерскую структуру приходится всего 500 человек — экономическая целесообразность стремится примерно к самоокупаемости (оверхед съедает всю прибыль), в случае же 1500 подчиненных для той же менеджерской структуры прибыль была бы совершенно иной за счет гораздо большей эффективности.

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

В EPAM это PDS 2.0, в Luxoft — Managed Delivery, в Intetics — PSE (Predictive Software Engineering). Чем больше компания, тем острее ее руководство ощущает потребность в диверсификации бизнеса и переходе в сегменты разработки решений.

Для всех нас, преимущественно работающих в IT outsourcing, это означает одно — с изменением фокуса на решения от всех нас будут требовать совершенно иного набора навыков. Гораздо более разнообразного и широкого, чем просто уметь писать код либо выполнять тесты, либо составлять требования. Сложность работ, выполняемых в сегментах «бизнес» и «технологических» решений на порядок выше, чем в сегменте «люди». Поэтому, чтобы делать consumable solutions, для начала нужно будет поменять майндсет в стиле «works on my PC».

К сожалению, быть просто «хорошим кодером» уже недостаточно. Причина этому очень проста. Сейчас от специалиста ожидается автономность. Ожидается, что ему можно сказать, что «с 01.06.2017 пользователь хочет видеть бонусы по всем своим скидочным картам». Предположим, что вы разрабатываете некий агрегатор скидочных карт. Раньше специалист мог бы прийти к архитектору и спросить, а как же и где же взять информацию о бонусах и где и как же взять и создать список карт, ну и имел luxury задать еще с десяток вопросов, частично перекладывая решение задачи на своих коллег. Это было возможно благодаря контрактной модели Staff Augmentation или Time and Materials, когда вендору было выгодно продавать отдельно QA, отдельно BA, отдельно Database Developer и еще .NET Developer, ну и, может, даже .NET Architect (причем довольно часто Solution уровня. У нас их почему-то очень много). Все эти люди ходили пили кофе и чай, устраивали митинги и задавали друг другу вопросы, аргументируя их своей узкой специализацией и зоной ответственности.

По модели Fixed Price, чем меньше людей у нас работает, тем выгоднее, так как меньше затрат на зарплату, аренду столов и туалетную бумагу. И в таком проекте от специалиста будут ожидать даже общение с конечными пользователями для выяснения, а каким же цветом показывать отрицательные числа, если это возможно? Красным или оранжевым? Не говоря уже о том, где взять информацию, с кем, как и когда провести интеграцию, как обеспечить безопасность и отказоустойчивость. И все это за те же $3500-4000, за которые мы раньше привыкли зарабатывать ВСД, выпивая по 5-7 чашек кофе в день, в попытках выспросить у коллег, как же лучше выполнить нашу работу.

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

Чему же учиться?

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

LinkedIn

58 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

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

Владимир — если текущий объем работы вполне закрывает то за что заказчик готов платить — вы абсолютно правы. Выполнять больше за те же деньги имеет смысл только если нет других вариантов. К сожалению в Украине с фрилансерами совсем беда потому что они не смотрят на бизнес контекст в широком его смысле. В makeme.guru есть бизнес симуляция называется Outsourced Production. Суть ее в разделении 20 −30 человек на рынок, продуктовую и производственную компании. После чего продуктовая компания идет выявлять потребность рынка придумывает прототип решения заказывает его у производственной компании, проверяет валидность ожиданиям рынка, «допиливает напильником» и заказывает серию из 3-5 штук. Понятно что все это из скотча и картона потому что и так сложно. Так вот довольно частно производственная компания говорит в конце игры что считает что все прошло успешно. При этом рынок не купил продукт у продуктовой компании и соответственно они «попали на деньги» заплатив производственной компании. Если смотреть на контекст шире — в целом работа не успешна тк не все участники получили выгоду а только производство. Потребность рынка не удовлетворена и продуктовая компания терпит убытки. Если мы говорим о разовых работах — такой исход можно расценивать как успех (если вы просто исполнитель того что вам сказали). Если мы говорим о долгосрочном сотрудничестве — такого исполнителя не особо будут любить. Если ваш рейт как фрилансера на уровне просто исполнителя указаний — с вами будут работать. Если он выше — будут думать имеет ли это смысл тк получается переплата, связанная с тем что я как заказчик должен сам все придумать и заменеджить а фрилансер просто сделает механическую работу продуманную мной от а до я но за деньги, включающие в себя еще и работу менеджера и аналитика + на уровне ожиданий чем выше чек тем «очевиднее» для заказчика что фрилансер будет смотреть широко учитывая всех участников сделки а не только «фрилансер-заказчик». Как пример — заказывается дизайн сайта. И происходит опоздание на неделю. И присылается совсем грустный дизайн. После чего фрилансеру говорится — верни предоплату. На что он говорит — не. не верну тк я ж то потратил время. На что заказчик говорит — ок. оставляй себе $200 а мне пожалуйста компенсируй мои недополученные за эту неделю ввиду отсутствия сайта $2500. И для фрилансера это звучит как обида. Хотя как вы говорите — это же бизнес. Поэтому вопрос в том насколько широко смотреть на понятие «бизнес». После чего становится понятно достаточно ли вы делаете за те деньги которые берете. Все вышесказанное — просто мое мнение и никак не критика если что)

хорошая статья и изложение мыслей,
разрабы подтянутся с экспертизой как только компании начнут правильно формулировать требования, нужно вам понимание индустрии к примеру e-commerce у разработчика — включите это в требования и добавьте мотивации +500-1000$ за искомую экспертизу при прочих равных и будет вам счастье — народ начнет обзаводиться экспертизой,
сейчас это часто идет в списке прочих требований, есть єкспертиза — хорошо, а не — ну и ладно.

логика проста — начните доплачваить за экспертизу и вы получите через несколько лет рынок сениор девов с искомой экспертизой.
За AX начали доплачивать и какое бы Г не представляла из себя разработка под АХ — на рынке уже не мало людей с экспертизой в АХ.

Вопос ещё упирается в квалификацию рекрутеров.
Сейчас что западные рекрутеры, что наши — это недообученные боты — увидели слово JavaScript в резюме и давай спамить левыми офферами (только ~5% офферов релевантные кор компетенциям)

Чем рекрутер отличается от бота? — обученный бот делает match скилов лучше обученного рекрутера

мотивации +500-1000$ за искомую экспертизу при прочих равных

Меня всегда интересовало самим в этом месте не смешно?

начните доплачваить за экспертизу и вы получите через несколько лет рынок

«Доплачивать за экспертизу» это когда кто-то покупает какой-нибудь viewdle looksery grammarly на худой конец мелкую технологическую конторку целиком за пару другую миллионов но счёт идёт на сотни тысяч «за голову» а «доплачивать за экспертизу $500» это можно например в эксорте да и то это разовые суммы «на карманные расходы».

Чем рекрутер отличается от бота?

Дык и программеры та же ж история поклал ему на погоны +$500 и уже эксперт! ))

500$ x 12 = 6k в год, при медиане зп в Украине 30-40к/год это неплохой стимул для гребца получать экспертизу

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

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

неплохой стимул для гребца получать экспертизу
«... така и экспертиза» (к) (тм)

Я как раз об этом собираюсь говорить на Kyiv Outsourcing Forum 2017
Раз тема интересна — следующая статья о Competency Based Management

Всем добрый день.
Не стоит смешивать физический продукт и услугу по его изготовлению. Это два разных бизнеса с абсолютно разными правилами внутри. Разработчик продукта (А) может воспользоваться услугой по его разработке, предоставляемого компанией Б. Для него это нормально в рамках продуктовой бизнес модели (как и рассказывалось в комментариях). Для аутсорсера начать разрабатывать свой продукт = почти полностью поменять бизнес модель компании. Если так не считаете — подумайте поспрашивайте и поищите на рынке примеры тех компаний кто пытался начать такое делать. Заканчивалось все созданием дочерней либо отдельной компанией. Совмещать услугу и продукт некак и точка. Сюда не входит услуга по кастомизации своего же продукта. Я говорю только о чистом аутсорсе. Если захотите привести в пример автомотив люкса или digital епама — вникните в суть предложения. Потому что оно состоит не в продукте а в том что у компании есть полуфабрикат на основе которого она может сделать вам ваш продукт экономя на «не с нуля». Это как bespoke vs ready-to-measure vs ready-to-wear. В аутсорсе как нигде нужны полуфабрикаты (архитектурный репозиторий и тд). Это тоже может быть частью УТП и конкурентным преимуществом тк вы делаете то же что и соседи но быстрее и иногда дешевле.

Аутстаф и дальше будет существовать. Особенно в маленьких компаниях. Я нигде не написал что он исчезает как вид. Весь вопрос в том на какие сделки вы ориентируетесь. Большинство работает в крупных компаниях где за мелкие контракты никто браться не будет. И им все написанное актуально сегодня. Для компаний поменьше это «на подумать» что делать через год два три.

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

Вы хотите сказать, что клиенты оплачивают (и тем более держат в штате) архитекторов, продактов, аналитиков и прочих просто от избытка денег/глупости (при наличиии разработчиков с 5-15 годами опыта в предметной области), а украинские аутсорсеры справятся универсалами во всем?

Ви пишете що це зараз тренд в аутсорсингу, але принаймні на ринку Львова я цього не побачив. Аутстаффінг росте нормально. Хотів б побачити хоч 1 вакансію де описанні «скілли» продаж потрібні?
Я наприклад 10 років програмую, про те що ви вкінці описали почав цікавитись останні пів року, але це не для того щоб сидіти в аутсорингу і кліпати двотижневі проектіки по fixed price. Я б дуже поспорив для чого це знати девам (включаю сеньйор рівня), зараз так дуже багато технологій і практик, без маркетингу є чого повчитись.

А вам не здається що місцевий аутсорсінг доволі тупий? Є компанії з топ 30 які б надавали послуги по «маркетингу» і наприклад «колл центру»? Всі тупо як 10 років тому навчились продавати програмістів і QA так далі за ці межі й не вийшли, та навпаки більше скотились просто до аутстафінга, ніж розробки готових рішень. Всі полюбили говорити, що вони «сервісні компанії», проте мені здається що й немає навіть базових напрацювань по швидкій розробці рішень.
Будь який тип проекту підходить під певний тип шаблону та стек технологій ітд, тобто коли заходить клієнт вже 10% роботи має бути зроблено в 1 день, хтось це пропонує? Не думаю

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

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

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

Чему же учиться? Основы бизнеса. Основные понятия о том, что такое маркетинг, продажи, выручка, доход, налоги, клиенты, бизнес-модель, создание ценности.
Janosh, как это организовано у вас в компании ? Проводятся внутренние тренинги, семинары ?

Начинаю злорадствовать...

Почему-то получилось «надо меньше кормить и больше доить и пусть она ещё сама сыр сразу делает».

Когда статью пишет С*O, то он описывает то, что ему хочется, а не то, что есть на самом деле. К этому уже давно пора привыкнуть :)

Со времён СССР так.

Яноша знаю давно, такі думки він висловлював в раніше. Так, що, сорі, це об’єктивна реальність людини з досвідом, а не ілюція.

Значит я живу в другой реальности. В моём мире всё по другому.

об’єктивна реальність
реальність людини
Ги.

А якщо по суті — ну повна ж маячня у статті написана, вибачте. Невже пан Орос справді стверджує, що команда, у якій є один программіст, який пише код, один тестувальник, який тестує код, і один аналітик, який проводить допити кастомера про те, що взагалі двом іншим людям потрібно робити — що така команда буде менш ефективною, ніж команда з трьох людин-оркестрів, які робили б те саме, але усі разом і врозбрід? Без розподілу праці ми б досі кукували у мазанках і займались збиральництвом.

Ще у статті чорним по білому написано, чому у пана Ороса, голови Інтетіксу, з’явилися такі думки — тому що просто людиночаси продавати вже не виходить, треба продавати продукти. А проблема в тому, що виробляти ці продукти чогось не виходить, і коли постає питання «чому», у менеджерів, звісно, одна відповідь — «це все программисти винні». А програмісти не винні. Винен менеджмент.

Чому совок розвалився? Тому що ще з совкових часів у нас купа розумних програмістів/інших спеціалістів будь-якого рівня кваліфікації, але жорстко бракує нормальних менеджерів проектів, які б мали віжн і створювали планування проекту — є лише люди, які називають себе менеджерами і ходять на роботу посидіти на стільці та почитати ВК. Я за свою трьохрічну кар’єру в Україні зустрічався лише з двома або трьома реальними менеджерами, усі інші створювали видимість роботи, а на

что такое маркетинг, продажи, выручка, доход, налоги, клиенты, бизнес-модель, создание ценности
їм було глибоко начхати. І коли я бачу цілу статтю, в якій говориться, що так і треба і обов’язки ПМа повинні виконувати програмісти — мене, як програміста, це трохи ображає.

Тому частіше почали з’являтись вакансії на посаду Product Manager та Product Owner :-)

А проблема в тому, що виробляти ці продукти чогось не виходить,
Нужен посредник (предприниматель) между производителем и потребителем, который убедит потребителя принять этот продукт и за него заплатить.
За это придется вложить не мало «собственных» средств.
И по своей структуре: производство и продвижение — два разных вида деятельности.
і коли постає питання «чому», у менеджерів, звісно, одна відповідь — «це все программисти винні». А програмісти не винні. Винен менеджмент.
Менеджмент виноват всегда.
Но у него всегда есть право не брать на себя риски.
І коли я бачу цілу статтю, в якій говориться, що так і треба і обов’язки ПМа повинні виконувати програмісти — мене, як програміста, це трохи ображає.
На самом деле (для тех кто еще не понял) идея переложить на разработчика задачи поддержания операционной эффективности и работы с клиентом преследует перед собой цели:

1. повысить маржинальность команды
2. повысить вовлеченность и концентрацию исполнителей на потребностях клиента
3. вовлечь разработчиков в поддержание операционной эффективности
4. уменьшить фактор «выгорания» на рабочем месте, в том числе за счет работы с клиентом
5. ....
И это все на благо программисту.

але жорстко бракує нормальних менеджерів проектів, які б мали віжн і створювали планування проекту
В данном случае задачи нормальных менеджеров проектов делят на 2 части (все по Agile):
на Product management
и на Scrum master’s поддержку

Теперь Вам во всем винить ПМ-а уже не удастся.
Его теперь не будет.

Наверное, на самом то деле, суть статьи:

1. повысить маржинальность команды
не меняя модели бизнса, аля, аутсафинг — оплата за тело, при этом могут аутсафить как разработчиков, так и полностью укомплектованную комманду — менеджеры, архитекторы и т.д. И при этом особо напрягаться не стоит — продал «тушку» или комманду «тушек», желательно лет так на 5, и все класс.

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

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

И да,

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

Так, вроде, автор статьи именно об этом и пишет? :)

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

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

Скоріш за все тому, що за хороше знання предметної області йде суттєва надбавка до зарплати

точно нет, никто не платит за просто знание предметной области

емм... тобто якщо, скажімо, проект по медицині і я знаю HL7, DICOM, SNOMED і т.п. — бабла більше не обломиться ?

бабла більше не обломиться ?

Там же написано :)

И все это за те же $3500-4000, за которые мы раньше привыкли зарабатывать ВСД, выпивая по 5-7 чашек кофе в день, в попытках выспросить у коллег, как же лучше выполнить нашу работу.
бабла більше не обломиться ?
ну, конечно же нет, просто если будет выбор между тобой и примерно таким же по скилам человеком на одинаковую зп, скорее всего тебе офер предложат первому, вот и все плюсы предметной области
К сожалению, быть просто «хорошим кодером» уже недостаточно. Причина этому очень проста. Сейчас от специалиста ожидается автономность.
Замечание — автономность ожидается не от программистов, а от менеджеров и бизнес-аналитиков, которые, если статья не врёт, наконец-то начнут заниматься делом, а не
зарабатывать ВСД, выпивая по 5-7 чашек кофе в день, в попытках выспросить у коллег, как же лучше выполнить нашу работу
Очень надеюсь, что именно так и произойдёт :) А от программистов в продуктовых компаниях ждут того же, чего и в аутсорсе — писать код.

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

Интересно узнать, как концепция fixed price уживется с agile, где клиент заранее не знает что хочет и аппетит приходит к нему во время еды

фиксируем цену за неделю работы.

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

Роман — Agile ж не про «не знает что хочет». А про «готовность поменять направление движения в случае необходимости». И каждое такое изменение стоит денег. И об этом нужно договариваться «на берегу». Если мы с самого начала строим машину — нет смысла проходить все по классике объяснения эджайла — строить самокат потом велосипед потом мопед потом мотоцикл потом его клонировать чтобы получить 4 колеса и понять что нужен другой кузов. Если вы с самого начала знаете что это автомобиль — стройте автомобиль. Если знаете что это транспортное средство для вспахивания полей — сделайте несколько PoC и выберите подходящее решение после чего уже делайте его по модели автомобиля — понимая что зачем. Нет смысла брать инструменты из области построения продуктов/решений и применять их 1 в 1 в области исследовательской. Это не будет эффективным. Любой аппетит можно измерять как в ресторане и потом выставлять счет. При условии что вы об этом изначально договорились. Другой вопрос что у нас мало кто умеет оценивать иначе чем «экспертным мнением». Но это уже другая история.

Уживается она так: нужно работать над самым важным с короткими итерациями и shippable product в них. Тогда к концу денег будет некий продукт, который, вероятно, будет содержать самое важное из возможного. Но не каждый клиент готов на такую неопределенность, так что постарается внести какую-то конкретику в что именно продукт будет содержать, и вот уже рисуется диаграмма Ганта, определяется критический путь, ответственный менеджер с навыками MS Project, вот это все...

и вот уже рисуется диаграмма Ганта, определяется критический путь, ответственный менеджер с навыками MS Project

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

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

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

Fixed cost или fixed all? Если первое, то качественной приоритезацией и варьированием объёма функционала. Другими словами — «пилим самые нужные бизнесу фичи, пока есть деньги».

А я как-то по-другому написал?

Плохо уживается. Как результат — ошибочные эстимейты, кривая архитектура и овертаймы.

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

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

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

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

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

Т.о. аутсорсер берет на себя большую часть рисков за внедрение инноваций.
За реализованные инновации всегда просят выше рынка.

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

Ну с таким раскладом оно понятнее... хотя тема не новая, и причина понятная. Индусов жалко :)

Алексей — все именно так. Одно небольшое дополнение. Нет возможности вести бесконечную конкуренцию ввиду того что у заказчика нет печатного станка. Чтобы рассчитаться с вендором заказчик будет использовать либо привлеченные средства (инвестиции и т.п.) либо доход от конечных пользователей продукта. В обоих случаях сумма ограничена. При привлечении средств доходностью бизнеса и доступностью этих самых средств. При доходе — суммой которую конечный потребитель готов заплатить за продукт. И мы уже очень близко к этим границам (смысла нет платить больше за разработку продукта на котором ты не заработаешь). Плюс заказчик тоже «конечный потребитель» и тоже имеет некие мысли на тему что сколько стоит. Какое то время можно играть в игру «а куда ж ты денешься». Все в нее и играли. Проблема этой игры — в долгосрочной перспективе происходит изменение (кто то что то обычно придумывает), меняющее правила этой самой игры. И тогда те кто ухмылялся думая что «деться некуда» говорят что то типа «Э Э ты куда?! мы ж так не договаривались» оставаясь обычно без денег.

Janosh Oros, спасибо за диалог.
Я понял Ваш пост как попытку презентовать новые правила игры, ставшие следствием естественной эволюции отрасли.
Суть этой эволюции вот в чем: и заказчик и подрядчик стремятся уйти из сегмента Люди в сегменты Бизнес и Технологии.
Каждый из них преследует свои корыстные цели и исходит из своих возможностей, но в итоге стремления сторон совпадают:
Заказчик хочет экономить оценивая не только проектные затраты а и полные затраты включая затраты например на собственный менеджмент, а
подрядчик хочет больше зарабатывать и стремится снижать свои собственные риски

Миграция из сегмента Люди в сегменты Бизнес и Технологии требует иных организационных процессов и Вы об этом сказали.

Теперь осталось узнать подробности о новых бизнес-процессах dev-а, и о
том какие новые устойчивые «паттерны поведения» должны заменить старые.

Очевидно что эти новации представляют собой некие собственные ноу-хау упомянутых выше PDS 2.0, Managed Delivery, PSE.

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

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

Вы серьезно верите в

будут тестить знания в предметной области
???

Вы вникали, как быстро меняется бизнес у ваших клиентов? И вы реально верите, что здесь будут организованы «галеры» по предменой области?

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

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

Проще потому что ... cделать это и сложнее.
Попался на слове!!!! :))))

Но если по сабжу, то просчитать инвестицию сравнительно легко, как минимум опираясь на уже сегодня известную себестоимость. Прогнозирование доходности — уже задача не такая тривиальная. Тут требуются и знания технологий бизнеса, и маркетинговый прогноз по нише. Итак, пабабабамс! для появления нового бизнес-игрока (со своим insource IT) в нише понадобится лишь операционка!

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

Я скажу больше — подобного рода учебный центр обычно продается заказчикам как инструмент, обеспечивающий поддержание профессиональности сотрудников на требуемом уровне. Кривые косые не до конца дающие то что нужно — все это следствия того контекста в котором мы живем. Тем не менее они есть и они дают возможность что то получить в плане знаний и опыта. Если вам это не нужно значит ваш уровень выше чем то что может дать такой УЦ. И значит пора искать что то следующего уровня. Ну а как план Б — никто ж не заставляет. Рынок большой и каждый волен выбирать.

По модели Fixed Price, чем меньше людей у нас работает, тем выгоднее, так как меньше затрат на зарплату, аренду столов и туалетную бумагу. И в таком проекте от специалиста будут ожидать даже общение с конечными пользователями для выяснения, а каким же цветом показывать отрицательные числа, если это возможно? Красным или оранжевым? Не говоря уже о том, где взять информацию, с кем, как и когда провести интеграцию, как обеспечить безопасность и отказоустойчивость. И все это за те же $3500-4000, за которые мы раньше привыкли зарабатывать ВСД, выпивая по 5-7 чашек кофе в день, в попытках выспросить у коллег, как же лучше выполнить нашу работу.
Тобто сейлсів, аналітиків, менеджерів проектів і т.д. звільняємо, замість них буде super-full-stack developer: и швец, и жнец, и на дуде игрец ?
за те же $3500-4000

Я говорю о том что в плане знаний человек занимающий любую из перечисленных ролей должен будет чуть чуть знать и о том как шить и как жать и как играть на дуде. Хотя бы знать. Это смешно когда программист не знает хотя бы поверхностно как работает тестировщик. Я не говорю про умение тестировать всеми возможными способами. Я говорю про «знать». Не зная он не может с ним коммуницировать. Он не понимает зачем этот человек в их общей команде. Он не может ему помочь. И не может адекватно воспринимать и обмениваться информацией. На сейчас у нас есть слишком много уж очень узко специализированных сотрудников, играющих в игру «а это ж не из моей зоны ответственности». И так как индустрия молодая и эджайл и время перемен и менеджмент не зрелый и нет должностных инструкций — эта манипуляция срабатывает. Но манипуляция так и остается манипуляцией а сделанное дело сделанным делом. За манипуляцию могут заплатить зарплатку. Просто потому что проще заплатить чем разбираться. Потому что нет времени и большинство такие же. А клиент хочет платить за результат. Ему все равно что кто то не может понять зачем код фриз на проекте. И все равно что QA автоматизатор принципиально не хочет что то протестить ручками. И все равно что программист топает в знак протеста негодуя на BA за то что тот использовал непонятные ему слова в описании тасочки. И это именно BA виноват никак иначе. Я именно о таких ситуациях а не о живородящеяйцекладущем. Я и сам против непонятных мутантов. Всем всегда говорю что хватит эксперементировать на живых организмах.

Интересная статья! Спасибо автору!
1) Вот мне интересно, писал ли автор качественный код?
2) И как же наши швецы-жнецы будут писать качественный код?
Имеется ввиду когда же они научатся писать качественный код, если им придется постоянно и шить и жать и на дуде играть?

И как же наши швецы-жнецы будут писать качественный код?
Имеется ввиду когда же они научатся писать качественный код, если им придется постоянно и шить и жать и на дуде играть?

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

Подписаться на комментарии