İşleri Doğru Yapmak (Crema’dan Michael Luchen ile)

Deşifreyi Okuyun:

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

Ben Aston:

İşlerin yolunda gitmemesi kötüdür; bir proje üzerinde haftalarca, hatta aylarca çalışıp sonunda son UAT aşamasında ortaya çıkan sinsi bir hata yüzünden hayal kırıklığına uğramak daha da kötüdür. Peki bu neden neredeyse her zaman oluyor gibi görünüyor ve bu konuda yapabileceğimiz bir şey var mı? Hatalar tarafından rahatsız ediliyorsanız dinlemeye devam edin; çünkü bugünkü podcast'te, geliştirilmiş bir ürün ve süreçle işleri nasıl doğru yapabileceğimizi ve kalite yönetim planının sihrini konuşacağız.

Bizi dinlediğiniz için teşekkürler. Ben proje yöneticilerinin kurucusu Ben Aston. DPM podcast'ine hoş geldiniz. Proje yöneticilerinin başarılı olmasına ve proje yöneten kişilerin daha iyi işler teslim etmesine yardımcı olmak için çalışıyoruz. Proje yönetimi becerilerinizi bir sonraki seviyeye taşımanıza yardımcı olmak için buradayız. Eğitimlerimiz ve üyelik aracılığıyla sunduğumuz kaynaklar hakkında bilgi edinmek için thedigitalprojectmanager.com adresine göz atın. Bu podcast size kurumsal proje ve portföy yönetimi yazılımlarının lideri Clarizen tarafından sunuluyor. Daha fazla bilgi için clarizen.com adresini ziyaret edin.

Bugün bize Michael Luchen eşlik ediyor. Michael, yerleşik DPM uzmanlarımızdan biri. Kendisi bir ürün koçu. Crema'da çalışıyor; Crema, yenilikçi şirketler ve sektör liderleri için web ve mobil uygulamalar oluşturan bir dijital ürün ajansı. Michael normalde Washington D.C. dışından uzaktan çalışıyor ve ekiplerin iş birliğini geliştirmelerine, karmaşık sorunları analiz edip çözmelerine yardımcı oluyor. Adidas, Callaway Golf ve başka şirketlerle çalıştı; ayrıca Crema'da koçluk yapıyor. Bugün onunla bir kalite yönetim planı oluşturmayı konuşacağız. Merhaba Michael, programa hoş geldin.

Michael Luchen:

Merhaba Ben, nasıl gidiyor?

Ben Aston:

İyi, teşekkürler. Yıllar boyunca konuşup podcast kayıtları yaptıkça rolünün geliştiğini fark ettim. Şimdi sahip olduğun koçluk rolü, sanırım yeni bir iş unvanı. Bize bu koçluğun ne olduğunu anlatabilir misin? Ürün koçu nedir ve Kramer'da bu ne anlama geliyor?

Michael Luchen:

Bahsettiğin gibi bu rol, yaklaşık yedi yıllık uygulamalı proje ve ürün yönetimi deneyiminin ardından ortaya çıktı. Açıkçası bu rol şu anda tanımlanma aşamasında. Crema'da koçluk rolünün ne olduğunu anlamaya çalışıyoruz. Şu anda bunu, müşterilerin Çevik uygulamayı anlamalarına ve kendilerinin daha iyi versiyonları olmalarına yardımcı olan bir hizmetkâr liderlik rolü olarak ele alıyoruz. Genellikle onların sorunları yeniden çerçevelemelerine ve yenilikçi yaklaşımlar belirlemelerine yardımcı olmak için kolaylaştırıcı, ürün stratejisti ve tasarım odaklı düşünür olarak görev yapabilirim. Ancak bence bu yeni rolün ve Crema'nın bu yeni girişiminin gerçekten ilginç yanı, kalabalık bir sektörde reçeteci olmayan, çok özgün bir yaklaşımla fark yaratmaya çalışması. Piyasada çok fazla reçeteci koçluk süreci var ve biz farklı olmak istiyoruz.

Ben Aston:

Anladım. Rolünde küçük bir ekiple müşterinin yanına gidip doğrudan çalışıyorsun. Bu, proje veya ürün yol haritasını tanımlamaya çalıştığın zamana göre daha stratejik bir rol mü?

Michael Luchen:

Evet, bu-

Ben Aston:

Yoksa daha çok teslimat odaklı mı?

Michael Luchen:

… Az önce bahsettiğin şeye benziyor. Biraz daha kapsamlı ve insanlara daha fazla odaklanıyor. Proje yönetimi hakkında sevdiğim şeylerden biri, ekiplerin ellerinden gelenin en iyisini yapabilmeleri için sağlıklı bir ortam geliştirmeye odaklanabilmek. Bu rol de bunu temel alarak müşterilere, ekipleri içinde sağlıklı ve üretken bir kültür ve ortam oluşturmaları için ihtiyaç duydukları araçları ve bakış açısını kazandırmakla ilgili.

Ben Aston:

Peki müşterilerin teslimat anlayışını değiştirmelerine yardımcı olurken ne tür zorluklarla karşılaşıyorsun?

Michael Luchen:

Ortaya çıkabilecek çok sayıda zorluk var; ancak bence asıl mesele, sonuçların her zaman anında ortaya çıkmayacak olması. Gidip “Bunu yapın, her şey daha iyi olacak” diyebileceğim bir şey değil. Piyasada “X çerçevesini öğrenin, ekibiniz başarılı olsun” gibi çok fazla yaklaşım var. Ancak önemli olan, kurum kültürünün tamamını ve içinde bulunulan koşulları anlamak. Birlikte çalıştığınız liderleri güçlendirirken, dersleri deneyip nasıl işe yaradıklarını anlamanın zaman aldığını kabul etmek gerekiyor.

Ben Aston:

Kesinlikle. Bir kuruluş veya ajans için her zaman tamamen doğru olacak tek bir süreç yok. Adımları basitçe izleyerek bir anda sihirli sonuçlar elde edemezsiniz. Tüm sorunlarınızı bir anda çözecek sihirli bir çözüm yok. Bazen insanlar “Çevik yaklaşım sihirli çözümdür” diye düşünüyor; sonra da bunun ne anlama geldiğini tanımlamamız gerekiyor. İlginç bir rol gibi görünüyor. Bunu çoğunlukla uzaktan mı yapıyorsun, yoksa müşterilerle yerinde mi çalışıyorsun?

Michael Luchen:

Kesinlikle ikisinin bir kombinasyonu. Şu anda, bu kaydı yaptığımız sırada yüzde 100 uzaktan çalışıyoruz. Ancak ilişkiler yüz yüze kurulabilir; mümkünse koçluk sürecine yüz yüze başlamak her zaman harika. Bununla birlikte, Zoom görüşmeleri veya Loom ekran paylaşımları kullanarak yönlendirme sağlamak, soruları yanıtlamak ya da Mural panolarında iş birliği yapmak aracılığıyla gerçekten üretken ve anlamlı konuşmalar gerçekleştirebildiğimi gördüm. Yani her iki şekilde de yapılabilir.

Ben Aston:

Uzaktan çalışmadan söz ediyoruz. Açıkçası Korona karantinasının ortasındayız ve kısa süre önce bizim için uzaktan çalışma üzerine bir atölye düzenledin. Bunu kaçıranlar için veya uzaktan çalışma hayatını düşünürken, tek başına ya da uzaktan çalışırken akıl sağlığını korumana yardımcı olan en etkili ipucu veya teknik nedir? İzolasyon ve uzaktan çalışma hissiyle nasıl başa çıkıyorsun? Normalde ortak çalışma alanlarına gittiğinden söz ederdin. Belki evinde kapalı kalmak konusunda da çok deneyimlisin. Bu süreçte aklını korumak için ne yapıyorsun?

Michael Luchen:

Evet, gerçekten iyi ve zamanında bir soru. Zihinsel olarak, başka insanlarla iş birliği yaptığımı ve çalıştığımı hatırlamaya çalışıyorum. Bu nedenle mümkün olduğunca görüntülü Zoom görüşmeleri yapmak son derece değerli oldu. Bu dönemde kulağa çok basit geliyor; özellikle Zoom'un şu anda en çok indirilen ücretsiz bir numaralı uygulama olduğunu gördüğümde. Ancak buna iş birliği perspektifinden bilinçli şekilde yaklaşmak önemli: Ekibimle bir Zoom görüşmesine katılıp konuları birlikte ele alalım. Özellikle proje yöneticisi olarak sözsüz etkileşimleri görebilmek çok değerli. Hatta ekranımı paylaşırken herkesin yüzünü görebilmek için bazen ikinci bir ekran kullanmaya özen gösteriyorum.

Ben Aston:

Bence bu sağlam bir tavsiye. Zoom harika bir araç. Ayrıca Slack'imiz olduğunda her şeyi Slack'te yazmaya başlama eğilimine girebiliyoruz; böylece iletişimin büyük bir bölümünü ve ilişki kurma fırsatını kaçırıyoruz. Zoom görüşmesindeki konuşma farklıdır; bu nedenle üzerinize düzgün bir şey giyip Zoom görüşmesi yapın. Bunun kesinlikle faydasını görürsünüz.

Koçluktan ve bunu yüz yüze olduğu kadar uzaktan da yaptığından söz ettin. Şu anda her şey uzaktan; ancak üzerinde çalıştığın bazı projelerden bahsedebilir misin?

Michael Luchen:

Şu anda ürün yönetiminden tamamen koçluk rolüne geçiş yapıyorum. Büyük ve çok yıllı bir kurumsal geliştirme projesini tamamlıyorum. Bunu koçluk anlayışıyla ele almak gerçekten güzel; çünkü koçluğu uygulayıcı seviyesine indirdiğinizde ciddi bir örtüşme var. Bunun dışında, bu koçluk hizmetlerinin neler olduğunu ve Crema'nın burada nasıl fark yaratabileceğini, özellikle de temel farklılaştırıcının ne olduğunu belirlemeye çalışıyorum. Müşterilere alçakgönüllü bir özgüvenle hizmet vermek istiyorum.

Ben Aston:

Müşterilerin yaşadığı ve çözmeye yardımcı olduğun zorlukları düşünürken, bu rolü oluştururken potansiyel fırsatlar olarak belirlediğin temel teslimat sorunları neler?

Michael Luchen:

Bunun için ilginç bir benzetme buldum. Koçluğa, bir üniversite müfredatındaki dönem gibi yaklaşmayı düşünüyoruz. Bunun nedeni, etkili koçluğun büyük ölçüde denemeye dayanması; koçluk yaptığım kişilerin gerçekten deneyerek ve kendi başlarına öğrenmeleri gerektiğine inanıyorum. Benim rolüm, uygulayıcı deneyimine sahip bir kolaylaştırıcı, rehber ve mentor olmak.

Bunun içinde düzenli görüşmeler, retrospektifler, gözlemler ve paylaşılan notlar yer alıyor. Örneğin “Belki buna göz atmak veya bir sonraki toplantınızda bunu denemek isteyebilirsiniz” diyebilmek. Asıl amaç bir ritim oluşturmak; birkaç hafta veya birkaç ayın sonunda hep birlikte geriye dönüp “Evet, burada belirgin bir gelişme var. Ekibimin daha fazla üretim yapabildiğini hissediyorum” diyebilmek.

Ben Aston:

Bir kuruluşun daha Çevik hale gelebileceği alanları belirlerken, bu alanları önceliklendirmelerine nasıl yardımcı oluyorsun? Büyük bir kuruluşta çok sayıda farklı süreç olacaktır. Müşterilerin süreçlerinin veya teslimatlarının hangi yönlerinin Çevik bir yaklaşım için uygun ve kolay kazanım fırsatı olduğunu belirlemelerine nasıl yardımcı oluyorsun?

Michael Luchen:

Bence bu bir anketle başlıyor. Önce bir görüşme yapabilmek gerekiyor. Anket yalnızca tek bir müşteri temsilcisiyle yapılmamalı; bazı proje yöneticileri, geliştiriciler ve sürece dahil olan ya da dahil olmak isteyen diğer kişiler de katılabilir. Öncelikle, çözülmesi gereken en önemli konuların ne olduğuna dair algılarını anlamak için bir anket yapıyoruz. Ardından ekibimin ve benim anketi inceleyip duyduklarımızın alt metniyle karşılaştırmamız gerekiyor. Böylece “Öncelikle şu iki veya üç alanda ilerleyelim; şimdi bunlara odaklanırsak gerçekten iyi sonuçlar elde edeceğiz” şeklinde önerilerde bulunabiliyoruz.

Ben Aston:

Oldukça akıllıca görünüyor. Bunun için bol şans.

Michael Luchen:

Teşekkürler.

Ben Aston:

Şimdi başlangıçta konuştuğumuz yazına ve kalite yönetimi konusuna dönmek istiyorum. Henüz sözünü edeceğimiz yazıyı okumadıysanız thedigitalprojectmanager.com adresinden göz atın. Yazının adı “Kalite yönetim planı nasıl geliştirilir?” Michael yazıda kalite planı oluşturmak için gerçekten kapsamlı ve adım adım bir süreç sunuyor. Üyeyseniz kalite yönetim planı, hedef cihaz listesi ve gereksinim kalitesi kontrol şablonuna da erişebilirsiniz. Böylece tüm bunları kolayca uygulamaya koyabilirsiniz.

Burada plan oluşturma sürecinin tamamını ayrıntılı olarak incelemeyeceğiz; çünkü bunlar yazıda yer alıyor. Özetle Michael, projeniz veya ürününüz için nasıl bir kalite planı oluşturabileceğinizden bahsediyor. Ancak kalite kavramıyla başlamak istiyorum. Bu ortak anlayışı oluşturma sürecinde kalite kavramını projeniz için tanımlayarak başlıyorsun. Sence bunu kavramak neden bu kadar zor?

Michael Luchen:

Öncelikle kaliteyi ve bu tartışmanın çerçevesini çizmek için kaliteyi iki unsur olarak görüyorum: ürün kalitesi ve süreç kalitesi. Ürün kalitesi, gerçek veya dijital ürününüzün kalitesidir; tasarım ekibinin, geliştirici ekibinin ve diğer ekiplerin çalışmalarının tüm sonuçlarını kapsar. Süreç kalitesi ise proje yöneticileri olarak güçlü biçimde etkileyebildiğimiz bir konudur. Ekibimizin sonuç üretme becerisini etkileyen ve geliştirdiğimiz süreci ifade eder. Hepimizin aşina olabileceği bir ölçüm örneği, süreç kalitesinin nasıl ilerlediğini ölçmeye yardımcı olan hızdır.

Bununla birlikte, kalite konusunda ortak bir anlayış oluşturmak birçok ekip için zordur; çünkü bu kavrama çok fazla öznellik ve duygu dahil olabilir. Geliştiricilerden tasarımcılara kadar pek çok paydaş ve kendi ekibiniz, farklı nedenlerle ve farklı bakış açılarıyla konuya yaklaşır. Örneğin bir müşteri paydaşı beklentileri karşılayan belirli bir kalite seviyesini isteyebilirken, bir geliştirici kod kalitesine ve temiz koda büyük önem verip mükemmel kod yazmak isteyebilir. Bizim görevimiz bu dengeyi kolaylaştırmak ve kurmaktır.

Ben Aston:

Bu dengeden bahsedelim. Benim için bu biraz zor bir konu. Çevik yaklaşımda bir kullanıcı hikâyesinin parametrelerini tanımlayan kabul kriterlerimiz var. Hikâyenin tamamlanmış sayılması için ne yapması ve hangi sonuçlara ulaşması gerektiğini belirliyoruz.

Sonra tüm kullanıcı hikâyelerine uygulanan genel kuralların tamamını tanımlayan tamamlanma tanımımız var. Ancak Çevik yaklaşımı düşünürken genellikle değer sunmaya ve bunu yinelemeli olarak gerçekleştirmeye çalışıyoruz. Bu nedenle kalite kavramı, en azından benim için, bu Çevik teslimat yaklaşımıyla çelişebiliyor. Hangisi daha önemli? Tüm kabul kriterlerini ve tamamlanma tanımını karşılamak mı, değer sunmak mı, yoksa ikisi birden mi? Bunun sonucunda daha yavaş mı ilerlememiz gerekiyor?

Michael Luchen:

Bu gerçekten iyi bir soru. Bu soruyu seviyorum, çünkü bu konuya neden bu kadar derinlemesine dalmayı sevdiğimin temelini oluşturuyor. Kaliteye odaklanmanın Çevik yaklaşımla çelişmediğine inanıyorum. Aksine, ekipler için bir hızlandırıcı ve Çevik uygulamalara odaklanan ekipler için bir kolaylaştırıcıdır. Projenin başında ekibinizle oturup kalitenin ne anlama geldiğini ve ne anlama gelmemesi gerektiğini tanımlarsanız, bu, işi gerçekten oluşturup teslim ederken ekibinizin sağlıklı bir odağa sahip olmasına yardımcı olur. Nelerin dikkate alınması ve alınmaması gerektiğini açıkça ortaya koyar.

Teslimatın ve günlük işlerin kabul kriterleri gibi ayrıntılarına indiğimizde bile bunlar, doğru perspektiften bakarsanız Çevik yaklaşımı destekleyen araçlar olarak hizmet eder. Örneğin ekibiniz bir sprint sırasında bir kullanıcı hikâyesi üzerinde çalışıyor ve bu hikâyenin zaten kabul kriterleri var. Geliştiriciler hikâyeyi oluştururken bir engelle veya belirli bir teknik zorlukla karşılaşabilir ve bu durum kabul kriterlerinin bir bölümünü değiştirebilir.

Bu, harika bir tartışma başlatır. Yavaşlayıp eski yönteme dönmemiz gerektiği anlamına gelmez. Ekip olarak durup hızlıca konuşabilir, kabul kriterlerini güncelleyebiliriz. Bu örnekte kabul kriterleri kaliteyi desteklemek için vardır.

Ben Aston:

Bence mesele kalite anlayışını değiştirmek. Kalitenin değeri hızla teslim etmenin karşısında duran bir şey olması gerekmiyor. Aslında kalite, değerin önemli bir bileşenidir. Değer taşıyan bir şey teslim ediyorsak, belirlediğimiz kalite kriterlerini karşılamadığında olması gerektiği veya olabileceği kadar değer sunmuyor olabilir. Kalite kavramımızı yeniden çerçevelemek önemli: “Bu, oluşturduğumuz değerin bir bileşenidir; bunu bu şekilde tanımlamamızın nedeni, bu kriteri karşıladığında değerin üretileceğini bilmemizdir.”

Michael Luchen:

Kesinlikle.

Ben Aston:

Kalite yönetimi sorumluluklarını bölme yaklaşımından bahsediyorsun. Bu konu ilginç; çünkü büyük ajanslar veya kuruluşlarda genellikle özel kalite güvence ekipleri olur. Ancak bazen iş gerçekten proje yöneticisinin veya geliştiricilerin üzerine kalabilir. Bir test mühendisi için savunuculuk yapmaktan söz ediyorsun. Deneyimine göre bu neden bu kadar önemli?

Michael Luchen:

Bunu gündeme getirmek iyi oldu. Kişisel geçmişim açısından şunu söylemeliyim: Proje yöneticisi olarak ilk yıllarımda kalite güvencesini ben yapıyordum. Şimdi birlikte çalışabildiğim test mühendisleriyle aradaki fark gece ve gündüz kadar belirgin. Bu rolün bu kadar önemli olmasının nedeni, kaliteye yönelik eleştirel bir bakış geliştirmeye ihtiyaç duyulmasıdır. Test mühendisi, benim açımdan her projede proje yöneticisinin en iyi ortağı gibi davranır; çünkü ekipteki başka hiçbir rolün yapmadığı şekilde hem oluşturulan ve teslim edilen şeyin ayrıntılarını inceler.

Teknik açıdan ayrıntılara odaklanırlar; ancak daha büyük resmi, geliştirmenin etkilerini ve yaptığımız işin kullanıcılara nasıl ulaştığını da değerlendirirler. Bir test mühendisinin bu şekilde çalışmasına izin verdiğinizde, ekipteki diğer rollerin, geliştiricilerin, tasarımcıların ve kesinlikle benim rolümün değerini çoğaltan temel bir ekip üyesi haline geldiğini düşünüyorum.

Ben Aston:

Benim deneyimimde de test mühendisi veya kalite güvence analistinin bakış açısı proje yöneticisininkinden çok farklı olma eğiliminde. Proje yöneticisi olarak her zaman en uygun yolu düşünürüm. Bir şeyi test ederken “Tamam, bunu böyle yaparsınız” derim; çünkü oluşturulan ürünü ve nasıl çalışması gerektiğini biliyorum. Ayrıca ürünün bozuk olmasında benim de çıkarım var; çalışmasını ve bu nedenle üzerinde daha fazla zaman harcamamayı istiyorum. Ancak kalite güvence veya test mühendisi bakış açısı, işleri bozma deneyimine sahip olmayı ve keşif amaçlı testlerle müşteri deneyimini düşünmeyi gerektirir. İdeal yolun aslında çalışmadığı, işlerin nasıl bozulabileceği üzerine düşünmek daha fazla titizlik ve kapsamlılık sağlayabilir. Böylece teslim ettiğimiz nihai ürünün kalitesini artırabiliriz; çünkü ürettiğimiz şeylerde her zaman hatalar olacağını biliyoruz.

Bu beni soruma getiriyor. Yazında hedef cihazlarınızı belirlemekten bahsediyorsun. Müşterilerimizde eski bir telefon olabildiği için bu çoğu zaman çok zor. İnsanların Internet Explorer 6 kullandığı veya BlackBerry sahibi olduğu günleri hatırlıyorum; eski tarayıcılarında ve telefonlarında her şeyin çalışmasını bekliyorlardı. Müşteriniz geçmişteki ve gelecekteki tüm cihazlarda çalışacak bir ürün istediğinde, bu kapsamı sınırlamak için onlarla nasıl çalışıyorsunuz? Onlara “Bu aslında hiçbir şeyde çalışmayacak, ama sorun değil” yaklaşımını nasıl anlatıyorsunuz?

Michael Luchen:

Hedef cihazları belirlemek söz konusu olduğunda bu, özellikle proje yöneticiliği geçmişimi düşündüğümde en sevdiğim çalışmalardan biri. Çünkü bu yalnızca kaliteye ve ekibin bu alana ne kadar yatırım yapması gerektiğine odaklanmayı daraltmaz; aynı zamanda kullanıcılar için oluşturup üretmeye çalıştığınız sonuçlara da odaklanmanızı sağlar.

Müşteri şimdiye kadar üretilmiş her cihazın ve her işletim sisteminin desteklenmesini istediğinde, aslında desteklediğiniz kullanıcılar ve bu kullanıcıların gerçekten neye ihtiyaç duyduğu hakkında sorular sormaya başlamanızı sağlar. Geçmişte Internet Explorer desteğiyle ilgili şaka yapıyoruz; ancak bazen bu konuşmalar, kullanıcılar açısından değer taşıyan gerçek tartışmalara yol açar. Belki de gerçekten böyle bir desteğe ihtiyaç duyan niş bir uygulamadır.

Bu nedenle hedef cihazlar konuşması, sizin, ekibinizin ve müşterinizin kullanıcıya odaklanmasına, önceliğe ve bu öncelikleri yüksek bir kalite seviyesinde gerçekleştirmek için gereken zamana göre kapsamı daraltmasına yardımcı olur. Ne önemli, ne değil; bunu netleştirirsiniz.

Ben Aston:

Bu sağlam bir tavsiye. İş kapsamı belgesi yazan veya kabul kriterlerini tanımlayan kişilere küçük bir uyarıda bulunmak istiyorum: Hangi cihazları destekleyeceğinizi yazarken dikkatli olun. “Bu, şimdilik ve sonsuza kadar tüm mobil ve masaüstü cihazlarda çalışacak” gibi ifadeler kullanmayın. Çünkü yalnızca geçmişteki tarayıcılarda çalışmamakla kalmayacak; tarayıcılar geliştikçe bazı şeylerin çalışmayı bırakacağını da göreceksiniz.

Bazen siteniz veya ürününüz sorunsuz biçimde çalışabilir. Ardından Google tarayıcının yeni bir sürümünü yayımlar ve bir anda işler bozulur. Bunun suçu kimin? Başlangıçta bunu tanımlamak gerekir. Kimsenin suçu olmadığını söyleyebilirsiniz; ancak çalışmakta olan şeyin artık çalışmamasının bedelini birilerinin ödemesi gerekir.

Bu nedenle hedef cihazlarınızı belirlemek ve bunları açıkça tanımlamak önemlidir. Bunu dikkatli biçimde yapmazsanız ileride sizi çok zor durumda bırakabilecek konulardan biri budur.

Şimdi test senaryolarından söz etmek istiyorum. Ayrıntılara iniyoruz. Birçok kişi test odaklı geliştirmeyi duymuştur; ancak bir de testleri o anda gerçekleştirip ilerledikçe belgelemek var. Sonra şu ikilem ortaya çıkıyor: Bir test planımız olacak mı? Bunu nasıl yöneteceğiz? Deneyimine göre test odaklı geliştirme hakkında ne düşünüyorsun? Değer üretme açısından doğru sonuçları sağlıyor mu? Test mühendisleriniz sadece o anda test edip ilerledikçe mi belgeliyor, yoksa gerçekten kapsamlı bir test planıyla mı ilerliyorsunuz?

Michael Luchen:

Crema'daki deneyimime göre test mühendislerimiz, kalitenin herkesin sorumluluğu olduğu anlayışını şirkete taşıdı. Bu anlayıştan hareketle geliştiricilerimiz test odaklı geliştirme uyguluyor ve uygun bileşenler için entegrasyon testlerinin koda yazılmasını sağlıyor. Böylece gerçekten test edilebilir işlevler test mühendisine ulaştığında, test mühendisi kullanıcı perspektifinden manuel testlere, otomatik testler yazmaya, keşif amaçlı sınır durumu testleri gerçekleştirmeye ve benzeri çalışmalara daha fazla zaman ayırabiliyor.

Ben Aston:

Herkesin sorumlu olmasındaki düşman, aslında hiç kimsenin sorumlu olmamasıdır. Kuruluşta kaliteyi nasıl bir değer olarak teşvik ediyorsunuz? Pratikte bu nasıl görünüyor?

Michael Luchen:

Bunun büyük bölümü eğitim temeliyle başlıyor. Kalite hakkında konuştuğumuz Slack kanalları oluşturuyoruz ve projelerimiz için kalitenin ne anlama geldiğine dair sürekli bir tartışma yürütüyoruz. Ancak özellikle proje yöneticilerinin yardımcı olabileceği pratik açıdan, ekiplerin süreç boyunca kalite kontrolleri yapmasına izin veren süreçler oluşturmak gerekiyor. Böylece kalite sürecin bir parçası haline geliyor. Örneğin JIRA kullanıyoruz. JIRA'daki iş akışları, istersek kod inceleme kontrolleri oluşturmamıza ve bunları zorunlu kılmamıza izin veriyor. “Zorunlu” güçlü bir kelime olabilir; çünkü bu aslında işin hizmetinde olan bir süreç. Ancak bir iş devam ediyor durumundan hazırlık ortamına geçtiğinde kod incelemesinden geçmesini, hazırlık ortamından kalite güvencesine geçtiğinde de yeterli zaman ve kapsam sağlandığından emin olmak için başka bir süreçten geçmesini mümkün kılıyor.

Ben Aston:

Yani kaliteyi yalnızca “bileşeni oluşturduk, iş bitti, sonra belki kalite güvencesi yaparız” şeklinde düşünmek yerine sürecin içine entegre ediyorsunuz. Geliştirmenin bir parçası da test edilmesi oluyor. Bu güçlü bir yaklaşım. Geliştirme sırasında birim testlerini koda entegre etmekten söz ettin. Bu da şu soruyu doğuruyor: Manuel testlerimiz var; ancak otomatik testler de var. Otomatik testleriniz ne kadar güçlü ve ne zaman buna değeceğine nasıl karar veriyorsunuz? Kurulması uzun zaman alabiliyor. İş akışınızda bunu nasıl dengeliyorsunuz?

Michael Luchen:

Manuel testler çok değerlidir. Kolayca uygulanabilecek bir yöntemdir. Ancak kullanıcı deneyimi çok kapsamlı olduğunda otomatik testlerle karşılaştırıldığında özellikle değerlidir. Belki otomatik testler oluşturmak için harcanacak emek buna değmeyecektir. Bunun bir örneği, bir uygulamadaki sürükle ve bırak etkileşimi olabilir.

Öte yandan otomatik testler aynı şeyi tekrar tekrar yaptığınızda harika olabilir. Uzun ve karmaşık bilgi formları bunun iyi bir örneğidir. Test mühendisiniz, tüm uygulamalarımızın her zaman bayıldığı o çılgın karakterlerle otomatik doldurma kriterleri yazabiliyorsa ekstra puan kazanırsınız.

Ben Aston:

Kalite yönetim planına yaklaşımınızın, başlangıçtaki fikrimizle uyumlu olduğunu anlıyorum: İşleri doğru yapabiliriz; bunun için kaliteyi geliştirmenin entegre bir parçası olarak görmemiz gerekir. Ayrıca kalite ve test konusunda herkese uyan tek bir yaklaşım yerine, süreci projeye, hatta üzerinde çalıştığınız bileşenlere göre uyarlamak gerekiyor. Kalite yönetimi sürecini ve planlamasını oldukça organik, içinde bulunduğunuz duruma göre gelişen ve değişen bir şey gibi gösteriyorsun. Bu noktaya gelip “Oluşturduğumuz şey için doğru yaklaşımın bu olduğundan eminim” diyebilmek nasıl mümkün oluyor?

Michael Luchen:

İyi bir soru. Tereddüt ediyorum; çünkü organik sürecin büyük bir hayranıyım. Birkaç sprint boyunca hızımızı belirleyip projenin geri kalanında başarıya ulaşmak için kendimizi hazırlamayı düşünün. Kaliteye de aynı şekilde bakıyorum. Bir projeye başladığımızda her zaman ilk iyi yaklaşımımızı ortaya koyarız. Yazdığım kalite yönetim planı oluşturma makalesi, sağlam bir temel oluşturabilmeniz için iyi bir çerçeve sunuyor.

Ancak bu her zaman yalnızca bir varsayımdır. Özellikle ekip daha önce birlikte çalışmadıysa, ilk birkaç sprint veya birkaç hafta içinde doğal ve organik biçimde değişen ve gelişen şeyler olacaktır. “Tamam, burada biraz değişiklik ve akış olabilir” diyebilmeye açık olmak gerekiyor. Çok fazla değil; dramatik biçimde sapmamalı. Ancak ürünün ilk sürümüne geldiğimizde hedef cihazlarımızdan birinin hiç kimse tarafından kullanılmadığını fark edebiliriz. Bu durumda hedef cihaz listesini güncelleyebilmek ve zamanımızı ve enerjimizi diğer alanlara ayırabilmek için esnek olmamız gerekir.

Bu yönü benimsemek çok önemli. Benim için bir sonraki yeni projeye başlarken her zaman önceki projenin deneyimlerinden yararlanacağım; ancak yeni ekibin koşullarını ve ihtiyaçlarını da göz önünde bulunduracağım.

Ben Aston:

Bence sağduyu kalite yönetiminde büyük rol oynuyor. Dikkatli olmazsak “Kalite her şeyden önemlidir” yaklaşımına yönelebilir, çok sağlam bir kalite yönetim planı oluşturup çeşitli kontroller koyabiliriz. Ancak bu, benim için dokümantasyona benzeyen bir şeye dönüşebilir; yani daha organik davranmak yerine yalnızca yapmak gerektiği için bir şeyler yaparız.

Bir yandan kontrollerimizin ve planımızın olması, diğer yandan sağduyumuzu kullanıp ilerledikçe uyum sağlamamız gerekiyor. Bu da bizi yeniden konuştuğumuz Çevik yaklaşıma getiriyor. Kalite yönetim planına körü körüne ve dogmatik biçimde bağlı kalmamalı; işleri güvence altına almak için daha serbest keşif amaçlı testleri benimsemeli ve ilerledikçe uyum sağlamalıyız. Nihai amacımız değer sunmak ve bunu artımlı olarak gerçekleştirmek. Üzerinde çalıştığımız proje veya ürün zamanla değer kazanmalı ve sunduğumuz kalite de bunun bir parçası olmalı.

Michael Luchen:

Kesinlikle.

Ben Aston:

Yakın zamanda kardeş sitemizde bir podcast başlattık. Adı QA Lead. Kalite güvencesiyle ilgileniyor ve test mühendisleriyle veya kalite güvence uzmanlarıyla çalışıyorsanız, onlara QAlead.com adresine göz atmalarını söyleyin. Bir proje yöneticisi olarak siz de kontrol etmeye başlayın. Yazı çok ayrıntılı; üyelik aracılığıyla paylaştığımız örnekler ve şablonlar da var.

Daha önce kullanmadıysanız bir kalite yönetim planını deneyin. Sürecinizi, projenizi veya üzerinde çalıştığınız ürünleri nasıl düşündüğünüzü ve daha kaliteli bir ürün sunarak nasıl daha fazla değer sağlayabileceğinizi anlamanıza gerçekten yardımcı olacaktır.

Bu ipuçlarının hepsi çok değerliydi; ancak bende en çok karşılık bulan şey, kalite yaklaşımının kuruluş genelinde geliştirilmesi gereken bir konu olduğu fikriydi. Test mühendislerimiz olsun veya olmasın, kaliteyi yalnızca “Bu şey bozuk mu, değil mi?” şeklinde düşünmemeliyiz. Kalite aynı zamanda sürecimizin de bir yansımasıdır ve üzerinde düşünmemiz gerekir. Kuruluşun tamamında işler yolunda mı, bunları nasıl geliştirebiliriz? Daha yinelemeli bir anlayışa sahip olmalıyız. Michael, içgörülerini paylaştığın için çok teşekkürler.

Michael Luchen:

Teşekkür ederim.

Ben Aston:

Siz ne düşünüyorsunuz? Projeleri veya ürünleri kaliteli biçimde teslim etmek için hangi ipuçlarını, püf noktalarını ve yöntemleri kullanıyorsunuz? Nelerin işe yaradığını veya yaramadığını bize anlatın. Paylaşmak istediğiniz başarısızlık hikâyeleri ya da başarılarınız varsa aşağıdaki yorumlarda bizimle paylaşın.

Daha fazla öğrenmek ve işinizde öne geçmek istiyorsanız DPM üyeliğiyle topluluğumuza katılın. Slack ekibimize, şablonlara, atölyelere, danışma saatlerine, e-kitaplara ve daha fazlasına erişmek için thedigitalprojectmanager.com/membership adresine gidin. Bugün duyduklarınızı beğendiyseniz lütfen abone olun ve thedigitalprojectmanager.com üzerinden iletişimde kalın. Bir sonraki bölüme kadar dinlediğiniz için çok teşekkürler.