Memperkenalkan "20% waktu" di tempat kerja [ditutup]

30

20% waktu itu adalah budaya majikan yang memungkinkan karyawannya menghabiskan 20% dari waktu mereka mengerjakan proyek yang menurut mereka menarik - mungkin menciptakan aplikasi baru, atau meningkatkan proses yang ada, dll. Beberapa orang mungkin tahu ini sebagai skunk berfungsi, namun istilah itu mungkin tidak berarti apa-apa (atau sesuatu yang sama sekali berbeda) bagi Anda.

Ada banyak kasus terdokumentasi dari produk-produk hebat yang lahir dari 20% / pekerjaan sigung di sebuah perusahaan. Sepertinya situasi menang / menang; perusahaan berpotensi mendapatkan produk atau aplikasi baru yang hebat, dan pengembang memiliki kesempatan untuk melenturkan otot kreatif dan berinovasi.

Saya mencoba beberapa kali untuk memperkenalkan beberapa bentuk 20% / Skunk yang bekerja di perusahaan saya sebelumnya tanpa hasil.

Bagaimana saya bisa membenarkannya kepada manajemen? Apa cara "benar" untuk mendekati pengaturan kerja semacam ini?

development-environment

— dannywartnaby
sumber

11

Pekerjaan sigung? Apakah ini tempat semua orang merokok ganja yang kuat dan menulis kode funky yang sebenarnya?

— Dan Diplo

@Dan theregister.co.uk/1999/10/27/what_the_hell ;) Ini adalah istilah yang digunakan untuk menggambarkan "pekerjaan yang tidak direncanakan, diprakarsai pengembang" di sebuah perusahaan. Biasanya paruh waktu. Beberapa perusahaan mengizinkan staf mereka untuk menghabiskan sebagian waktu mereka mengerjakan apa pun yang mereka suka - kadang-kadang pekerjaan itu berubah menjadi pekerjaan yang bisa digunakan perusahaan, atau produk untuk dirilis.

— dannywartnaby

2

@danny Itu sama sekali tidak bagaimana saya memahami istilah: Anda menggambarkan Google "20% waktu". Saya agak ragu bahwa Lockheed's Skunk Works melakukan sesuatu yang tidak direncanakan. Alih-alih, ini adalah "sebuah kelompok di dalam organisasi yang diberi otonomi tingkat tinggi dan tidak dihadang oleh birokrasi, bertugas mengerjakan proyek-proyek lanjutan atau rahasia". (Kutipan dari halaman WP's Skunk Works)

— Frank Shearar

1

@SteveBennett: Kebalikan logis ekstrim dari waktu 20% adalah pemanfaatan 100%, bekerja di silo fungsional, spesialisasi tingkat tinggi, memperhitungkan waktu yang dihabiskan di setiap fungsi, dan banyak, banyak, dan banyak pemborosan.

— azheglov

1

Ini lebih merupakan pertanyaan untuk Workplace, tetapi sudah ditanyakan di sana - workplace.stackexchange.com/questions/468/…

— ChrisF

45

Alasan utama untuk waktu 20% adalah untuk menjaga pemanfaatan kapasitas pada 80% daripada pada 100%.

Anda dapat menganggap organisasi pengembangan perangkat lunak sebagai sistem yang mengubah permintaan fitur menjadi fitur yang dikembangkan. Anda dapat memodelkan perilakunya menggunakan teori antrian .

TEORI

Jika permintaan datang lebih cepat daripada yang dapat diservis sistem, permintaan itu akan masuk. Ketika kedatangan lebih lambat, ukuran antrian menurun. Karena proses kedatangan dan layanan acak, ukuran antrian berubah secara acak seiring waktu.

Secara matematis cenderung dapat bertanya tentang "keacakan" ini: harus ada distribusi probabilitas, jadi apa ukuran antrian rata-rata? Matematika (teori antrian) memiliki jawaban untuk itu: jika proses kedatangan dan layanan adalah Markov, maka N = rho ^ 2 / (1-rho).

(Di mana rho adalah koefisien pemanfaatan sama dengan rasio tingkat layanan dan kedatangan. Jika prosesnya non-Markov, matematika lebih rumit, tetapi tidak mengubah kesimpulan.)

Jika Anda memplot fungsi ini, Anda dapat melihat bahwa panjang antrian rata-rata tetap rendah sementara pemanfaatannya mencapai 0,8 , kemudian naik tajam dan pergi ke tak terhingga. Anda dapat memahami ini secara intuitif dengan memikirkan CPU komputer Anda: ketika pemanfaatannya mendekati 100%, komputer menjadi tidak responsif.

PRAKTEK

Ekonomi pengembangan perangkat lunak sedemikian rupa sehingga perusahaan perangkat lunak mengeluarkan biaya besar ketika antrian mereka berada dalam status antrian tinggi. Ini termasuk peluang pasar yang terlewatkan, produk usang, proyek yang terlambat, dan pemborosan yang disebabkan oleh fitur bangunan untuk mengantisipasi permintaan.

Dengan demikian, waktu 20% adalah jawaban ilmiah untuk masalah mengoptimalkan hasil ekonomi: hindari status antrian tinggi dengan menghindari rasio pemanfaatan yang menyebabkannya. Ini pada dasarnya adalah kelonggaran yang membuat sistem responsif.

Beberapa kesimpulan praktis segera menyusul:

jika Anda mempertimbangkan 20% waktu dan melakukan akuntansi biaya (biaya waktu pengembang X, tetapi / dan perusahaan dapat / tidak mampu membelinya), Anda salah melakukannya.
jika Anda mengalokasikan 20% untuk hari Jumat setiap minggu, Anda salah melakukannya
jika Anda menyiapkan sistem pengajuan / peninjauan / persetujuan proposal proyek 20%, Anda salah melakukannya
jika Anda mengisi lembar waktu, Anda salah melakukannya
jika Anda menggunakan inovasi sebagai motivator selama 20%, Anda salah melakukannya. Sementara produk baru telah keluar dari proyek 20%, mereka bukan itu intinya. Jika perusahaan Anda tidak dapat berinovasi selama jam-jam intinya, itu masalah!
20% waktu bukan tentang kreativitas. Jangan katakan Anda akan melepaskan kreativitas Anda dengan 20% waktu, tanyakan mengapa Anda belum cukup kreatif selama jam-jam inti Anda.

JAWABAN UNTUK PERTANYAAN DALAM KOMENTAR

Dan , Anda benar dan menggambarkan kesalahan yang dibuat oleh banyak orang secara akurat. Anda tidak dapat memilih persentase pemanfaatan Anda, karena ini merupakan variabel keluaran. Ini adalah rasio karakteristik dari dua proses, jadi ini adalah apa adanya karena prosesnya adalah sebagaimana adanya. Organisasi memang memiliki pengaruh terhadap kedua proses; mencocokkan kemampuan dan permintaan adalah salah satu masalah sulit yang dihadapi oleh badan pengembangan perangkat lunak lean of knowledge. Pemanfaatan adalah salah satu indikator seberapa baik masalah ini diselesaikan dalam suatu organisasi. Slack muncul saat inisiatif lean Anda berkembang dan Anda membuang limbah dari value stream. Tetapi jika Anda mengamanatkan 20% waktu, Anda berakhir dalam perangkap pemanfaatan yang sama dengan kapasitas yang tersedia lebih sedikit.

Kim , itu masih sebagian hal budaya. Referensi budaya terdekat yang dapat saya pikirkan adalah tingkat sinergis dari apa yang disebut model perubahan organisasi Marshall . Ini muncul pada akhir transformasi lean yang sukses atau hadir dalam organisasi yang dibangun lean sejak awal. ( Berikut tautan ke kertas putih Bob Marshall (PDF) .)

REFERENSI

Logika di atas didukung dengan baik dalam literatur rekayasa perangkat lunak. Mary dan Tom Poppendieck mengisyaratkan hal itu dalam buku mereka 2006 Implementing Lean Software Development . Donald Reinertsen dalam bukunya 2009 Principles of Product Development Flow (Bab 3) memberikan pengobatan selama ini untuk subjek ini, dengan formula dan grafik.

— azheglov
sumber

Woah, jawaban yang bagus. Saya tidak pernah menganggap itu - selalu memandangnya sebagai hal budaya. +1

— Kim Burgess

SANGAT menarik ... Satu hal yang saya tidak grok, meskipun: Mengapa antrian tetap kecil hingga 80% adalah karena ada kapasitas gratis hingga saat itu. Jika 20% dari kapasitas Anda diamanatkan untuk diisi dengan barang-barang non-antrian, maka Anda baru saja menyusutkan kapasitas Anda menjadi 80%, dan 80% adalah 100% baru Anda. Kanan?

— Dan Ray

@ KimBurgess: Saya menambahkan komentar pada komentar Anda pada Tanya Jawab di akhir jawaban.

— azheglov

@DanRay: Anda benar! Saya menambahkan T&J di akhir jawaban.

— azheglov

3

Kuharap aku bisa menang sepuluh kali.

— Daniel Daranas

12

Empat belas bulan setelah saya menulis jawaban ini, saya menghasilkan jawaban yang jauh lebih baik .

Saya belum pernah bekerja di tempat di mana karya-karya seperti itu diakui secara resmi. Tetapi dari percakapan dan upaya saya untuk mempelajari praktik ini, saya menemukan ini - yah, sebagian besar bukan "20% waktu":

memang budaya dan bukan kebijakan
tidak dapat ditentukan oleh manajemen senior
itu tidak bisa dilembagakan oleh komite pengembang
ini bukan 32 jam untuk ini dan 8 jam untuk itu

— azheglov
sumber

Terimakasih atas tanggapan Anda. Saya kira itu harus menjadi budaya - Anda tidak dapat memaksa staf untuk menciptakan sesuatu. Juga setuju bahwa itu tidak dapat dilembagakan oleh komite pengembang - pengalaman saya tentu sejalan dengan itu, jadi saya kira pertanyaannya menjadi dari mana budaya ini berasal? Atlassian menguji coba ini, jadi itu pasti keputusan manajemen. Apakah Anda pikir ini sesuatu yang hanya bisa berfungsi jika itu adalah jantung dari budaya perusahaan sejak awal?

— dannywartnaby

Dalam kasus Atlassian, keputusan memang datang dari atas, tapi saya kira mereka memiliki karyawan yang tepat, pengembang yang siap untuk itu. Namun, posting blog ini: blogs.atlassian.com/developer/2009/02/... melaporkan beberapa masalah dengan penerapannya dan meskipun mereka mengatakan akan melanjutkan percobaan, mereka belum memperbarui publik di lebih dari satu satu setengah tahun. Saya tetap disini.

— azheglov

6

" Skunkworks " tidak sama dengan 20% waktu. 20% waktu seperti yang Anda katakan - waktu pengembang memilih sendiri apa yang harus dikerjakan. Skunkworks sangat berbeda. Proyek skunkworks adalah proyek bernilai tinggi, berbiaya tinggi yang dikerjakan oleh tim (sering kali merupakan tim sempalan guru) yang tidak dilaporkan ke manajemen atas, dan tim memutuskan sendiri bagaimana proyek harus dilanjutkan tanpa arahan manajemen . Proyek-proyek ini sering dimotivasi oleh kebutuhan taktis atau bisnis untuk menyelesaikan sesuatu, tetapi tidak ada ruang dalam anggaran untuk itu. Jika sesuatu harus dilakukan , itu akan dilakukan - anggaran terkutuk.

Saya mengelola tim pengembangan tempat saya menerapkan waktu 20%. Atau tetap mencoba. Saya mendapat persetujuan dari atasan saya, jadi itu bukan masalah. Masalahnya adalah tim itu terlalu kecil dan terlalu terspesialisasi. Setiap kali muncul masalah yang membutuhkan intervensi segera, waktu 20% terbentur. Ini akhirnya sering terjadi.

Saya juga menemukan bahwa beberapa pengembang saya menemukan kurangnya arah yang mengganggu saya. Meskipun saya mengatakan "kerjakan apa pun yang Anda inginkan, asalkan terkait dengan pemrograman," mereka masih kesulitan menerima bagian "apa pun". Mereka berpikir bahwa beberapa proyek akan lebih baik daripada yang lain, sehingga mereka mau tidak mau bekerja pada permintaan implementasi tingkat rendah dalam produk utama, hal-hal seperti itu. Saya ingin mereka tumbuh dan berkembang, tetapi sebaliknya mereka menggali lebih dalam keahlian utama mereka.

Saya akan melakukannya lagi, tetapi saya akan secara tegas melarang bekerja pada produk utama dan saya mungkin memulainya dengan beberapa ide untuk dipilih.

— John Dibling
sumber

1

Mengapa menjadi masalah bahwa mereka menggali lebih dalam keahlian utama mereka? Sepertinya mereka senang menerapkan hal-hal yang (mungkin) perlu dilakukan, tetapi tidak. Tidak semua orang akan bersemangat untuk mencoba hal-hal baru dan inovatif sepanjang waktu, dan saya pikir itu akan menjadi kesalahan untuk memaksakan sikap itu.

— Matt Olenik

Saya tidak akan mengatakan itu masalah , tepatnya. Saya hanya berpikir mereka bekerja pada produk karena mereka enggan memilih sesuatu yang terlarang. Ini sebagian karena saya tidak cukup menjelaskan bahwa domain masalah yang memenuhi syarat adalah segalanya.

— John Dibling

Jawaban John sangat berguna, terima kasih. Sangat menarik bahwa Anda menemukan bahwa kurangnya arahan dan kebebasan relatif untuk menemukan pekerjaan adalah faktor penyebab 20% waktu tidak bekerja untuk beberapa pengembang, karena itu adalah inti dari konsep. Saya kira beberapa pengembang hanya perlu diberi target yang jelas untuk mendapatkan yang terbaik dari mereka. Saya kira budayanya bisa "menghabiskan 20% dari waktu Anda untuk menciptakan sesuatu, tetapi jika Anda tidak bisa, tidak apa-apa, mungkin gunakan waktu untuk membuat sesuatu yang lebih baik - itu tidak harus menjadi proyek Anda saat ini" ..?.

— dannywartnaby

Itu aneh, saya pertama kali menemukan istilah "karya sigung" dalam sebuah buku yang menggambarkan proyek bernilai tinggi tetapi murah yang dimulai sebagai proyek hewan peliharaan rahasia untuk satu pengembang dan kemudian berubah untuk mengubah arah organisasi sepenuhnya.

— Spoike

4

Saya bekerja untuk perusahaan baru yang telah menerapkan kebijakan 20%. Ini adalah majikan pertama saya yang melakukan ini, dan ketika dia membahasnya di wawancara kerja, saya benar-benar terkejut, karena sebagian besar pengusaha lain berusaha untuk tidak "menyia-nyiakan" satu jam pun.

Saya bergabung dengan start-up ketika dibentuk, dan selama hampir satu tahun saya adalah satu-satunya pengembang. Saya menghabiskan 20% pada dasarnya dengan beberapa hal:

Melaporkan / memperbaiki bug dalam proyek sumber terbuka acak - ini bisa sekecil mencari proyek yang menarik di Github & memperbaiki beberapa kesalahan ketik dalam dokumen.
Menulis "hal" open-source - hal-hal seperti tantangan pemrograman, hanya untuk bersenang-senang.
Pergi ke konferensi dan sprint - setiap beberapa ngengat saya akan pergi ke sprint di mana saya dapat mengerjakan proyek (beberapa di antaranya mungkin digunakan oleh aplikasi utama, yang lain tidak) dan mendapatkan pengalaman. Ada beberapa perpustakaan yang digunakan oleh aplikasi kami dan oleh aplikasi yang dikembangkan oleh perusahaan lain yang mengirim pengembang ke konferensi, sehingga dapat dilihat sebagai manfaat langsung bagi perusahaan kami.
Mempelajari teknologi baru - ini adalah cara saya belajar Go , meskipun kami tidak menggunakannya di perusahaan. Ini terutama didorong oleh atasan saya. Akhir-akhir ini saya mengikuti beberapa kelas on-line gratis Stanford.

Waktu tidak diukur dengan tepat, pasti bukan 32 + 8 jam, kadang-kadang ada hal-hal mendesak yang harus dilakukan ketika tidak ada cukup waktu untuk memotong 20% itu, di lain waktu saya memiliki lebih banyak waktu luang.

Saya bekerja dari jarak jauh, dan kami menggunakan obrolan api unggun 37signal untuk berkomunikasi dan secara longgar melacak kehadiran satu sama lain, dan jam-jam ini dilacak sebagai jam "bekerja", saya masuk ke obrolan dan tersedia untuk rekan kerja, meskipun membuat jelas bahwa saya tidak mengerjakan proyek kami sekarang.

— Attila O.
sumber

3

Dari pengalaman kecil saya, banyak proyek kami sebenarnya dimulai dengan cara ini. Kami memiliki waktu luang dan bandwidth untuk mengerjakan proyek-proyek baru, kami berkumpul dan menghasilkan ide-ide pemikiran yang keren / maju untuk departemen kami. Di waktu luang kami, kami mengembangkan prototipe dan setelah itu dipoles dengan cukup, disajikan ke tingkat atas dan biasanya mereka melihat manfaatnya.

Tampak bagi saya bahwa tingkat atas tahu apa yang mereka inginkan jika mereka melihatnya tetapi tidak tahu mereka membutuhkan / menginginkannya sampai mereka melihatnya. Prototyping telah memungkinkan kami untuk membuat proyek kami sendiri, mengusulkannya dan kemudian setelah disetujui mengalihkan lebih banyak waktu untuk menyelesaikannya.

— Chris
sumber

Saya pikir itu benar bagi sebagian besar organisasi - saya tentu pernah mengalami di masa lalu yang menunjukkan hal-hal keren kepada manajemen / pemasaran membuka peluang-peluang tertentu dan menciptakan proyek-proyek baru - namun segala upaya dan menjadikan waktu ini 'secara resmi' tersedia untuk mengejar yang baru dan yang akan datang ide-ide berpikir jatuh sangat datar, sangat cepat. Anda menyebutkan "waktu luang" - apakah saat ini di luar jam kerja Anda, atau di dalam? Juga, boleh saya bertanya, seberapa besar departemen Anda? (berapa banyak devs, dan berapa banyak yang terlibat dengan ini?)

— dannywartnaby

Proyek-proyek ini biasanya dimulai di antara proyek-proyek yang disewa. Tim kami adalah tim kecil (3-7 pengembang). Dan itu tergantung pada proyek yang terlibat di dalamnya. Kadang-kadang saya melakukan hal-hal ini di rumah untuk bersenang-senang jika saya ingin belajar teknologi baru, di lain waktu jika itu sesuatu yang saya dapat membuat prototipe dengan cukup cepat tanpa mengerjakan sebagian besar rincian saya akan melakukan hal itu.

— Chris