Herhangi bir proje üzerinde çalışırken, zamanla ortada o proje ile ilgili bir çok materyal birikir. Müşterinizden gelen spekler, proje dokümantasyonu, ürünün son halini vermiş tam yeni sürümü çıkaracağınız esnada e-posta ile gelen spek güncellemeleri, proje’ye ilişkin e-postalar… Özellikle de e-postalar, bunların arasında belki en önemlileridir. Proje’nin tarihçesi e-postalarda gizlidir. İçlerinde herhangi bir ihtilafta kurtarıcınız olacak, müşterinize delil olarak gösterebileceğiniz - ama bunun böyle olmasını siz istemiştiniz - malzemelerini taşırlar. Aynı zamanda proje süresince müşteri ile sorunların tartışıldığı ve kararların alındığı ortamlardır.

Proje ile ilişkili materyallerin düzenli bir şekilde saklanıyor olması önemlidir. Eğer bu konuda dağınıksanız, ilerde sıkıntı çekmeniz kaçınılmazdır. Klasör klasör dokümanlarınızı arar, e-postalarınız arasında kaybolursunuz.

Projeleriniz uzun vadeli ya da hizmete dayalı ve sürekli ise bir diğer sorununuz da çalışan devir-daimidir. Yazılım projeleri için konuşursak; şirketinizden ayrılan bir programcının koltuğuna, yeni bir programcı işe alıp oturtarak her şeyin olduğu gibi devam etmesini bekleyemezsiniz. Şirketinizden ayrılan programcı beraberinde çalıştığı projelerin birikimini de götürecektir. Bu birikim içinde en önemlileri: proje’nin ne-neden-ne zaman ve sorun-çözüm bilgileridir.

Kod, koddur. İşten ayrılan programcı kafasında yüzlerce fonksiyon ve değişken bilgileri taze olarak, her an her soruna nokta atışı yapabilecek durumdadır. Fakat bu bilgi, şirket içinde olduğu süre boyunca bile üç, dört ay ayrı bir proje üzerinde çalışsa kendisinin de kaybedeceği, dolayısıyla işe yeni başlayan programcı tarafından zamanla kazanılması mümkün olan bir bilgidir. Her ne kadar bu, proje’nin ilerlemesini yavaşlatsa da, edinilmesi zor bir bilgi değildir.

Bazen proje üzerinde çalışan programcının kodda rastladığı bir işin neden yapıldığını çözemediği durumlar olur. Eski işimde bu durum ile sık karşılaşırdım. Müşterinin yeni istediği özellikler doğrultusunda A fonksiyonalitesinin, B fonksiyonalitesi ile çakıştığı durumlar olur. Kod o kadar kritiktir ki tahmin yürüterek sonuçlara varmanız mümkün değildir. Artık ihtiyaç olmayacağını ya da zaten kapsanacağını düşünerek çıkaracağınız bir satır kod, ciddi sorunlara sebep olabilir. Bu durumda iki şey yapabilirsiniz, ya proje üzerinde daha önce çalışmış ve halen şirket çalışanı olan birini bulur ve konu hakkında bir fikrinin olup olmadığını sorarsınız ya da şanslı iseniz uzun zamandır şirket çalışanı olan ve onlarca projeyi aynı anda takip eden yöneticinizin aklında o konu ile ilgili e-postalarda geçmiş olan bazı kırıntılar kalmıştır. Siz de bunları yöneticinizin o anki 500 MB kotalı, sıkıştırılmış Outlook e-posta klasörlerinde ve öncesinde saklanan arşivlerinde şanslı bir iki kelime ile arar durursunuz. Arama sonuçlarını beklerken, kendinizi geliştirecek bir takım aktiviteler ile de uğraşabilirsiniz. Ofis ortamı müsait ise top sektirme rekorunuzu kırmaya çalışmak buna bir örnek olabilir. Arama sonuçlarınız başarısız olduğunda son olarak müşteriye döner ve onlardan yardım isteyebilirsiniz. Ama bazen bu bile yeterli olmaz. Çünkü müşterinizde yıllardır bu proje ile ilgilenen arkadaşın yerine artık yeni birisi bakmaktadır.

Ayrılan çalışanın beraberinde götürdüğü bir diğer değerli şeyin de sorun ve çözüm bilgileri olduğunu söyledik. Yeri gelecek, müşterinin sorunlarının e-posta ve telefon yolu ile çözülemediği durumlar olacaktır. Bu durumda çalışan saha’da soruna direk müdahale etmek durumunda kalacak ve bir şekilde bu sorunu çözecektir. Belki sorunun çözümü saatlerce ve ya günlerce sürecektir. Fakat en nihayetinde çözülecektir. Eğer bu sorun-çözüm bilgisini düzenli bir şekilde proje içerisinde saklamıyorsanız, daha önce harcadığınız zamanın aynısını ve belki de daha fazlasını eninde sonunda yine harcayacaksınız demektir. Çalışan ile geri döndüğünde sorun ya da sorunlar üzerine muhabbet edip geçmek yerine bunları bir yerde saklarsanız, bir daha ki sefere hatırlamakla uğraşmaz, soruna çok daha hızlı müdahale eder ve zamanınızı da boşuna harcamamış olursunuz. Çalışan işten ayrılmış olsa bile sorunun çözümü bir yerlerde sizinle birlikte kalır.

Peki bu bilgiyi nerede saklayacaksınız?:

E-posta ile mi? Eğer çalışan iseniz belki işe geri döndüğünüzde yöneticinize bu konuda e-posta atabilirsiniz. Belki de bir yerlerde bulunsun diye kendinize e-posta gönderebilirsiniz. E-posta kutularının aradığınız bilgiye ulaşmada çok başarılı olmadığını anlatmaya çalıştığımı anlamışsınızdır. Özel bir konu başlık kalıbı ile belki başarılı olabilirsiniz. Ama ya proje üzerinde sizden başka çalışanlar da varsa. Her proje için e-posta listesi açmak belki bir çözüm olabilir. Belki de e-posta kötü bir fikirdir.

Sürekli ekleme yaptığınız, sorun-çözüm dosyanız mı olmalı? Ortak bir yerde her proje’nin kendi klasörü içerisinde bir sorun-çözüm dosyası’na eklemeler yaparak tutabilirsiniz belki bu bilgiyi. Sorun, çözüm, tarih, yer bilgileri için birer kalıp ile dokümanda tutabilirsiniz. Doküman boyutu sürekli artacak ve aradığınızı bulmakta zorlanacaksınız. Belki de dokümanda tutmak kötü bir fikirdir.

Hata takip sistemi mi? (Yoksa bir yazılım projeniz var ve hata takip sisteminiz yok mu? - Evet diyorsanız okumayı burada bırakabilirsiniz.) Sahada karşılaştıklarınızı bir hata takip sistemine aktarmak pek de mümkün olmayabilir. Birden fazla sorunla karşılaşabilir, bunlara farklı çözümler üretebilir ve ya bu çözümlere dair fikirlerinizi ileriye dönük olarak saklamak isteyebilirsiniz. Bir kaç ufak ayrıntı ile ya da bir config dosyasında bir anahtar kelime ile sorunu çözülebiliyorsunuzdur. Ve ya sahada sorunu çözerken başka yerlerde de uygulayabileceğiniz performansınızı arttıracak bir yol keşfetmişsinizdir, bunu da bir yerlerde saklamak istiyorsunuzdur. Belki de hata takip sisteminde bunları tutmak kötü bir fikirdir.

Önceki işimde dokümantasyon ortamı olarak Word dosyalarını kullanırdık. Çeşitli klasörlere dağılmış bu dokümanlar arasında aradığım içerikteki dokümanı bulmakta bayağı zorlanırdım. Bu konuda oldukça dağınıktık. Doküman paylaşımı için en iyi ortam’ın wiki olduğunu düşünürdüm. Fakat bir versiyon kontrol sistemine geçiş için 6 ay uğraştıktan sonra bu iş için gerçekten hiç isteğim kalmamıştı. Wiki’nin dokümantasyon için ne kadar uygun olduğu malum. Ortak bir çalışma ortamı. İlgili konudaki doküman, çalışanlar tarafından sürekli güncellenebilir ve kolay erişilebilir durumda. En azından bir doküman sistemim var diyebilirsiniz. Ama bahsettiğim sorunlar için düşündüğüm çözüm wiki değil.

Projenizin takibi için, çalışanlar tarafından tutulan şirket içi bir blog’a ne dersiniz? Her proje’nin ayrı bir kategori olduğu, proje üzerinde çalışanların sahaya gittiklerinde yaptıkları işleri, gün içinde karşılaştıkları ve ürettikleri çözümleri yazdıkları, proje’nin belli aşamalarında e-postalar ile yazışmalar sonucunda alınan kararların yazıldığı, müşteri ile ve ya geliştiricilerin kendi aralarında yaptıkları görüşmeler sonrası toplantı notlarının yazıldığı, geliştiricilerin ferdi olarak karşılaştıkları zorluklara ürettikleri çözümleri ve dikkat edilmesi gereken bir takım noktaları yazdıkları bir günlük. İleride yapılacak aramalar için uygun şekilde taglenen içerikli bir günlük. Proje’de başlangıcından bugününe kadar karşılaşılan her türlü sorunun, çözümün ve alınan kararların kronolojik sırada bulunduğu, istendiğinde bu sırada takip edilebildiği, neyin kimin tarafından yapıldığının yazılı olduğu ve her hangi bir konuda arama yapılabilen bir günlük. Projeye yeni katılan birinin de daha kolay adapte olabilmesini sağlayacak bir günlük. Blog’un farklı ve ilginç bir şekilde kullanımı. Belki de proje günlüğü tutmak iyi bir fikirdir…