Özel yazılım yaptırmayı düşünen çoğu işletmenin kafasındaki en büyük soru işareti, aslında teknoloji değil: "Bu iş baştan nereye bağlanacak, ben parayı verdikten sonra ne olacak?" Haklı bir tedirginlik. Hazır bir programı satın aldığınızda ne aldığınızı görürsünüz; özel yazılımda ise ortada henüz olmayan bir şeyi sipariş edersiniz. Süreci görünür kılmak, bu belirsizliği dağıtmanın en iyi yolu.
Bir özel yazılım projesinin ilk görüşmeden teslim sonrasına kadar hangi adımlardan geçtiğini, her adımda sizden ne beklendiğini ve işin en çok nerede tökezlediğini, bu işi yapan tarafın gözünden anlatalım.
Keşif ve analiz: projenin kaderi burada belirlenir
İyi kurulmuş bir projeyle yarım kalmış bir projenin farkı, çoğu zaman daha ilk haftada belli olur. Keşif aşaması, "ne istiyorsunuz" sorusunun ötesine geçip "bu yazılım hangi derdi çözecek, kimler kullanacak, bugün bu işi nasıl yapıyorsunuz" sorularının cevaplandığı yer.
Burada masaya oturup süreçlerinizi konuşuruz. Siparişi kim giriyor, onay kimden geçiyor, hangi bilgi nerede tutuluyor, hangi adım elle yapıldığı için zaman kaybettiriyor. Çoğu zaman işletme sahibi bu konuşma sırasında kendi sürecinde daha önce fark etmediği boşlukları görüyor; iyi bir analiz, yazılımdan bağımsız olarak bile işe yarıyor. Bu konuşma çoğu zaman "bize özel bir panel ya da CRM mi gerekiyor" sorusunu da netleştirir; özel panel / CRM ne zaman gerekir yazımız bu eşiği ayrı ele alıyor.
Bu aşamanın çıktısı somut: ne yapılacağının yazılı bir çerçevesi — hangi ekranlar, hangi roller, hangi akışlar, hangi entegrasyonlar. Uygulamada en çok burada emek harcıyoruz, çünkü üstünkörü geçilen her analiz, aylar sonra "ama ben bunu böyle anlamamıştım" olarak geri dönüyor. Bu belgeyi birlikte netleştirmeden teklif aşamasına geçmiyoruz.
Teklif ve sözleşme: işin sınırını yazıya dökmek
Analiz netleştiğinde ortaya kapsamı belli bir iş çıkar ve ancak o zaman anlamlı bir teklif verilebilir. "Şöyle bir yazılım ne kadar" sorusuna analiz yapmadan rakam söylemek, metrekaresini bilmeden eve fiyat biçmeye benzer; o yüzden sağlıklı bir teklif her zaman keşfin ardından gelir.
Teklifte yalnızca bedel olmaz. Kapsamın sınırı, teslim aşamaları, kabaca zaman planı ve kapsam dışında kalan işler de yazılır. Bu "kapsam dışı" kısmı insanların en çok atladığı ama en çok işe yarayan bölümdür; çünkü ilerledikçe çıkan "bir de şu olsa" istekleri, baştan çizilmiş bir sınır olunca rahatça yeni bir aşama olarak ele alınır, projeyi ray dışına çıkarmaz.
Sözleşmenin asıl kıymeti ise iki tarafı da korumasıdır. İçinde net olması gereken başlıklar arasında teslim takvimi ve ödeme planı kadar, çoğu kişinin hiç sormadığı bir madde de bulunur: üretilen kodun ve verinin kime ait olduğu. Bizde bu konu baştan açıktır — yazılan kod da içine girdiğiniz veri de baştan sona size aittir. Fiyat modelimizin mantığını önceden görmek isterseniz fiyatlandırma sayfamız bir başlangıç fikri verir; kesin rakam ise her zaman kendi kapsamınızdan çıkar.
Tasarım: kod yazılmadan ekranları görmek
Geliştirmeye geçmeden önce yazılımın nasıl görüneceğini ve nasıl kullanılacağını tasarlarız. Bu, estetik bir süsleme değil; bir binanın mimari projesi gibi, inşaat başlamadan planı görme fırsatı.
Genelde önce arayüzün taslaklarını (wireframe), ardından gerçek tasarımları paylaşırız. Siz ekranlara bakıp "sipariş butonu burada olmaz, bizim kullanıcı önce müşteriyi seçer" diyebilirsiniz — ve bu geri bildirim o an bir çizim üzerinde değiştiğinde neredeyse bedavaya gelir. Aynı değişiklik yazılım bittikten sonra istense, hatırı sayılır bir yeniden-geliştirme demektir. Tasarım aşamasını ciddiye almanın bütçeye en büyük katkısı tam da budur.
Geliştirme: neden parça parça ilerliyoruz
Tasarım onaylandıktan sonra asıl yazılım geliştirme başlar. Burada çalışma biçimimiz, projeyi tek seferde yazıp sonunda büyük bir "işte bitti" anıyla teslim etmek değil; aşamalara (sprint) bölerek ilerlemek.
Bunun mantığı basit. Yazılım, planladığınız parçalardan biri bittikçe size gösterilir; siz çalışan hali üzerinde görüşünüzü söylersiniz, bir sonraki parça bu geri bildirimle şekillenir. Böylece aylarca hiçbir şey görmeden beklemez, sürecin içinde kalırsınız. Yolun yarısında "aslında bunu şöyle istiyordum" dendiğinde, henüz yazılmamış kısımları buna göre ayarlamak çok daha kolay olur.
İşin aslı, bir yazılımın gerçek ihtiyacı çoğu zaman ancak çalışan ilk parçalar elde oynadıkça netleşir. Masa başında kusursuz görünen bir akış, gerçek veriyle karşılaşınca değişebiliyor. Aşamalı ilerlemek, bu değişimi bir kriz değil, sürecin doğal parçası haline getiriyor.
Bir örnek üzerinden somutlaştıralım. Diyelim ki bir servis firması için iş emri takip sistemi geliştiriyoruz. İlk aşamada yalnızca iş emri açma ve teknisyene atama devreye alınır. Firma bunu bir hafta kullanınca, baştan hiç konuşulmamış bir ihtiyaç ortaya çıkar: teknisyenin sahadan fotoğraf ve not eklemesi gerekiyor. Bu istek henüz yazılmamış sonraki aşamaya kolayca yedirilir; eğer tüm sistem tek seferde yazılıp bitseydi, aynı değişiklik çok daha maliyetli olurdu. Çalışan parçayı erken görmenin getirisi tam olarak bu.
Test, teslim ve eğitim
Her parça geliştirilirken test edilir, ama teslim öncesi bütünün bir arada sınandığı ayrı bir aşama vardır. Burada yalnızca "çalışıyor mu" değil, "yanlış veri girilince ne oluyor, aynı anda iki kişi kullanınca ne oluyor, beklenmedik durumda sistem ne yapıyor" sorularının peşine düşülür. Kullanıcının yapabileceği hataları önceden düşünmek, canlıya çıktıktan sonra yangın söndürmekten çok daha ucuzdur.
Teslim, dosyayı gönderip el sıkışmak değildir. Yazılım kendi sunucunuza ya da anlaştığımız barındırma ortamına kurulur, gerçek verilerle devreye alınır ve en önemlisi, kullanacak ekibe anlatılır. Dünyanın en iyi yazılımı bile, onu kullanacak insanlar nasıl işlediğini bilmiyorsa rafta kalır. Bu yüzden eğitim ve gerektiğinde kısa bir kullanım kılavuzu, teslimin ayrılmaz parçası.
Devreye almanın kolayca atlanan ama önemli bir ayrıntısı da eski verinin taşınması. Çoğu işletme yeni yazılıma geçerken yıllarca biriktirdiği müşteri, ürün ya da geçmiş kayıtları da yanında getirmek ister. Bu veriyi mevcut sistemden ya da Excel dosyalarından yeni yazılıma düzenli biçimde aktarmak, teslimin planlanması gereken bir parçası; sonradan akla gelince acele edilen bir iş değil. Taşınan kayıtlar kişisel veri içeriyorsa — müşteri bilgileri gibi — yazılımın KVKK ve VERBİS yükümlülükleriyle uyumlu kurulması da bu aşamanın bir parçası. Bunu baştan konuştuğumuzda geçiş, ekip için hiçbir şeyi sıfırdan girmeden, kaldığı yerden devam eder gibi oluyor.
Teslimden sonra: sahiplik ve bakım
Yazılım canlıya çıktığında ilişki bitmez, biçim değiştirir. İlk haftalarda gerçek kullanımdan ufak pürüzler çıkması olağan; bunları gidermek işin doğal bir parçası. Sonrasında ise iki tür ihtiyaç doğuyor: zamanla çıkan hataların giderilmesi ve işiniz büyüdükçe eklenecek yeni özellikler.
Bu noktada en çok önemsediğimiz konu sahiplik. Kodun ve verinin size ait olması, yalnızca bir sözleşme maddesi değil, pratik bir özgürlük: yarın bizimle çalışmaya devam etmek istemezseniz, yazılımı başka bir ekibe teslim edip yolunuza gidebilirsiniz. Müşteriyi kendine kilitleyen, kaynağını vermeyen yaklaşımlara hiç girmiyoruz. Bize kalırsa güven, ancak karşı tarafın her an gidebileceğini bildiğinizde gerçek anlam kazanıyor.
En sık nerede aksıyor?
Yıllar içinde gördüğümüz aksama noktaları şaşırtıcı ölçüde birbirine benziyor. Üç tanesi öne çıkıyor.
Birincisi, kapsamın yürürken sürekli büyümesi. Proje ilerledikçe akla yeni fikirler gelir, bu doğaldır; ama her fikir anında "bunu da ekleyelim" olarak sokuşturulursa, hiçbir aşama bitmez ve bütçe şişer. Çözüm, yeni istekleri reddetmek değil — onları sıraya koyup ayrı bir aşama olarak ele almak.
İkincisi, müşteri tarafının yavaş kalması. Bir yazılım projesi çift taraflı yürür; onaylar, örnek veriler, geri bildirimler zamanında gelmezse en hızlı ekip bile bekler. Projelerin gecikme sebeplerinin azımsanmayacak bir kısmı, aslında geliştirme değil, bekleyen onaylardır.
Üçüncüsü, doğru kişinin masada olmaması. Yazılımı günlük kullanacak kişi hiç sürece katılmadıysa, bir üst yöneticinin hayal ettiği akışla sahadaki gerçek iş tutmayabiliyor. Keşif ve tasarım aşamasına işi fiilen yapan kişiyi dahil etmek, sonradan çıkacak sürprizlerin çoğunu baştan eliyor.
Projede sizin rolünüz
Özel yazılım, ısmarlanıp beklenerek değil, birlikte yürüyerek çıkan bir iş. Sizden beklediğimiz birkaç şey var ve bunlar projenin hızını doğrudan belirliyor: işinizi ve sürecinizi açıkça anlatmak, onayları makul sürede vermek, gerçek örnek verilerle test etmek ve yazılımı kullanacak kişiyi sürecin içine katmak.
Bunun karşılığında bizden bekleyeceğiniz şey de nettir: her aşamada ne yaptığımızı görünür kılmak, kararların sebebini açıklamak ve kötü haberi de — bir şey tahmin edilenden uzun sürecekse — zamanında söylemek. İyi bir yazılım ilişkisi, teknik beceriden önce bu şeffaflıkla ayakta duruyor. Süreci ve kapsamı kendi işinize göre konuşmak için bir özel yazılım geliştirme görüşmesi, her zaman en sağlıklı başlangıç.
Sıkça Sorulan Sorular
Özel yazılım projesi ne kadar sürer?
Kapsamına göre değişir, ama süreyi belirleyen asıl şey projenin büyüklüğü kadar iki tarafın ritmi. İyi tanımlanmış, odaklı bir ilk sürüm birkaç haftada çıkabilirken, çok modüllü bir sistem aylar alır. Aşamalı ilerlediğimiz için ilk çalışan parçaları görmeniz genelde uzun sürmez; her şeyin birden bitmesini beklemek yerine, adım adım devreye almak hem daha hızlı hissettirir hem gerçekten daha hızlıdır.
Proje yürürken yeni özellik isteyebilir miyim?
İsteyebilirsiniz, bu son derece doğal. Önemli olan bunu nasıl ele aldığımız: yeni istek, yürüyen aşamanın içine sıkıştırılmaz, ayrı bir iş kalemi olarak değerlendirilir ve kapsam ile takvime etkisi açıkça konuşulur. Böylece hem fikrinizi hayata geçirirsiniz hem de mevcut planı ray dışına çıkarmazsınız.
Yazılımın kaynak kodu ve verilerim kimde kalıyor?
Sizde. Ürettiğimiz kodun ve sisteme girdiğiniz verinin mülkiyeti baştan sona size aittir ve bunu sözleşmeyle güvence altına alırız. Yarın dilerseniz başka bir ekiple devam edebilir, yazılımı kendi sunucunuza taşıyabilirsiniz. Bu özgürlük, bizimle çalışmaya devam etme kararınızın gönüllü kalmasını sağlıyor.
Hazır bir programla özel yazılım arasında nasıl seçim yapmalıyım?
Genel bir işi yapıyorsanız — standart muhasebe, basit stok — hazır bir çözüm çoğu zaman daha hızlı ve ucuzdur. Kendi sürecinize özgü, piyasadaki hazır programlara sığmayan bir akışınız varsa ya da birkaç farklı sistemi birbirine bağlamanız gerekiyorsa, özel yazılım devreye girer. Doğru soru "hangisi daha iyi" değil, "benim işim standart bir kalıba sığıyor mu" sorusudur. Bu kararı derinleştirmek için özel yazılım mı hazır şablon mu karşılaştırmamıza ve WordPress mi özel yazılım mı yazımıza bakabilirsiniz.
Teslimden sonra sorun çıkarsa ne oluyor?
İlk kullanım döneminde çıkan pürüzleri gidermek işin doğal parçası. Sonrası için bakım ve destek düzenini baştan konuşuyoruz; kimi müşteri bu işi tümüyle bize bırakıyor, kimi kendi ekibini kullanıyor. Kod sizde olduğu için her iki yol da açık — hiçbir senaryoda tek bir ekibe mahkûm kalmıyorsunuz.
Nereden başlamalı?
Özel yazılımın en büyük korkusu belirsizlik, panzehiri ise görünürlük. Sürecin adımlarını, her birinde ne beklendiğini ve nerede tökezlenebileceğini önceden bilmek, bu işi çok daha az tedirgin edici hale getiriyor. Gerisi, doğru soruları soran bir keşifle başlayıp aşama aşama, görünür biçimde ilerlemek.
Aklınızda bir fikir ya da çözülmesi gereken bir süreç varsa, önce onu konuşalım; kabaca nasıl bir yol haritası çıkacağını açıkça masaya koyarız. Başlamak için bize yazmanız yeterli.
Etiketler
