Kurumsal Bir Web Sitesi Projesi Nasıl Yönetilir? (Project Zendo’dan Rich Butkevic ile)

Metnin Tamamını Okuyun:

Podcast'lerimizin metin dökümlerini bir yazılım programı kullanarak oluşturmayı deniyoruz. Bot her zaman yüzde 100 doğru olmadığı için lütfen olası yazım hatalarını mazur görün.

Ben Aston

Bizi dinlediğiniz için teşekkürler. Ben, The Digital Project Manager'ın kurucusu Ben Aston. DPM Podcast'e hoş geldiniz. İster deneyimli bir proje yöneticisi, ister dijital yapımcı olun, isterse kendinizi bir şekilde projeleri yönetirken bulmuş olun; bugün kulaklıklarınızda, daha iyi projeler başlatmak, planlamak ve teslim etmek için ellerinden geleni yapan, sizinle aynı durumda olan binlerce kişinin bulunduğunu bilin.

thedigitalprojectmanager.com olarak daha özgüvenli ve becerikli bir proje yöneticisi olmanıza yardımcı olmak ve projeleri yöneten ve yönlendiren diğer kişilerle bağlantı kurmanızı sağlamak için buradayız. Seviyenizi gerçekten yükseltmek ve proje yönetimi becerilerinizi bir sonraki aşamaya taşımak istiyorsanız DPM School'a göz atın ve seçilmiş tüm kaynaklarımıza erişmek için profesyonel üyeliğimize kaydolduğunuzdan emin olun.

Son olarak, programı dinlerken lütfen abone olun ve gündemdeki gelişmelerden haberdar olmak için thedigitalprojectmanager.com adresindeki posta listemize katılın. Daha önce bir kurumsal web sitesi projesi gerçekleştirdiyseniz, bunları doğru yapmanın ne kadar zor olduğunu çok iyi bilirsiniz. Bunun kısmen nedeni, bu işin çok sık yapılmamasıdır; ancak mesele bundan daha fazlasıdır: belirsiz hedefler, muğlak bir brief, karmaşık paydaş ilişkileri ve yoğun politika.

Bunların tümü, kurumsal bir web sitesini yalnızca doğru şekilde değil, herhangi bir şekilde tamamlamayı bile son derece zorlaştırır. Bir de teknik zorlukları eklediğinizde, parlak ve yeni web sitesi projeleri tam bir felakete dönüşebilir. Bugünkü podcast'te kurumsal web sitesi projelerini nasıl doğru şekilde yürütebileceğinizi açıklayacağız. Yaklaşan kurumsal web sitesi projelerinizi nasıl planlayacağınızı, yöneteceğinizi ve kontrol edeceğinizi öğrenmek için dinlemeye devam edin.

Bizi dinlediğiniz için teşekkürler. Ben, The Digital Project Manager'ın kurucusu Ben Aston ve DPM Podcast'e hoş geldiniz. İster deneyimli bir proje yöneticisi, ister dijital yapımcı olun, isterse kendinizi bir şekilde projeleri yönetirken bulmuş olun; bugün kulaklıklarınızda, daha iyi projeler başlatmak, planlamak ve teslim etmek için ellerinden geleni yapan, sizinle aynı durumda olan binlerce kişinin bulunduğunu bilin. thedigitalprojectmanager.com olarak daha özgüvenli ve becerikli bir proje yöneticisi olmanıza yardımcı olmak ve projeleri yöneten ve yönlendiren diğer kişilerle bağlantı kurmanızı sağlamak için buradayız.

Proje yönetimi becerilerinizi bir sonraki aşamaya taşımak istiyorsanız DPM School'a göz atın ve seçilmiş tüm kaynaklarımıza erişmek için profesyonel üyeliğimize kaydolun. Son olarak, programı dinlerken lütfen abone olun ve gündemdeki gelişmelerden haberdar olmak için posta listemize katılın.

Bu podcast, Kurumsal Proje ve Portföy Yönetimi Yazılımları alanında lider Clarizen tarafından sunulmaktadır. Daha fazla bilgi için clarizen.com adresini ziyaret edin. Bugün konuğum Rich Butkevic-

Rich Butkevic

Harika.

Ben Aston

Doğru mu söyledim?

Rich Butkevic

Mükemmel söyledin.

Ben Aston

İşte böyle, pratik yaptım. Rich bir Proje Yönetimi Danışmanı ve projectzendo.com blogunun yazarı. Mutlaka göz atın. Ayrıca Teksas'ın dört bir yanında proje yönetimi atölyeleri düzenliyor; bununla ilgileniyorsanız artofpmo.com adresine bakın. Buna birazdan değineceğiz. Rich'in proje ve ürün yönetimi, kalite güvence, iş analizi, pazarlama ve eğitim alanlarında liderlik deneyimini bir araya getiren benzersiz bir geçmişi var. Çevik ve Scrum yöntemlerini kullanıyor; sahip olmak isteyebileceğiniz tüm unvanlara ve sertifikalara sahip: PMP, Sertifikalı Scrum Yöneticisi, IBM Rational Birleştirilmiş Süreç uzmanı, Amazon ve E-Pazarlama sertifikaları. Her şey var.

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

Rich Butkevic

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

Ben Aston

Tüm bu yeterliliklerin ve adının sonundaki unvanların üzerinde biraz durarak başlamak istiyorum. Bazı insanlar sertifikaları önemsemediklerini söyler. Sen ise bunun tam tersine gidip mümkün olan her sertifikayı almışsın. Bu, öğrenmeye duyduğun özel bir tutkudan mı kaynaklanıyor? Her konuda sertifika almaya karar vermene ne neden oldu?

Rich Butkevic

Her konuda olduğunu söyleyemem ama öğrenmeye gerçekten tutkuyla bağlıyım. Yapmaktan çok hoşlandığım bir şey. Proje yönetiminde ya da genel olarak herhangi bir alanda sertifika almak, bence mesleği ne kadar ciddiye aldığınızı ve gelişmeleri takip ettiğinizi gösteriyor. PMP dışında diğer sertifikaları çoğunlukla projelerin gerektirdiği şekilde edindim.

Örneğin AWS sertifikası için Amazon Web Services kullanan bir projede yer alacaksam, proje yöneticisi olarak daha iyi iş çıkarabilmek için teknolojiye gerçekten hâkim olmayı severim. Bunu yaparken bundan hoşlandığımı ve daha fazla öğrenmek istediğimi fark ettim. Zaten daha fazla öğreneceksem, ulaşmaya çalışacağım bir hedefimin olması güzel. Bu nedenle kendime sertifika alma hedefi koyuyorum.

Ben Aston

Peki proje yönetimine nasıl başladığını anlatır mısın? Açıkça teknik bir yönün var. Tanıdığım pek çok proje yöneticisinin AWS gibi teknik bir sertifikası olduğunu sanmıyorum-

Rich Butkevic

Elbette.

Ben Aston

Nasıl başlayıp proje yönetimine geçtin?

Rich Butkevic

Üniversitedeyken teknik destek personeliydim. Geniş bant internetin yaygınlaşmaya başladığı dönemde telefonlara cevap veriyordum. Teknik açıdan oldukça heyecan verici bir dönemde bu işin en başından yer aldım. Üniversiteden mezun olur olmaz, o sırada yaşadığım Chicago'daki büyük bir telekomünikasyon şirketinde iş analisti oldum. Daha sonra kalite güvenceye geçtim, kalite güvence ekibini yönetmeye başladım ve ardından proje yönetimine girdim. O şirkette sertifikamı aldım ve işler oradan devam etti.

Ben Aston

İlk proje yöneticiliği gününü düşünelim. O günden bu yana pek çok ders öğrendin. Bugün bildiklerini o zamanki kendine söyleyebilseydin, ilk gününde kendine ne söylerdin?

Rich Butkevic

En önemli şeyin araçla ilgili olmadığını söylerdim. Pek çok proje yöneticisi, kendilerine yardımcı olması için kullandıkları proje yönetimi aracının tüm ayrıntılarını ve inceliklerini öğrenmeye fazla odaklanıyor. Bana göre yaptığınız her şeyde araç, aslında kalem ve kâğıtla gerçekleştirebilmeniz gereken bir süreci yönetmenizi kolaylaştıran, otomatikleştiren ve destekleyen bir yöntemdir.

Bir projeyi yalnızca bir kalem ve defterle yönetme konusunda rahat değilseniz, bunu gerçekten yapmanız gerektiğini söylemiyorum. Ancak iyi bir proje yöneticisi olmak Microsoft Project'i veya başka bir proje yönetimi aracını en iyi bilen kişi olmakla ilgili değildir. Bundan çok daha fazlasıdır. Daha çok iletişim gibi yumuşak beceriler ve bir proje yöneticisi olarak neyi başarmaya çalıştığınızı iyi anlamakla ilgilidir.

Ben Aston

Kesinlikle. Araçlardan söz etmişken, kalem ve not defterinin dışında proje yönetimi araç setinde neler var?

Rich Butkevic

Kullandığımız proje yönetimi aracının yanı sıra en büyük farkı yaratan şeyin bir tür iş birliği aracı olduğunu düşünüyorum. Slack'i seviyorum. Basit ve insanların kullanması kolay. Şirketin ortak sürücülerinde dağınık hâlde duran, kimsenin bulamadığı e-postalar ve Excel dosyalarıyla işleri yönetmeye çalışmaktan çok daha etkili.

Slack'i seviyorum; ancak proje yönetimi aracında olduğu gibi burada da kavram ve fikir, kullanmayı seçtiğiniz belirli araçtan daha önemli.

Ben Aston

Slack ile özellikle yararlı bulduğun entegrasyonlar var mı?

Rich Butkevic

Danışman olarak kullandığım bazı zaman takip entegrasyonları dışında aklıma gelen belirli bir şey yok. Çalıştığım şirketlerin genellikle uymamız gereken standartları oluyor. Slack'le entegre ettiğiniz zaman yönetimi yazılımı değişebilir; ancak bir şekilde entegre olması iyi. Slack'te bana gerçekten fayda sağlayan şey klavye kısayollarını öğrenmek oldu. Bunları bilmek büyük fark yarattı.

Ben Aston

En sevdiğin kısayolu söyle.

Rich Butkevic

Şimdi beni zor durumda bıraktın. Bilmiyorum. Sanki onları içgüdüsel olarak biliyorum; parmaklarım biliyor ama-

Ben Aston

Muhtemelen biliyorsundur.

Rich Butkevic

Beynim bilmiyor.

Ben Aston

Adını söyleyemiyorsun ama el hareketlerini biliyorsun.

Rich Butkevic

Evet. Telefon numaram gibi. Bazen insanlara telefon numaramı söylemekte zorlanıyorum ama aramam gerektiğinde tuşlamakta zorlanmıyorum.

Ben Aston

Proje yönetiminin araçlarla ilgili olmadığı noktasına dönelim. İyi proje yönetiminin araçlarla ilgili olmaması senin için ne anlama geliyor? Yumuşak becerileri daha iyi projeler teslim etmek için nasıl kullanıyorsun?

Rich Butkevic

İletişim gibi yumuşak beceriler elbette önemli. Ancak daha doğru ifade etmek gerekirse, bir proje yöneticisinin kavramsal düzeyde ne yapması gerektiğini ve bir projenin ideal olarak nasıl yürütülmesi gerektiğini anlamak gerekir. Böylece gerçekten önemli olan şeylere odaklanabilir, zaman kaybı olan işlerle uğraşmazsınız.

Bir projenin seyri boyunca odaklanmanız gereken birkaç büyük konu vardır. Bunların altında yapmanız gereken çeşitli görevler bulunur. Öncelikle gereksinimlerinizi belirlemeniz gerekir. İş birimiyle, proje bir BT veya web sitesi projesiyse teknik ekiple, gereksinimler konusunda ortak bir anlayış bulunduğundan emin olmalısınız. Testlerin yapılmasını ve hataların bir şekilde yönetilmesini sağlamalısınız. Bir proje planında özet görevler olarak gösterilecek üst düzey konuları anlamanız ve bunları neden yaptığınızı bilmeniz gerekir.

Bir belgeyi neden doldurduğunuzu veya yaptığınız işi neden yaptığınızı bir tweet ile açıklayamıyorsanız durup ne yaptığınızı netleştirmeniz gerektiğini düşünüyorum. Çünkü neden yaptığınızı bilmiyorsanız bunu iyi yapamazsınız ve belki de hiç yapmamanız gerekir.

Ben Aston

Kurumsal web sitesi projelerini yönetme konusuna geçelim. Kurumsal web sitesi projelerinin nasıl yanlış gittiğiyle ilgili bir yazı yayımladık. Henüz okumadıysanız thedigitalprojectmanager.com'da proje yöneticileri için hazırlanmış bu kısa rehbere göz atın. Gerçek şu ki kurumsal web sitesi projeleri zordur. Kurumlar, önemli bir güncelleme yapmak, buluta geçmek, yeni bir içerik yönetim sistemi uygulamak veya dijital pazarlama araçlarıyla entegrasyon kurmak için ajansları ve danışmanları işe alır.

Bu projeler çoğu zaman üç ila beş yılda bir gerçekleştirildiği için projeye dâhil olan kişiler bu konuda çok deneyimli olmayabilir. Paydaş sayısının fazla olması, belirsiz brief'ler, politika ve teknik zorluklar da işi daha karmaşık hâle getirir. Bu sürecin nasıl kolaylaştırılabileceğini konuşalım. Önce neden bu kadar zor olduğunu ele alalım. Geçmişte senin için yanlış giden bir projeden örnek veya korku hikâyesi paylaşabilir misin?

Rich Butkevic

İşlerin yanlış gitmesi konusunda kariyerimin erken dönemlerinde öğrendiğim en önemli derslerden biri, güvenmek ama doğrulamaktı. Proje kaynakları bir görevi tamamladıklarını söylerdi; aslında kastettikleri görevi tamamlamayı planladıkları veya görevin yapılacaklar listesinde olduğuydu. Sonra başka işler çıkardı ve görev unutulur ya da halının altına süpürülürdü. Bazı maddeler ne yazık ki üretim ortamına geçilene kadar fark edilmez.

Bir diğer önemli konu da büyük ekiplerle, özellikle kaynakların coğrafi olarak dağınık olduğu projelerde iyi iş birliği yapmaktır. Proje büyüdükçe sonunda işleri kurtaracak bir veya iki kişinin kahramanca çabasına güvenemezsiniz.

Bir danışman olarak yılda birkaç kez farklı şirketlere gidip bu tür projelerde çalışabilirim. Belki birkaç düzine benzer proje yürüttüm. Ancak 15 yıldır bir kurumda çalışan sistem veya ağ yöneticisi böyle bir işi kariyerinde yalnızca bir, en fazla iki kez yapmış olabilir. Bu nedenle bana rutin gelen bir süreç, kurum içindeki birçok kişi için hiç rutin olmayabilir.

Ben Aston

Ben de yanlış giden bir projeden bahsedeyim. Birkaç yıl önce kurumsal bir web sitesi projesinde çalışıyordum. Sorun, brief üzerinde hizalanma eksikliğine dayanıyordu. İçeride projeyi yönetmekle görevlendirilen kişi, ekibinden alması gereken tüm görüşleri toplamamıştı. Bir brief yazılmıştı ancak onaylatılmamıştı veya onaylatılmış olsa bile düzgün şekilde gözden geçirilmemişti.

Web sitesini tasarladık ve geliştirdik. Yayına geçmek üzereyken proje yönetişim yapısında, tüm proje boyunca hiç haberdar olmadığımız ek bir onay katmanı bulunduğunu fark ettik. Yayına geçmeden önce kurucu ve başkanın onay vermesi gerektiği söylendi. Kurucu ve başkan gerçek karar vericiydi ve projenin temelini oluşturan çok net istekleri vardı.

Sonunda büyük bir değişiklik talebi hazırlamak zorunda kaldık. Müşteri daha fazla ödeme yapmak zorunda kaldığı için üzüldü ve bu durum ilişkimizi zedeledi. Projenin başında bu yönetişim yapısını yeterince sorgulamamamızda bizim de payımız vardı. Projeyi daha yavaş ilerletmeli ve onayları en üst seviyeye kadar çıkarmalıydık.

Rich Butkevic

Bu, özellikle büyük şirketlerde zor olabilir. Projede yaklaşık on iki paydaş belirlenmiş olabilir; ancak bu paydaşların hepsinin bir yöneticisi, yöneticilerinin de başka bir yöneticisi vardır. Yeterince üst düzey bir yönetici beğenmediği bir web sitesi değişikliği gördüğünde daha önce alınan kararları geçersiz kılabilir.

Ben Aston

Bunun sonuçlarını açıklamak önemli. Paydaşları haritalandırıp projenin farklı kilometre taşları için bir RACI matrisi oluşturuyoruz. Ancak bir kişinin onay veren kişi olduğunu söylüyorsak ve daha sonra başka birinin nihai kararı vermesi gerektiğini öğreniyorsak maliyet ve takvim üzerinde etkisi olacağını en baştan açıkça belirtmeliyiz. Şimdi söyleyin, yoksa daha sonra sonuçlarıyla karşılaşırsınız.

Peki yüksek seviyede süreç nasıl ilerliyor? Bir kurumsal müşterinin yeni bir web sitesine ihtiyacı olduğunu söylemesinden sitenin tamamlanmasına kadar neler yapıyorsun? Proje planındaki büyük konu başlıkları ve özet görevler nasıl görünüyor? Ayrıca Çevik yaklaşım ve Scrum sertifikan bu projelerde nasıl rol oynuyor?

Rich Butkevic

En üst düzeyde ilk iş, projenin veya web sitesinin gerçek hedeflerini belirlemektir. Bazen iki web sitesini birleştirmek için bir birleşme veya satın alma gerçekleşir; bazen yeniden tasarım ya da yeniden markalama yapılır; bazen de yeni bir içerik yönetim sistemi uygulanır. Hedefler belirlendiğinde sonraki görevlerin çoğu da buna göre şekillenir.

Daha sonra kullanıcı hikâyelerine geçmeyi severim. Tasarım veya web sitesi projelerinde bu konu çoğu zaman gözden kaçar. Şirketler herkese hizmet etmez; genellikle birkaç farklı müşteri profili vardır. Web sitesini ziyaret edecek kişilerin farklı hedefleri, bilgi düzeyleri ve siteyi kullanma yolları bulunur. Bu kullanıcı profillerini ve hedeflerini belirlemek sonraki aşamayı yönlendirir.

Kullanıcıların neden siteyi ziyaret ettiğini ve ne yapmayı umduğunu yazmak, site hiyerarşisinin ve yapısının tasarlanmasına yardımcı olur. Kullanıcının bir yere ulaşmak için yapması gereken tıklama sayısını sınırlamak gerekir. Aradığı bilgiyi sitenin yirmi sayfa altında saklamamalısınız; aksi hâlde kullanıcı bulamaz, hayal kırıklığına uğrar ve bu SEO açısından da sorun yaratabilir.

Hiyerarşi belirlendikten sonra içerik ve içeriğin nasıl yönetileceğine bakarız. Küçük bir sitede bu kolaydır. Ancak kurumsal ölçekte bir web sitesinde binlerce sayfa olabilir. Hangi içeriğin kalacağı, güncelleneceği, silineceği veya birleştirileceği önemli bir çalışmadır. Bu noktada araçlar gerçekten yardımcı olabilir.

Teknik yönleri ancak bunlardan sonra ele alırım. Teknik ayrıntılar altyapıya ve içerik yönetim sistemine göre değişir; ancak hedefler, kullanıcı ihtiyaçları ve içerik yapısı doğru düşünülmediyse teknik bölümlerin mükemmel olması yeterli değildir.

Ben Aston

Yani senin için önemli olan; brief'i ve hedefleri en başta tanımlamak, temel kullanıcı profillerini belirlemek, site mimarisini ve bilgi mimarisini oluşturmaktır. Ardından tasarım aşamasında tel kafesleri ve tasarım bileşenlerini yaratırız. Bunları paralel iş akışları olarak mı yürütüyorsun? Keşif, planlama ve tasarım aşamalarının geliştirmeden önce çok zaman alacağı düşünülebilir. İşleri paralel yürütmek ve hızlanmak için önerilerin neler?

Rich Butkevic

Çok fazla kestirme yol kullanmamaya çalışıyorum. Planlama, projenin sonraki aşamalarda ne kadar hızlı ilerleyeceği konusunda büyük fark yaratır. Bir şeyi doğru yapmaya zamanınız yoksa yeniden yapmaya da zamanınız olmayacaktır.

Bununla birlikte pek çok işi paralel yürütebilirsiniz. Web sitesinin genel hedefleri üzerinde çalışırken müşterilerin kim olduğunu ve siteyi hangi kişilerin ziyaret edeceğini genellikle bilirsiniz. Kullanıcı hikâyelerini yazmaya başlayabilir, site yapısı için notlar alabilirsiniz. Mevcut bir siteyi yeniden tasarlıyorsanız mevcut yapıyı başlangıç noktası olarak kullanmak mantıklıdır.

Satış, insan kaynakları ve diğer departmanlar kendi içeriklerini inceleyip neleri birleştirmek, kaldırmak veya güncellemek istediklerine karar verebilir. Tüm bu işler birlikte ilerleyebilir.

Çevik veya Scrum yaklaşımlarının en büyük katkısı paydaş yönetiminde ortaya çıkar. Karar vericilerin mümkün olan en kısa sürede gerçek bir şey görmesini istersiniz. Günlük çalışmaya dâhil olmak istemeyen yöneticiler, ilerlemeyi ekranda görebilecekleri toplantılara katılacaktır. Geri bildirimi ne kadar erken alırsanız o kadar iyi olur. Aksi hâlde sitenin tamamına yayılan bir tasarım kararının üst düzey bir yönetici tarafından istenmediğini en sonda öğrenebilirsiniz.

Ben Aston

Kullanıcı testi de çok yararlı olabilir. Projenin başında kullanıcı profillerini belirleriz ve siteyi kim için yaptığımız konusunda müşteriyle hizalanırız. Kurumsal web sitelerinde bazen yöneticilerin egolarını tatmin etmek gibi örtük hedefler de bulunur. Bunların da bir şekilde tanımlanması gerekir.

Kullanıcı profilleri karar vermeyi yönlendirmemize yardımcı olur. Daha sonra kullanıcı testi yaparız. Kullanıcılara belirli görevler verir, örneğin yeni bir geniş bant paketi bulmalarını isteriz. Eğer kullanıcılar ana sayfada yalnızca CEO'nun başarılarını görüp kendi paketlerini nasıl yapılandıracaklarını bulamıyorsa, tasarım kararımızı yeniden değerlendirmemiz gerekir.

Rich Butkevic

Bu tür şeyler sürekli yaşanır. Kullanıcı testine getirdiğiniz kişilerin gerçekten belirlediğiniz müşteri profillerini temsil ettiğinden emin olmanız önemlidir. Örneğin ev sahibi sigortası satıyorsanız ev sahibi olmayan kişileri veya gençleri teste dâhil etmemelisiniz.

Birçok şirket kullanıcı testlerinde kendi çalışanlarını kullanıyor. Bu genellikle kötü bir fikirdir; çünkü şirket çalışanları işin nasıl yürüdüğünü, hedefleri ve sektör jargonunu zaten bilir. Genel kullanıcıların anlamayacağı bir terimi kullanabilir ve insanların rakibe gitmesine neden olabilirsiniz. Bu nedenle gerçek kullanıcıları temsil eden kişilerle test yapmak gerekir.

Ben Aston

Keşif, planlama ve tasarım bölümünü konuştuk. Şimdi geliştirme aşamasına geçelim. Kurumsal web sitesi geliştirmenin teknik yönlerinde deneyimlisin. Tasarımın hedeflere ulaşması ve dönüşümleri artırması önemlidir; ancak tasarımın doğru olması ile sitenin işlevsel olarak doğru çalışması arasında fark vardır. Kurumsal bir web sitesi projesinde geliştirme sürecini yönetmek için en önemli önerilerin neler?

Rich Butkevic

En önemli nokta, geliştiricilerin bu alanda veya özellikle geçiş sürecinde büyük deneyime sahip olmayabileceğini unutmamaktır. Site çalışmaya başladıktan sonra yönetim konusunda deneyimli olabilirler; ancak teknik geçiş ayrıntılarında eksikleri olabilir.

Dikkat ettiğim konulardan biri HTTPS yönlendirmesidir. Günümüzde neredeyse tüm kurumsal siteler güvenlidir. Kullanıcı HTTP yazar, HTTPS yazmaz veya siteye bir bağlantı üzerinden gelmezse isteğin güvenli sayfaya yönlendirildiğinden emin olmalısınız. URL doğru şekilde yeniden yazılmazsa arama motorları açısından sitenin iki farklı sürümü oluşur. Bu da yinelenen içerik sorunlarına ve analiz verilerinin bölünmesine yol açabilir.

Bir diğer konu yayına geçerken DNS'i güncellemektir. DNS, Google gibi bir alan adının IP adresine çevrilmesini sağlayan sistemdir. DNS güncellemesini yapması gereken kişinin alan adı kayıt kuruluşuna erişimi olmayabilir. Bu erişimlerin önceden kontrol edilmesi gerekir.

Ayrıca DNS değişikliklerinin internetteki sunuculara yayılması için bir süre gerektiğini proje ekibinin bilmesi önemlidir. Değişiklikler hemen herkese yansımayabilir. Bu, yayına geçiş gününde gereksiz paniği önler.

Ben Aston

Yayına geçiş önerilerini çok önceden düşünmek gerekir. Geliştirme sürecine kapılıp yayına iki hafta kaldığında DNS yönlendirmelerini düşünmeye başlamak sorun yaratabilir. Sonra giriş bilgilerini kimsenin bilmediğini ve bilen kişinin tatile çıktığını fark edebilirsiniz.

Peki teknik olmayan bir proje yöneticisi geliştiricileri nasıl yönetmeli? Geliştirici bir görevin tamamlandığını söylediğinde aslında yalnızca yapmayı planladığını kastediyorsa ne yapmalı?

Rich Butkevic

Yinelemeli yaklaşım burada çok faydalıdır. Ekranınızda bir şeyin gerçekten çalışıp çalışmadığını görme fırsatınız olur. Böylece sorunları erkenden fark eder ve ilerlemenin söylendiği gibi olup olmadığını görebilirsiniz.

Toplantılar ve güncellemeler arasında uzun boşluklar bırakmamak da önemlidir. Toplantı yapmak için toplantı yapmak istemem; ancak günlük veya iki günde bir beş dakikalık kısa toplantılar işleri yolunda tutmaya yardımcı olur. Bu Scrum'a özgü değildir; her geliştirme yaklaşımında kullanılabilir. Konuların gündemde tutulması, düzenli kontrol edilmesi ve sorunların çözülmesi işleri doğru yönde ilerletir.

Ben Aston

Momentum önemlidir. Düzenli demolar yapmalı ve çalışan bir şey görmeliyiz. Haftanın sonunda bir geliştirme sürümü ortaya koyup değerlendirebiliriz. Geliştirici yalnızca gezinme çubuğunu yaptığını söylese bile bunu test ederiz. Telefonda çalışmıyorsa sorunu erkenden yakalarız. Düzenli sprint demoları ve günlük toplantılar, geliştiricilerin ortadan kaybolup altı hafta sonra yanlış bir ürünle dönmesini önler.

Kurumsal bir web sitesi projesini yönetmek üzere olan kişiler için tek bir tavsiye vermen gerekse ne söylerdin? Bütçeyi, takvimi ve ekibi kontrol altında tutmak için ne işe yarıyor?

Rich Butkevic

İyi iş birliği ve bunu kolaylaştıracak bir araç kullanmak önemli. Günlük toplantılar sorunların önüne geçmeye yardımcı olur. Çevik yaklaşımda geri bildirim döngüsü genellikle iki haftalık parçalara ayrılır ve gerçek bir şey gösterilir. Bu döngüyü günlük toplantılarla daha da kısaltabilirsiniz. Slack gibi bir iş birliği aracı kullanıldığında sorunları bir sonraki günü veya iki hafta sonrasını beklemeden anında gündeme getirebilirsiniz.

Yayına geçmeden önce siteyi bozuk bağlantılar için taramanızı da öneririm. Bu, insanların genellikle fark etmediği pek çok sorunu ortaya çıkarır. Bir proje yöneticisi olarak yayına geçmeden bir hafta önce siteyi taratırım. Böylece kodlama, site organizasyonu veya teknik sorunlar hakkında bilgi elde edebilirsiniz.

Ben Aston

Hangi tarama aracını kullanıyorsun?

Rich Butkevic

Belirli bir aracım yok; hepsi aşağı yukarı aynı şekilde çalışıyor. İnternette bağlantı denetleyicisi veya benzeri bir araç arayabilirsiniz. Yeni bir site mi oluşturduğunuza, yeniden tasarım mı yaptığınıza ve aracın ağ içinden mi yoksa dışından mı çalışması gerektiğine bağlı olarak bazı farklılıklar olabilir. Ancak önemli olan bunu yapmanızdır.

Ben Aston

Rich, bize katıldığın için çok teşekkürler. Brief'i, hedefleri ve amaçları projenin başında netleştirmenin ne kadar önemli olduğunu konuştuk. Her şey buradan ilerliyor. Ayrıca site yayına alındıktan sonra sonuçları değerlendireceğiniz bir dönem olur. Proje boyunca hedefleri takip ettiyseniz sitenin sonuç ve yatırım getirisi sağladığını görmek çok daha kolay olur. Bu nedenle projeye doğru başlamak çok önemlidir.

Rich Butkevic

Teşekkürler Ben, burada olmak harikaydı.

Ben Aston

Bize katıldığın için memnun olduk. Sizce site geliştirme projelerinde hangi yöntemler işe yarıyor? Başarılarınızı veya başarısızlık hikâyelerinizi aşağıdaki yorumlarda paylaşın. Daha fazlasını öğrenmek ve işinizde öne geçmek istiyorsanız DPM üyeliği ile topluluğumuza katılın.

Üyelik içinde farklı metodolojiler, sprint'ler veya daha şelale tipi bir yaklaşım kullanılarak hazırlanmış büyük site projeleri için proje planları da dâhil olmak üzere pek çok kaynak bulacaksınız. Slack ekibimize, şablonlara, atölyelere, danışma saatlerine, e-kitaplara ve daha fazlasına erişebilirsiniz. Bugün dinlediklerinizi beğendiyseniz lütfen abone olun, birkaç dakikanızı ayırarak dürüst bir değerlendirme bırakın ve dinlediğiniz için teşekkürler. Bir sonraki bölüme kadar kendinize iyi bakın.