Bu yazımda proje yönetim süreci hakkında genel bilgilerin haricinde içinde bulunduğum çeşitli proje süreçlerinde edindiğim deneyimleri aktararak bu alanda kendini geliştirmek isteyenlere ve proje yönetim süreçleri içerisinde yer alan kişilere bir bakış açısı katmak isterim.
Sıkıcı ve anlaması zor bir yazı olmasın bence bu yüzden maddeleyerek gidelim. Aslında ben bu süreci baştan uca olmak üzere 3 bölümde değerlendiriyorum. Bu 3 bölümde değineceğim maddelerin doğru uygulanmasıyla herkesin mutlu olduğu bir proje yönetmek mümkündür.
İçindekiler
Her bölümün en önemli maddesi ile başlayalım;
Proje başlamadan önce analiz sürecinde hazırlanmış Proje Tanımlama Dokümanı (PTD) çok önemlidir. Bu doküman ne kadar detaylı hazırlanır ise proje süreci bir o kadar kolay ve verimli bir şekilde geçirilir. Her projede mutlaka bir PTD olmalı ve bu PTD belirlenen zaman planında yapılacak geliştirmeleri içermelidir. PTD, her proje ekibi üyesinin (örneğin geliştirici ya da iş birimi) anlayabileceği dilden olmalı ve baştan uca tüm süreci anlatıyor olmalıdır.
Süreci anlatırken görsel bir akış şeması proje dokümanına mutlaka eklenmelidir. Geliştirme sürecinde PTD dışında gelen geliştirme talepleri önem derecelerine göre değerlendirilmeli, önem derecesi yüksek talepler olursa zaman planında değişikliğe gidilmeli, önem derecesi düşük maddeler ise projenin ilerleyen fazlarına planlanmalıdır. Bir projede PTD bizim sınırlarımız olmalıdır ve proje boyunca hedefimiz bu sınırların dışına çıkmamak olmalıdır.
Güçlü bir “proje tanımla dokümanı” ile bu adım aslında çok kolay. Doğru bir zaman planı için doğru gün tahminlerini geliştiricilerden almak mantıklı olacaktır. Zaman planı hazırlanırken her geliştiriciden doğru günleri belirlemesini istemek gerekir. Projede yer alan geliştirici, proje boyunca yeterli zamanı olmadığını düşünür ise projenin başından itibaren stres altında çalışmak zorunda kalır. Bu süreçte geliştirici ekip tarafında mecburi mesailer yapılır, yapılan işin verimi düşer ve sonuç olarak mutsuz bir proje süreci geçirilmiş olunur.
Bir proje sürecinde zaman planı yapmak kadar bu zaman planına tüm proje üyelerinin sadık kalması da önemlidir. Proje yönetim sürecinde hedefimiz olabildiği kadar zaman planında değişikliğe gitmemek olmalıdır. Mecburi durumlarda ise tüm ekip üyelerinin ortak kararı ile zaman planında değişikliğe gidilebilir.
Proje başlamadan proje boyunca kim kiminle iletişime geçecek belirlenmelidir. Eğer bu belirlenmez ise proje boyunca iletişim bozukluklarından kaynaklanan kazalar meydana gelebilir. Ya da küçük bir problemde panik ve kaos ortamı oluşabilir.
İlgili proje ekibi üyeleri hangi aralıklar ile bir araya gelip durum değerlendirmesi yapacağı proje başlamadan önce planlanmalıdır.
Bu soruların cevapları için bir çalışma hazırlanmalı her proje ekibi üyesi kendi toplantılarına mümkün olduğunca sadık kalmalıdır. Bu toplantılar tüm proje ekibi üyelerinin anlık olarak proje durumu hakkında bilgi sahibi olmasını sağlamaktadır. Tabi bir de en önemli maddemiz dokümantasyondu. Mutlaka bu toplantılarda alınan kararlar ve toplantı notları tüm proje ekibi üyeleri ile paylaşılmalıdır. Söz uçar yazı kalır değil mi?
Proje başlamadan hazırlık döneminde güçlü silahlarımızı hazırladık artık projeye başlayabiliriz. Proje boyunca dokümantasyon olarak PTD her zaman elimizin altında olacak. PTD dışında her bir ekip üyesinin takip edeceği bir “To-Do List dokümanı” olmalıdır. To-Do List dokümanı bazen yalnızca geliştirme ekibin kendi iç maddelerini içerebilir bazen ise daha büyük açıdan tüm üyelerin takibindeki maddelerden oluşabilir.
Bu dokümanı hazırlamak için en hızlı ve maliyetsiz online bir excel kullanılabilir. Online excel dışında birçok To-Do List uygulaması mevcut bu uygulamalar üzerinden de madde takibi yapıla bilinir. To-Do List dokümanlarında maddelerin sorumlusu ya da sorumluları net olarak belirtilmelidir ve her madde için mutlaka tahmini bir termin tarihi belirlenmelidir. To-Do List dokümanımız sayesinde “anlık olarak hangi statüde kaç maddemiz var?”, “şu an ne durumdayız?”, “herhangi bir risk durumu var mı?” vb. soruların yanıtlarına kolayca ulaşabilir, bunları raporlayabilir ve gerektiğinde müdahale edebiliriz. Böylece proje boyunca her şey kontrolümüz altında kalır.
Bu doküman gerçekten ilginç ve en sevdiğim doküman diyebiliriz. 😊 Şu ana kadar bulunduğum tüm projelerde bu dokümanın çözemediği bir problem görmedim. Haftalık olarak o hafta tamamlanan maddeler, bir sonraki hafta planlanan maddeler ve önem dereceleri ile mevcut riskleri içeren bir rapor tüm proje ekibi üyeleri ile paylaşılır. Ama 1 hafta bile bu dokümanda atlama yapılmamasına dikkat etmek gerekir. Dokümanımız proje paydaşlarında belirli bir süre sonra güven oluşturur. Böylece kimde hangi maddenin ne kadar süre beklediği raporlanmış olur ve bu raporlama, aksiyon maddelerinde tüm ekip üyelerine hız kazandırır.
Bu başlığın en önemli dikkat edilmesi gereken maddesi değişiklik taleplerinin nasıl yönetileceğidir. Bence geliştiricinin en çok motivasyonunu düşüren durum geliştirilen bir web sayfanın ya da servisin silinip yeni baştan yazılmasıdır. Geliştirici olarak görev aldığım projelerde olduğu için bunu çok iyi anlıyorum. Günlerce üzerinde çalıştığınız, bazen çalışırken baş ağrıları yaşadığınız geliştirmeler için “aslında öyle olmamalı değiştirelim” denmesi sizi kötü hissettirecektir. Hele bu bir kere değil çok fazla kez oluyorsa?
Aslında bu durumu engellemek için üst maddelerimizde birçok önlem aldık. 😊 Doğru bir PTD hazırladık, güçlü dokümantasyonlarımız var, iletişim şemamız ile proje ekibi üyeleri arasında doğru iletişimi sağlayıp iletişim kazalarını önledik. Kural olarak bir değişiklik talebi geldiğinde asla hemen kabul etmiyoruz. Değişiklik talebimiz tüm proje ekibi üyeleri tarafından değerlendirilmeli ve daha sonra bir karar alınmalı. Bu değişiklik gerçekten gerekli mi? Neden bu değişikliğe ihtiyaç duyuldu? Değişiklik yapılacak ise zaman planı ve proje maliyeti nasıl etkilenecek? Tüm bu soruların yanıtları proje ekibi üyeleri tarafından verilmeli ve öyle aksiyona geçilmelidir.
Başlığımızda mutlu bir proje süreci demiştik. Tüm proje ekibi üyeleri iletişimlerinde birbirlerine karşı saygılı ve hoşgörülü olmalıdır. Problem yaşandığı durumlarda fevri davranılmamalı, bekleyip üzerine düşünüp öyle iletişim sağlanmalıdır. Her ekip üyesinin kendi sınır alanları vardır. Tabi bu sınırları bilmek zamanla ve tanıyarak olur. Herkes birbirinin sınırlarına saygılı davranmalıdır. Birçok proje aslında bir takım çalışması olduğu için yeri geldiğinde bireysel değil takımca projeye destek verilmelidir. Problemlere birlikte göğüs gerilmeli ortaya çıkan güzel işlerde de birlikte gurur duyulması gerekir.
Test süreci kaos ortamı oluşmasına çok müsait bir süreçtir. Öncelikle test öncesi test adımları doküman olarak en detaylı şekilde hazırlanmalıdır. Testler öncesi hazırlanacak kullanıcı kılavuzları ve kullanıcı eğitimleri oldukça önemlidir. Bu adımlar olmadan test sürecine başlamamak gerekir.
Test ortamında olabildiğince tüm detayları ile canlı ortamın bir simülasyonu oluşturulmalıdır. Ne kadar detaylı ve canlı kullanıma yakın testler yapılır ise projenin canlıya geçişi bir o kadar sorunsuz ilerleyecektir. Testler başladığında test dönüşleri her zaman tek bir dokümanda toplanmalı ve durum, sorumlu kişi bilgileri ile birlikte To-Do List tadında süreç ilerletilmelidir. Düşünün her kullanıcı portalde bir yere tıklıyor hata alıyor ve bu hataları iletiyor. Hangisi çözümlendi, hangisi tekrar eden hata bilinmezse bu süreci yönetmeniz çok zor olur. Geliştirme ekibi ise bu dönüşler içinde kaybolabilir, tekrar eden hatalarda ekstra eforlar harcayabilir.
Tabi ki proje bitse bile destek süreci hep devam eder. İlk 1 ay yoğun bir destek süreci olur, bu süreç zaman geçtikçe hafifler. Aslında proje müşteriye teslim edildikten sonra en önemli süreçlerden biri destektir. Müşteri ürünü, hizmeti satın aldıktan sonra canlı kullanımda yaşadığı herhangi bir sıkıntıda elinizi omuzlarında hissetmek ister. Problemi o an çözmenize gerek yok problem için orda olduğunuzu ve onu yönlendireceğinizi hissettirmeniz yeterli.
Proje sürecinde birlikte çalıştığınız müşteri ile belirli aralıklarla iletişime geçerek projede bir sorun olup olmadığı veya projeyle ilgili herhangi bir desteğe ihtiyaçları olup olmadığınız sorabilirsiniz.
Ve her proje bitse bile bir iz bırakır ardında...
Herkesin mutlu olacağı proje yönetimi aslında imkânsız değildir. Proje yöneticisi olarak projenin 3 ana aşamasında da doğru adımları uygulanmasını sağlayarak herkesin mutlu olduğu bir proje yönetmeniz mümkündür.
SAP ABAP Danışmanı
Doğal Dil İşleme Nedir?
Doğal Dil İşleme (Natural Language Processing) Dil, insanlar arasında anlaşmayı sağlayan bir iletişim aracıdır. Sosyal yaşamın en büyük...
Öneri Yönetim Sistemi Nedir?
Şirket İçi İnovasyon Neden Önemlidir?İnovasyon, var olan ürün veya hizmeti yenilemek, geliştirmek, daha verimli hale getirmek veya yeni...
Elektronik Veri Alışverişi Otomasyonunun (EDI) 6 Faydası
Elektronik Veri Alışverişi Otomasyonu (EDI), bilgisayar sistemlerinin birbiriyle iletişim kurma yeteneğine sahiptir. Bu sayede kâğıt...
6 Adımda SAP Mobil Tahsilat Çözümü
Teknolojik gelişmeler sayesinde her şeyin çok hızlı değiştiği bir çağda işletmeler, günlük işlerini sistemli bir hale getirmek...
GS1 Barkod Sistemi Nedir? GS1 & SAP Entegrasyonu
GS1 sistemi, uluslararası elektronik ticaret uygulamaları için evrensel bilgi tanımlama sistemdir. Tedarikçiler ve müşteriler arasındaki...
SAP PO 7.5 geçişine hazır mısınız?
2020 yılının sonunda SAP PI sürümleri 7.5’den düşük olan sistemlerin desteğinin sona erecek olması SAP PO 7.5’e geçişini zorunlu...
E-Gider Pusulası Nedir?
Günümüzde bir işin hızlı olması daha da önem kazanmıştır. Artık insanlar basit işlere uzun zamanlar harcamaktansa bu işlerini hızlıca...
Depo Yönetim Sisteminin Faydaları
İşletmelerin deposu karmaşık ve dinamik bir yapıya sahiptir ve verimli çalışmasını sağlamak için gerekli en önemli araçlardan biri Depo...
Yazılım Varlık Yönetimi Nedir?
Genellikle Software Asset Management (SAM) olarak adlandırılan Yazılım Varlık Yönetimi, yaşam döngülerinin tüm aşamaları boyunca...
Mailiniz başarıyla gönderilmiştir en kısa sürede sizinle iletişime geçilecektir.
Mesajınız ulaştırılamadı! Lütfen daha sonra tekrar deneyin.