Yazılım

İş akışını ekranlardan önce anlamak

Bir işin dijital karşılığını kurmadan önce o işin nasıl aktığını anlamak gerekir. Sahadan ofise kayıt taşıyan bir ekipte hangi bilginin nereden girildiği, kimin elinde beklediği ve hangi anda karara dönüştüğü çoğu zaman ekranlardan daha belirleyicidir. Bu yüzden özel yazılım çalışmasına arayüz çizerek değil, günlük işin gerçek sırasını dinleyerek başlarız.

Stok ile talep kaydını aynı yerde tutmaya çalışan ekiplerde en sık görülen sorun, aynı bilginin iki farklı deftere farklı biçimde yazılmasıdır. İş akışının önce kâğıt üzerinde netleşmesi, sonradan yapılacak onlarca küçük düzeltmenin önüne geçer. Böyle bir çözümleme, projenin başında verilmesi gereken en temel karardır.

Aynı kurumun farklı yerlerdeki birimleri çoğu zaman birbirinden habersiz alışkanlıklar edinir. Bu alışkanlıkların hangisinin ortak sisteme taşınacağına masabaşında değil, işin yürüdüğü yeri görerek karar veririz. Batman ve çevresindeki ekiplerle yaptığımız ilk görüşmelerde de öncelik, mevcut düzeni doğru okumaktır.

Kullanıcı rollerini yetkiye göre ayırmak

Herkesin her ekrana erişebildiği bir düzen ilk bakışta pratik görünse de zamanla kimin neyi değiştirdiğinin izini kaybettirir. Dağınık onay trafiğini azaltmak isteyen kurumlarda önce kimin hangi kaydı görmesi, kimin düzenlemesi gerektiğini birlikte konuşur; kullanım sıklığını ve yenileme temposunu bu konuşmanın içine katarız.

Yetki sınırlarını çizmek yalnızca teknik bir ayar değildir. Bir kullanıcının karşısına çıkan alanlar, onun işini ne kadar rahat yürüttüğünü doğrudan belirler. Fazla yetki kadar eksik yetki de günlük işi yavaşlatır; bu dengeyi ekibin gerçek görev dağılımına bakarak kurarız.

Kaydı elden ele geçen ekiplerde her rolün sınırının baştan tanımlı olması, sonradan çıkacak yetki karmaşasını büyük ölçüde engeller. Bu tanım, çalışmanın ilk aşamasında oturması gereken kararlardandır; sonraya bırakıldığında düzeltmesi hem uzun hem de yorucu olur.

Veri alanlarını ortak bir sözlükte toplamak

Aynı bilgiye bir birimin müşteri, diğerinin cari, bir başkasının firma demesi tek başına sorun değildir; asıl sorun bu adların ortak bir karşılığa bağlanmamış olmasıdır. Hangi alanın hangi anlamı taşıyacağına, birimlerin gerçekte nasıl kayıt tuttuğunu görmeden karar vermeyiz.

Ortak bir alan sözlüğü kurarken eldeki formları, tabloları ve alışılmış kısaltmaları bir araya getirir; hangisinin kalıcı olacağını kullanım sıklığına göre değerlendiririz. Amaç yeni bir dil dayatmak değil, hâlihazırda konuşulan dili tutarlı hâle getirmektir.

Alan adlarının tutarlı olması, raporların birbiriyle uyuşması ve arama yaparken doğru sonucun gelmesi demektir. Bu tutarlılık kaybolduğunda ekip veriye güvenmek yerine her seferinde elle kontrol etmeye başlar. Sözlüğü baştan sağlam kurmak, bu güveni korur.

Onay aşamalarını görünür kılmak

Bir talebin hangi aşamada olduğunu görmek için birini aramak zorunda kalınıyorsa süreç görünür değil demektir. Kaydı ortak sistemde tutan ekiplerde onay basamaklarının ekranda açıkça izlenebilmesini, özel yazılım tasarımının ilk aşamada oturtulması gereken kararlarından sayarız.

Onay sırasının nasıl işleyeceği kurumdan kuruma değişir; kiminde tek imza yeterken kiminde birkaç kademe devreye girer. Bu sıranın gerçek hâlini, işin yürüdüğü yerdeki uygulamayı görmeden tasarlamaya kalkmak sonradan bozulan bir akış üretir.

Onay adımlarını netleştirirken mevcut belgeleri, kimin neyi imzaladığını ve bu adımların ne sıklıkla tekrarlandığını birlikte inceleriz. Görünürlük arttıkça bekleyen işlerin nerede takıldığı da kendiliğinden ortaya çıkar; böylece darboğazlar tahminle değil kayıtla konuşulur.

Bildirimleri doğru sorumluya iletmek

Bir bildirimin herkese gitmesi, kimseye gitmemesi kadar etkisizdir; çünkü kısa sürede göz ardı edilmeye başlanır. Uyarının yalnızca o işten sorumlu kişiye ulaşması hem gereksiz dikkat dağınıklığını azaltır hem de işin sahibinin zamanında haberdar olmasını sağlar.

Kaydın elden ele dolaştığı yapılarda kimin ne zaman haberdar olacağı baştan tanımlanmazsa bildirimler ya birikir ya da kaybolur. Hangi olayın kimi tetikleyeceğini projenin başında belirlemek, sonradan eklenen yamalarla uğraşmaktan çok daha sağlıklıdır.

Uyarı kurallarının işe yaraması için o işi fiilen yürüten kişilerin hangi durumda neye ihtiyaç duyduğunu bilmek gerekir. Bunu ancak sahadaki karşılığını görerek kurgularız; yoksa herkesin bir süre sonra sustuğu bir uyarı yığını ortaya çıkar.

Saha kullanımını mobilde çözmek

Masabaşında rahat görünen bir ekran, sahada tek elle ve aceleyle kullanıldığında bambaşka davranır. Mobil tarafı ele alırken eldeki cihazları, bağlantının ne kadar güvenilir olduğunu ve ekranların gerçekten hangi koşulda açıldığını birlikte değerlendiririz.

Sahadaki bir kullanıcının en çok ihtiyaç duyduğu şey, birkaç dokunuşta kaydı tamamlayabilmektir. Gereksiz alanlarla dolu bir mobil akış işi kolaylaştırmak yerine geciktirir. Bu yüzden mobil tarafta öncelik, en sık yapılan işlemi en kısa yoldan bitirebilmektir.

Depoda ya da yolda kayıt giren ekiplerde mobil kullanımın nasıl çözüleceği sonradan eklenen bir özellik değil, baştan verilen bir karardır. Batman genelinde sahada çalışan birimlerle de önce en çok tekrarlanan işlemleri konuşur, arayüzü bunların etrafında sadeleştiririz.

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

Bir sistemin başka bir sistemle konuşması gerektiğinde asıl soru bağlantının kurulup kurulamayacağı değil, hangi verinin hangi yetkiyle geçeceğidir. Özel yazılım tarafında bu bağlantıları kurarken veri akışının sınırlarını ve kimin neye erişeceğini işin gerçek ihtiyacına göre belirleriz.

Dış bağlantıları tasarlarken hangi bilginin dışarı çıkacağını, hangisinin içeride kalacağını ve bu akışın ne sıklıkla tekrarlanacağını önceden konuşuruz. Bağlantının çalışması kadar bir aksama anında sistemin nasıl davranacağı da baştan planlanması gereken bir konudur.

Bir dış servisin yavaşlaması ya da yanıt vermemesi, kötü kurulmuş bir bağlantıda tüm işi durdurabilir. Bu yüzden bağlantıları hata anında ekibin işine devam edebileceği biçimde kurmayı; verinin güvenliğini de bu sürecin ayrılmaz parçası saymayı tercih ederiz.

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

Bir aksama yaşandığında yalnızca bir şeyler ters gitti demek yerine tam olarak neyin, nerede ve ne zaman olduğunu söyleyebilmek gerekir. Kaydı ortak tutan ekiplerde hata izlerinin okunabilir kalması, çözümü hızlandırdığı için baştan tanımlanması gereken kararlardandır.

Teknik olmayan bir kullanıcının karşısına çıkan hata metni onu korkutmak yerine ne yapması gerektiğini anlatmalıdır. Bu dengeyi mesajı gerçekte kimin okuyacağını bilerek kurarız; sahadaki kullanıcı ile arka taraftaki sorumlunun gördüğü kaydın ayrıntı düzeyi aynı olmak zorunda değildir.

Hata kayıtlarını düzenlerken hangi olayların not edileceğini, bu notların ne kadar süre saklanacağını ve kimin inceleyeceğini birlikte kararlaştırırız. İyi tutulmuş bir kayıt, aynı sorunun tekrarını önlemenin de en sağlam yoludur.

Oturum ve yetki güvenliğini desteklemek

Kullanıcının sisteme girişi ve orada kalabildiği süre güvenlik kadar günlük rahatlığı da ilgilendirir. Fazla sık kesilen bir oturum işi böler, hiç kapanmayan bir oturum ise riski büyütür. Bu ikisi arasındaki dengeyi ekibin çalışma ritmine bakarak kurarız.

Ortak kayıt tutan ekiplerde kimin nereden, hangi cihazla girdiğini takip edebilmek sonradan eklenecek bir önlem değil, baştan kurulması gereken bir zemindir. Batman’daki kurumlarla da yetki ve oturum kurallarını ilk kurulum görüşmesinde birlikte netleştiririz.

Yetki kurallarının işe yaraması, onları kullananların gündelik akışını zorlamamasına bağlıdır. Bu yüzden güvenlik önlemlerini soyut bir kalıp olarak değil, işin fiili yürüyüşünü görerek yerleştirir; her önlemin karşılığında ekibe ne kadar yük bindiğini de ölçeriz.

Yedekleme planını oluşturmak

Yedeklemeyi konuşmanın en kötü zamanı, veriyi kaybettikten sonrasıdır. Bir özel yazılım kurulurken hangi verinin, ne sıklıkla ve nereye yedekleneceğini baştan kararlaştırır; bu planı eldeki depolama imkânlarına ve verinin değişme hızına göre biçimlendiririz.

Bir yedeğin varlığı kadar gerektiğinde geri dönülebilmesi de önemlidir. Denenmemiş bir yedek çoğu zaman olmayan bir yedektir. Bu yüzden geri yükleme adımını da planın parçası sayar, kimin hangi durumda bu adımı işleteceğini önceden belirleriz.

Kaydı sürekli değişen ekiplerde yedekleme sıklığının işe göre ayarlanması gerekir; günde birkaç kez değişen bir veriyle ayda bir güncellenen bir veri aynı planla korunamaz. Bu ayrımı, verinin gerçek değişim temposunu görerek çalışmanın başında yaparız.

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

Çalışan bir sisteme yeni bir özellik eklerken asıl mesele, mevcut işleyişi bozmadan ilerleyebilmektir. Değişikliğin ne zaman ve kimin haberi olarak devreye alınacağını önceden konuşur; işi fiilen yürüten ekibin ritmini görmeden büyük bir güncellemeyi devreye almayız.

Bir güncellemeyi hazırlarken neyin değiştiğini, kimin bundan etkileneceğini ve bir sorun çıkarsa nasıl geri dönüleceğini birlikte kaydederiz. Kontrollü bir sürüm sürprizleri azaltır; ekip yeni hâle hazırlıksız yakalanmaz.

Sık ve küçük değişikliklerle ilerlemek, seyrek ama büyük güncellemelerden çoğu zaman daha güvenlidir; çünkü bir aksama olduğunda nedenini bulmak kolaylaşır. Hangi değişikliğin ne zaman verileceğini ekibin işini en az bölecek biçimde planlarız.

Eğitim ve teslim kayıtlarını oluşturmak

Bir sistemin gerçekten kullanılır olması, onu devralan ekibin ne yaptığını bilmesine bağlıdır. Teslim aşamasında hangi işlemin nasıl yürüdüğünü yazılı bir kayda bağlar; böylece özel yazılım ekip değişse bile aynı düzende çalışmayı sürdürür.

Eğitim, herkese aynı anda aynı şeyi anlatmak değil, her rolün kendi işini rahatça yapabilmesini sağlamaktır. Bu yüzden anlatımı o işi fiilen yürütecek kişinin günlük akışına göre düzenler; gereksiz ayrıntıyla değil, gerçekten kullanılacak adımlarla ilerleriz.

Devir sırasında dağınık notları toplar, kimin neyden sorumlu olduğunu ve bir sorun çıktığında kime başvurulacağını tek bir kayıtta netleştiririz. Böyle bir teslim, işin ilk günden sonra da kendi ayakları üzerinde durmasını sağlar.

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

Hazır bir paket, ihtiyacın standart olduğu yerde işi hızlıca görür; ayrım, işleyişin kalıba sığmadığı noktada başlar. Böyle bir çalışmada eldeki kaynaklar, kullanım sıklığı ve ekibin sorumluluğu birlikte tartılır, çözüm işin kendi akışına göre biçimlenir. Bu nedenle bir özel yazılım kararı, hazır seçenekler yetersiz kaldığında anlam kazanır.

Genellikle değildir; en çok işe yarayan çekirdeği önce ayağa kaldırmak hem geri bildirimi erken almayı hem de yanlış varsayımlarla büyük emek harcamamayı sağlar. Hangi özelliğin ilk turda gireceğine kullanım sıklığına ve ekibin önceliğine bakarak karar verilir. Sonraki adımlar, ilk sürümün gerçek kullanımından öğrenilenlerle şekillenir.

Çoğu durumda taşınabilir; ancak taşımadan önce eski kayıtların ne kadarının hâlâ kullanıldığı ve hangi biçimde tutulduğu incelenir. Kaynağın durumu, verinin miktarı ve sorumlu ekibin ayıracağı zaman birlikte değerlendirilerek bir aktarım yolu belirlenir. Amaç geçmişi olduğu gibi yığmak değil, işe yarayanı düzenli biçimde yeni yapıya almaktır.

Evet; yetkiler kalıcı bir kalıp değildir, ekip büyüdükçe ya da görevler değiştikçe yeniden düzenlenebilir. Yeni bir yetki tanımlandığında ilgili kullanım durumunda denenir, beklendiği gibi çalıştığı görüldükten sonra devreye alınır. Bu esneklik, düzenin zamanla işe ayak uydurmasını sağlar.

Hayır; mobil bir uygulamanın gerekli olup olmadığı işin nerede ve nasıl yürüdüğüne bağlıdır. İşlem çoğunlukla masabaşında yapılıyorsa tarayıcı üzerinden çalışan bir çözüm çoğu zaman yeterlidir. Sahada, hareket hâlinde kayıt giriliyorsa mobil taraf öne çıkar; bu karar ihtiyaç görülerek verilir, baştan dayatılmaz.

Bakım, çalışan bir düzenin sağlıklı kalmasını; yeni geliştirme ise o düzene daha önce olmayan bir yetenek eklemeyi anlatır. İkisini ayrı tutmak hangi işin sürekli, hangisinin talebe bağlı yürüdüğünü netleştirir. Bu ayrım baştan konuşulduğunda ekip neyin rutin, neyin ayrı bir çalışma olduğunu önceden bilir.