Uzun zamandır beklenilen bu konu sonunda yürürlüğe girmiş. PMI Türkiye bu konudaki çalışmalarını sürdürüyordu ve 2010 sonu itibarı ile sınavların Türkçe alınabileceğini belirtmişlerdi. 2011′e yeni girdiğimiz şu sıralar bu çalışma tamamlanmış ve artık PMP sınavları Türkçe alınabilecek. PMBOK Türkçe (Proje Yönetimi Bilgi Birikimi Klavuzu) ve CSG (Birleşik Standartlar Sözlüğü) temel alınarak hazırlanan sınavlar PMI tarafından sunulmaya başlamış. Türkçe PMP sınavına girmek isteyen adayların PMI web sayfasından (www.pmi.org) başvurularını yaparken başvurunun son aşamasında, “Language Aid” bölümünde “Turkish” seçeneğini işaretlemeleri yeterli olacak…
PMBOK 4th Edition ile Birleşik Standartlar Sözlüğününün Türkçe’ye çevrilmesi ve sınavın da artık Türkçe alınabilmesi, Türkiye’de proje yönetimi konusuna ilginin artmasını ve gelişimini destekleyecektir. Daha önceki yazılarımda da vurgulamıştım, ülkemizin çok daha fazla PMP’ye ihtiyacı var. Sınavın da artık Türkçe olması sertifikalı sayısını arttıracaktır.
Diğer bir haber de CAPM sınavı da çok yakında Türkçe alınabilecekmiş. Bu da gençlerin, bu sertifikayı almasını kolaylaştıracaktır.
Ülkemize hayırlı olsun.
Henry Gantt (1861-1919), planlama ve kontrol tekniklerinin babası olarak bilinmektedir. Henry Gantt, Amerikalı bir makine mühendisi ve yönetim danışmanıymış. Proje Yönetimi ile uğraşan herkes GANTT şemalarını bilir. Henry Gantt, GANTT şemasını 1910-1915 yıllarında tasarlamış.
Bu konuyu biraz daha araştırdığınızda GANTT şeması kavramının gerçek mucidinin, Rusya’dan Polonyalı mühendis Karol Adamieki (1866-1933) olduğunu görüyorsunuz. Karol bu şema kavramını 1896 yılında geliştirmiş ve zaman çizelgesi anlamına gelen Harmonogram, Harmonograf olarak adlandırmış. Maalesef Karol, bulduklarını Lehçe ve Rusça dillerinde dokümante etmiş. Batı dünyasında bu diller bilinmediği için Karol Adamieki hiç bir zaman bu şemanın babası olarak anılmamış. Biz bu şemayı bugün GANTT şeması olarak biliyoruz. Halbuki bu şemanın babası Henry Gantt değil, Karol Adamieki.
Geçen yıl Anadolu Üniversitesi Endüstri Mühendisliği kulübü, IV.MÜYAK (Mühendislik Yönetimi Akademisi)etkinliğine beni konuşmacı olarak davet etmişlerdi. Geçen yıl yaptığım sunum dikkatlerini ve ilgilerini çekmiş, bu sene 5.etkinliklerine tekrar davet ettiler. Bugün, 25 Aralık 2010, Eskişehir’e gidip öğrencilere tekrar bir konuşma yaptım.
2009′da yaptığım sunum uzun sürmüştü. Bu sene katılımcı sayısı da oldukça fazlaydı. Bugünkü sunumumu 45 dakikaya sığdırmaya çalıştım. Proje Yönetimi konusunda bilgi aktardım ve bu mesleğe yönelmeleri için dinleyici öğrencileri teşvik etmeye çalıştım. CAPM (Certified Associate in Project Management) sertifikasını almalarını önerdim. Geçen yıl da aynı vurguları yapmıştım. PMI Türkiye’den bahsettim ve web sayfasının linkini www.pmi-tr.org paylaştım. İş yaşamına başlayacaklar ve proje yönetimi konusunu öğrendikleri takdirde kariyerlerinde hızla ilerleyebilecekler. Çevremdeki gençleri bu sertifikayı almaları için yüreklendiriyorum. İletişim bilgilerimi paylaştım ve bu konuda isteyen herkese elimden geldiğince destek olacağımı da söyledim. CAPM sertifikası almak isteyenleri bekliyorum, destek vereceğim.
Bugün, bütün dünyada proje yönetimi günü olarak kutlanıyor. Artık Türkiye’de de kutlamalar yapılmaya başladı. Bu sene PMI TR ile İPYD ortak etkinlik düzenliyor. Bugün İstanbul’da yarın da Ankara’da proje yönetimi günü kutlanacak. İleriki yıllarda çok daha geniş kitlelere ulaşarak daha büyük organizasyonlar ile uluslararası proje yönetimi gününü kutlayacağımıza inanıyorum.
Bu konu ile uğraşan, işi proje yönetimi olan hepimiz için “Uluslararası Proje Yönetimi Günü” kutlu olsun.
IPMA (International Project Management Association) 24. Dünya proje Yönetim Kongresi 1-3 Kasım tarihlerinde İstanbul’da gerçekleştirildi. Daha önceki bir yazımda belirtmiştim, IPMA en eski proje yönetimi kuruluşu ve 1965 yılından bu yana aktif. İsviçre kökenli bir kuruluş. Etknlikleri 1 Kasım pazartesi günü başladı. Çalıştığım şirket, Avea, sponsor olduğu için 2 gün etkinliklere katıldım. Pazartesi günü sponsor olarak bir de konuşma yaptım. Konuşmamda Avea’daki proje yönetimi tecrübesini aktarmaya çalıştım. Biz projeleri nasıl yönetiyoruz? Proje Yönetimi disiplinini nasıl uyguluyoruz? Bunları aktarmaya çalıştım. Bana ayrılan süre 20 dakikaydı. Salonda bulunan dinleyicilerin %90′ı yabancı olduğu için sunumu İngilizce yaptım. Sunumumun sonunda şirketimizin “Proje Yönetimi Olgunluk Seviyesini (Project Management Maturity Level)” ve bize göre çizilen bu seviyenin neresinde durduğumuzu gösterdim. Benimle birlikte diğer sponsorlar, Vodafone ve Turkcell de sunum yaptılar.
Sunumlarımız bitince dinleyicilerin sorularını aldık. Proje Yönetimi Olgunluk Seviyesi dinleyicilerin çok ilgisini çekti ve bu konuda birkaç soru geldi. Bir tanesi bu konuda eklediğim görselin kaynağının neresi olduğu diğeri de biz bu seviyeyi korumak için neler yapıyoruz… Proje Yönetimi olgunluk seviyesi ile ilgili birçok görsel var. Farklı kurumların hazırladıkları ya da bu konuda profesyonel çalışan kişilerin oluşturdukları birçok görsel var. Ben içlerinden bir tanesini seçtim, bize uygun olduğunu düşündüm. Seçtiğim görsel aşağıda.
Burada ilk adım olan ad-hoc, ihtiyacımız olduğunda proje yönetmeye çalışıyoruz. Planned, projeler için plan yapıyoruz. Managed, proje yönetimini şirket içinde bazı departmanlarda gerçekleştiriyoruz ama tümünde değil! Integrated, proje yönetimini bütün departmanlarda gerçekleştiriyoruz. Sustained, bütün organizasyonda proje yönetimi yapıyoruz ve şirketin stratejik bakış açısıyla uyumlu projeler gerçekleştiriyoruz, program yönetimi var…
Biz proje yönetimi disiplinini şirkette oturttuk. Kendi metodolojimiz var. PMO, program yönetim ofisi, var. Proje Yönetimi kültürü şirkette oluşmuş durumda. Proje Yöneticisi arkadaşlarımızı sürekli eğitiyoruz. Proje Yöneticilerini ayda bir bir araya toplayıp proje yönetimi üzerine fikir paylaşımında bulunuyoruz. 2 sene içinde 20 kişi PMP oldu. Hatta bunların 17 tanesi, geçen sene 8 ay içinde bu sertifikayı aldı. Eğitimden geçen, PMP olan arkadaşlar belli bir disiplin içinde proje yönetimi metodolojimizi uygulayarak projeleri yönetiyorlar. Her proje sonunda öğrenilen dersler (lessons learned) hazırlıyorlar ki daha sonra yapılacak projelere tecrübeleri aktarıyorlar.Görselde 4-5 arasında yer aldığımızı düşünüyorum. Vurguladığım gibi proje yönetimi kültürünü sağlamlaştırmak için, elimizden geldiğince, çalışmalarımıza devam ediyoruz.
20 ekim tarihi dünya istatistik günü olarak kutlanıyor. 20 Ekim 2010 tarihi bu kutlamanın ilk tarihi. Birleşmiş Milletler Genel Kurulu’nun 64/267 sayılı kararnamesi ile, 20 Ekim 2010 tarihinin “Resmi İstatistiklerdeki Başarıların Kutlanması” ana teması altında ve hizmet, doğruluk ve profesyonellik ana ilkeleri göz önüne alınarak “Dünya İstatistik Günü” olarak kutlanması kararlaştırılmıştır. Üye ülkelerin yanı sıra, Birleşmiş Milletlere bağlı alt kuruluşlar, diğer uluslararası ve bölgesel kuruluşlar ile sivil toplum örgütlerinin de söz konusu kutlamaya katılımı teşvik edilmektedir.
Ben de lisans eğitimini İstatistik üzerine yapmış ve bu konunun önemini bilen bir kişi olarak dünya istatistik gününü kutluyorum. Bizde bu konuya yeterince önem verilmediğini düşünüyorum ama zamanla bu bilinç artacaktır, buna inanıyorum. Daha önce yazmış olduğum bir yazıda, “Matematik yerine İstatistik”, Prof Dr. Arthur Benjamin’in vurguladığı ve benim de aynı fikirde olduğum yaşayan insanların istatistik bilmesi, olaylara istatistiki olarak yaklaşması hayatımızı kolaylaştıracaktır.
Bilinirliğin artması adına ülkemizde de istatistik konusunda etkinliklerin çoğalmasını bekliyorum.
Şirketten arkadaşım, Murat, bayramda Amerika’ya gitti. Öncesinde hem o hem de ben e-kitap okuyucu için araştırma yapmıştık. Birçok kişinin bildiği Amazon’un Kindle’ı ve Barnes & Noble’ın Nook’u bu konuda öne çıkıyor. Farklı markaların başka okuyucuları da var. Daha önce bu ürünleri inceleme fırsatımız da olmamıştı. Internet’ten yaptığım araştırmalarda benim değerlendirmeme göre Nook, Kindle’a göre daha öne çıktı ve Murat’a Nook siparişi verdim. Bu cihazları Türkiye’den sipariş ederek getirtemiyorsunuz. Ancak giden birisine sipariş etmek gerekiyor.
20 Eylül’de Murat Amerika’dan döndü ve sipariş ettiğim Nook’u getirdi. O da kendisine Kindle aldı. Kindle 139$, Nook ise 149$ fiyatla satılıyor. Her ikisi de e-ink teknolojisini destekliyor ki cihaz üzerinde bir dokümanı okumaya çalışınca sanki bir kağıt üzerinde yazılmış gibi görüyorsunuz. Bunu sağlayan da e-ink teknolojisiymiş. Bu cihazlar farklı formattaki dokümanları destekliyor. Her ikisinde de pdf formatında bir dokümanı okuyabiliyorsunuz. Bununla birlikte Nook’un desteklediği e-kitap formatı “e-pub”, Kindle’ınki ise “mobi”. Kitaplar için para ile satın alınabilen Amazon ya da Barnes & Noble gibi siteler var, aynı zamanda ücretsiz kitap edinebilecek siteler de mevcut. Maalesef henüz Türkiye’deki e-kitap sayısı çok az. Idefix, D&R gibi web sitelerinde Türkçe e-kitap’lar var ama vurguladığım gibi az. 2 haftada Nook’tan iki kitap okudum. Oldukça başarılı. Kitap okuyan bir kişi için güzel bir cihaz, binlerce kitabı fiziki olarak bir yere yerleştirme zahmetinden sizi kurtarıyor. Kağıt gibi olduğu için karanlıkta ekstra dışarıdan ışığa ihtiyaç var. Cihazın üstüne takılabilen aydınlatma aksesuarlarını da piyasaya sürmüşler.
Niye Nook seçtim? Kindle ile Nook karşılaştırınca her ikisinin de avantaj ve dezavantajlı özelliklerinin olduğunu görüyorsunuz. Öncelikle Kindle, Nook’tan daha hafif. Ayrıca Kindle’da sesli okuma özelliği var. Nook ise Android tabanlı bir cihaz. Üstündeki işletim sistemi kırılabiliyor. Böylelikle birçok ilave özellik kullanıma geliyor. Nook’u Kindle’dan ayıran diğer önemli farklar ise Nook’ta pil değiştirmek mümkün ve üzerine microSD ilave bellek takılabiliyor. Ayrıca üzerindeki yazılım güncellenebiliyor. Nook’un bu özellikleri, Kindle’dan daha ağır olmasına rağmen, Nook’u seçmeme neden oldu. Seçimimden memnunum. Bu konu ile ilgilenenlere tavsiye ediyorum. Google’dan topladığım karşılaştırma linkleri aşağıda, inceleyebilirsiniz.
http://ezinearticles.com/?Kindle-Nook-Comparison—Which-E-Reader-is-Right-For-You?&id=4514665
http://comparisonz.com/comparisons/100142/kindle-vs-nook/
http://www.teleread.com/2010/08/04/comparison-of-kindle-wifi-and-nook-wifi-by-kindle-review/
http://ireaderreview.com/2010/04/24/kindle-vs-nook-review-2010/
e-kitap okuyucularla ilgili Türkiye’deki en kapsamlı araştırma ve inceleme, dilerseniz aşağıdaki link’i inceleyebilirsiniz.
http://gofret.wordpress.com/2010/12/18/turkiye%E2%80%99deki-en-kapsamli-e-kitap-okuyucu-arastirmasi-ve-incelemesi/
Geçen sene Türkiye’deki CAPM sertifikasına sahip kişiler ile ilgili bir yazı yazmıştım. PMI’nın online registry sayfasından sorgulama yapmış ama doğru rakamlara ulaşamamıştım. Bir arkadaşım yazıya eklediği yorumla esasında Türkiye’de 2009 başı itibarı ile 5 tane CAPM olduğunu belirtmiş ve ben de tekrar sorgulama yaparak bunu görmüştüm.
Sanırım PMI veri tabanını sorgulama biçimim artık doğru. Dün tekrar bir sorgulama yapıp Türkiye’de bugün itibarı ile kaç tane PMP, CAPM, PMI-RMP, PgMP ve PMI-SP olduğunu öğrenebildim. Veri tabanından yapmış olduğum sorgulamada, sertifika sahibinin adı-soyadı, hangi il’den PMI’ya kayıt olduğu ve sertifikayı hangi yıl aldığı bilgisi de var.
22 Ağustos 2010 tarihi itibarı ile rakamlar şöyle…
PMP sertifikasına sahip toplam 714 kişi var listede. Listede 2 kişi var, ülke olarak Türkiye görünmekle birlikte bu kişilerin belirttikleri şehir yurtdışı… Bu 2 kişiyi listeden çıkartırsak Türkiye’deki PMP sayısı toplam 712 kişi. PMP’lerin illere göre dağılımı: Istanbul 516, Ankara 144, Kocaeli 25, İzmir 16, Bursa 1, Mersin 1, Rize 1, Konya 1, Kütahya 1, Zonguldak 1, Kayseri 1, Antalya 1, Tekirdağ 1, Sakarya 1, Adana 1
PgMP sertifikasına sahip şu anda 1 kişi var, listede Ankara olarak görünüyor, kendisi aynı zamanda PMP ve 17 Temmuz 2010 tarihinde sertifikayı almaya hak kazanmış.
CAPM sertifikasına sahip toplam 8 kişi var. İçlerinden birisi daha sonra PMP sertifikası da almış. İllere göre dağılımı: İstanbul 6, Ankara 1 ve Konya 1
PMI-RMP sertifikasına sahip 1 kişi var, listede Istanbul olarak görünüyor ve aynı zamanda PMP sertifikasına da sahip.
PMI-SP henüz yok. Bakalım zaman içerisinde bu sertifikayı da alacak kişiler olabilir.
70 milyon nüfusu olan bir ülke olarak sertfikalı sayısının bu rakamların çok üzerinde olması lazım, kafamdaki rakam en az 5000 kişi olmasının gerektiği… PMP sınavı inşallah bu sene sonunda Türkçe alınabilecek. PMBOK Türkçe de bu sene piyasaya çıktı. Bu rakamların önümüzdeki birkaç yıl içerisinde hızlı bir şekilde artacağına inanıyorum.
Daha önce de birkaç yazımda vurgulamıştım blog’uma olabildiğince iş ağırlıklı yazılar yazıyorum. Arada sırada hobilerim ve kendi yaşamım ile ilgili yazılar da yazıyorum. Bugün yaşadığım yoğun duygular ve düşündüklerimin kayıt altına alınması için bu yazıyı yazmak istiyorum.
Kızım, Zeynep, bugün 12:15′de Delta Airlines ile Amerika’ya uçtu. Öğrenci Değişim programı kapsamında geçen sene sınava girdi ve başarıyla geçti. Yaklaşık 2 yıldır bunu kendisi istiyor. Lise 3′ü orada okuyacak. Bu kendi kararıydı. Eşim ve ben onu yönlendirmedik. Kendi vermiş olduğu karardan dolayı onu destekledik. Son3-4 aydır hazırlıkları sürüyordu. Eşim inanılmaz koşturdu, hazırlıkları için en ince detayına kadar uğraştı onu hazırladı. Bu hazırlık sürecinde içimde oluşan duyguları anlatamam. 17 yıldır kızımla beraberiz. 2 sene önce 1 aylığına İngiltere’ye gitmişti. En uzun ayrı kaldığımız süre oydu ama o zaman bu kadar etkilenmemiştim. Bu sefer çok daha uzun bir süre…
Zeynep, Amerika’da Virginia Beach şehrinde kalacak. Okyanus kıyısında 500.000 nüfusu olan sevimli bir yer. Kalacağı ailenin biri 17 yaşında diğeri de 12 yaşında iki kızı var. Anne öğretmen, baba bankacı. Gideceği yer belli olduktan sonra Zeynep aileyle iletişim kurdu. Aile heyecanla Zeynep’i bekliyor. Oradaki ailesi bizlere ve kendisine çok sıcak mesajlar gönderdiler. Eşimle benim ilk başlardaki tedirginliğimiz gitti. Zeynep’in yaşında olan Victoria diplomat olmak istiyormuş. Türkiye ve Türkçe ile ilgileniyor. Geçen sene Ankara’ya gelmiş bir süre kalmış. Bu yıl da Istanbul’a Türkçe öğrenmeye geldi Temmuz başında ve 6 hafta burda kaldı. Zeynep gitmeden Victoria ile tanışma fırsatı oldu. Bu onun için çok iyi oldu. Onun da içinde bazı tedirginlikler vardı. Amerika’da beraber olacağı, aynı evde yaşayacağı kardeşi ile tanışmış olduğu için kendini iyi hissetti.
Oldukça uzun bir süre bizim için. Bugün yolcu ederken içimiz iyice parçalandı, duygulandık, göz yaşlarımıza hakim olamadık. Onu çok ama çok özleyeceğiz. Programın bize aktardığı diğer bir konu da anne ve baba, çocukla 6 ay yüz yüze görüşemiyor. Anne, Baba olarak baktığınızda bu durumu kabul edemeseniz de bunun haklı nedenleri var. Bakalım biz gidebilirsek Şubat ayında onu görmeye gidebileceğiz.
Evet bu, Zeynep’in kararıydı ve bu kararına sıkıca tutundu. Kafa olarak kendini hazırladı ve gitti. Zeynebime güveniyorum, başarılı olacağına eminim. Yolun açık olsun bitanem, seni çok seviyorum.
Değişiklik istekleri (change request) bir projede farklı kanallardan gelebiliyor. Bir proje nasıl ortaya çıkıyor? Çalıştığınız şirketin yapısına bağlı değişiklikler gösterebilir. Örneğin benim çalıştığım şirkette projeler şu şekilde ortaya çıkıyor. Ben bir GSM operatöründe program yöneticisi olarak çalışıyorum. Yukarıdan baktığınız zaman şirketimiz, kabaca, Teknoloji, Satış, Pazarlama ve Müşteri Hizmetleri bölümlerinden oluşuyor. Teknoloji dışındaki bölümler ihtiyaçlarını karşılamak için Teknoloji bölümüne ihtiyaçlarını bildiriyor. Teknoloji bölümü bu süreçte müşteriden iş gerekçesini istiyor. Tamam bu projeyi yapalım ama bunun sonucunda şirket ne kazanacak? Müşteri sayısı artacak mı, gelirimiz artacak mı? Bu akış tanımlanmış bir süreç çerçevesinde ilerliyor. İş’i isteyen, proje sonunda ortaya çıkan hizmeti, ürünü veya uygulamayı kullanacak olan bölümler Teknoloji bölümüne göre “müşteri”. İş’in sahibi bu bölümler. Daha fazla detaya girmeyeyim. Projenin yapılabilirliği iş analistleri tarafından çalışılıyor, analiz ediliyor. Eğer yapılabilir ise ne kadar sürede yapılacağı ve kabaca bütçesi müşteri ile paylaşılıyor. Projenin başlamasına karar veriliyor ve proje yöneticisi atanıyor. Artık elimizde bazı biligiler var, tahmini süre, bütçe ve eğer başka bir firma (tedarikçi) ile çalışılacaksa onların bilgileri vs… Proje kickoff toplantısı ile başlatılıyor. Planlama aşamasında proje paydaşları olarak hem müşteri hem de teknik proje ekibi ile yoğun mesai yapılıyor. Bütün bunların koordinasyonunu proje yöneticisi yapıyor. Bu çalışmaların içerisindeki en önemli doküman “kapsam dokümanı”. Kapsam çıkartılıyor ve müşterinin onayına sunuluyor. Kapsam dokümanı projede ne yapılacak, müşteri tarafından ne isteniyor gibi bilgilerin detaylı olarak yer aldığı doküman. Bu doküman müşteri tarafından onaylanınca artık taraflar arasında mutabakat sağlanmış oluyor. Sonrasında tasarım aşamasına geliniyor, tasarım çalışmaları yapılıyor. Bu çalışmalar sırasında da müşteri ile iletişim devam ediyor. Tasarım dokümanı da onaylanıyor. Eğer proje bir yazılım geliştirme sürecini içeriyorsa tasarım onayından sonra geliştirmeler başlıyor. Vurguladığım gibi bu geliştirmeleri şirket içi kaynaklarla ve/veya tedarikçi bir firma ile yapabilirsiniz. Geliştirmeler bittikten sonra geliştirilen uygulamanın mevcut alt yapınıza entegrasyonu için testler yapılıyor. Bu teknik testler başarı ile tamamlanınca artık geliştirilen uygulama, yani müşterinin istediği uygulama son kullanıcı testi (UAT: user acceptance test) için hazır hale geliyor. Müşteri son kullanıcı testlerini de başarı ile bitirirse artık proje hayata geçiyor ve tamamlanıyor. Bu aşamadan sonra operasyon başlıyor ve projeyi şirketin operasyon bölümü devir alıyor.
Proje başladıktan sonra analiz yapılırken, tasarım çalışmaları sürerken müşteriden değişiklik istekleri gelebiliyor. Şuna da ihtiyacımız var, yeni bir düzenleme geldi şunları da eklememiz gerekiyor, tasarımı böyle yaptık ama kullanıcı ekranında şu buton şurada olsun, ben bu butona basığımda bir bilgilendirme mesajı önümüze çıksın, almak istediğim raporlar için şu tip raporları da ekleyelim gibi birçok değişiklik isteği geliyor. Değişiklik istekleri bir projenin doğasında vardır ve normaldir. Fakat proje sağlığı açısından değişiklik isteklerinin proje akışında bir noktaya kadar gelmesine izin vermek gerekiyor. Örneğin artık test aşamasına gelmişsiniz, tasarım onaylanmış, geliştirmeler tamamlanmış, artık projenin sonuna yaklaşmışsınız. Müşteri önünüze değişiklik isteği ile geliyor. Bu durum projeyi maliyet ve zaman açısından etkiliyor. Baştan planladığınız sürede bitiremeyeceksiniz ve üzerine fazla para harcamanız gerekiyor. Ben program yönetici olarak proje yöneticisi arkadaşlarıma tasarım sürecinin sonuna kadar müşteriden değişiklik isteklerini alabileceklerini ve değerlendirebileceklerini söylüyor ve onların da müşteriye bu bilgiyi aktarmasını istiyorum. Tamam müşterinin ihtiyacı varsa bu yapılacak, ihtiyacını karşılamak lazım. Ama bu ilave ihtiyaçların projenin 2.fazı olarak ele alınacağını müşteri ile paylaşmalarını, proje yöneticilerinden istiyorum.
Bu arada değişiklik istekleri sadece iç müşterinizden gelmiyor. Proje için birlikte çalıştığınız tedarikçi firma da karşınıza, farklı bir şekilde, değişiklik talebi ile çıkabiliyor. Örneğin tasarım aşamasında birlikte çalışmış, sonrasında çıkan dokümanı da şirket olarak onaylamışsınız. Geliştirmeler yapılıyor, teste geliyorsunuz ve geliştirilen uygulamayı fonksiyonel olarak ele alıyorsunuz, bakıyorsunuz ki eksikler var. Bunu tedarikçi firmaya iletiyorsunuz, bakın tasarım dokümanında yazdık bunu bekliyorduk ama şu anda yok bunu da eklemelisiniz diyorsunuz. Tedarikçi firma orada yazanı biz şu şekilde algılıyoruz, bu istek bir değişiklik isteğidir, daha önce konuşulan, yazılan şeylerin dışındadır diyebiliyor. Sonra ne oluyor, başlıyorsunuz kavga etmeye bu değişiklik isteğidir, değildir yapmalısınız vs.
Geçen yıl Değişiklik Yönetimi konusunda bir yazı yazmıştım. O yazıda kaleme aldığıım durum farklı bir değişiklik isteğiydi. O zaman üstünde çalıştığımız büyük bir projede çalıştığımız tedarikçi firma ile aramızdaki onların hatasından kaynaklanan bir durum için karşımıza değişiklik isteği ile gelmişler ve biz de bunu kabul etmemiştik. Biz onların hatası olduğunu ortaya koyuyorduk onlar da hayır siz bizi beklettiniz biz şu kadar adamı burada tuttuk, bize şu kadar para vermelisiniz diyorlardı. Oldukça sıkıntılı bir durumdu ve yönetmekte zorlanmıştık. O yazımda da bu tür değişiklik isteklerinin önüne geçmek için neler yapılması gerektiğini vurgulamıştım.
Bir projede değişiklik isteklerinin (change request) hangi süreçte ele alınacağının ve işleyişin, sürecin nasıl olması gerektiğinin başlangıçta belirlenmesi önemli. Değişiklik isteği proje ekibine nasıl ve hangi yolla iletilecek? Değişiklik istekleri nasıl analiz edilecek? İletilen değişiklik istekleri nasıl takip edilecek? Değişiklik isteğinin onaylanması ya da reddedilmesi için neler yapılacak? Büyük projelerde, örnek olarak 1 yıldan fazla süren, değişiklik yönetimi sürecinin proje başlangıcında çok net belirlenmesinde fayda var.
Değişiklik isteklerini ilk karşılayan kişi Proje Yöneticisidir. Gelen istekleri proje ekibi ile değerlendirip analiz eder. Projeye olan etkisi (zaman, maliyet…) çıkartılır. Analiz tamamlanıp dokümante edilince değişiklik kontrol kuruluna (change control board – CCB) proje yöneticisi tarafından aktarılır. CCB değişiklik isteği üstünde bir değerlendirme yapar ve sözkonusu isteğin yerine getirilip getirilmeyeceği konusunda bir karar verir.
Geçen seneki yazım Vikipedi Özgür Ansiklopedi’de ele alınan Değişiklik Yönetimi makalesinde kaynak olarak gösterilmiş. Sonradan fark ettim, ben bunun için bir şey yapmadım. Ama tanımadığım birisi yazımı kaynak olarak göstermiş, çok memnun oldum. Blog’umda yazdığım bu yazılar okuyanlara bir şeyler verebiliyorsa ne mutlu bana.
