Лідерство практики: основи від Canonical

Ця стаття є першою в серії матеріалів про інженерне лідерство в Canonical.

Я працюю в Canonical і маю три посади, що є трохи незвично і може здаватися надмірним.

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

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

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

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

Мені доводиться пояснювати це, бо люди часто запитують: «Що таке лідер практики?»

Інженерні практики

Я приєднався до Canonical, щоб перетворити всі аспекти її документації: вихідні дані та зусилля, до яких вона прагне, що вважає хорошим, як це реалізується, як організація думає про мету та цінність документації.

Це було цікаве завдання відразу. Я був один, а 650 людей повинні були стати активними учасниками мого проекту (650 осіб у 2021 році; до 2024 року Canonical збільшилася вдвічі).

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

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

У моєму випадку не було інженерної команди, яку потрібно було вести – моя команда по суті охоплювала всю компанію. І я не зосереджувався на жодному конкретному продукті. Кожен буде під впливом моїх планів, і кожен мав іти зі мною.

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

Прецеденти

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

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

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

Так само і практика продуктивності, яка не може бути успішно дописана до роботи, що не врахувала її з самого початку.

Отже, існує принаймні прецедент для ідеї інженерної практики, не пов’язаної з жодним конкретним продуктом, яка повинна утвердитися в інженерній організації – і яку кожен повинен прийняти як свою проблему.

Елементи практики

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

Однак найважливішим імперативом у встановленні практики є визначення її цінності.

У Canonical документацію потрібно було прийняти як первинну інженерну дисципліну. Цінності документації повинні були бути сприйняті інженерними командами, embraced як свої. Це повинно було стати так само неможливим відмовитися від ідеї документації, як і від ідеї безпеки або продуктивності.

Коли я кажу «воно потрібно було» я маю на увазі «мені це потрібно було» – мій проект не мав шансів на успіх, якщо це не станеться.

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

Через чотири роки

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

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

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

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

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

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

Модель лідерства практики була розроблена і прийнята для інших сфер. Нещодавно Canonical найняв нового голову спільноти, Себастьяна Тржинського-Клемента, для здійснення аналогічної трансформації в практиці спільноти в інженерії (для Canonical, компанії з відкритим кодом, практика спільноти в інженерії має таку ж вагу, як практика безпеки, продуктивності чи документації). І звичайно, у Себастьяна також є кілька титулів: він також є лідером практики – у спільноті – і йому також потрібно зробити роботу з визначення цієї конкретної практики та нашого підходу до інженерної практики загалом.

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

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

Посібник з лідерства практики Canonical

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

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

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

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

Посібник з лідерства практики Canonical

Зв’яжіться з нами сьогодні

Вас цікавить впровадження Ubuntu у вашій організації?

Підписка на розсилку

Отримуйте останні новини та оновлення Ubuntu на електронну пошту.

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