Proje Yönetimi ve İletişim

Projede muhatabınız kim olacak?

Her projeye bir proje yöneticisi atanıyor. Talebiniz, geri bildiriminiz ve onayınız bu kişiye gidiyor; teknik ekibi arayıp tek tek durum sormanız gerekmiyor. Proje yöneticisi işin teknik içeriğine hâkim oluyor, yani sorularınızı "sorayım da haber vereyim" diye ertelemiyor.

Teknik ekiple doğrudan konuşmak istediğiniz durumlar oluyor; buna karşı değiliz. Ortak bir mesajlaşma kanalı açıyoruz ve tasarımcı, geliştirici ve proje yöneticisi bu kanalda bulunuyor. Tek kural, kapsamı etkileyen kararların kanalda sözlü kalmaması: her karar yazılı özet olarak kayda geçiyor.

Hangi kanalları kullanıyoruz?

Günlük yazışma için mesajlaşma kanalı, resmî onaylar ve teslimler için e-posta, ekran üzerinden konuşulması gereken konular için kısa video görüşmeler kullanıyoruz. Tasarım geri bildirimlerini tasarım dosyasının üzerine yorum olarak alıyoruz; böylece "üstteki bölümdeki yazı" gibi belirsiz tariflerden kurtuluyoruz.

Hata bildirimleri için ayrı bir liste tutuyoruz. Bir hata bildirdiğinizde kayıt numarası alıyor, hangi ekranda, hangi tarayıcıda ve hangi adımlarla oluştuğu yazılıyor. Bu, aynı hatanın iki kez bildirilmesini ve düzeltilen bir hatanın gözden kaçmasını engelliyor.

Ne sıklıkta bilgilendiriliyorsunuz?

Aktif geliştirme dönemlerinde haftada bir durum notu gönderiyoruz. Not üç bölümden oluşuyor: bu hafta tamamlananlar, gelecek hafta planlananlar ve sizden beklenenler. Üçüncü bölüm en kritik olanı; içerik metni, logo dosyası, bayi listesi veya bir entegrasyonun anahtar bilgisi gecikirse takvimin nerede kayacağını önceden görüyorsunuz.

Uzun projelerde ayda bir kısa toplantı yapıyoruz. Bu toplantıda ilerlemeyi ekran üzerinden gösteriyor, öncelik değişikliği gerekip gerekmediğini konuşuyoruz. Toplantı gerekmiyorsa yapmıyoruz; toplantı sayısı proje sağlığının göstergesi değil.

Onay noktaları nerede?

Projede üç resmî onay noktası var. Birincisi kapsam dokümanının onayı; bu onay olmadan tasarıma başlamıyoruz. İkincisi ana sayfa ve bir iç sayfa tasarımının onayı; bu onay tasarım dilini sabitliyor ve sonraki sayfalar bu dilden türetiliyor. Üçüncüsü yayın öncesi kabul onayı; staging ortamındaki sürümü kontrol listesiyle birlikte gözden geçiriyorsunuz.

Onaylar yazılı alınıyor. Bunu bürokrasi olsun diye değil, hafızayı korumak için yapıyoruz. Dört ay süren bir projede kimin neyi ne zaman onayladığını hatırlamak mümkün değil; yazılı kayıt her iki tarafı da koruyor.

Değişiklik talepleri nasıl yönetiliyor?

Proje sırasında yeni fikirler çıkması normal, hatta iyi bir işaret. Sorun, bu fikirlerin sessizce plana eklenmesi. Kapsam dışı bir talep geldiğinde önce anlıyoruz: gerçekten yeni bir özellik mi, yoksa mevcut kapsamın yanlış anlaşılmış bir parçası mı. İkinci durumda ek ücret konuşmadan düzeltiyoruz.

Gerçekten yeni bir talepse süre ve bedel etkisini hesaplayıp yazılı olarak iletiyoruz. Üç seçenek sunuyoruz: plana ekleyip takvimi uzatmak, mevcut kapsamdan denk bir maddeyi çıkarıp yerine koymak veya ikinci faza bırakmak. Kararı siz veriyorsunuz. Kapsam değişikliklerini sessizce yutmuyoruz, çünkü yutulan her değişiklik projenin sonunda kaliteden çalınıyor.

Gecikme olursa ne yapıyoruz?

Gecikmeler oluyor. Bir entegrasyonun karşı tarafındaki belgeler eksik çıkabiliyor, bir tedarikçi anahtarı geç verebiliyor, ekipten biri hastalanabiliyor. Bizim kuralımız, gecikmeyi fark ettiğimiz gün bildirmek. Teslim tarihinde "yetişmedi" demek yerine, iki hafta önce "şu nedenle risk var, iki seçenek şunlar" demeyi tercih ediyoruz.

Gecikmenin bizden kaynaklandığı durumlarda telafi planını da birlikte sunuyoruz. Bu genellikle kapsamın önceliklendirilmesi anlamına geliyor: kritik akış zamanında yayına alınıyor, ikincil ekranlar birkaç hafta sonra ekleniyor.

İçerik ve görsel sorumluluğu kimde?

Bu, projelerin en sık aksadığı nokta. Metinleri kimin yazacağı ve görselleri kimin sağlayacağı kapsam dokümanında açıkça yazıyor. İçerik sizde ise teslim tarihlerini de takvime koyuyoruz; içerik gelmediğinde geliştirme durmuyor ama tasarım onayı bekliyor.

İçerik yazımını bizden isterseniz bunu ayrı bir kalem olarak fiyatlandırıyoruz. Bu durumda sizinle içerik görüşmesi yapıyor, sektöre özgü bilgileri sizden alıyoruz. Kaynağını sizden almadan yazılan metin, teknik olarak doğru ama işletmenize ait olmayan bir metin oluyor; bunu tercih etmiyoruz.

Proje bittikten sonra iletişim nasıl devam ediyor?

Yayın sonrası ilk otuz gün proje yöneticisi aynı kalıyor; bu dönemdeki düzeltmeler için ayrıca destek talebi açmanız gerekmiyor. Otuz günün sonunda, bakım anlaşmanız varsa destek kanalına geçiş yapıyoruz. Bakım anlaşmanız yoksa taleplerinizi saatlik olarak karşılıyoruz ve her talep öncesi tahmini süreyi yazılı bildiriyoruz.

Eski müşterilerimizin çoğuyla ilişki, yılda birkaç kez gelen küçük geliştirme talepleriyle sürüyor. Bu talepleri sıraya alırken önceliği acil sorunlara veriyoruz; planlı geliştirmeler için takvim veriyoruz. Ne zaman başlayabileceğimizi tahmin yerine tarih olarak söylüyoruz.

Aynı anda kaç projeyle ilgileniyorsunuz?

Ekip kapasitesini aşan sayıda işi aynı anda kabul etmiyoruz. Bir projeye başlayabileceğimiz tarihi tahmin olarak değil, takvimde gerçek bir tarih olarak söylüyoruz. Bu bazen "altı hafta sonra başlayabiliriz" demek anlamına geliyor; hemen başlayıp sonra yavaş ilerlemeyi tercih etmiyoruz.

Her ekip üyesinin aynı anda ilgilendiği aktif proje sayısını sınırlı tutuyoruz. Sürekli bağlam değiştiren bir geliştiricinin hem hız hem de hata oranı belirgin şekilde kötüleşiyor; bu, ölçtüğümüz ve dikkate aldığımız bir gerçek.

Acil bir talep geldiğinde bunun başka bir projeyi etkileyeceğini açıkça söylüyoruz. Bir işi öne almak, mutlaka bir başka işi geriye itiyor. Bu kararı sessizce vermek yerine, etkilenen tarafla konuşup birlikte planlamayı tercih ediyoruz.

Toplantı mı yazışma mı tercih ediyorsunuz?

Konuya göre değişiyor ve ayrımı net yapmaya çalışıyoruz. Bir kararın gerekçesinin anlatılması, birden fazla seçeneğin tartışılması veya ekranın üzerinde konuşulması gerekiyorsa toplantı daha verimli. Bilgi aktarımı, onay ve durum güncellemesi ise yazışmayla daha hızlı hâllediliyor.

Yazıyla halledilebilecek bir konu için toplantı kurmanın hem sizin hem ekibin zamanını harcadığını düşünüyoruz. Buna karşılık ekran üzerinden gösterilmesi gereken bir konuyu uzun mesajlara sıkıştırmak da yanlış anlaşılmalar üretiyor.

Her toplantının sonunda kısa bir özet yazıyoruz: konuşulanlar, alınan kararlar ve kimin ne yapacağı. Bu özet toplantının kendisinden daha kalıcı oluyor. Proje bittikten aylar sonra bir kararın nedeni sorulduğunda bu özetlere dönebiliyoruz.

Ekipten biri ayrılırsa proje etkilenir mi?

Bu riski baştan yönetiyoruz. Her projenin en az iki kişi tarafından biliniyor olmasını takvim planlarken gözetiyoruz; tek kişinin bildiği bir proje, hem sizin hem bizim için risk anlamına geliyor.

Kod deposu, kurulum adımları, karar kayıtları ve teknik notlar proje boyunca güncel tutuluyor. Bir ekip üyesi değiştiğinde devir, sözlü aktarıma değil bu belgelere dayanıyor. Proje yöneticisi değişimi olduğunda ise değişimi önceden bildiriyor ve devir görüşmesine sizi de dahil ediyoruz.