İş birliği işe yaramaz
(newsletter.posthog.com)- “Yalnız gidersen hızlı, birlikte gidersen uzağa gidersin” sözü startup’ları batırabilir
- Verimli iş birliği, araba kullanırken navigasyon yardımı seviyesinde olmalı; ancak çoğu şirket aşırı geri bildirim ve rol dağılımı yüzünden hız kaybı yaşıyor
- PostHog, “Sürücü sensin (You're the Driver)” değeri altında özerklik ve yüksek sahiplenmeyi vurguluyor ve gereksiz iş birliğini en aza indiriyor
- Aşırı iş birliğinin nedenleri arasında yardımcı olma isteği, kapsayıcılık kültürü, belirsiz geri bildirim talepleri, “let’s discuss” ifadesinin aşırı kullanımı, sorumluluktan kaçınma yer alıyor
- Çözüm ise hemen yayına almayı önceliklendiren, sorumluyu netleştiren, yalnızca gerekli kişilerden geri bildirim isteyen, yayın sonrası geri bildirim veren ve gereksiz iş birliğini anında kesen pratik bir yaklaşım
İş birliğinin tuzağı
- "Hızlı gitmek istiyorsan yalnız, uzağa gitmek istiyorsan birlikte" sözü şirketi yavaş yavaş öldürür
- Bu, aşırı iş birliğini meşrulaştıran bir tuzaktır
- Faydalı iş birliği, araç kullanırken yön tarifi ya da çevre bilgisi vermek düzeyinde olmalıdır
- Ancak çoğu organizasyon, direksiyonu sırayla tutmaya benzeyen verimsiz bir iş birliği biçimine saplanır
- Doğru miktarda geri bildirim hedefe hızlı ulaşmayı sağlar; ama aşırı geri bildirim hızı düşürür ve istediğiniz yere hiç ulaşamama riskini doğurur
Geri bildirimin paradoksu: Geri bildirimi iyi vermek, onu ne zaman vermemek gerektiğini bilmektir
- PostHog’da da büyümeyle birlikte değer katmayan ya da harcanan zamana göre değeri çok düşük kalan iş birlikleri arttı
- Yakın tarihli şirket geneli toplantısında konu olarak "iş birliği kötüdür" ele alındı
- "Sürücü sensin (You're the driver)", PostHog’un temel değerlerinden biri: "Mükemmel insanları işe al ve yollarına çıkma"
- Deadline yok, minimum koordinasyon var, yöneticiler ne yapılacağını söylemiyor
- Bunun karşılığında son derece yüksek sahiplenme duygusu ve tek başına çok şey başarabilme yeteneği bekleniyor
- Pazarlamacı kod deploy ediyor, satış çalışanı yedek almadan teknik soruları yanıtlıyor, ürün mühendisi tüm stack üzerinde çalışıyor
- Neredeyse her zaman sizden daha iyi bilen biri vardır ve onunla iş birliği yapma cazibesi doğar; ancak iş birliği sürücünün yavaşlamasına, arka planı, bağlamı ve düşüncelerini açıklamasına neden olur
- Bu eğilim birkaç temel ifadeyle ortaya çıkar
- "X’in bu konuda ne düşündüğünü merak ediyorum"
- "Y’nin fikrini duymak istiyorum"
- "Bunu Z ile birlikte yapmalıyız"
- Bunlar bazen değerli içgörülere yol açsa da, her zaman sürücünün hızını keser
- Sürücünün motivasyonunu, özgüvenini ve verimliliğini aşındırır; sonunda da yayınlanan iş miktarını azaltır
İş birliği kötüyse insanlar neden bunu yapıyor?
- Bunda herkesin payı var
- İnsanlar yardımcı olmak ister: Biri Slack’e üzerinde çalıştığı şeyi koyunca, geri bildirim kültürü nedeniyle başkaları da yorum yapmak zorunda hisseder
- Tersine, belirli bir kişiden geri bildirim istemek yeterince kapsayıcı değilmiş gibi hissedildiği için bunu istemezler (oysa aslında faydalı olacaktır)
- Ne tür geri bildirime ihtiyaç duyulduğu yeterince net söylenmez: Bu da iş birliğinin araya girmesine alan açar. Belirli bir özelliğin nasıl yapılacağına dair bir tartışma, tüm ürün yol haritasını yeniden değerlendirmeye kadar büyüyebilir
- Biri iyi bir fikir ortaya attığında, varsayılan tepki "onu yap" değil, "hadi tartışalım" olur
- Bunun kanıtı olarak Slack’te sayısız kez "let's discuss" yazılır
- Böylece uygulamadan tartışmaya geçilir
- İnsanlar ya uygulayamayacak kadar meşguldür ya da uğraşmak istemez; bu yüzden sadece konuşmak isterler
- PR → issue/RFC → Slack (şu anda çoğunlukla burada) → "hadi tartışalım" akışına kayar
- Kimin sahibi olduğu net değildir (ya da kimse tartışılan şeyi sahiplenmek istemez)
- Sinir bozucu olsa da bazen tek bir kişi baştan sona yeterince yüksek kalitede Shipping yapamaz ve sadece Shipping yapıp iterasyonla ilerlemek mümkün olmaz
- Bozuk kod düzeltilebilir ama bülten yeniden gönderilemez
İş birliğini bozmanın yolu (ve daha hızlı, daha uzağa gitmenin yolu)
- İş birliğini düşman olarak görüyorsanız, onu nasıl yenersiniz?
- Varsayılan tercih uygulamadır: Pull request > Issue > Slack mesajı
- İş birliği aşırıya kaçtığında, “Sürücü sensin, kararı sen ver” diyerek sınırı net çizin
- Geri bildirim isterken, kimden tam olarak ne istediğinizi etiketleyin; ortaya boş bir çağrı atmayın
- Yayın öncesi inceleme yerine yayın sonrası (bir sonraki iterasyondan önce) geri bildirim vermek tercih edilir: Önceden verilen geri bildirim yarı-onay sürecine dönüşebilir
- Liderler geri bildirim verme konusunda kendini tutmalı ve “bir şeyleri doğrudan yapabilirsin (you can just do stuff)” yaklaşımını korumalı
- Herkes “bilgi sahibi kaptan (informed captain)” gibi davranmalı
- Geri bildirimi dinleyebilir ama kararı kendisi verir
Sonuç
- Tüm iş birliğini kökünden söküp atmak mümkün değil; bazı iş birlikleri faydalıdır (bu bülteni Ian ve Andy düzenliyor)
- Ama varsayılan olarak iş birliğini azaltmaya çalışmak gerekir
- İş birliğini aktif olarak azaltmaya çalışmıyorsanız, muhtemelen varsayılan olarak zaten fazla iş birliği yapıyorsunuzdur
- İş birliği doğası gereği hızı düşürdüğü için,
ne kadar az iş birliği yaparsanız o kadar uzağa ve o kadar hızlı gidebilirsiniz
- (Köpükler fazla iş birlikçi olduğu için) gazlı suyu sevmeyen Charles Cook tarafından yazıldı
12 yorum
Birlikte çalışmak doğrudur.
O kişi yoksa (vefat, hastalık, izin), müşteriye hiç mi yanıt verilmiyor?
Çok küçük bir şirkette çalışıyorum ve tek çalışan benim. Bu yüzden bakım işlerini de tek başıma yapıyorum, geliştirmeyi de tek başıma yapıyorum.... Ama bu durum çok uzun sürdüğü için insanlarla birlikte çalışmak istediğimi de hissediyorum. Tek başına çalışmak çok yalnız hissettiriyor...
Oldukça dikkat çekmek için yazılmış bir yazı.
Yazarın kişiliği fazla baskın olduğu için diğer insanlarla iyi anlaşamıyor olabilir mi?
Tek bir özelliği oluşturmak için
tasarımcı, planlama, proje yöneticisi, frontend, backend, QA gibi rollerin mutlaka gerekli olması kaçınılmazdır
Kişinin fark ettiği sorunu görünür kılmak için aşırı iddialarda bulunduğu anlaşılıyor.
İşbirliği denince bunun agora benzeri bir şekilde yürütülmesi kastedilmiyor olmalı.
Yine de
let’s discussifadesinin gereğinden fazla kullanılması ve sorumluluktan kaçılması, bu iki unsurun kesinlikle sorun olduğu açık.Ancak bunlar çoğu zaman içgörülü bir liderin ya da sorumlunun bulunmamasından kaynaklanıyor.
Zaten bunun için araştırma yapılır, insan yetiştirilir, işe alım yapılır ya da çözüm satın alınır.
Ekibi sadece söyleneni iyi dinleyen üyelerden kurarsanız bu durum daha da tetiklenebiliyor.
Bunun, işbirliğinin ya da tek başına çalışmanın yarattığı bir sorun olduğunu sanmıyorum.
Posthog’un her zaman bu şekilde güçlü ifadeler kullanan yazılar yazdığını akılda tutarak okuyun.
Üslup fazla sert olduğu için bazen konuyu biraz aşıp yanlış bir yöne sapan yazılar da görülebiliyor.
(Gazlı su ne kadar da güzel ama!!!)
Maden suyu dediğin şey highball fırlatma rampası değil mi, şey...
Hacker News görüşü
Her iş birliği ortaya çıktığında “çok fazla insan var, X driver olduğu için kararı sen ver” denmesi tavsiye edilmişti
Ama yönetici “kararı sen ver” deyip toplantıya gelmez, sonra da “ben olsam farklı yapardım” diyerek değişiklik isterse çalışanlar ayrılmaya başlar
Müdürümün müdürü sürekli böyle konuşurdu; ben bir PR açtığımda ise sonunda baştan aşağı redesign isterdi
Sonunda hangi proje olursa olsun en baştan yeniden yazmak gerekeceğini bildiğim için işin kendisinden korkar hale geldim
Üst yönetici kararları çok sık tersine çevirirse ekip üyeleri bilerek bütün kararları ona yıkmaya başlar
Sonunda yönetici kendi kontrol arzusu içinde boğulur
Ama bağlam “yönetici talimat vermesin” olunca kendi içinde tutarlı
Çünkü ardından bitmeyen piksel düzeltmeleri, yerleşim değişiklikleri ve tam kapsamlı stack yeniden çalışma önerileri gelirdi
Sorunun özü iş birliği değil, karar alma yapısı bence
Geri bildirim bir öğrenme fırsatıdır ama son kararı kimin verdiği belirsizse hız düşer
Hızlı kararlar için karar sahibi net olmalı ve çoğu kararın geri alınabilir olduğu kabul edilmeli
İş birliği azalırsa öğrenme fırsatları da azalır
Karar sahibi açıkça belirlenmeli ama geri bildirim dikkatle dinlenmeli
Ayrıca geri alınabilir kararlar hızlı verilmelidir
İş birliğinin hızı düşürdüğü söylenir ama aslında o süreçte kalite artar
Bazıları sırf karşı çıkmak için karşı çıkar ve sonunda fikrin sahipliğini ele geçirmeye çalışır
Son karar verici net olsa bile görüşleri zayıfsa sonunda çoğunluk uzlaşmasına bırakılır
“Değişiklik iste” koyduklarında herkes buna uymak zorunda kalıyordu ve sonunda kod kalitesi düşüyordu
İyi insanları işe alıp karar yetkisini devretmenin çok daha iyi olduğunu düşünüyorum
Yön, öncelik ve çerçeve sunarak ekibin kendi başına karar verebilmesini sağlamalıdır
Yazarın maden suyu nefretine katılmıyorum ama iş birliği sorunlarını açıkça ele alması sevindirici
Birkaç şirkette kod incelemesi sırasında önemsiz stil yorumları yüzünden gerçek uygulamaya harcadığım zamanın 3 katını harcadığım oldu
Benim yaklaşımım “beğenmiyorsan kendin düzelt ve haber ver” şeklinde
İlgili video da paylaşılmış
Kod inceleme aşamasında bunları ele almak artık çok geçtir
Sorun, çevredeki kod stiline uymayan kişidedir
Bu, linter ya da kültürle çözülmelidir
İş birliği olmadan tek başına yapılan bir özellik bakım sırasında büyük risk haline gelir
Ben yokken sistem patlarsa, asıl sorun iş birliğinin eksikliği olarak ortaya çıkar
Yazar eylem yanlılığını vurguluyor ama iş birliğini dışlarsanız silo'lar ve aşırı özgüven oluşur
“Ben X yapmayı düşünüyorum, güçlü bir itirazı olan var mı?” tarzı Slack kültürü etkili olmuştu
Bu yüzden iş gerçekten ilerliyor
Eskiden GitHub hakkında bir kitap yazarken röportajlar yaptım; bazı ekipler kod yazmadan önce tasarım onayı almak için boş PR açıyordu
Bu, geliştirme sırasında iş birliği değil, planlama aşamasında iş birliği
İyi yazı ve iletişim varsa iş birliği hızlı ve etkili olabilir
Yapay zeka çağında bu beceriler daha da önemli olacak
Toplantı ve paylaşım yoksa emeğin görünmüyor
Sorunları önlersen kimse fark etmiyor; bu yüzden bazı yerlerde sorunların bilerek oluşmasına izin verilen bir kültür bile var
Sadece planla uygulamayı zihnimde canlandırmak zor oluyor
Yazının son cümlesinde dendiği gibi “iyi iş birliği vardır”
Başlık clickbait ama PostHog zaten bu tarzıyla biliniyor
İnsanları “iş birliği” mem'ine daha eleştirel bakmaya itiyor
Bu yazı yanlış bir düşünce deneyi
Sorun iş birliği değil, karar yetkisinin yokluğu
Tek bir kişinin net biçimde karar vermesi gerekir; bu yetki ne kadar aşağıya inerse hız o kadar artar
Böyle yazılar dili çarpıtarak gerekli kavramları değersizleştiren bir toksiklik taşıyor
Biri takılınca hemen “Bob'a sor” denilen kültür de sorunlu
Kısa vadede hızlıdır ama uzun vadede öğrenme fırsatı kaybı ve iş yükü aşırılaşması yaratır
İş arkadaşlarımın yaptığım işle ilgilenmesini seviyorum
“Sen bilirsin” aslında çoğu zaman “umurumda değil” demektir
Sorun iş birliği değil, verimsiz iş birliği
PR'larda somut bir çıktı olduğu için tartışma daha net hale geliyor
Bana göre iş birliği en iyi iki kişiyle çalışıyor
İki kişi kod tabanını birlikte anlayabiliyor ve birbirlerinin PR'larını inceleyebiliyor
Ama üç kişi ve üstüne çıkınca kombinatoryal karmaşıklık patlıyor
Bu yüzden projeleri iki kişilik ekip yapısı ile tasarlamak isterdim
Referans bağlantı
Yazıdaki benzetmede olduğu gibi, F1 yarışı aşırı derecede iş birlikçi bir spor
Sürücü yarış boyunca koçla sürekli iletişim halinde
Yazılımda buna benzer bir örnek olup olmadığını merak ediyorum
Yorumlar tuhaf görünüyor. Yazının özetine bakınca, tek başına çalışın ya da ekip arkadaşlarına gerek yok denmiyor; daha çok ekip üyeleri arasındaki aşırı iş birliğini azaltalım deniyor gibi.
Katılıyorum.
Clickbait bir başlıkla metni dikkatle okumamış bir okurun birleşiminin sonucu gibi görünüyor.
Sadece böyle yazılarda değil, YouTube'da bile sadece başlığa bakıp yorum yapan çok insan var.
Yeni bir işe başlarken, fazla temkinli davranıp çevrenizdekilerden gereğinden çok inceleme istemeniz mümkün. Aslında çevrenizdeki insanlar ya da ekip konuya çok hakim olmayabileceği için iyi geri bildirim vermeleri de zor olabilir. Sonuçta önce bir şey ortaya koyup, yön yanlış olsa bile ardından somut geri bildirim alarak yeniden çalışmak, genel olarak zamandan tasarruf sağlayabilir gibi görünüyor.