Проектування системної команди

Моделі та уроки навчилися масштабувати команду для підприємства

Більшість організацій розуміють системи та чому вони важливі. Однак скільки це коштує? Яка команда нам потрібна?

Системна команда обслуговує команди (або подібні)

Чудова книга Пітера Мерхолца та Крістен Скіннер Org Design for Design Orgs описує моделі та ролі в складі дизайнерських команд та оргів. У розділі "Ролі та склад команди" вони описують відповідну дослідницьку групу, яка працює у багатьох інших колективах:

"Зараз дослідники UX мають критичну масу, щоб бути власною командою ... [з] керівником досліджень ... підтримуючи професійний ріст дослідників та підтримуючи глобальне розуміння дослідницької інформації про всі товари та послуги компанії."

Читаючи це, я думав собі: «Так, як команди дизайнерських систем», вирішуючи широкі, простіші проблеми дизайну - візуальну мову, зручні компоненти інтерфейсу тощо.

Маючи на увазі цю модель, я був здивований, коли почув, що Пітер роздумував над (Spotify's) командою систем у листопаді минулого листопада в UI21 як на те, що довелося "зламати патч, організаційний патч на [модель] [s]", який він описав. Можливо, я нерозумію. Але я протягом багатьох років працював над ~ 15–20 системними командами, які обслуговували багато команд аналогічно (але не такому ж, як) подібні дослідницькі практики.

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

Хто в цій команді? Вони повний або неповний робочий день? Які дисципліни слід представляти? З якої команди ми їх отримуємо?

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

Етапи зростання команд систем

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

Етап №1: Запасні таймери

Люди, які працюють на робочих місцях, часто описують, як їх пристрасний вибух насправді не знявся:

"Я сам по собі Я створив {аркуш наклейок Sketch або комплект міні-Bootstrap} у свій додатковий час, але ніхто більше не використовує його. Як зробити наступний крок? "

Системи, побудовані в п'ятницю вдень або в неділю вночі, не витримують. Шаблон стартового ескізу або код стартера краще, ніж нічого. Однак спартанські зусилля не є практикою підприємства у створенні.

Винос: Не омикай! Багато системних подорожей починається так. Доведіть, що ваші інструменти призводять до результатів - послідовності, ефективності та повторного використання - у пілотних проектах. Це трамплін для того, щоб навчити, як зусилля системи приносять користь іншим.

Етап 2: Виділені фізичні особи

Як визнається системна цінність, менеджер вирішує передбачуване, але обмежене виділення (10%? 25%) індивіда з прихильності колективу продуктів та оприлюднює системну відповідальність перед командами та однолітками. Наділений повноваженнями та часом, ви починаєте регулярно випускати відчутні результати, будь то стандартизовані дизайнерські активи чи кодований комплект.

У цей момент прихильники систем, що однодумці, можуть почати координувати роботу в галузі дизайну та інженерії. Хтось може почати відставання, але він може загнивати, коли місяці нечітко визначені, які відпочивають місяцями. Напівзапечена документація спливає на неполірованих веб-сторінках або (о, ні!) Злиття. Оновлення трапляються, але мало хто знає, коли, як чи чому.

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

"Якщо ви добре в цьому зробите, ви створюєте попит у вашій організації, який не може відповідати поточним асигнуванням". - Джаред Спул, поза межами UX Tipping Point

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

Етап 3: Команда системи - як – продукт

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

Склад командної групи високого рівня, за розміром

Команди, які я нещодавно формував та очолювали, складаються як суміш:

  • ОБОВ'ЯЗКОВО: учасники дизайну можуть охоплювати піддисципліни - візуальність, взаємодія, архітектура інформації, щоб назвати їх декілька, - але команда повинна мати найкращий досвід у створенні елегантної візуальної мови.
  • ОБОВ'ЯЗКОВО: інженерія приносить основний фокус зі знаннями HTML та CSS, досвідченими навичками створення конвенцій та створення інструментів.
  • ПОТРІБНО: ВИКОРИСТОВУВАННЯ продукту та лідерства для встановлення бачення, спрямування руху, розроблення дорожніх карт, моніторингу прийняття та організації відставання, скандалів та критики.
  • МОЖЕ БУТИ: Спеціальність стосується таких, як стратегія контенту, доступність, продуктивність, SEO та інше. Незважаючи на цінність, майте на увазі, що системи в першу чергу одружуються на дизайні та техніці.
  • НАЗАГАЛЬНО НЕ МАЙТЕ: QA та дослідження. Фінансування якості забезпечення часто недостатнє, і системні команди в будь-якому випадку можуть встановити практику для оцінки якості. Дослідження можуть існувати як послуга побратимів для команд продуктів.

Етап 4: Системна група команд

Деякі масивні підприємства (як, я підозрюю, Google, IBM, GE, Cisco або Microsoft) посилюють системні зусилля, щоб охопити парасольку декількох взаємопов'язаних команд для досягнення системних цілей.

Команда команд

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

Приклади системної команди

Хоча я беру участь у командах дизайнерських систем безперервно з 2006 року, практика значно зменшилась приблизно в 2012 році, коли сталося чуйне реагування, HTML і CSS зміцнилися, і єдинороги почали (частково) систематично розробляти коди.

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

Приклад 1: Електронна комерція реагує на ефективність

Що добре працювало: Ця спеціальна команда розробила та задокументувала багато стандартів у спеціалізованому досвіді на веб-основі. Це була система "великої кахуни": стиль, взаємодія, компоненти, моделі, бренд, редакція, SEO, доступність, роботи! Оскільки на підприємстві знадобилося ~ 2 роки, щоб "реагувати на реагування", система мала вирішальне значення для зближення розрізненої подорожі клієнтів.

Що я робив по-різному: Зітхання, інженерія. Наша команда системи побудувала надійну бібліотеку компонентів для моделювання зразкових конструкцій та створення стандартного сайту. Але інженерні ведучі протистояли нашому коду і ніколи не будували бібліотеку для своєї громади. Результат? Дублюючі зусилля, неефективність та невідповідність, за винятком того, як розробники підкрадають наш код до своїх складових.

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

Приклад 2: Мова дизайну для вибухового органу

Що добре спрацювало: використовуючи повітряні кулі від ~ 30 до 200+ дизайнерів за 12–18 місяців, команда системи очолила розробку спільної мови дизайну, задокументованої на користувальницькому сайті стандартів (таким чином, розробник інтерфейсу). Враховуючи масштабний, розподілений масштаб дизайнерських організацій, ми використовували об'єднаних дизайнерів для керування основою взаємодії, UX та значків.

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

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

І, знову ж таки: код. Ми повинні були випустити комплект і пізніше попросити пробачення.

Приклад 3: Безпосередня бібліотека веб-сайтів

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

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

Приклад 4: Екосистема цифрових продуктів

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

Ми випустили бібліотеку v1.0 за три місяці і слідували щоквартальними циклами, щоб удосконалити інструментарій та розширити каталог бібліотеки. Під час проектування, інженерії та виробів, які були скликані на планування на 2017 рік, VP Engineering привітала систему:

«Найголовніше, що ми зробили минулого року, - це побудова цієї системи. Це основа всієї нашої майбутньої роботи ».

Приклад 5: Бібліотека з конкурентами

Що добре працювало досі: Поки ми почали оптимізувати та розширювати існуючу основну бібліотеку, додаткові бібліотеки з’явилися в інших сферах діяльності. Команди були розгублені: що прийняти? Замість того, щоб змагатися, ми координували зусилля та інтегрувались у більшу, єдину команду.

Було короткочасне перетягнення на повторну команду та код рефактора, щоб гнучко обслуговувати всіх. Скандали та планування також стали довші. Однак наш шлях вперед виробить разом в осяжному майбутньому, і генеральний директор та ще один віце-прем'єр-міністр здаються впевненими:

«Я відчував і визнав, що у нас є дві бібліотеки, але потім з’явилася третя. Я радий бачити, що ми знайшли спосіб зробити лише один ».

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

Навчені уроки управління командними системами

№1. Зашифрований дизайн - це правда. Дизайн та інженерія сумішей

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

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

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

№2. Ємність на півтора разу - це міцність, а не слабкість

Помічаєте схему в кожній команді вище? Усі співробітники працюють на півтора робочого часу, інакше залишаються відданими продукту. Для команди середнього розміру такі зобов'язання створюють зв'язки між 3–5 ключовими командами продуктів. Це дозволяє зрозуміти, які важливі продукти потребують, і мінімізує упередженість щодо будь-якого окремого продукту.

Дизайнери та інженери, котрі скликаються як системні команди, але все ж розподілені для розрізнення продуктів

Це пов'язано з ризиками:

  • Продукти лідирують, поступаючись потужності системи за півтора разу, але все ж призначають і очікують 32 і більше годин на тиждень для свого продукту.
  • Учасники команди, що розгалужують численні суперечливі ритуали (скрут, планування, критика), які спотворюють пропорції зустрічей у порівнянні з "завершенням роботи".

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

№3. Врівноважуйте безперервність з обертанням

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

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

№4. Передбачте періодичне скорочення як можливість

Деякі співробітники системи зазвичай переходять до роботи на повний робочий день після значного випуску системи. Все добре.

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

№5. На борту нових членів як лакмусовий тест якості системи

Інтеграція нового члена команди - це чудовий (і простий) тест чіткості дизайну вашої системи, якості коду та дотримання системних обіцянок.

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

№6. Персонал системи повинен охоплювати округи

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

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

27 квітня 2017: Діаграми статті були оновлені, щоб видалити гендерну специфіку у відповідь на коментар читача.