Yol Haritası Kronik Olarak Raydan Çıktığında Nasıl Yön Düzeltilir?

Transkripti Okuyun:

 

Podcast’lerimizin transkripsiyonunu bir yazılım programı kullanarak deniyoruz. Bot her zaman yüzde 100 doğru sonuç vermediği için lütfen yazım hatalarını mazur görün.

 

Hannah Clark: Ürün yol haritaları, gerçek yol haritaları gibi gecikmelerle karşılaşmaya mahkûmdur. Bazı gecikmeleri öngörebilir ve bunlara göre plan yapabilirsiniz; bazıları ise birdenbire ortaya çıkar. Ancak çoğu zaman bir sapma yolu bulup yeniden doğru rotaya girebilirsiniz. Peki ya endişe verici bir örüntü fark ederseniz? Hedefler kaçırılıyor, zaman çizelgeleri kronik olarak uzuyor ve tüm yol haritası sürekli olarak raydan çıkıyor gibi görünüyorsa ne yaparsınız?

Bugünkü bölümde, Public Consulting Group’ta Ürün Yönetimi Direktörü olan Michael Pierce’ı dinleyeceksiniz. Pierce, sürekli olarak geride kalan bir yol haritasının, işletme yapısı ile ürün ekibinin yapısı arasındaki uyumsuzluğun belirtisi olabileceğini savunuyor. Dolayısıyla hedeflerinizin ve girişimlerinizin neden öngördüğünüz şekilde sonuçlanmadığını anlamakta zorlanıyorsanız, ihtiyacınız olan yön düzeltmesi bu olabilir. Başlayalım.

Merhaba dinleyiciler. Ürün Yöneticisi podcast’ine tekrar hoş geldiniz. Bugün Public Consulting Group’ta Ürün Yönetimi Direktörü olan Michael Pierce ile birlikteyim. Michael, bugün bize katıldığınız için çok teşekkür ederim.

Michael Pierce: Evet. Teşekkürler Hannah. Burada olacağım için çok heyecanlıyım.

Hannah Clark: Michael, bize biraz geçmişinizden ve şu an bulunduğunuz noktaya nasıl geldiğinizden bahsederek başlayabilir misiniz?

Michael Pierce: Elbette. Birçok ürün çalışanı gibi ekonomi bölümünden mezun olarak başladım, değil mi? Hepimizin farklı geçmişleri var. Bir sigorta aracılık şirketinde çalışıyordum. O dönemde bir arkadaşım bana The Lean Startup’ın bir kopyasını verdi. Kitabı okumaya ve iş yerindeki verimsiz çeşitli süreçleri düşünmeye başladım. Bu, belki de oldukça olgunlaşmamış bir ürün bakış açısının başlangıcıydı.

Sonunda oldukça gelişmiş bir VBA programı oluşturdum, kendime Visual Basic kodlamayı öğrettim ve işleri otomatikleştirmeye başladım. Ürün yönetimiyle ilgilenmeye başlamamın temeli de bu oldu. O zamanlar ürün yönetimi bugünkü kadar yaygın değildi.

Kullanıcılarla konuşmak, neye ihtiyaç duyduklarını anlamak, bir çözüm oluşturmaya çalışmak ve süreç boyunca onlarla iletişimde kalmak gibi şeylerden bahsediyorum. Kısa bir süre sonra ilk girişimimi kurdum. Su sporları alanındaydı. Birçok havuzla çalıştık. Yaşadığım yer olan Denver, Colorado’daki Denver şehri müşterilerimizden biriydi. Bu bizim için çok heyecan vericiydi, ancak ürün yolculuğumun gerçek başlangıcı buydu.

Çünkü kullanıcılarla konuştuk ve bir yol haritası oluşturduk. Ürün yolculuğumun henüz başında olduğum için neredeyse şimdi, sonra, daha sonra tarzında bir yapı kullanıyorduk. Ancak bu, o alana harika bir giriş oldu. Yıllar ilerledi, bir satın alma yoluyla işe alım süreci yaşadım ve Boston’da kurumsal bir şirkette çalışmaya başladım. Bu harika bir deneyimdi. Kısa süre sonra mevcut şirketim Public Consulting Group’a Ürün Yönetimi Direktörü olarak katıldım.

Hannah Clark: Harika. Kariyeriniz boyunca birkaç ekiple çalıştınız; bazen ekip üyesi oldunuz, ancak çoğunlukla ekiplere liderlik ettiniz. Genel olarak ürün ekiplerinde ortak olan ve karşılaştığınız zorluklardan bazıları nelerdi?

Michael Pierce: Bence birçok ürün çalışanının her zaman fark etmediği büyük bir zorluk var. Şu anda çalıştığınız şirkete bakmanız ve şirketi iki büyük kategoriye ayırmanız gerekiyor. Şirket satış odaklı mı? Finans odaklı mı? Pazarlama odaklı mı? Hepimiz bunun harika örneklerini gördük.

HubSpot’a bakarsanız, pazarlama açısından kesinlikle pazarlama odaklı bir şirket olduğunu görürsünüz. Zoom veya Slack gibi bir şirkete baktığınızda ise güçlü ürün odaklı büyüme örnekleri ve ürün odaklı liderlik görürsünüz. Bu nedenle ürün ekiplerinin şirketlerine bakıp şunu düşünmesi çok önemli: CEO satış departmanıyla sık sık görüşüyor mu ve aralarında çok yakın bir ilişki var mı?

Ya da şirket liderlerinden bazıları operasyon, satış veya başka bir işlevden mi geldi? Bu, şirketin nasıl çalıştığına dair bir ipucu olabilir. Ürün ekiplerinin şirket kültürünü gerçekten anlamak için yapması gereken diğer önemli şey, büyük kararların nasıl alındığını düşünmektir.

Kararlar tamamen yukarıdan aşağıya mı alınıyor? Üst düzey liderlik bazı kararları alıp bunları diğer yöneticiler ve idarecilerle mi paylaşıyor? Süreç çok demokratik mi? Şirketlerin büyük kararları nasıl aldığına dair yapıyı anlamak da gerçekten önemli.

Bu iki şeyi biliyorsanız, yani şirketin satış veya finans odaklı olduğunu ve karar alma yapısının nasıl işlediğini anlıyorsanız, ürün departmanının genel tabloya nasıl uyduğunu ve içinde bulunduğu dinamikleri nasıl yönetebileceğini anlamasına yardımcı olabilirsiniz.

Çünkü tüm bu bilgileri görmezden gelir ve bir ürün departmanı olarak gününüzü sıradan şekilde geçirirseniz, kendinizi birçok engel ve zorlukla karşı karşıya bulabilirsiniz. Bunun nedeni, kurum içindeki diğer kişileri etkilemek için kendinizi doğru şekilde konumlandırmamış olmanızdır.

Hannah Clark: O zaman bunu bir örnekle ele alalım. Ürün ekibinin kendisini nasıl gördüğü ile işletmenin gerçekte nasıl işlediği arasındaki uyumsuzluk, ilerleyen dönemlerde ne gibi sorunlara yol açabilir?

Michael Pierce: Elbette. Soruyu doğru anladıysam, buna örnek olarak bugün ürün odaklı büyüme etrafında çok fazla enerji olmasını verebiliriz.

Ben ürün odaklı büyümeyi gerçekten seviyorum; biraz taraflı olabilirim. Ancak ürün departmanı ürün odaklı büyümeye büyük önem veren bir şekilde çalışırken şirket gerçekte satış odaklı büyümeyi benimsiyorsa bu, girişimlerin finanse edilmesi ve farklı departmanlardan destek alınması açısından büyük bir uyumsuzluk yaratacaktır.

Bu nedenle bir departman ve işlev olarak diğer işlevlere kıyasla bulunduğunuz yeri fark etmeniz ve ekip olarak atacağınız adımları buna göre hesaplamanız çok önemlidir.

Hannah Clark: Önceliklendirme ve bununla birlikte gelen zorluklardan biraz bahsedelim. Büyüme modeliniz ne olursa olsun, bunun her ürün ekibinin bir ölçüde zorlandığı bir konu olduğunu düşünüyorum. Çalıştığınız şirketlerde önceliklendirme konusunda ne gibi zorluklar gördünüz?

Michael Pierce: Aklıma iki şey geliyor. Bunlardan biri, inşa ettiğimiz şeyle ilgili ideal durum veya istek listesi zihniyeti ile gerçeklik arasında genellikle bir boşluk olmasıdır.

Önceliklendirmenin zorluklarından biri, yönetim kurullarıyla, halka açık şirketlerle veya yatırımcılarla çalışırken ortaya çıkar. Özel sermaye şirketlerinin sahip olduğu bazı şirketlerde çalıştım. Büyük, eğlenceli ve çekici özelliklerle dolu bir yol haritasına sahip olmanız konusunda üzerinizde çok fazla baskı olabilir.

Buradaki zorluk, herkesi gerçekliğe geri döndürmek, ancak bunu kendilerini iyi hissetmelerini sağlayacak şekilde yapmaktır. Önceliklendirme hakkında konuştuğunuzda, öncelikle daha üst düzey unsurlar konusunda ortak bir anlayışa ulaşmanız gerekir. Önceliklendirme ancak vizyonunuzu ve yönünüzü bildiğinizde yapılabilir.

Etkili bir önceliklendirme için bu üst düzey unsurlara sahip olmanız gerekir. Belki de diğer tuzak budur. Paydaşları ve yöneticileri vizyonumuz, başarıyı nasıl ölçeceğimiz, yönümüz, temel performans göstergelerimiz ve hedeflerimiz konusunda hizaladığınızda sağlıklı bir önceliklendirme süreci yürütmek çok daha kolay olur.

Böylece şişirilmiş istek listesi zihniyetinden uzaklaşıp daha net bir yapıya geçebilirsiniz. Çok sayıda madde olabilir, ancak bunlar iyi tanımlanmıştır. Kurum olarak dört büyük destan ya da girişimin, CEO’nun ve kurumun gerçekten önem verdiği iki hedefle güçlü biçimde ilişkili olduğunu biliriz. Ben önceliklendirme sorununu en azından bu şekilde düşünüyorum.

Hannah Clark: Önceki bir konuşmamızda, bir şirket hakkında analiz yaptığınız ve bazı hedeflerin neden tutmadığını belirlemenizin istendiği bir örnekten bahsetmiştiniz. Hangi şirket olduğunu söylemeyelim; ancak bu konuyu ve örneği biraz anlatabilir misiniz?

Michael Pierce: Elbette. Şirket, yol haritasındaki maddelerin büyük bir bölümünü tamamlayamıyordu ve nedenini öğrenmek istiyordu. Bu tamamen masum ve iyi bir soruydu. Bir ürün çalışanı olarak yol haritasını, başka birçok sürecin sonucu olarak görüyorum. Yani büyük bir karmaşık etkileşim ve girdiler kutusunun çıktısıdır.

İlk yaptığım şeylerden biri, katmanları geriye doğru inceleyerek yol haritası maddelerinin yüzde 50’sini tamamlayamıyorsak temel nedenlerin neler olduğunu anlamaya çalışmaktı. Daha derine inmeden önce sorduğum sorulardan biri şuydu: Çok fazla yol haritası maddemiz mi var?

Örneğin 2.000 saatlik bir yol haritanız, ancak yalnızca 1.000 geliştirici saatlik kapasiteniz varsa bu maddelerin yarısını tamamlayamayacağınız açıktır. Ancak görebildiğim kadarıyla bu yol haritasını uygulamaya yetecek kadar mühendis, kalite güvence çalışanı ve destek personeli vardı.

Bunun üzerine şirket olarak neden hâlâ bu maddelerin çoğunu tamamlayamadığımızı anlamak için daha derine indim. Analizimi yaptığımda birkaç şey keşfettim. Bunlardan biri, geliştirme ekiplerinin birden fazla ürün arasında paylaştırılmış olmasıydı. Ürün çalışanı olarak iyi bir yol haritası oluşturmanın zorluğu, elinizde sabit kaynakların bulunduğundan emin olmanızdır.

Örneğin bu üründe çalışan beş mühendisiniz vardır ve haftada 40 saat çalışırlar. Dikkat dağınıklıkları, Slack mesajları ve e-postalar nedeniyle haftada belki 30 saat verimli olabilirler. Bu zamanı inceleyip geleceğe dönük bir tahmin yapabilir ve yol haritasına ulaşma ihtimalimizin yüzde 80 veya yüzde 90 olup olmadığını hesaplayabilirsiniz.

Ancak paylaşımlı geliştirmede büyük sorun şudur: Başka bir üründe bir kriz çıkarsa veya ürün portföyünüzdeki ürünlerden biri için büyük bir sözleşme imzalarsanız, bu durum hem şirketin genel yol haritasını hem de ilgili ürünün yol haritasını ciddi biçimde raydan çıkarabilir. Bulduğum temel nedenlerden biri paylaşımlı geliştirmeydi.

Bulduğum diğer büyük temel neden ise planlanmamış işlerin ve hataların yüksek hacmiydi. Yol haritası oluşturulduğunda bu işlerin tamamlanabileceğine dair yüksek bir güven vardı. Ancak ekipler sorunlarla karşılaştığında, örneğin yükseltilmesi gereken büyük bir bağımlılık olduğunda, büyük bir sözleşme kazanıldığında kaynakları başka yere çekmek gerektiğinde veya bir kod üretime alındıktan sonra hata bulunduğunda, tüm bunlar yol haritasının tamamlanmasını raydan çıkarabilir.

Ürün çalışanları olarak dışarıda çok fazla değişken olduğunu biliyoruz. Bu nedenle hangi değişkenlerin sabit, hangilerinin dinamik olduğunu anlamaya ve ardından üretim planını buna göre oluşturmaya çalışırız. Ancak farklı değişkenlerin sayısını artırdıkça, o çeyreği veya mali yılı başarıyla tamamlama olasılığınızı azaltırsınız.

Hannah Clark: Bu yalnızca yol haritasında bulunanları konuştuğumuz anlamına geliyor. Bunun inovasyon veya sırada ne olduğu konusunda yaratabileceği sorunlardan henüz bahsetmiyoruz.

Michael Pierce: Doğru.

Hannah Clark: Peki yol haritasını nasıl koruyabiliriz? Yol haritasını uygulamak için ihtiyaç duyduğumuz tüm zamanı hesaba kattık; ancak gelecekte yenilik yapmak, yeni özellikler oluşturmak ve satış ekibinin belirli bir müşteri için yapılmasını istediği özelliklere yanıt vermek için ihtiyaç duyacağımız zaman da var. Yol haritasını ve bu zamanı nasıl koruyabiliriz?

Michael Pierce: Bence bu harika bir soru. Ürün çalışanına önereceğim ilk adım, geçmiş çeyreklere bakarak klasik ifadeyle “dünün hava durumu” hakkında zihninde iyi bir temel oluşturmaktır. Geçen çeyrekte hatalar yüzde 20, yeni satış özellikleri talepleri yüzde 20 ve yenilikçi denemeler yüzde 10 oranındaysa, gelecekteki yol haritalarınızı tahmin etmek için bunların toplamını kullanabilirsiniz.

Yol haritası konusunda kurum olarak hizalanmanın iyi bir yolu, yol haritasının dengeli bir beslenme düzeni olması gerektiği fikrini yaygınlaştırmaktır. Geçmiş verilere dayanarak yeni özelliklere yüzde 40 ayırabilirsiniz. Hatalara yüzde 10 veya yüzde 15, gelebilecek büyük bir satış talebine de yüzde 20 ayırabilirsiniz.

Hangi tür işlerin hangi oranlarda yapılması gerektiğine dair güzel bir oran oluşturabilirsiniz; tıpkı bir beslenme düzeni gibi. Ürün çalışanları için iyi bir ilk adım, doğru oranların bulunduğundan ve bunun paydaşlara iletildiğinden emin olmaktır.

Böylece mühendislerin zamanının yüzde 10’u ilginç bir denemeye veya geleceğe dönük, daha özgür bir özelliğe ayrıldığında paydaşlar hazırlıksız yakalanmaz. Ekipler de saygılı bir şekilde hayır deme konusunda daha fazla yetkiye sahip olur. “Bu özelliğe bir ek düzenleme yapmayı çok isterdik; ancak bu çeyrekte kapasitemizin yüzde 10’unu gelecek yıl satışlara gerçekten yardımcı olabilecek yeni bir işlevi keşfetmeye ayırmaya kararlıyız” diyebilirler.

Yine her şey beklentilere dönüyor. Ekipler ve ürün çalışanları için üst yönetimle veya farklı paydaşlarla ilişkilerde bunun önemli olduğunu düşünüyorum.

Hannah Clark: Ekiplerden söz etmişken, ekiplerin tasarlanma biçimi ile önceliklendirilen ve sunulan işler arasındaki ilişki nedir?

Michael Pierce: Bu, başlangıçta konuştuğumuz ürün odaklı veya satış odaklı yapı konusuna geri dönüyor. Ekiplerin tasarlanma biçimine kurum kültürüne göre bakabilirsiniz.

Kurumun çok saldırgan bir satış kültürü varsa, bunu olumlu anlamda söylüyorum; yani çok sayıda yeni iş kazanmaya çalışıyor ve bu konuda büyük bir enerji varsa, bu durum ekiplerin nasıl tasarlandığını belirli ölçüde etkiler. Çünkü daha fazla özellik geliştirme işi yapmanız gerekebilir.

Ayrıca müşteriler için özelleştirme yapan özel ekiplere sahip olmanız gerekebilir. Ekip yapısının büyük bölümü, kuruluşun veya şirketin satış, finans ya da ürün öncelikli düşünme biçimine göre doğal olarak şekillenir. Yeni iş veya sıfırdan oluşturulan işlevsellikle ilgili düşünce ve değerleri de bunu etkiler.

Tüm bunlar bir ekibin nasıl tasarlanacağını etkileyebilir. Burada konuşulabilecek başka bir konu da işi yürütmek için hangi yapıya sahip olduğunuzdur. Sürekli Çevik yöntemden söz ediyoruz. Geçmişte daha fazla Şelale yöntemi kullanan şirket vardı ve firmaların örgütlenebileceği çeşitli başka yollar da bulunuyor.

Bu nedenle ekip tasarımındaki bir diğer önemli konu, bu ortamı anlamaktır. Çevik yaklaşımı temel alan bir kültüre mi sahibiz? Kısmen Şelale yaklaşımını mı kullanıyoruz? Tüm bunlar ekibin yapısını etkiler. Ancak bunu anladığınızda bir ürün çalışanı olarak boşlukları gördüğünüz yerde savunuculuk yapabilirsiniz.

“Geçmişte Şelale yaklaşımını yoğun biçimde kullandığımızı anlıyorum. Pazara sunacağımız yeni bir ürün var. Burada Çevik bir süreç kullanmayı veya paylaşımlı mühendislik ekibi yerine özel bir mühendislik ekibine geçmeyi deneyelim” diyebilirsiniz. Bu bağlamsal bilgiye sahip olmak, ürün ekipleri için gerçekten güçlendiricidir.

Hannah Clark: Daha önce, şirketin ihtiyaç duyduğu çalışma biçimine uyum sağlamak için bir ekibi yeniden yapılandırmayı denemeniz gereken böyle bir deneyim yaşadınız mı?

Michael Pierce: Evet, kesinlikle. Son çalıştığım şirket Boston merkezli bir özel sermaye şirketiydi. Beni sıfırdan bir ürün departmanı kurmam için işe aldılar.

Bunun bir parçası olarak tüm ekiplerin nasıl çalıştığına ve nasıl organize edildiğine baktım ve analiz ettim. Şirkette birkaç farklı ürünümüz vardı. Yapı bir bakıma Şelale yaklaşımı ile dağınık bir çalışma biçiminin karışımıydı. Her şeyi ayrıntılı biçimde incelediğimizde ve şirket sahipleriyle CEO’yla konuştuğumda, ekiplerin nasıl çalıştığını yeniden yapılandırma fırsatı olduğunu söyledim.

Ekipleri, tüm ürün portföyünün değerine katkıda bulunacak küçük gruplar hâlinde yeniden yapılandırma fırsatı vardı. Bu harika bir deneyimdi çünkü tüm ekiplerde Çevik yaklaşımı uygulamaya koyma fırsatı yakaladık. Platform ekipleri ile doğrudan ürünler üzerinde çalışan ekipleri birbirinden ayırarak farklı grupları kümelendirdik.

Ayrıca bazı çalışanları standart bir hizmet olarak yazılım teklifindeki klasik ürün yöneticisi yerine daha teknik ürün yöneticileri olacak şekilde güçlendirdik.

Bir ürün çalışanı olarak yapılandırmanın bütününe bakmak, ekipleri en iyi şekilde yapılandırma konusunda önerilerde bulunmak ve öncesiyle sonrasını ölçmek harika bir fırsattı. Günlük toplantıların ve sprint gösterimlerinin verimliliği artırdığını gördüm. Tüm bunların kurum üzerinde çok olumlu ve anlamlı bir etkisi oldu.

Ürün çalışanları olarak isteyebileceğimiz en iyi şey, bir etki yaratabilmek ve bu etkiyi ölçebilmektir.

Hannah Clark: Kesinlikle. Bu deneyimi yaşamışken, özellikle liderlerin ekiplerini yeniden yapılandırmaya başlamanın veya bunu düşünmenin iyi bir fikir olabileceğini gösteren hangi uyarı işaretlerine dikkat etmesini önerirsiniz?

Michael Pierce: Evet, kesinlikle. Uyarı işaretlerinden biri, bu konularla ilgili veri toplamanız gerektiğidir. İş fikrinden üretime geçmenin ne kadar sürdüğüne bakmak bunlardan biridir. Bu süre normale kıyasla çok uzunsa bir sorun olabilir.

Bunu değerlendirmek zor olabilir çünkü bu konularla ilgili yayımlanmış standartlar her zaman bulunmaz. Ancak daha küçük bir yeni özellik geliştirme işinin üretime alınmasının iki hafta sürdüğünü düşünelim. Bu oldukça iyidir. Ortalama sprint döngüsü iki veya üç hafta olduğundan, bir ürün çalışanı olarak bunu mutlaka bir uyarı işareti olarak görmezsiniz.

Fakat küçük bir işlev parçasına bakalım. Diyelim ki bu iş 40 geliştirici saati sürüyor, ancak üretime alınması beş, altı, yedi veya sekiz hafta alıyor. Bu durumda bana göre bir uyarı işareti vardır. İşlerin yapılandırılma biçiminde bir sorun olabilir; kalite güvencede bir darboğaz veya ilgili destana ya da işlevsel gereksinim belgesine doğru paydaşların katkı sağlamasında bir tıkanıklık olabilir.

Tüm sistemi girdileri ve çıktıları olan bir kutu gibi düşünürseniz, bunlar çıktıların normal bir temel beklentiyle uyuşmadığını gösteren işaretlerdir.

Hannah Clark: Peki ekipleri yeniden yapılandırmanın başarısını nasıl ölçersiniz?

Michael Pierce: Bunu yapmanın çeşitli yolları var. Klasik yöntemlerden biri ekibin çıktısına bakmaktır. Daha kısa sürede son müşterilere daha fazla değer artışı sunuyorlar mı? Bir diğer klasik yöntem ise fikirden üretime geçiş süresini azaltıp azaltmadığımıza bakmaktır.

İşi A noktasından B noktasına taşırken daha hızlı ve daha Çevik hâle geliyor muyuz? Genellikle gözden kaçan başka bir yöntem de bire bir görüşmeler yapmak, çalışanların durumunu kontrol etmek ve bulguları yöneticilere raporlamaktır. Bunun yanı sıra yeniden yapılandırma öncesi ve sonrasında ekip üyelerinin nasıl hissettiğini ölçen klasik bir anket de uygulanabilir.

Farklı yönlere daha az çekildiklerini, yani bağlam değiştirme yüklerinin azaldığını düşünüyorlar mı? İşi tamamlamak için doğru kişilerle birlikte karar alma konusunda kendilerini daha yetkin hissediyorlar mı? Bunların hepsi yeniden yapılandırmanın işe yarayıp yaramadığını ve olumlu sonuçlar doğurup doğurmadığını gösteren iyi göstergelerdir.

Hannah Clark: Bunu toparlayacak olursak, ekibi yeniden yapılandırma deneyiminizin sonuçları ne oldu?

Michael Pierce: Gerçekten harika bir soruydu. En başından itibaren belirgin olan şey, ekibin yürüttüğü işle ilgili sorular ve belirsizlikler konusunda ortak bir anlayışa sahip olmasındaki boşluğun büyük ölçüde azalmasıydı. Çünkü ben şirkete gelmeden önce haftada bir kez toplantı yapıyorlardı.

Yeniden yapılandırmadan sonra ise günlük toplantılar yapmaya başladık. Böylece ekip, sorularının her sabah doğru kişiler tarafından yanıtlanmasını sağlayabildi. Bu, iş çıktısını artırdı ve geliştiricilerin kaygısını da azalttı; çünkü soruların yanıtını bir hafta boyunca beklemek zorunda kalmıyorlardı.

Bir şeyden emin değillerse, çoğu durumda yanıtı almak için yalnızca ertesi günü beklemeleri yeterliydi. Her durumda böyle olmasa da çoğu durumda bu gerçekleşti. Bunun da ekibin kurum genelinde çok daha fazla desteklendiğini hissetmesini sağladığını düşünüyorum.

Hannah Clark: Son olarak, üst düzey paydaşların desteğini almaktan biraz bahsedelim. Yeniden yapılandırmanın başlangıçta ihtiyaç duyduğu yatırımın karşılığını vereceğini kanıtlamak veya buna dair bir gösterge sunmak için hangi yöntemler sizin için başarılı oldu?

Michael Pierce: Yeniden yapılandırmanın önemli bir bölümü, yazılım geliştirme sürecinde A noktasından B noktasına gelene kadar yaşanan tüm karmaşıklıkları düşünmektir. Buna kara kutu demekten hoşlanmıyorum ama yazılım geliştirme karmaşıktır. Her türlü dönemeç ve değişken bulunur.

Yeniden yapılandırmayı düşünürken yöneticiler ve üst düzey paydaşlarla gerçek sonucun ne olduğu hakkında konuşmak önemlidir. Kurum için hangi sonuçları elde etmeye çalışıyorlar? Hedefler nelerdir? Hangi temel sonuçları yönlendirmeye çalışıyorlar?

Bunları işin nasıl organize edildiğinin etkililiği için bir kıyas noktası veya temel olarak kullanabilirsiniz. Aynı durum genel olarak işi ölçmek için de geçerlidir. Önemli olan temel noktaların nerede olduğunu bilmek ve bunlara karşı ölçüm yapmaktır. Böylece hedefe ne kadar yaklaştığınızı görebilirsiniz.

Hannah Clark: Harika. Michael, bize katıldığınız için çok teşekkür ederim. The CPO Club’a katkıda bulunduğunuzu biliyorum. Çalışmalarınızı TheProductManager.com adresinde okuyabilirsiniz. İnsanlar sizi internette başka nerelerde bulabilir?

Michael Pierce: Beni internette bulmanın en iyi yolunun LinkedIn olduğunu söyleyebilirim. Dijital minimalizm yanlısıyım, bu nedenle yalnızca LinkedIn kullanıyorum. Oradan bana mesaj gönderirseniz podcast’in tüm dinleyicileriyle sanal bir sohbet yapmaktan memnuniyet duyarım.

Hannah Clark: Harika. Zaman ayırdığınız için çok teşekkür ederim; görüşlerinizden gerçekten yararlandım.

Michael Pierce: Ben teşekkür ederim Hannah.

Hannah Clark: Bizi dinlediğiniz için teşekkürler. Daha fazla harika görüş, nasıl yapılır rehberi ve araç incelemesi için theproductmanager.com/subscribe adresinden bültenimize abone olun. Bunun gibi daha fazla sohbeti, podcast’lerinizi dinlediğiniz her yerde The CPO Club’a abone olarak dinleyebilirsiniz.