Yazılım Geliştirici için toplantıdan karara ve aksiyona geçiş: uygulama dosyası

Gündemi beklenen kararla birlikte yazın

Gündemde yalnızca ‘durum değerlendirmesi’ bulunması, toplantının ne üretmesi gerektiğini belirsiz bırakır. Yazılım Geliştirici kapsamında ‘gereksinimi küçük parçalara ayırmak’ konusundaki görüşmede hangi karara ihtiyaç duyulduğunu baştan yazın. Bilgilendirme, seçenek değerlendirme ve onay gündemleri farklı hazırlık gerektirir.

Katılımcıları karar için gerekli bilgi ve yetkiye göre belirleyin. Görüşme öncesinde okunacak kayıtları kısa ve erişilebilir biçimde paylaşın. Bir sayfalık durum özeti; sorun, seçenek, belirsizlik ve önerilen sonraki adımı görünür kılabilir. Böylece toplantı, ilk kez veri toplama faaliyetine dönüşmez.

Yazılım Geliştirici rolünde başlangıç noktası

Bu mesleğe uyarlanmış çalışmada üç görev üzerinden ilerleyin: ‘gereksinimi küçük parçalara ayırmak’, ‘kodu gözden geçirmek’, ‘hata durumlarını test etmek’. Her görevin girdisini, görev sırasında verilen kararı ve sonraki kişiye aktarılacak bilgiyi ayrı yazın. Böylece yöntem, meslek adını değiştiren genel bir şablon olarak kalmaz; gerçek iş akışını incelemek için başlangıç noktası verir.

Beklenen mesleki çıktı ‘kabul ölçütleri doğrulanmış ve incelenmiş yazılım değişikliği’ olarak ele alınmıştır. İşletmenizdeki görev kapsamı farklıysa bu tanımı uygulama başlamadan önce uyarlayın. Aynı unvan farklı şirketlerde farklı sorumlulukları kapsayabilir. Rehberdeki görevler değerlendirme ve öğrenme için örnektir; kurumun güncel görev tanımı, yetki ve kabul koşulları esas alınmalıdır.

Görüş, karar ve aksiyonu ayırın

Bir katılımcının önerisi ortak karar olarak kaydedilmemelidir. Kararın hangi kapsam için geçerli olduğu ve kimin onayıyla alındığı açık olmalıdır. Aksiyon ise kararın uygulanması için yapılacak somut iştir. ‘Takip edilecek’ gibi öznesiz ifadeler yerine sorumlu, çıktı ve tarih yazın.

‘kodu gözden geçirmek’ göreviyle ilgili aksiyonun kapanışını hangi kayıt gösterecek? Bu sorunun yanıtı toplantı bitmeden netleşmelidir. Bir aksiyonun sahibi, işi tek başına yapan kişi olmak zorunda değildir; tamamlanmasını koordine eden kişi olabilir. Gerekli destek ve bağımlılıkları da kayda ekleyin.

Kapanış koşulunu teslimle ilişkilendirin

Bu rolün beklenen çıktısı ‘kabul ölçütleri doğrulanmış ve incelenmiş yazılım değişikliği’ olarak düşünülüyorsa, aksiyonun başarı koşulu bu çıktının kullanılabilirliğine bağlanmalıdır. E-posta gönderilmesi veya toplantı yapılması her zaman işin tamamlandığını göstermez. Sonuç, kabul eden tarafın ihtiyacını karşılamalıdır.

Karar verilemeyen konularda eksik bilgi, bilgi sahibi ve yeniden değerlendirme zamanını yazın. Açık konuyu gündemden düşürmek yerine görünür tutun. Sonraki toplantıyı varsayılan çözüm haline getirmeden, kararın yazılı olarak tamamlanıp tamamlanamayacağını değerlendirin.

Takibi kısa ve düzenli yapın

Aksiyonları açık, sürüyor, engelli ve kanıt bekliyor gibi anlaşılır durumlarla izleyin. Geciken kayıtta sadece yeni tarih istemek yerine gecikme nedenini ve karar gereksinimini görünür kılın. Tarih değişiyorsa önceki hedef ve değişiklik gerekçesi korunmalıdır.

Toplantı sonunda karar özetini katılımcılarla kontrol edin. Özellikle kapsam ve sorumluluk yorumlarının farklı kaldığı noktaları o anda düzeltin. Sonraki görüşmede bütün konuşmayı yeniden anlatmak yerine açık aksiyonlar, değişen koşullar ve yeni karar ihtiyacı üzerinden ilerleyin.

Teknoloji bağlamında kapsamı belirleyin

Teknoloji işlerinde iş talebi, sürüm, test bulgusu ve kabul kaydı birbirine bağlanmalıdır. Bir denemenin başarılı olması, bütün kullanıcılar veya bütün veri türleri için aynı sonucu garanti etmez. Kapsam, bağımlılıklar ve sınanmayan koşullar açık yazılır. Üretim sistemine değişiklik yapılması bu rehberin örnek çalışmasından ayrı bir yetki ve kontrol sürecidir.

Uygulama için temsilî veri ve sınırlı bir test ortamı seçilebilir. İş ihtiyacını açıklayan tarafla çıktıyı değerlendiren tarafın aynı kabul tanımını kullanması gerekir. Sonucun çalışmasının yanında yeniden üretilebilirliği, hata durumundaki davranışı ve bakım sorumluluğu da kayıt altına alınmalıdır.

Örnek senaryo: bir çalışma gününü inceleyin

Aşağıdaki durum öğretici bir kurgu olup gerçek bir müşteri projesini anlatmaz. Yazılım Geliştirici görevini yürüten bir ekip üyesinin aynı konu art arda toplantılarda konuşulmasına rağmen sorumluluk netleşmediğinde kısa bir uygulama başlattığını düşünün. Başlangıçta seçilen iş ‘gereksinimi küçük parçalara ayırmak’ olsun. Mevcut durumu anlatan bir örnek kayıt, beklenen teslim ve ilgili sorumlular aynı dosyada toplanır. Henüz bilinmeyen bilgiler boş bırakılarak kimden yanıt beklendiği yazılır.

İlk değerlendirme ‘kodu gözden geçirmek’ aşamasında yoğunlaşır. Ekip hangi kararın verildiğini, kim tarafından uygulanacağını ve sonucun nasıl kontrol edileceğini netleştirir. Tartışılan her seçenek için ihtiyaç duyulan bilgi ve işi etkileyen varsayım not edilir. Bir kişinin deneyimine dayanan görüşle kayıt üzerinden doğrulanmış bulgu ayrı tutulur. Seçilen yaklaşımın neden uygun görüldüğü kısa ve anlaşılır bir cümleyle açıklanır.

Çalışmanın sonunda ‘hata durumlarını test etmek’ göreviyle bağlantılı kontrol tamamlanır. Ortaya çıkması beklenen araç: karar, gerekçe, sorumlu, hedef tarih ve kabul kanıtı bulunan aksiyon kaydı. Örneğin hedefi belirli bir performans artışı vaat etmek değildir. Amaç, hangi kararın hangi bilgiyle verildiğini ve sonucun nasıl kontrol edildiğini görünür kılmaktır. Beklenen sonuç oluşmadıysa bunun nedeni ve bir sonraki deneme için gerekli bilgi kayda geçirilir.

İlk uygulama için kontrol soruları

Başlamadan önce şu soruları yanıtlayın: İşin sınırı nedir? Gerekli girdiler hazır mı? Karar sahibi kim? Sonucu kim kabul edecek? Kabulün kanıtı hangi kayıt olacak? Bu sorulardan biri belirsizse uygulamanın sonucunu değerlendirmek de güçleşir. Soruların yanıtı uzun olmak zorunda değildir; ilgili kişilerce aynı şekilde anlaşılması yeterlidir.

İzlenebilecek bir gösterge: hedef tarihinde kanıtıyla kapatılan aksiyonların oranı. Ölçümün kapsamını, başlangıç durumunu ve veri kaynağını birlikte yazın. Sayıları farklı iş büyüklükleri arasında doğrudan karşılaştırmayın. Sonucu ekip içinde değerlendirip işe yarayan uygulamayı güncelleyin; işe yaramayan varsayımı da görünür bırakın. Bir sonraki çalışmada aynı hatalı varsayımdan yeniden başlamamak, bu dosyanın somut yararlarından biridir.