Yarım kalmış yazılım projesini kime devredersiniz? Beş seçenek, on iki soru ve puanlama tablosu

Yarım kalmış projeyi devralabilecek beş tür taraf

Yarım kalmış bir yazılım projesini beş tür taraf devralabilir. Hangisinin doğru olduğu, projenin neden durduğuna, ne kadarını kendinizin yönetebileceğine ve sonradan neyi kanıtlayabilmeniz gerektiğine bağlıdır:

1. Önceki ekip, yeni bir yazılı kapsamla.
2. Yeni bir yazılım şirketi: önce değerlendirir, sonra devam eder ya da yeniden yazar.
3. Bağımsız bir geliştirici: sınırlı bir iş ya da ikinci bir görüş için.
4. Kendi işe aldığınız kişi: ürün yıllarca gelişecekse ve mühendisleri yönetebiliyorsanız.
5. Ayrım: değerlendirmeyi bir taraf yazar, işi başka bir taraf yapar.

Bunların hiçbiri genel olarak doğru değildir. Aşağıdaki tablo her birinin ne zaman uygun düştüğünü ve neyi riske attığını gösteriyor. Hücreler bilerek nitel tutuldu; gerçek cevap, sizin projenize ait ve hiçbir yazının göremeyeceği olgulara bağlı.

Biz de bir yazılım şirketiyiz; bu yazıyı hangi satırı seçerseniz seçin, biz olmayanlar dahil, işe yarayacak biçimde yazdık. Yarım kalmış bir yapım işini bu satırlarla tartıyorsanız, değerlendirmeyi nasıl yaptığımız yazılım danışmanlığı ve modernizasyon sayfamızda; kodun kendisinin nasıl yargılanacağı yarım kalmış yazılım projesi nasıl devralınır rehberimizde anlatılıyor.

Her seçenekte ilk sorulacak soru

Hangi satıra yakın olursanız olun, bir soru çoğu zaman o seçeneğin dayanıp dayanmayacağını çabuk gösterir.

• Önceki ekip. "Bitirmek için yazılı olarak neye ihtiyacınız var ve bu sefer ne farklı?" Cevap yalnızca "daha fazla zaman" ise durma nedeni yerinde duruyor demektir. Erişim listesini bir iyilik olarak değil, devam etmenin koşulu olarak isteyin.
• Yeni bir yazılım şirketi. "Değerlendirmeyi kim yazıyor ve sizi işe almazsam onun akıbeti ne olur?" Yalnızca yazanına yarayan bir değerlendirme bir satış adımıdır; başka bir ekibin de kullanabildiği bir değerlendirme ise bir teslimattır.
• Bağımsız bir geliştirici. "Siz ulaşılamazsanız işi kim üstlenir, notlarınız nerede duruyor?" Her şeyin tek kişide olması sınırlı bir iş için işler, süregelen bir iş için kırılgandır.
• Kendi işe aldığınız kişi. "Bu kişinin devralacağı kodu kim yargılayacak?" Yeni bir mühendisin ilk haftaları, kimsenin teminat veremediği kodu savunmakla ya da şüphe etmekle geçer; dışarıdan bir okuma ona bir başlangıç noktası verir.
• Değerlendirici, sonra yapan. "Rapor neyi içermeli ki yapan baştan yapmadan başlayabilsin?" Devralma rehberindeki rapor iskeleti makul bir başlangıç listesidir.

Birini seçmeden önce yapılacak iki iş

Erişimleri kendi elinize alın. Seçtiğiniz tarafın hiçbir şeyin tek kopyasını elinde tutması gerekmemeli. Devralma rehberimizdeki ilk 48 saat listesi kod deposunu, barındırmayı, alan adını, veritabanını, mağaza ve üçüncü taraf hesaplarını kapsıyor; önce onu yapın, yeni tarafla sözleşme yapmayı beklemeyin. GitHub belgelerinden iki ayrıntı burada işe yarar. Kurum sahipleri kurum üzerinde tam yönetim yetkisine sahiptir ve GitHub, sahip sayısını az tutmayı ama hiçbir zaman ikinin altına düşürmemeyi önerir (GitHub). Bir depo devredildiğinde webhook'ları, gizli anahtarları ve dağıtım anahtarları depoyla ilişkili kalır ve özgün sahip ortak çalışan olarak eklenir (GitHub); bu, yedeği aldıktan sonra eski ekibin bildiği her anahtarı döndürmek ve kimin hâlâ ortak çalışan olduğunu gözden geçirmek için bir nedendir.

Değerlendirmeyi işten ayırın. Kodu yargılamak ve kod üzerinde çalışmak iki ayrı iştir. Bunda bir suçlama yok: bu, her tarafa, kendi ekibinize bile sorabileceğiniz yapısal bir sorudur. Değerlendirmenin yazılı olmasını, başka bir ekibin de üzerinde iş yapabileceği bir biçimde olmasını isteyin; kapsamı ve maliyeti inşadan ayrı yazılsın. Yalnızca işi yapacak tarafın kafasında duran bir rapor, hiçbir şeyle karşılaştırılamaz.

Devralacak ekipte bakılacak yedi işaret

Yarım kalmış yazılım projesini devralan bir firma ya da ekip, ilk görüşmede, teklif gelmeden önce, neyi istediğine ve neyi yazıya dökeceğine bakılarak değerlendirilebilir. Tablo, işaretleri kanıt soruları olarak okuyor. Bu bizim okumamız; bir standart değil.

NIST'in Güvenli Yazılım Geliştirme Çerçevesi (SSDF), ortak sözlüğünün "yazılım alıcıları ve tüketicileri"nin "tedarikçilerle iletişimi geliştirmek" için de kullanılabileceğini söyler (NIST SP 800-218; çeviri bize ait). Çerçeveyi benimsemeniz gerekmez; tedarikçiye yazılımı nasıl geliştirdiğini, sınadığını ve yayımladığını sormanın sıradan bir alıcı sorusu olduğunu, kabalık olmadığını hatırlatır.

Yarım kalmış projeyi devralan firmaya sorulacak on iki soru

Bunlar devralmaya özgü. Her yazılım tedarikçisine sorulacak genel sorular için outsource, ekip kiralama ve proje bazlı çalışma rehberimizdeki on iki soruya bakın. Yazılı sorun, cevapları yazılı alın ve saklayın.

1. Teklif vermeden önce ilk olarak ne isteyeceksiniz? İyi cevap bir fiyatla değil, erişim, belge ve sözleşmeyle başlar.
2. Kimin hesaplarında çalışacaksınız? Kod deposu ve barındırma, kontrol ettiğiniz bir kurumda, sizin için yönetici rolüyle durmalı.
3. Temiz makinede kurulum ve yedekten geri yükleme yapıp sonucu bana yazılı olarak bildirecek misiniz?
4. Yazılı rapor neyi içerir, kim yazar? İdeal olarak işi yapacak mühendis.
5. Hangi durum mevcut kodla devam etmenizi, hangisi baştan başlamanızı önerirdi? İki tarafta da gerekçeyi dinleyin.
6. Değerlendirmenin kapsamı ve bedeli yeniden yazımdan ayrı mı, raporu başka bir ekibe götürebilir miyim?
7. Testi olmayan kodla ne yapıyorsunuz? Bir cevap, hiçbir şeyi değiştirmeden önce bugünkü davranışı kaydeden testler yazmaktır (Feathers).
8. Önceki ekibin bildiği gizli anahtarları nasıl ele alıyorsunuz? Önce yedek, sonra iptal ve döndürme; OWASP Secrets Management Cheat Sheet, ele geçmiş olabilecek gizli bilgilerin güvenli biçimde iptal edilmesi gerektiğini söyler (çeviri bize ait).
9. Uygulamalar önceki ekibin adınaysa mağaza hesaplarını ve devri kim yürütür?
10. Eski sistem çalışmaya devam etmek zorundaysa nasıl çalışıyorsunuz? Eski sistemin yanında yeni bir sistem kurup işlevleri kademeli olarak taşımak bir desendir; Martin Fowler buna boğucu incir (strangler fig) der (Fowler). Hangisini, neden kullanacaklarını sorun.
11. Öğrendiklerinizi nasıl yazıya dökeceksiniz? Gerekçeli kararlar, kurulum adımları, çalıştırma notları.
12. Değerlendirmeden sonra yollarımız ayrılırsa elimde ne kalır? Rapor, erişimler, belgeler.

Cevapları okumak: yeşil, sarı, kırmızı

Tablo bir okuma yardımcısıdır, hüküm değil. Tek bir sarı cevap yalnızca bir ek soru sormak için nedendir; asıl önemli olan, on iki cevabın bütünündeki örüntüdür.

Karşılaştırma tablosu: adaylarınızı puanlayın

Tabloyu kopyalayın, her ölçütün ağırlığını kendiniz belirleyin ve her adayı 0 ile 2 arasında, söylediğine değil yazıya döktüğüne göre puanlayın. Ağırlıklar ve puanlar sizindir; tabloda bize ait hiçbir rakam yok.

Her puanı ağırlığıyla çarpın ve sütunu toplayın. Toplamın karar vermesine izin vermeyin: adayların en çok ayrıştığı iki satırı bulmak için kullanın ve onlar üzerinde konuşun. İki aday eşitse, daha çok şeyi yazıya dökmüş olan, ayrılırsanız elinizde daha çok şey bırakandır.

Bunların hepsi hangi sırayla yapılır

1. Devralma rehberinde listelendiği gibi erişimleri güvene alın ve tam bir kopya edinin.
2. Projenin neden durduğunu birkaç satırla yazın: kapsam, ortadan kaybolan bir ekip, teknik bir engel, "bitti" denmiş ama bitmemiş bir iş ya da kapanan bir şirket. Neden, hangi seçeneğin uyduğunu değiştirir.
3. İki ya da üç tarafı listeye alın ve her birine on iki soruyu yazılı gönderin.
4. Yazılı cevapları tabloda puanlayın; yalnızca sözlü söylenmiş olanları puanlamayın.
5. Önce yalnızca değerlendirmeyi görevlendirin; kapsamı ve maliyeti işten ayrı yazılsın.
6. Rapora göre karar verin: devam, bir katmanı yeniden yazma ya da baştan başlama. İşin kapsamını ancak ondan sonra, seçtiğiniz tarafla çıkarın.

Beşinci adımı yapıp durursanız elinizde yine bir belge ve erişimleriniz vardır; raporun maliyeti dışında hiçbir şey kaybedilmemiştir.

Henüz yeni bir ekibe ihtiyacınız olmayabilecek iki durum

Önceki ekip ulaşılabilir ve neden kapsam ya da bütçeydi. O zaman soru "başka kim?" değil, "hangi daha küçük, yazılı kapsamla bitirirler?" olur. Önce erişimleri ve tam bir kopyayı hesaplarınıza alın, sonra yeni kapsamı yazın. Yazılmazsa aynı örüntünün geri gelmesi olasıdır.

Kodu gerçekten kimse yazmadı. Proje bir yapay zekâ aracıyla üretilmiş bir prototipse sorun giden bir ekip değil, kimsenin gözden geçirmediği koddur. Vibe coding uygulaması üretime hazır mı yazısındaki denetimle başlayın; bir kurtarıcıdan çok bir gözden geçirene ihtiyacı var.

Sahiplik ve sözleşme için yazılı netleştirilecek sorular

Bu bölüm genel bilgidir; hukuki danışmanlık değildir. Koda ait haklar, hesapların durumu ve kişisel verilerin konumu devralma rehberimizin "Mülkiyet ve hukuki notlar" bölümünde; yeni biriyle imza atmadan önce onu okuyun. Yeni tarafla, insanların unuttuğu iki şeyi yazılı koşullara bağlayın: değerlendirme bitince erişimler kimde kalır ve raporu başka bir ekiple kim paylaşabilir. Teklifin yapısı ve içinde önce neyin okunacağı yazılım teklifi nasıl okunur yazısında. OWASP, ASVS'nin "sözleşmelerde uygulama güvenliği doğrulama gereksinimlerini belirlemek için bir temel" sağlayabileceğini söyler (OWASP ASVS; çeviri bize ait); yeni işin bir güvenlik çıtasını karşılaması gerekiyorsa işe yarar. Bağlayıcı her sözleşmeyi bir avukata okutun.

Biz bunu nasıl yapıyoruz

Burada yalnızca sitemizde yazdığımızı tekrarlıyoruz. Danışmanlık işimiz koda, sisteme ve erişimlere dayanan yazılı çıktılar üretir; bir strateji sunumu değildir. Hazır bir çözüm ya da hiç dokunmamak işinize daha uygunsa bunu söyleriz. Değerlendirme de diğer işlerimiz gibi bir iştir: kapsamı ve maliyeti siz onaylamadan önce yazılı teklifte yer alır; devam etmek isterseniz sonraki işin kapsamı da aynı biçimde netleştirilir. Kodunuzu yazan mühendisle doğrudan konuşursunuz; yalnızca kıdemli mühendislerle çalışırız. Ana sayfamızda yazdığımız gibi bir fikir, bir ihtiyaç ya da yarım kalmış bir proje ile gelebilirsiniz; yöntem ve süre elinizdeki duruma göre değişir ve yazılı teklifte yer alır. Her proje, onayladığınız yazılı teklifle başlayan ücretli bir çalışmadır. Yaklaşımımız yazılım danışmanlığı ve modernizasyon sayfamızda, adımlar Süreç sayfasında. Yarım kalmış bir projeniz varsa ve konuşmak istiyorsanız projenizi anlatın. Yeni bir yapım olarak devam edecekseniz özel yazılım geliştirme sayfamız o işi anlatır.

Sık sorulan sorular

Başka bir firmanın başlattığı projeyi bir firma devralabilir mi?

Evet, ve yaygındır. İyi gidip gitmeyeceğini şirket değil iş sırası belirler: önce erişimleri ve tam bir kopyayı güvene alın, sonra değerlendirin, sonra karar verin; değerlendirme yazılı olsun. Denetim planı devralma rehberimizde.

Kodu değerlendiren taraf yeniden yazımı da yapmalı mı?

Yapabilir, ama iki işin nasıl ayrı tutulduğunu sorun. Değerlendirmenin kendi yazılı kapsamı ve maliyeti olmalı, rapor başka her ekibin kullanabileceği bir belge olmalı. Rapordan sonra durup onu başka yere götürebiliyorsanız seçim sizde kalır.

Kurtarma için serbest çalışan mı, firma mı daha iyi?

İşin biçimine bağlı. Sınırlı bir düzeltme ya da koda ikinci bir görüş tek bir kişiye uyar. Değerlendirme, iş ve sürekliliği birlikte isteyen bir iş, yazılı sürece ve bir kişi ulaşılamadığında ne olacağına daha çok ağırlık verir. İlk bölümdeki tablo iki riski de gösteriyor; outsource rehberi modelleri sekiz ölçütle karşılaştırıyor.

Önceki geliştirici hâlâ ulaşılabiliyor ama güvenilmezse?

Devralma rehberindeki "Eski ekipten istenecekler" tablosundaki kalemleri yazılı isteyin ve cevapları saklayın. Ulaşabildiğiniz her şeyin kendi kopyasını alın ve onların bildiği gizli anahtarları döndürün. Onlarla devam edip etmemek iyi niyete değil, yazılı kapsama bağlı bir karardır.

Yeniden yazım teklifi istemeden önce değerlendirme gerekir mi?

Sistemi kimse görmeden verilen yeniden yazım teklifi bir tahmindir. Önce değerlendirme, soruyu yazılı bir karara çevirir: devam, bir katmanı yeniden yazma ya da baştan başlama. Alternatif, sistem görüldükten sonra teklifin değişeceğini kabul etmek ve değişikliğin nasıl yazılacağını sormaktır.

Kaynaklar

Aşağıdaki sayfalar 9 Kasım 2026'da açılıp okundu. Sayfalar zamanla değişir; harekete geçmeden önce resmî olanları yeniden açın.

• Joel Spolsky, The Joel Test: 12 Steps to Better Code, 9 Ağustos 2000 · The Twelve-Factor App, Adam Wiggins, son güncelleme 2017
• NIST SP 800-218, Secure Software Development Framework (SSDF) Sürüm 1.1, Şubat 2022 · OWASP Application Security Verification Standard 5.0.0, 30 Mayıs 2025
• GitHub Docs: Roles in an organization · GitHub Docs: Transferring a repository
• OWASP Secrets Management Cheat Sheet · Michael Feathers, Characterization Testing, 8 Ağustos 2016
• Joel Spolsky, Things You Should Never Do, Part I, 6 Nisan 2000 · Martin Fowler, Strangler Fig Application, 22 Ağustos 2024

Bu yazı genel bilgi içindir; hukuki danışmanlık değildir.