Geliştirmeden Önce İşi Anlayın
Bir şirket platform geliştirmeyi düşündüğünde konuşma çoğu zaman görünen şeylerle başlar.
Tasarım.
Modüller.
Özellikler.
Erişim kontrolleri.
Raporlar.
Ancak tüm bunlardan önce, sonucun büyük bölümünü belirleyebilecek bir aşama vardır:
işin gerçekte nasıl yürüdüğünü anlamak.
Çünkü bir platform iyi görünüp yine de desteklemesi gereken operasyonu yansıtmakta başarısız olabilir.
Önce iş mantığı gelir
Her şirketin kendine özgü bir işleyiş biçimi vardır.
Bazı süreçler belirli adımları izler.
Bazı kurallar belirli koşullara bağlıdır.
Kullanıcıların farklı yetkileri vardır.
Bazı bilgilerin yalnızca belirli anlarda görünmesi gerekir.
Bazı durumlar, bağlama göre farklı bir yanıt gerektirir.
Tüm bunlar teknolojiye dönüşmeden önce de vardır.
Ve net bir şekilde anlaşılmazsa geliştirme süreci sorunun yalnızca bir kısmını çözmekle sonuçlanabilir.
Bir özellik, tamamen incelenene kadar basit görünebilir
Bir kişiyi platforma kaydetmek kadar sıradan bir şeyi düşünün.
İlk bakışta bir formdan ibaret gibi görünebilir.
Ancak arkasında birkaç karar yatıyor olabilir.
Hangi bilgiler istenmeli?
Hangi alanlar zorunlu?
Kayıttan sonra ne olur?
Kullanıcı hangi yetkileri alır?
Nelere erişebilir?
Hangi süreçler otomatik olarak tetiklenir?
Görünen özellik basit olabilir.
Arkasındaki mantık ise öyle olmayabilir.
Teknoloji tasarlamak, soru sormak demektir
İnşa etmeden önce anlamak gerekir.
Önce ne olur?
Ne neye bağlıdır?
Her işlemi kim gerçekleştirebilir?
Bir koşul karşılanmadığında ne olur?
Her rolün hangi bilgilere ihtiyacı vardır?
Hangi süreçler insan müdahalesi gerektirir?
Neler otomatikleştirilebilir?
Hangi istisnalar vardır?
Bu sorular, genel bir fikri bir sistem içinde temsil edilebilecek bir operasyona dönüştürmeye yardımcı olur.
İstisnalar da işin bir parçasıdır
Süreçler genellikle ideal senaryo düşünülerek anlatılır.
Ancak günlük operasyonlar nadiren yalnızca bu şekilde işler.
Özel durumlar vardır.
Değişen koşullar.
İnceleme gerektiren durumlar.
Ana akışı tam olarak izlemeyen işlemler.
Bu istisnalar en baştan dikkate alınmadığında sistemin dışında ele alınır hâle gelebilir.
Zamanla bu geçici çözümler kontrol edilmesi zor süreçlere dönüşebilir.
Geliştirme bağlam gerektirir
Bir teknoloji ekibi bir özellik inşa edebilir.
Ancak doğru özelliği inşa edebilmesi için o özelliğin neden var olduğunu anlaması gerekir.
Onu kimin kullandığını.
Hangi sorunu çözdüğünü.
Hangi bilgileri aldığını.
Hangi bilgileri ürettiğini.
Ve operasyonun geri kalanıyla nasıl bağlantı kurduğunu.
Bu bağlam, geliştirmenin yapılış biçimini değiştirir.
Görev artık yalnızca bir talebi yerine getirmek değildir.
O talebin işte oynadığı rolü anlamaktır.
Bir platform iş kararlarını da yansıtır
Her yetki bir kararı yansıtır.
Her iş akışı bir önceliği yansıtır.
Her otomasyon bir kuralı yansıtır.
Her rapor bir bilgi ihtiyacını yansıtır.
Bu yüzden bir platform, araçlardan oluşan bir koleksiyondan fazlasıdır.
Bir şirketin nasıl organize olduğunu da temsil edebilir.
Bu organizasyon ne kadar netse teknolojiye aktarılması da o kadar tutarlı olabilir.
Daha iyi inşa etmek, daha iyi anlamak da demektir
Bir proje doğrudan özelliklerle başladığında ekranda neyin görünmesi gerektiğine odaklanmak kolaydır.
Operasyonla başladığında ise konuşma değişir.
Ekip neyin gerçekleşmesi gerektiğini inceler.
Neden gerçekleştiğini.
Kimlerin dahil olduğunu.
Hangi bilgilerin devreye girdiğini.
Ve hangi sonucu üretmesi gerektiğini.
Bu fark ilk başta küçük görünebilir.
Ancak sonrasında inşa edilen her şeyi etkileyebilir.
Son düşünceler
Teknoloji, kod yazıldığında başlamaz.
Çözmesi gereken sorunu anladığınızda başlar.
Bir ekran tasarlamadan önce süreci anlamak faydalıdır.
Bir işlemi otomatikleştirmeden önce kuralı anlamak faydalıdır.
Bir özelliği inşa etmeden önce amacını anlamak faydalıdır.
Çünkü bir şirket için teknoloji geliştirmek yalnızca araç yaratmakla ilgili değildir.
Gerçek bir operasyonu anlamlı bir dijital yapıya dönüştürmekle ilgilidir.
