Value-Driven Development: досвід трансформації сервісної команди в продуктову

Стаття написана у співавторстві з Катериною Сиротинській, HR-директором в Omnicore, і Дмитром Куявцем , консультантом в області цифрових та організаційних трансформацій.

Ця стаття присвячена досвіду трансформації української сервісної команди в продуктову. Тут ви знайдете як теорію, так і інформацію про реалізації.

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

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

Розвиток за кількісним сценарієм, очевидно, є тупиковим, оскільки (навіть організувавши демографічний бум :) ) країна не зможе виграти в конкурентній боротьбі за вартість послуг у перманентно демпінгують Індії, Пакистану чи Філіппін. Другий, якісний, сценарій є більш складним і ризикованим, але він дозволить вибудувати довгострокову ціннісно орієнтовану стратегію. Багато ІТ-аутсорсингові компанії роблять ставку на проектну розробку, деякі — на дослідження, і лише одиниці пропонують продуктову розробку.

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

Висновок № 1: зручно, але недобре

І все-таки, крім зниження доходів з-за високої конкуренції і «генерації» величезної кількості низькопрофільних ІТ-фахівців, навіщо відмовлятися від такого зручного ІТ-аутсорсингу і щось там будувати? Адже добре!

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

Випадково чи поспішно зібрана сервісна команда не здатна вирішувати складні завдання в довгостроковій перспективі. Крім того, така команда не в змозі ефективно інтегруватися в компанію-замовника для спільної розробки інноваційного продукту. А враховуючи статистику, «плинність» кадрів в аутсорсингових ІТ-командах становить понад 20% , що взагалі викликає питання, чи може ця група людей називатися командою. Не радують такі перспективи? Тоді читайте, як трансформувати сервісну команду в продуктову нижче.

Висновок № 2: ні, не клієнтоорієнтованість

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

Тому що для функціонування команди як системи, необхідно налагодити взаємодію між усіма трьома рівнями її функціонування: командою (людьми), продуктом і бізнесом.

Напевно ви ставите питанням, яким чином пов'язані між собою ці настільки нерівноцінні рівні і як цей зв'язок побудувати? На кожному з рівнів релевантною є своя система цінностей, і найважливішим завданням при побудові ефективної продуктової команди є розуміння і поділ командою цінностей компанії (бізнесу) і замовника (продукту). Тільки при цьому умові можливо її подальший розвиток.

Цінності продуктової команди як системи

Висновок № 3: еволюція, не революція

Що це за цінності, як з ними працювати і як зробити так, щоб з'явилася система цінностей, релевантна для команди, для клієнта і для бізнесу одночасно? На цей нетривіальний питання хотілося б відповісти влучним висловом: «Цінності — це не якості співробітників, а ідеї, за якими стоїть команда». Тобто на передній план виходить поняття культури як сукупності цінностей членів команди, які inline з цінностями компанії і замовника, а також надають на команду і всю систему саморегулирующее управлінський вплив.

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

Висновок № 4: ні, не грошову винагороду

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

Отже, 8 ключових цінностей співробітників продуктових команд в порядку їх пріоритетності:

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

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

Висновок № 5: не лінійно

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

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

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

Контекст взаємодоповнюваності на основі різних типажів особистостей досить широко відомий і не буде фокусною в цій статті. Хотілося б лише нагадати, що буде доречно використовувати такі підходи, як DISC і Belbin, з їх відмінними готовими опитуваннями, описами і рекомендаціями по композиціям команд. У цій статті ми хотіли б сфокусуватися на створенні спільності на «живому» прикладі трансформації невеликий української команди з сервісного рівня в продуктовий.

Історія однієї трансформації

Мотиваційні фактори

Отже, спочатку у нашому активі була маленька команда Red Dot Square, що складається з 7 осіб, які працювали в сфері VR. На етапі маленької команди немає необхідності в чітко формалізованій місії і бачення, досить наявності у працівників загальних цінностей, які будуть їх об'єднувати. Також ця команда повинна складатися з людей, що мають однаковий рівень відповідальності (ownership) за свій продукт.

Першим микрошагом до трансформації команди Кантар стала поява в команді проектного менеджера. Старт проектної роботи все ж передбачає наявність спільної місії та візії команди, які повинні транслюватися замовником.

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

Щоб більш системно підійти до цього завдання, було прийнято рішення взяти за основу для розвитку команди теорію спіральної динаміки. Стан To-Be ми визначили рівень цінностей компанії в спіральної динаміки. Стан As-Is — це той рівень спіральної динаміки, на якому знаходяться цінності команди в даний момент. На жаль, готових опитувальників по спіральної динаміки нам не вдалося знайти, тому довелося створювати власні.

Еволюція розвитку команди Кантар

Дорожня карта трансформації стану As-Is To-Be вимагала ряду кроків, перше з яких стало створення ініціативної групи агентів змін (leadership team), місією яких стала допомога команді в адаптації цінностей.

Місія — агенти змін

Навіщо потрібні агенти змін? Тому що цінності і цілі ToBe необхідно було донести до членів команди в доступній формі і на власному прикладі, каскадируя їх зверху вниз, від агентів до команди.

Для цього команда агентів змін регулярно, з періодичністю один-два рази в два-три тижні, збиралася для того, щоб в неформальній обстановці прописати поведінкові стандарти, які прив'язувалися до кожної з цінностей. Наприклад, We Develop — що це означає для нас? Чи означає це, що ми повинні розвиватися самі і допомагати один одному зростати? Як нам це реалізувати на практиці? Так, розширити компетенції колег можна за допомогою ініціювання регулярних inspiration breakfast, коли щотижня впродовж години будь-який член команди може поділитися своїм досвідом або новими знаннями з колегами. Сесія обов'язкова для всіх членів команди.

Оскільки агенти змін — це колеги, з якими кожен член команди регулярно спілкується, дружить і пише код, практика щотижневих leadership team не викликала спротиву і була прийнята членами команди з ентузіазмом.

Етапи каскадування цінностей Кантар

Налагодження взаємодій в команді

Завдяки зусиллям команди агентів змін на момент «синьої» організації спіральної динаміки нам вдалося створити і імплементувати поведінкові стандарти, вибудувати організаційну структуру, прописати job-інструкції, а також створити handbook з прописаними правилами, корпоративними та соціальними активностями.

Практики команди Кантар на етапі «синьої» організації спіральної динаміки

І це все не залишилося лише «на серветках». Так, поведінкові прояви (Behavior), які є наслідком цінностей, имплементированными самими співробітниками, кожні півроку оцінювалися за допомогою спеціального опитувальника 360 (опитувальник можна буде знайти за посиланням нижче), який показував, наскільки цінності людини і його поведінкові патерни відповідають організаційним. Продуктивність (Performance) співробітника оцінювалася по ряду kpi's, які відстежувалися PMO-командою аудиторів замовника та/або аутсорсингової компанії. Компенсація також була обов'язковою, однак залежить від фінансових результатів компанії.

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

Мотиваційний трикутник Кантар

Моніторинг процесу трансформації команди

В якийсь момент для моніторингу прогресу трансформації ми стали використовувати рівні спіральної динаміки як майлстоуны, адже згідно теорії «перестрибувати» рівні не можна, все розвивається послідовно. В самому початку шляху, ще до розробки анкет, був ініційований процес отримання зворотного зв'язку у співробітників про їх внутрішньої оцінки рівня команди. Команда оцінила себе як знаходиться на верхніх рівнях, однак, як з'ясувалося, насправді ми стартували з нижніх рівнів цінностей. На той момент ми були скуті великою кількістю процедур і правил, які блокували наш рух в помаранчеву область — «корпорацію успіху».

В підсумку наша система моніторингу прогресу трансформації звелася до:

Еволюція порогу входу в команду Кантар

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

Етапи впровадження мотиваційного трикутника Кантар

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

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

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

Опубліковано: 15/08/19 @ 10:00
Розділ Сервіси

Рекомендуємо:

Шлях від QA до Product Owner: як зважитися на зміни в кар'єрі
Мотивація до інновацій у IT-компаніях України. Результати опитування
Топ-50 ІТ-компаній України, липень 2019: 60 тисяч спеціалістів і подолання відмітки «7000 фахівців»
C++ дайджест #18: Summer ISO C++ standards meeting, technical vision for Qt 6
Ruby/Rails дайджест #31: другий реліз-кандидат Rails 6, перша мажорна версія ruby-prof, Aaron Patterson про рантайме Ruby