Teknik Olmayan Bir Kurucu Olarak Yazılım Geliştirme Projesi Nasıl Yönetilir

Birlikte çalıştığımız teknik olmayan kurucuların büyük çoğunluğu, bir yazılım geliştirme projesini yönetirken iki tuzaktan birine düşmektedir. Birincisi aşırı yönetim (mikroyönetim) — her günlük toplantıya katılmak, değerlendirme bağlamına sahip olunmayan teknik kararları sorgulamak ve geliştiricilere gece yarısı Slack mesajları yağdırmak. İkincisi ise tam tersi: tüm sorumluluğu delege etmek, ekibin üstesinden geldiğine güvenmek ve yalnızca bir şeyler açıkça ters gittiğinde — çoğunlukla olması gerekenden aylarca ve ciddi bir bütçe kaybından sonra — ortaya çıkmak.

Her iki uç da sonuçlara zarar verir. Aşırı yönetim, geliştirici özerkliğini zayıflatır, hızı düşürür ve ekibin sorunları çözmek yerine onay bekleyen bir kültür oluşturmasına neden olur. İlgisizlik ise uyumsuzluğun sessizce birikmesine izin verir. Durum görünür hale geldiğinde, düzeltme maliyeti iki sprint önce fark edilmiş olsaydı ödeneceğin çok üzerindedir.

Orta yol, yapılandırılmış bir denetimdir. Bu; tek bir satır kod okumanızı gerektirmez. Rolünüz konusunda netlik, güvenilir bir iletişim ritmi ve doğru zamanlarda doğru soruları sorma disiplini gerektirir. Bu rehber, teslim ettiğimiz projelerden ve kurtarmaya çağrıldığımız projelerden derlendi. Burada tanımladığımız örüntüler, iyi giden katılımları iyi gitmeyenlerden ayıran şeylerdir.

---

Müşteri Olarak Rolünüz

İlk ve en önemli zihinsel dönüşüm, işinizin gerçekte ne olduğunu anlamaktır. Siz ürün sahibisiniz, alan uzmanısınız ve neyin neden inşa edileceğine dair nihai karar vericisiniz. Kod inceleyici değilsiniz. Mimar değilsiniz. Proje yöneticisi de değilsiniz.

Sizin işiniz; kullanıcıyı ve işletmeyi temsil etmektir. Geliştirme ekibinin işi ise bunu çalışan yazılıma dönüştürmektir. Bu roller bulanıklaştığında her iki taraf da zarar görür.

Yazılım geliştirmede iyi bir müşteri olmak şu anlama gelir.

Ekibin ihtiyaç duyduğu zamanlarda net ve zamanında kararlar alırsınız. Belirsizlik, yazılım geliştirmenin en maliyetli unsurlarından biridir. Bir geliştirici, bir gereksinimi netleştirmesi için paydaşın iki gün beklemesi gerektiğinde, bu kaybedilen bir günlük ivme ve sessizce dağılan bir sprint planı anlamına gelir. Sizin işiniz, belirsizliği proaktif olarak azaltmak ve ortaya çıktığında hızla gidermektir.

Uygulamaları değil, çıktıları tanımlarsınız. Ekibe kodun nasıl çalışması gerektiğini değil, kullanıcının ne yapabilmesi gerektiğini ve neden buna ihtiyaç duyulduğunu anlatın. "Kullanıcıların hesap oluşturmadan randevu alabilmesi gerekiyor" iyi bir brifingdir. "Yerel depolama alanında oturum çerezi saklayan bir misafir ödeme akışı oluşturun" ise değildir — teknik bir geçmişiniz olmadıkça ve ekibiyle bu düzeyde katkıda bulunacağınızı özellikle kararlaştırmadıkça.

Kendi fikirlerinizden kaynaklanan kapsam kayması da dahil olmak üzere ekibi kapsam kaymasından korursunuz. Proje ortasında gelen iyi fikirler tehlikelidir. Bunu ilerleyen bölümlerde ayrıntılı ele alacağız.

Önemli temas noktalarında hazır bulunur, gerekli olmayanlardan uzak durursunuz. Bir sprint değerlendirmesi, varlığınızı ve geri bildiriminizi gerektirir. Bir geliştiricinin üç saatlik render sorununu ayıklaması ise sizin katkınızı gerektirmez.

---

Doğru İletişim Ritmi

Yazılım projelerinde en yaygın başarısızlık noktalarından biri teknik değil, iletişimseldir. Ekipler ve müşteriler birbirinden farklı ilerleme tabloları oluşturur ve mesele ciddileşene dek her iki tarafın da boşluğu ortaya çıkarmak için güvenilir bir mekanizması yoktur.

Çözüm, proje boyunca sürdürmek için yeterince hafif ve sorunları gerçekten yakalamak için yeterince sağlam olan yapılandırılmış bir ritmdir.

Sprint Değerlendirmeleri

Sprint değerlendirmeleri, sahip olduğunuz en önemli temas noktasıdır. Bir sprint, genellikle iki haftalık bir geliştirme çalışması döngüsüdür. Her sprintin sonunda ekip, planladıklarına karşılık inşa ettiklerini sunar. Ürün sahibi olarak sizin işiniz; katılmak, etkileşimde bulunmak, sorular sormak ve onaylamak — ya da endişelerinizi dile getirmektir.

Bir sprint değerlendirmesine katıldığınızda üç şeyi değerlendirirsiniz: planlanan çalışmanın teslim edilip edilmediğini, teslim edilenin anladığınız şekliyle gereksinimi gerçekten karşılayıp karşılamadığını ve bir sonraki sprint başlamadan önce çözülmesi gereken açık sorular olup olmadığını.

Sprint için belirlenen kapsamın listesiyle hazırlıklı gelin. Kanıt olarak ekibin sunumun sözlü özetini değil, sunumun kendisini kullanın.

Günlük Standup Toplantıları

Günlük standup toplantılarına genel olarak katılmamalısınız. Bunlar — tipik olarak on beş dakikalık — kilitlenmeleri ortaya çıkarmak ve ekip içi çalışmayı koordine etmek için tasarlanmış kısa iç senkronizasyon toplantılarıdır. Bir kurucunun varlığı dinamiği değiştirir: geliştiriciler sorun çözme modundan raporlama moduna geçer ve toplantı işlevini yitirir.

Proje yöneticisinden yazılı güncellemeler alıyorsanız standup toplantısına ihtiyacınız yoktur. Proje yöneticisi yoksa ve ekip küçükse, her günün sonunda Slack veya proje araçlarınız aracılığıyla kısa bir yazılı güncelleme, standup toplantısına katılmaktan daha iyi bir mekanizmadır.

Yazılı Güncellemeler

Birinci günden itibaren yazılı güncelleme ritmi oluşturun. Genellikle; tamamlananları, devam edenleri, bloke edilenleri ve gelecek hafta için planlanmış olanları kapsayan haftalık yazılı ilerleme özetlerini öneririz. Yazılı güncellemeler bir kayıt oluşturur. Hesap verebilirliği görünür kılar. Ve bunları yazan kişiyi durumu net biçimde özetlemeye zorlar — bu da çoğu zaman aksi takdirde dile getirilmeyecek sorunları yüzeye çıkarır.

Ne Zaman Üst Makama Bildirmelisiniz

Net bir çözüm yolu olmaksızın bir kilitlenme 48 saatten uzun süre açık kaldığında üst makama bildirin. Kapsam veya zaman çizelgeleri açık onayınız olmadan revize edildiğinde üst makama bildirin. Yazılı güncellemeler gelmeyi bıraktığında veya muğlak hale geldiğinde üst makama bildirin. Bunlar küçük iletişim sürtüşme noktaları değildir — daha büyük sorunların erken göstergeleridir.

---

Kod Anlamamadan İlerlemeyi Nasıl Değerlendirirsiniz

Bir sprintin kararlaştırılanları teslim edip etmediğini değerlendirmek için kodu anlamanız gerekmez. İşte bunu etkili biçimde nasıl yapacağınız.

Demo tabanlı incelemeyi birincil değerlendirme yönteminiz olarak kullanın. Test ortamında çalışan bir demo — özelliği gerçekten tıklayabildiğiniz, uç durumları test edebildiğiniz ve sistemin sınırlarını zorlayabildiğiniz bir ortamda — geliştirilen şeyin geliştirici tarafından tanımlanmasından veya bir ekran görüntüsünden sonsuz kez daha güvenilirdir. Ekip size tamamlanmış bir özelliğin çalışan bir demosunu gösteremiyorsa, o özellik tamamlanmamış demektir.

Geliştirme başlamadan önce kabul kriterlerini yazın. Her özellik için, tek bir satır kod yazılmadan önce "tamamlandı" ifadesinin ne anlama geldiğini yazılı olarak mutabık kalın. Kabul kriterleri sade bir dille yazılmalıdır: "Kullanıcı iletişim formunu gönderebilir ve 60 saniye içinde onay e-postası alabilir." Özellik teslim edildiğinde, kabul kriterlerini kendiniz test edin. Bu aşırı yönetim değildir — ürün sahibi olarak sorumluluğunuzdaki temel kalite güvencesidir.

Kendi ürününüzü her sprintte test edin. Bu, teknik olmayan bir kurucunun kullanabileceği en az kullanılan araçtır. Bir test ortamı URL'sini açmak ve ürünü bir kullanıcı gibi kullanmaya çalışmak için teknik bilgiye ihtiyacınız yoktur. Ürünün ne yapması gerektiğini bildiğiniz için UX sorunlarını, bozuk akışları ve eksik içerikleri herhangi bir kalite güvence sürecinden daha hızlı fark edersiniz. Bunu bir alışkanlık haline getirin, istisna değil.

---

Her Sprint'te Sorulması Gereken Sorular

Yapısız bir standart sprint değerlendirmesi, bir demo ve hızlı bir "iyi görünüyor" haline dönüşür. Bu sorular bunu önler.

• İlerleme ile plana karşı: Bu sprint için ne kapsama alındı ve gerçekte ne teslim edildi? Tamamlanmayan bir şey varsa açıklama nedir?
• Kilitlenmeler: Bu sprintte ekibi ne yavaşlattı? Bu kilitlenmelerden herhangi biri bir sonraki sprinte açık şekilde giriyor mu?
• Riskler: Bu sprintte ilerleyen dönemde sorun yaratabilecek teknik kararlar alındı mı? Henüz doğrulanmamış harici bağımlılıklar — API'ler, üçüncü taraf hizmetler, altyapı — var mı?
• Sırada ne var: Bir sonraki sprint için ne kapsama alındı? Ekip bu tahminlere güveniyor mu, yoksa önce çözülmesi gereken açık sorular var mı?
• Kararlaştırılandan ne değişti: Herhangi bir gereksinim yazıldığından farklı yorumlandı mı? Daha sonra yeniden ele alınması gereken kısayollar kullanıldı mı? Ekibin ele almak için bir planı olan birikmiş teknik borç var mı?

Bu soruları her sprintte tutarlı biçimde sorun. Cevapları yazın. Daha sonra bir şeyler ters gittiğinde paha biçilmez olan bir proje anlatısı oluştururlar.

---

Kapsam Kaymasını Yönetme

Kapsam kayması yalnızca geliştirme ekibinizden kaynaklanmaz. Deneyimlerimize göre, kapsam kaymasının önemli bir kısmı müşteriden kaynaklanır — proje ortasında ortaya çıkan yeni fikirlerden, ilk demo görüldükten sonra genişleyen gereksinimlerden ve küçük görünen ancak önemli gecikmelere dönüşen iyi niyetli eklemelerden.

En önemli kural: kapsama yapılan her değişiklik, ne kadar küçük görünürse görünsün, sözleşmeye yapılan bir değişikliktir. Formdaki yeni bir alan, ek bir e-posta bildirimi, biraz farklı bir kullanıcı akışı — bunların her biri zamanda ve çoğu zaman karmaşıklıkta bir maliyete sahiptir. Birden fazla küçük değişiklik bir projede biriktiğinde, sonuç sessizce iki katına çıkmış bir zaman çizelgesi ve teslim baskısı altındaki bir ekip olur.

Başlangıçtan itibaren resmi bir değişiklik talep süreci oluşturun. Yeni bir fikir ortaya çıktığında — ve çıkacaktır — bunu bir toplantıda dile getirmek veya doğrudan bir geliştiriciye mesaj atmak yerine yazıya dökün. Fikir yapılandırılmış bir değerlendirmeden geçer: efor açısından maliyeti nedir? Zaman çizelgesini etkiliyor mu? Halihazırda inşa edilmiş bir şeyi etkiliyor mu? Yalnızca bu değerlendirmeden sonra onaylanmalı veya lansman sonrası bir iterasyona ertelenmelidir.

Proje ortasında kendi fikirlerinize hayır demenin disiplini gerçekten güçtür. Bu, fikrin kalitesini zamanlamanın uygunluğundan ayırmayı gerektirir. Bir projede yanlış noktada gelen iyi bir fikir, kötü bir karardır. Lansman sonrası iyileştirmeler için bir birikim listesi oluşturun ve fikirleri aktif sprint'e değil, oraya taşıyın.

---

Projenin Sorunlu Olduğunu Gösteren Uyarı İşaretleri

Bunlar, ciddi sorunlara doğru ilerleyen projelerde en sık gördüğümüz örüntülerdir. Bunlardan herhangi birini gözlemlerseniz, bunu bir sonraki sprint değerlendirmesinde değil, hemen harekete geçmeniz için bir işaret olarak kabul edin.

• Dört hafta sonra çalışan demo yok. Makul ölçüde kapsamlanmış herhangi bir katılımda, dört hafta içinde — tamamlanmamış olsa bile — gösterilebilecek bir şey olmalıdır. Ekip kod üretiyorsa ancak görünür ya da test edilebilir hiçbir şey yoksa, projede teslim etmesi için gereken disiplin eksiktir.
• "Neredeyse tamamlandı" ifadesi iki haftadan uzun sürüyor. Neredeyse tamamlanmış özellikler günler içinde tamamlanmalıdır. Bir iş parçası iki ya da üç hafta boyunca yüzde doksanda bekliyorsa, bu genellikle ya yüzeye çıkarılmayan bir teknik sorunu ya da kabul ettiklerinden daha fazla bağlam değiştiren bir ekibi işaret eder.
• Belirli sorulardan kaçınma. Doğrudan sorular — "Tamamlanan özelliği test ortamında gösterebilir misiniz?" veya "API entegrasyonunu özellikle ne engelliyor?" — doğrudan yanıtlar yerine muğlak güvencelerle karşılandığında, bu ciddi bir uyarı işaretidir.
• Test ortamı yok. Test ortamı isteğe bağlı değildir. Ekip, geliştirmenin ilk iki ila üç haftası içinde bir test ortamı oluşturmadıysa, hiçbir şeyi güvenli biçimde test etme yolunuz yoktur ve ekibin kendi çalışmalarını üretime ulaşmadan önce doğrulama yolu yoktur.
• Test "sonra" için planlanmış. Projenin sonuna ertelenen test, test değil — umuttur. Kalite güvencesinin sürekli gerçekleşmesi gerekir. Ekip son sprint'e kadar test uygulaması yerleştirmediyse, son sprint kaosa dönüşecektir.

---

Bütçe ve Harcama Takibi

Zaman ve malzeme (T&M) sözleşmelerinde, bütçe yönetimi pasif değil, aktif bir sorumluluktur. Ekibin size bütçenin ne zaman tükendiğini söylemesini bekleyemezsiniz — o noktada sınırlı seçenekleriniz vardır.

Başından itibaren haftalık harcama raporu oluşturun. Bu rapor en azından; ayrılan bütçeye karşılık her ekip üyesinin kaydettiği saatleri ve mevcut harcama hızında mevcut bütçenin ne zaman tükeneceğine dair basit bir projeksiyon göstermelidir. Bu, karmaşık araçlar gerektirmez — haftalık güncellenen paylaşımlı bir elektronik tablo yeterlidir.

Bütçe görüşmesini acil hale gelmeden önce yapın. Harcama hızı aşımına gidildiğini gösteriyorsa, iki ila üç günlük değil, iki ila üç haftalık hareket alanınız kaldığında bunu gündeme getirin. Kapsam azaltma veya aşamalama hakkındaki erken görüşmeler size gerçek seçenekler sunar. Geç yapılan görüşmeler acil kararlar doğurur.

Aşımlar yaşandığında, ilk soru her zaman şudur: Sapmayı açıklayan, orijinal kapsamdan ne değişti? Kapsam sıkı biçimde kontrol edildiyse ve aşım düşük tahminlemeden kaynaklanıyorsa, bu tahmin doğruluğu ve orijinal teklifin gerçekçi olup olmadığı üzerine bir görüşmedir. Kapsam genişlediyse ve aşım bu genişlemeyi yansıtıyorsa, hesap verebilirlik değişiklik yönetim sürecindedir. Hangi kategoride olduğunuzu anlamak, nasıl yanıt vereceğinizi belirler.

---

Her Zaman Sahip Olmanız Gereken Belgeler

Geliştirme ekibinize ne kadar güvendiğinizden bağımsız olarak, proje boyunca kontrolünü sürdürmeniz gereken birkaç belge ve erişim vardır.

Bir gereksinimler belgesi — inşa edilmesi kararlaştırılanı sade bir dille kaydeder. Bunun resmi bir şartname belgesi olması gerekmez — kabul kriterleriyle birlikte yapılandırılmış bir kullanıcı hikayeleri seti yeterlidir. Bu, her sprint değerlendirmesi için referans noktanızdır.

Test ortamına erişim. Ekipten talep etmeksizin istediğiniz zaman test ortamına giriş yapabilmeli ve ürünü test edebilmelisiniz. Her test yapmak istediğinizde erişim talep etmeniz gerekiyorsa, süreç doğal olarak daha az sıklıkta test yapmanıza neden olacaktır.

Kod deposuna erişim. Kodu okuyamasanız bile, kod tabanının bulunduğu Git deposuna erişiminiz olmalıdır. Bu sizin fikri mülkiyetinizdir. Buna erişim, geliştirme ekibiyle ilişkinizin durumuna bağlı olmamalıdır.

Dağıtım belgeleri. Uygulama nasıl dağıtılıyor? Hangi sunucular, bulut hizmetleri veya barındırma platformları kullanılıyor? Kimlik bilgileri neler? Hesapların sahibi kim? Bu bilgiler, projeyi devretmeniz veya yeni bir ekip getirmeniz gerektiğinde kritik hale gelir. Projenin sonuna bu bilgileri yazılı olarak almadan asla ulaşmayın.

---

Geliştirme Ekibinizle Çatışmayı Nasıl Yönetirsiniz

Yazılım projelerinde çatışma normaldir. Soru, bunun ortaya çıkıp çıkmayacağı değil, çıktığında nasıl ele alındığıdır.

Üst makama bildirin — ekip, net bir açıklama olmaksızın taahhüt edilen teslimatları sürekli olarak kaçırıyorsa, endişeleriniz somut bir ilgi gösterilmeksizin göz ardı ediliyorsa veya yukarıdaki uyarı işaretleri bölümündeki örüntüleri gözlemliyorsanız. Üst makama bildirmek, yalnızca proje yöneticisi veya baş geliştiriciye değil, ajansın yönetimine, belgelenmiş endişelerinizi açıkça belirterek yapılan resmi bir görüşme anlamına gelir.

Uzlaşın — anlaşmazlık çıktılar yerine yaklaşımla ilgiliyse. Ekip, emin olmadığınız bir teknik karar öneriyorsa, doğru yanıt onları geçersiz kılmak değil, gerekçeyi ve değiş tokuşları açıklamalarını istemektir. Alan uzmanlığınızın ve onların teknik uzmanlığının birlikte çalışması gerekir. Yaklaşım konusunda uzlaşma sağlıklıdır. Taahhütler konusunda uzlaşma değildir.

Ayrılın — yalnızca güven onarılamaz biçimde kırıldığında ve devam eden katılımın yeni bir ekiple yeniden başlamaktan daha kötü sonuçlar doğuracağı durumlarda. Bu, gerçek maliyetleri olan ciddi bir karardır — geçiş süresi, yeni ekibin dahil edilmesi, mevcut kod tabanı üzerinde olası anlaşmazlıklar. Önce tüm üst bildiri seçeneklerini tüketin. Ancak ekip ilerleme konusunda sürekli dürüst değilse, çalışan yazılım teslim etmiyorsa ve endişelerinizle yapıcı biçimde ilgilenmiyorsa, katılımı sürdürmek bir erdem değildir — kapanmayacak bir maliyet merkezidir.

Ekip geçişi yaptığınızda, bunu temiz bir şekilde yapın: ilişki resmen sona ermeden önce kod tabanına, belgelere ve tüm kimlik bilgilerine sahip olduğunuzdan emin olun.

---

Sıkça Sorulan Sorular

Bir yazılım projesini etkin biçimde yönetmek için teknik bir kurucu ortağa veya CTO'ya ihtiyacım var mı?

Zorunlu değil. Bu rehberde açıklanan çerçeve, harici bir geliştirme ekibiyle çalışan teknik olmayan kurucular için tasarlanmıştır. İhtiyacınız olan şey; rolünüz konusunda netlik, güvenilir bir iletişim yapısı ve ekibi kararlaştırılan taahhütlere bağlı tutma disiplinidir. Mimari kararları gözden geçirebilecek ve ekibin çıktılarını kalite kontrol edebilecek bir teknik danışman değerlidir — ancak bir geliştirme katılımını iyi yönetmek için tam zamanlı bir CTO ön koşul değildir.

Teknik bilgi olmadan bir sprint tahmininin makul olup olmadığını nasıl anlarım?

Ekipten tahmini bireysel görevlere bölmelerini ve her görevin ne gerektirdiğini sade bir dille açıklamalarını isteyin. Saatleri kendiniz değerlendirmeniz gerekmiyor — kapsamı anlamanız yeterlidir. Ekip, neyi inşa edeceklerini takip edebileceğiniz bir dilde açıklayamıyorsa, tahmin taahhüt verecek kadar iyi biçimlendirilmemiş demektir. Zaman içinde sprint'ler arasındaki tahminleri karşılaştırın — benzer özellikler tahmini eforda sürekli büyük farklılıklar gösteriyorsa, nedenini sorun.

Proje ciddi ölçüde bütçeyi aşarsa ne olur?

Önce, aşımın kapsam genişlemesine mi, düşük tahminlemeye mi yoksa verimsizliğe mi atfedilebileceğini belirleyin. Kapsam onayınızla genişlediyse, bu maliyetin bir kısmına siz sahip çıkarsınız. Orijinal tahmin önemli ölçüde yanlışsa, bu orijinal teklifin güvenilirliği üzerine bir görüşmedir. Çoğu durumda doğru yol yapılandırılmış bir sıfırlamadır: neyin inşa edildiğini belgeleyin, kalanı yeniden kapsama alın ve devam etmeden önce revize edilmiş bir bütçe ve zaman çizelgesi üzerinde anlaşın — tanımsız bir temelde devam etmek ve nihai sayıyı yalnızca sonunda öğrenmek yerine.

Tasarım ve UX kararlarında ne kadar yer almalıyım?

Tasarım ve UX kararlarında yoğun biçimde yer almalısınız — bu, kullanıcılarınızı ve işletmenizi anlayan biri olarak alan uzmanlığınızın tam olarak içindedir. Bir ödeme akışının sezgisel olup olmadığı, içeriğin net olup olmadığı ve bilgi mimarisinin kullanıcılarınızın düşünce biçimini yansıtıp yansıtmadığı konusundaki görüşünüz, veritabanı şema tasarımı hakkındaki görüşünüzden çok daha alakalıdır. Tasarım incelemelerine yakından katılın. Ürünün görsel ve deneyimsel katmanı, katkınızın en yüksek değere ve teknik aksaklığa en düşük risk taşıdığı yerdir.

---

Teknik olmayan bir kurucu olarak bir yazılım geliştirme projesini yönetmek, kod yazmayı öğrenmek veya proje yönetimi teorisinde ustalaşmak değildir. Doğru temas noktalarında hazır bulunmak, doğru soruları sormak ve hem ekibinizi hem de kendinizi başlangıçta yapılan taahhütlere bağlı tutma disiplinini sürdürmekle ilgilidir.

Bir yazılım projesi planlıyorsanız ve teknik olmayan kuruculara ihtiyaç duydukları görünürlüğü ve kontrolü sağlamak için katılımlarımızı nasıl yapılandırdığımızı anlamak istiyorsanız — ekibi yavaşlatmadan — bizimle iletişime geçin. Herhangi bir taahhütte bulunmadan önce sürecimizi size anlatmaktan memnuniyet duyarız.