Bazı özelliklerin neden sunulmadığını anlamak çoğu zaman zorlayıcı olabilir. Yönetim teknik ekipleri suçlayabilir, teknik ekipler ise yönetimi suçlayabilir. Bu arada, iş tarafı ortada kalmış durumda ve koşullar ne olursa olsun sonuç almak için çabalarken temel nedeni belirlemeye çalışıyor. Bu senaryo genellikle önemli şirket büyümesinden sonra veya daha önce düzeltilmesi kolay olan sorunların zaman içinde ihmal edilmesi durumunda ortaya çıkar. Bir teknoloji şirketindeki tüm sorunların tamamen teknik olduğu düşüncesi yaygın bir yanılgıdır; bu gerçeklerden uzaktır. Bu makalede, bir şirketin organizasyonu içinde özellik sunumunu önemli ölçüde engelleyebilecek alanları özetleyeceğim. Ayrıca, temel nedenleri belirlemek için araştırmaya yönelik talimatlar da önereceğim; bunlar daha sonra sizin yetki seviyeniz dahilinde üst kademeye iletilebilir veya çözülebilir. Herhangi bir değişiklik veya iyileştirmeyi uygulamaya koymadan önce çalışma ortamımızı anlamak çok önemlidir. Bu konuyla ilgili pek çok aydınlatıcı kitap yazılmış olmasına rağmen, her yaklaşım her şirkete uymayacaktır. Bu, yanlış bir şey yapmanın yansıması değil, daha ziyade her şirketin benzersiz doğasının kabul edilmesidir. Önemli bir not, burada paylaşılan görüşlerin öncelikle yazılım geliştirmeyle ilgili olduğu ve en çok 50 veya daha fazla çalışanı olan şirketler veya departmanlar için geçerli olduğudur. Örgütsel yapı Her şeyden önce şirketinizin boyutunu ve yapısını anlayın. Çeşitli departmanları tanımlayın ve her birinden beklentilerinizi netleştirin. Tüm bu departmanların gerekli olup olmadığını değerlendirin. Her departmanı ve rollerini detaylandıran, ne yaptıklarını ve neden var olduklarını anlamanızı sağlayacak şekilde organizasyon yapısının bir diyagramını oluşturun. Çoğu zaman, her departman birkaç takımdan oluşur; bunları da şemanıza dahil edin ancak şimdilik bunları açıklamayın, sadece takım isimleri olarak kalın. Şirketler büyüdükçe organizasyon yapıları karmaşık hale gelebilir ve ilerlemenin izlenmesini zorlaştırabilir. Bu karmaşıklık içinde, belirli departmanların veya ekiplerin oluşturulmasının ardındaki asıl mantığı gözden kaçırabilirsiniz. Artık geçerli olmayan sorunları çözmek için bazı ekipler kurulmuş olabilir. Burada, yüksek düzeyde nasıl görünebilir. Organizasyon yapınızın net bir şemasına sahip olduğunuzda, sırada ne var? Çalışan hiyerarşisi Daha sonra, çalışanlarınızın hiyerarşisini haritalandırmak önemlidir. Kimin kime ve neden rapor verdiğini anlamak çok önemlidir. Hat yöneticilerinin, ister büyük bir iş birimini ister küçük bir ekibi yönetsinler, astlarıyla etkili bir şekilde iletişim kurmaları gerekir. Her ikisini de ele almak zor olabileceğinden, iletişim teknik veya iş dilinde açık olmalıdır. Daha büyük şirketlerde, hiyerarşi diyagramınızda açıkça temsil edilmesi gereken, farklı sorumluluk alanlarına sahip doğrudan ve fonksiyonel yöneticiler olabilir. Çalışan hiyerarşisi yalnızca raporlama hatlarını netleştirmekle kalmaz, aynı zamanda kuruluş içindeki sektörlerin belirlenmesine de yardımcı olur. Dikeyler; tasarımcılar, İK, DevOps ve hatta geliştiriciler gibi birden fazla departman arasında paylaşılan kaynaklar olarak hizmet veren hiyerarşik yapılardır. Dikeyler çok faydalı olabilse de, özellikle geliştiriciler farklı projeler üzerinde çalıştığında ve iş hedeflerine veya teknik zorluklara aşina olmayan yöneticilere rapor verdiğinde bazen darboğaz haline gelebilirler. Sonuç olarak geliştiriciler doğru geri bildirimleri alamıyor, yöneticilerin ise uygun bir bağlamı yok. Bu nedenle hiyerarşiyi anlamak, potansiyel sorunları veya görevlerin önceliklerini belirlemek ve analiz etmek için hayati öneme sahiptir. O zaman sonunda böyle bir şeye sahip olacaksın. Dipnot CEO Genel Müdür CPO — Baş Ürün Sorumlusu CTO — Baş Teknik Sorumlu COO — Operasyon Direktörü HD — Tasarım Başkanı PO — Ürün Sahibi HE — Mühendislik Başkanı HS — Satış Müdürü HM — Pazarlama Müdürü D — Geliştirici PM — Ürün Müdürü TL — Teknik Lider EM — Mühendislik Müdürü S — Satış Müdürü M — Pazarlamacı Her çalışanın çeşitli faaliyetlere katılımı hakkında bilgi edinmek için organizasyon yapınızı raporlama hatlarınızla karşılaştırın. Üstelik organizasyon yapınızı çalışan hiyerarşisiyle uyumlu hale getirmek, bireylerin aynı departmanlar ve ekipler içinde ve ortak bir amaç doğrultusunda çalışıp çalışmadığını belirlemenize yardımcı olabilir. Haritalama şablonu tamamen size kalmış ama şöyle de olabilir. Ekibin sorumlulukları Her ekibin faaliyet gösterdiği alanı açıkça tanımlamak önemlidir. Bir ekip kodla çalışıyorsa kullandıkları hizmetleri ve sahip olduklarını belirtin. Şaşırtıcı bir şekilde, bunlar genellikle farklı olabilir. Ekibin yalnızca bir departmanda mı çalıştığını yoksa doğrudan değiştirmeden diğer ekipler tarafından kullanılan temel özellikler üzerinde çalışan bir platform ekibi mi olduğunu belirleyin. Aşağıdaki sütunlardan oluşan bir tablo oluşturmak çok yararlı olabilir: ekip adı, departman, sahip olunan hizmetlerin listesi, ekibin değiştirebileceği ancak sahip olmadığı genel hizmetlerin listesi (ideal olarak bu tür hizmetlerin olmaması gerekir) ve kısa bir açıklama . Bu tablo, birden fazla ekibin aynı kod temeli üzerinde çalışıp çalışmadığını, çatışmalara yol açıp açmadığını veya sorumluluk alanlarıyla ilgili netlik eksikliği olup olmadığını incelemenize yardımcı olacaktır. Ayrıca bir ekibin öncelikle hataları mı düzelttiğini yoksa net bir odaklanma olmadan çeşitli görevlerle mi uğraştığını da ortaya çıkarabilir. Bu düzeydeki ayrıntı, ekip sorumluluklarındaki örtüşmeleri, çatışmaları ve boşlukları belirlemek, daha sorunsuz işbirliği ve daha verimli proje yürütme sağlamak için çok önemlidir. Çalışanın sorumlulukları Ekipleri tanımlamanın yanı sıra genel çalışanların pozisyonlarını anlamak ve sorumluluklarının ayrıntılı bir tanımını hazırlamak çok önemlidir. Çoğu zaman, yönetimin öngördüğü şeyler çalışanların gerçekte yaptıklarından önemli ölçüde farklı olabilir. Yazılım geliştirme sektörünün çeşitli pozisyonları vardır ve beklentiler şirketten şirkete büyük ölçüde değişebilir. Örneğin, bir Mühendislik Yöneticisinin rolü, Teslimat Yöneticileri, Veri Bilimcileri, Mimarlar, Teknik Liderler vb. rollerin yanı sıra büyük ölçüde farklılık gösterebilir. Bazı şirketlerde tek bir kişinin birden fazla görevi yerine getirmesi beklenebilir. Her pozisyon için net beklentiler belirlemek önemlidir. Bu netlik, yalnızca faaliyetlerin doğru bir şekilde izlenmesine yardımcı olmakla kalmaz, aynı zamanda çalışanların kendilerinden ne beklendiğini ve neyin kendi kapsamlarının dışında kaldığını anlamalarını da sağlar. Bu, organizasyon içindeki tüm pozisyonlar için geçerlidir. Açık rol tanımları çakışmayı önlemeye, kafa karışıklığını azaltmaya yardımcı olur ve herkesin ortak hedefler doğrultusunda verimli ve düzenli bir şekilde çalışmasını sağlar. Özellik teslim süreci Şimdiye kadar şirket yapınızı, çalışan hiyerarşisini ve sorumluluklarını net bir şekilde anlamış olmalısınız. Her ne kadar işler kafa karıştırıcı görünse de amaç, herhangi bir değişiklik yapmadan önce öncelikle mevcut durumu anlamaktır. Şimdi özellik sunma sürecinizi, yani iş özelliklerinin ilk fikirden üretime nasıl geçtiğini açıklamanın zamanı geldi. Lütfen burada CI/CD gibi teknik yönlere odaklanmayın, geliştiricilerin kod yazdığını ve bunu doğrudan üretime dağıttığını varsayarak iş dünyasından geliştiricilere giden akışa odaklanın. Amaç, işten ekibe kadar sürecinizdeki sorunları belirlemek ve çalışanların buna ne kadar iyi uyum sağladığını görmektir. Şu yönleri göz önünde bulundurun: Ne sıklıkta yeni özellikler planlıyor ve her departman ve ekip için iş ataıyorsunuz? Temel performans göstergelerini nasıl belirliyor ve ölçüyorsunuz? Kilometre taşlarını kullanıyor musunuz? İlk hazırlıklarına kimler katılıyor? Bunları ekiple nasıl planlıyorsunuz? Planlama ve yürütme sürecini kim koordine ediyor? Gerçekten çevik bir şirket misiniz? SAFe, Prince2 veya PMP gibi çerçeveler mi kullanıyorsunuz yoksa işinize yarayacak özelleştirilmiş bir şeyiniz mi var? Ekipler arası karmaşık görevleri nasıl ele alıyorsunuz ve ilerlemeyi nasıl kontrol ediyorsunuz? Yapılandırılmış bir yaklaşımınız var mı, yoksa olayların bir şekilde çözüleceğine mi güveniyorsunuz? Unutmayın, yönetim ve raporlamanın her düzeyi, yönü ne olursa olsun karmaşıklık ve belirsizlik katar. Sonuçta süreç diyagramınız basit bir soruyu yanıtlamalıdır: "Nasıl?" Şablonlarla oynayabilir ve ihtiyaçlarınıza göre ayarlayabilirsiniz. Burada, teslimatı düzenleyen kilit oyuncuların olmadığı ancak zaman dilimleri olan teslimat sürecinin çok yüksek düzeyde bir örneği bulunmaktadır. Bu diyagramın nasıl oluşturulacağından emin değilseniz, tüm paydaşlar arasında netlik ve anlayış sağlamak için BPMN (İş Süreci Modeli ve Gösterimi) veya dikdörtgenler ve çizgiler gibi daha basit bir format kullanmayı düşünün. Önemli olan süreci açık ve anlaşılır kılmaktır. Geri bildirim toplayın Şirket yapısının, çalışan hiyerarşisinin, ekiplerin ve pozisyon sorumluluklarının ve teslimat sürecinin haritasını çıkardıktan sonra, tüm bulgularınızı kuruluşla paylaşın ve tercihen isimsiz bir anket yapın. Bu temel, şirketinizin nasıl çalıştığını vurgular. Bu genel bakışı kendiniz hazırlamış veya bazı görevleri devretmiş olsanız da geliştiricilerin, tasarımcıların ve analistlerin doğrudan sürece dahil olmaması muhtemeldir. Bulgularınızın doğruluğunu değerlendirmek için geri bildirimleri çok önemlidir. Çalışanlarınızdan belgelerinizin kalitesini değerlendirmelerini isteyin. Teslimat süreci hakkında ne düşünüyorlar? Gerçekten işlerin nasıl yapıldığını yansıtıyor mu? Engelleri nerede görüyorlar? Bulgularınızı şirketin operasyonlarının gerçekliğine daha iyi uyacak şekilde geliştirmenize yardımcı olacak çeşitli şikayet ve geri bildirimler bekliyoruz. Bu geri bildirim, bağlamın çoğu zaman birden fazla hiyerarşi düzeyinde kaybolması nedeniyle hayati öneme sahiptir ve tüm düzeylerden girdi toplamak, kuruluşun daha net, daha doğru bir resmini sağlayacaktır. Sonuçları tahmin edin Artık şirketinizin veya departmanlarınızın nasıl çalıştığına dair kapsamlı bir açıklamaya sahip olduğunuza göre, potansiyel sorunları analiz etmeye ve araştırmaya başlayabilirsiniz. Bu temel, sorunları anlamak ve çözmek için net bir başlangıç noktası sağlar. Odaklanmanız gereken bazı alanlar şunlardır: Departmanlarınız yapılandırılmış mı? Raporlama hatları açık mı? Bölüm yöneticileri gerçekten kendi sorumluluk alanlarıyla ilgili geri bildirimde bulunabilir mi? İş gereksinimlerini teknik görevlere dönüştürmede karışıklık veya belirsizlik var mı? Geliştirme sırasında gecikmelere neden olan diğer ekiplere bağımlılıklar var mı? Çalışanlar, asıl sorumluluk alanları dışında, asli görevlerini aksatacak faaliyetlerde bulunuyor mu? Çalışan hiyerarşisi ekip yapısıyla ne kadar uyumlu? Raporlama hiyerarşisi etkili mi, yoksa iletişim ve bağlamda boşluklar mı var? Farklı ekipler aynı hizmetler üzerinde çalışıyor, bu da çatışmalara ve görev sahipliğine karar vermede zaman kaybına neden oluyor mu? Açıkça tanımlanmış sorumlulukları olmayan veya önemli oyuncuları eksik olan takımlar veya departmanlar var mı? Bazı ekipler herhangi bir departmana entegre değil mi? Daha sonra şirketinizin sahip olduğu gerçek sorunların bir listesini hazırlayabilirsiniz, bu da üzerinde çalışacağınız bir şeydir. Anında etkileşim gerektiren kritik iyileştirmelerden "sahip olunması iyi" iyileştirmelere kadar bunları önceliklendirin. Değişiklikler nasıl yapılır? Şunu merak ediyor olabilirsiniz: "Bunların hepsi kulağa harika geliyor, ama aslında işleri nasıl geliştirebilirim?" Bu iyi bir sorudur ve dürüst yanıt, tanımladığınız belirli sorunlara ve iş gereksinimlerinize bağlıdır. Ancak önemli bir tavsiye, her şeyi bir anda değiştirmeye çalışmaktan kaçınmaktır. Bunun yerine, küçük değişiklikleri aşamalı olarak uygulayın, sonuçları değerlendirin ve yineleyin. Çevik yaklaşımın yalnızca yazılım geliştirmede işe yaramadığını, her türlü organizasyonel değişime uygulanabileceğini unutmayın. İyileştirme sürecinize rehberlik edecek bazı adımlar şunlardır: Çalışanların, rollerinin neleri gerektirdiğini ve nelerin sorumluluklarının dışında kaldığını tam olarak bilmelerini sağlayın. İyi tanımlanmış departmanlar veya alanlar oluşturun ve her alana belirli ekipler atayın. Açık sorumluluk alanlarını tanımlayın ve departmanlar ve ekipler için çakışmaları en aza indirin. Yazılım geliştirmenin çeşitli yönlerini kapsayacak şekilde platform, akış hizalı, etkinleştirme ve karmaşık alt sistem ekiplerini tanıtan Ekip Topolojileri yaklaşımına kendinizi alıştırmayı düşünün. Yeni kurulan alan adları ve ekiplerle uyum sağlamak için çalışan hiyerarşinizi gözden geçirin ve ayarlayın. Raporlama yapılarının açık olduğundan ve ilerleme takibinin basit olduğundan emin olun. Özellik sunumu ve izleme sonuçları için kullanacağınız metodolojiyi veya çerçeveyi seçin. Değişiklikleri herhangi bir departmanda (tercihen kritik olmayan) test edin ve etkiyi değerlendirin, geri bildirim ve sonuçlara göre yaklaşımınızı iyileştirin. Seçilen zihniyeti organizasyonel değişikliklere uygulayarak sürekli gelişin. Bu adımları izleyerek kuruluşunuzun verimliliğini ve etkinliğini kademeli olarak artıran bilinçli, kademeli değişiklikler yapabilirsiniz. Özet Herhangi bir şirket veya departmanda ortaya çıkabilecek ortak sorunları vurgulamayı amaçladım. Belirli çerçeveleri veya yaklaşımları tavsiye etmekten kasıtlı olarak kaçındım çünkü her şirketin kendine özgü hedefleri ve yapıları vardır ve sizin için neyin en iyi olduğuna karar vermek çok önemlidir. Tekrar ediyorum, suçu geliştiricilere yüklemek kolaydır ancak geliştiricilerin iş önceliklerinden habersiz olabileceğini veya belirsiz teslimat süreci nedeniyle engellenmiş olabileceklerini unutmayın. Bazen işletmenin kendisi bilinçsizce engelleyiciler yaratır. Bu makalenin iyileştirmeye yönelik ilk adımları atmanıza yardımcı olacağını umuyorum.
