Gereksinimleri Kusursuzlaştırmak (BI Worldwide’dan Kelly Suter ile)

Transkripti Okuyun:

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

Ben Aston:

Daha iyi dijital projelere liderlik etmek için uzman PM tavsiyeleri sunduğumuz DPM Podcast'e hoş geldiniz. Bizi dinlediğiniz için teşekkürler. Ben, Digital Project Manager'ın kurucusu Ben Aston. Dürüst olun; müşteriniz projenizin sonunda hiç dönüp “Harika bir iş çıkardınız, tam olarak istediğimiz şey bu, projenin başında yapacağınızı söylediğiniz şeyin aynısını yaptınız ve her şeyi nasıl eksiksiz yakalayıp süreç boyunca hiçbir şeyi gözden kaçırmadığınız gerçekten inanılmaz” dedi mi?

Muhtemelen böyle bir şey olmadığını düşünüyorum. Bunun nedeni büyük ihtimalle gereksinimlerinizin doğru şekilde tanımlanmamış olmasıdır. Peki gereksinimleri nasıl yönetebilirsiniz ki projenin ilerleyen aşamalarında kendinizi büyük bir karmaşanın içinde bulmayın; aynı zamanda müşteriye ve geliştiriciye işi tamamlamak için bilmeleri gerekenleri sağlayın? Bugünkü podcast'in konusu tam olarak bu: proje gereksinimleri.

Bir projeyi ve müşterilerimiz için işlevleri, herkes teslim edilecekleri bilsin diye tanımlama biçimimizden söz ediyoruz. Bence gereksinimler esas olarak bir iletişim aracıdır; ancak doğru şekilde oluşturulmaları gerçekten zordur. Gereksinimleri çok gevşek tanımlarsak daha fazla esnekliğe sahip oluruz, fakat belki de tam olarak istediğimiz şeyi elde edemeyiz. Gereksinimleri çok katı tanımlarsak da pek çok şeyin eksik kaldığını görebiliriz. Peki bu dengeyi nasıl kuracağız?

Bugün Kelly Suter ile konuşuyorum. Kelly, BI Worldwide'da teknik proje yöneticisi ve Digital Project Manager'daki yerleşik Deakin uzmanlarımızdan biri. Merhaba Kelly.

Kelly Suter:

Merhaba, beni davet ettiğin için teşekkürler Ben.

Ben Aston:

Seni ağırlamak harika. Sanırım bu ikinci podcast'imiz, değil mi?

Kelly Suter:

Evet, öyle.

Ben Aston:

Uzun zaman önce bir podcast yapmıştık. Seni unutanlar için, proje yönetimine nasıl girdiğini kısaca anlatmak ister misin? Çoğu proje yöneticisininkine benzemeyen, ilginç bir yol izlediğini düşünüyorum. Çocukken proje yöneticisi olmayı planlamadık. Hikâyeni ve şimdi nasıl dijital PM olduğunu biraz anlatır mısın?

Kelly Suter:

Profesyonel kariyerime aslında spor muhabiri olarak başladım. İletişim, halkla ilişkiler ve medya odaklı eğitim aldığım için gazetelerin artık yükselen bir alan olmadığını fark ettiğimde tanıtım sektörüne yöneldim. Yaklaşık üç yıl halkla ilişkiler uzmanı olarak çalıştım; Sesame Street Live markası için görev yaptım ve yaklaşık üç yıl boyunca bu markayı yönettim. Daha sonra özel e-ticaret mağazaları geliştiren, tam hizmet sunan bir dijital ajansta çalışan biriyle tanıştım.

Bana “Burada proje yönetimi departmanımız yok, proje yöneticisi olmak ister misin?” diye sordu. Ben de “Bu nedir?” dedim. Babamın bir grafik tasarım ajansı vardı; bu nedenle büyürken ajans süreçlerine aşinaydım ve işlerin çok yoğun olduğunu biliyordum. Yine de “Evet, ilgileniyorum, bakalım orada neler var” dedim. İlk okuduğum kitap Meghan McInerny'nin İnsanlar, Pikseller ve Süreç kitabıydı. Kitabı okudum ve öğrendiklerimi uyguladım.

Ben Aston:

Hangisinden bahsettiğini biliyorum, evet.

Kelly Suter:

Evet. O kitabı karşımdaki ajansa elimden geldiğince uyguladım. O sırada 12 kişiydik. Özel broşür siteleri ve e-ticaret siteleri geliştiriyorduk. Yaklaşık dört yıl içinde yedi kişilik bir proje yöneticisi ekibi kurdum. Sürekli gelişen bir süreci uygulayabildik. Sonrasında Magento, Drupal, Cantego, WordPress ve benzeri teknolojilerle çalışırken kendimi rahat hissettiğimi fark ettim ve teknik bilgimi genişletmek istediğime karar verdim. Şu an çalıştığım BI Worldwide'da teknik proje yönetimi pozisyonu açılmıştı. Buraya geçtim; PM dünyasına dönmek, projelere daha yakından dokunmak ve teknik araçlarımı geliştirmek istiyordum. Şu an bulunduğum yer burası. Çok heyecan verici; zaman göz açıp kapayıncaya kadar geçti ama işimi kesinlikle seviyorum.

Ben Aston:

Her zaman merak etmişimdir: Şimdi hayalindeki iş bu mu? Spor muhabirliği, Sesame Street ve şimdi teknoloji sektöründe proje yöneticiliği gibi ilginç bir yol izledin. Peki büyüdüğünde ne olmak istiyorsun?

Kelly Suter:

Bu gerçekten iyi bir soru. Şu an yaptığım işte ve kısa süre önce çalıştığım diğer geliştirme şirketi Irish Titan'da en sevdiğim şey, bir sürecin henüz bulunmadığı ya da yeni gelişmeye başladığı ortamlara girmek. Ekibin çok yetenekli olmadığını veya iyi işler çıkarmadığını söylemiyorum; ancak süreç oluşturulabilecek, neyin işe yaradığını keşfedebileceğimiz zorlukları doğrudan ele almayı seviyorum. Ekiplere “Üzerinde çalışabileceğimiz, dayanabileceğimiz bir şey var” rahatlığını yaşatmak, süreçleri kurmak hoşuma gidiyor. Bu yüzden hayalimdeki iş, belki yeni kurulmuş işletmelere gidip bir itfaiyeci gibi sorunları çözmek ve “Bu süreci uyguladık; şimdi bunu ve bunu da deneyelim” diyebilmek. Çünkü gerçekten zorlu problemleri seviyorum.

Ben Aston:

Güzel. Peki şu anda karşılaştığın zorluklar neler? Süreçleri düzeltmeye ve oluştur­maya çalışıyorsun ama günlük olarak üzerinde çalıştığın belirli bir sorun var mı?

Kelly Suter:

Şu anda karşılaştığımız tüm zorluklar arasında en önemlisi, ekibin dokümantasyona sıkıcı olmayan bir şekilde destek vermesini sağlamak. Bu podcast'in konusunu satmaya çalışıyor gibi görünmek istemem ama heyecanlı bir müşteri ve heyecanlı bir ekip olduğunda “Yavaşlamak ya da ivmeyi kaybetmek zorunda değiliz; ancak dokümantasyon hazırlamamız gerekiyor” fikrine tam destek almak zor. Bu dokümantasyonu şablonlaştırmak ve temel noktaları yeterince kapsamak gerekiyor. Süreçleri gereğinden fazla zahmetli hâle getirmeden, farklı bir ekibe geçtiğinizde, terfi aldığınızda veya farklı bir role geçtiğinizde tüm mantığın ve sürecin kaybolmaması için yeterince dokümantasyon hazırlamalısınız.

Ekiplerin sürekli olarak ya ürün geliştirme süreçlerinde ya da dokümantasyonda tekerleği yeniden icat ettiğini gördüm. Oysa şablonlaştırılabilecek veya daha verimli hâle getirilebilecek şeyleri gereğinden fazla karmaşıklaştırıyorlar.

Şu anda ekibin desteğini almaya çalışıyorum. Üzerinde çalıştığım bazı şeylerin en son dokümantasyonu 2014 yılına ait. Bu dokümantasyon müşteri ve ekip için işe yaramış olabilir ama böyle kalmasını istemiyoruz. Daha sonra denetim yaptığınızda her şeyin düzenli ve güncel olması güzel.

Ben Aston:

Süreç tanımlama, dokümantasyon oluşturma ve süreci iyileştirme zorluklarıyla uğraşıyorsun. Bunu yaparken hayatını kolaylaştıran hangi araçları kullanıyorsun?

Kelly Suter:

Dokümantasyon özelinde, bozuk değilse düzeltme yaklaşımını benimserim. Bilgilerinizle ilgili güvenlik veya gizlilik sorunu yaşamayan müşterileriniz varsa Google Suite, Google Dokümanlar ve paylaşılan alanlar oldukça kullanışlıdır. Kimlerin yalnızca görüntüleyebileceğini, kimlerin yorum yapabileceğini belirleyebilirsiniz.

Böylece sürüm kontrolü hakkında düşünmeniz gerekmez. Daha sonra belgeyi PDF olarak dışa aktarabilir ve imzalanabilir resmî bir dokümana dönüştürebilirsiniz. Gerçek anlamda dokümantasyon yazmaya gelince kullandığımız araçlar bunlar. InVision, tasarım kontrolleri ve dengeleri için, yaratıcı çalışmaları yorumlamak için harika bir araçtır. Tasarımcılar tüm tasarımlarını veya tel kafeslerini buraya yükleyebilir. Müşteri ya da incelemeyi yapan paydaş yorum ekleyebilir. Tasarımlar tamamlandığında InVision'da açıklamalar ekleyebilir ve dokümantasyon için dışa aktarabilirsiniz. Görseller dokümantasyon için çok faydalıdır.

InVision kullanmıyorsanız, çünkü ücretli ve pahalı olabilir, Sketch'i kullanabilirsiniz. Sketch, InVision gibi bir bütçeniz olmadığında kullandığım bir araçtır. Tasarımları yükleyebilir, numaralarınızı veya harflerinizi ekleyebilir ve tasarımları basitçe açıklayabilirsiniz.

Gerçekten karmaşıklaştırmıyorum: Tasarımlarımı içe aktarmam, açıklama eklemem, dokümantasyona koymam ve metni yazmam gerekiyor. Dokümantasyon söz konusu olduğunda benim için işe yarayan araçlar bunlar.

Ben Aston:

Dijital proje yöneticisi olarak gelişimine dönmek istiyorum. Şimdi teknik bir PM'sin ama farklı roller üstlendiğini biliyorum: proje yöneticisi, iş analisti ve Scrum yöneticisi. Teknik PM, DPM'den nasıl farklı? Farklı rolleri üstlenmek senin için nasıl işliyor?

Kelly Suter:

Bu gerçekten iyi bir soru. Buradaki rolüm özelinde kendimi şanslı hissediyorum çünkü görevim benzersiz. BIW'de hem teknik proje yönetimi hem de geleneksel proje yönetimi yapıyorum. Canlı etkinliklerin ve içerik ile eğitim materyallerinin proje yönetimini üstleniyorum; bunlar yaptığım işin yaklaşık dörtte biri. Kalan dörtte üçü teknik proje yönetimi ve bu rol, baktığınız yere göre değişebilir.

Proje yönetiminin önünde dijital, teknik veya çevik gibi pek çok kelime görebilirsiniz. Önceki işimdeki gerçek DPM rolü ile şu anki TPM rolüm arasındaki en büyük fark, yaptığınız dijital çalışmanın arkasındaki anlayış düzeyidir. Dijital çalışmanız ne kadar teknik hâle geliyor? Dijital proje yöneticisiyken tüm hareketli parçalarla ilgileniyordum. Daha üst seviyedeydim ama içerik stratejisinin, site haritalamanın, tel kafeslerin ve yaratıcı çalışmaların ne olduğunu biliyordum. Geliştirme aşamasında ise “Bu veriyi denetlemeniz gerektiğini biliyorum; envanterinizin dışa aktarımının nasıl görünmesi gerektiğini belirlemeniz gerektiğini biliyorum, siz tamamladığınızda bana haber verin” diyordum.

Teknik PM rolünde ise geliştirme sürecinin ayrıntılarına çok daha fazla giriyorum. Yaratıcı çalışmaların, dijital stratejinin ve kalite güvencenin teslimatlarını hâlâ yönetiyorum; fakat geliştirme aşamasında kalite güvence sürecine daha yakından katılmam gerekebiliyor. Kod incelemeleri ve sürümler sırasında baş geliştiriciyle yan yana çalışıp “Bunlar yazdığım gereksinimler; kontrol listesinde işaretlenmeden önce gördüğün kodla nasıl karşılaştırılıyor?” diyorum.

Diğer fark, teknik gereksinimleri benim yazmam. Gereksinimlere ne kadar yakınsanız sorumluluğunuz da o kadar artar; ileride bu konular gündeme geldiğinde konuşmalara daha yakından katılmanız gerekir. Dijital PM olarak gereksinimleri yönetiyor, bunları yerine getirmesi gereken kişilere iletiyor ve tamamlanmalarını sağlıyordum. TPM olarak ise gereksinimleri bizzat yazıyorum. Geliştirme sürecinde siperlerin içine daha fazla giriyorum.

Ben Aston:

İşlevsel gereksinimlere veya iş gereksinimlerine aşina olmayan kişiler için: İşlevsel gereksinim tasarımı ve iş gereksinimi tasarımı yapıyorsun. Bu alan çoğu kişi için biraz karmaşık görünüyor; çünkü geliştirici açısından “Bu PM'in işi” veya “Bu iş analistinin işi, tanımlamak benim görevim değil” denebiliyor. Diğer taraftan BA veya PM de “Bunu tanımlayamam, seçeneklerin neler olduğunu bilmiyorum” diyebiliyor. Ortada duran bir rolde bunu nasıl yürütüyorsun?

Kelly Suter:

Her projenin başında, ekibe ilk katıldığınızda veya bir şirketle ilk kez çalıştığınızda roller ve sorumluluklar gerçekten anlaşılmalı. Bunlar tanımlanmış olsa bile müşteriye bağlı olarak gelişebilir veya değişebilir. Örneğin özel bir entegrasyon üzerinde çalışırken “Bu entegrasyon bir envanter gibi; farklı ürünlerin bulunduğu bir veritabanı. Bunların canlı olarak güncellenmesini, envanterde kaç tişört ve kaç küçük, orta ya da büyük beden olduğunu göstermesini istiyorum. Verilerin her gün belirli bir saatte güncellenmesi gerekiyor” diyebilirim.

Geliştiriciye ne olmasını istediğimi anlatabilirim ama o benden daha derine inebilir ve benim dokunamadığım bir noktaya ulaşabilir. Bunu anlamayabilirim. Anlıyormuş gibi davranamam ve davranmak da istemem. Oturup “Gereksinimlerin şu kısmını ben üstleneceğim. Bundan sonrasını tamamlamama yardım eder misin? Makalemde de söz ettiğim beş neden sorusunu soralım. Bu verinin neden bu şekilde doldurulması gerekiyor? Çünkü ziyaretçiler bu ürünü şu sıklıkta satın alıyor. Peki neden?” demek isterim.

Bir noktada sınır çizip “Geliştirici, bu işlevle ilgili gereksinimlerin geri kalanını yazmama yardım etmelisin; çünkü bunu tek başıma yapamam ve anlamadığım için bir şeylerin gözden kaçması riskini almak istemiyorum” demeniz gerekir.

Bu bir denge meselesidir. Önceden neleri yapabileceğinizi belirlemelisiniz. Daha önce “Bunu neden sen yapıyorsun? Bunu iş analistinin veya öğrenme stratejistinin yapması gerekmiyor mu?” diye soruldu. Cevabım “Elbette bunu ekibinizden isteyebilirsiniz. Ancak kendinize şu soruyu sormalısınız: Gereksinimleri yazmaları için bütçenin ne kadarını ayırmaya hazırım? Sonra herkesin inceleme yaptığı kontrolleri ve dengeleri nasıl kuracağım? Gereksinimleri sizin yazmanız mı yoksa başkasının yazması mı daha verimli?” olur.

Bu bir denge işidir ve değişecektir. İnsanlar kimin neyi sahiplendiğini kişisel mesele hâline getirmediği, birbirlerinin güçlü yönlerinden yararlandığı sürece iş yoluna girer. Ancak bunun etrafında iletişim kurulmalıdır.

Ben Aston:

Bunu dinleyip “İş gereksinimi tasarımı nedir, işlevsel gereksinimler nelerdir?” diye düşünenler olabilir. Bir ajans veya stüdyo olarak tasarımları yapıp geliştiricilere devrediyor, sonra da geliştirilmesini bekliyor olabiliriz. Dokümantasyondan söz ediyorsun. Bu yapmamız gerekenin tam tersi değil mi? Çevik ve esnek olmamız gerekmiyor mu? Bu dokümanlar nedir ve neden önemlidir?

Kelly Suter:

İş gereksinimleri dokümantasyonundan söz ederken buna bundan sonra İGD, işlevsel gereksinimler dokümantasyonuna da İGDD diyeceğim. İGD'yi bir dersin giriş seviyesi dersi gibi düşünebilirsiniz. Genellikle şu üst düzey maddeleri içerir: Bunun İspanyolca ve Mandarin diline çevrilmesi gerekiyor. On farklı eğitim sunmamız gerekiyor. Nisan ayına kadar yayında olmalı. 6.000 kullanıcılık bir veritabanını veya bu miktardaki trafiği destekleyebilmeliyiz.

İGD temel olarak “Şimdiye kadar konuştuklarımız bunlar; herkes doğru yöne baksın” anlamına gelir. Her iki taraftaki herkesin “Evet, aynı noktadayız” diyerek onay verdiği resmî bir kontrol noktasıdır. Elbette dokümanda gereksinimlerin daha sonra ayrıntılandırılacağı da belirtilir. Kapsam dışına çıkan veya bütçeyi aşan konular ortaya çıkarsa bunu bildireceğimizi, öncelikleri yeniden belirleyeceğimizi ve ikinci aşamaya neyin aktarılacağına karar vereceğimizi söyleriz.

İGDD ise başka bir kontrol noktasıdır ve İGD ile İGDD arasında çok şey olur. Her bir maddeyi daha fazla ayrıntıyla genişletirsiniz. Çevirileri İspanyolca ve Mandarin dilinde üçüncü taraf bir tedarikçi aracılığıyla mı yapacağız? Bunun için kod mu yazacağız? İçerik yönetim sisteminde yöneticilerin üç dili ayrı ayrı elle girmesi mi gerekecek? Tüm bu noktaları ayrıntılandırırsınız.

İGD, herkesin aynı noktada olduğunu gösteren bir kontrol noktasıdır. İGDD'nin kapsamı kesinlikle büyüyecektir; ancak örneğin çevirinin mevcut bütçeleri için erişilebilir olmadığını fark edebilir ve bunu ikinci aşamaya erteleyebilirsiniz. Bunu İGDD'de belgelersiniz ve geri kalan her şeyi tanımlamaya odaklanırsınız.

Bir belge diğerine dönüşür. İGDD, geliştirme sürecinin planı olmalıdır.

Ben Aston:

İGD'yi projenin başında tanımlıyoruz. İş açısından başarının neye benzediğini belirliyoruz. Proje başarıyı nasıl sağlayacak ve hangi noktalara değinmemiz gerekiyor? İşlevsel gereksinimde ise işlevin nasıl çalışacağını tanımlıyoruz. Örneğin sitenin Çin'deki kişiler tarafından erişilebilir ve okunabilir olması gerekiyor; bu nedenle Mandarin dilinde olmalı ve yerelleştirilmelidir.

Çeviklik konusuna gelirsek: Bazı geliştiriciler “Gereksinimleri gösterin; gereksinim olmadan hiçbir şey yapamam” der. Aynı geliştiricilere gereksinimleri verdiğinizde ise “Böyle çalışmamalıyız; çevik olmalıyız, işlevin küçük bir bölümünü teslim edip üzerinde yinelemeli çalışmalıyız, bu kadar çok dokümantasyona gerek yok” diyebilirler. Yinelemeli yaklaşım ile dokümantasyonu sınırlamaya ve deneme-öğrenme yöntemine çalışırken bu dengeyi nasıl kuruyorsun?

Kelly Suter:

Bu dengeyi önceden ortak bir anlayış oluşturarak kurarsınız. Bir miktar dokümantasyon hazırlayıp “Çevik bir sürece ilerleyeceğiz. Bunun anlamı bu. Müşteri tarafından şunlara, içeride ise bunlara ihtiyacımız var” dersiniz. Sağlam bir başlangıç toplantısı yaparak üzerinde çalıştığınız ürünü açıklarsınız.

Örneğin şu anda öğrenmeyle puanları ilişkilendiren bir yazılım geliştiriyoruz. Eğitim materyallerini tamamlıyor, ilerleme kaydediyor ve puan kazanıyorsunuz. Bu puanlar daha sonra bir pazaryerinde kullanılabiliyor. Arka planda pek çok mantık var ve neyi bilmediğimizi bilmiyoruz.

Müşteri ürünü istiyor ve ocak ayına kadar hazır olmasını bekliyor. Bize güveniyorlar; geçmişte birlikte birçok iş yaptık. Tüm dokümantasyonu hazırlamak için zamanımız yok. Bu nedenle son hedefi bilerek “Harika, hedefimiz bu” diyorum. Ara adımların tamamını ve bütün görevleri ayrıntılı biçimde tanımlamadan, haftalık toplantılarımızda “Sen rozetler üzerinde, sen sertifikalar üzerinde, sen liderlik tablosu üzerinde, sen de alışveriş deneyimi üzerinde çalışıyorsun” diyoruz.

Müşteriyle iki haftada bir sürüm ve sunum yapıyoruz. İnceledikleri şeyin yalnızca kaba bir taslak olduğunu, ön yüzünün henüz cilalanmayacağını ve asıl amacın işlevselliği oluşturmak olduğunu biliyorlar. Bu nedenle haftalık toplantılar çok değerlidir. PM olarak toplantıları belgeleyebilirsiniz: “Bugün rozetleri bu eğitim materyaliyle ilişkili hâliyle gösteriyoruz. Geçen hafta yaptıklarımız nedeniyle şu sonuçları görmeyi bekleyebilirsiniz. Bu rozet için mantığın şu şekilde olmasını ister misiniz?”

Müşteriyle toplantı yapıp onlara çalışmayı gösterdiğinizde “Ben bunu böyle sanıyordum” diyebilir. Bu noktada endişelerini ifade edebilecekleri bir güven ortamı oluşur. Siz de bunları yanıtlar ve sonraki hafta için bir plan hazırlarsınız. Zor ama gerekli olan şey, sürekli olarak projenin gidişatını kontrol etmektir.

Ben Aston:

İşte böyle.

Kelly Suter:

Ürünün tamamlanmasına kadar nasıl ilerlediğimizi kontrol ederiz. Sertifikaların şu anda yetişmeyeceğini, bu nedenle başka bir şeye odaklanmamız gerektiğini görebiliriz. Sürekli iletişim kurmak, süreç boyunca dokümantasyon hazırlamak ve güven oluşturmak gerekir.

Ben Aston:

Projeyi daha başlangıçta durdurabilecek şeylerden biri, her şey tanımlanana kadar beklemektir. Tüm projenin işlevsel gereksinimlerini tanımlamak çok uzun sürebilir. Gereksinimler geliştiricilere tam olarak ne inşa etmeleri gerektiğini, müşteriye ne elde edeceklerini ve kalite güvence ekibine neyi test edeceklerini gösterir. Ancak süreç ilerledikçe gelişmeleri gerekir.

Bu dokümantasyonu nasıl hazırlıyorsun? Bir görev yazarken JIRA'da mı yapıyorsun?

Kelly Suter:

Tamamlanmış bir İGDD hazırlarken bunu tek başıma ve kimseye danışmadan yapmıyorum. Ekip üyelerine ilerledikçe sorular soracağımı söylüyorum. Bunun en iyi uygulamalarla mı ilgili olduğunu, yoksa önceki bir toplantıda konuştuğumuz bir konuya mı dayandığını kontrol ediyorum.

İGDD tamamlandığında herkes incelemiş ve müşteri onaylamış oluyor. Daha sonra iki yöntemden birini kullanıyorum. Geliştirme ekibine sunarken bazı geliştiricilerin gereksinimlerin kendilerine verilmesini, görevlerinin açıkça belirtilmesini ve tahmin yapabilmelerini istediğini biliyorum. Başka geliştiriciler ise “Görevlerimi nasıl yapacağımı söyleme; onları bu sırayla yapmazdım” diyebilir.

Bu nedenle toplantıda önce “Bu görevleri kendiniz mi oluşturmak istersiniz, yoksa benim oluşturmamı mı tercih edersiniz?” diye sorarım. İGDD'yi inceledikleri için çoğunlukla görevleri benim oluşturmamı kabul ederler. Her satır maddesi için bir görev oluştururum. Hikâyeleri sayfa türüne göre düzenlerim: kayıt sayfası, ana sayfa veya ürün sayfası gibi. Ardından her sayfa türündeki satır maddeleri için alt görevler oluştururum.

Geliştiriciler gereksinimleri ve beklentileri bildiği için tahminlerini kendileri yapmalıdır. Mümkünse işi gerçekten geliştirecek kişinin tahmin yapmasını sağlayın. En iyi geliştiricilerinizin her şeyi tahmin edip daha sonra işi kıdemsiz bir geliştiriciye vermeyin.

Görevleri JIRA ve Atlassian paketini kullanarak yönetiyorum. İş listesini oluşturduktan sonra geliştiricilerden tahmin yapmalarını istiyorum. Görevleri hangi sırayla ele alacaklarını belirtmelerini ve yaklaşık olarak sıralamalarını istiyorum. Daha sonra tek bir iş parçacığında çalışıyorlarsa 30 veya 30-35 saatlik haftalara göre sprint'lere ayırıyorum. Çevik çalışıyorsanız her göreve bir kalite güvence adımı ekleyin ve test kaynağınızın görevin başarılı olup olmadığını nasıl kontrol edeceğini yazmasını sağlayın.

Ben Aston:

Tahmin konusuna değinmek istiyorum. Teknik projelerde bu giderek daha büyük bir zorluk hâline geliyor. Projenin başında müşteri maliyeti bilmek istiyor, ancak işlevselliği henüz tam olarak bilmiyoruz. Müşteriye “Bunun maliyeti yaklaşık 200 bin olacak” demek için iş gereksinimlerini mi temel alıyorsun? İşlevsel gereksinimleri daha ayrıntılı tanımlayıp gerçek tahminlere nasıl ulaşıyorsun?

Kelly Suter:

Bu çok kapsamlı bir soru. Projelerimin PM'i olarak yaklaşık tahmin vermeye katkıda bulunma yetkim olsaydı, zamanın yüzde 90-95'inde tahmine ilişkin görüş bildirme yetkim olmadığını söylerdim. Bazen bir müşteriyle ilgili “Harika bir fikirleri var; sence bunu mart ayına kadar yapabilir miyiz?” diye sorulur. Benim aklıma hemen yüzlerce soru gelir.

Bir tahmin istendiğinde önce daha üst düzeyde daha önce ne yaptığımızı bilmek isterim. Şirketlerin genellikle bir uzmanlık alanı vardır. Geçmişte yaptığımız işlere bakar, kullanıcı tabanının veya şirketin büyüklüğü gibi benzerlikleri bulur ve bunları karşılaştırma noktası olarak kullanırım.

Örneğin daha önce Magento ile yaptığımız bir e-ticaret geliştirmesi altı ila sekiz hafta sürmüştü. İki geliştiriciyle, büyük ölçüde tek iş parçacıklı çalışarak varsayılan süre altı ila sekiz haftaydı. Ancak bu saat veya para tahmini değildi; yalnızca dayanabileceğimiz bir referans noktasıydı.

Satış veya iş geliştirme ekiplerine “Bilmiyoruz” derim. Entegrasyon ve özelleştirme yoksa, kullanıma hazır bir çözümse yaklaşık olarak ne olacağını söyleyebiliriz. Fakat daha ileri düzeyde tahmin yapmak zordur. Geliştirme lideri veya teknik PM bu konuda yardımcı olabilir. Bu nedenle arka cebinizde e-ticaret, öğrenme yönetim sistemi veya başka bir alan için benzer işlerin özetlendiği tek sayfalık bir doküman bulundurmanız yararlı olur.

Ben Aston:

Bunun benzer projelere dayalı tahmin olduğunu söylüyorsun. Gereksinimler tam olarak belli değilken erken aşamada yapılabilecek en iyi şey, benzer üç projeyi bulup düşük ve yüksek aralıkları göstermek. Daha sonra gereksinimleri tanımlayana kadar tek bir sayıya bağlanmamak. Keşif sürecinin gereksinimleri tanımlamak olduğunu müşteriye anlatmak ve gereksinimler netleştikçe tahmini ayrıntılandırmak.

Kelly Suter:

Evet. Her zaman yaptığım iki kısa çalışma var. İlki başlangıç toplantısında kapsam, zaman çizelgesi ve bütçeden oluşan bir üçgen çizmek. Bunları önem sırasına göre birden üçe kadar derecelendirmelerini istiyorum. Genellikle “Hepsi önemli” derler. Sonra “Gerçekten seçim yapmanız gerekseydi sıralamanız nasıl olurdu?” diye sorarım. Bu sıralama süreç içinde değişebilir; örneğin yeni mali yıl başladığında bütçe en önemli konu olmaktan çıkabilir.

İkinci çalışma iyi-daha iyi-en iyi yaklaşımıdır. Müşterinin bir bütçesi varsa “Bu bütçe içinde kalmayı ben de sizin kadar isterim. Ancak yeni bir entegrasyon ortaya çıkarsa veya üçüncü taraf bir tedarikçi kapsamı genişletirse, bunu bütçenizi aşarak yapabiliriz; bütçe içinde kalırsak kapsamın bir kısmını çıkarabiliriz ya da ikisinin arasında bir seçenek belirleyebiliriz” dersiniz.

Müşterinin bu zor kararı vermesini sağlayın. Böylece yalnızca “Bu olmayacak” demek yerine müşteriyi iş birliğine dayalı karar sürecine dahil etmiş olursunuz.

Ben Aston:

Bu gerçekten iyi. Müşteriyi sürece dahil etmek, özellikle sabit fiyatlı ve yeni entegrasyonlar ya da bilmediğimiz bir platform içeren teknik projelerde çok önemli. İşlevselliği genişletmenin daha fazla çalışma gerektirdiğini açıklayabiliriz. Tahminleri ve yaklaşımı, müşterinin önceliklerine göre uyarlayabiliriz.

Son olarak, gereksinim yazmaya yeni başlayan biri için ilk adım ne olurdu? Daha önce yalnızca tel kafesleri ve tasarımları olup doğrudan geliştirmeye geçen biri gereksinimleri nasıl tanımlamaya başlayabilir?

Kelly Suter:

Dijital proje yöneticisi rolüne ilk kez giriyorsanız, dijital çağda yaşayan ve akıllı telefonlar, tabletler ve her türlü teknolojiyle karşılaşmış biri olarak bildiğinizden fazlasını biliyorsunuz. Dijital davranışlara maruz kaldınız, alışkanlıklar edindiniz ve teknik çağda bugüne kadar başarılı oldunuz.

Teknik dokümantasyon şablonunu arayıp indirmek ve boşlukları doldurmaya çalışmak yerine önce geri adım atın. “Bu müşteri için ne yapıyoruz? Bir etkinlik için kayıt sayfası oluşturuyoruz; ana sayfası var ve ana sayfada bir web formu bulunuyor. Burada neyi tanımlamamız gerekiyor?” diye sorun.

Sayfadaki her ögeyi bulun ve “Bu, mobilde ve masaüstünde ne yapıyor?” diye sorun. Hâlâ tuğla gibi bir Nokia telefonu kullanan birinin büyükannesine açıklıyormuşsunuz gibi kendinize yüksek sesle anlatın. Daha sonra geliştiricinize gidip “Bunu doğru varsayıyor muyum?” diye sorun. Geliştiriciniz, doğru soruları sormanızı ve onların da başarılı olmasını sağlayacak şekilde tanım yaptığınızı takdir edecektir.

Gereksinim dokümantasyonuna yeni başlıyorsanız, oluşturduğunuz şeyi ögelere ayırın ve açıklayın. İlk dokümantasyonum muhtemelen olması gerekenden daha konuşma diline yakındı ve aynı işlevi farklı sayfalarda tutarlı biçimde tanımlamamış olabilirim. Bu sorun değil; süreç gelişecektir. Müşteriniz muhtemelen her gün dijital proje yapmıyor. Siz şirketinizi, grubunuzu veya ekibinizi temsil eden uzman kişisiniz. Projeyi müşterinizle birlikte adım adım inceleyin ve aslında düşündüğünüzden daha fazlasını bildiğinizi unutmayın.

Ben Aston:

Bu gerçekten yararlı. Gereksinimler aslında soru sormak ve soruları yanıtlara dönüştürmekle ilgilidir. Gereksinimleri tanımlamaya başladığımızda “Bu aptalca bir soru mu, yoksa bu zaten açık mı?” diye düşünebiliriz. Ancak hiçbir şeyin gerçekten açık olmadığını anlamak önemli. Bunu annenize veya büyükannenize açıklayacak olsaydınız ona ne söylemeniz gerektiğini düşünerek başlayabilirsiniz.

Gereksinimlerin, herkesin ne yapılacağı konusunda aynı noktada olmasını sağlayan bir iletişim aracı olduğunu hatırlamak gerekir. Ne yaptığınız konusunda netlik olduğunda beklenti yönetimi için harcanan emek azalır. Herkes teslim edilecekleri bilir ve daha az zaman kaybedersiniz. Dokümantasyonu oluşturmak zaman alabilir; ancak yeniden çalışma yapmadığınızda veya müşteri beklediğinden farklı bir şey elde edip hayal kırıklığına uğramadığında bunun karşılığını fazlasıyla alırsınız.

Kelly, bize katıldığın için çok teşekkürler.

Kelly Suter:

Teşekkür ederim, burada olmak benim için de çok değerliydi.

Ben Aston:

DPM uzmanlarımızdan biri olan Kelly, Dijital Proje Yönetiminde Ustalaşma kursumuzda da yer alıyor. Ne hakkında konuştuğumu bilmiyorsanız ama PM eğitimine ihtiyacınız olduğunu düşünüyorsanız kursumuza göz atın. Yedi haftalık yoğun bir programımız var; etkileşimli video dersleri, ödevleri, grup tartışmalarını ve web seminerlerini içeriyor. dpmschool.com adresine giderek kaydolabilirsiniz. Kursumuz şubatta başlıyor.

Gereksinimler ve bunları nasıl yönettiğimiz hakkındaki bu konuşmaya katkıda bulunmak isterseniz, ilginç konuşmaların sürdüğü kaynaklar bölümüne giderek Slack ekibimize katılabilir veya gönderiye yorum bırakabilirsiniz. Bir sonraki bölüme kadar bizi dinlediğiniz için teşekkürler.