İskenderun’da Yazılımcı ile Çalışmak: İhtiyaç Tarifi, Toplantılar, Deneme ve Geri Bildirim

Yazılımcıyı seçtiniz, ilk görüşme yapıldı, anlaşma imzalandı. İşin asıl uzun kısmı şimdi başlıyor: ihtiyacın tarif edilmesi, ekranların konuşulması, ilk sürümün denenmesi ve geri bildirimle düzeltilmesi. İskenderun’da bir yazılımcı ile çalışan işletmelerin zorlandığı yer genellikle teknik değil, bu iletişim düzenidir. Yazılımcı işletmenin işini bilmez, işletme sahibi de yazılımın dilini; aralarında köprü kurulmazsa program istendiği gibi değil, anlaşıldığı gibi çıkar.

Firma seçerken nelere bakılacağını İskenderun’da işletmeye özel yazılım rehberinde ayrıca anlattık. Bu yazı seçimden sonrasıyla, yani birlikte çalışma süreciyle ilgili.

İhtiyacı kullanıcının ağzından yazın

“Stok modülü olsun” bir istek değil, bir başlıktır. Yazılımcının işine yarayan tarif, programı kimin, ne için kullanacağını söyleyen kısa cümlelerdir. Yazılım dünyasında bunlara kullanıcı hikâyesi denir ve kalıbı basittir: “[Kim] olarak [ne] yapmak istiyorum, çünkü [neden].” Birkaç örnek:

• Depo sorumlusu olarak malzeme çıkışını telefondan girmek istiyorum, çünkü gün sonunda kâğıttan aktarırken kayıt kaçıyor.
• Muhasebeci olarak teslim edilmiş ama faturalanmamış işleri görmek istiyorum, çünkü bunları şimdi tek tek arıyorum.
• Müşteri olarak siparişimin hangi aşamada olduğunu telefonla sormadan görmek istiyorum.

Bu cümleleri programı gerçekten kullanacak kişilerle birlikte yazın. Patronun tahmin ettiği ihtiyaç ile bankodaki çalışanın yaşadığı sorun çoğu zaman aynı değildir. “Neden” kısmını atlamayın: yazılımcı nedeni bilirse sizin aklınıza gelmeyen daha kısa bir yol önerebilir.

Toplantıların düzeni

Düzensiz ve uzun toplantılar da, hiç toplantı yapmamak da projeyi yavaşlatır. Baştan şu üç şeyi kararlaştırın:

1. Tek muhatap: İşletme tarafında kararları kimin vereceği belli olsun. Üç ayrı kişiden üç ayrı istek gelirse yazılımcı hangisini yapacağını bilemez.
2. Düzenli, kısa görüşme: Belirli aralıklarla, gündemi önceden belli bir değerlendirme. Ne bitti, ne denenmeye hazır, hangi soru yanıt bekliyor?
3. Yazılı özet: Her görüşmenin sonunda alınan kararlar birkaç satırla yazılsın ve iki taraf da görsün. Sözlü kalan karar, haftalar sonra farklı hatırlanır.

Yazılımcının aynı şehirde olması burada işe yarar: İskenderun’daki bir atölyede ya da depoda işin nasıl yürüdüğünü yerinde görmek, saatlerce anlatmaktan daha çabuk anlaşılır. Ama yakınlık, yazılı özetin yerini tutmaz.

Kod yazılmadan önce ekran taslağı

Ekran taslağı, programın hangi sayfalardan oluşacağını ve her sayfada ne yer alacağını gösteren basit bir çizimdir. Renk ve süs yoktur; amaç düzeni konuşmaktır. Taslak üzerinde bir düğmenin yerini değiştirmek dakikalar alır, yazılmış bir ekranı değiştirmek ise çok daha fazla emek ister. Taslakları incelerken kendinize şunu sorun: bugünkü en sık işimi bu ekranlarla baştan sona yapabilir miyim? Yapamıyorsanız eksik olan adımı şimdi söyleyin. Bazı yazılımcılar taslağı tıklanabilir bir örnek hâline de getirir; telefonda sayfalar arasında gezinip akışı denemek, kâğıt üzerindeki çizimden çok daha fazlasını anlatır. Taslağı bankodaki ya da sahadaki çalışana da gösterin; onun takıldığı yer, programın ilk zorlanacağı yerdir.

Deneme ortamı: gerçek işle sınayın

İyi kurulmuş projelerde program önce bir deneme ortamında çalışır. Bu, canlı sistemden ayrı, içine örnek ya da kopya veri girilebilen bir kopyadır; burada yapılan hata gerçek kayıtları bozmaz. Program parça parça teslim edildiğinde her parçayı burada sınarsınız. Sınarken “açıldı, güzel görünüyor” demek yetmez; geçen haftanın gerçek bir siparişini, gerçek bir müşterisini baştan sona programdan geçirin. Eksikler en çok bu sırada ortaya çıkar.

İşe yarayan geri bildirim

Her geri bildirimde üç bilgi olsun: ne yaptınız, ne bekliyordunuz, ne oldu. Bir ekran görüntüsü ya da kısa bir ekran kaydı çoğu zaman uzun bir açıklamadan daha çok şey anlatır. Geri bildirimleri dağınık mesajlar yerine tek bir listede toplayın ve her birinin durumunu (bekliyor, düzeltildi, denendi) işaretleyin.

Hata mı, yeni istek mi?

Yazılı kapsamda olup çalışmayan şey hatadır ve düzeltilmesi işin parçasıdır. Kapsamda hiç yer almayan, denerken aklınıza gelen şey ise yeni istektir. İkisi de meşrudur ama farklı ele alınır: yeni istek takvimi ve kapsamı etkiler, bu yüzden konuşulup yazıya geçirilir. Bu ayrımı baştan kabul eden işletme ile yazılımcı arasında “bu da olsaydı” tartışması çıkmaz. Her aşamanın sonunda o parçanın kabul edildiğini yazılı olarak belirtin; böylece neyin bitip neyin beklediği herkes için açık olur.

Program tamamlandığında kaynak kodun, sunucu erişiminin ve hesapların kimde kalacağını yazılım projesinde teslim ve sahiplik yazısında madde madde sıraladık. Çalışma sürecini İskenderun’da yüz yüze yürütmek isterseniz iş akışınızı özel yazılım sayfasındaki kapsamla karşılaştırın ve arayın.