×

Яку engagement модель обрати Senior PM-у, який переходить у Delivery?

Стаття базується на бесіді з Іваном Погребняком, ex Delivery Operations Director of Ciklum, а зараз консультантом для іноземних компаній по встановленню незалежних R&D центрів в Україні.

В Україні не існує стандартизованого росту до позиції Delivery Manager взагалі. А те, що існує, кардинально відрізняється від картини в Штатах, де кандидат може стати Delivery, умовно, через 10 років роботи на конкретних позиціях. Але в цій ситуації є і позитив для спеціалістів в Україні. Тут немає прив’язки до років досвіду, а тільки до навичок, які ви встигли розвинути. І, залежно від того, наскільки ваші навички метчаться зі skills metrics позиції Delivery у великих аутсорс компаніях, настільки швидко ви можете досягти цієї посади. Така прогресивна шкала, в середньому, дуже подібна у великих аутсорсингових конгломератах в Україні. І ці компанії шукають на позицію Delivery Manager прогресивних людей, які вже попрацювали як PM, виросли до сінйорного рівня і хочуть відповідати за весь SDLC (Software Development Lifecycle).

Якщо ви розумієте, що наступна сходинка вашої кар’єри — це DM, важливо розібратись з ключовими engagement моделями співпраці аутсорсу з замовником після підписання договору і визначитись, з якою ви готові працювати.

Таких моделей взаємодії існує три. Для того, щоб з’ясувати в якій з них буде йти співпраця з клієнтом, IT компанії оперують 3-ома ключовими факторами: risk, control, responsibility.

Risk стосується відповідальності за кінцевий продукт. Відповідальність може нести або замовник, або компанія, або і той і інший — shared responsibility.
Responsibility відноситься до найму і утримання співробітників. Хто приймає рішення, що на проект потрібно наприклад, 3 джавіста з таким-то профайлом, хто проводить інтерв’ю і хто затверджує кандидата.
Control — тут йдеться про щоденну модерацію, беклог і контроль процесу розробки продукту.

В залежності від комбінацій цих трьох чинників включається одна з з трьох моделей співпраці: аутстаффінг, team/project on T&M та fixed project.

Перша модель — це аутстаффінг, або її ще називають extended team і dedicated team. Тут всі 3 фактора відповідальності лягають на плечі клієнта. Модель має найменший gross margin для аутсорс провайдера, а для клієнта — це найдешевший варіант. Адже за кожен з факторів, коли клієнт перекладає відповідальність на аутсорсера, збільшується і вартість послуг. В основі цієї моделі не існує бенча. Колектив набирається з ринку, і після закриття проекту спеціалісти випускаються на ринок з termination notice і підтримкою в пошуку нових проектів. В інших типових варіантах аутсорсингових напрямків такого не існує. Всі спеціалісти сидять на бенчі і відбувається передислокація.

Друга модель — це team або project на Time & Material (T&M), ще можуть додавати слово «managed». Тут відповідальність щодо команди повністю переходить до аутсорс компанії, а ризики щодо фінального продукту бере на себе клієнт. В більшості випадків аутсорсер також контролює day-to-day розробку. Тут розрахунок з компанією може йти як по rate card — коли клієнт кожен місяць платить за спеціалістів, так і по T&M (time &material), коли біллінг відбувається за конкретну кількість годин роботи.

Третя модель менше піддається модифікаціям — це fixed project. В цьому варіанті і responsibility, i control, i risk падає повністю на аутсорс провайдера. В сьогоденні, продукт в цій моделі пишуть значно рідше, тому що це найбільш ризикована справа, ніякої гнучкості, і точно не agile, тому що ніхто не дасть змінити специфікації по ходу справи. Є дуже мало випадків у великому аутсорсі, де компанії підписуються на щось подібне до fixed price і комітяться видати конкретний результат за кілька років. Тоді починають маневри з ресурсами, пошук дешевших варіантів та інші спроби викрутитися в строки і бюджет. Fixed project зазвичай є лише частиною гібридних проектів, коли частина процесу фіксована, а решта виконується по моделі T&M.

Тому, коли ви збираєтесь застрибнути на позицію Delivery Manager — головне питання — це за що відповідає аутсорс провайдер в якому ви хочете працювати. Від цього напряму залежать ваші обов’язки. Хоча в аутстаффінгу клієнт бере на себе всі ризики, у вашій відповідальності буде надати йому команду «під ключ», організувати рекрутмент, ретеншн, екосистему додаткових технологічних послуг і виступити в ролі консультанта, як єффективно налагоджувати увесь процес розробки, але ви не будете нести остаточну відповідальність за продукт. Якщо ж ви будете працювати в моделі fixed price або T&M проектах — відповідальність виходить на зовсім інший рівень, і DM вже бере в свої руки весь actual software development process.

Тож тричі подумайте, з яким форматом ви готові працювати на позиції Delivery Manager. Від цього сильно залежать вимоги до вас при спілкуванні з IT компанією.

Щоб глибше копнути у Delivery Management та варіанти виходу на цю позицію, компанія Skyworker огранізовує зустріч зі спеціалістами Delivery для Senior PM-ів 29 — травня.

Запрошуємо спеціалістів, які збираються рости до позиції Delivery Manager в перспективі.

Деталі події тут: www.facebook.com/events/1853140244986805

Гарних вам офферів!

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
одна з з трьох моделей співпраці

з зайва 😊

Зарпошуємо спеціалістів

опечатались, поправьте пожалуйста, если еще можете редактировать статью

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

навички метчаться
і комітяться видати
ретеншн

— для чого?читати неможливо

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

ну можно было и не транслитерировать понапрасну, все равно уже пол-текста на английском

Стаття базується на бесіді з Іваном Погребняком

ну може так в оригіналі ?
P.S.
Але чому

Risk стосується відповідальності за кінцевий продукт. Відповідальність може нести або замовник, або компанія, або і той і інший — shared responsibility.

і зразу

Responsibility відноситься до найму і утримання співробітників

не зрозумів. Яким чином визначення поняття «responsibility» мутує від того, що воно «shared» ?

Нужен enlarged model (к) (тм)

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