Zayıf proje iletişimi nasıl çözülür: eksik bilgi, yanlış anlama ve gecikmelerin kökenlerini belirleyin
Kimsenin iletişim kurmadığı yönündeki genel şikayet yerine, ters giden tek bir el değiştirme süreciyle başlayın. Somut bir sonuç seçin: Bir iş arkadaşının eski bir teslimat tarihini kullanması, bir incelemecinin yanlış belgeyi geri göndermesi veya bir kararın iş başladıktan sonra gelmesi gibi. Her bir kişinin hareket ettiği anda elinde ne olduğunu yeniden kurgulayın. Buradaki faydalı soru, bilginin bir sonraki eylemi desteklemeyi ilk nerede bıraktığıdır.\n\nEksik bilgi, yanlış anlama ve gecikme bir arada meydana gelebilir. Geç yapılan bir düzeltme, orijinal iletinin geç kaldığını kanıtlamaz; okundu olarak işaretlenen bir ileti de içeriğinin anlaşıldığını göstermez. Aşağıdaki yöntem, bir olayı incelemek için editoryal bir yoldur, yeni bir raporlama sistemi değildir. Ekibin hâlihazırda sahip olduğu kayıtları kullanın.
Açıklamaya başlamadan önce olayı dondurun
Beklenen eylemi, gerçekleşen eylemi ve bunların ayrıştığı noktayı yazın. Orijinal iletiyi ve atıfta bulunduğu belgenin sürümünü saklayın; bugünün düzeltilmiş dosyası, bir iş arkadaşının dün ne gördüğünü gösteremez. Bilinmeyen bir zamanı hafızadan doldurmak yerine bilinmiyor olarak kaydedin. İnsanlar olayları farklı hatırlıyorsa, her iki anlatımı da tarihli kayıtların yanına koyun. Birinin genel olarak dikkatli olup olmadığını değil, söz konusu işi sorun. Küçük, sınırları belirli bir olayı doğrulamak, birbiriyle ilişkisiz şikayetler yığınından daha kolaydır.
Gerekli bilginin var olup olmadığını öğrenin
Göndericinin, alıcının ihtiyaç duymasından önce ilgili gerçeği bilip bilmediğini kontrol edin. Bir teslim tarihi henüz kararlaştırılmamışsa bu açık, üzerinde anlaşılmış bir tarihin dağıtılamaması değil, çözülmemiş bir karardır. Eğer gerçek mevcut idiyse, onun ilk kayıtlı sürümünü ve onu alması beklenen kişiyi tespit edin. Alıcı listesinden çıkarılan bir isim, erişilemeyen bir ek ve bulunmayan bir kabul koşulu farklı türde boşluklardır. Ray Boedecker'ın PMI makalesi, kimin bilgiye ihtiyacı olduğunu ve ne zaman soru sorulacağını veya bilgilendirme yapılacağını bilmeyi vurgular; ileti göndermeyi, el değiştirme sürecini tamamlamakla eşdeğer tutmaz.
Anlamları ancak sürümleri karşılaştırdıktan sonra karşılaştırın
Her katılımcıdan talep edildiğine inandığı eylemi tarif etmesini isteyin. Nesneyi, son teslim tarihini, tamamlanma koşulunu ve varsa bağımlılıkları karşılaştırın. Örneğin, “perşembe günü hazır” ifadesi bir kişi için şirket içi incelemeye hazır anlamına gelirken, bir başkası için dışarıya gönderilmeye hazır anlamına gelebilir. Bu açıklayıcı bir örnektir, rapor edilmiş bir şirket vakası değildir. Öncelikle her iki kişinin de gerçekten aynı ifadeleri gördüğünden emin olun. Farklı belge sürümleri, yorumlama sorunundan önce bir dağıtım sorununa işaret eder. APM'nin iletişim kılavuzu; kitleye, iletiye, yönteme ve zamanlamaya dikkat edilmesini destekler; olay incelemesi ise burada bunlardan hangisinin ilgiye ihtiyacı olduğunu belirler.
Her şeye gecikmiş demek yerine beklemenin nerede olduğunu tespit edin
Bilginin erişilebilir hale geldiği zamanı, gönderildiği zamanı, erişilebildiği zamanı ve kullanıldığı zamanı tek bir çizgiye yerleştirin. Bunları bilginin gerekli olduğu kararlaştırılmış zamanla karşılaştırın. Hızlı bir yanıt bile iş için çok geç kalabilir; ertesi gün gelen bir yanıt ise kararlaştırılmış bir takvime uygun olabilir. Kararlaştırılmış bir yanıt süresi yoksa, kaçırılmış bir taahhüt uydurmak yerine bu eksikliği kaydedin. Ardından neyin beklendiğini kontrol edin: erişim, açıklama, uzman incelemesi, uygun kapasite veya onay. Onaydaki bir gecikme, birinin yanıt verme istekliliği hakkındaki bir varsayıma değil, karar rolüne dair kanıta ihtiyaç duyar.
Açıklamayı bir karşı örnekle test edin
Bir düzeltme seçmeden önce, açıklamanızı neyin yanlış çıkaracağını sorun. İş arkadaşınız güncel dosyayı almış ve talep edilen eylemi doğru şekilde tarif etmişse, daha fazla hatırlatma yapmak geriye kalan engeli çözmeyecektir. Bir incelemeci tavsiyede bulunmuş ancak değişikliği onaylayamamışsa, bekleme durumu yetkiyle ilgili olabilir. Atlassian'ın DACI kılavuzu, katkıda bulunanları karar veren kişiden ayırır; ekibin mevcut yetkisi referans noktası olmaya devam eder. Sırf bu olayı araştırmak için DACI'yi zorunlu kılmayın. Kusursuz bir ileti olsa bile, bir sonraki görevin eksik malzemeler veya iş yükü nedeniyle yine de engellenip engellenmeyeceğini de kontrol edin.
İncelemeyi kanıtlanmış tek bir değişiklikle kapatın
Kanıtlanan ilk kopukluğu, sonucunu ve buna bağlı en küçük düzeltmeyi özetleyin. Atlanan bir alıcının yalnızca o spesifik el değiştirme anında dahil edilmesi gerekebilir; belirsiz bir tamamlanma koşulu için her iki tarafça üzerinde anlaşılmış somut bir örnek gerekebilir. Düzeltmeyi kimin yapacağını belirtin ve bir sonraki benzer el değiştirmeyi aynı aksaklık açısından inceleyin. Kanıtlar eksikse, neyin hâlâ kontrol edilmesi gerektiğini belirtin. Bu inceleme, kanıtlanmış bir açıklama ve test edilebilir bir uyarlamayla sona erer. Bilgi paylaşımı veya eskalasyon sürecinin tamamını baştan tasarlamak ayrı bir görevdir ve yalnızca tekrarlanan olaylar daha geniş bir ihtiyacı gösterdiğinde yapılmalıdır.