Yazılım

İş akışını ekranlardan önce çözmek

Bir işin dijitale taşınması, çoğu zaman ekran tasarımıyla değil, o işin kendi mantığını sökmekle başlar. Özel yazılım yaklaşımında önce kimin hangi kaydı ne zaman girdiğini, verinin elden ele nasıl geçtiğini izliyor; arayüzü ancak bu akış netleştikten sonra biçimlendiriyoruz. Böylece uygulama, ekibin gerçek gününe oturur, alışması istenen yapay bir düzene dönüşmez.

Stok ile talebi tek bir sistemde tutan ekiplerde, bir kaydın nereden doğduğu ve nereye ulaştığı çoğu aksamanın kaynağıdır. Bu nedenle çözümlemeyi kâğıt üstünde değil, çalışanın masasında yapıyor; hangi adımın elle, hangisinin kendiliğinden yürüdüğünü ayırıyoruz. Sonrasında yazılan her ekran, bu haritanın üzerine oturur.

Farklı yerlerde, farklı alışkanlıklarla çalışan birimler söz konusu olduğunda tek bir akış herkese uymaz. Bu yüzden ortak omurgayı korurken, istisnaları da baştan not ediyoruz. Sahadaki karşılığı görülmeden verilen bir akış kararı, çoğu zaman daha ilk haftada yeniden yazılmak zorunda kalır.

Kullanıcı rollerini net sınırlarla tanımlamak

Herkesin her şeyi görebildiği bir düzen, başta pratik görünse de zamanla karışıklığın kaynağı olur. Onay yollarını sadeleştirmek isteyen kurumlarda mevcut belgeleri ve günlük kullanım beklentisini birlikte masaya koyuyor; kimin neyi görmesi, kimin değiştirmesi gerektiğini tek tek konuşuyoruz. Yetki, sonradan eklenen bir katman değil, kurgunun kendi parçasıdır.

Bir kişinin ekranda ne görebileceği yalnızca teknik bir ayar değildir; onun işini ne kadar rahat yapacağını doğrudan belirler. Gereksiz alanları gizlediğimizde hem hata payı düşer hem de dikkat, gerçekten önemli olana yönelir. Rol tasarımını bu yüzden görsel bir ayrıntı gibi değil, iş güvenliğinin bir parçası gibi ele alıyoruz.

Kayıtların ortak bir sistemde toplandığı ekiplerde rollerin ilk günden tanımlı olması, ileride yaşanacak pek çok tartışmayı baştan keser. Bir depoyu yöneten ile raporu okuyan kişinin ihtiyacı aynı değildir; bunu Bayburt ölçeğindeki işletmelerde de sık gördük. Bu ayrımı erken netleştirmek, sonraki geliştirmeleri belirgin biçimde kolaylaştırır.

Veri alanlarını ortak bir sözlükte birleştirmek

Aynı bilgiye herkesin farklı isim vermesi, bir süre sonra raporların birbirini tutmamasına yol açar. Özel yazılım çalışmasında alan adlarını, birimlerini ve olası değerlerini ortak bir sözlükte topluyor; böylece müşteri, cari ya da firma gibi ayrı sözcüklerin tek bir kayda karşılık gelmesini sağlıyoruz. Tutarlılık, buradaki en sessiz ama en belirleyici kazanımdır.

Bu sözlüğü oluştururken eldeki formları, tabloları ve alışılmış terimleri birer birer inceliyoruz. Amaç kimseye yabancı gelen bir dil dayatmak değil; ekibin zaten kullandığı sözcükleri düzenli bir yapıya bağlamak. Böylece yeni bir kişi işe başladığında, alanların ne anlattığını tahmin etmek zorunda kalmaz.

Alanların ortak tanımı, ekranların ötesinde bir meseledir. Bir kayıt yanlış yerde, yanlış biçimde tutulduğunda sorun tek bir kişinin değil, o veriye dokunan herkesin işine yansır. Bu yüzden sözlüğü erken sabitliyor, sonradan yapılacak eklemeleri de bu düzenin içine yerleştiriyoruz.

Onay adımlarını görünür hale getirmek

Bir talebin hangi aşamada beklediği belli değilse, çoğu gecikme kimsenin fark etmediği bir köşede birikir. Onay adımlarını görünür kıldığımızda, bir işin kimde durduğu ve ne kadar beklediği bir bakışta anlaşılır. Bu görünürlük, insanları sıkıştırmak için değil, tıkanmayı erken görmek için vardır.

Onay yollarının sahadaki karşılığı, ofisteki varsayımdan çoğu zaman farklıdır. Bu yüzden akışı önce gerçek örneklerle deniyor; bir istisna çıktığında sistemin ne yaptığını izliyoruz. Yerinde görülmeden kurgulanan bir onay zinciri, ilk yoğun günde beklenmedik yerlerden kilitlenebilir.

Dağınık onayları azaltmak isteyen kurumlarda önce mevcut alışkanlığı anlıyor, sonra hangi adımın gerçekten gerekli olduğunu sorguluyoruz. Kimi onay, yıllar önce eklenmiş ve artık işlevini yitirmiş olabilir. Süreci sadeleştirmek çoğu zaman yeni bir şey eklemekten değil, gereksizi ayıklamaktan geçer.

Bildirimleri doğru sorumluya yöneltmek

Bir bildirimin doğru kişiye, doğru anda ulaşması küçük bir ayrıntı gibi görünür; oysa çoğu aksama tam bu noktada yaşanır. Özel yazılım içinde bildirimleri role ve göreve bağlıyor, herkese giden genel uyarılar yerine yalnızca ilgili kişiye ulaşan hatırlatmalar kuruyoruz. Böylece bildirim bir gürültü değil, işe yarayan bir işaret olur.

Kayıtları ortak sistemde tutan ekiplerde, bir işin sahibi netse bildirim de anlam kazanır. Kime gideceği belirsiz bir uyarı çoğu zaman hiç kimsenin üstlenmediği bir mesaja dönüşür. Bu yüzden sorumluluğu önce tanımlıyor, bildirimi ancak ondan sonra bu tanıma bağlıyoruz.

Sahada çalışan biri için bildirimin zamanlaması, içeriği kadar önemlidir. Geç gelen bir uyarı çoğu zaman hiç gelmemişle aynı sonucu doğurur. Bunu yerinde görmeden ayarlamak zordur; bu nedenle bildirim kurallarını gerçek kullanım temposuna göre ölçüyor, gerektiğinde sadeleştiriyoruz.

Saha kullanımını mobilde karşılamak

Masasında oturan biriyle depoda dolaşan birinin ihtiyacı aynı değildir. Mobil kullanımı ele alırken ekibin eldeki cihazlarını ve alışkanlıklarını birlikte değerlendiriyor; küçük ekranda hangi bilginin gerçekten gerektiğini ayıklıyoruz. Amaç masaüstündeki her şeyi küçültmek değil, sahadaki işi olduğu yerde bitirebilmektir.

Kayıtları saha ile ofis arasında taşıyan ekiplerde telefon çoğu zaman asıl çalışma aracıdır. Bir bilgiyi girmek için masaya dönmek gerekiyorsa, o kayıt ya geç girilir ya hiç girilmez. Bu yüzden mobil akışı bir ek özellik gibi değil, işin kendisinin bir parçası gibi tasarlıyoruz.

Sahadaki kullanımı yalnızca ekranda değil, gerçek koşulda deniyoruz; zayıf bağlantı, tek elle kullanım ve acele edilen anlar dahil. Bir kayıt en zor koşulda bile rahat giriliyorsa, sakin bir ofiste zaten sorun çıkarmaz. Mobil tarafı bu yüzden en baştan ciddiye alıyoruz.

Dış sistem bağlantılarını güvenle kurmak

Bir uygulama tek başına çalışmaz; çoğu zaman muhasebe, kargo ya da başka bir kayıt sistemiyle konuşması gerekir. Özel yazılım geliştirirken bu bağlantıları baştan planlıyor, hangi verinin hangi yönde aktığını ve bir tarafta hata olduğunda ne olacağını önceden tanımlıyoruz. Güvenli bağlantı, sonradan eklenen değil, tasarımın içine dokunan bir karardır.

Bağlantıları kurarken önce eldeki sistemleri ve onların sınırlarını inceliyoruz. Her servis aynı hızda ya da aynı güvenle yanıt vermez; bunu bilmeden kurulan bir köprü en kritik anda çöker. Bu yüzden bağlantının koptuğu durumda verinin kaybolmayacağı bir yolu da baştan hazırlıyoruz.

Dış bir sistemle veri paylaşmak, aynı zamanda bir sorumluluk paylaşmaktır. Hangi bilginin dışarı çıktığını ve kimin eriştiğini açıkça tanımlamadan kurulan bağlantı, ileride izi sürülemeyen sorunlara yol açar. Bu ayrımı erken netleştirmek hem güvenliği hem de günlük işi rahatlatır.

Hata kayıtlarını anlaşılır tutmak

Bir şey ters gittiğinde asıl mesele, ne olduğunu anlaşılır biçimde görebilmektir. Kayıtları ortak sistemde tutan ekiplerde hata mesajlarını teknik bir kalabalık olmaktan çıkarıyor; ne zaman, nerede ve hangi işlemde çıktığını sade bir dille yazıyoruz. Böylece sorun, tahminle değil, kayda bakılarak çözülür.

Hataların sahadaki görünümü, ekrandaki halinden farklı olabilir. Bu yüzden mesajları yerinde deniyor; bir kişinin o an ne yapması gerektiğini anlayıp anlamadığını izliyoruz. Anlaşılmayan bir uyarı, olmayan bir uyarıdan çoğu zaman daha zararlıdır.

Onay ve düzeltme süreçlerini sadeleştirmek isteyen kurumlarda hata kayıtlarını da bu düzenin parçası sayıyoruz. Bir sorunun ne sıklıkla tekrarlandığını görmek, çoğu zaman kalıcı çözümün ilk adımıdır. Bu yüzden hataları yalnızca gidermekle kalmıyor, tekrarını izlenebilir kılıyoruz.

Oturum ve yetki güvenliğini sağlamak

Kimin sisteme girdiği ve orada ne yapabildiği, güvenliğin en somut tarafıdır. Özel yazılım tarafında oturumların süresini, yetki sınırlarını ve olağandışı erişimlerde ne olacağını önceden konuşuyoruz. Amaç, kullanımı zorlaştırmadan bir hesabın kendi yetkisinin ötesine geçmesini baştan güçleştirmektir.

Kayıtları ortak sistemde tutan ekiplerde yetki, bir kişinin işini kolaylaştırdığı kadar başkasının verisini de korur. Bu yüzden yetkiyi tek bir düğme gibi değil, işin doğasına göre katmanlanmış bir yapı gibi kuruyoruz. Bir çalışanın görevi değiştiğinde, erişimi de zahmetsizce buna uyar.

Güvenliğin sahadaki karşılığı, ofisteki teoriden ayrı düşünülemez. Mobil girişte, ortak cihazlarda ya da acele edilen anlarda oturum yönetiminin nasıl davrandığını yerinde deniyoruz. Kâğıt üstünde sağlam görünen bir kural, gerçek kullanımda pürüz çıkarıyorsa yeniden ele alınır.

Yedekleme planını baştan kurmak

Bir verinin değeri çoğu zaman kaybedildiği gün anlaşılır. Yedekleme planını kurarken hangi kaydın ne sıklıkla, nereye kopyalanacağını ve geri dönüşün nasıl yapılacağını önceden tanımlıyoruz. Düzenli işleyen bir yedek, görünmez bir emniyet gibidir; varlığı ancak gerektiğinde hissedilir.

Yedeklemede asıl soru, kopyanın alınıp alınmadığı değil, gerektiğinde geri yüklenip yüklenemeyeceğidir. Bu yüzden planı yalnızca yazmıyor, geri dönüşü deneyerek doğruluyoruz. Verinin kaynağını, saklandığı yeri ve ona kimin dokunabileceğini ilk kurulumda birlikte kararlaştırıyoruz.

Kayıtları ortak sistemde tutan ekiplerde yedekleme, tek bir kişinin değil, kurumun sorumluluğudur. Bu yüzden planı belirli bir kişiye değil, tanımlı bir göreve bağlıyoruz. Böylece o kişi işten ayrılsa bile, verinin güvenliği bir boşluğa düşmez.

Sürüm değişikliklerini kontrollü yürütmek

Yeni bir özellik eklerken asıl risk, çalışan bir düzeni farkında olmadan bozmaktır. Değişiklikleri önce ayrı bir ortamda deniyor, ancak sorunsuz göründükten sonra kullanıma alıyoruz; bu yöntemi Bayburt’taki ekiplerle yürüttüğümüz işlerde de temel alıyoruz. Kontrollü ilerlemek hızdan değil, huzurdan yana bir tercihtir.

Onay ve güncelleme temposunu sadeleştirmek isteyen kurumlarda her sürümün neyi değiştirdiğini yazılı tutuyoruz. Bir aksama olduğunda hangi değişikliğin sebep olduğunu bilmek, çözümü saatler yerine dakikalara indirir. Bu yüzden her adımın geri alınabilir olmasına baştan özen gösteriyoruz.

Bir güncellemenin sahadaki etkisi, ofiste görülenden farklı olabilir. Bu yüzden değişikliği önce sınırlı bir grupta izliyor, sonra genele açıyoruz. Kimin neyi ne zaman güncelleyeceğini tanımlamak, sürüm yönetimini tahminden çıkarıp izlenebilir bir düzene bağlar.

Eğitim ve teslim sürecini kayda bağlamak

Bir uygulamanın gerçek başarısı, teslim edildiği gün değil, ekibin onu rahatça kullanmaya başladığı gün ölçülür. Bu yüzden eğitimi ve devri baştan planlıyor; kimin neyi öğrendiğini ve hangi adımın kime bırakıldığını kayda geçiriyoruz. Böylece bilgi, tek bir kişinin belleğinde değil, kurumun düzeninde kalır.

Devir sırasında en çok unutulan şey, günlük kullanımın küçük ayrıntılarıdır. Bunları sahada, gerçek işlerle göstererek aktarıyor; anlaşılmayan noktayı orada gideriyoruz. Yerinde yapılmayan bir teslim, çoğu zaman haftalar sonra aynı soruların yeniden sorulmasıyla sonuçlanır.

Dağınık bilgileri tek bir düzene bağlamak isteyen kurumlarda eğitim kayıtları da bu düzenin parçasıdır. Kimin neyi bildiğini yazılı tutmak, yeni bir kişi katıldığında işi sıfırdan anlatma yükünü ortadan kaldırır. Teslim, böylece bir bitiş değil, sürdürülebilir bir başlangıç olur.

Yazılım Hakkında Sık Sorulan Sorular

Ayrım, çoğunlukla işin kendine özgü kurallarında başlar. Hazır bir paket genel ihtiyaçlar için tasarlanır; sizin için geliştirilen bir çözüm ise sizin akışınıza, terimlerinize ve onay yollarınıza göre biçimlenir. Eldeki kaynakları, kullanım sıklığını ve ekipteki sorumluları birlikte değerlendirerek hangi yolun daha yerinde olduğuna karar veriyoruz.

Genellikle şart değildir. İlk sürümde en çok kullanılan ve en çok değer üreten adımları öne alıyor, gerisini kullanım geri bildirimine göre sıralıyoruz. Böylece ekip sistemi erken tanır, geliştirme de gerçek ihtiyaca göre yön bulur. Kapsamı baştan kilitlemek yerine, adım adım büyümeyi tercih ediyoruz.

Çoğu durumda aktarılabilir. Önce eski kayıtların hangi biçimde tutulduğuna bakıyor, tutarlı olanları yeni yapıya uyarlıyoruz. Eksik ya da çelişkili veriler varsa bunları aktarım öncesinde birlikte ayıklıyoruz. Amaç, geçmişi kaybetmeden temiz bir başlangıç kurmaktır.

Evet, yetkiler zamanla değişebilir. Bir çalışanın görevi değiştiğinde ya da ekip büyüdüğünde erişim düzeyleri buna göre güncellenebilir. Bunu baştan esnek kurduğumuz için, sonradan yapılan bir değişiklik yeni bir geliştirme gerektirmez; tanımlı yapı üzerinden yürür.

Her zaman gerekmez. Kimi iş yalnızca masaüstünde rahatça yürürken, saha ağırlıklı işlerde mobil kullanım öne çıkar. Kararı, işin nerede ve nasıl yapıldığına bakarak veriyoruz; gereksiz bir mobil katman hem maliyeti hem bakım yükünü boşuna artırır.

Bakım, çalışan bir düzenin sürmesini sağlar; yeni geliştirme ise sisteme daha önce olmayan bir yetenek ekler. İkisini baştan ayırıyor, hangi işin hangi başlık altında yürüdüğünü açıkça tanımlıyoruz. Böylece günlük destek ile yeni taleplerin planı birbirine karışmaz, ikisi de kendi temposunda ilerler.