- Büyük ölçekli teknik projelerde motivasyonu korumak ve işi tamamlamak için günlük gözle görülür sonuçlar kritik önem taşır
- Projeyi büyük ve belirsiz parçalar yerine gözle görülebilen küçük parçalara ayırır, her aşamada somut ilerlemeyi doğrulayabileceğim yöntemleri seçerim
- İlk aşamada sıkı bir geri bildirim döngüsü ile hızlıca demo üretmek, odaklanma ve öz motivasyon açısından çok yardımcı olur
- Önce yalnızca kendim için gerekli olan özellikleri geliştirip, gerçek kullanım üzerinden sürekli iyileştirmek etkili bir yaklaşımdır
- Mükemmellikten çok ilerlemeyi önemserim; küçük başarı deneyimlerini tekrar tekrar yaşamak, uzun projeleri tamamlama gücü verir
Başlangıç noktasında
- Büyük ölçekli bir projeye başlarken en büyük eşik, nereden başlanacağına karar vermektir
- Tüm bileşenleri aynı anda düşünmek, işi fazla belirsiz hale getirir ve ilgiyi hızla azaltabilir
- Pratikte hızlı sonuç görülebilecek küçük birimlerle başlamak önemlidir
- Her alt proje bağımsız olmalı ve net bir tamamlanma işareti sunmalıdır
- Deneyim arttıkça projenin genel şeklini ve alt bileşenlerini daha iyi kavramak mümkün olur
Erken sonuç üretmek
- İlk çalışmaların dışarıdan görünen kısmı az olduğu için ilerleme görünmeyebilir
- Böyle durumlarda görünür sonuç üretmek için otomatik testleri (ör. birim testleri) uygun şekilde kullanmak önemlidir
- Örneğin bir terminal ayrıştırıcısı geliştirirken, girdi dizgelerine karşılık ayrıştırma sonuçlarını testlerle hemen doğrularım
- Tekrar tekrar testlerin geçtiğini görmek başlı başına bir başarı hissi verir
- Bu küçük başarılar sayesinde, projenin genel ilerleyişine dair nesnel kanıtlar biriktirmeye devam edebilirim
Hızlıca demo yapmak
- İlk hedef kusursuz bir alt bileşen değil, demo için yeterli bir uygulama oluşturmaktır
- Uzun vadede gerekecek karmaşıklıkları (ör. veritabanı, gelişmiş veri yapıları vb.) şimdilik erteler, basit bir uygulamayla hızlı ilerlemeyi önceliklendiririm
- 'Mükemmellik, ilerlemenin düşmanı olabilir' fikrini her zaman akılda tutarım
- Haftada bir ya da iki kez basit bir demo çıkarmayı hedeflerim
- Kusurlu bir demo bile doğrudan görülüp sezgisel geri bildirim sağlayabilir; bu da motivasyona büyük katkı yapar
Kendim için geliştirmek
- Özellikle kişisel projelerde, önce gerçekten ihtiyaç duyduğum özellikleri geliştirip bunları bizzat benimseyerek kullanma sürecini önemli bulurum
- Doğrudan kullanırken eksikleri hisseder, gerçekte gerekli olan özelliklere odaklanarak iyileştirir ve projeyi gerçek bir kullanıcı bakış açısından geliştiririm
- İlk kullanımda rahatsızlıklar veya hatalar ortaya çıkar, ama bunlar sırada ne yapılması gerektiğini netleştirir
- Kendi yazdığım yazılımı kullanmanın verdiği gurur, projeyi sürdürmeye yardımcı olur
- Başlangıçta gereksiz özelliklerin hepsini (kaydırma, fareyle seçim, sekmeler vb.) dışarıda bırakırım
Projenin tamamını paketleme yöntemi
- Bütün problemi, gözle görülebilen küçük problemlere ayırırım. Her problem, somut bir sonucun doğrulanmasına izin vermelidir
- Her küçük problem yalnızca demo üretmek için yeterli düzeye kadar çözülür, sonra bir sonrakine geçilir
- Mümkün olduğunca erken çalışan bir demo yapılır, ardından özellikler yinelemeli olarak eklenir
- Öncelik, kendi kullanımım açısından anlamlı olan özellikleri geliştirmektir
- Gerektiğinde her bileşen tekrar tekrar iyileştirilir ve bu döngü sürdürülür
Sonuç
- Bu yaklaşım sayesinde kişisel, grup, iş ve akademik projeler dahil çeşitli projelerde kendimi motive ederek işi tamamlayabildim
- Odak, dağıtım veya tooling'den çok, hangi çalışma biçiminin sürdürülebilir motivasyon sağladığı üzerinedir
- Her yöntem herkese uymaz, ancak gözle görülür ilerleme sonuçları uzun soluklu projeleri tamamlarken en büyük güçtür
- Kişinin kendi ilgi ve motivasyon yapısını anlayıp buna uygun bir çalışma süreci kurması önemlidir
1 yorum
Hacker News yorumu
Yazıda öne sürülen tüm fikirlere katılıyorum ve bir şey eklemek istiyorum: hızlı geri bildirim döngülerinin önemi
Bir değişiklik yapıp sonucunu hemen görebilmek gerçekten motive edici
Kodla oyuncu gibi oynayıp etkisini gözlemlediğinizde, birçok sorunun ya ortadan kalktığını ya da kolayca çözülebilecek bir hâle geldiğini deneyimliyorsunuz
Büyük projelerde, kurulumun ve çalıştırmanın ne kadar kolay olduğu ile projedeki sorunların miktarı (bug’lar, teslim tarihlerini kaçırma vb.) arasında kesin bir ilişki vardı
Inventing on Principalkonuşmasını tavsiye ederimBu konuşma geri bildirim döngülerinden bahsediyor
YouTube bağlantısı
Bulduğum bug’lar için e2e test uygulayıp gerçekten düzelip düzelmediklerini doğrulamayı düşünüyorum
Bir şeyi denemek ya da düzeltmek istediğinizde, sadece kurulumun kendisi saatler sürüyorsa hevesiniz kaçıyor ve sonunda ertelemeye başlıyorsunuz
Bu yüzden lisp gibi kullanılabilir bir REPL’i olan dilleri seviyorum
Sonucu anında görebilmenin getirdiği bir tür anlık tatmin var
Motivasyonu kaybettiğiniz anda proje buharlaşıyor
Bu yüzden geliştirme sürecinin keyifli bir deneyim olmasını sağlamak neredeyse en önemli unsur
Bence deneyim bazen tersine engel oluyor
Kıdemli mühendislerin mükemmel bir şey yapmak için çok derine indiklerini ama demo zamanı geldiğinde ortaya çıkan sonucun pek iyi olmadığını sık sık görüyorum
Uygulama iyi yapılmış olsa bile, özellik ya da ürünün kendisi tamamen zayıf olabiliyor
Bazen beynimi kapatıp özensiz kodu öylece yazmak istiyorum
Eskiden çok sayıda eğlencelik proje yapardım ve tüm kaynak kodunu tek dosyaya yığdığım da olurdu
Modülerliği hiç umursamasam da eğlenceliydi ve çalışıyordu
Ama artık böyle eğlencelik bir projeyi bile tamamlamak gerçekten zorlaştı
second system problemdenilen şey mi deniyor?Sanırım bir kez yapmış olmanın getirdiği, gereksiz tüm ek özellikleri de koyma eğiliminden kaynaklanıyor
Mesela Advent of Code gibi kodlama meydan okumalarına katıldığınızda, ilk problemler basit oluyor ve ancak sonlara doğru optimizasyon ya da karmaşık algoritmalar gerekiyor
Ya da pico-8 gibi kısıtlı ortamlarda uzun süre kod yazmak zaten mümkün olmuyor
Veya hackathon ya da game jam gibi zaman kısıtlı ortamlarda denemek de yardımcı olabilir
Çünkü daha az deneyimli insanlar, eski dillerde bıktıkları tüm “best practice”leri unutup daha özgürce deneme yapabiliyor
DB tablolarını kendim tasarlıyorum, uygulama kısmını ise biraz daha serbest biçimde LLM’ye bırakıyorum
İlk alt projelerin amacının “tamamlanmış bir alt bileşen” yapmak değil, bir sonraki adıma geçmeye yetecek kadar “yeterince iyi” bir alt bileşen yapmak olması dikkatimi çekti
Bu yaklaşımı uygulamak için bir şeyleri “atlamak” gerektiğini fark ettim
Başkaları bu modda kod modülerliğini göz ardı ettiklerini söylemiş ama ben kodu düzenli tutmanın bana daha çok tatmin ve motivasyon verdiğini düşünüyorum
Bu yüzden ben algoritmalar, veri yapıları ve performans gibi tarafları “atlayacağım”
Sonuçta asıl nokta şu: evet, kesinlikle bir şeyleri atlamanız gerekiyor, ama o şey size motivasyon veren bir unsur ise onu atlamamalısınız
Demo, yazılım geliştirme (programlama) ile bunu yazıyla anlatma (dokümantasyon) arasında bir ara basamak görevi görüyor
Demo sayesinde, projemin ne yapması gerektiğine dair kendi hipotezlerimi sürekli test edebiliyorum ve bu bir tür geri bildirim mekanizması oluyor
Demo kalıcı oluyor; bir özelliği bozduğumda bunu hemen fark edip düzeltmeye yönelik yinelemeli döngüyü sürdürebiliyorum
Kendi geliştirdiğim oyun motorunda bu şekilde çalışıyorum
Demo örneği GitHub bağlantısı
Keşke bu yaklaşım sağduyu hâline gelse
Daha çok kişisel projelere odaklanıyor gibi geldi
Ben, büyük teknik ekip projelerinde herkesin tek bir hedefe doğru çalışmasını ve işlerin gerçekten düzgün şekilde tamamlanmasını sağlayan iyi yöntemleri merak ediyorum
Yaklaşık 15 yıldır çalışıyorum; bütçeyi aşmayan, takvimi sarkmayan, özellikleri eksik kalmayan ve tükenmişlik yaratmayan bir teknik proje görmedim
Öte yandan, bu tür büyük projeleri gerçekten başarılı biçimde yöneten örnekler varsa, ek okuma bağlantıları ya da öneriler paylaşılırsa güzel olur
Bütçe aşımı, gerçekten para tamamen bitmediği sürece çok yaygın bir durum
Çoğu zaman sadece birilerinin tahmininin yanlış çıkmasından yakınılmış oluyor
Takvimin sarkması da benzer şekilde, gerçekten uyulması zorunlu bir teslim tarihi yoksa ciddi bir sorun değil
Aslında büyük tanıtım kampanyaları gibi takvime bağlı etkinlikleri, proje neredeyse tamamlanana kadar planlamamak daha iyi
Özelliklerin eksik kalması da sonuçta beklenti meselesi
Asıl sorun, insanların tamamen tükenip burnout yaşaması
En azından kesinlikle kaçınılması gereken şey bu
Kişisel olarak Scaled Agile Framework’e giderek daha fazla ısınıyorum
Bunu bir framework olarak, yani duruma göre uyarlanan bir tür “iskelet” gibi kullanıyorum
Bu sayede daha derin birincil kaynakları inceleyip kendi sonuçlarıma varabildim
Gerçek başarının, “Bunu neden yapıyoruz?” sorusunu net biçimde anlamakla başladığını öğrendim
Hedef net değilse ne önceliklendirme yapabilirsiniz ne de nereden başlayacağınızı bilebilirsiniz
Bu netlik, “neyi ne zaman yapacağımıza” çok daha fazla yardımcı oluyor ve bazen “hiç yapmama kararı” almayı bile mümkün kılıyor
Ondan sonraki önemli şey ise empati
Müşterinin bakış açısından, onların sorununu tam anlamıyla anlayıp bir çözüm sunmanız gerekiyor
Bu, müşterinin istediği her şeyi aynen yapmak değil; temel acı noktasını doğru anlayıp gerçekten değerli olanı sunmak demek
Projelerin çoğunun başarısız olmasının asıl nedeni, ekiplerin “yanlış şeyi” üretmek için fazla zaman harcaması
Eğer sürekli olarak ihtiyaç duyulan, insanların gerçekten istediği ya da para ödemeye değer bulduğu özelliklere odaklanırsanız, çok daha fazla proje başarıyla tamamlanır
Büyük projelere bakıp analiz felcine kapılan gerçekten çok insan var
Gerçekten zor olan bitirmek
Build for Yourselfbölümü dikkatimi çektiKendi kullanacağınız bir yazılım yaparsanız, kendi probleminizi kendiniz çözebilirsiniz
Yazılımı bizzat kullanırken bug’ları da kendiniz keşfedebilirsiniz
Nitekim kendi web sunucumu yapıp kullanırken birçok bug bulmuştum
Odaklı, yinelemeli ve her zaman çalışan çıktılar üretmeyi amaçlayan bir geliştirme kültürü