Intranette proje ve görev yönetimi: nerede durmalı, nereye karışmamalı?

Intranet içindeki proje modülü, en çok yanlış anlaşılan bileşenlerden biridir. Beklenti çoğu zaman "bize bir proje yönetim aracı lazım" biçiminde gelir; oysa gerçek ihtiyaç genellikle farklıdır: hangi işin nerede olduğunu görmek.

Ne yapmalı, ne yapmamalı?

Yazılım geliştiren bir ekibin sprint panosuna, bağımlılık grafiklerine ve iş yükü hesabına ihtiyacı vardır; bunu özel bir araç yapar ve intranetin o aracı taklit etmesi gerekmez.

Intranetteki proje modülünün karşılığı olduğu ihtiyaç ise şudur: departmanlar arası, orta ölçekli, birkaç aylık işlerin görünür olması. Yeni şube açılışı, bir sistemin devreye alınması, yıllık denetim hazırlığı, bir kampanyanın yürütülmesi.

Bu tür işlerin ortak özelliği, tek bir ekibe ait olmaması ve kimsenin özel bir araca girmek istememesidir.

Görev: atama ve son tarih

Modülün çekirdeği sadedir: bir projenin altında görevler, her görevin bir sorumlusu ve bir son tarihi. Bu üçlü olmadan liste bir yapılacaklar defterine dönüşür ve kimse sahiplenmez.

Sorumlunun kişi olması kritiktir; "Pazarlama" değil, adı yazılı biri. Kolektif sorumluluk, projelerde de sahipsizliğe dönüşür — aynı ilkeyi içerik sahipliği yazımızda ele almıştık.

Durum: az kademe

Yedi durumlu bir iş akışı kâğıt üzerinde ayrıntılı görünür, pratikte kimse doğru kademeyi seçemez. Üç durum çoğu iş için yeterlidir: yapılacak, devam ediyor, bitti.

Bir de dördüncü kademe işe yarar ve genellikle atlanır: bekliyor. Bir görev başkasının işine takıldığında bunun görünür olması, projenin gerçek durumunu gösteren tek şeydir. "Devam ediyor" olarak duran ama aslında üç haftadır bekleyen görevler, proje raporlarını yalancı çıkarır.

Görünürlük: kim ne görmeli?

Projelerin varsayılan olarak org geneline açık olması, çoğu şirkette doğru tercihtir. Bir başka ekibin neye çalıştığını görmek, tekrar eden işleri ve çakışmaları erken ortaya çıkarır.

İstisnalar nettir ve sınırlı tutulmalıdır: satın alma görüşmeleri, yeniden yapılanma çalışmaları, personel süreçleri. Bu projelerin kısıtlı olması gerekir ve kısıt veri katmanında uygulanmalıdır — arayüzde gizlemek yeterli değildir.

Bildirim dengesi

Proje modülleri bildirim üretmeye çok müsaittir: görev atandı, durum değişti, yorum yazıldı, son tarih yaklaştı. Hepsini göndermek katılımı artırmaz, bildirimlerin tamamen kapatılmasına yol açar.

İşe yarayan sadeleştirme: kişiye kendi görevi hakkında bildirim, proje sahibine takılan görevler hakkında bildirim. Geri kalanı akışta kalsın yeter. Bildirim yorgunluğunun genel dinamiğini çalışan katılımı yazımızda ele aldık.

Şablon projeler

Tekrar eden projeler şablona dönüştürülebilir: her yeni şube açılışı benzer adımlardan geçer, her yıllık denetim benzer hazırlık ister. Şablondan üretilen proje, hem zaman kazandırır hem de unutulan adımı önler.

Şablonun canlı tutulması gerekir: her uygulamada ortaya çıkan yeni adım şablona işlenmezse, üçüncü projede yine aynı şey unutulur.

Talep ve görev ayrımı

Sık karışan iki kavramdır. Talep bir kişiden bir birime yapılan başvurudur ve onay bekler (izin, masraf, BT desteği). Görev ise bir kişiye atanmış iştir ve tamamlanma bekler.

İkisini aynı listede toplamaya çalışmak, ikisinin de işlevini bozar. Talep akışını ayrı bir yazıda, sahaya atanan işleri ise saha görevleri yazımızda ele aldık.

Özel araçla birlikte yaşamak

Şirkette zaten bir proje aracı varsa, intranetteki modülün onun yerini almaya çalışması gereksiz bir çatışma üretir. Sağlıklı bölüşüm şudur: ayrıntılı yürütme özel araçta, kurumsal görünürlük intranette. Projenin özeti, sahibi, durumu ve kilometre taşları intranette durur; günlük iş kendi aracında.

Ölçüm

• Geciken görev oranı — son tarihi geçmiş açık görevlerin payı.
• Bekleyen görev süresi — "bekliyor" durumunda ortalama kalış süresi; darboğazları doğrudan gösterir.
• Güncellik — son 14 günde hiç güncellenmemiş aktif proje sayısı.

Sonuncusu en dürüst göstergedir: güncellenmeyen bir proje kaydı, projenin durduğunu değil, kaydın terk edildiğini söyler — ve terk edilmiş kayıtlar tüm modülün güvenilirliğini düşürür.