Представлення «20% часу» на робочому місці [закрито]

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

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

Я неодноразово намагався ввести якусь форму 20% / Skunk, працюючи у мого попереднього роботодавця, не маючи успіху.

Як я можу краще виправдати це керівництву? Який "правильний" спосіб підійти до подібної роботи?

Основна причина в 20% часу - це збереження використання потужностей на 80%, а не на 100%.

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

ТЕОРІЯ

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

Математично схильні можуть запитати про цю "випадковість": має бути деякий розподіл ймовірностей, тож яким буде розмір черги в середньому? Математика (теорія черги) має відповідь на це: якщо і процес приходу, і обслуговування - Марков, то N = rho ^ 2 / (1-rho).

(Де rho - коефіцієнт використання, рівний співвідношенню тарифів обслуговування та прибуття. Якщо процеси не маркові, математика є складнішою, але висновки не змінюють.)

Якщо побудувати цю функцію, ви зможете побачити, що середня довжина черги залишається низькою, а коефіцієнт використання до 0,8 , а потім різко піднімається і йде до нескінченності. Ви можете зрозуміти це інтуїтивно, подумавши про процесор комп'ютера: коли його використання наближається до 100%, комп'ютер стає невідповідним.

ПРАКТИКА

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

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

Одразу випливає кілька практичних висновків:

• якщо ви розглядаєте 20% часу і займаєтесь обліку витрат (час розробників коштує X, але / і компанія може / не може собі цього дозволити), ви робите це неправильно.
• якщо ви виділяєте 20% на п'ятницю щотижня, ви робите це неправильно
• якщо ви налаштовуєте систему подання / перегляду / затвердження пропозицій на 20%, ви робите це неправильно
• якщо ви заповнюєте часові таблиці, ви робите це неправильно
• якщо ви використовуєте інновацію як мотиватор протягом 20% часу, ви робите це неправильно. Хоча нові продукти вийшли з 20% проектів, вони не полягали в цьому. Якщо ваша компанія не може впроваджувати інновації протягом основних годин, це проблема!
• 20% часу - це не про творчість. Не кажіть, що ви розкриєте свою творчість за 20% часу, запитайте, чому ви недостатньо креативні вже протягом основних годин.

ВІДПОВІДИ НА ЗАПИТАННЯ В КОМЕНТАРІ

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

Кім , це все одно частково культурна річ. Найближчим культурним орієнтиром, про який я можу придумати, є синергетичний рівень так званої Маршаллової моделі організаційних змін. Він з'являється в кінці успішних художніх перетворень або присутній в організаціях, побудованих спершу з самого початку. ( Ось посилання на білу книгу Боба Маршалла (PDF) .)

ЛІТЕРАТУРА

Вищенаведена логіка добре підтримується в технічній літературі з програмного забезпечення. Мері та Том Поппендієк натякнули на це у своїй книзі 2006 року «Впровадження розробки програмного забезпечення» . Дональд Рейнерцен у своїй книзі 2009 року "Принципи потоку розвитку продукту" (Глава 3) детально розглядає цю тему за допомогою формул та графіків.

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

Я не працював у місці, де такі роботи були офіційно визнані. Але з моїх розмов і спроб дізнатися про цю практику я виявив це - ну, переважно, те, що "20% часу" не:

• це справді культура, а не політика
• це не може бути ухвалено вищим керівництвом
• він не може бути заснований комітетом розробників
• це не 32 години на це і 8 годин на це

" Skunkworks " - це не 20% часу. 20% часу - це, як ви сказали, - час розробник самостійно обирає, над чим працювати. Skunkworks зовсім інша. Проект скунктури - це вагомий, дорогоцінний проект, над яким працювала команда (часто це команда гуру), про яку не повідомляється керівництвом, і команда самостійно вирішує, як проект повинен тривати без керівництва . Ці проекти часто мотивовані тактичною або діловою потребою, щоб щось зробити, але в бюджеті немає місця для цього. Якщо щось доводиться робити , це робиться - бюджети будуть прокляті.

Я керував командою розвитку, де впроваджував 20% часу. Або намагався, все одно. Я мав схвалення начальства, тож це не було проблемою. Проблема полягала в тому, що команда була занадто маленькою і занадто спеціалізованою. Кожного разу, коли виникали проблеми, які потребували негайного втручання, 20% часу піддавалися. Це в результаті траплялося дуже часто.

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

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

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

Я приєднався до стартапу, коли він був сформований, і майже рік я був єдиним розробником. Я витратив свої 20% на пару речей:

• Повідомлення / виправлення помилок у випадкових проектах з відкритим кодом - це може бути настільки мало, як розписувати цікавий проект на Github та виправити кілька помилок у документах.
• Писати "речі" з відкритим кодом - такі речі, як проблеми з програмуванням, просто заради задоволення.
• Ходити на конференції та спринти - кожні кілька місяців я б поїхав у спринт, де я можу працювати над проектами (деякі з яких можуть використовуватися основним додатком, інші - ні) та набути певного досвіду. Є кілька бібліотек, які використовуються нашим додатком та програмами, розробленими іншими компаніями, які надсилають розробників на конференції, тому це може розглядатися як пряма вигода для нашої компанії.
• Вивчення нових технологій - саме так я навчився Go , навіть якщо ми не використовуємо їх у компанії. Це особливо заохочує мого роботодавця. Останнім часом я слідкую за деякими безкоштовними он-лайн класами в Стенфорді.

Час не вимірюється точно, це точно не 32 + 8 годин, іноді потрібно терміново робити, коли просто не вистачає часу, щоб відрізати ці 20%, в інших випадках у мене є більше часу.

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

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

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