Teknik fizibilite: Yazılım projesine başlamadan risk haritası

Bayi portalı için ekran listesi hazırdır: ürünler, stok, sipariş ve raporlar. Takvim konuşulurken stok bilgisinin eski bir sistemden alınacağı anlaşılır. O sisteme kimin erişebildiği, verinin hangi sıklıkta güncellendiği ve test ortamı olup olmadığı ise henüz bilinmez. Tasarım ilerleyebilir; fakat projenin temel bağımlılığı hâlâ açıkta durur. Teknik fizibilite, böyle bir belirsizliği geliştirme başladıktan sonra sürpriz olmaktan çıkarıp karar verilebilir bir konuya dönüştürür.

Bu yazıdaki bayi portalı kurgusaldır. Örnek üzerinden bir yazılım projesinin risk haritasını nasıl hazırlayabileceğimizi ele alacağız. Fizibilite, yalnızca “yapılabilir” cümlesi kurmak veya teknoloji seçmek değildir. Hangi koşulda, hangi bağımlılıklarla ve hangi sınırlarda ilerlenebileceğini açıklamalıdır. Sonuç bazen geliştirmeye başlamak, bazen küçük deneme yapmak, bazen de kapsamı değiştirmek olabilir. Her durumda kararın hangi bilgiye dayandığı ve neyin henüz doğrulanmadığı görünür kalmalıdır.

İncelemeye çözüm listesinden değil kritik varsayımdan başlayın

Portalın işe yaraması için hangi şeylerin doğru olması gerekiyor? Stok verisi zamanında alınabilmeli, bayi yalnızca yetkili ürün ve koşulları görmeli, sipariş doğru sisteme ulaşmalı. Bu cümleler projenin temel varsayımlarını ortaya çıkarır. Her ekranı eşit önemle incelemek yerine bu varsayımları değerlendirin. Güzel bir rapor paneli, stok kaynağına erişilemiyorsa temel sorunu çözmez. Fizibilite, projenin kaderini etkileyen bilgiyi ön sıraya almalıdır.

Varsayımı gereksinimden ayırın. “Stok gösterilecek” istenen davranış olabilir; “mevcut sistemden güncel stok alınabiliyor” ise doğrulanması gereken koşuldur. İkisi aynı cümlede yazıldığında belirsizlik kaybolmuş gibi görünebilir. Her koşulun yanına mevcut kanıtı ekleyin. Doküman mı var, erişim mi denenmiş, yalnızca bir kişinin beyanı mı bulunuyor? Bu ayrım, karar toplantısında kesin bilgiyle beklentinin karışmasını önler. Bilgi sahibi ve kontrol noktası da kayda alınabilir.

Entegrasyon bağımlılığını gerçekten inceleyin

Bir dış sistemin adını bilmek bağlantı işini tanımlamaz. Hangi kaydın hangi yönde aktarılacağı, erişim yolu, güncel dokümantasyon ve test imkânı sorulmalıdır. Bayi portalında stok okumakla sipariş yazmak farklı yetki ve davranışlar gerektirebilir. Kaynak sistemin sorumlusu incelemeye katılmalıdır. “Entegrasyon var” cümlesini, gerekli işlemin gereken koşullarda yapılabildiği kanıtıyla tamamlayın. Hazır bir bağlantının farklı veri kapsamı taşıması mümkündür; isim benzerliği yeterli değildir.

Hata koşullarını erken konuşun. Bilgi gecikirse portal kullanıcıya ne gösterecek? Sipariş gönderildi ama yanıt alınamadıysa tekrar mı denenecek, durum mu araştırılacak? Karşı sistemin bakım saatleri veya değişiklikleri nasıl öğrenilecek? Her ayrıntı ilk incelemede kesinleşmeyebilir. Fakat işin güvenilirliğini etkileyen sorular listelenmeli ve gerekli teknik deneme planlanmalıdır. Bağımlılığın fark edilmesi, bütün soruların aynı gün çözüleceği anlamına gelmez; çözüme giden yolun görünür olması gerekir.

Verinin varlığıyla kullanılabilirliğini karıştırmayın

Bir tabloda ürün bilgisi bulunması, portalda kullanılmaya hazır olduğunu göstermez. Kodlar tutarlı mı, pasif ürünler ayrılıyor mu, aynı ürün için birden fazla kayıt var mı? Bayiye gösterilecek ad ve açıklama başka kaynaktan gelebilir. Örnek veri üzerinden inceleme yapılmalıdır. Boş bir ekran taslağı bu sorunları göstermez. Gerçek verinin uygun biçimde hazırlanmış veya anonimleştirilmiş örneği, alan ilişkilerini ve eksikleri daha somut tartışmayı sağlar.

Veri sahibi de belirli olmalıdır. Hatalı stok veya ürün tanımı görüldüğünde hangi ekip düzeltecek? Portalda yapılan değişiklik kaynağa geri yazılacak mı? İki sistemde ayrı ayrı düzenlenirse hangi kayıt esas kabul edilecek? Bu kararlar teknik yapı kadar işletme sürecini de etkiler. Fizibilite, veri sorununu yalnızca yazılımcının aktarım işi olarak görmemelidir. Temizliği, doğrulamayı ve günlük bakımını yapacak sorumluların bulunması projenin uygulanabilirliğinin bir parçasıdır.

Yetki ve kullanım koşullarını örnek işlemlerle sınayın

Bayi, iç satış ekibi ve yönetici aynı bilgiyi görmeyebilir. Bazı kullanıcılar fiyatı, bazıları yalnızca ürün açıklamasını görebilir. Hangi kaydın kime ait olduğu ve hangi işlemin yapılabildiği açıkça tarif edilmelidir. “Kullanıcı rolleri olacak” ifadesi bunu tam anlatmaz. Örneğin bir bayinin başka bayinin siparişini görememesi gibi senaryolar üzerinden konuşmak daha açıklayıcıdır. Yetki sınırları arayüz görünümünün ötesinde veri davranışıyla birlikte değerlendirilir.

Günlük kullanım ortamını inceleyin. Kullanıcı telefonla mı, masaüstüyle mi çalışıyor, aynı kaydı birden fazla kişi mi değiştiriyor? İnternet bağlantısı veya vardiya düzeni önemli mi? Bunlar tasarım ve teknik planı değiştirebilir. Bütün zor koşulları kapsam dışında bırakmak projeyi kâğıt üzerinde kolaylaştırır ama gerçek kullanımını zayıflatabilir. Gerekli koşullar, ertelenebilecek seçeneklerden ayrılmalıdır. Kullanılabilirlik incelemesi bu yüzden teknik fizibilitenin dışında bir süsleme değil, planın gerçek işte çalışmasının kontrolüdür.

Performans beklentisini senaryoya bağlayın

“Hızlı çalışsın” herkesin kabul edebileceği fakat farklı yorumlayacağı bir beklentidir. Hangi işlem, hangi veri hacmi ve hangi eşzamanlı kullanım koşulu önemli? Portal için ürün arama, büyük sipariş veya rapor açma farklı yükler oluşturabilir. Önce kritik senaryolar seçilir, sonra uygun hedefler teknik değerlendirmeyle belirlenir. Tahmini sayıları gereksinim gibi sunmayın. Bilinmeyen kullanım hacmi varsa bunun nasıl araştırılacağı veya hangi aralıkta değerlendirileceği kaydedilebilir.

Performans denemesi, gerçek koşulu ne kadar temsil ettiğini açıklamalıdır. Az kayıtla hızlı sonuç almak daha büyük veride aynı davranışı kanıtlamaz. Bunun tersi de geçerlidir: gerçek işte gerekmeyen aşırı bir senaryoyu tek karar ölçütü yapmak gereksiz karmaşıklık yaratabilir. Ölçüm ortamı, veri ve sınırlar birlikte sunulur. Amaç etkileyici bir sayı üretmek değil, işletmenin ihtiyacını karşılayacak yaklaşımın hangi kanıta dayandığını anlamaktır. Gerekli belirsizlik için ek deneme planlanır.

Güvenlik, işletim ve bakım işlerini görünür tutun

Erişim yönetimi, kayıt geçmişi, yedekleme, geri yükleme ve hata bildirme düzeni projenin sürdürülebilirliğini etkiler. Hangi kontrolü kim yapacak? Bir sorun olduğunda hangi ekibe hangi bilgi ulaşacak? Fizibilite, yalnızca ilk geliştirme ekibinin kodu yazabileceğini göstermekle sınırlı kalmamalıdır. İşletmenin sistemi kullanıp sürdürebilmesi de değerlendirilir. Gereken incelemenin derinliği veri ve operasyonun riskine göre belirlenir. Kontrollerin isimlerini listelemek, uygulandıklarını kanıtlamaz.

Canlı ortam, alan adı, üçüncü taraf hesaplar ve dağıtım erişimleri için sahiplik belirleyin. Bir kişinin kişisel hesabına bağımlı bir kurulum sonradan devri zorlaştırabilir. Bakım ve destek kapsamı ayrıca konuşulmalıdır. İşletme hangi işleri kendi yapabilecek, hangileri uzman desteği gerektirecek? Özel Yazılım Projeleri kapsamını değerlendirirken bu işletim koşullarını ihtiyaç analizi ve geliştirme planıyla birlikte ele almak, ilk teslimin ötesindeki sorumlulukları açıklaştırabilir.

Risk haritası puandan daha fazla bilgi taşısın

Her risk için neden, olası etki, mevcut kanıt, kontrol sahibi ve sonraki adım yazılabilir. Olasılık ve etki sınıfları kullanılacaksa ekip bunların ne anlama geldiğini bilmelidir. Kesin veri yokken ayrıntılı yüzdeler vermek yapay kesinlik oluşturabilir. “Yüksek” etiketi de tek başına karar sağlamaz. Bayi portalında stok kaynağına erişilememesi temel akışı engellerken bir görsel özelleştirme gecikmesi başka düzeyde etki taşıyabilir. Gerekçe farkı görünür kılar.

Riskleri yalnızca sıralamak yerine eyleme bağlayın. Dış sistem erişimi için toplantı, örnek veri için teslim, kritik işlem için teknik deneme gibi işler tanımlanır. Her birinin sahibi ve kontrol noktası olur. Risk kaydı böylece projenin neden zor olduğunu anlatan bir liste değil, belirsizliği azaltan çalışma planı hâline gelir. Kapanan riskte hangi kanıtın elde edildiği de saklanabilir. Bir kişinin “tamamdır” demesiyle gerçekten neyin doğrulandığı aynı şey değildir.

Aynı riske farklı yanıtlar mümkün olabilir

Bir bağımlılık giderilebilir, kapsam değiştirilebilir, alternatif kaynak seçilebilir veya belirli koşulla kabul edilebilir. Hepsi teknik çözüm üretmek anlamına gelmez. Örneğin anlık stok yerine açıkça belirtilen güncelleme zamanı bazı işlerde uygun olabilir; başka işlerde temel ihtiyacı karşılamaz. Bu karar işletme etkisiyle birlikte verilir. Kullanıcıya sunulan bilginin sınırı anlaşılır kalmalıdır. Fizibilite, seçenekleri dürüstçe gösterdiğinde yönetim yalnızca “olur mu?” sorusundan daha anlamlı bir karar verebilir.

Sonucu üç karardan birine bağlayın

İnceleme sonunda geliştirmeye devam, hedefli araştırma veya kapsamı yeniden ele alma kararı çıkabilir. Bunlar katı bir sınıflandırma değildir; sonucu eyleme dönüştürmenin bir yoludur. Devam kararı koşullarıyla yazılmalıdır. Hangi bilgi kesinleşti, hangi bağımlılık sürüyor, hangi iş başlamadan önce ne gerekli? Araştırma kararı için cevaplanacak soru ve çıktı belirlenir. Kapsam değişikliği de kullanıcı ihtiyacını nasıl etkilediğiyle birlikte değerlendirilir. İncelemenin sonu belirsiz bir olumlu görüş olmamalıdır.

Bayi portalına dönelim. Ekip stok kaynağından gerekli veriyi alabiliyor ama güncelleme gecikmesinin iş üzerindeki etkisini henüz bilmiyor olabilir. Bu durumda bütün projeyi kesin süreyle başlatmak yerine sınırlı akış ve kullanım incelemesi seçilebilir. Sonuç, ilk ekran listesine göre daha küçük görünebilir; fakat karar daha somut bilgiye dayanır. Fizibilitenin çıktısı tam da budur: hangi yolda, hangi koşulla ve hangi açık sorularla ilerleyeceğini bilen bir proje başlangıcı.

Tedarik ve işletme kararlarını geliştirme işi gibi saklamayın

Test hesabının açılması, dış sistem sorumlusunun toplantıya katılması veya veri kullanımının kurum içinde değerlendirilmesi kod yazarak tamamlanmaz. Bu işler de plana dahil edilmelidir. Bir bağımlılık işletmenin kararını bekliyorsa geliştiriciye belirsiz bir teslim tarihi vermek yerine karar sahibini ve gerekli girdiyi belirtin. Aynı şekilde üçüncü taraf hizmet bedeli veya erişim koşulu değişebiliyorsa güncel teklif incelenir. Fizibilite kaydı, bunları yazılım ekibinin sessizce çözeceği ayrıntılar olarak bırakmamalıdır. Projenin yapılabilirliği, teknik beceri kadar gerekli işbirliği ve girdilerin gerçekten sağlanabilmesine de bağlıdır.

Sık Sorulan Sorular

Teknik fizibilite ne zaman yapılmalı?

Temel bağımlılıklar ve bilinmeyenler büyük geliştirme kararından önce incelenmelidir. Derinlik projenin riskine göre değişir. Basit bir iç araçla çok sistemli operasyon aynı çalışma gerektirmeyebilir. Önemli olan kritik varsayımların ekran ve takvim kararlarının arkasında görünmez kalmamasıdır. Yeni bilgi çıktığında fizibilite bulguları da yeniden değerlendirilebilir.

Fizibilite her ayrıntıyı kesinleştirir mi?

Hayır. Hangi bilginin doğrulandığını ve hangi sorunun açık kaldığını ortaya koymalıdır. Bazı konular prototip veya teknik deneme gerektirir. Sonuç, bilinmeyeni gizlemek yerine ona uygun sonraki adımı seçer. Kesinlik düzeyi açıklanmış bir karar, her şey hazırmış gibi görünen fakat varsayımları belirsiz bir plandan daha yararlı olabilir.

Fizibilite ile kapsam belgesi aynı mı?

Birbirini desteklerler ama aynı işlevde değildirler. Kapsam neyin geliştirileceğini ve nasıl kabul edileceğini anlatır. Fizibilite, bunun hangi koşullarda uygulanabileceğini ve hangi belirsizliklerin kararı etkilediğini inceler. Bulgular kapsamı değiştirebilir. İki çalışma arasında bağ kurmak, istenen özelliklerin gerçek bağımlılıklarla birlikte planlanmasını sağlar.

Prototip yapılmadan karar verilebilir mi?

Bazı konular doküman, örnek veri veya mevcut erişim kontrolüyle değerlendirilebilir. Başka belirsizlikler deney gerektirir. Her soruya aynı prototip yöntemini uygulamak gerekli değildir. Hangi kanıtın kararı destekleyeceğini seçin. Görsel taslak, entegrasyonun çalıştığını kanıtlamaz; teknik deneme de kullanıcının akışı anlayacağını kendiliğinden göstermez.

Fizibilite olumsuz çıkarsa proje bırakılmalı mı?

Sonuca göre alternatifler değerlendirilir. Kapsam değişebilir, bağımlılık giderilebilir veya başka çözüm seçilebilir. Bazı durumlarda devam etmemek uygun olabilir. Olumsuz bulgu yalnızca başarısızlık olarak görülmemelidir; büyük bir yatırımı daha bilinçli değerlendirmeyi sağlar. Hangi koşul değişirse kararın yeniden açılacağı da kaydedilebilir.