Sektör· Kültür· Oyun· Hakkımda


17 Aralık 2018·Sektör

Ürün geliştirme kültürü: Takım oluşturmak

Dünya üzerinde her ekip ve ürün için kullanabileceğiniz, birbirinden farklı çok sayıda ürün geliştirme yöntemi bulunuyor. Bu yöntemlerden hangisini kullanacağınıza karar verirken ekibinizi, ürününüzü, ihtiyaçlarınızı ve kapasitenizi göz önünde bulundurmanız çok önemli. Proje yönetiminde kesin başarıya ulaştırır diyebileceğiniz sabit bir yol yok, ekibinize ve isteklerinize uygun şekilde uyarlayabileceğiniz en iyi yöntemi kendi başınıza seçmeniz gerekiyor.

Facebook’un kendisi için kullandığı ürün geliştirme yöntemi, Airbnb için doğru olmayabilir. Bunun sebebi ekibin ve ürünün birbirinden tamamen farklı olması. Bu yüzden de ürün geliştirmede bir yöntem ve metod belirlemeden önce ilk olarak bir kültür inşa etmeniz gerekiyor. Bu kültür ekibinizdeki herkesin benimseyebileceği ve ekibinizin hayat tarzlarıyla bile uyumlu olmalı. Bu kültür şirketinizin insan kaynaklarını etkilemeli, ekibinize birini dahil etmek istediğiniz zaman bu kültür ile ilgili uyumuna dikkat etmelisiniz. Yani artık işe alım süreçlerinizde sadece yeteneğe bakmamanız gerekiyor, ekibiniz ile ne kadar uyumlu çalışacağı da en önemli işe alım koşullarınızdan birisi olmalı.

Spotify ürün geliştirme yöntemini sonradan değiştiren şirketlerden birisi. İlk başta tamamen scrum kurallarına uyarak, scrum master önderliğinde yönetilen bir ekip. Bir süre sonra aslında vizyonun ve prensiplerin, tek düze bir süreç yönetiminden daha önemli olduğunu düşündüler. Kısacası şirket içerisindeki kültürü tamamen değiştirmek istediler. Bunu da “Kurallar iyi bir başlangıçtır ama gerektiğinde onları kırmalısınız” cümlesiyle açıklıyorlar. İlk olarak Scrum Master dedikleri pozisyonu Agile Coach olarak değiştirdiler. Bu küçük bir değişiklik gibi gözükse de aslında çok köklü bir değişikliğin ilk atılan radikal adımlarından. Çünkü bu değişikliğin asıl amacı basit bir pozisyon isim değişikliği değil, biz artık felsefesi ve kültürü olan bir takım olacağız demenin ilk adımı.

Bireysel performans yerine takım olarak hareket etmek

Yazılım şirketlerinin kendi ekiplerini nasıl departmanlara böldüğünü aşağıda basit bir görsel ile anlatmaya çalıştım. Çok yaygın olarak kullanılan bu sistemde her departmanın belli görevleri oluyor ve departman içerisindeki kişiler bu görevlerinin dışına çıkmıyorlar. Örnek vermem gerekirse, bir frontend developer eline gelen tasarımı ekrana döktükten sonra işi devam ettirtmek üzere backend developer’a gönderiyor. Bu işlemden sonra ya da önce süreci takip etme gereği duymuyor. Yani yapacağı iş daha tasarım aşamasındayken, frontend developer tasarım sürecinde bulunmuyor. Ya da sürecin en başında, bu özelliğin neden geliştirildiği ile ilgili yapılan toplantıda olmadığı için bu özelliği neden yaptığını bile bilmiyor. Kısacası bir makine gibi eline gelmiş işi, sorgulamadan sadece kendi görevini yapacak şekilde yapıp bir sonraki departmana gönderiyor. İşin neden yapıldığını, nasıl bir ihtiyacı gidereceğini, yaptıktan sonra bu özelliğin nasıl bir dönüşü olduğunu bilmiyor. Günün sonunda, genele bakıldığında düzgün bir işleyiş ile istediğiniz özelliği elde etmiş gibi gözükseniz bile ürün tarafına ve sürekliliğe baktığımızda, özelliğin amacından ve sonuçlarından haberi olmayan, sadece bu özelliği geliştiren, sorgulamayan, düşünmeyen, motive olmamış ve ürünü sahiplenmeyen bir ekip yaratmış oluyorsunuz.

Yukarıdaki görselde olduğu gibi çalışanlar dikey olarak gruplanmış. Bu sayede her kişi kendi özelliklerindeki ve aynı yeteneğe sahip kişiler ile çalışıyor. Alışık olduğumuz kurumsal şirketlerde de kullanılan departman mantığının aynısı.

Aşağıda göreceğiniz görselde ise Spotify’ın kendi bünyesinde kullandığı takım kavramı bulunuyor. Görselden de anlayabileceğiniz gibi burada departman içerisinde aynı yeteneklere sahip kişiler değil, bir takım içerisinde birbirinden bağımsız yeteneklere sahip insanlar mevcut. Bu sayede bir takım içerisinde birbirinden farklı düşünceler ve farklı uzmanlıklar bulunuyor. Böyle bir takım kurulmasının avantajlarından bazıları;

  • Herkes kendi alanında uzman olduğu için bir ürün üzerinde geliştirme yapılırken tüm departmanlara uyumlu bir şekilde bu özelliğin geliştirilmesi
  • Farklı bakış açılarından ortaya çıkabilecek farklı fikirler
  • Bir ürün ya da özelliğin geliştirme sürecine herkesin baştan sona dahil olması
  • Ürün ve özelliği daha çok sahiplenme
  • Sahiplenmeye odaklı ürün ya da özellik üzerinde daha özverili çalışma
  • Kişilerin bireysel olarak suçlanacağı hatalar yerine takım olarak hatayı kabullenme ve daha hızlı bir şekilde çözüm üretme
  • Ortaya çıkan ürün ya da özellik başarılı ise bunu takım olarak yapmanın verdiği motivasyon artışı ve buna bağlı olarak hep daha iyisini isteyerek sürece devam etme

Spotify Autonomous Squad adını verdiği bu sisteme geçiş yaptı. Takımlarını bir müzik grubuna benzetiyorlar. Herkes farklı bir nota çalıyor ve bu notaların sonunda bütün bir şarkıyı elde ediyorsunuz. Spotify tarafından baktığımızda bu müziğin içerisindeki farklı notalar; arama bölümü, keşfet bölümü, listelerin bulunduğu bölüm ya da player’ın olduğu bölüm diyebiliriz. Kısacası Spotify, uygulama içerisindeki yüzlerce farklı özelliği tek tek bölüp, her bir bölümü tek bir takıma veriyor. Takımlar tüm uygulama yerine sadece kendi sorumluluklarında oldukları kısımlarda çalışıyorlar. Örneğin; keşfet bölümünden sorumlu takım, Dünya üzerindeki en iyi keşfet bölümünü yapmaya çalışıyor. Aynı şekilde player üzerinde çalışan ekip yalnızca player’ın çalışmasıyla ilgileniyor. Bu sayede tüm takım bir uygulama üzerinde dağınık bir şekilde çalışmak yerine belirlenmiş küçük bir bölüm üzerinde tüm farklı departmanlar ile takım olup, daha ayrıntılı bir şekilde çalışıyor. Ayrıca takımların içerisinde data, marketing gibi ekipler bile bulunduğu için geliştirdikleri bir özelliği test edip, sonuçları görüp sonuçlara uygun şekilde tekrar geliştirmeye devam edebiliyorlar. Yani yaptıkları bir özellikte işleri bittikten sonra bu özelliği uzay boşluğuna yollamıyorlar, sonuçlarını görüp, nedenleri anlayıp tekrar çalışmaya devam ediyorlar. Bu sayede de çözüm odaklı bir ekip ortaya çıkmış oluyor.

Bu takımlar yalnızca özellik geliştirmesine dayalı seçilmiyorlar tabii ki. Bazı takımların tek görevi uygulama üzerinde ortaya çıkan hataları gidermek, bazı takımlar sadece kullanıcılar üzerinde uygulanacak olan A/B testine yoğunlaşıyor. Yani aklınıza gelebilecek her türlü özelliği ve ürün içerisindeki görevi tüm takımlara tek tek bölebiliyorsunuz. Bu da olabilecek en uygun çözümlerle ve en efektif çalışma şekliyle ortaya çıkmış bir ürün anlamına geliyor.

Uyum ve otonomi

Görsel Spotify’dan alınmıştır.

Takım oluşturmanın ve takım olmanın mantığını ve sebeplerini iyice öğrendiğimize göre şimdi sıra geldi bu takımların nasıl bir yönetim sürecine sahip olması gerektiğine. Öncelikle bunun için yukarıdaki -bana göre hayatım boyunca gördüğüm en güzel görselleştirilmiş matrixlerden birisi- görseli incelemenizi istiyorum.

Burada da görebileceğiniz gibi bir ürün üzerinde çalışan birbirinden farklı karaktere sahip, proje ve ürün yöneticileri bulunuyor.

  • Lider söyler, takım takip eder: High Alignment – Low Autonomy kısmında gördüğümüz bu lider sorunu ve çözümü kendisi belirler. Takım ise sadece kendisine söylenen görevleri yapmakla mükelleftir. Bu yöntem bizim ülkemizde 10 şirketten 9’unda gördüğümüz yöntem diyebiliriz. Ortaya bir ürün çıksa da çalışanların motivasyonu açısından aslında oldukça yanlış olan yöntemlerden birisi. Ayrıca bu süreçte belki de bir çalışandan gelebilecek daha güzel bir çözümü de bu yönetim şekliyle ortadan kaldırmış oluyorsunuz.
  • Belirsizlik ve yönetimsizlik: Low Alignment – Low Autonomy bölümündeki bu yönetim şekline sanırım yönetim şekli demek bile doğru olmaz. Çalışanların hiç bir şeyden haberi olmadığı, karar mekanizmasının çalışmadığı, herhangi bir yönetim ya da çalışan disiplininin olmadığı yerdir burası. Bu şekilde işleyen süreçler tahmin edebileceğiniz gibi hiç bir zaman başarılı olamayacaktır.
  • Siz işinizi bilirsiniz: Low Alignment – High Autonomy olarak tanımlanan yönetim şekli ise tüm iplerin takıma bırakıldığı, ürün ya da proje yöneticisinin ortalıkta gözükmediği yönetim şekli. Burada çalışanlar tahmin edebileceğiniz gibi oldukça mutlu çünkü herhangi bir zorunlulukları olmadan, üzerinde düşünmeleri gereken ve onları stres sahibi yapacak herhangi bir sorun olmadan çalışabiliyorlar. Fakat ne üzerinde çalışıyorlar, nasıl bir plana sahipler bunu da bilen yok. Böyle bir ortamda başarılı bir ürün geliştirmek, başarılı bir şekilde geliştirseniz bile bu ortamı uzun süre boyunca korumak imkansız gibi duruyor.
  • Hepimiz bir takımız, biz başarırız: Konumuzu tamamlayacağımız yönetim şekline geldik. High Autonomy – High Alignment bölümünde gözüken bu süreç sayesinde lider kollarını sıvayıp takım ile birlikte ortadaki bir sorun için çözüm bulmaya çalışır. Bu çözüm bulma sürecinde kendisinin söz hakkı diğer takımdaki her üyenin sahip olduğu söz hakkı kadardır. Bu sayede tüm herkesin tartıştığı, ortak bir çözüm bulmaya çalıştığı bir ortam elde edilir. Bunun avantajları oldukça fazla. Yukarıda takım olma kısmında da bahsettiğim gibi, bu sayede tüm takım ürünü daha çok sahiplenir, herkesin farklı bakış açılarıyla soruna yaklaşmasından dolayı daha sağlıklı çözüm fikirleri ortaya çıkar ve her şeyden önemlisi takım olarak bir şeyleri başarabilmenin motivasyonuna sahip olunur.

Tahmin edebileceğiniz gibi takım kurmak kadar bu takıma liderlik edebilecek kişiyi de iyi seçmemiz gerekli. Kendisini takımdan üstün gören ya da tüm görevleri takıma bırakıp kendini ortada pek fazla göstermeyen, sorumluluk almaktan kaçınan bir lider hem takıma hem de ürüne oldukça fazla zarar verir. Türkiye’deki en kötü yanlış anlamalardan birisi proje yöneticisi ya da ürün yöneticisinin takımın içerisindeki herhangi birinden kendini yukarıda görmesi. Böyle bir şey yok, eğer siz proje ya da bir ürün yöneticisiyseniz, adından da anlayacağınız gibi insanların yöneticisi değil, ürünün ya da projenin yöneticiliğini yapmalısınız. Bunu yaparken de takımın motivasyonunu ve çözüm odaklı bakış açınızı hiç bir zaman kaybetmemelisiniz.

Etiket: ······