Kapsam Kaymasını Kontrol Etmek (Suze Haworth ile)

Transkripti Okuyun:

Podcast yayınlarımızı bir yazılım programı kullanarak yazıya dökmeyi deniyoruz. Bot her zaman yüzde 100 doğru olmadığı için lütfen yazım hatalarını mazur görün.

Ben Aston:

Daha iyi dijital projelere liderlik etmek için uzman tavsiyeleri sunduğumuz DPM podcast'ine hoş geldiniz. Bizi dinlediğiniz için teşekkürler. Ben, The Digital Project Manager'ın kurucusu Ben Aston. Şimdi, neredeyse her projeyi rayından çıkaran tek bir şey varsa, o da kapsam kaymasıdır. Bunun kötü olduğunu hepimiz biliyoruz. Hepimiz bundan kaçınmak istediğimizi biliyoruz. Peki kapsam kaymasını tüm farklı biçimleriyle nasıl tanıyabilirsiniz? Buna ne sebep olur? Kimin hatasıdır? Daha da önemlisi, bununla gerçekten nasıl başa çıkabilirsiniz? Bugünkü podcast'te, proje kapsamındaki kaymaları kontrol etmekten bahsederken tüm bunlar ortaya çıkacak.

Bu podcast, kurumsal projeler ve proje yönetimi yazılımları alanında lider olan Clarizen tarafından sunulmaktadır.

clarizen.com adresinden daha fazla bilgi edinin

Bugün Suze Hayworth ile birlikteyim. Suze, The Digital Project Manager'daki yerleşik DPM uzmanlarımızdan biri ve Birleşik Krallık'ın Londra şehrinde serbest çalışan Kıdemli Dijital Proje Yöneticisi olarak görev yapıyor. Ajanslarda 10 yılı aşkın deneyime sahip ve çok fazla kapsam kayması yaşamış; bu nedenle bugün bizimle konuşmak için harika bir konuk. Suze, hoş geldin.

Suze Hayworth:

Merhaba Ben.

Ben Aston:

Suze, kayda başlamadan önce konuşuyorduk. Şu anda üzerinde çalıştığın projelerin türü hakkında biraz bilgi verebilir misin? Karşılaştığın bazı zorluklar neler?

Suze Hayworth:

Evet, şu anda Londra'daki bir ajansta serbest çalışıyorum. İki hesap arasında kıdemli proje yöneticisi ve proje direktörü rollerini paylaşıyorum. Bunlardan birinde IKEA için çalışıyorum; büyük bir perakende ve e-ticaret şirketi. Onlar için bir tasarım sistemi geliştiriyoruz; bir tür prototip tasarım sistemi. Ayrıca Birleşik Krallık'taki başka bir e-ticaret perakendecisi üzerinde çalışıyorum. Yani şu anda çok sayıda perakende projesi var. Zorluklara gelince, sanırım zorluklar hakkında konuşmak her zaman zor; özellikle de projeler hâlâ devam ederken. Evet, bence—

Ben Aston:

O sorun çıkaran müşteri mi?

Suze Hayworth:

Hayır, aslında değil. Gerçekten çok iyiler; bunu söylemem gerekiyor.

Ben Aston:

Söylemen gerekiyor.

Suze Hayworth:

Bu doğru. Şu anda birlikte çalıştığım müşteriler gerçekten çok iyi. Sanırım projelerin ve genel olarak proje yöneticisi olmanın iyi ve kötü tarafı insanlarla çalışmak. İnsanlarla, farklı karakterlerle, farklı tuhaflıklarla çalışmayı seviyorum. Ama bazen bir şey yapmak istemeyen insanlardan bir şeyler çıkarmaya çalışırken hayal kırıklığına uğradığınız bir noktaya da geliyorsunuz. Son zamanlarda bunun birazını yaşadım sanırım.

Ben Aston:

Eğlenceli ve hareketli günler. Peki tasarım sistemi oluşturma projesinden biraz bahset. Bence bu ilginç bir proje ve aslında giderek daha fazla gördüğümüz türden bir proje. Daha önce herkes her projeyi özel bir proje gibi ele almayı severdi; yaratıcılar da yaratıcı olmak isterdi. Peki tasarım sistemi nedir? Gerçekte üzerinde çalıştığın proje ne? Bunu nasıl uyguluyorsunuz?

Suze Hayworth:

Gerçekten heyecan verici bir proje çünkü söylediğin gibi tasarım sistemleri dijital dünyada giderek daha fazla kullanılmaya başlanıyor. Temel olarak şirketlerin ve markaların dijital tasarımları için bir stil kütüphanesi gibiler. Tasarım bileşenleri, modülleri ve şablonları için bir temel oluşturuyorlar. Markayla çalışan herhangi bir tasarımcı veya geliştirici bunları alıp kendi tasarımlarını ve kodlarını geliştirmek için kullanabiliyor. Yani bu bir temel oluşturuyor ve verimliliği destekliyor: yeniden kullanılabilir kod ve tasarımlar, ayrıca şirket içinde verimlilik ve tutarlılık sağlıyor.

Örneğin IKEA çok büyük bir marka ve onun için çalışan birçok farklı ajans, kişi ve kuruluş var. Böyle bir tasarım sistemi, tasarımcıların ve geliştiricilerin üzerinde çalışabileceği bir standart oluşturabilir. Bir sayfadaki düğmenin, yani harekete geçirici mesajın, farklı platformlarda, cihazlarda ve uygulamalarda tutarlı olmasını sağlayabilir. Kullandıkları dijital alanlar ne olursa olsun.

Ben Aston:

Bu projeyi yönetme sürecini anlatabilir misin? Bir bakıma “ip ne kadar uzun?” türünde bir proje olabilir. Nereden başladınız? Neyi yineleyerek geliştiriyorsunuz? Ürün nerede sona eriyor?

Suze Hayworth:

IKEA için birçok marka bunu aslında kurum içi bir proje olarak yürütüyor. IKEA bu konuda destek ve yardım almak ve tasarım sürecine dâhil olmamız için dışarıya başvurdu. Bence bu gerçekten akıllıca bir hamleydi çünkü dışarıdan gelen kişiler olarak şirkete fazlasıyla gömülmeden işleri değerlendirebiliyoruz. İlk olarak kavramsal açıdan değerlendirmeler yaptık: temel dijital ilkeleri, tasarımımızın arkasındaki düşünceyi ve IKEA'nın marka ve tasarım ilkelerini inceledik. Bu başlangıç aşamasıydı; tüm deneyime ve arkasındaki tasarım ilkelerine daha stratejik bir bakıştı. Ardından tasarımlara daha fazla odaklandık ve mevcut temel unsurlara dayanarak bir temel tasarım oluşturduk. Renk, tipografi ve ızgaralar gibi unsurları ele aldık ve buradan ilerledik.

Daha sonra bu tasarımla IKEA'nın farklı dijital alanlarından seçtiğimiz birkaç platform üzerinde kullanıcı testleri yaptık. Ardından belirli bileşenleri tasarlayıp geliştirmeye ve bunları bir tasarım sistemi sitesinde yayımlamaya geçtik. Site şu anda yalnızca kurum içinde kullanılıyor. Şimdilik baktığımız şey, sistemi çalışır hâle getirmek için kullanılabilecek daha esnek bir prototip. Bu aşamanın sonunda tam bir çözüme dönüştürülecek.

Ben Aston:

Bu tam çözüm nasıl olacak? İnsanların alıp kullanabileceği parçaları bulunan, yaşayan ve gelişen bir stil kılavuzu mu? Yoksa alabilecekleri şablonlar mı olacak?

Suze Hayworth:

Bence her tasarım sistemi projesinin sürekli gelişen, yaşayan bir yapı olması gerekir. Sonlu bir bitiş noktası olmamalı. Öylece durdurduğunuz bir ürün gibi olmamalı. Geliştirilmeye devam etmesi gerekir. Biz daha yeni başladık ve ilkeler, temeller ve bileşenler açısından henüz yüzeysel bir başlangıç yaptık. Bundan sonra bu bileşenleri gruplandırmak, modüller ve şablonlar geliştirmek, insanların sistemi nasıl kullanacağını ve yaygınlaştıracağını düşünmek gerekiyor. İnsanları sisteme dâhil etmek de önemli. Bu, özellikle şirket içinde çok sayıda farklı tarafın yer aldığı düşünüldüğünde çok büyük bir proje. Yani neredeyse bir yıldır devam ediyor olsa da hâlâ başlangıç aşamasındayız.

Ben Aston:

Eğlenceli bir projeye benziyor. Son zamanlarda hayatını kolaylaştıran herhangi bir araç bulup bulmadığını sormayı seviyorum. Son zamanlarda okuduğun veya keşfettiğin, başkalarının da bilmesi gerektiğini düşündüğün bir şey var mı?

Suze Hayworth:

Dürüst olmak gerekirse son zamanlarda farklı araçlar kullanmadım. Bildiklerimi kullanmaya devam ediyorum. Ama bir podcast'te olduğum düşünülürse bu biraz ironik; son zamanlarda daha fazla podcast dinliyorum. Normalde işe giderken, işe gidiş yolundaki bir saatlik yolculukta müzik dinlerdim. Ama son zamanlarda bu zamanı biraz daha faydalı kullanmaya başladım ve çeşitli podcast'ler dinliyorum. Öğrenmenin başka bir yolu olduğu için gerçekten iyi oldu.

Ben Aston:

Sana gerçekten faydalı veya ilginç gelen podcast'ler var mı?

Suze Hayworth:

The Digital Project Manager podcast'ini söylemek zorundayım, kesinlikle. Bu zaten belli. Ayrıca yakın zamanda başka bir podcast'e katıldım. DPM Zirvesi oturumumdan sonra oturumumun konusu hakkında konuştuk. The Bureau of Digital'ın da iyi yayınları var. Zirveyi yöneten Brett yakın zamanda kendi kitabındaki Dijital Proje Yönetimi hakkındaki fikirlerden yola çıkan “Sprintler ve Kilometre Taşları” adlı bir yayın hazırladı; oldukça faydalı bir kaynak.

Ben Aston:

Güzel. Podcast'lerinizi dinlemeye başlayın. Son zamanlarda çok ilginç bulduğum bir şey var: Blinkist. Dürüst olmak gerekirse kendi konuştuğum podcast'ler dışında çok fazla podcast dinlemiyorum. Ama her zaman “Bu kitabı gerçekten okumalıyım” diye düşünüyorum; sonra kitabı satın alıp okumaya hiç fırsat bulamıyorum. Blinkist'te kitapların çok kısa özetleri bulunuyor. Kitabın ana fikirlerinin özeti yaklaşık 15 dakikada okunabiliyor veya dinlenebiliyor. Bir podcast gibi düşünebilirsiniz. Ayrıca oynatma hızını artırabiliyorsunuz. Normal hızda veya iki kat hızda dinleyebiliyorsunuz. Böylece bir kitabı yedi buçuk dakikada okuyabiliyor ya da dinleyebiliyorsunuz.

Suze Hayworth:

Bu harika. Bunu denemeliyim çünkü ben de son zamanlarda daha fazla okumaya çalışıyorum. Daha fazla kitabı araya sıkıştırabilmek iyi olur.

Ben Aston:

İşte size kitap okuma önerim: Blinkist. Neyse, bugün kapsam kayması hakkında konuşmamız gerekiyor. O hâlde kapsam kaymasından bahsedelim. Konuya yabancı olanlar ve daha önce kapsam kaymasını duymamış olanlar için: Bu nedir ve neden önemsemeliyiz?

Suze Hayworth:

Temel olarak kapsamınızın, yani teslimatlarınızın, üzerinde anlaştığınız her şeyin ve projedeki özelliklerin, başlangıçta üzerinde anlaştığınız hâlin ötesine geçmesi veya büyümesi demektir. Bu değişiklikler için ek zamanı hesaba katmadığınızda sorun ortaya çıkar. Proje bundan çeşitli şekillerde etkilenebilir; işler planlanmadan içeri sızmaya ve kapsamı genişleterek projenizdeki sürelerin aksamasına başlayabilir.

Ben Aston:

Yani hesaba katmadığımız ek işler ortaya çıkıyor ve bunlar bütçemizi, takvimimizi ve yaptığımız iş miktarını etkiliyor. Bunun birçok nedeni var. Yapacağımızı düşündüğümüz veya planladığımız iş birdenbire büyüyebiliyor. Kendi üzerimize iş yaratma konusunda oldukça iyiyiz. Yazdığın makalede bunun birçok nedeni olduğunu söylüyorsun.

Suze Hayworth:

Evet, çok fazla neden var.

Ben Aston:

Sence en tipik nedenler hangileri? Önce en yaygın olanları, sonra da en sinsi olanları konuşalım.

Suze Hayworth:

Gördüğüm en yaygın nedenlerden biri, başlangıçta kapsamı net biçimde tanımlamamaktır. Bir projenin başında teslimatları belirlerken ve bir iş kapsamı belgesi hazırlarken ifadeleriniz çok belirsizse veya ne teslim ettiğinizi yeterince kesin biçimde tanımlamadıysanız, bu durum daha sonra karşınıza çıkar. Müşteri veya kurum içindeki kişiler yazdıklarınızı farklı anlamlara çekebilir. Böylece teslimatların başlangıçta belirsiz tanımlanması nedeniyle proje büyümeye başlar.

Bu nedenle ilk konu, kapsamı baştan netleştirmektir. Ayrıca kapsamı onaylayan kişinin ne alacağını açıkça anlamasını sağlamalısınız. İş kapsamı belgesi tüm teslimatları ve proje çalışmalarını ortaya koymak açısından harikadır; ancak genellikle uzun bir belgedir. Müşteriye bu belgeyi verip içindeki her şeyi okuyup anlamasını beklemek yerine, projenin temel noktalarını, teslimatlarını, zamanlamasını ve bütçesini açıkça vurgulamak gerekir. Belgeyi okuduğunu düşünseniz bile geri bildirimleri çok yüzeysel kalıyorsa, projenin başlangıç kapsamını bir toplantıda birlikte gözden geçirmek önemlidir. Böylece ne alacaklarını gerçekten anladıklarından emin olabilirsiniz.

Geçmişte birçok sorunun, iş kapsamı belgesi onaylandıktan sonra ortaya çıktığını gördüm. Daha sonra birileri “Ben bunu alacağımı sanıyordum” diyor; oysa belgede bu konu daha açık biçimde belirtilmiş olabiliyor.

Ben Aston:

Yani başta yeterince açık olmamamız bir neden. “Sizin için bir sayfa şablonu oluşturacağız” diyebiliriz ama şablonda gerçekten nelerin bulunacağını tam olarak tanımlamayabiliriz. İkinci konu da iletişimle ilgili: Şablondan ne anladığımızı müşteriye açıklamamış olabiliriz.

Suze Hayworth:

Evet, burada iki şey var: Teslimatları baştan açıkça tanımlamak ve kapsamı onaylayan kişinin söylediklerinizi gerçekten anlamasını sağlamak. Açık konuşsanız bile karşı taraf sizin kapsamda yazmadığınız başka bir şeyi alacağını düşünmüş olabilir.

Ben Aston:

Bunlar bence kapsam kaymasının en yaygın iki biçimi: bizim net olmamamız ve müşterinin anlamaması. Peki daha sinsi tarafına ne dersin? Fark etmeden gerçekleşen, alışılmadık kapsam kaymaları nasıl ortaya çıkıyor?

Suze Hayworth:

Proje yöneticileri kapsam kaymasını genellikle müşterinin yaptığını düşünür: müşteri başka bir şey ister, kapsamı genişletir veya sürekli daha fazlasını talep eder. Ancak bu, kurum içindeki ekiplerden ve paydaşlardan da gelebilir. Ekip üyeleri ne yapmaları gerektiğini net biçimde anlamazsa farklı yönlere gidebilir ve farkında olmadan süreleri veya işlevselliği genişletebilir. Örneğin bir tasarımcı, geliştirme kapsamını nasıl etkileyeceği düşünülmemiş bir şey tasarlayabilir. Bunu tamamen kasıtsız olarak yapabilir. Ya da kendi gündemi olabilir; örneğin yapmak veya tasarlamak istediği bir şeyi projeye eklemeye çalışabilir.

Kapsam kayması kurum içinden geldiğinde daha şaşırtıcı olabilir çünkü herkesin aynı anlayışta olmasını beklersiniz. Ayrıca kurum içindeki başka paydaşların iş ihtiyaçları da kapsama eklenebilir. Müşteri ilişkileri açısından daha fazlasını teslim etmenizi isteyebilirler veya sizin farkında olmadığınız bazı şeyleri kabul etmiş olabilirler. Bu da klasik bir durumdur.

Ben Aston:

Evet, sinsi kapsam kaymasının en yaygın nedenlerinden biri kurum içinden gelmesidir. Kendi ekiplerimizin yaptıkları işe gereksiz bir “altın kaplama” eklemeye çalışması buna örnektir. Bu durum strateji, kullanıcı deneyimi ve tasarımda sık görülür; ancak geliştirmede de ortaya çıkabilir. Birisi harika bir iş yapmak veya projeyi ödüllere aday gösterilebilecek bir vitrin çalışmasına dönüştürmek isteyebilir. Fakat hiç kimse ek çalışmanın ücretini kimin ödeyeceğini konuşmamıştır.

Suze Hayworth:

Kesinlikle.

Ben Aston:

Ya da bu çalışmanın sorumluluğunu kimin üstleneceği belli değildir. Bağımsız düşünen kişilerin isteneni kendi yorumlarına göre uygulaması da kapsam kaymasına neden olabilir. Makalende kalite güvencesinden de bahsetmişsin. Kullanıcı hikâyesini yazarken kabul kriterlerini tam olarak tanımlamamış olabiliriz. Ya da kalite güvencesi ekibine artık IE9'u desteklemediğimizi söylememiş olabiliriz. Ekip de “IE9'da her zaman hatalar çıkıyor, bu nedenle test etmeliyiz” diyebilir. Blackberry gibi rastgele bir cihazda test yaptıklarını görebiliriz. Bir anda, umursamadığımız şeyleri test etmek için çok fazla zaman harcarlar; geliştiriciler de aslında düzeltilmesi gerekmeyen sorunları düzeltmeye çalışır.

Suze Hayworth:

Kesinlikle. Kalite güvencesi, özellikle geliştirme süresine dayanarak başlangıçta kabaca tahmin yapabildiğiniz projelerdeki en büyük alanlardan biridir. Ancak yeniden kalite güvencesi ve tekrar test için kaç değişiklik yapılacağını tahmin etmek çok zordur. Başlangıçta parametreleri belirlemezseniz bu çalışma giderek büyüyebilir. Kabul kriterlerini, tarayıcı ve cihaz matrisini, hataların ve sorunların önceliklerini belirlemek gerekir. Yayına çıkmak için hangilerini düzeltmeliyiz? Hangileri daha yüksek veya daha düşük öncelikli? Bazılarını ele almadan yayına çıkabilir miyiz? Bunlar daha çok tasarım veya yüzeysel değişiklikler olabilir.

Yine konu, mümkün olduğunca temel kapsamı tanımlamaya geliyor. Belirsizliği başlangıçta azaltmalısınız. Ayrıca proje boyunca temel iletişimi sürdürmek ve iletişimi açık tutmak çok önemlidir. Kalite güvencesi sırasında belirli bir cihazda veya tarayıcıda fazladan zaman harcandığını görüyorsanız, bunu müşteriye veya paydaşa hızla ve açıkça bildirmelisiniz.

Örneğin IE'nin kalite güvencesi için çok daha fazla zaman harcadığını söyleyip alternatifler sunabilirsiniz. Kullanıcı tabanının büyük olduğunu biliyorsanız IE'yi önceliklendirebilir, diğer tarayıcıları ise daha düşük öncelikle ele alabilirsiniz. Kapsamın kaydığını gördüğünüz sorunları mümkün olduğunca erken ortaya çıkarmalı ve kapsam kaymasını açıkladığınızda alternatif çözümler sunmalısınız.

Ben Aston:

Bu gerçekten yararlı. Kapsam kaymasına neden olan birkaç şeyi konuştuk: belirsiz kapsam, ekiplerin kendi başına hareket etmesi ve kalite güvencesi. Peki kimin hatası? Bununla başa çıkmak için sorumlunun kim olduğunu belirlemek yardımcı olabilir; parmakla suçlamak için değil, nasıl başa çıkacağımızı anlamak için. Müşteri daha fazlasını istiyor olabilir. Kurum içindeki paydaşlarımız ve ekiplerimiz yaptıkları işe gereksiz eklemeler yapıyor olabilir. Makalende üçüncü taraflardan, kullanıcılardan ve biz proje yöneticilerinden de bahsediyorsun. Özellikle bizi dinleyenlerin çoğu proje yöneticisi olduğuna göre, bu ne ölçüde bizim sorunumuz ve hatamız?

Suze Hayworth:

Kapsam kayması için birini suçlamak yerine riskleri belirlemeye çalışmalıyız. Projede kapsam kaymasına neden olabilecek kişilerin kimler olduğunu ve neler yapabileceklerini önceden değerlendirmek riskleri görmenin iyi bir yoludur.

Proje yöneticisi olarak genellikle ekibin veya müşterinin ne yapabileceğine bakarız. Ancak kişisel olarak bizim açımızdan mesele, sorunlar ortaya çıktığında bunları bildirmemek veya vurgulamamaktır. Bir projede sorun olduğunda onu çözmek, hatta müşteriye yansıtmadan gömmek isteyebiliriz. Özellikle projede çok sayıda sorun varsa, sürekli olumsuz bir görüntü vermekten kaçınabiliriz.

Projeyi sürdürmeye, zamanlamaya yetişmeye ve işleri teslim etmeye çalışırken “Bunu burada karşılarız” diyebiliriz. Ancak bunu o anda müşteriye açıklamayız çünkü sorunu çözmeye çalışıyoruzdur. Bence daha iyi olabileceğimiz önemli alanlardan biri bu. Ben de geçmişte bunu yaptım.

Sorunları dürüst ve açık biçimde, ortaya çıkar çıkmaz konuşmak çok daha kolaydır. Bir sorun varsa bunu hızlıca gündeme getirmek gerekir. Ancak yalnızca “Bir sorunumuz var” demek ve müşteriyle ne yapılacağını düşünürken bocalamak yerine çözüm sunmak önemlidir. Önce sorunu tanımalı, ne olduğunu belirlemeli ve ardından birkaç alternatif çözümle müşteriye gitmelisiniz.

Kapsam kayması kurum içinden geldiyse, bunu geri çekmek için neler yapabileceğinizi değerlendirebilirsiniz; ancak müşteriye bunun gerçekleştiğini yine de yansıtmalısınız. Müşteri üzerinde anlaşılandan fazlasını istiyorsa bunu sessizce üstlenmeyin. Etkisini değerlendirin, birkaç farklı seçenek hazırlayın ve müşteriye dönerek örneğin hangi işlerin önceliğinin düşürülebileceğini konuşun.

Ben Aston:

Aslında bununla nasıl başa çıkacağımıza geçtik.

Suze Hayworth:

Üzgünüm.

Ben Aston:

Hiç sorun değil. Kapsam kaymasına neden olan şeyleri belirledikten sonra bununla nasıl başa çıkacağımızı konuşuyoruz. Proje yöneticileri olarak kapsamımızı daha açık hâle getirebiliriz. Bir proje yöneticisi arkadaşımızdan belgeyi incelemesini istemek yararlı olur. Kalite güvencesi ekipleri ve iş analistleri yazdığınız metindeki boşlukları bulmakta çok iyidir. “Bunu düşündünüz mü?” veya “Bunu neden tanımlamadınız?” diye sorabilirler.

Yani kapsam konusunda net olmak ve daha önce konuştuğumuz iletişim boyutunu geliştirmek önemli. Bir iş kapsamı belgesini duvarın üzerinden atıp müşterinin imzalamasını beklemek yerine, belgeyi müşteriyle birlikte gözden geçirmek kapsam kaymasını en baştan önlemeye yardımcı olur.

Ancak söylediğin gibi bunu halının altına süpürmemeliyiz. Özellikle müşteriyle doğrudan çalışan proje yöneticileri olarak ilişkiyi korumak istediğimiz için sorunu ele almaktan kaçınabiliriz. Başta şeffaf olmazsak sorun büyür. Proaktif olmak, şeffaf davranmak, önceliklendirmek ve etkileri analiz etmek çok yararlıdır.

Kapsam kayması genellikle çok fazla planlama yapılan ve aşamaların birer birer yürütüldüğü şelale projeleriyle ilişkilendirilir. Peki çevik projelerde de bu bir sorun mu? Daha yinelemeli ve esnek olan çevik bir projede kapsam kayması nasıl görünür?

Suze Hayworth:

Makalemde vurgulamak istediğim noktalardan biri buydu. Kapsam kaymasını genellikle olumsuz görürüz çünkü üzerinde anlaştığımız sabit kapsama bağlı kalmaya ve değişiklikleri engellemeye çalışırız. Ancak çevikliğin ve çevik yöntemlerin güzel yanı değişimi benimsemeleridir. Bu, çevikliğin temel ilkelerinden biridir. Değişim, sonunda daha iyi bir ürün veya hizmet oluşturabilir. Dolayısıyla değişime izin vermek aslında iyi bir şeydir.

Değişim düşman olarak görülmemeli. Nasıl ele aldığınız önemlidir. Örneğin Scrum tabanlı bir projede, çevik bir proje olsa bile belirli zaman kutusu, yani sprint için ne yapacağınız üzerinde yine anlaşmanız gerekir. İş listesini oluşturursunuz. Ürün sahibi veya müşteri, planlama yapıldıktan ve sprint içeriği üzerinde anlaşmaya varıldıktan sonra sprint sırasında listeye yeni bir şey eklemeye çalışabilir. Bu, teslim edeceğiniz şeyi ve sürümü etkileyebilir.

Bu nedenle getirilen şeyin diğer her şeye eklenmediğinden emin olmak gerekir. Yeniden önceliklendirme yapmalı ve eklenen hikâyelerin veya epiklerin çabasını başka bir şeyin önceliğini düşürerek dengelemelisiniz. Çevik projelerde de kapsam kayması yaşanır; ancak daha küçük zaman kutuları sayesinde değişiklikleri biraz daha kolay yönetebilirsiniz.

Ben Aston:

Bu yaklaşımı, yani konuşmayı değiştirmeyi gerçekten seviyorum. Değişimi benimsemekten bahsettin. Kapsam kayması genellikle olumsuz bir konuşmaya dönüşür çünkü genellikle daha fazla maliyet anlamına gelir. Müşteriye “Bu ek şeyi istiyorsunuz; başlangıçta planlanmamıştı, bu nedenle ek zaman ve bütçe gerektirecek” deriz.

Ancak müşterilerle bütçelerinin gerçekliği ve sınırları hakkında daha şeffaf ve sürekli bir diyalog kurarsak, birlikte önceliklendirme yapabiliriz. Böylece başlangıçta istedikleri bir işlevi alamayabilecekleri için endişelenmek yerine proje boyunca daha önemli bir ihtiyacı belirleyebiliriz. Bu iyi bir değişimdir. Bunu proje boyunca konuşabiliriz; son dakikada müşteriye daha fazla ödeme yapması gerektiğini veya istediği şeyi alamayacağını söylemek zorunda kalmayız.

Suze Hayworth:

Kesinlikle. Teslim ettikleriniz hakkında devamlı konuşmak çok önemli çünkü sonunda asıl mesele ürün veya hizmeti kullanan kullanıcılar için en faydalı olan şeydir. Müşteri yeni bir şey istediğinde hemen “Hayır, bunu yapamayız; daha fazla ödeme yapmanız ve sürenin uzaması gerekir” demek yerine bunun kullanıcılar için faydasını, neden şimdi bir gereksinim hâline geldiğini ve yeni bir ihtiyacı karşılayıp karşılamadığını sormalıyız. Geçerli bir talepse ve kullanıcılara daha fazla fayda sağlayacaksa, bunu diğer teslimatlarla karşılaştırabiliriz. Yeni özelliği ekleyip daha az önemli olan başka bir özelliğin önceliğini düşürebiliriz.

Bu nedenle devamlı görüşmeler yapmalı, müşteriyi yaptığımız işe dâhil etmeli ve yeni istekleri analiz ederek neden talep edildiklerini anlamalıyız. Asıl faydaları nedir?

Ben Aston:

Bu gerçekten sağlam bir tavsiye. Bunu bir konuşmaya dönüştürün ve kullanıcıyı düşünün. Kapsam kayması mutlaka olumsuz bir şey değildir. Kullanıcılar, müşteri, proje ve ekipler için iyi olabilir. Bundan milyonlarca kilometre kaçmamız veya korkmamız gerekmiyor; onu benimsemek sağlam bir yaklaşım.

Peki tüm projeleri bütçeyi aşan, geciken ve büyük kapsam kayması sorunlarına dönüşen kişiler için tek bir önerin ne olurdu?

Suze Hayworth:

Yeni başlayan bir projeye dâhil oluyorsanız, üzerinde çalışmanız gereken en iyi konu tahmin ve projenin kapsamını belirleme biçiminizdir. Tek başınıza çalışmadığınızdan emin olun. Ekip ile birlikte tahmin yapın ve tahminlerin mümkün olduğunca iyi olmasını sağlayın. Bunların tahmin olduğunu unutmayın. Kapsamını belirlediğiniz işi teslim etmeye başladığınızda zamanlama ve bütçenin kontrolden çıkmadığından emin olun.

Devam eden bir projeye yeni katılıyorsanız, mevcut durumu değerlendirin. Ne kadar aşıldığını, geriye ne kadar iş kaldığını doğru biçimde belirleyin. Ardından müşteriyle açık bir konuşma yapın. Sorunların nerede olduğunu ve projenin hangi alanlarda aştığını müşteriye bildirin.

Ben Aston:

Suze, bize katıldığın için çok teşekkürler. Birlikte olmak harikaydı. DPM uzmanlarımızdan biri olan Suze, şubat ayında başlayacak yeni kursumuzda da yer alacak. Kursun adı “Dijital Proje Yönetiminde Ustalaşma”. Ne hakkında konuştuğumu bilmiyorsanız ancak proje yönetimi eğitimi almanız gerektiğini düşünüyorsanız kursa göz atın. Etkileşimli video dersleri, ödevler, web seminerleri, grup tartışmaları ve koçluk oturumları seçeneğini içeren yedi haftalık yoğun bir kurstur. DPMschool.com adresine giderek kontenjan dolmadan kaydınızı yaptırın. Kapsam kayması hakkındaki bu konuşmaya katkıda bulunmak isterseniz gönderiye yorum yazın ve TheDigitalProjectManager.com kaynaklar bölümüne giderek Slack ekibimize katılın. Orada her türden ilginç konuşma bulacaksınız. Bir sonraki bölüme kadar bizi dinlediğiniz için teşekkürler.