Departmanlar arası projelerde nasıl iş birliği yapılır: bilgi engellerini ve sorumluluğu başkasına atmayı azaltmak
Departmanlar arası iş birliği, bir ekibin çıktısının diğer bir ekibin girdisi haline geldiği noktada somutlaşır. Yeni toplantılar eklemeden önce neyin el değiştireceği, bunu kimin hazırlayacağı, kimin kontrol edeceği ve neyin onu kullanıma hazır kılacağı konusunda anlaşın. Bir departmanın kendi görevinin bittiğini söylemesi, sonraki departmanın başlayabileceğini göstermez.\n\nProjeye önemli bir devir teslimle başlayın. Her departmanın çalışma yöntemlerini baştan tasarlamanıza gerek yoktur. İki tarafın da aynı teslimatı tanıması ve hiçbir tarafın üstlenmediği sorumlulukları belirlemesi için yeterli düzeyde paylaşılan detaya ihtiyacınız vardır.
İşi teslim alacak ekipten geriye doğru çalışın
Basılı bir ziyaretçi rehberi hazırlamak için kurgusal bir projeyi ele alalım. Bir editör ekibi metni hazırlar, tasarımcılar sayfaları oluşturur ve bir operasyon çalışanı da baskıyı ayarlar. “İçeriği salı günü gönderin” ifadesi henüz işe yarar bir devir teslim değildir. Yazarlar çözülmemiş yorumların yer aldığı bir taslağın yeterli olduğunu düşünebilirken, tasarımcılar onaylanmış metne, görsel alt yazılarına ve net bir sayfa düzenine ihtiyaç duyabilir.
İşi teslim alacak kişiye sonraki göreve başlamadan önce nelerin elinde olması gerektiğini sorun. Ardından işi gönderecek kişiye bu girdinin kararlaştırılan süre içinde gerçekten üretilip üretilemeyeceğini sorun. Dosyanın konumu ve kullanılacak sürüm de dahil olmak üzere cevabı mevcut görevin yanına yazın. Bu, teslim alan ekibin dayattığı bir talepler listesi değil, iki taraflı bir anlaşmadır.
Bağımlılığı görünür kılın
Rehber için, sayfa düzeninin onaylanmış metne ve baskının ise kontrol edilmiş baskı dosyasına bağlı olduğunu kaydedin. Her iki uçtaki irtibat kişisini belirleyin. Bir girdi değiştiğinde oluşacak etkiyi not edin: geciken bir paragraf yalnızca yeni bir e-posta değil, başka bir mizanpaj kontrolü de gerektirebilir. Kuruluştaki tüm ilişkilerin haritasını çıkarmaktan kaçının; yalnızca bu teslimatı etkileyen bağımlılıklara odaklanın.
Atlassian'ın Bağımlılık Haritalama (Dependency Mapping) kılavuzu, ekiplerin girdi ve çıktı yönlü etkileri, sorumluları, riskleri ve inceleme düzenlemelerini belirlemesini önerir. Bu, bir departmandaki son teslim tarihinin otomatik olarak diğer departmanın işini de kapsadığını varsaymak yerine, ilişkinin görünür kılınmasını destekler. Haritayı etkilenen ekiplerle tartışın; çünkü bir koordinatör, ekiplerin bağlı olduğu tüm girdileri bilmeyebilir.
Belirlenmiş roller arasındaki işleri netleştirin
Rehber, net bir sorumlusu olmayan bir görevi açığa çıkarabilir: her görsel alt yazısının nihai görselle eşleşip eşleşmediğini kim kontrol edecek? Görevin yanına “editör ve tasarım” yazmak aynı belirsizliği gizleyebilir. Kontrolü hangi kişinin yapacağını, eksik bilgileri kimin sağlayacağını ve sonucun kullanılabilir olduğunu kimin onaylayacağını sorun. İsimler, kabul edilen bir sorumluluğu ve kişinin gerçek kapasitesini yansıtmalıdır.
Atlassian'ın Roller ve Sorumluluklar (Roles and Responsibilities) çalışması, görevler çakıştığında birincil bir sorumlu belirlenmesini önerir. Sahipsiz görevler, bir kişinin sorumlu bulmasını ve bir takip tarihi belirlemesini gerektirir. Bu, küçük bir görev ortaya çıktığında kalıcı yeni bir rol uydurmak anlamına gelmez. Öncelikle mevcut bir sorumluluğun bunu makul bir şekilde kapsayıp kapsayamayacağına bakın; kimse üstlenemiyorsa, çözülmemiş kapasite veya yetki konusunu açıkça belirtin.
İşi teslim almanın ne anlama geldiği konusunda anlaşın
Gözlemlenebilir az sayıda teslim alma koşulu belirleyin. Tasarım devir teslimi için bunlar; eksiksiz bir metin dosyası, onaylanmış görsel alt yazıları ve ayrı olarak işaretlenmiş çözülmemiş sorular olabilir. Böylece teslim alan kişi nelerin mevcut, nelerin eksik olduğunu söyleyebilir. Paylaşılan bir klasörü açmak veya “teşekkürler” şeklinde yanıt vermek, sessizce eksik işin kabulü anlamına gelmemelidir.
Scrum Kılavuzu, Scrum içinde tamamlanan işe dair ortak bir anlayış oluşturmak için bir Bitti Tanımı (Definition of Done) kullanır. Sıradan bir departmanlar arası projenin bu çerçevenin tamamını benimsemesine gerek yoktur. Buradaki faydalı ilke, tamamlanma durumunu buna bel bağlayan herkes için anlaşılır kılmaktır. Sırf gönderenin süresi doldu diye bir taslağı nihai olarak adlandırmayın ve teslimattan sonra değişikliği kabul etmeksizin yeni kabul talepleri eklemeyin.
Tüm sorunu başkasına yıkmadan değişen bir girdiyi yönetin
Onaylanan metin mizanpajdan sonra değişirse hangi sayfaların etkilendiğini ve nelerin yeniden kontrol edilmesi gerektiğini kaydedin. Düzeltilen metinden yazar sorumlu olmaya devam eder; tasarımcı gereken mizanpaj çalışmasını onaylar; koordinatör ise baskı düzenlemesinin etkilenip etkilenmediğini kontrol eder. Bunlar ayrı taahhütlerdir. Bir kişinin herkese haber vermesi, bu üç işin tamamını otomatik olarak devraldığı anlamına gelmez.
İlk devir teslimden sonra yapılan anlaşmayı gerçekleşenle karşılaştırın. Teslim alan kişinin elinde kullanılabilir materyal var mıydı? Roller arasında kalan herhangi bir iş oldu mu? Bir düzeltme, fark edilmeyen bir bağımlılık yarattı mı? Süreci genişletmeden önce söz konusu anlaşmayı uyarlayın. Her departmanın mevcut araçlarını çalıştıkları yerlerde tutun ve projenin ilerleyebilmesi için aralarındaki bağlantıları yeterince açık hale getirin.