Efsanevi Efsanevi Adam-Ay

Bir teknoloji şirketinde ürün lideri olarak dipsiz bir ihtiyaç çukuruyum. Mailchimp'te Baş Ürün Sorumlusu olarak görevim, çok rekabetçi bir alanda kazanacak ürünü pazara sunmak. Mailchimp'in beklentileri yüksek ve bunları gerçekleştirmek için pazara önemli miktarda ürün sunmamız gerekiyor. Çoğu zaman şirketteki birçok kişiye çok fazla şey yapıyormuşuz gibi gelir. Her zaman çıkan tekerleklerin kenarındayız.

Ve çok fazla şey yaptığınızda ve bundan daha fazlasını yapmaya karar verdiğinizde, kaçınılmaz olarak The Mythical Man-Month'a atıfta bulunulduğunu duymaya başlayacaksınız. Bir ucunu sıkarsanız, diğer ucunda Efsanevi Adam-Ayı dışarı fırlayan stres giderici toplardan biri gibi.

1975'te Frederick Brooks tarafından yayınlandı (1975'i hatırlıyorsunuz değil mi? Yazılım geliştirmenin %100'ü 2020'de yazılım geliştirmeye benzediğinde?), bu kitap yazılım mühendisleri arasında oldukça ünlüdür. Özellikle, kitabın tamamında ünlü olan bir nokta var (insanların kitabı okudularsa bu noktadan başka bir şey okuduklarına ikna olmadım):

“...daha fazla erkek eklemek programı kısaltır, uzatır.”

Kolay düzeltme. Bundan böyle projelerde sadece kadınları görevlendireceğim (bkz. Kralın Dönüşü ve Angmar'ın Cadı Kralı'na karşı savaş).

Ancak, söz konusu yazılım mühendislerinin cinsiyet kimliğinden bağımsız olarak Brooks'un görüşünün geçerli olduğunu varsayalım. İşin püf noktası şudur: Çok sayıda karmaşık karşılıklı bağımlılıkla yazılım oluşturmak zordur. Ve bunu başarmak için herkesin birlikte çalışması gerekiyor.

İnsanları bir ekibe eklediğimde, onların projeye dahil edilmeleri ve aşılanmaları gerekiyor. Birileri onlar için doğru işi kesmeli. Ekip, tüm öğelerinin birlikte çalıştığından emin olmak için iletişim kurmalıdır ve her ek kişi bu iletişim karmaşıklığını geometrik olarak artırır. Ve bir noktada, insanları eklemek projeye bir yük olur - fayda değil.

İşte bu noktayı gösteren kitaptan grafik:

Bu kesinlikle adil bir nokta. Bu yüzden işyerinde çok duyuyorum. Tükenmiş bireysel katkıda bulunanlar ve bitkin liderler bunu bir kenara atacaklar - daha hızlı gidemeyiz, daha fazlasını yapamayız, işe alımı durdurun, Efsanevi Adam-Ayı okuyun ve umutsuzluk! Görünüşe göre tek çözüm büyümeyi durdurmak ve bazı projeleri öldürmek.

CPO olarak “Bu işi yapacağız!” dediğimde. o zaman cevap genellikle, "Tamam, öyleyse ne öldüreceğiz?" Efsanevi Adam-Ay , ürün geliştirmeyi sıfır toplamlı bir oyuna dönüştürüyor. Bir şeyi istiyorsak, diğerini durdurmalıyız. Şimdi, bu gerçek bir efsane ve ben buna hogwash diyorum.

Ve patolojik olarak yanlış yorumlanmış (buna geleceğiz) sonucuna bakıldığında, kitap görünüşe göre en hızlı teknoloji şirketinin dört kişiyi de istihdam eden bir şirket olduğunu söylüyor - görünüşe göre dört adam . Daha fazlası her şeyi yavaşlatır. Birileri kitabın Amazon, Apple ve Google kopyalarını göndermeli ki bariz şekilde şişmiş olan organlarını düzeltebilsinler.

Bu yaklaşımla ilgili tek sorun, rekabetin büyüdüğü ve yinelendiği ve yürütüldüğü bir alanda - yalnızca kurumsal büyümeyi değiştiriyor - düzenleme ve iş yükünü eşleştirmeye odaklamanın bir yok olma reçetesi olabilmesidir. İşiniz bitene kadar daha aklı başında ve daha az stresli olacaksınız.

Ve şirketimin ürün yönetiminin sahibi olarak, bu yavaşlama ve odaklanma ihtiyacına sıcak bakmıyorum. Acımasızca öncelik vermeliyiz ! Şüphesiz. Ancak bir ürünü çalıştırmak çelişkili bir alıştırmadır. Aynı anda daha fazlasını yapmak için planlar yaparken, sahip olduklarıma öncelik vermeliyim. Ama Efsanevi Adam-Ayı karşısında ne yapacağım?

Şaşırtıcı bir şekilde, bu sorunun cevabı Brooks'un aynı kitabından geliyor. İşte aynı bölümdeki başka bir grafik:

Ürün geliştirmeyi ölçeklendirmede bir savaş var. Başarmaya çalıştığınız iş tamamen bölünebilirse, devam edin ve insanları ekleyin! İşiniz birbiriyle bağlantılıysa, bir noktada insanları eklemek tamamen yanlıştır.

Birisi, bir başka projeye başlamak için kesinlikle bir projeyi bitirmem gerektiğini söylüyorsa, durum böyle değil. İki proje çok az iletişim ve koordinasyon gerektiriyorsa, ölçeği küçültebiliriz.

Bu nedenle bir CPU'ya çekirdek eklemek, bilgisayarınızın veya telefonunuzun deneyimli hızını bir noktaya kadar artırabilir - mühendislerin her şeyi bilmesi gereken bir şey. Elbette, çekirdek eklemek karmaşık bir tek iş parçacıklı hesaplamayı tamamlamama yardımcı olmayacak. Ancak bir dizi bağımsız görevi yürütmeme yardımcı olabilir.

Bir ürün yöneticisi için ölçeklendirme ve acımasız önceliklendirme arasındaki çatışma yönetilebilir.

1. Tek iş parçacıklı (bir ürün ekibinin biriktirme listesi diyelim) olan yerlerde acımasızca öncelik veriyorsunuz.
2. Bağımsız çalışmayı halletmek için daha fazla çekirdek ekleyerek ölçeklendirirsiniz.

Bununla birlikte, çok nadiren, bir şirkette diğer her şeyden tamamen bağımsız bir şeydir. En azından, şirketiniz darboğazlara yol açan destekleyici işlevleri (küresel BT, hukuk, İK vb.) merkezileştirecektir.

Her Şey Bağımlılık Yönetimi Hakkında

Bu durumda bir ürün yöneticisinin işi yalnızca bir strateji oluşturmakla kalmaz, aynı zamanda verimliliği sağlayarak ve karşılıklı bağımlılık riskini mümkün olduğunca azaltarak müşteri ve işletme için değeri en üst düzeye çıkaracak şekilde yürütme olur. “Mümkün olduğunca” burada anahtardır. Bu şekilde şirketin öncekinden çok ikinci grafiğe benzemesini sağlayabilirsiniz. Bağımlılık tedavisi olmayan bir hastalıktır , ancak semptomları birçok tedavi ile yönetilebilir.

Çözümlerden biri, dikkatle seçilmiş bir girişim portföyü aracılığıyla bağımlılığı en aza indiren veya sınırlayan şirket için stratejik bir yön oluşturmaktır. Buradaki komik olan şey, birçok insanın bu konuda geri adım atacak olmasıdır. Diyelim ki iki seçeneğim var, biri çok az koordinasyona sahip A, B ve C projelerini yürütebileceğim ( farklı ürünleri etkilediğini varsayalım) ve tonlarca birbirine bağlılığı olan D1, D2 ve D3 projeleri olan başka bir seçenek ( Diyelim ki hepsi aynı ürünü etkiliyor). Efsanevi Adam-Ay'ın ikinci plana değil, eski plana karşı çağrılacağı sık sık görülür. Çünkü kağıt üzerinde daha çok görünüyor .

Aslında, daha az “odaklanmış”. Ancak, bağımlılık açısından aslında daha az zor ve bu nedenle ilave personelle daha iyi sonuç veriyor.

Aklınızda bulundurun, ilgili olmayan şirket için bir grup iş seçin demiyorum. Mailchimp yakın zamanda bir mikrodalga fırın yapmayacak. Tüm işler aynı uzun vadeli yönde ilerlemelidir. Bu yaklaşım, müşteri deneyimi riskini (daha sonra tartışacağız) ve müşteri araştırması gibi küresel işlevler üzerindeki yükü artırabilir. Buna dikkat edin.

Diğer bir tedavi ise, ekiplere gerekli değilse koordinasyon ile aşırı yük bindirmeden , gerektiğinde bağımlılık koordinasyonunu ve iletişimi kolaylaştıran bir ürün ve program yönetim süreci oluşturmaktır. Bazen daha fazlasını yapabilmek için koordinasyonu yönetmeye çalışırken, o kadar zahmetli süreçler yaratırız ki daha azını yaparız. Bu, parçaların birbiriyle çalışmamasına neden olan çok az koordinasyon ile parçaların asla inşa edilmemesine neden olan çok fazla koordinasyon arasındaki bir denge çünkü hepimiz sonsuza kadar ayaktayız.

Efsanevi Adam-Ay'daki çekişme, bir yazılım projesine insan ekledikçe, iletişimin geometrik olarak artması gerektiğidir. Örneğin, projede 3 kişi varsa, bu 3 iletişim hattıdır. Ancak 4 hattınız varsa, bu 6 iletişim hattıdır. Bu durumda fazladan bir kişi, iletişimi ikiye katlar! Eğlence. (Bu, elbette, yazılım geliştirme projelerinde iletişimin aşırı basitleştirilmesidir.)

Farklı insanlar farklı rollere sahiptir ve bu nedenle farklı miktarlarda özerklik alırlar. Belki de proje yöneticisinin ekipteki herkesle iletişim kurması gerekiyor. Ancak API üzerinde çalışan bir mühendisin ürün pazarlamacısı ile iletişim kurması gerekir mi? Yoksa pazarlamacı sadece ürün yöneticisinden geçebilir mi? İyi bir süreç ve toplantı ritmi, gereksiz iletişim ve toplantıları ortadan kaldırabilir. Mesele şu ki, Brooks'un iletişim formülü bir ölüm cezası değil , koordinasyonun bir üst sınırıdır .

Son olarak, karşılıklı bağımlılık belirtileriyle mücadele etmek için gerçek işbirliği üzerinde bağımsız çalışmayla birleştirilmiş araçları, ilkeleri ve çerçeveleri kullanın. Örneğin, aşağı yukarı aynı yönde hareketi teşvik etmek için iki ekibin temel performans göstergelerini (KPI'ler, yani başarı ölçümleri) koordine edebilirsem, o zaman onların bağımsız çalışmasının, "birbirine daha yakın" olması muhtemeldir. KPI'ları dikey hareketi teşvik eder. Bu, işlerin mükemmel bir şekilde birbirine uymasını sağlamayacak, sadece gelecekte onları bir araya getirmek için yapmam gereken iş, aksi halde olabileceğinden daha az. Diğer örnekler arasında "çift-üstü" ifadeler, tasarım sistemleri ve otomatik testler yer alabilir.

Yani bir başlangıç ​​var. Ancak karşılıklı bağımlılıklar, kodun ötesinde birçok biçim alır. Mailchimp'ten bir örnek vereyim.

Müşteri Deneyimi Riski: Güvenlik Duvarı Çalışmasının Gizli (Ama Kabul Edilebilir?) Maliyeti

Mailchimp'in müşterisi genellikle pazarlamada acemi bir küçük işletme sahibi olduğundan (ve dünya çapında pazarlamacılığa dönüşen milyonlarca küçük işletme sahibi vardır), sorunsuz ve baştan sona hemen anlaşılabilir bir deneyim sunmalıyız. Kurumsal oyuncuların yapabileceği şekilde satın alma yoluyla bir Frankenstein'ın bulut canavarını bir araya getirme lüksüne sahip değiliz. Danışmanlar ve hesap yöneticileri ile zayıf bir şekilde entegre edilmiş yazılımları kağıt üzerinde kağıda dökemeyiz.

Bir tüketici ürünü olarak (Instagram veya Nintendo Switch veya Roomba'yı düşünün), kutudan çıkar çıkmaz kullanılabilir olmalıyız. İşinizi güçlendirmeyi amaçlayan hepsi bir arada bir pazarlama platformu için bu zor! Bu da Mailchimp'in oluşturduğu her şeyin bir deneyim perspektifinden sorunsuz bir şekilde bağlanması gerektiği anlamına gelir.

Ancak, projeleri mükemmel bir şekilde bölümlemek, deneyim riskini beraberinde getirir . Kodun bağımsız olarak yazılamayacağı anlamına gelmez. Bu başarılabilir, ancak ürünlerin farklı ekipler tarafından yapılmış gibi görünme riski vardır ve bu deneyim kullanıcı için gerçekten kafa karıştırıcı olabilir. Conway yasasına karşı çıkıyoruz - müşterilerimiz bir ekibin işinin nerede bittiğini ve diğerinin işinin nerede başladığını söyleyebilir.

Böylece herkesin işini birbirine bağlamaya çalışıyorsunuz - sadece arka uçta değil, aynı zamanda ön uçta da. Apple gibi oyuncuların CX mükemmelliğinin hakim olduğu ekosistem çağında, bu, tüketici alanında neredeyse masa bahisleri haline geldi. Ancak bu, bu sefer mühendislik perspektifinden olmasa da, Efsanevi Bir Adam-Ay kabusu. Bu bir hizmet tasarımı perspektifinden. Tüm bu "uçtan uca" bağlantılı çalışmaya daha fazla insan ekledikçe, her şey ortak çalışmaya dayalı bir taramaya dönüşüyor.

Aşırı gözlemciler ve sahne kapıları yerine araçlar ve çerçeveler kullanarak yukarıda belirttiğim üçüncü düzeltmenin dışında, başka bir tahliye vanası daha var: kasıtlı müşteri deneyimi takasları yapın . Spesifik olarak, diğerlerinden kopuk bir deneyimi (yani ortalamanın altında olan) bir deneyimi serbest bırakmak konusunda nerede rahatız? Riski kabul etmek ve ilerlemek ürün liderinin işidir. Ve böylece, onu sıralamak için bazı kriterler kullanırsınız (belki de uygulamanın yeni, düşük trafikli alanlarını “nakit inekleriniz” ile aynı deneyim standartlarında tutmaz) ve bir karar verirsiniz (örneğin, bitişikte tekrarlama ve cilalama üzerine öğrenme). yenilikler). Bu, elbette, tasarımın ötesine geçer.

Mükemmel bir dünyada güvenlik duvarıyla kapatılmaması gereken çabalar da dahil olmak üzere, güvenlik duvarını seçerek Brooks'un yasasını her zaman kısa devre yapabilirsiniz!

“

Yaptığım yazılımın kimseyi öldürmediğini söyleyerek bunu uyaracağım. Tıbbi bir cihaz yapıyor olsaydım bu yaklaşımı savunmazdım. Ancak bir pazarlama yazılımı şirketinde, personeli büyütmek ve daha hızlı hareket etmek için bir takas olarak uyumsuzluk olasılığını artırdığımı bilerek ekipleri kasıtlı olarak izole edebilirim.

Efsanevi Adam-Ayı'nın benim şirketimde bir gerçeklik olduğunu kabul ettiğim için üzgünüm ve sizinkinden de şüpheleniyorum. Ama yönetilebilir - sonuç bu. Paralelleştirme ve bağımlılık azaltma, bize Efsanevi Adam-Ay'ın neredeyse efsanevi durumunu sınırlayan bir çıkış yolu sunar. Bu nedenle, şirketinizde bir sonraki katı ikilik ortaya çıktığında (daha yavaş gitmek veya beklentilerinizden vazgeçmek için ölçeklendirin), işi nasıl sıralayacağınız konusunda akıllıysanız, yine de büyüyebileceğinizi unutmayın.

Ölçeklemenin Daha Yumuşak Tarafını Unutmayın

Efsanevi Adam-Ay'ı yönetmenin, mühendislerin kara büyü gibi onu çağırmasını engellemeyeceğini unutmayın. İlkeyi yalnızca içinde bir miktar gerçek olduğu için değil, aynı zamanda ölçeklemenin duygusal ve bilişsel bir perspektiften (her zaman) berbat olduğu için çağırıyorlar. Kod yazmak ve müşteri sorunlarını çözmek için para aldığımı düşünüyorsam, yapmak istediğim son şey rutinimi değiştirmek ve yeni insanlarla ve daha büyük bir ekiple nasıl çalışılacağını bulmaktır.

Şirketinizi ölçeklendirirken, ölçekleme ve değişimin acısıyla empati kurmayı unutmayın. Tek bir üye bile ekleyen bir ekip, güven ve kültürel açıdan yepyeni bir ekip haline gelir. İnsanlar bu değişimden bıktı. Bu, Efsanevi Adam-Ay'ı yönetmeye ve hafifletmeye devam ederken, büyümeyi çevreleyen duyguları yönetmeniz gerekeceği anlamına gelir. Belki de en kritik görev budur.

Efsanevi Adam-Ay'a bir ekibin kendi başına güçlü bir şekilde inanması, sonuçlarını gerçeğe dönüştürebilir. Temelde Peter Pan'da uçma inancına eşdeğerdir. Ekip, ölçeklendirmenin onları yavaşlatacağına inanırsa ve değişimi kabul etmezlerse, gerçekten yavaşlayacaklardır.

Bu nedenle, bağımlılıkları yönetmeye çalışırken ve ölçeklendirmeye yardımcı olacak araçları tanıtırken, uygulamaların arkasındaki nedeni açıkça belirttiğinizden emin olun. İnsan-ay sorunlarını azaltan iş ve süreçlerin seçilmesine insanları dahil edin, çünkü onlar değişimin bir parçası olduklarında ve bakış açıları değiştiğinde, ölçeklendirme aniden en azından kültürel olarak mümkün hale gelir.