Yazılım
- Anasayfa
- Yazılım
Yazılım İhtiyacını Ekibinizin Gün İçinde Tuttuğu Kayıtlardan Okuyoruz
Bir işletmede yeni bir sisteme ihtiyaç olduğunu gösteren ilk işaret, genellikle masaların üzerinde birikmiş defterler, birbirini tutmayan tablolar ve mesajlaşma gruplarında kaybolan notlardır. Özel yazılım geliştirme sürecine bu kayıtları inceleyerek giriyoruz. Ekibinizdeki kişilerden, bir günü nasıl geçirdiklerini, hangi bilgiyi nereye yazdıklarını ve hangi işi her gün elle tekrarladıklarını anlatmalarını istiyoruz. Mümkünse bir iş gününü yerinde izliyoruz; masa başında anlatılan süreçle sahada yaşanan süreç arasında çoğu zaman küçük ama önemli farklar olur. Hakkâri’de faaliyet gösteren bir işletmenin ihtiyacı, başka bir yerdeki benzer bir firmanınkinden farklı olabilir; bu yüzden hazır bir şablonla değil, sizin gerçek iş akışınızla çalışıyoruz. Gözlem sırasında en çok zaman kaybettiren adımları, sık yapılan hataları ve bilginin el değiştirirken bozulduğu noktaları not ediyoruz. Elle tutulan kayıtların fotoğraflarını ya da örnek tabloları da inceleme için bizimle paylaşmanızı rica ediyoruz. Bu notlar, ileride kurulacak sistemin neyi çözmesi gerektiğini gösteren en güvenilir kaynak olur.
Gözlemden sonra işin akışını sade bir şemaya döküyoruz: Bir talep nereden geliyor, kim onu kaydediyor, kim onaylıyor, iş bitince kime haber veriliyor? Bu şema, herkesin kafasında farklı duran süreci ilk kez aynı kâğıt üzerinde buluşturur. Şemayı çizerken çoğu zaman, sistem kurulmadan bile düzeltilebilecek gereksiz adımlar ortaya çıkar ve bunları size açıkça söylüyoruz. Ardından projenin çözeceği sorunu tek bir cümleyle tanımlıyoruz; örneğin siparişlerin kaybolmadan ve kimin elinde olduğu görünerek teslimata kadar izlenmesi. Bu cümle, sonraki bütün kararlarda pusula görevi görür. Bir özellik önerisi geldiğinde önce bu tanıma hizmet edip etmediğini soruyoruz. Kullanıcı rollerini de bu aşamada belirliyoruz; muhasebe, saha ekibi ve yönetim aynı ekrana bakmak zorunda değildir. Her rolün sistemde hangi bilgiyi girdiğini, hangisini yalnızca gördüğünü ve hangi kararı verdiğini ayrı ayrı yazıyoruz. Bu ayrım hem ekranların sadeleşmesini hem de yetki düzeninin baştan doğru kurulmasını sağlar.
Her ihtiyaç sıfırdan geliştirilen bir sistemi gerektirmez ve bunu en baştan açıkça konuşmak isteriz. Piyasada hazır bulunan bir yazılım paketi işinizin büyük kısmını karşılıyorsa, onu önermek hem bütçenizi hem de zamanınızı korur. Hazır çözümün sizi kendi kalıbına zorladığı, ekibinizin programa göre çalışmaya başladığı durumlarda ise özel geliştirme anlamlı hâle gelir. Bazen doğru yol ikisinin karışımıdır; hazır bir sistemi temel alıp yalnızca size özgü kısmı ayrıca geliştirmek hem hızlı hem ekonomik olabilir. Karar verirken lisans maliyetlerini, ileride gerekebilecek değişiklikleri, verinizin nerede tutulacağını ve başka sistemlerle bağlantı ihtiyacını birlikte tartıyoruz. Seçim ne olursa olsun, başarının neyle ölçüleceğini baştan yazıyoruz. Bir işlemin kaç adımda tamamlandığı, bir bilgiye ne kadar sürede ulaşıldığı ya da hatalı kayıtların azalıp azalmadığı bu ölçütlere örnektir. Ölçülebilir hedefler, projenin sonunda gerçekten bir şeyin iyileşip iyileşmediğini görmenizi sağlar.
İlk Sürümü Her Gün Kullanılacak İşlevlerle Sınırlı Tutuyoruz
Kapsam belirlenirken en sık karşılaşılan tuzak, akla gelen her özelliği ilk sürüme sığdırmaya çalışmaktır. Bu yaklaşım teslimi uzatır, maliyeti artırır ve ekibin sistemi benimsemesini zorlaştırır. İstekleri üç gruba ayırıyoruz: İlk günden gerekli olanlar, kullanım başladıktan sonra eklenebilecekler ve şimdilik yalnızca not edilip bekletilecek olanlar. İlk sürüm, işin çekirdeğini sağlam biçimde çözen az sayıda işlevden oluşur. Küçük başlayan bir sistem gerçek kullanımla sınandıkça, sonraki aşamada neyin gerçekten gerekli olduğu da kendiliğinden ortaya çıkar. Bu işlevlerin her birini, kimin kullanacağını, hangi ekranda ne göreceğini ve hangi durumda ne olacağını anlatan kısa maddelerle kapsam belgesine yazıyoruz. Neyin yapılmayacağını da belgede açıkça belirtiyoruz; beklentilerin baştan netleşmesi, ileride doğabilecek hayal kırıklıklarını önler. Yazılım projesi boyunca bir anlaşmazlık çıktığında dönülecek ortak metin bu belgedir. Kapsam dışında kalan bir isteği reddetmiyor, bir sonraki aşamanın listesine alıyoruz; böylece hiçbir fikir kaybolmuyor ama ilk teslim de gereksiz yere uzamıyor.
Kodlamaya geçmeden önce ekranların taslaklarını hazırlıyoruz. Önce kâğıt üzerinde kaba çizimlerle, sonra tıklanabilir basit bir prototiple, sistemin kullanıldığında nasıl hissettireceğini göstermeye çalışıyoruz. Bu taslakları yalnızca yöneticilerle değil, sistemi her gün kullanacak çalışanlarla da deniyoruz. Bir formu her gün dolduran kişi, eksik bir alanı ya da gereksiz bir adımı herkesten önce fark eder. Taslak aşamasında yapılan bir değişiklik küçük bir iştir; oysa aynı değişiklik kod yazıldıktan sonra çok daha fazla zaman ve maliyet doğurur. Ekranlarda kullandığımız dilin ekibinizin günlük diliyle örtüşmesine de dikkat ediyoruz. Sizin cari dediğiniz şeye sistemde başka bir ad vermek gereksiz bir karışıklık yaratır. Telefon ve tablet gibi farklı ekranlarda kullanılacak bölümleri de bu aşamada ayrıca çiziyoruz; sahada ayakta kullanılan bir ekran, masadakinden farklı bir düzen ister. Onaylanan taslaklar, geliştirme ekibinin tahmin yürütmeden çalışmasını sağlayan net bir yol haritasına dönüşür.
Yeni sistem çoğu zaman tek başına çalışmaz; muhasebe programınızla, e-fatura altyapısıyla, ödeme hizmetiyle ya da kargo firmalarının sistemleriyle konuşması gerekir. Bu bağlantıları kapsam aşamasında tek tek listeliyor, her birinin teknik olarak mümkün olup olmadığını ilgili hizmetin belgelerinden kontrol ediyoruz. Bazı kurumlar veri paylaşımı için ayrıca başvuru ya da sözleşme istediğinden, bu adımları takvime baştan ekliyoruz. Dış servislerin zaman zaman yanıt vermeyebileceğini hesaba katıyor, böyle bir durumda işlemin kaybolmaması için bekleme ve yeniden deneme düzeni kuruyoruz. Eski kayıtlarınızın yeni sisteme nasıl aktarılacağını da burada planlıyoruz. Dağınık tablolardaki veriyi temizlemek, tekrar eden kayıtları birleştirmek ve eksik alanları tamamlamak çoğu zaman sanıldığından fazla emek ister. Aktarımı önce küçük bir örnek veriyle deniyor, sonuçları sizinle birlikte kontrol ettikten sonra tamamını taşıyoruz. Böylece yeni sistem ilk gününden itibaren boş değil, geçmişinizi taşıyan bir kayıt defteri olarak açılır.
Her Geliştirme Adımını Test Edip Güvenlik Süzgecinden Geçiriyoruz
Geliştirmeyi uzun ve sessiz bir dönemin sonunda tek seferde teslim edilen bir paket gibi yürütmüyoruz. İşi kısa aşamalara bölüyor, her aşamanın sonunda çalışan bir parçayı size gösteriyoruz. Bu gösterimlerde ekranları kendiniz kullanıyor, beklentinizle örtüşmeyen noktaları hemen söylüyorsunuz. Yanlış anlaşılmalar böylece büyümeden yakalanır ve düzeltme maliyeti düşük kalır. Geliştirme, canlı sistemden ayrı bir deneme ortamında yürür; siz de yeni özellikleri önce orada görüp onaylıyorsunuz. Hangi işin tamamlandığını, hangisinin sürdüğünü ve hangisinin sırada beklediğini gösteren ortak bir iş panosu tutuyoruz; ilerlemeyi görmek için bizi aramanıza gerek kalmıyor. Kodun okunabilir ve başka bir geliştiricinin de anlayabileceği biçimde kalması için her değişikliği ikinci bir geliştiriciye inceletiyoruz. Yazılım geliştirme sırasında karşılaştığımız teknik zorlukları da saklamıyoruz. Gerekirse alternatif bir yol öneriyor, kararı sizinle birlikte veriyoruz. Bu şeffaflık, projenin sonunda sürprizle karşılaşma ihtimalini belirgin biçimde azaltır.
Bir işlevi, yazıldığı anda değil, gerçek kullanım koşullarına benzeyen senaryolarla sınandığında tamamlanmış sayıyoruz. Bir siparişin iptal edilmesi, aynı kaydın iki kişi tarafından aynı anda açılması ya da bağlantının işlem ortasında kopması gibi durumları özellikle deniyoruz. Testlerde boş örnek veriler yerine, gerçek kayıtlarınıza benzeyen ama kişisel bilgileri ayıklanmış veri setleri kullanıyoruz. Ekibinizden birkaç kişinin sistemi teslimden önce kendi işleri üzerinde denemesini istiyoruz. Kabul testi dediğimiz bu adım, ekranların gerçek hayatta nasıl kullanıldığını gösterir. Bulunan her hatayı ortak bir listeye kaydediyor, düzeltildiğinde yeniden deneyip kapatıyoruz. Hata bildirimi için ekibinizin kullanabileceği basit bir yol kuruyoruz; ekran görüntüsü ve kısa bir açıklama çoğu zaman sorunu bulmamıza yeter. Sistemin yoğun saatlerde yavaşlayıp yavaşlamadığını da yük altında ölçüyoruz. Otomatik testlerle, ileride yapılacak bir değişikliğin çalışan bir bölümü bozmasının da önüne geçiyoruz.
Güvenliği işin sonunda eklenen bir katman olarak değil, ilk satırdan itibaren tasarımın parçası olarak ele alıyoruz. Her kullanıcı yalnızca işi için gereken ekranları ve kayıtları görür. Yetkileri roller üzerinden tanımlıyor, ayrılan bir çalışanın erişimini tek adımda kapatılabilir hâle getiriyoruz. Parolaları geri çözülemeyecek biçimde saklıyor, veri trafiğini şifreli bağlantı üzerinden taşıyoruz. Yönetici hesapları için iki aşamalı giriş gibi ek önlemler öneriyor, art arda hatalı giriş denemelerini otomatik olarak sınırlandırıyoruz. Kimin hangi kaydı ne zaman değiştirdiğini gösteren işlem kayıtları tutuyoruz; bir hata ya da anlaşmazlık olduğunda geriye dönüp bakabilmeniz için bu kayıtlar önemlidir. Yedekleri düzenli olarak alıyor, geri yüklemenin gerçekten çalıştığını belirli aralıklarla deniyoruz. Kullandığımız hazır kütüphanelerin güvenlik duyurularını da takip ediyor, açık bulunan bir bileşeni gecikmeden güncelliyoruz. Müşterilerinize ya da çalışanlarınıza ait kişisel verileri işliyorsanız, yasal yükümlülüklere uygun saklama ve erişim kurallarını da sistemin içine yerleştiriyoruz.
Kaynak Kodu Sizde Kalıyor, Bakımı Yazılı Bir Planla Sürdürüyoruz
Parasını ödediğiniz bir yazılım ürününün kaynak kodu ve içindeki veriler size ait olmalıdır. Kodu, işletmeniz adına açılan bir depo hesabında tutuyor, geliştirme boyunca yapılan her değişikliğin orada kaydını bırakıyoruz. Sunucu, alan adı ve kullanılan üçüncü taraf hizmetlerin hesaplarını da işletmeniz adına açıyor, yönetici erişimlerini size veriyoruz. Sunucu ve hizmet faturalarının doğrudan size kesilmesi, maliyetlerin nereye gittiğini görmenizi de kolaylaştırır. Verilerinizi istediğiniz an yaygın bir biçimde dışa aktarabilmeniz için gerekli aracı sistemin içine koyuyoruz. Veritabanının yapısını anlatan bir şemayı da teslim dosyalarına ekliyoruz; verileriniz başka bir sisteme taşınırken bu belge yol gösterir. Bu yaklaşımın amacı basit: Bir gün başka bir ekiple çalışmaya karar verirseniz, sisteminizi olduğu gibi devredebilmeniz. Sahipliği sözleşmede açıkça yazıyor, kullanılan açık kaynak bileşenlerin lisanslarını da listeleyerek teslim ediyoruz. Hakkâri’deki işiniz büyüyüp yeni ihtiyaçlar doğduğunda, elinizde kimsenin insafına kalmamış eksiksiz bir altyapı bulunur.
Teslim, çalışan bir sistemi size bırakıp ayrılmak anlamına gelmez. Sistemin nasıl kurulduğunu, hangi parçanın ne işe yaradığını ve bir sorun çıktığında nereye bakılacağını anlatan teknik belgeleri hazırlıyoruz. Bu belgeler, ileride başka bir geliştiricinin de işi kaldığı yerden devralabilmesi için yazılır. Kullanıcılar için ise ekran görüntüleriyle desteklenmiş sade bir kullanım kılavuzu ve kısa anlatım videoları hazırlıyoruz. Eğitimi herkese aynı anda uzun bir sunum yaparak değil, her rolün kendi işine odaklanan kısa oturumlarla veriyoruz. Eski düzenden yenisine geçişi de bir gecede değil, kısa bir süre iki sistemin yan yana çalıştığı kontrollü bir dönemle yapıyoruz. Ekibinizden sistemi iyi tanıyan bir kişiyi iç sorumlu olarak belirlemenizi öneriyoruz. İlk haftalarda gelen soruları toplayıp kılavuzu bu sorulara göre güncelliyoruz, çünkü gerçek kullanımda ortaya çıkan sorular çoğu zaman bizim öngördüklerimizden farklıdır. Ekibinizin sistemi kendi aracı gibi benimsemesi, projenin gerçekten başarılı sayılmasının ön koşuludur.
Canlıya alınan her sistem zamanla güncelleme ve bakım ister. Kullanılan altyapı bileşenleri yeni sürümler yayımlar, güvenlik açıkları kapatılır, işletmenizin ihtiyaçları değişir. Bakım kapsamını teslimden önce yazılı bir planla netleştiriyoruz: Hata düzeltmeleri, güvenlik güncellemeleri, sunucu takibi ve yedek kontrolleri bu planın içindedir. Yeni bir özellik ya da ekran talebi ise bakımdan ayrı tutulur ve kendi kapsamıyla değerlendirilir. Bu ayrım, hangi işin neden faturalandığı konusunda iki taraf için de netlik sağlar. Sistemin çalışıp çalışmadığını sürekli denetleyen bir izleme düzeni kuruyoruz; bir kesinti yaşandığında çoğu zaman siz fark etmeden haberimiz olur. Bir sorun bildirdiğinizde kaydın nasıl açılacağını, önceliğin nasıl belirleneceğini ve size nasıl dönüş yapılacağını da planda tanımlıyoruz. Yılda birkaç kez kullanım verilerine birlikte bakıp hangi ekranın az kullanıldığını, hangi işlemin hâlâ zaman aldığını konuşuyoruz. Düzenli bakımla ayakta tutulan bir yazılım, yıllar boyunca işinizle birlikte gelişen ve değerini koruyan bir araca dönüşür.
Yazılım Hakkında Sık Sorulan Sorular
Hazır paketlerle ısmarlama bir çözüm arasındaki fark nerede başlar?
Fark, hazır paketin sizi kendi kalıbına uydurmasıyla başlar; iş akışınızı programa göre değiştirmeniz beklenir. Bir özel yazılım ise tersini yapar, sistemi sizin gerçek sürecinize göre biçimler. Bu ayrım teknik koşullar, eldeki içerik ve iş hedefleri birlikte incelendikten sonra netleşir.
İlk sürümde bütün özellikleri bir arada yapmak şart mı?
Genellikle şart değildir ve çoğu zaman doğru da olmaz. İşin çekirdeğini oluşturan az sayıda işlevi önce sağlam kurmak, sonra kullanımdan gelen geri bildirimle ilerlemek daha sağlıklıdır. Böylece hangi eklentinin gerçekten gerektiği, varsayımla değil sahadan gelen veriyle belli olur.
Eski kayıtlar yeni sisteme sorunsuz aktarılabilir mi?
Çoğu durumda aktarılabilir, ancak önce eski verinin ne kadar düzenli tutulduğuna bakmak gerekir. Bu yüzden Hakkâri’de yürüttüğümüz aktarımlarda kaynağı, biçimi ve eksik alanları baştan tespit ediyoruz. Verinin nereden geldiği ve nasıl temizleneceği yazılı hâle getirilmeden aktarıma başlamıyoruz.
Kullanıcı yetkileri kurulumdan sonra değiştirilebilir mi?
Evet, yetkiler zamanla değişen ihtiyaçlara göre yeniden düzenlenebilir. Yeni bir görev, ayrılan bir çalışan ya da değişen bir sorumluluk erişimin güncellenmesini gerektirir. Önemli olan, her değişikliğin kimin kararıyla yapıldığının kayıt altında kalması ve gerektiğinde geriye dönük izlenebilmesidir.
Her dijital çalışma için ayrı bir mobil uygulama gerekir mi?
Hayır, her iş ayrı bir mobil uygulamayı gerektirmez. Kimi durumda telefondan da rahat açılan bir arayüz yeterlidir; asıl belirleyici, işlemin gerçekten sahada mı yapıldığıdır. Bu karar, kullanılan altyapının olanaklarına ve işi kimin yürüttüğüne göre birlikte planlanır.
Bakım ile yeni geliştirme arasındaki sınır nasıl belirlenir?
Bakım, çalışan bir sistemin ayakta ve güvende kalmasını sağlayan işlerdir; yeni geliştirme ise sisteme daha önce olmayan bir yeteneği eklemektir. Bir özel yazılım için bu ayrımı baştan yazmak, hangi işin rutin destek hangisinin ayrı bir çalışma olduğunu belirsizlikten çıkarır. Sınırı netleştirmek, sonradan doğacak beklenti farklarını da önler.
