Джерело: cloud.google.com
Алекс МакУільям, голова німецького відділу інфраструктури Google.
Нещодавно Річард Серотер, директор із взаємодії з розробниками та управління розгортанням продуктів, розповів про важливість використання вже існуючих ресурсів та функціональних можливостей, щоб полегшити навантаження як для ваших розробників, так і операторів. Я не можу з цим не погодитись у контексті моєї роботи, коли я консультую керівників інженерів з питань модернізації хмарних обчислень. Однак, якщо ваша організація створює власну платформу (і, відповідно, команду розробників платформи), зробіть собі ласку і поставте собі кілька запитань, перш ніж почати. Повірте мені на слово: якщо ви цього не зробите, ваша платформа зазнає краху.
Створення внутрішніх технологічних платформ на підприємстві сьогодні в моді, і на те є вагома причина: вони дозволяють ІТ-фахівцям працювати незалежніше, зберігаючи при цьому централізоване управління та безпеку. Хмара не тільки сама по собі є платформою, вона також надає чудову можливість для розробки додаткових внутрішніх платформ поверх неї, наприклад: платформа даних з BigQuery, платформа ML/AI з Vertex AI, платформа управління API з Apigee, або середовище виконання контейнерів з Google Kubernetes Engine. Платформи працюють поверх платформ.
Для ІТ-директора або корпоративного архітектора стратегічна важливість інвестицій у платформу може здатися очевидною. Є тільки одна проблема: нікому на вашому підприємстві немає справи до вашої платформи. Те, що ви її збудуєте, не означає, що до неї прийдуть.
Звичайно, ви можете змусити людей використовувати вашу платформу, але тоді ви виконаєте лише половину своєї місії: ви отримаєте централізоване управління та систему безпеки, але ви відкинете своїх внутрішніх користувачів назад, змусивши їх переучуватися та перебудовувати процеси. Це те, про що вони не просили і (суб’єктивно) не потребували, і, отже, обурюватимуться ще до того, як почнуть користуватися. Якщо досвід кінцевих користувачів не буде бездоганним, вони звинувачуватимуть і платформу, і вас.
Невже неможливо досягти не тільки використання, але й ухвалення нового рішення? Чи завжди нові внутрішні платформи приречені на провал? На щастя, не завжди.
Є три основні питання, на які ви повинні заздалегідь відповісти, щоб настроїти себе на успіх: Для кого ви створюєте платформу? Хто має намір її будувати? І, що не менш важливо, як ви вимірюватимете успіх?
Запитання 1: Для кого ви створюєте платформу?
Ми всі чули пораду «почати з користувача та працювати у зворотному напрямку». Однак на великих підприємствах це може бути складнішим, ніж здається. Фактичним користувачем вашої внутрішньої платформи є співробітник іншого відділу, але його потреби представлені керівником його відділу або власником продукту. Вони, у свою чергу, можуть взаємодіяти з «головою платформи X», який розставляє пріоритети в беклог функцій і делегує проектування архітектури корпоративному архітектору, який, у свою чергу, дає вказівки розробникам платформи про те, як її побудувати… Що там було потрібно вашому користувачеві?
Ось що має відбуватися: розробники платформи, які створюють вашу внутрішню платформу, повинні регулярно зустрічатися з реальним користувачем віч-на-віч за підтримки менеджера з продукту, який є частиною їхньої команди. Всі, хто бере участь у створенні або використанні платформи, повинні розташовуватися в одній кімнаті або принаймні відображатись на одному екрані Meet/Zoom/Teams. Найкращі платформи часто створюються людьми для себе – ви не можете наблизитися до свого користувача ще ближче, якщо кінцевий користувач – ви.
Якщо ви не можете дозволити собі розкіш зібрати всіх зацікавлених осіб в одній кімнаті, є потужний інструмент, який можна використовувати, щоб подолати розрив: сесії спостереження за користувачами. Сесії спостереження за користувачами – це еквівалент фокус-групи, коли ваші інженери збираються разом, щоб дивитися запис екрана комп’ютера користувача і слухати супутній голос (звичайно, з дозволу співробітника). Все, що вам потрібно зробити, це набрати п’ять тестових користувачів і дати їм ті ж дві або три цілі для виконання, використовуючи або застарілі платформи, які ви хочете замінити, або MVP-версію нової платформи, яку ви вже створюєте. Скажіть їм, щоб вони думали вголос і озвучували будь-які припущення, які вони роблять, та будь-яку плутанину, з якою вони можуть зіткнутися.
Ви будете вражені, побачивши, як навіть найрозумніший і найкмітливіший тестовий користувач витратить більше часу, ніж ви думали, і застрягне там, де, як ви думали, застрягти неможливо. Можна відкинути ці спостереження як анекдотичні винятки або думати, що чіткіша документація і додаткове навчання вилікують усі хвороби, але реальність така, що ви спостерігаєте у всій її невідфільтрованій красі справжню проблему, з якою стикається нова платформа: неможливість відразу радувати ваших користувачів і полегшувати їхню роботу.
У сесіях спостереження за користувачами також відбувається узгодження пріоритетів усередині вашої інженерної команди, тому що всі щойно бачили одне й те саме на власні очі та вуха. Раніше у кожного члена команди могла бути своя улюблена функція, яку він хотів створити в наступну чергу, а тепер цілком очевидно, яка з функцій найбільше заслуговує на увагу вашої команди.
Запитання 2: Хто буде створювати платформу?
Ідеї легкі – реалізація складна. Якщо ви не підійдете до цього питання самокритично, ідея буде запропонована командою, яка створює вашу платформу. Це може бути гіркою пігулкою, але давайте не забуватимемо: йдеться не про вас, ваших інженерів з платформ, вашого керівника з платформ або вашого ІТ-директора, а про ваших користувачів. Ви повинні сформувати команду платформи, яка найкраще задовольняє насамперед потреби ваших користувачів, а по-друге — ваші особисті амбіції.
Далі, як має виглядати команда платформи? У двох словах, ідеальна команда платформи має бути виділеною, невеликою та багатофункціональною. Краще мати трьох інженерів, які працюють повний робочий день над вашою новою платформою, ніж десять осіб, які працюватимуть над нею одночасно з безліччю інших повсякденних завдань. Так, для цього буде потрібний спеціальний персонал, а також сильний керівник, який захищатиме цю команду на ранніх стадіях розвитку. Саме так цифрові компанії організовують розробку своїх внутрішніх платформ, і ви повинні дотримуватись цих правил.
Створення платформи – це завдання з елементами вивчення, а не суто виконавське, тому швидкий зворотний зв’язок та спільне навчання мають першорядне значення для успіху команди. Вони досягнуть хорошого результату тільки в тому випадку, якщо будуть знаходитися в безпосередній близькості один від одного (фізично або віртуально) і їхня залежність від інших команд буде зведена до мінімуму. Ця безпосередня близькість також важлива для того, щоб уникнути пастки «не моя робота», в якій кожна людина погоджується лише на роботу, яка відповідає її досвіду чи профілю роботи. Загальне мислення «покажи мені, як» дозволяє команді за замовчуванням використовувати відповідного експерта в предметній галузі (SME), але передбачає, що кожен у команді здатний вирішити будь-яке технічне завдання.
Нарешті, чи є ймовірність, що вам знадобиться чиєсь благословення для використання певних послуг, наприклад, зелене світло від директора з інформаційної безпеки чи архітектора вашого підприємства? Якщо це так, зробіть їх (або одного з їхніх делегатів) основною частиною команди — принаймні доти, доки їхній внесок не буде вбудований у платформу у вигляді політики у вигляді коду та архітектурних креслень.
Питання 3: Як ви вимірюватимете успіх?
Ніхто не виграє від платформи, яка надається в рамках бюджету та вчасно, але не набула широкого поширення. Постарайтеся не ставити в основу ключові показники ефективності проекту. Натомість зверніть увагу на ключові показники ефективності продукту, які вимірюють корисність платформи, прийняття та задоволеність користувачів.
Немає єдино правильного способу виміряти успішний програмний продукт, але успішні відповіді на ці три питання демонструють прогрес:
- Скільки часу потрібно користувачеві, щоб досягти своєї мети? (менше = краще)
- Скільки користувачів використовують платформу та як часто? (Більше = краще)
- Наскільки задоволені користувачі та наскільки ймовірно, що вони порекомендують платформу іншим співробітникам?
У Google часто використовують H.E.A.R.T. Framework для багатьох споживчих продуктів. Також є модифікований фреймворк S.U.P.E.R. для деяких внутрішніх ІТ-платформ:
Підійдіть до них
Ми пояснили, чому безпосередня близькість до ваших внутрішніх користувачів має першорядне значення при створенні платформи, і показали, як ви можете частково відновити втрачену близькість, організувавши групи спостереження за користувачами. Ми також наголосили на важливості створення виділених, невеликих, крос-функціональних команд і як стимулювати їх до створення привабливої платформи, що полегшує роботу ваших співробітників, а не просто виконувати один ІТ-проект, перш ніж вони перейдуть до наступного.
Ми лише торкнулися того, що означає успішно планувати, створювати та запускати привабливу платформу як продукт. Можна було б сказати набагато більше про важливість персонажів користувачів, картування шляху користувача та справжню роль менеджера по продукту, і це лише деякі з областей.
Якщо ви витягнете з цієї статті лише одну річ, то нехай це буде те, що ви не знаєте, що потрібно і чого хочуть ваші користувачі. У вас є лише гіпотези, які вам ще належить довести чи спростувати. Те, що ви будуєте платформу не означає, що користувачі прийдуть. Ви маєте підійти до них.