Çevik Ürün Yönetimi Nedir: Süreçler ve Roller Rehberi

Çevik ürün yönetimi hakkında pek çok içerik, rehber, ders kitabı, kurs ve sertifika mevcut. Açıkçası bunların hepsine ihtiyacınız yok.

Özünde Çevik ürün yönetimi, basit ve insan odaklı bir felsefe etrafında şekillenir. Çevikliğin oluşturduğu süreçlerin çoğu basit ve anlaşılması kolaydır. Ancak karmaşıklık, yanlış anlaşılan beklentiler, roller ve süreçler nedeniyle ortaya çıkar.

Bu rehberde şunları ele alacağız:

Çevik ürün yönetimini, felsefesini ve şekillendiği süreçleri inceleyeceğiz.
Tipik bir Çevik ürün geliştirme ekibini oluşturan rolleri, bu rollerin ne olduğunu ve nasıl iş birliği yaptıklarını ele alacağız.

Bu temel alanları anlamak önemlidir. Bu, ekibiniz veya kuruluşunuz içinde Çevik ürün yönetimini uygulamak veya geliştirmek için gereken araçları size sağlayacaktır.

Çevik ürün yönetimi nedir?

Çeviklik, ekiplerin bir hedefe ulaşmak için etkili bir şekilde nasıl iş birliği yapabileceğine ilişkin bir felsefedir. 2001 yılında yayımlanan özgün Çevik Manifesto, Çevik ilkeleri en iyi şekilde ifade eder:

Süreçler ve araçlar yerine bireyler ve etkileşimler
Kapsamlı dokümantasyon yerine çalışan yazılım
Sözleşme müzakeresi yerine müşteriyle iş birliği
Bir planı takip etmek yerine değişime yanıt vermek

Çevik ürün yönetiminin özü budur. Hikâye puanlarından veya yüzme kulvarlarından söz edilmez. Günlük toplantılar ya da sprintler yoktur.

Çevik Manifesto süreçlerin ve araçların kullanılmasını zorunlu tutmasa da insan odaklı, uyarlanabilir iş birliğini ön plana çıkararak bunların önemini ikinci plana iter. Çevik ürün geliştirmeye ilk kez yaklaşırken (hatta konuyu tazeleme amacıyla bile olsa), Manifesto ile temellerden başlamak aydınlatıcı olabilir.

Çevikliğin pratik yönlerini konuşmaya başladığımızda Manifesto'yu aklımızda tutmaya devam etmek önemlidir. Süreçler, dokümantasyon ve planlama oldukça faydalıdır. Ancak kendinizi, sizin veya ekibinizin bunlara ekibinizden ya da çalışan bir üründen daha fazla öncelik verdiği bir durumda bulursanız, buna dikkat etmek istersiniz.

Çevik ürün geliştirme zihniyetinin bazı inceliklerine göz atalım.

İnsan Odaklı

Çevik yazılım geliştirme, ürün ekibinizi oluşturan kişileri güçlendirmeye odaklanır. Bunu iyi uygulamak için birlikte çalıştığınız kişilere gerçekten güvenmelisiniz. Güven olmadığında ekibinizin psikolojik güvenliği riske girer ve üretken iş birliği sekteye uğrayabilir.

Kullanıcı Odaklı

Kullanıcılarınıza aralıksız odaklanmak bir zorunluluktur. Sonuçta, biz kimin için ürün geliştiriyoruz?

Etkili bir Çevik ekip, ürünleri hakkında geri bildirim almak için sürekli olarak kullanıcılarla görüşür. Yeni özellik geliştirmeye öncelik vermeyi yönlendirmek amacıyla anketler düzenler ve bunların sonuçlarını işlerler. Çevik ürün yöneticileri, kullanıcılarla süreç boyunca doğrulama yapmak üzere çalışmayı küçük ve yayımlanabilir parçalara ayırmanın yollarını sürekli ararken özellik kapsamının kontrolsüzce genişlemesinden kaçınmaya dikkat eder.

Kullanıcıları düzenli olarak sürece davet etmezsek bugün planladıklarımız yarın geçerliliğini yitirebilir.

Zorlu

Çevik ürün yönetimi son derece zordur ve bunun nedeni tahmin edebileceğiniz şeyler değildir.

Etkili Çevik ekiplerde genellikle Çevik olmayan ekiplerdekine kıyasla daha az süreç ve resmî raporlama bulunur. Bunun nedeni, Çevikliğin tek seferlik dönüm noktaları yerine iş birliğine öncelik vermek için devam eden bir iş akışına ve şeffaflığa odaklanmasıdır.

Süreçlerin eksikliği, birçok ürün yöneticisi için kontrol eksikliği hissini de beraberinde getirir. Bununla birlikte, bu rolle birlikte gelen yüksek düzeyde sorumlulukları hâlâ vardır. Kişinin aşırıya kaçmaması ve ekibinin odağını bozmaması için kendini dengelemesi bir sanattır; bu durum, dinamiğe bağlı olarak ekipten ekibe değişebilir.

Ancak bir ürün yöneticisi hizmetkâr lider olma yaklaşımını benimsediğinde, uzun vadede daha fazla fayda — ve ironik bir şekilde daha fazla kontrol — elde edebilir. Bunun nedeni, güvene dayalı Çevik süreçlere ağırlık vermenin sağlayabileceği kazanımlardır.

Agile'ı destekleyen bir çalışma kültürüne sahip olmak da idealdir. Agile desteği olmayan bir ortamda başlamak mümkün olsa da bu daha zorlu olacaktır ve kendinizi akıntıya karşı mücadele ederken bulacaksınız. Agile'ı destekleyen bir kuruluş, planların kasıtlı olarak belirsiz olmasını sorun etmeyecektir; çünkü zaman ilerledikçe planların daha net hâle geleceğini anlar.

Yalın

Pratikte yalın olmak çok önemlidir. Sonuçlara lazer gibi odaklanmak, Agile ekiplerinin dikkatlerinin dağılmasını en aza indirerek hedefe doğru ilerlemesini sağlar. Hedefe ulaşmak için yapılabilecek en az işe odaklanmak, ekibin ilerlemeye ve pazarda mümkün olan en kısa sürede başarıya ulaşmaya devam etmesine yardımcı olur.

Agile Akışı

Agile akış infografiği — Strateji oluşturmadan denemeye, test etmeye ve doğrulamaya kadar Agile metodolojisinin genel akışı. Süreç, sürekli yinelemeyi teşvik etmek için tekrarlanır.

Agile ürün yönetimini benimsemek için kullanabileceğiniz birkaç özel sürece geçmeden önce, genel süreç akışından ve çoğu sürecin izleyeceği Agile metodolojisi adımlarından bahsedelim.

İlgili Okuma: Agile Ürün Portföyü Yönetimi İlkeleri Nasıl Uygulanır?

Strateji

Harika Agile geliştirme, iyi bir strateji ve uyumla başlar. Ekipteki herkesi bir odaya (veya Zoom toplantısına) toplamak, ortak bir ürün vizyonu ve yönü oluşturmak için harikalar yaratabilir. İnsanların ilgisini kaybetmemesini sağlamak için ilgi çekici görsel iş birliği yazılımlarını kullanmayı düşünün.

Bu, ekibin iş planı, görsel yön, hedef kullanıcılar ve diğer konularda aynı noktada buluşması için bir fırsat olabilir. Ekibin odaklanması için önemli bir ortak başlangıç noktası oluşturur.

Bu süreçte oluşturulan planların ve belgelerin varsayım olarak ele alındığını belirtmek önemlidir. Zaman ilerledikçe düzenli olarak gözden geçirilmeye ve yinelenmeye hazırdırlar.

Get Free Access to the Product Vault

We’ve collected the goods — AI prompts, exclusive deals, and a library of resources for product leaders. Unlock your account for access.

Have an account? Log In

Deney

Her şey bir deneydir. Başlangıçta yaptığınız ilk odaklanılmış iş parçası zamanla sınırlandırılmalı ve ardından kullanıcılarla test edilmelidir. Bu çalışma son derece temel düzeyde olabilir; hatta birine üzerinden geçerek anlatacağınız kaba taslak çizimler kadar basit olabilir.

Buradaki amaç, çalışmanıza bilimsel yöntem anlayışıyla yaklaşmaktır. Bilgi çalışanlarıyız ve bu nedenle odağımız yalnızca uygulama değildir. Aynı zamanda bilgi üretmeye ve keşfetmeye de odaklanırız.

Test

Her deney nitel ve nicel olarak test edilmelidir. Sonuçları düzenli olarak gözden geçirerek ekibinizin geliştirdiği şeyin değer taşıdığını ve pazarda kabul göreceğini doğrulamak için ihtiyaç duyduğunuz araçlara sahip olursunuz.

Doğrula

Yeni bir özelliği kullanıma sunduktan sonra onu yakından takip edin. Kullanılıyor mu? İnsanlar onu bulabiliyor mu? Bu özelliğin kullanıma sunulması, ürününüzün diğer alanlarını olumlu veya olumsuz etkiledi mi?

Kullanıma sunduğunuz şeyleri "tamamlandıktan" sonra düzenli olarak gözden geçirmek ve kontrol etmek, daha da iyi kararlar almanız için size daha fazla araç ve rehberlik sağlayacaktır.

Tekrarla

Bu, en önemli adımdır. Bir motor gibi Agile süreç akışında sürekli olarak geri dönüp ilerlemeye devam edin. Bu akış, öğrenmeyi teşvik etmek için doğrusal değil, kasıtlı olarak döngüseldir. Ondan öğrenin. Ondan uyarlayın. Onu kutlayın. Değişim akışını benimseyin.

Yaygın 2 Agile Yaklaşımı

Agile, aşırı yapılandırılmış süreçler ve raporlamayla mümkün olmayan iş birliğine dayalı yöntemlerle ekipleri ortak bir hedef etrafında bir araya getiren, güçlendirici bir felsefedir.

Ancak bazı süreçler faydalıdır. Doğru şekilde uygulandığında ve bir ekibin kendine özgü kültürü dikkate alındığında süreçler, yaratıcı özgürlüğü desteklerken ekibin hedeflerine ulaşmaya odaklanmasını sağlayan korkuluklar görevi görebilir.

Agile felsefesini hayata geçiren daha popüler süreçlerden bazılarını inceleyeceğiz.

Scrum

Scrum, belki de en popüler Agile sürecidir ve bunun iyi bir nedeni vardır: Taahhütleri ve öğrenmeyi "sprint" adı verilen özel zaman bloklarına bölerek çalışma çabasını yapılandırır. Bu, sağlıklı ölçüde öğrenmeyi ve bu öğrenmelere uyum sağlamak için daha fazla fırsatı teşvik eder.

Bu sprintlerin merkezinde scrum ekibinin kendisi yer alır. Scrum'da unvanlar yoktur: ekipteki her ürün çalışanı "geliştirici" rolünü üstlenir. Bu, güçlü bir ekip odağını iş birliğine ve her sprintin hedefe ulaşmasına yönlendirir.

Uygulamada bu, bir test mühendisi test edilecek bir özelliği bekliyorsa yeni bir özellik kodlamaya başlayarak zaman geçirebileceği anlamına gelir. Bu çapraz işlevli yaklaşım işe yaradığında inanılmazdır; çünkü bir ekibin harika sonuçlar üretmesini sağlar.

Scrum, odaklanmış geliştirme zamanını teşvik etmek için toplantıları en aza indirmeye çalışır. Bunu yapmak için düzenli olarak tekrarlanan bir dizi toplantı veya tören vardır:

Sprint Planlaması: Ekibin sprint için üstlenmek istediği çalışmayı planlamak amacıyla kullanılır.
Sprint İncelemesi (Gösterim): Herhangi bir ilerlemeyi birbirine ve paydaşlara göstermek ve edinilen öğrenimleri ele almak için ayrılan zamandır.
Sprint Retrospektifi: Ekibin önceki sprinte dürüstçe dönüp baktığı; nelerin iyi gittiğini, nelerin iyi gitmediğini ve hangi gelişim fırsatlarının bulunduğunu tartıştığı zamandır.
İş Listesi Düzenleme ve Tahmin: İş ve teknik öğrenimlere göre sürekli değişen ürün iş listesini gözden geçirmek ve önceliklendirmek için düzenli olarak ayrılan zaman dilimidir. İş listesindeki öğeler üzerinde mutabakat sağlandıktan sonra planlama amacıyla tahmin edilirler.
Günlük Ayakta Toplantılar: Ekibin dün tamamladıklarını, bugün üzerinde çalıştıklarını ve herhangi bir engelle karşılaşıp karşılaşmadıklarını paylaştığı, her gün düzenli olarak yapılan toplantıdır.

Sprint odaklı çalışmayı büyük resimle ilişkilendirmek için scrum, yapılandırılmış sprint planlama oturumları aracılığıyla tahmin yapmak üzere "hikâye puanlarının" kullanılmasını teşvik eder. Bunlar, ekibin her iş listesi öğesine atadığı, çabanın keyfi bir düzeyini ifade eder.

Silvia DakeÜrün Müdürü
Share This Quote on:

Bunun son derece güçlü olmasının nedeni, hız takibinin kullanılmasını desteklemesidir. Yani ekibin her sprintte tamamladığı ortalama hikâye puanı sayısından söz ediyoruz. İlk birkaç sprintten sonra bu sayı netleşmeli ve hedefli sürüm öngörüsü ile planlama için kullanılabilir.

Bu araçlar ekiple birlikte özenli bir şekilde kullanılır ve deneyimli bir scrum yöneticisi tarafından yönlendirilirse scrum, odaklanmış Çevik geliştirmeyi destekleyen ve etkili yineleme için geniş fırsatlar sunan güçlü bir süreç olabilir.

Kanban

Scrumdan büyük ölçüde yararlanan Kanban; iş listesi düzenleme, sprint panosunu andıran bir pano ve daha fazlası gibi birçok tanıdık unsuru içerir.

Ancak scrum az miktarda işe odaklanırken kanban, sürekli bir iş akışına odaklanmayı vurgular.

Bu sürecin merkezinde kanban panosu bulunur. Öğeler sürekli olarak sol tarafta önceliklendirilir ve ekibin özel süreci boyunca sağa doğru ilerleyerek "tamamlandı" durumunda sonlanır. İş yükünü dengelemek amacıyla her sütunda, aynı anda üzerinde çalışılabilecek görev sayısını belirleyen bir devam eden iş (WIP) sınırı bulunabilir.

Kanban, destek çalışmaları veya taahhütte bulunmak için düzensiz uygunluğa sahip ekipler için harikadır.

SAFe, XP ve Diğerleri

Her biri belirli kurumsal ihtiyaçlara ve kültürel normlara uygun olan, Çevik süreçlerin daha birçok ek çeşidi vardır.

SAFe, genellikle büyük bir kuruluşta Çevik yaklaşımı ölçekli bir şekilde uygulamaya yönelik kapsamlı bir Çevik sistemdir. Esasen ayrı scrum ekiplerinden oluşan birden çok "Çevik sürüm treni" içerir. Tüm ekiplerin ortak kurumsal hedefler ve sürüm planları doğrultusunda çalışmasını sağlamak için birden fazla rol ve tören bulunur.

Aşırı programlama (XP), DevOps, Modern Çevik ve diğer metodolojiler, belirli roller veya kültürler için Çevik kullanım alanlarını hedeflemek üzere mevcuttur.

Farklı Çevik uygulamalarla denemeler yapmak sağlıklıdır. Bu, benzersiz kuruluşunuz için neyin işe yaradığını etkili bir şekilde anlamanızı sağlayabilir.

Çevik Ürün Yönetimi Sertifikaları

Muhtemelen belirli bir Çevik süreç için alabileceğiniz çok sayıda sertifikayı görmüşsünüzdür. Bu sertifikalar, kendi süreçlerinin tek yol olduğuna ve pahalı bir sertifikasyon sürecinden geçmeden bu süreci gerçekten uygulayamayacağınıza inanmanızı sağlayacak şekilde pazarlanır.

Bunu görmezden gelin.

İdeal olarak bu rehber, kendi öğrenme yolunuza devam etmeniz için size yeterli ivmeyi sağlayacaktır. Çevik metodolojiler, üzerinde sınava gireceğiniz bir konu değil, uygulayıcıların araç setidir. Her sürece özgü süreç, seremoniler ve dokümantasyon hakkında bilgi sahibi olmak değerlidir; ancak manifestoya dönecek olursak, seçtiğiniz Çevik sürecin uygulanmasına ekibinizi dâhil etmek çok daha kritiktir. Sertifikalar oluşturmaya ve sürdürmeye adanmış kuruluşlar vardır; süreçleri insanların önüne koymayı teşvik etmek doğal olarak onların çıkarınadır.

Bu gerçekten Çevik mi?

Tüm bunları söylememin nedeni, kendi Çevik öğrenme yolculuğunuza çıkarken bunun yalnızca uyarıcı bir hikâye olmasıdır. Sertifikalar değerli olabilir. Bir atölye çalışmasına katılırsanız bu, belirli bir sürecin tüm ayrıntılarını hızlıca öğrenmek için hedefe yönelik bir yol olabilir. Bazı kuruluşlar, güveni hızlı bir şekilde oluşturmanın bir yolu olarak sertifikaya sahip olmanızı önemser.

Bir sertifika edinmek istediğiniz sonuca ulaşmanıza yardımcı oluyor ve bunu elde etmek için gereken çaba düşükse, devam edin. Ancak bir sertifikaya ihtiyacınız yoksa Çevik'i uygulama konusunda denemeler yapmak ve sürekli öğrenmek, Çevik yolculuğunuzda en etkili yoldur.

İlgili: Çevrim İçi En İyi 4 Çevik Ürün Yönetimi Sertifikası

Çevik ürün geliştirme rolleri nelerdir?

Çevik süreçleri ele alırken, Çevik bir ürün geliştirme ekibini oluşturan bir dizi temel rolü tanımlamaya başladık. Bu roller şunlardır:

Ürün Yöneticisi
Ürün Sahibi
Geliştirici
Tasarımcı
Test Mühendisi / QA

Her kuruluşun genellikle bu rollerin ne olduğuna dair kendi yaklaşımı vardır. Örneğin, bir şirketteki ürün yöneticisinin sorumlulukları, başka bir şirketteki ürün sahibinin sorumluluklarıyla daha çok örtüşebilir. Ancak bu esnekliği göz önünde bulundurarak, bir ürün ekibindeki rolleri açıklayan daha geniş tanımlardan bazılarına göz atalım.

Ürün sahipleri, ürün yöneticileri ve proje yöneticileri arasında genellikle bazı görev örtüşmeleri vardır ve ekiplerde bu rollerden biri, ikisi veya üçü birden bulunabilir. Ekipte bir proje yöneticisi olmadığında, ürün yöneticileri veya ürün sahipleri genellikle proje yönetimi sorumluluklarını üstlenir.

Ürün Yöneticisi

Peki, ürün yöneticisi ne yapar? Ürün yöneticisi, tahmin edebileceğiniz gibi ürünü yönetmekten sorumludur. Ürün yönetimi rolünün temel sorumluluğu, kullanıcı testleri, ekip girdileri ve stratejik planlama temelinde önemli sonuçlara ulaşmak için her şeyin uyumlu olmasını sağlamaktır.

Ancak etkili ürün yönetimi, ürün ekibinin güçlendirilmesiyle ilgilidir. Bu nedenle ürün yöneticisi, genelci bir roldür. Yani etkili olabilmek için beceri setini geniş tutabilmesi gerekir; ancak mutlaka yetkin bir geliştirici veya tasarımcı olması gerekmez (geliştirme rollerinden ürün yönetimine geçiş yaygın olsa da).

Genelci beceri seti, ürün yöneticisinin ekibi için empati kuran bir hizmetkâr lider olmasını sağlar. Ürün yöneticisi, geliştirmenin gerektirdikleri konusunda yeterli düzeyde anlayışa sahip olarak, ekibin becerilerinin önüne geçmeden ekibe etkili ürün tanımlama ve planlama konusunda rehberlik edebilir.

İlgili Okuma: Ürün Yönetimi Neden Önemlidir?

Ürün Yöneticisinin Sorumlulukları

Ürün Sahibi

Ürün yöneticisi ürünün taktik başarısının sorumluluğunu üstlenirken, Çevik ürün sahibi işletme ve pazar başarısından sorumludur.

Genellikle ürün sahibi, bazen ürün ekibinin temel paydaşı da olabilen temel bir iş rolüdür. Pazar bilgisi ve işletmeye odaklanan 50.000 fitlik bakış açısı, ürün ekibinin başarı için optimize edilmesine yardımcı olan önemli ve bilgili bir kaynak olmasını sağlar.

Ürün Sahibinin Sorumlulukları

Ürün başarısı
Pazar araştırması ve bilgisi
İş geliştirme
Finansman
Oy eşitliğini bozma

Yaygın bir zorluk, ürün sahibi ile ürün yöneticisi rolleri arasındaki örtüşme ve farklılıklardır. Bazen bu rol, ürün yöneticisi rolünün bir parçasıdır ve bunun tersi de geçerlidir. İki rol ayrı olduğunda, genellikle rol örtüşmesi yaşanır. Hatta bazı kuruluşlar ürün yöneticisi ve ürün sahibi rollerinin sorumluluklarını birbirinin yerine kullanır.

Ancak bu bir sorun değildir!

Ortaya çıkabilecek zorluklara rağmen, bu roller tamamlayıcı bir iş birliği içinde sağlıklı bir denge bulmak için birlikte çalıştığında inanılmaz sonuçlar elde edilebilir. Örneğin, rollerden biri aralıksız biçimde ürüne odaklanırken diğeri işe odaklanabilir. Biri ürünün teknik ayrıntılarına odaklanırken diğeri üst düzey pazar konumlandırmasına odaklanabilir.

Ardından bu iki rol iş birliği yapmak üzere ortak çalıştığında, ürünün ve ekibin başarısını olumlu yönde etkileyen, oyunun kurallarını değiştirecek stratejik içgörüler beklenmedik şekilde ortaya çıkabilir. Sonuçta, iki kafa bir kafadan iyidir!

Geliştirici

Etkili bir ürün ekibinde geliştirici rolü yalnızca kod yazmaktan ibaret değildir: Geliştiriciler stratejik ve teknik planlama ile öneriler için tüm rollerle iş birliği yapar.

Ürün geliştirme araçları, kullanıcı ihtiyaçları ve ürün-pazar hedefleri hakkında güçlü bilgiyle donanmış geliştiriciler, ürüne tam anlamıyla uyan bir teknik plan oluşturabilir. Geliştirme ekibi üyelerini bu bilgiyle ve temel teknik kararları alma becerisiyle güçlendirmek, bu kararların beraberinde getirdiği teknik ödünleşimler nedeniyle bir aylık geliştirme süreci ile bunun kat kat uzunu arasındaki farkı yaratabilir.

Geliştiricileriniz geliştirme ekibinizin ürün boyutuna dâhil edildiğinde, ekibin başarısını katlayabilirler.

Geliştirici Sorumlulukları

Ürün geliştirme
Teknik planlama ve araştırma
Teknoloji yığını danışmanlığı
İşlevsel prototipleme
Birim testi
DevOps (bazen ayrı bir rol)
- Dağıtım işlem hattının oluşturulması ve yönetimi

Tasarımcı

Geliştiricilerin yalnızca kod yazmakla sınırlandırılmaması gerektiği gibi, tasarımcıların bir ürün ekibindeki etki alanı da tasarım oluşturmaktan daha geniş olmalıdır. Aslında bir ürün ekibindeki en iyi iş birliklerinden bazıları, bu rol ile ürün yöneticisi rolü arasındaki iş birliğinden doğar.

Ürün ekiplerindeki tasarımcılar işe ürün stratejisine ve işe stratejik açıdan bakarak başlar. Genellikle ekipte kullanıcı odaklı en güçlü savunuculardır. Bu içgörüler, daha sonra hedefli bir odakla tasarım yapmalarını sağlar.

Geliştirme ve öğrenme süreçlerinde verimliliği mümkün kılmak, tasarım rollerinin temel odak alanlarından biridir. Tasarım sistemleri oluşturmak, geliştiricilerin sürekli entegrasyon iş akışları aracılığıyla yeni özellikleri hızla geliştirmesini sağlar. Etkileşimli ve görsel prototipler oluşturmak, daha fazla yatırım yapılmasını doğrulamak için tek satır kod yazılmadan önce kullanıcı testlerinin gerçekleştirilmesini sağlar.

Tasarımcı Sorumlulukları

Ürün tasarımı
Taslaklar
Prototipleme
Stil kılavuzu oluşturma
Tasarım sistemi oluşturma ve destekleme
Ürün yöneticisiyle iş birliği içinde kullanıcı testleri
Sürekli kullanıcı araştırması

Test Mühendisi / QA

Test mühendisi (bazen kalite güvencesi veya QA olarak adlandırılır), bir ürün ekibindeki en etkili rollerden biri olabilir. Temel odakları, ürün özelliklerini kullanıcılara sunmadan önce test etmek olsa da ayrıntılara gösterdikleri dikkat, yeni bir özellik geliştirilmeden önce ekibin odağını düzenlemeye yardımcı olabilir.

Test mühendisleri, ürün geliştirmenin en erken aşamalarından itibaren sürece dâhil edilmelidir. Bu sayede bu rol, ekibin geri kalanına işi tamamlamaları için yol gösteren kullanıcı hikâyeleri için kabul kriterlerini tanımlayabilir.

Kullanıcı odaklı bir zihniyetle çalışan test mühendisleri, yaklaşan bir sürümün olası sonuçları hakkında önceden uyarıda bulunabilir. Bu rol, ürün sahibine stratejik tavsiyelerde bulunabildiğinde, yeni bir sürümün kullanıcılara sunulmasının ticari başarısı veya başarısızlığı üzerinde somut bir etki yaratabilir.

Test Mühendisi/QA Sorumlulukları

İşlevsel test
Regresyon testi
Keşifsel test
Kabul kriterlerinin tanımlanması
Sürekli risk değerlendirmeleri ve analizleri

Diğer Roller

Daha önce bahsedilen roller bir ürün ekibini oluştursa da ekibin sonuç odaklı yaklaşımını destekleyen ekip dışı birçok rol vardır.

Bu roller arasında pazarlama, satış, müşteri desteği ve daha fazlası bulunur. Genellikle bu roller, pazarda başarı elde edildikçe ürünü desteklemek amacıyla organizasyona dahil edilir. Çoğunlukla ürün ekibinin bir parçası değildirler. Ancak bu rollerle güçlü ve iş birliğine dayalı bir ilişki kurmak, iş başarısını daha da ileri taşır.

İş Birliği

Her rolün bir ürün ekibinde kendi uzmanlık alanı olsa da hepsinin birlikte iş birliği yaptığı varsayılır. Her rol ekibe "T-şeklinde" bir zihniyet getirdiğinde, herkes kendi uzmanlığını ortaya koyabilir ve aynı zamanda birbirlerinin rol tanımının bir parçası olarak ürüne odaklanabilir. Herkes kendi uzmanlık alanında derinleşirken, aynı zamanda bir ekip olarak başarıya ulaşmak için diğer tüm beceri setlerinde genişler.

Bir ürün ekibinde iş birliği, ürün sonuçlarına ve kullanıcı deneyimine kesintisiz biçimde odaklanılması anlamına gelir. Herkes bu vizyonu gerçekleştirmeye ve uyumlu bir ekip olarak birlikte ilerlemeye dahil edilir.

Sonuç

Temel çıkarımlar

Çevik ürün yönetimi, doğru çıktıyı daha kısa sürede sunmaya yönelik, insan ve kullanıcı odaklı bir felsefedir.
Çeviklik özünde basit olsa da süreçler, organizasyon kültürü ve daha fazlası karmaşıklıklar ve zorluklar ortaya çıkarır.
Çevik süreçler ve roller; scrum, kanban, SAFe ve daha fazlası gibi süreçlerle yönlendirilebilir.
Bir Çevik ürün ekibini oluşturan roller arasında geliştiriciler, tasarımcılar, test mühendisleri, bir ürün yöneticisi ve bir ürün sahibi bulunur.

Çevik ürün yönetimi son derece basit ve bunu bilinçli olarak amaçlayan bir yaklaşımdır. Ekibinizin oluşturabileceği değeri katlayabilecek güçlü bir felsefedir. Ancak onu destekleyen süreçlere ve rollere ne kadar derinlemesine girerseniz, daha karmaşık hale gelme riski de o kadar artar.

Bu karmaşıklığın içinde ürün ekibinizi ve organizasyonunuzu güçlendirmeye yönelik fırsatlar saklıdır. Bu taktikleri ekibinizle kullanırken, normal iş birliği süreci boyunca istemeden organizasyonel bir yavaşlamaya yol açmamalarını sağlamak bir denge işidir.

Ancak iyi uygulandığında ve deneyselliği benimseyen bir yaklaşımla ele alındığında Çeviklik, ürün ekibinizin başarısının geleceğini şekillendirebilir.

Çevikliğin uygulandığı bir çalışma gördünüz mü veya bu konuda deneyiminiz var mı? Bu uygulama, bu kılavuzda açıklananlara benziyor muydu, yoksa farklı mıydı? Yorumlarda bize bildirin! Daha fazla içgörü ve kılavuz için Ürün Yöneticisi bültenimize abone olmayı unutmayın.

Ya da okuma/izleme/dinleme seçenekleriyle kolayca yararlanabileceğiniz bu podcast'e göz atarak öğrenmeye devam edin: Ürün Yol Haritalarıyla Uyum (Crema'dan Brandon Blackman ile)

İlgili Okumalar:

Bunlara da Göz Atmaya Değer: