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

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

Давно на цьому каналі не було відео... Виправляю ситуацію і публікую інтерв'ю, яке ми з Олександром Майданюком записали ще в серпні минулого року. Після роботи на позиції VP Technology в Intellias Олександр вирішив створити власний бізнес і зараз керує двома стартапами - VibeVenture.ai та PitchMyDream.io Говорили на тему, яка з моменту запису відео стала ще більш актуальною - AI, його вплив на SDLC, а відтак - і на бізнес сервісних компаній. Деякі з прогнозів Олександра вже почали ставати реальністю - тим цікавіше буде дивитися :) 👉 Відео вже доступне тут: https://youtu.be/FwZpdMAQhbc Бажаю приємного перегляду :)

Гнучкість, що лякає Колись давно, коли я ще працював ПМом, мені було потрібно зробити оцінку проекту на пресейлі. Ми з командою все оцінили, порахували, розписали скільки людей в яких ролях буде потрібно на проекті. Якось вийшло, що на тестування ми відвели дуже небагато часу, і пропорція QA до девелоперів виявилась дуже малою - хай буде 1 до 7, для прикладу (хоча точні цифри, я звісно не пам'ятаю). Мені ця пропорція не подобалась, але я вирішив її не змінювати. Підходжу до свого керівника, показую оцінку. Він дивиться і каже "Чому тут закладено так мало QA? Я би поставив більше". І тут спрацьовують мої попередні сумніви і я миттєво відповідаю - "ок, збільшимо до двох". Керівник підіймає на мене очі і уважно, навіть з підозрою, дивиться на мене. Повисає незручна пауза. А потім він каже фразу, яку я запам'ятав надовго: "Ти мене лякаєш, коли так швидко зі мною погоджуєшся". В будь-якій ролі, якщо тільки ви не джун або трейні, від вас очікують певного рівня професійності та експертизи. Це означає, що люди (в тому числі ваші керівники) розраховують на те, що ваші пропозиції є обгрунтованими - що перед тим, як щось пропонувати або говорити, ви подумали над тим, що збираєтесь казати і можете пояснити, аргументувати і захистити свою точку зору. Це не означає, що ви вперто маєте наполягати на своєму - якщо контраргументи будуть сильнішими за ваші, змінити думку цілком ок. Але миттєва необгрунтована (непояснена) зміна думки дійсно насторожує. Бо вона може означати: - необгрунтованість попередньої версії ("пальцем в небо") - вашу нездатність протистояти тиску Останнє особливо важливо для менеджерських ролей, а також у взаємодії з клієнтами. Адже і там, і там надійність та передбачуваність часто важливіші за експертність. Якщо щось пропонуєте - майте аргументи і будьте готові їх висловити Бажаю вдалих проектів :) — Підписатись: Telegram | YouTube

Де ваш архітектор? В будь-якому пресейлі (принаймні проектному, тобто такому, де вендор пропонує технічне рішення та відповідає за делівері) має бути виділений один головний технічний десижн-мейкер. Фактично - архітектор. І рівень цієї людини має бути відповідний - як мінімум інженер senior-рівня. Краще лід чи архітектор. Розумію, що ця думка звучить очевидною (і навіть непотрібною) для більшості простих пресейлів, де мова йде про веб-додаток середньої складності, де вся архітектурна робота зводиться до вибору техстеку. Але для більш складних і багатокомпонентих систем, де присутні різні технології і інтеграції, а особливо - складні нефункціональні вимоги, наявність однієї людини, що приймає остаточні технічні рішення - маст хев. Чому? Тому що інакше ваше рішення (а відповідно, і пропозал) не буде цілісним. Як результат: ▪️Проблеми з делівері: після старту проекту ваш ПМ з подивом зрозуміє, що якісь інтеграції просто не включені в скоуп і не оцінені ▪️Проблеми з запереченнями замовника: коли дійде до того, щоб зробити солюшн "дешевше" буде важко це зробити без цілісної картини технічної пропозиції ▪️Складність роботи з сейлзами. Сейлз завжди прагне продати. Часто - не розбираючись глибоко в технологіях. Немає архітектора - немає кому відповісти на тиск сейлза, або навпаки - допомогти йому аргументувати ціну (див. попередній пункт) Тому перед тим, як починати пресейл і вирішувати хто яку частину пропозала пише: 1) Призначте архітектора 2) Зберіться командою і проговоріть як ви розумієте потреби клієнта і яке рішення в цілому ви будете пропонувати 3) І тільки потім плануйте подальшу роботу Бажаю вдалих пресейлів :) — Підписатись: Telegram | YouTube

Одна з типових проблем аутсорсингу ... ... зазвичай виглядає так: Ви намагаєтесь встановити структурований процес розробки, напрацювати беклог на кілька спринтів вперед, узгодити плани та процедури, виконати необхідний обсяг тестування та багфіксу для стабільного релізу Клієнт абсолютно це не сприймає, вкидає кардинальні зміни посеред роботи, просить про швидкі релізи "тут і зараз", постійно переключається між задачами Ви намагаєтесь переконати клієнта в тому, що так працювати неправильно, що це демотивує команду і не допомагає (радше заважає) якісній роботі, закладає проблем на майбутнє Клієнт не реагує і каже "мені і так ок" ----- Можлива (і доволі розповсюджена) причина такого "різнобою" - різне розуміння моделі співпраці між клієнтом і вами, як вендором. Наприклад, вендор може сприймати вас як чисто staff augmentation вендора - він "купив" команду і дає їй роботу, як вміє. Ви, натомість, сприймаєте ситуацію як "проект", де ви та ваша команда несете відповідальність за делівері - терміни виконання, бюджети, якість. Через це і виникає конфлікт Тому один з перших кроків у вказаній ситуації - (пере)домовитись про модель співпраці і чітко визначити, за що ви відповідаєте: - Якщо відповідальність за делівері - на вас, то саме ви маєте визначати процес розробки, розподіляти задачі всередині команди, і структурувати роботу з клієнтом через планінги, управління змінами, тощо - Якщо ви НЕ відповідаєте за делівері, а клієнт просто "купує" команду - то просто працюйте за його процесом Головне - щоб всі однаково розуміли зони відповідальності ----- (написано за мотивами нещодавнього кейсу консультації, а також за власним досвідом з часів ПМства) Бажаю вдалих проектів :) — Підписатись: Telegram | YouTube

Принагідно нагадаю, що в нас є група для обговорення - коментарі під постами там відображаються автоматично, а також іноді учасники стартують свої теми. Подивитись можна тут: https://t.me/+fPRO9DCdLNg1YTVi

Отже, щодо кейсу вище На мій погляд, принципово важливий момент - вирішити з якої точки зору ми дивимось на умови, які пропонує нам клієнт. Тут можливі два варіанти: 1) Розглядаємо цей кейс як замовлення на послуги з розробки ПЗ (тобто, стандартний кейс аутсорсингу). В такому випадку на запропоновані клієнтом умови погоджуватись не можна - високий ризик, а додаткової користі для нас як для вендора немає. Навіть і з підвищеним рейтом. Особливо з точки зору компенсації втрат через дефект - це взагалі кроляча нора, з якої буде важко вийти 2) Розглядаємо цей кейс як бізнес-партнерство між двома компаніями. Ось в цьому випадку можна розглянути пропозицію клієнта більш серйозно, але тоді варто говорити і про те, щоб розділити прибуток від продажів продукту. Звичайно, і в тому, і в тому випадку треба ще рахувати цифри і дивитись на рівень ризику, який ми можемо собі дозволити. І ще важливий момент - якщо в першому випадку рішення може приймати менеджмент компанії, то в другому - це радше відповідальність власника, оскільки мова вже йде не про стандартні послуги, а домовленості будуть ширшими за те, чим займається компанія. Дуже дякую за ваші думки і коментарі і бажаю вдалих проектів :)

Колеги, пропоную розглянути цікавий (сподіваюсь) кейс: Ви - сервісна компанія. Ваш потенційний клієнт отримав від вас пропозал на розробку ПЗ. Він погоджується на пропозал, але додає наступні умови: 1) Ви ведете розробку своїм коштом. Оплата (по рейтах, що в пропозалі) буде здійснена тільки після отримання відповідного доходу від продажів продукту 2) У випадку дефектів (після релізу) ви маєте їх безкоштовно пофіксити. Окрім того, маєте компенсувати втрати, викликані дефектом При цьому рейти, які включені в пропозал (і по яких збирається платити замовник є +/- вашими стандартними рейтами) До якого варіанту ви б схилилися: А) прийняти такий пропозал в принципі, але наполягати на вищому рейті Б) прийняти як є В) наполягати на стандартному контракті на розробку без додаткових умов Ваші думки (в будь-якій формі) можете залишати в коментарях під цим постом 👇 Днями поділюсь своїм баченням ситуації

Я рідко (насправді - ніколи) не висвітлюю тут інші канали, але сьогодні буде виключення Частина з вас знає, що публічна частина моєї кар'єри, як автора та викладача курсів, а згодом і консультанта, почалася зі школи IAMPM у вже далекому 2020-му. Саме ця школа надала мені можливість з перших днів створити свою авторську навчальну програму (а не викладати по матеріалах інших експертів), що для мене надзвичайно важливо. Нещодавно Мері, CEO IAMPM, продала школу. Тепер Мері веде канал для власників бізнесів, де пише про свій досвід продажу компанії, зокрема: • як насправді виглядає шлях до exit • якою має бути компанія, щоб її купили • і про те, про що зазвичай мовчать Бажаю Мері успіхів у новій справі і дуже рекомендую її канал: https://t.me/marybuilds Гарного початку тижня!

В 2025 році я встиг проконсультувати кілька сервісних компаній. Один з моментів, які підсвічували клієнти в моїй роботі - це увага до аналізу AS-IS-ситуації Виявляється, це роблять далеко не всі консультанти - дехто просто приходить і одразу розповідає "як все має працювати". Як на мене, є дуже вагомі причини все-таки проводити AS-IS-аналіз на початку консалтингу або коли ви стаєте новим керівником якоїсь функції: 1) Ви виявляєте повагу до людей, з якими вам надалі доведеться працювати. Вони будували свою роботу роками і робили це якнайкраще в межах своїх компетенцій. Попросіть їх розповісти як все відбувається зараз - і ви зменшите тертя під час впровадження змін 2) Розмови з колегами дозволять зрозуміти їх (колег) сильні і слабкі сторони, оцінити їх досвід, та й в принципі познайомитись 3) Те, як процеси реалізовані "на сьогодні" має свої причини, про які ви можете не здогадуватись. Вивчення AS-IS-картини допоможе в розумінні цих причин, а відтак - і в розумінні специфіки компанії або відділу, з яким ви плануєте працювати. 4) В існуючих процесах можуть бути (і швидше за все будуть) елементи, які варто зберегти - про них варто знати 5) Нововведення будуть сприйматися краще, якщо люди знатимуть, що вони будуються не на "порожньому місці", а з урахуванням контексту, в якому вони працюють. Бажаю вдалих проектів :) — Підписатись: Telegram | YouTube

Про KPI пресейлу Якщо в вашій компанії пресейл виділено в окрему функцію, постає питання про KPI. Ширше (навіть якщо окремої функції немає) воно звучить так - що таке "добрий" пресейл? Перше, що спадає на думку (особливо з точки зору бізнесу взагалі) - почати вимірувати Win Rate - тобто відсоток виграних opportunity від всіх закритих. Це хороший показник, але він не може бути єдиним показником для оцінки якості роботи пресейл-функції, і ось чому: - Пресейл ≠ Сейлз. На успішне закриття контракту впливає багато речей, що знаходяться поза зоною впливу пресейл-відділу - наприклад, рейт-карта, контрактні умови, стосунки зі стейкхолдерами клієнта - Задача пресейл - не просто"продати", а продати реалістичні очікування - бо інакше потім ваше Делівері матиме проблеми з реалізацією проекту (саме тому пресейл як частина сейлз-відділу - погана ідея) - Якщо вже й міряти Win Rate - робити це треба тільки на базі кваліфікованих оппортюніті, при чому кваліфікація має відбуватись за критеріями, погодженими між сейлз-пресейл-делівері функціями. Тоді ви знатимете, що компанія намагається виграти лише те, що може реалізувати, і те, що комерційно привабливо + реалістично з точки зору проведення самого пресейлу (наприклад, час на підготовку пропозалу - достатній, ми, як вендор, маємо всі необхідні сертифікації, тощо) На додачу до Win Rate вартує ще додати якусь метрику, яка враховує реалістичність пропозалів. Це важко зробити, адже проекти в Делівері можуть фейлитись навіть якщо пресейл пройшов ідеально. Одним з варіантів може бути вимірювання внутрішнього Customer Satisfaction Index, де пресейл сприймається як сервіс, внутрішніми клієнтами якого є Продажі та Делівері. Ось тоді маємо +/- збалансовану оцінку якості пресейлу: - Win Rate з кваліфікованих оппортюніті - CSAT за участі Делівері та Продажів Бажаю вдалих пресейлів :) — Підписатись: Telegram | YouTube

Якісне Делівері - ззовні і зсередини Коли починаєш керувати якоюсь функцією, дуже важливо зрозуміти для чого вона потрібна бізнесу - тобто власникам і керівникам компанії. Для прикладу, запитайте себе - для чого в сервісній компанії потрібне Делівері? Не як процес або ролі, а як структура, частина організації. На перший погляд відповідь буде очевидною - щось на кшталт: - Щоб надавати клієнтам якісний сервіс - Щоб виконувати проекти вчасно та в межах бюджету Всі ці варіанти - вірні, більш того - всі вони є елементами одного пазла. Але є одне "але" Якщо поглянути на те саме питання не "зсередини" Делівері, а "ззовні", тобто з позиції менеджменту або власників компанії, то відповідь зміниться. З цієї "зовнішньої" точки зору Делівері має забезпечувати: - client retention - тобто робити свою роботу так, щоб клієнти залишались з компанією - певний рівень прибутковості проектів - upsell - продавати додаткові послуги/проекти існуючим клієнтам Саме за цими показниками "бізнес" буде оцінювати Делівері. Особливо якщо функція акаунт-менеджменту в вашій компанії вбудована в Делівері (бувають різні варіанти). При цьому якісне виконання проектів як таке (бюджет, таймлайн, тощо) буде другорядним фактором, який впливає на результат, але не відображає його безпосередньо. Якщо ви керівник делівері-функції, то для тих, хто керує вами, це - ваші внутрішні "деталі" Умовно, якщо всі проекти виконані якісно, але клієнти при цьому масово йдуть від компанії, то таке Делівері не буде вважатись успішним. Те саме відбудеться, якщо проекти виконуються вчасно, але з низьким рівнем прибутковості (тобто, для того, щоб "витягнути" свій комітмент перед клієнтом ви залучаєте додаткових або надто дорогих спеціалістів). Така сама історія відбувається з кожною функцією в компанії - є внутрішні показники, які потрібні керівникам функції, і є зовнішні - ті, за якими функцію "міряють" ззовні. Для якісного виконання роботи потрібно знати і внутрішню і зовнішню сторону справи. Бажаю вдалих проектів :) — Підписатись: Telegram | YouTube

Спостереження року Замість підсумків року та на додачу до привітань поділюсь своїми суб'єктивними спостереженнями індустрії за 2025 рік. Суб'єктивні - набуті на власному досвіді, або через спілкування з колегами, компетенції яких можу довіряти. На дуже різні теми і з дуже різних сфер. Без претензії на універсальність. 1. Пресейл. Точно буде змінюватись. Основний акцент - швидкість та візуальність/інтерактивність. Те, для чого раніше робили місячне діскавері, в результаті якого мали беклог, архітектуру та UX, тепер буде тривати значно менше, а на виході мати функціональний прототип. Цього року вже бачив компанії, які роблять перші кроки - AI-based оцінка (підтверджена делівері), прототипування. Також знаю про клієнтів, що проводять "офлайн-хакатони", де вендори мають безкоштовно надати прототипи рішень як частину пропозалу 2. Позиціонування компаній. Є думка, що аутсорсер заробить більше, якщо буде вирішувати "бізнес-проблеми" своїх замовників замість "технічних" проблем. В теорії це вірно, оскільки в такому разі замовником є "бізнес", а не ІТ, і чеки більше. Проблема в тому, що для допуску до таких проблем, вендор має мати відповідний "brand permission" - тобто сприйматись саме як компанія, що допомагає на рівні "бізнесу", а не просто "розробляє софт". Для цього треба мати або дуже великий розмір, або дуже вузьку галузеву спеціалізацію. Такий brand permission мають компанії на кшталт Accenture, а от більшість українських (і не тільки) вендорів розглядаються саме як інженерні провайдери. 3. Корпоративна культура. Не зважаючи на схожість в послугах, різні сервісні компанії роблять свою роботу дуже по-різному. За цей рік бачив компанії: - швидкі і повільні - з дуже чіткою і продуманою оргструктурою і дублюванням функцій - ті, що хочуть великих клієнтів і ті, які свідомо йдуть на обмеження місячного чека від одного клієнта, щоб диверсифікувати портфель - орієнтовані суто на гроші, і ті, що багато думають про людей і про свій імпакт в індустрії (не забуваючи про гроші звісно) 4. АІ. Якщо на початку року я ставив собі питання "чи змінить АІ звиклий нам SDLC, то зараз впевнений, що так, змінить". Питання - коли, як, і наскільки компанії будуть до цього готові. Мав на цю тему кілька розмов з дуже експертними людьми впродовж року. Без хайпу і зайвого футуризму, а на базі того, що вони роблять вже тут і зараз. Поділюся згодом. І ні, AI менеджерів не замінить, але менеджерам варто розуміти як впроваджувати AI-augmented SDLC. 5. Ринок аутсорсингу. Моя особиста думка - маржинальність цього бізнесу буде згодом зменшуватись. І не тільки для staff augmentation і ТМ-моделей. Fixed-Price та outcome-based-моделі теж там будуть, але трохи згодом. Я вже втретє в своїй кар'єрі бачу масові кост-оптимізації і маю враження, що зараз це має дещо інший характер - деякі компанії зменшують кости на базові речі, без яких певні функції просто не можуть працювати. Вихід з цього - поступове відновлення витрат зі збереженням або незначним ростом revenue, що з рештою призведе до зменшення маржи (Повторюю, це суто особисті думки. Буду вдячний за ваші коментарі) --- Дякую, що читали в 2025 і до зустрічі в 2026! З Різдвом та Новим Роком! Бажаю вдалих проектів :) 🎄🎁🎉 — Підписатись: Telegram | YouTube

Хто такий Senior? Минулого тижня на курсі з делівері-менеджменту попросили назвати основні критерії відбору кандидатів на роль Senior PM. Далі наводжу свої думки, але треба сказати, що вони релевантні не тільки для PMів, а для будь-яких ролей рівня Senior. 1. Знання кількох альтернативних інструментів Senior-спеціаліст не може мати один "молоток", щоб вважати все "цвяхами" - він/вона має підбирати інструментарій під ситуацію У випадку ПМа це можуть бути процесні фреймворки. Невелика команда - Scrum, кілька команд в одному солюшені - SAFe, робота що вимагає не ітерацій, а постійної поставки - Kanban (це лише спрощені приклади) 2. Наявність в досвіді кризових ситуацій Створених самостійно чи "чужих", які треба було "розрулювати". Бажано - з досвідом успішного розв'язання. Тільки в кризах та проблемних проектах ПМ (і будь-який інший менеджер) досягає меж своєї компетентності. І тільки досягнувши цих меж, може їх розширити. + Такі ситуації тренують стресостійкість, кризові комунікації, тощо 3. Досвід менторинга менш досвідчених колег Не те щоб маст-хев, але такий досвід буває корисним. По-перше, це заявка на подальше зростання. По-друге - "розповів іншому - зрозумів сам" - часто менторинг інших допомагає сформувати в спеціаліста усвідомлену компетентність — І так, звичайно - все це йде на додачу до багатьох інших хард- і софт-скілів, які компанія (бажано) має звести в матрицю компетенцій, з якої можуть "вирости" й чек-лісти для співбесід на різні рівні. Бажаю вдалих проектів :) — Підписатись: Telegram | YouTube

Хто в компанії головний? Консультуючи різні сервісні компанії з питань пресейлу, я бачу принаймні два типові патерни: Sales-driven В такій компанії часто сейлзи (люди з сейлз-бекграундом) широко представлені в керівництві, або принаймні мають вагомий вплив на прийняття рішень Delivery/Engineering Driven В керівництві - люди з делівері-досвідом, або інженери в минулому. Відповідно саме ці відділи (і спеціалісти цього профілю) відіграють важливішу роль в рішеннях та розробці стратегії Ці два типи компаній (а швидше - культур) проявляють себе по-різному в багатьох процесах, але найяскравіший приклад такого процесу - це opportunity qualification, тобто прийняття рішень "візьмемо/не візьмемо цей проект в роботу". Sales-driven-компанія дивиться більше (або навіть виключно) на комерційні характеристики - великий клієнт, класний потенціал зростання, бажано великий проект. Вміємо чи не вміємо ми такі проекти робити - питання другорядне. Не вміємо - навчимося, або когось наймемо. Основний акцент - отримати нового клієнта. Delivery-driven-компанія має більший фокус на тому, чи можна цей проект виконати - наявність досвіду, компетенцій, реалістичність вимог клієнта, тощо. Це не означає, що якщо проект занадто ризикований або "не наш", компанія його ігнорує. Вона може, наприклад, залучити партнерів з відповідним досвідом, або повністю передати їм проект за певну комісію. Але загалом підхід до продажів більш "обережний". Ясно, що світ не чорно-білий, і завжди є напівтони та виключення, але кореляція все-таки помітна :) Бажаю вдалих пресейлів, в якій би компанії ви не працювали :) — Підписатись: Telegram | YouTube

Про ретроспективи пресейлів Про проектні ретроспективи знає майже кожен - хтось проводить кожного спринта, хтось в кінці релізу, хтось не проводить взагалі В пресейлі ретроспективи теж проводити можна, і в принципі, треба, якщо ви дійсно хочете щоб у вашій діяльності мав місце славнозвісний continuous improvement Я особисто мав досвід/проводив пресейл-ретроспективи двох типів: 🟦 Ретро по програному пресейлу Тут загалом все очевидно - програли оппортюніті, є бажання зрозуміти чому так сталося і що ми можемо зробити в майбутньому Питання, що обговорюються: - фідбек від клієнта, якщо він був - спостереження команди на тему "що було не ідеально" / що можна зробити краще - що саме на наш погляд призвело до того, що обрали не нас і чи це взагалі від нас залежало (наприклад, клієнт з самого початку не був налаштований на підписання контракту, а просто взяв наш пропозал для порівняння/вивчення ринку) 🟦 Ретро по виграному пресейлу Трохи менш очевидний кейс, бо "навіщо щось обговорювати якщо ми успішно продали проект" Насправді "успішно" чи ні ми побачимо не одразу, а за кілька місяців/тижнів (в залежності від розміру проекту) Наприклад, під час делівері можуть виникнути проблеми, яких можна було б уникнути, якби пресейл було проведено більш ретельно Ось саме на такі аспекти і налаштований цей тип ретроспектив - що ми (не) зробили на пресейлі, що призвело до проблем в делівері і чи могли (і чи можемо надалі) ми все таки змінити свій процес, щоб зменшити ймовірність проблем Наприклад, могли не пояснити клієнту "правила гри", або ідентифікувати не весь скоуп, або помилитись в оцінці. На такі ретро дуже важливо залучати ще й делівері-команду, бо хто ж ще вам розповість про те, як проект жив після підписання контракту. Бажаю вдалих пресейлів і результативних ретроспектив :) — Підписатись: Telegram | YouTube

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