PandaDoc R&D зсередини: Як ми працюємо? | Scrum Україна - тренінги, навчання та сертифікації Agile, Scrum, Large-Scale Scrum
 
Стаття відображається оригінальною мовою.

PandaDoc R&D зсередини: Як ми працюємо?

02 вер. 2022

Це розширений переклад статті Євгенія Лабунського — Head of Agile Practices в PandaDoc, керуючий партнер, тренер в Scrum Ukraine.
Оригінал статті "PandaDoc R&D from the Inside: How We Work" розміщений на сайті medium.com за цим посиланням.
Переклад: Кирило Сітніков

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

Команди

Команда — це мінімальний будівельний елемент, цеглина організації. У нас є три типи команд: Feature команди, Complex Subsystem та Functional команди.

Feature Команди

Переважна більшість (більш ніж 90%) наших команд є Feature командами (див. ілюстрацію 1), і це означає, що вони дотримуються наступних визначених правил:

  • Довговічні та стабільні, тобто команда сформована та не перебудовується;
  • У кожній команді 5-6 осіб;
  • Крос-функціональні — команда володіє всіма знаннями, які необхідні для виконання елементів - Product Backlog, тобто, з технічної точки зору може виконати як фронтенд частину так і бекенд частину задачі;
  • Deliver end-to-end customer value — команда має можливість виконати будь-який елемент - - - Product Backlog, не чекаючи, поки інша команда завершить свою роботу, або внести зміни в будь-яку систему чи компонент.

Feature_team_image
Ілюстрація 1. Feature команда.

Кожна Feature команда може створювати потенційно придатний для доставки інкремент самостійно або у співпраці з іншою командою (або кількома), якщо фіча достатньо велика.
Кожна Feature команда працює зі Scrum Master-ом та Engineering Manager-ом, кожний з яких, в свою чергу, працює з 2–3 командами.
Ми розвиваємо нові команди, навчаючи нових учасників існуючих команд, поки вони не стануть досвідченими. Після того, як нові учасники команди будуть достатньо навчені, ми формуємо нову команду.

Complex Subsystem Команда

Complex subsystem команда має досвід, щоб скоротити цикл розробки компонента, за який вони відповідають. Ця команда допомагає оптимізувати роботу шляхом рефакторингу або розділення складних компонентів.
У нашій системі є деякі компоненти, до яких важко внести зміни, якщо ви недостатньо знайомі з ними. Ця команда відповідає за те, щоб зробити внесок у розробку складного компонента якомога легшим способом (тобто за менший Cycle Time). Ця команда дотримується наступного правила:

Не можна писати бізнес-логіку в задачах. Тільки Feature команди мають право на написання бізнес-логіки в БУДЬ-ЯКОМУ компоненті.

Ця (Complex Subsystem) команда допомагає полегшити роботу іншим, виконуючи комплексний рефакторинг та розділення складних компонентів.

В нашій компанії тільки одна команда такого типу, на всю організацію.

Functional Команди

Це команди, які представляють та відповідають за групи функцій, як-от Security Team, Operations, QA Automation (розробка фреймворку автоматизації), тощо.

Track

Об’єднання з кількох команд в більшу організаційну структуру ми називаємо Track. Track — це будівельна одиниця організації, яка може масштабуватися, і яка зосереджена на певній клієнтській області або об’єднана навколо бізнес метрик.
Кожен Track має:

  • Product Goal, представлена через OKR-и, довгостроковим зобов’язанням.
  • Набір Команд, які працюють над досягненням Track Goal (Мети Track-у)
  • Track backlog, який є частиною беклогу компанії і успадковує його пріоритети

Track_image_PandaDoc

Ілюстрація 2. Track.

Всі Track-и дотримуються наступних правил:

  • Simplicity: не більше ніж 6–8 команд, щоб уникнути ментального перевантаження та зберегти концентрацію та фокус
  • Flexibility: спроможність працювати з усім технологічним стеком компанії та PandaDoc application
  • Self-sufficient: необхідного досвіду та знань достатньо для покриття пріоритетів
  • Ownership: повна відповідальність за якість (як технічну, так і продуктову) в межах їх сервісу
  • Customer-focused: збільшувати цінність для клієнтів і пріоритезувати беклог

Track є тимчасовим за своєю суттю. Це означає, що кожен Track може бути переформатований, закритий або оновлений в певний момент часу через те, що Продукт змінюється.

Оскільки фіча-команди можуть виконувати БУДЬ-ЯКУ роботу в БУДЬ-ЯКІЙ частині продукту, тому цілі Track-ів або кількість команд Track-у дуже легко змінюються.

Зараз у нас наступні Track-и:

  • Growth Track: допомагає стимулювати product-led growth, проводячи експерименти пов'язані із зростанням
  • Day-2-Day Трек: допомагає нашим користувачам орієнтуватися в продукті та використовувати його з максимальною ефективністю.
  • Document-as-an-App Трек: імплементують випадки використання, пов’язані з документами
  • Ecosystem Трек: допомагає іншим компаніям інтегруватися з PandaDoc
  • Revenu Solutions Трек: Демократизація продажів B2B, що дозволяє малому та середньому бізнесу мати ефективні доступні інструменти для росту і перемоги
  • Platform Трек: Дає командам набір інструментів, зменшує cycle time

Усі Треки, крім Platform Track, орієнтовані на зовнішніх клієнтів і мають ТІЛЬКИ фіча-команди. Platform Track містить Функціональні Команди всередині і не розробляє жодних бізнес фіч, а також жодна з Фіча-команд не залежать від Platform Track.

Модель роботи Track

В організації ми використовуємо LeSS Framework. Кожен Track використовує Scrum і дотримується основних гайдлайнів та правил LeSS.

LeSS_framework_image

Ілюстрація 3. Track-и в LeSS.

Усі спринти синхронізовані в організації для всіх Track-ів, що допомагає мати загальний ритм.

Track Leadership

Ми розробили Track-и такими, щоб вони були незалежними та самокерованими. Лідерство в кожному Track представление через:

  • Product Director який виконує роль Area Product Owner (APO), який пріоритезує backlog Track-у та вирішує як досягати його цілі. В нього\неї є Product Owner команда яка допомагає їй\йому виконувати щоденну роботу, яка зазвичай складається з 3-5 Product Manager-ів на один Track.
  • Engineering Director допомагає налагодити інженерно-технічні підходи в Track. Кожна трек має близько трьох Engineering Manager-ів, які працюють з командами та Треком, звітують Engineering Director.
  • Head of Design допомагає налаштувати загальні дизайн-гайди та процеси
  • Scrum Master-и допомагають реалізувати LeSS (Large Scale Scrum) і налаштувати робочий Inspect & Adapt процес, працюють як з командами так і з організацією.

Івенти Track-ів

Кожна команда Track працює в Scrum, але в масштабований спосіб (події з кількома командами). Ось один приклад того, як ми виконуємо Sprint Review.

Sprint Review єдиний івент який проводиться за участі всіх Track-ів. Всі інші Scrum івенти ми проводимо на рівні одного Track-у.

Масштабування та організація R&D.

Головна одиниця Масштабування в Компанії це Track. Новий Track компонується після визначення бізнес потреб та потрібних ресурсів. Ми запускаємо новий Track, коли в новій області потрібно залучення принаймні 3-х команд.

Поточна структура організації відповідає LeSS Huge guidelines виглядає як на малюнку знизу:

LeSS_Huge_guidelines_image

Ілюстрація 4. Організаційна структура LeSS Huge guidelines.

Кожен Track має Area Backlog. Але кожен Area Backlog успадковує упорядкування (пріоритет - прим. перекладача) з Product Backlog який контролюється одним Product Owner-ом (у нашому випадку цю роль виконує CTO). Це дає нам можливість:

  • Переміщати команди між Track-ами, якщо ми бачимо, що глобальні пріоритети та поточний розподіл команд за Track-ами не збалансовані (наприклад, один з Track-ів потребує більше команд, оскільки їхні елементи Backlog-у тепер мають вищі пріоритети, ніж інші)
  • Змінювати Track-и, за необхідності, а також створювати нові Track-и чи закривати попередні (так, ми дійсно їх закриваємо)

Наша структура дуже гнучка, оскільки ми оптимізуємо наступні System Goals:

  1. У будь-який момент часу працюємо над більш цінними елементами Backlog-у, це означає, що ми уникаємо локальної оптимізації
  2. Адаптивність найвищого рівня: можливість змінювати плани на льоту на всю організацію

Що далі?

Більше експериментів та покращень :) здебільшого в:

  1. Технічна досконалість (Technical Excellence)  —  оскільки будь-яка команда працює з будь-якою частиною продукту, нам потрібно бути кращими, використовуючи кращі девелопмент практики
  2. Декомпозиція ініціатив (Initiatives decomposition)  —  спроможність отримувати краще з мінімуму :) Більше інформації в наступних статтях!

Тим часом подивіться:
"Як ми почали нашу подорож з Large Scaled Scrum"

"Останні експерименти, які ми проводимо в організації"

Детальніше про структуру та способи роботи

Рекомендовані заходи

тренінг
Олексій Кривицький  

Цей сертифікований онлайн-курс розкриє перед вам мир масштабної продуктової розробки на 5, 10 або 11...

тренінг
Олексій Кривицький  

Це офіційний інтенсивний сертифікаційний клас Scrum Alliance. Курс читає Олексій Кривицький – Certified Scrum Trainer, розробник, скрам-майстер та практикуючий agile-коуч з 2008 року.

тренінг
Олексій Кривицький  

Це офіційний інтенсивний сертифікаційний клас Scrum Alliance. Курс читає Олексій Кривицький – Certified Scrum Trainer, розробник, скрам-майстер та практикуючий agile-коуч з 2008 року.

Рекомендовані статті

Загальна поведінка та морфологія системи

Це переклад матеріалу "General System Behavior and Morphology", оригінал якого розміщений за цим посиланням.

1. Якщо щось може піти не так, це станеться.

Це вічне як «закон Мерфі», досить суворе спостереження насправді є узагальненою версією коментаря, зробленого капітаном ЗПС США Едом …

Ми активні в соціальних мережах і хочемо спілкуватися. Додавайтеся на нашу сторінку в facebook та приєднуйтесь до наших спільнот.

З приводу тренінгів, реєстрацій, рахунків:
+380993383636
@scrum_ukraine
hello@scrum.ua

Із питань корпоративних програм:
+380993383636
hello@scrum.ua

©2017 - 2024 Scrum Ukraine. Всі права захищені.

Політика конфіденційності