Bir işyerinde “% 20 zaman” tanısı [kapalı]

% 20 zaman o 's çalışanlar ilginç buldukları projeler üzerinde çalışırken zamanlarının% 20'sini geçirmek için izin işveren kültürü - bu yeni bir uygulama icat veya varolan sürecinin iyileştirilmesi olabilir, vs. Bazı insanlar olabilir kokarca olarak bunu biliyorum Ancak bu terim sizin için hiçbir şey ifade etmeyebilir (ya da tamamen farklı bir şey).

Bir şirkette% 20 / skunk çalışmasından doğmuş birçok harika ürünün belgelenmiş durumu vardır. Bir kazan / kazan durumu gibi görünüyor; Şirket potansiyel olarak mükemmel bir yeni ürün veya uygulama kazanır ve geliştirici yaratıcı kaslarını esnetme ve yenilik yapma olanağına sahiptir.

Önceki işverenimde başarılı olmayan bir şekilde% 20 / Skunk türünü tanıtmak için birçok kez denedim.

Nasıl yönetime haklı çıkarabilirim? Bu tür bir iş düzenlemesine yaklaşmanın "doğru" yolu nedir?

% 20 zamanın ana nedeni, kapasite kullanımının% 100 yerine% 80'de tutulmasıdır.

Bir yazılım geliştirme organizasyonunu, özellik isteklerini gelişmiş özelliklere dönüştüren bir sistem olarak düşünebilirsiniz. Davranışını kuyruk teorisini kullanarak modelleyebilirsiniz .

TEORİSİ

İstekler, sistemin kendilerine hizmet edebileceğinden daha hızlı gelirse, sıraya girerler. Gelenler yavaşladığında, sıra boyutu azalır. Varış ve servis işlemleri rastgele olduğundan, sıra boyutu zamanla rasgele değişir.

Matematiksel olarak eğimli bu "rastgelelik" hakkında soru sorabilir: bazı olasılık dağılımları olmalı, yani sıra boyutu ortalamada ne olacak? Math'ın (kuyruk teorisi) buna bir cevabı var: eğer hem varış hem de servis işlemleri Markov ise, o zaman N = rho ^ 2 / (1-rho).

(Hizmet ve varış oranlarının oranına eşit kullanım katsayısı ise. İşlemler Markov değilse, matematik daha karmaşıktır, ancak sonuçları değiştirmez.)

Bu fonksiyonu çizerseniz, ortalama kuyruk uzunluğunun kullanım 0.8'e kadar düşük kaldığını , ardından keskin bir şekilde yükseldiğini ve sonsuza kadar gittiğini görebilirsiniz. Bunu, bilgisayarınızın CPU'sunu düşünerek sezgisel bir şekilde anlayabilirsiniz: kullanımı% 100'e yaklaştığında, bilgisayar yanıt vermiyor.

UYGULAMA

Yazılım geliştirme ekonomisi, yazılım şirketlerinin sıralarının yüksek sıralarda olması durumunda büyük maliyetlere maruz kalmasıdır. Bu, kaçırılmış pazar fırsatlarını, eski ürünleri, geç kalan projeleri ve talep beklentisiyle bina özelliklerinden kaynaklanan atıkları içerir.

Dolayısıyla,% 20 zaman, ekonomik sonuçları optimize etme sorununa bilimsel bir cevaptır: Yüksek sıradaki durumlardan kaçının, buna neden olan kullanım oranlarından kaçının. Esasen sistemi duyarlı tutan gevşekliktir.

Birkaç pratik sonuç hemen takip eder:

• % 20 zaman alıyor ve maliyet muhasebesi yapıyorsanız (geliştiricilerin zamanı X'e mal olur, ancak / ve şirket bunu karşılayamaz / karşılayamazsa), yanlış yapıyorsunuzdur.
• Her hafta cumaya% 20 tahsis ediyorsan, yanlış yapıyorsun
• % 20 zaman proje teklifi teslim / inceleme / onay sistemi kuruyorsanız, yanlış yapıyorsunuzdur
• zaman çizelgelerini dolduruyorsan, yanlış yapıyorsun
• Eğer yeniliği% 20 zaman boyunca motive edici olarak kullanıyorsanız, yanlış yapıyorsunuz demektir. Yeni ürünler% 20 projeden çıksa da önemli değildi. Şirketiniz çekirdek saatleri boyunca yenilik yapamıyorsa, bu bir sorun!
• % 20 zaman yaratıcılıkla ilgili değil. Yaratıcılığınızı% 20 zamanla serbest bırakacağınızı söyleme, neden zaten çekirdek saatleriniz boyunca yeterince yaratıcı olmadığınızı sorun.

YORUMLARINIZDA SORULARA CEVAP

Dan , bunu doğru yaptın ve birçok kişi tarafından yapılan hatayı doğru tarif ettin. Kullanım yüzdesini seçemezsiniz, çünkü bu bir çıktı değişkenidir. İki sürecin özelliklerinin bir oranıdır, yani süreç budur, çünkü süreçler oldukları gibidir. Bir kuruluşun her iki süreçte de etkisi vardır; Yetenek ve talep eşleştirme, yalın yazılım geliştirme bilgi birikimi tarafından ele alınan zor sorunlardan biridir. Kullanımı, bu sorunun bir organizasyonda ne kadar iyi çözüldüğünün göstergelerinden biridir. Yalın girişiminiz ilerledikçe gevşeme ortaya çıkıyor ve atıkları değer akışından kaldırıyorsunuz. Ancak% 20 zaman ayırırsanız, daha az kapasite ile aynı kullanım tuzağına düşersiniz.

Kim , bu hala kısmen bir kültür meselesi. Düşünebileceğim en yakın kültürel referans, sözde Marshall örgütsel değişim modelinin sinerjik seviyesidir . Başarılı yalın dönüşümlerin sonunda ortaya çıkar veya başlangıçtan itibaren yalın olarak kurulan organizasyonlarda bulunur. ( İşte Bob Marshall'ın beyaz makalesine bir link (PDF) .)

REFERANSLAR

Yukarıdaki mantık, yazılım mühendisliği literatüründe iyi desteklenmektedir. Mary ve Tom Poppendieck, Yalın Yazılım Geliştirmeyi Uygulamaya Getirdikleri 2006 kitaplarında bunu ima etti . Donald Reinertsen , 2009 yılında yayınlanan Ürün Geliştirme Akışı İlkeleri kitabında (Bölüm 3), bu konunun formül ve grafiklerle ayrıntılı bir şekilde ele alınmasını sağlar.

Bu cevabı yazdıktan on dört ay sonra çok daha iyi bir cevap buldum .

Bu eserlerin resmen tanındığı bir yerde çalışmamıştım. Ancak konuşmalarımdan ve bu uygulama hakkında bilgi edinmeye çalıştığımda, şunu buldum - peki, çoğunlukla "% 20 zamanının" ne olmadığını:

• bu aslında bir kültür değil, politika
• üst yönetim tarafından karar verilemez
• bir geliştiriciler kurulu tarafından kurulamaz
• Bu 32 saat ve bu 8 saat değil

" Skunkworks "% 20 zamanla aynı değil. Söylediğiniz gibi% 20 zamandır - geliştirici üzerinde çalışılacak olanı kendi başına seçer. Skunkworks tamamen farklı. Bir skunkworks projesi, üst yönetime bildirilmeyen bir ekip (genellikle guruların parçalanma ekibi) tarafından yürütülen, yüksek değerli, yüksek maliyetli bir projedir ve ekip, projenin yönetim yönetimi olmadan nasıl ilerlemesi gerektiğine karar verir. . Bu projeler genellikle bir şeyi başarmak için taktiksel veya ticari bir ihtiyaçla motive edilir, ancak bütçesinde yer yoktur. Bir şeyin yapılması gerekiyorsa, yapılır - bütçeler lanetlenir.

% 20 zaman uyguladığım bir geliştirme ekibini yönettim. Ya da yine de denedim. Üstlerimin onayını aldım, bu bir sorun değildi. Sorun, ekibin çok küçük ve çok uzmanlaşmış olmasıydı. Acil müdahale gerektiren problemler ortaya çıktığında,% 20 zaman kaybedildi. Bu çok sık oldu.

Ayrıca geliştiricimin bir kısmının yön eksikliğimi rahatsız edici bulduklarını da buldum. “İstediğiniz herhangi bir şey üzerinde çalışın, programlamaya bağlı olduğu sürece” dediğim halde, “şey” kısmını kabul etmekte zorlanıyorlardı. Bazı projelerin diğerlerinden daha iyi olacağını düşünüyorlardı, bu yüzden kaçınılmaz olarak ana üründeki düşük seviyeli uygulama talepleri üzerinde çalıştılar, bunun gibi şeyler. Dallanmalarını ve büyümelerini istedim ama bunun yerine ana uzmanlıklarını daha derine çıkardılar.

Tekrar yapardım, ama ana ürün üzerinde çalışmayı açıkça yasaklardım ve başlamak için seçebilecekleri bazı fikirler ile başlayabilirim.

% 20 politikasını uygulayan bir girişim için çalışıyorum. Bu benim bunu yapan ilk işverenim ve iş görüşmesine katıldığı zaman, diğer işverenlerin çoğu bir saatini "boşa harcamamaya" çalıştığı için gerçekten şaşırdım.

Kurulduğu zaman devreye girdim ve neredeyse bir yıl boyunca tek geliştiriciydim. % 20'mi temelde birkaç şeyle harcadım:

• Raporlama / rasgele açık kaynak projelerine hata tespit - Bu ilginç bir projeyi bölmek gibi küçük olabilir Github & dokümanlar birkaç yazım hatası tespit.
• Açık kaynak kodlu "şeyler" yazma - sadece eğlence için programlama zorlukları gibi şeyler.
• Konferanslara ve sprintlere gitmek - birkaç ayda bir, projeler üzerinde çalışabileceğim (bazıları ana uygulama tarafından kullanılabilecek, bazıları değil) ve biraz tecrübe kazanabileceğim bir sprint'e giderim. Uygulamamız tarafından ve geliştiricilerini konferanslara gönderen diğer şirketler tarafından geliştirilen uygulamalar tarafından kullanılan birkaç kütüphane vardır, bu nedenle şirketimize doğrudan bir fayda olarak görülebilir.
• Yeni teknolojiler öğrenmek - işte böyle kullanmamıza rağmen Go'yu böyle öğrendim . Bu özellikle işverenim tarafından teşvik ediliyor. Son zamanlarda bazı Stanford ücretsiz çevrimiçi derslerini takip ediyordum.

Zamanlar tam olarak ölçülmüyor, kesinlikle 32 + 8 saat değil, bazen% 20 kesmek için yeterli zaman olmadığında yapılması gereken acil şeyler var, diğer zamanlarda ise daha fazla zaman ayıracağım.

Uzaktan çalışıyorum ve 37signal'ın Campfire sohbetini iletişim kurmak ve birbirimizin varlığını gevşek bir şekilde izlemek için kullanıyoruz ve bu saatler "çalışma" saatleri olarak izleniyor, sohbete giriş yapıyorum ve iş arkadaşlarım için uygunum. Şu anda projemiz üzerinde çalışmayacağımı açık.

Küçük deneyimlerime göre, aslında bir çok projemiz bu şekilde başladı. Yeni projeler üstlenecek boş zamanımız ve bant genişliğimiz vardı, bir araya geldik ve bölümümüz için potansiyel ileri / iyi düşünme fikirleri ile karşılaştık. Boş zamanlarımızda bir prototip geliştirdik ve bir kez oldukça cilalandı, üst seviyeye çıkarıldı ve genellikle fayda görüyorlar.

Bana öyle geliyor ki, üst seviye gördüklerinde ne istediklerini biliyor, ancak görene kadar ihtiyaç duyduğunu / bilmiyorlar. Prototipleme kendi projelerimizi yaratmamıza, teklif etmemize ve onaylandıktan sonra tamamlamaları için daha fazla zaman ayırmamıza izin verdi.