Düz bir mantıkla baktığımızda, biz frontend developerlar olarak bu akışın sonunda olduğumuz düşünülüyor, çünkü ihtiyaç veya sorun ortaya çıkıyor, bu probleme karşı yapılabilecek fikirler üretiliyor, tasarımlar yapılıyor ve sonrasında developer'a gelip, çıktı oluşturulup kullanıcılara sunuluyor. Fakat ilk bakışta gözden kaçırdığımız, ama bu akışı belirleyen en önemli unsur olan çıktıyı verecek olan bizler olduğu için bizlerin yetkinlikleri, müsaitlik durumu, işe katabildiğimiz fikirler, elimizdeki öncelikli işler gibi parametreler bu probleme çözüm üretmede göz ardı edilemeyecek kadar önemli oluyor. Çünkü bu noktaya kadar hızlı bir şekilde gelen iş, bizlerde takılıp sonuçlanmadıktan sonra pek bir işe yaramıyor. X biriminin ürettiği yeni bir ürünümüz var ve buna uygun bir panel yazılması gerekiyor diyelim. Burada en temel istek, bu panelin en geç ürünle birlikte sonlanması ve ihtiyaçları %100 karşılayacak şekilde tamamlanması. Bu istek bize ulaştıktan sonra, bu isteğe nasıl karşılık vereceğimiz, bununla ilgili konuşmalarımız, uygunluk ile ilgili verdiğimiz geri dönüşler vb tepkiler akışı etkileyebiliyor, belki bazı modüller için komple bir değişiklik ihtiyacı bile doğurabiliyor.
Biraz daha detaya inersek, bu isteğe karşılık verilmeden önce, frontend tarafı için tartışmaya başladığımız veya istek bize gelmeden üst yöneticilerimiz tarafından yürütülüyor ise, tartışmaya başlanan en temel olay ve ilk nokta, bu projenin nasıl yapılacağı, hangi framework ile, nasıl bir sistem üzerine inşa edilebileceği oluyor. Burada seçilebilecek ve son kullanıcı tarafında alacağı sonuç itibari ile benzer olan a, b ve c gibi seçenekler olduğunu düşünelim. Burada kararı verirken projede çalışabilecek developerların yetkinliği devreye giriyor. A ile yapılsa, bu proje için seçilen developerların yeterli olmadığı için öğrenme süreci ile 10 ay, b yöntemi ile yapılsa elimizde buna uygun 1 developer olduğu için 8 ay, c yöntemi ile yapılsa 2 developer'ın yetkinliği buna uygun olduğu için 3 ay gibi kısa bir sürede yapabiliriz bir sonuç çıktı diyelim. Burada hem işi sonuçlandırma, hem de maliyet anlamında bizlere uygun olan c seçeneği ile devam ediliyor.Bu ve bunun gibi konularda, top sürekli bizlere gelip, en uygun yol bulunduğu ve hem iş akışı hem de tasarımlar bu yönde ilerlediği için proje hem çok hızlı bir sürede, hem de nasıl ilerlenmesi gerektiği bilindiği için hatasız bir şekilde iş sonlanabiliyor.
Eğer burada konu böyle olmayıp, düz bir akışta ilerlenip; fikir oluşturuldu, tasarım bu, sizler bunu şöyle yapacaksınız denseydi, hem konuya hakimiyet eksikliği hem de uygun olmayan seçim ihtimaliyle isteklere 100% cevap verilemeyebilir, projenin sonlanması uzayabilir, maliyet olarak ön görülemeyen bir sonuca ulaşabilirdi.
Bu ve bunun gibi örnekleri çoğaltmak mümkün, ama temel olarak baktığımızda kullanıcıya gösterilecek olan her adımda karar verilirken, biz frontend developerların söylemleri, işi en hızlı ve en uygun şekilde sonlandırabilmek için büyük önem taşıyor.
