Крючков про аутсорсинг

Термін FDE (Forward-deployed engineer) стає настільки популярним, що скоро його неминуче очікує інфляція, коли так почнуть називати дорогий аутстаф. Частина клієнтів буде робити вигляд, що купують щось важливе і нове, а частина вендорів - що продають комплексну сучасну послугу.

Доречі, вже почав зустрічати вимоги на FDE в RFP - поки нечасто, але це тільки початок :)

Останнім часом активно вивчаю тему outcome-based delivery

Мої враження від цієї теми на даний момент:

1. Більшість компаній і експертів пише про модель дуже загально і без специфіки. Значна кількість статей на сайтах компаній зводяться до думки: “outcome-based - це добре і це майбутнє”, без вказання якоїсь специфіки

2. Деякі компанії пропонують цікаві моделі, але по факту подають під соусом outcome-based різні варіації fixed-price або price-per-feature.
Наприклад одна з українських компаній пропонує модель, де скоуп нарізається «порціями», тобто високорівневими задачами трьох розмірів. Кожному розміру відповідає своя ціна і в його межах клієнт може робити зміни і уточнення без зміни ціни. Де закінчується межа цих змін - не вказано (але тут мова про публічний сайт, контракт я не читав)

3. У великих аутсорсерів (Accenture, TCS, Wipro) outcome-based зустрічається частіше і існують описані кейси (різного рівня абстракції).
Іноді вони навіть містять опис конкретних показників, до яких привʼязується ціна контракту (але без самої формули привʼязки і цифр, що зрозуміло). 

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

Був один кейс, де вендор отримував “все або нічого” за вчасне виконання compliance-вимог.

Ще важливий момент - зазвичай комітмент саме на outcome (а не скоуп) зустрічається не в проектах на розробку, а в програмах з міграції, managed services, managed operations, тощо

4. Ще частіше опис такої моделі і кейси зустрічаються у консалтингових компаній з великої четвірки - там вже “справжні” бізнес-показники

—

Все прочитане мною за час вивчення теми outcome-based приводить мене до висновків, що:

1) Для роботи в цій моделі потрібен brand permission - тобто довіра до певного вендору і впевненість в тому, що він може взяти на себе відповідальність саме за результат, а не скоуп

2) Така довіра є лише у великих (або маленьких але дуже нішевих) гравців

3) Сама ця послуга більше потрібна великим клієнтам, масштаб яких вимагає аутсорсингу певних бізнес-процесів і трансформаційних задач зовнішньому вендору

4) Думаю, більшість сервісних компаній так і залишаться на рівні output-based, просто специфіка послуг буде іншою (але це окрема тема)

Якщо маєте думки з цього приводу - запрошую в коментарі

Бажаю вдалих проектів, за якою б моделлю ви їх не деліверили :)

—
Підписатись: Telegram | YouTube

Друга пара очей

Щоб трохи відволіктись від теми АІ поговоримо про те, що навряд чи можна буде найближчим часом замінити на "роботів".

Достатньо часто сервісні компанії (особливо невеликі) роблять наступну помилку. 
З'являється лід, йому продають послуги з розробки, формують команду, призначають ПМа/ДМа і... все.
ПМ залишається з клієнтом сам на сам, а клієнт - з ПМом.
В кращому випадку прописують і проговорюють escalation path - до кого бігти якщо все валиться.
Тобто - клієнт має лише одну постійну точку контакту в сервісній компанії, з якою регулярно спілкується. Все інше - на випадок "аварії".


Чому це помилка?

Проблема в тому, що такий сетап майже гарантує що:
- рано чи пізно між клієнтом і ПМом буде накопичуватись негатив (через проблеми, що з'являються на будь-якому проекті)
- негативний фідбек клієнта немає куди каналізувати - не кожен клієнт готовий висловлювати невдоволення особисто ПМу
- "аварія" стається, і хоча escalation path існує, він в такій ситуації малоефективний (бо пізно пити Боржомі, коли… самі знаєте що)
- клієнт або "вибухає" гучною ескалацією, або просто йде

Ситуація стає ще більш неприємною, коли клієнт представлений двома і більше стейкхолдерами - тим, хто спілкується с ПМом і командою регулярно і "великим босом", який до щоденного спілкування не доходить, і отримує всю інформацію від свого підлеглого (але якраз цей "великий бос" і є наш справжній замовник і десижн-мейкер). 
Тут з'являється велике поле для маніпуляцій.


Що з цим робити?

Думаю, багато хто вже здогадався, що мова йде про акаунт-менеджмент. 

В акаунт-менеджера (навіть якщо ця роль у вашій компанії називається по-іншому) є багато цілей і KPI - тут і customer satisfaction, і розширення акаунту, і багато чого ще.

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

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

А також - зможе з'ясувати чи існують на стороні клієнта інші стейкхолдери, які:
- можуть ще щось замовити (і це плюс)
- можуть "копати" під поточного вендора, намагаючись втілити в життя свої плани (і це мінус).  

Тобто, якщо у вас є клієнт, з яким спілкується тільки ПМ - це ризик.
Зняти цей ризик легко - призначте monthly/quarterly business review зустрічі, де інша людина (вища за ПМа по статусу) буде спілкуватись з клієнтом і його "босами". 

При цьому в ролі АМа можуть виступати різні люди - Senior PM, DM, CDO, Sales, чи навіть CEO невеликої сервісної компанії. 

Інвестиція невелика, але зберігає купу часу, нервів і грошей.

Бажаю вдалих проектів :)

—
Підписатись: Telegram | YouTube

Я дуже довго не вірив в продажі «через маркетинг».

Тобто коли ви робите контент, рекламу, seo, <додайте ще маркетингових термінів> і генеруєте inbound-лідів.

В моєму розумінні це все виглядало як якась додаткова і необовʼязкова активність.

Я вважав, що «серйозні продажі» робляться виключно через нетворк сейлза, і тільки так можна завести великий контракт.

І цієї думки я притримувався багато років.

Але згодом моя картина світу доповнилась:
- нетворк будь-якого сейлза має свої обмеження
- навіть якщо в ньому ну дууже багато контактів - хто сказав, що їм прямо зараз потрібно щось купити?
- покладаючись тільки на нетворк сейлзів і не роблячі жодних «додаткових» зусиль з лідогенерації, ви маєте обмежений вплив на такі речі як ICP, стратегія продажів, тощо - фактично, ви продаєте тим, з ким знайомі ваші сейлзи

Натомість, якщо лідогенераційна машина налаштована і працює, ви отримуєте систему, яка:
- краще скейлиться
- регулярно оновлює ваш нетворк
- дозволяє тестувати різноманітні гіпотези
- має характеристики, які можна достатньо точно виміряти та порахувати ROI (на великій вибірці)

Ідеальний варіант - комбінація обох каналів - і нетворку, і «машини» лідогенерації

Буду радий почути думки у відповідь

Бажаю вдалих продажів :)

—
Підписатись: | https://www.youtube.com/@kriuchkov.pro.outsourcing

Відео: Про AI в SDLC та пресейлі

А ось і та сама панельна дискусія, на яку я запрошував бажаючих :)

Обговорили багато питань, зокрема:
- де компанії знаходяться на шляху AI adoption та які етапи SDLC вже покриті AI
- яке пришвидшення AI дає в розробці та делівері
- як змінюються композиції команд і активності ролей

Мої співрозмовники, яким я надзвичайно вдячний за цікавий обмін думками:
▪️ Катерина Мотько: Client Partner - AI & Healthcare Projects @ Symphony Solutions
▪️ Віктор Назаренко: CTO & Founder @ http://TrendHero.io/
▪️ Даніель Ніязієв: Head of Engineering @ Relevant Software

👉 Відео вже доступне тут: https://youtu.be/bkPo9MM6vfk

Бажаю приємного перегляду і буду вдячний за поширення!

Колеги, маю пропозицію Зібратись і поговорити про реальний досвід впровадження AI-інструментів в SDLC у ваших компаніях/командах, і як це вплинуло на результати, пресейл та модель співпраці з клієнтами Форма - панельна дискусія: ефір або записана зустріч…

Колеги, маю пропозицію

Зібратись і поговорити про реальний досвід впровадження AI-інструментів в SDLC у ваших компаніях/командах, і як це вплинуло на результати, пресейл та модель співпраці з клієнтами

Форма - панельна дискусія: ефір або записана зустріч в YouTube, 3-4 учасники

Якщо бажаєте взяти участь в якості співрозмовника та поділитись досвідом - заповніть, будь-ласка, https://forms.gle/JPcYXGYtSjLVyRDe8

Форма відкрита до 8 березня включно

Заздалегідь дякую і бажаю гарного дня!

Про FDE

Останнім часом доволі часто можна зустріти згадку про Forward Deployed Engineers як про «нову і передову» модель надання сервісу.

Трохи розкажу про те, що знаю і що думаю про таку модель в контексті українських (і не тільки) сервісних компаній.

1. Модель позиціонується як «інженери що працюють безпосередньо з клієнтом, інтегруючись тимчасово в організацію клієнта»

2. Важливо розуміти, що перші і основні компанії яку цю модель використали під такою назвою - це Palantir, а згодом OpenAI, Amazon і інші великі гравці, що мають свою технологію, платформу або продукт, яку ці самі FDE і допомагають впроваджувати

3. Тобто - FDE це не просто інженери. Вони - носії знань про технологію/продукт і про те, як ця технологія може бути застосована в різних бізнес-кейсах. І саме в цьому полягає їх цінність

4. В чомусь ця модель дуже подібна до того, як впроваджуються ERP/CRM-системи - команда знає і технологію, і домен; впроваджує свій продукт або продукт партнера; може комітитись на результат - такі впровадження часто виконуються як ФП-проекти

5. Зверніть увагу - перші чотири пункти зводяться до того, що у вендора є два важливі моменти:
- компетенція, ширша за «просто інженерну»
- brand permission - згадані компанії є відомими і головними драйверами/гравцями свого ринку. Їм довіряють, як носіям унікальних знань.
Це дозволяє їх FDE не перетворитись просто на ще один додатковий ресурс в команді клієнта, принаймні в теорії.


Чи може така модель працювати в аутсорсі?

Так. Але наразі її можна спостерігати в основному у великих сервісних компаніях, які не позиціонують себе як «чисто інженерні».
Той самий Accenture говорить про себе як про консалтингову компанію. В них, і у інших великих сервісів є схожі моделі зі схожими назвами.

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


Чи може це працювати у східноєвропейському/українському аутсорсі?

Я далекий від того, щоб казати однозначне «ні».

Але треба розуміти, що для того, щоб ця модель не деградувала у glorified outstaff, потрібно щонайменше:
- компанії - мати компетенцію і brand permission (вже згадані)
- інженерам - знатись не тільки на технологіях, а і мати навички роботи з клієнтами, консультування, доменну експертизу (або хоча б як працюють domain-agnostic бізнес-функції)

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

Бажаю вдалих проектів :)

—
Підписатись: Telegram | YouTube

[poll]

Колеги, давайте поговоримо про так зване outcome-based delivery.
Чи хтось вже застосовує його в своїй компанії і чи воно насправді outcome-based чи це просто чергова назва для Fixed-Price?

Опитування - нижче 👇

В декількох своїх інтервʼю цього і минулого року я ставив співрозмовникам запитання - чи призведе АІ до скорочення потреби в інженерах, чи навпаки, наявність нових технологій спровокує появу (або, краще сказати, прояв) нових юз-кейсів, що компенсує падіння потреби в розробниках.

Умовно, чи проекти стануть меншими (за кількістю людей) і при цьому кількість проектів не зміниться/не зростатиме так швидко, щоб компенсувати це зменшення АБО все ж таки і проектів буде значно більше ніж зараз.

Тут в каналі теж було опитування на цю тему.

Що я думаю зараз:

- не буде проектів/програм на 1000+ людей на одного клієнта (або це буде значною рідкістю)

- різноманіття юз-кейсів буде зростати, адже нові можливості відкривають (і роблять видимими) ті застосування, які раніше ніхто й не уявляв

- необхідність в інженерах і в сервісних компаніях залишиться, бо ніхто не прибирає необхідність розуміти бізнес-проблему, мати індустрійний досвід впровадження технологій, менеджити стейкхолдерів (особливо в політично-складних середовищах)

Останній пункт буде актуальним наступні років пʼять. Далі будемо дивитись.

Бажаю вдалих проектів :)

—
Підписатись: Telegram | YouTube

[poll]

Десь півроку тому питав вас про те, чи ви використовуєте AI для оцінки проектів на пресейлі - і тоді скептиків була переважна більшість.

Давайте перевіримо як справи зараз :)

👇

Що нового?

Зібрав кілька тенденцій, що бачу/спостерігаю в новинах останнім часом, що можуть суттєво вплинути на сервісний бізнес, і вже впливають:


1) Agentic Transformation - все більше сервісних компаній переходять від "просто розробки" або впровадження рішень до "трансформації бізнесу" за рахунок розробки/інтеграції AI-агентів.

Тут є місце і для data-проектів, і для аналізу/оптимізації процесів, і для певного технологічного консалтингу.

В цілому, раніше цю нішу займала "цифрова трансформація", а ще раніше - "автоматизація"


2) Сервісний компонент поступово з'являється/збільшується у двох типів компаній, які не є безпосередньо аутсорсинговими:
- AI-вендори
- Клауд-провайдери

І ті, і ті вже мають (декларують, що мають) сервісні підрозділи, які допомагають з впровадженням технологій, кастомізацією рішень під клієнта.

Думаю, що тут може бути як ризик для типових сервісних компаній, так і можливості - якщо стати сертифікованим партнером таких вендорів (але ми розуміємо, що рівні партнерства бувають різні і іноді дуже сильно впливають відносини з конкретними стейкхолдерами)


3) Все більш актуальним стає питання AI Governance/AI Sovereignty - просто так відправляти дані компанії "кудись" і раніше було не ОК.

Зараз же проблема ще більш гостра - в якийсь момент модель може почати "знати" про ваш бізнес більше, ніж ви.
А ще вона може просто перестати працювати (а ви вже і агентів розробили, і до швидкості звикли).

І все більше постає питання про onprem-хостінг, open-source-моделі, тощо.

Що думаєте? Бачите те саме чи щось інше?

---
P.S.
Давно тут не писав, бо багато роботи (про це якось потім) + вся ця AI-історія дуже сильно все змінює, і потрібен час, щоб все обміркувати і узагальнити, а без цього нормальні пости не пишуться.

Бажаю вдалих проектів :)

—
Підписатись: Telegram | YouTube

Відео: Продукт vs Сервіс

Колеги, публікую анонсовану раніше дискусію про продуктові та сервісні компанії

Поговорили, зокрема, про:
▪️міфи про аутсорсинг та продукт
▪️переваги та недоліки роботи в різних типах компаній
▪️відмінності в навичках "продуктових" і "сервісних" інженерів і менеджерів
▪️що таке продуктовий майндсет і чи можна його розвинути
▪️як AI впливає на майбутнє сервісного та продуктового бізнесу

Мої співрозмовники, яким я дуже вдячний за цікаву та відверту дискусію:
▪️ Віктор Назаренко: CTO & Founder @ TrendHERO
▪️ Любомир Бойчук: CTO @ S-Pro
▪️ Євген Клюкін: Lead BA & Agentic Transformation @ Geniusee

👉 Відео вже доступне тут: https://youtu.be/xW1r3Y4zeAQ

Бажаю приємного перегляду і буду вдячний за поширення!

Колеги, привіт! Бачу, що формат панельної дискусії на YouTube (де ми говорили про AI в SDLC та пресейлі) викликав неабиякий інтерес, тому є пропозиція повторити цю вправу :) Цього разу пропоную поговорити про досвід переходу з продуктової компанії в сервісну…

Нещодавно натрапив на цікавий курс семінарів від Стенфордського університету.

Тематика - економіка AI.

Перше відео - оглядове.
В ньому мова про те, що технологічний бізнес за останні десятиріччя пережив кілька економічних «суперциклів» - починаючи від персонального компʼютінгу, розквіту інтернету та мобільних технологій до вибуху соціальний мереж, хмарних обчислень та data.
Десь в 2022 році починається AI Supercycle, основними економічними «рівнями» якого є напівпровідники, інфраструктура (датацентри та хмари) та consumer applications - інструменти від OpenAI, Anthropic, тощо.

Кожне наступне відео (їх поки чотири, але буде більше) - виступи запрошених спікерів з різних компаній, що працюють в кожному зі згаданих «рівнів» - в т.ч. Nvidia, OpenAI + трохи менш відомих.

Розповідають дуже цікаво - про те, як будуються датацентри і як там працює економіка; як через економічні міркування (вартість обчислень) інженери приходять до нових архітектур чіпів, хто і як інвестує в такі компанії.

Курс новий - перше відео опубліковане місяць тому, останнє (на цей момент) - два тижні.

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

Подивитись можна тут: https://youtube.com/@mse435economicsofai?si=nkcRgN6J8lI5e-kW

Бажаю вдалих проектів :)

—
Підписатись: Telegram | YouTube

Колеги, привіт!

Бачу, що формат панельної дискусії на YouTube (де ми говорили про AI в SDLC та пресейлі) викликав неабиякий інтерес, тому є пропозиція повторити цю вправу :)

Цього разу пропоную поговорити про досвід переходу з продуктової компанії в сервісну, або навпаки - не з метою холівару, а з метою конструктивного порівняння:
- що спільного
- що радикально відрізняється
- де цікавіше і чому

👉 Якщо бажаєте взяти участь в якості спікера, попрошу вас до кінця тижня заповнити цю форму: https://forms.gle/fTbSxyJ31xeRQLWPA

Дякую і бажаю вдалих проектів :)

Відео: Managed Support Service - як це працює

Колеги, починаємо тиждень з анонсованого раніше відео про Managed Support Service.

Багато хто вважає, що саппорт-сервіс - це “віддати” команду інженерів клієнту для регулярного багфіксу.

Таке розуміння, як мінімум, неповне - адже професійний саппорт-сервіс вимагає дотримання SLA, чітких алгоритмів обробки інцидентів, комунікації з клієнтом в стресових умовах.
А порушення заявленого часу реакції та вирішення інцидентів може вилитись в значні штрафи.

Більш того, саппорт-сервіс значно відрізняється від “звичайного” проекту з розробки ПЗ - як структурою команди, так і економікою бізнесу.

Мій гість - Ігор Коваль, Head of Information Security & Information Technologies @ Zehl, багато років займається саппорт-сервісом, знає як формуються саппорт-команди, комерційні пропозиції, SLA, тощо.

За півтори години ми встигли обговорити:
▪️рівні підтримки та типові ролі
▪️як забезпечити підтримку в режимі 24х7
▪️що робити, щоб уникнути вигорання команди
▪️як AI вже зараз впливає на саппорт-сервіси і що чекає нас в майбутньому

👉 Відео вже доступне тут: https://youtu.be/XonM_pAAjds

Дуже рекомендую всім, кому цікава тема саппорту.

Дякую Ігорю за цікаву розмову!

Як завжди, буду вдячний за поширення!

Нещодавно в приватній розмові я припустив, що сервісні компанії будуть не просто перемикатися зі стандартного SDLC на AI-augmented-розробку, але й почнуть надавати консалтинг з впровадження AI, як це робиться з CRM, ERP, автоматизацією, тощо.

Власне, деякі вже надають такі послуги (або кажуть, що надають).

А тепер і самі вендори AI-платформ вирішили включитись в цей процес - ось прес-реліз від Anthropic про створення сервісної компанії, саме для таких послуг: https://www.anthropic.com/news/enterprise-ai-services-company

Колеги, вчора записав розмову з людиною, що давно і глибоко займається напрямком Managed Support Services (тим, що з SLA, штрафами і всім іншим)

Це достатньо популярний запит, особливо від ентерпрайз-клієнтів, але далеко не всі компанії можуть надавати такий сервіс якісно і фінансово ефективно - як для себе, так і для клієнта.

Не в останню чергу тому, що економіка такого сервісу відрізняється від звичайного software development, та й від простого пост-релізного сапорту, який виконується силами девелопмент-команд.

Чекайте відео наступного тижня :)

Відео: Фасилітація - як тримати команду в фокусі

Чи бували ви в ситуації, коли треба провести важливу зустріч, а команда “не піддається”, не йде в конструктив? Або серед учасників є хтось, хто “не визнає авторитетів” і зриває розмову?

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

Фасилітація постійно присутня в нашому професійному житті, але далеко не завжди ми підходимо до неї усвідомлено.

Моя сьогоднішня гостя - Олеся Веремчук.
Окрім основної роботи (менеджмент проектів) Олеся проводить фасилітацію бізнес-зустрічей (наприклад, стратегічних сесій) на замовлення, а також тренінги з фасилітації.

Поговорили про:
- роль фасилітатора та (потенційний) конфлікт з іншими ролями
- "складних" учасників та стейкхолдерів, та як їх "приборкати"
- навички та правильне "налаштування" для проведення зустрічі

👉 Відео вже доступне тут: https://youtu.be/EQNKV7udlGY

Бажаю приємного перегляду і дякую Олесі за цікаву розмову!