Yazılım

Farklı Birimlere Yayılan Adımları Tek Bir Kayıt Altında Toplayalım

Bir sipariş talebi çoğu zaman satışta doğar, ardından sevkiyat ya da muhasebe tarafında sürer. Bu adımlar ayrı ayrı yazışmalarda kaldığında işin o an hangi noktada olduğu kolayca kaybolur. Hazırlayacağımız yazılım çalışması bu kopuklukları önce yerinde dinleyerek anlar; ilgili çalışanların ortak kayda hangi anda ne ekleyeceğini sizinle beraber kurgularız.

İşletmenize özel bir uygulamaya başlamadan önce sürecin gerçekte kaç adımdan oluştuğunu birlikte çıkarırız. Sözgelimi bir değişim başvurusunda müşterinin ilk bildirimi, ürünün elinize ulaşması ve sizin incelemeniz birbirinden ayrı aşamalardır. Hepsini tek bir durum gibi görmek, ekibin elindeki bilgi tamamlanmadan işlem yapmasına neden olabilir.

İncelemeye halihazırda kullandığınız araçları da katıyoruz. Her ihtiyacın mutlaka sıfırdan bir uygulama yazılmasını gerektirdiğini düşünmüyoruz. Elinizdeki hazır çözümün nerede yetersiz kaldığı ve kendinize özgü iş kurallarınız tartıldıktan sonra doğru yöntemi seçmek mümkün olur; hedefimiz işinizi izlemek için yeni bir karmaşa değil, kolay anlaşılır bir çalışma düzenidir.

  • Birimden birime geçen işin nerede olduğunu görme
  • Ortak kayıtta toplanacak bilgilerin seçimi
  • Kullanılan araçların sunduğu imkânların ölçülmesi
  • Gerçek gereksinime göre kurulan geliştirme yolu

Talep Açılırken Elimizde Hangi Bilginin Bulunması Gerektiğini Saptayalım

Bir kaydın açılabilmesi için mutlaka gereken bilgilerle sonradan eklenebilecek ayrıntıları ayrı tutmakta yarar var. Kullanıcıdan işin başında gereksiz alanlar istemek süreci ağırlaştırabilir. Öte yandan temel bağlantı bilgisi hiç yoksa talep doğru müşteriyle, ürünle veya işlemle örtüştürülemez. Alanları tam bu denge gözetilerek seçeriz.

Gereksinimleri belirlerken örnek bir kaydı en baştan sonuna kadar birlikte izleriz. Bir iade başvurusunda sipariş bağlantısı, ürün seçimi ve gerekçe açıklaması gerekebilir; ancak ölçü her zaman sizin gerçek işleyişinizdir. Tek bir formu bütün durumlara dayatmak yerine, bu yazılım projesinde hangi bilginin hangi kararı beslediğini sorarız.

Aranan bilgi başka bir sistemde zaten duruyorsa yeniden elle girilmesi gerekmeyebilir; böyle bir bağlantı olanağını ayrıca değerlendiririz. Eksik kalan kaydın, hatalı eşleşmenin ya da düzeltilmesi gereken açıklamanın nasıl karşılanacağı da bu adımda konuşulur. Böylece uygulama yalnızca kusursuz örneklere göre değil, günün gerçeğine göre çalışır.

  • Başlangıçta zorunlu olan alanların ayrılması
  • Her bilginin hangi kararı desteklediğinin belirtilmesi
  • Var olan veriyle kurulacak bağ ihtiyacı
  • Eksik ya da hatalı kayıtta izlenecek yolun tanımı

İşin Durumu Herkeste Tek Bir Anlama Gelsin

“Tamamlandı” gibi tek kelimelik bir durum, farklı ekiplerin gözünde başka başka şeyler ifade edebilir. Biri ürünün teslim alındığını düşünürken diğeri incelemenin tümüyle bittiğini varsayar. Durum adlarını sizin süreç dilinizle tarifleyerek her aşamanın tam olarak ne zaman başladığını ve neyi anlattığını açık hale getiririz.

Süreç hazırlanırken bir aşamadan diğerine hangi koşulda geçileceğini de belirleriz. Ürün henüz elinize ulaşmadan incelemenin açılıp açılamayacağı ya da ek bilgi bekleyen bir kaydın kimin üzerinde kalacağı gibi kararları beraber konuşuruz. Bunlar ekranın kendiliğinden üreteceği kurallar değil, sizin çalışma biçiminizle onaylanması gereken seçimlerdir.

Geri alınan bir karar ya da yeniden açılan bir talep, daha önce girilmiş bilgiyi etkileyebilir. Önceki durumun nasıl saklanacağını ve yapılan değişikliği kimlerin göreceğini önceden anlatırız. Kaydın geçmişine ihtiyaç varsa bunu kapsama yazarız; durum alanını yalnızca renkli bir etiket gibi değil, işin gerçek takibini taşıyan bir bilgi olarak ele alırız.

  • Ortak anlam taşıyan işlem durumları
  • İşletmeyle onaylanan geçiş koşulları
  • Yeniden açılan kayıtta bilgi bağının korunması
  • Takibe uygun biçimde tutulan durum geçmişi

Beklenmedik Durumları ve Boş Kalan Alanları Süreç İçinde Çözelim

Her talep bütün alanları eksiksiz doldurulmuş biçimde gelmez. Yanlış ürünün seçilmesi, açıklamanın boş bırakılması ya da tek başvuruda birden çok kaydın toplanması günlük kullanımda sık rastlanan örneklerdir. Bu kayıtların kime yönlendirileceğini ve hangi bilgi tamamlanmadan ilerlemenin durdurulacağını süreç planına yazarız. Aynı başvurudaki ürünler ayrı sonuçlara bağlanabiliyorsa, tüm talebe tek bir durum atamak çoğu zaman yetmez. Kayıt ile alt kalem arasındaki ilişkiyi bu örnek üstünden inceleyip kararın hangi düzeyde tutulacağını belirleriz.

İş kurallarını tasarlarken kendiliğinden uygulanabilecek denetimlerle, yetkili bir kişinin karar vermesi gereken durumları birbirinden ayırırız. Aynı talebin bir kez daha açılması gibi bir durumda sistemin ne göstereceğini önceden kararlaştırırız. Bu yazılım tasarımında amacımız gereksiz engel çıkarmadan hatalı işlemi durduran ve kullanıcıya yön veren davranışlar hazırlamaktır.

İşletmenizde istisnai bir onay yetkisi varsa bunun kimin elinde olduğu belirgin olmalıdır. Uygulamanın her koşulda aynı sonucu vermesi gerekmez; fakat farklı bir sonucun hangi kurala dayandığı okunabilir kalmalıdır. Sınama senaryolarını kurarken bu istisnaları da olağan akış kadar titizlikle ele alırız.

  • Eksik bilgiyle ulaşan kayıtların karşılanması
  • Otomatik denetimle insan kararının ayrılması
  • Yinelenen başvurular için tanımlanan davranış
  • Yetkilisi belirli istisna değerlendirmeleri

Kullanıcı Erişimlerini Görevlerle ve Bilgi İhtiyacıyla Eşleyelim

Bir birim kaydın tümünü görmeye gerek duyarken bir başkası yalnızca kendi payına düşen işlemi bitirir. Hangi bilginin kim tarafından görülüp değiştirileceğini sizinle beraber saptarız. Kullanıcı rollerini sadece yönetici ve çalışan diye ikiye bölmek her işletmenin gerçeğine uymayabilir; bu yüzden ayrımı işin kendisine göre kurarız.

Yetkilendirme içinde kayıt düzeyindeki erişimleri de gözden geçiririz. Görme hakkı olan bir kişinin bütün alanları değiştirebilmesi şart değildir. İzinleri yalnızca ekrandaki düğmelere değil, uygulamanın işlem kurallarına da yansıtırız; bir bağlantıyı gözden gizlemek tek başına bir erişim denetimi sayılmaz.

Personel değiştiğinde ya da geçici görevlendirmelerde erişimin nasıl yenileneceğini konuşuruz. Hesapların sorumluluğunu işletim planında açıkça belirtiriz. Hangi işlemin kim tarafından yapıldığını izlemek istiyorsanız, ortak hesap kullanmanın buna etkisini değerlendiririz; ihtiyaç duyduğunuz takip bilgilerini kapsam doğrultusunda hazırlarız.

  • Göreve göre belirlenen kullanıcı grupları
  • Görme ve değiştirme haklarının ayrılması
  • Erişim sınırlarının işlem kurallarına uydurulması
  • Hesap yönetiminde belirlenen sorumluluklar

Sıradaki İş Ekranlarda Kolayca Görünsün

Çalışanın bütün kayıtlar arasında kendi bekleyen işini araması vakit kaybettirir. Uygulamanın ana ekranlarını kullanıcıların gün boyunca yürüttüğü görevlere göre düzenleriz. Değerlendirmeyi bekleyen, ek bilgi isteyen ya da sonuçlandırılacak talepler uygun bir süzgeç ve liste biçimiyle karşınıza gelebilir.

Ekranı kurgularken kaydın durumu, açıklaması ve üzerindeki eylem düğmeleri için bir görme sırası belirleriz. Kullanıcı bir kaydı açar açmaz neyi gözden geçireceğini, ardından ne yapacağını zorlanmadan seçebilmelidir. Bu yazılım geliştirmesinde kaydetme, iptal etme ve önceki adıma dönme hareketlerini de ekranın bütünüyle birlikte düşünürüz.

Uzun açıklamaları, boş bırakılmış alanları ve kalabalık listeleri temsili verilerle sınarız. Telefon veya tabletten kullanım gerekiyorsa aynı görevleri dar ekranda yeniden gözden geçiririz. Arayüzün yalnızca birkaç derli toplu örnekte çalışması bize yeterli gelmez; günlük kullanımın değişen yoğunluğunu kaldıracak bir düzeni hedefleriz.

  • Bekleyen görevleri öne alan ekran düzeni
  • Durumla eylem arasında belirgin öncelik
  • Kaydetme ile geri dönüşün birlikte kurgulanması
  • Gerçek veri yoğunluğuyla yapılan görünüm sınaması

Fotoğraf ve Ekler İlgili İşlemin Hemen Yanında Dursun

Bir talebe ait fotoğraf ya da açıklayıcı bir belge ayrı yazışmalarda kaldığında sonradan bulunması güçleşir. Eklerin hangi kayda bağlanacağını ve bunlara kimlerin ulaşabileceğini belirleriz. Dosya adının yanında yükleme amacı ya da kısa bir not gibi bilgiler gerekiyorsa, bunları içerik yapısına ekleyebiliriz.

Dosya yüklemesinde boyut sınırlarını ve uygun olmayan içerikte gösterilecek uyarıları önceden düşünürüz. Kullanıcı yüklemenin tamamlanıp tamamlanmadığını görebilmelidir. Bir ekin sonradan değiştirilmesi incelemeyi etkiliyorsa, bununla ilgili durumu ve yetkili kişinin denetim ihtiyacını ayrıca tanımlarız.

Görsellerin gözden geçirildiği bir süreçte önizleme ya da indirme ihtiyacı doğabilir; bunun hangi kullanıcıya açık olacağını belirleriz. Verinin saklanması ve işletilmesiyle ilgili sorumlulukları teknik teslimden ayrı düşünmeyiz. Kapsama giren dosya yönetiminin günlük kullanımda nasıl sürdürüleceğini de açıkça anlatırız.

  • Talep kaydıyla ilişkilendirilen dosyalar
  • Yükleme sonucunu bildiren anlaşılır uyarılar
  • Değişen ekte yeniden inceleme ihtiyacı
  • Yetkiye göre açılan önizleme ve indirme

Uyarıların Kime Gideceğini ve Sistem Bağlarını Sürece Göre Kuralım

Bir işlemde bir şey değiştiğinde herkesin bundan haberdar olmasına gerek yoktur. Hangi olayın kimi harekete geçirdiğini öğrenip bildirimleri ona göre kurgularız. Kullanıcıya giden mesajın yalnızca bilgi mi verdiği yoksa ondan bir işlem mi beklediği ilk bakışta anlaşılmalıdır.

Bir bağlantı gerektiğinde sipariş, gönderi ya da müşteri kaydının tutulduğu sistemin neye izin verdiğini inceleriz. İstenen alanların okunması ile değişikliklerin karşıya yazılması çoğu zaman ayrı izinler ister. Teknik olarak doğrulanmamış bir yazılım bağını hazır bir özellik gibi sunmayız; kapsamı desteklenen işlemlere göre çizeriz. Yalnızca okuma izni olan bir bağın diğer sistemde durum değiştireceği baştan varsayılmaz. Talep edilen işlemleri tek tek ele alır, gerekli izin ve teknik destek onaylandıktan sonra uygulanabilir akışı anlatırız.

Karşıdaki sistem geçici olarak yanıt vermediğinde uygulamanın nasıl davranacağı tanımlı olmalıdır. Eski bilginin gösterilmesi, yeniden deneme ya da ilgili sorumluya haber verilmesi gibi seçenekleri işin ihtiyacına göre değerlendiririz. Aktarımın yönü ve asıl kayıt kaynağı belli olduğunda, iki sistemde birbiriyle çelişen güncellemeleri denetlemek kolaylaşır.

  • Olayla bağlantılı bildirim alıcıları
  • Mesajın amacını anlatan içerikler
  • Teknik imkânı doğrulanmış sistem bağlantısı
  • Kesinti ve yeniden deneme davranışının planı

Var Olan Kayıtların Taşınmasını Başlı Başına Bir İş Sayalım

Eski tablolarınız ve kullandığınız araçlar yeni uygulamaya taşınacak bilgi barındırabilir. Ne var ki farklı yazımlar, kopuk ilişkiler ya da yinelenen kayıtlar doğrudan taşımayı zorlaştırır. Örnek veri üstünde çalışarak hangi alanların temizlenmesi ve hangilerinin sizin tarafınızdan açıklanması gerektiğini saptarız.

Veri taşımada yalnızca kaç kaydın geçtiğini saymak yeterli olmaz. Bir talebin doğru müşteriyle ya da işlemle örtüşmesi ve ona bağlı eklerin yerinde olması gibi ilişkileri de inceleriz. Küçük bir örnek taşımanın sonucunu birlikte değerlendirir, daha büyük veri için izlenecek yöntemi ve denetim sorumluluğunu açıklarız.

Geçiş sürerken eski sistemde işlem yapmaya devam ediyorsanız, o sırada oluşan yeni verinin sisteme nasıl dahil edileceğini de konuşuruz. Kullanıcıların hangi günden itibaren hangi araca geçeceğini netleştiririz. Kayıtların aktarılmasını basit bir içe alma komutu gibi görmek yerine, işletmenizin gündelik işleyişini etkileyen bir hazırlık aşaması olarak ele alırız.

  • Taşıma öncesi incelenen örnek veriler
  • Temizlenmesi gereken kayıtların saptanması
  • Doğru ilişkilerle denetlenen taşıma
  • Bir araçtan diğerine sorunsuz aktarım sırası

Raporları Yönetimin Sorduğu Sorulara Göre Kuralım

Ekrana gösterge koymadan önce o rakamın hangi kararı kolaylaştıracağını sorarız; amacı belirsiz bir tablo kalabalıktan başka bir şey vermez. Yönetimin biriken yükü mü yoksa biten işlerin hızını mı görmek istediğini konuşarak başlarız. Her özeti kaydın kendisine dayandırır, anlamı ilk bakışta anlaşılan sade bir görünüm kurarız.

Raporlamada durum ve tarih tanımları belirleyicidir. Bir talebin açıldığı gün ile incelemesinin bittiği gün farklı sorulara yanıt verir. İyi kurulmuş bir yazılım raporlamasında hangi tarihe göre gruplama yapılacağını ve iptal edilen kayıtların nasıl sayılacağını sizinle belirleriz; rapor hesabını bir varsayıma dayandırmayız.

Gerektiğinde özetten ayrıntıya inmeyi ya da veriyi dosya olarak dışarı almayı planlarız. Erişim sınırları bu alanlarda da geçerli kalmalıdır. Denetim için örnek kayıtların beklenen sonucunu önceden hesaplar, ekranın bunu doğru yansıttığını inceleriz; göze düzenli görünen bir tablo tek başına verinin doğru olduğunu göstermez.

  • Karar ihtiyacından türetilen rapor alanları
  • Anlamı belirlenmiş tarih ve durum ölçütleri
  • Yetkiyle sınırlanan veri incelemesi
  • Örnek kayıtlarla doğrulanmış rapor sonuçları

Kabul Denetiminde Olağan Akışı ve Hataları Birlikte Sınayalım

İşin hangi noktada tamamlanmış sayılacağını daha en başta birlikte yazıya dökeriz. Sözgelimi bir başvurunun kaydedilip ilgili ekibe düşmesi ve orada sonuca ulaşması, üzerinde anlaştığımız bir kontrol adımı olabilir. Beklediğimiz sonuçları not ettiğimiz için kabul kararı ilk izlenime değil, denenen bu adımlara dayanır.

Denemelerimiz her şeyin yolunda gittiği durumla sınırlı kalmaz; biri hatalı bilgi girdiğinde, yetkisiz biri işleme kalkıştığında ya da aynı adım iki kez yinelendiğinde sistemin ne yaptığına da bakarız. Senaryoyu ayrı bölümlerden kişilerin denemesi, akıştaki boşlukları erken görünür kılar. Neyin beklendiği baştan belliyse, çıkan aksaklık bize somut iletilir.

Yeni bir işlev isteği ile üzerinde anlaşılan bir işin beklendiği gibi yürümemesi bizim için iki apayrı başlıktır. Bu ikisini ayrı tutmak, teslime kadar mutlaka bitmesi gereken işleri gözden kaçırmamayı sağlar. Bize ulaşan her not yazılı durduğu için; kapanmış konular, bir kez daha ele alınacak yerler ve ileriye bıraktığımız eklemeler birbirine karışmaz.

  • Önceden tanımlanan kabul senaryoları
  • Hatalı giriş ve yetki sınırı denemeleri
  • Gerçek kullanıcılarla yürütülen işleyiş kontrolü
  • Öneriden ayrı tutulan hata onarımları

Teslimden Sonra Uygulamayı Kimin İşleteceği Netleşsin

Sistem canlıya geçtiğinde işletmeyle ilgili günlük sorumluluklar kendiliğinden ortadan kalkmaz. Sunucunun barındırılması, hesapların yönetimi, verinin yedeklenmesi ve varsa dış servisler için kimin ne yapacağı önceden paylaştırılır. Bu işlerden hangisinin bizde, hangisinin sizde olduğunu baştan yazarak sistemin sürekliliğinde soru işareti bırakmayız.

Sunduğumuz yazılım hizmetinde ilk kapsam, teslim biçimi ve sonrasındaki destek ayrı ayrı tanımlanır. Yeni bir işlev isteği mevcut yapıyı etkileyebilir; uygulamadan önce bu etkinin ölçülmesi gerekir. Sabit ve sınırsız gelişim sözleri yerine, yapılacak işi ve denetim yöntemini konu alan anlaşılır bir süreç kurarız.

Başlamak için çoğu zaman elinizdeki dağınık bir takip tablosunu ya da ekibinizi en çok uğraştıran işi bize aktarmanız yeter. Oturup o akışı adım adım konuşalım; hangi ekranların gerekeceğini, kayıtlar arasında nasıl bir bağ kurulacağını ve işin kurallarını beraberce ortaya çıkaralım. Böylece uygulamayı soyut bir dökümana sıkıştırmadan, masanızda gerçekten sonuçlanması gereken işlere göre kuralım.

  • İşletim için belirlenen görev paylaşımı
  • Teslimden ayrılan destek kapsamının tanımı
  • Yeni taleplerin etkisini ölçme yöntemi
  • Somut işlerden yola çıkan geliştirme yol haritası

Yazılım Projesine İlk Adımdan Önce

İlk görüşmede elinizde ayrıntılı bir teknik belgenin bulunması gerekmez. İzlemekte zorlandığınız süreci, kullandığınız araçları ve ulaşmak istediğiniz sonucu anlatmanız yeterlidir. Örnek bir işlem üzerinden gereken kullanıcılar, bilgiler ve kararlar çıkarılır. Teknik kapsam bu incelemenin ardından hazırlanır; henüz netleşmemiş bir ihtiyaç için size doğrudan bir ekran ya da özellik listesi dayatılmaz.

Yanıtı, bağlanmak istediğiniz sistemin dışarıya hangi kapıları açtığına ve size ne kadar izin verdiğine göre veririz. İşin başında hangi bilginin hangi yöne akacağını ve bir kaydın aslının nerede tutulduğunu belirlememiz gerekir. Teknik karşılığını görmeden her isteğe söz vermeyiz. Küçük bir örnek veriyle bağın nasıl çalıştığını ve aksama halinde ne olacağını görür, ancak sonra kapsamı bağlarız.

Çalışma düzeniniz bunu gerektiriyorsa tek bir kayıt, her rolün yalnızca kendini ilgilendiren alanları görecek biçimde açılabilir. Hangi ekibin neyi göreceği ve hangi işlemi üstleneceği ayrı ayrı belirlenir. Bir aşamanın adının bütün bölümlerde aynı şeyi karşılaması önem taşır. Kayıt bir gruptan diğerine aktarıldığında ne beklendiğini ve haberin nasıl verileceğini süreçle beraber tasarlarız.

Buna kesin yanıt vermeden önce hem dosyaları hem de aralarındaki bağları görmemiz gerekir. Boş ya da tutarsız satırlar elden geçmek isteyebilir; kimi bilgi yeni düzene olduğu gibi yerleşmez. Bu yüzden geçişi önce küçük bir kümeyle deneriz; alanların hangi karşılığa oturduğunu sınarız. Nelerin aynen kalacağı, nelerin baştan düzenleneceği ve hangi adımdan kimin sorumlu olduğu bu denemenin sonunda belli olur.

Eğitimin neleri kapsayacağı daha ilk aşamada belirlenir. Gündelik işlerin gerçek örnekler üzerinde canlandırılması, çalışanların uygulamayı kendi görevleriyle eşleştirmesini kolaylaştırır. Yöneticinin yürüteceği işlemlerle diğer kullanıcıların adımları birbirinden ayrı gösterilir. Bir aksaklıkla karşılaşıldığında bunun kime, nasıl iletileceği de anlatılır; böylece teslim tek bir giriş adresinin elden çıkarılmasıyla bitmiş sayılmaz.

Yeni ihtiyacın mevcut verilere, yetkilere ve ekranlara nasıl etki edeceği değerlendirilir. Bazı değişiklikler ayar düzeyinde karşılanabilir, bazıları ise geliştirme ister. Kapsam ve doğrulanacak senaryolar ortaya konmadan sınırsız ekleme sözü verilmez. Bildiğiniz büyüme planlarını başta paylaşmanız, uygun bir temel yapının seçilmesine yardımcı olur; sonraki işler ayrıca değerlendirilip uygulanır.