ar-ge-teknik-iddia-kanit · saha-notu

Jira kayıtlarınız var. Teknik kanıt zinciriniz var mı?

Kayıt sayısı ile teknik iddiayı destekleyen izlenebilir mühendislik kronolojisi aynı şey değildir.

Bir AR-GE teknik incelemesi başladığında ilk tepki şu olabilir:

“Jira kayıtlarımız var.”

“Git geçmişi duruyor.”

“Pull request’leri çıkarabiliriz.”

“Haftalık notlar da bir yerde olmalı.”

Bunlar değerlidir. Fakat yüzlerce kayıt bulmak, teknik iddianın kanıtlandığı anlamına gelmez.

Kanıt mühendisliği bir dosya toplama işi değildir. İlişkileri keşfetme problemidir.

Arama problemi de burada başlar. Teknik iddiada kullanılan ad, proje sırasında kullanılan adla aynı olmayabilir. Bileşen yeniden adlandırılmış, algoritma başka bir kod adıyla geliştirilmiş veya çalışma iki Jira projesine bölünmüş olabilir.

Yalnız bugünkü proje adını aramak yüksek doğruluklu ama düşük hatırlamalı bir kanıt araması yaratabilir. Alan bilgisi, eski isimler ve teknik eş anlamlılar bulunmadan önemli kayıtlar görünmez kalır.

Teknik iddia belirli bir başlangıç noktasını, teknik ilerlemeyi, belirsizliği ve çözüm girişimini anlatıyorsa kayıtların da bu sorularla ilişkisi kurulmalıdır.

Her teknik kayıt aynı kanıt değerine sahip değildir

Bir Jira kaydı doğrudan belirli bir teknik belirsizliği gösterebilir. Başka bir kayıt yalnız zaman bağlamı sağlar. Bir pull request çözüm girişimini gösterebilir ama neden yapıldığını açıklamayabilir. Bir haftalık not, kararın gerekçesini anlatabilir ama sonucu kanıtlamayabilir.

Negatif sonuç da değerlidir. Bir deneyin başarısız olması, teknolojik belirsizliğin gerçekten var olduğunu ve ek çözüm arayışının neden başladığını gösterebilir. Yalnız başarılı pull request’leri seçmek teknik hikâyeyi olduğundan düz ve kolay gösterebilir.

Kanıt değeri dosya türünden çıkmaz. Kaydın teknik iddianın hangi unsuruyla, hangi zaman noktasında ve hangi ilişkiyle bağlandığından çıkar.

Bu ayrım yapılmazsa “kanıt paketi” büyür. Fakat teknik savunulabilirlik aynı ölçüde artmayabilir.

Teknik bağlam, kanıt aramasının isabetini artırır.

Tek bir kayıt teknik hikâyeyi açıklamayabilir

Mühendislik çalışması çoğu zaman tek bir Jira kartına sığmaz.

İlk kayıtta sorun görülür. Bir Slack konuşmasında nedenin bilinmediği tartışılır. Sonra bir deney branch’i açılır. Pull request’te yaklaşım değiştirilir. Test sonucu beklenen ilerlemenin çıkmadığını gösterir. Haftalık notta ikinci yaklaşım kararı verilir. Sonraki sprintte veri hazırlığı değişir.

Bu zincir tek tek kayıtların toplamından daha değerlidir.

Kronoloji kurulurken yalnız tarihe göre sıralamak da yetmeyebilir. Aynı tarihte üç paralel çözüm girişimi olabilir. Bir test sonucu iki hafta önceki varsayımı çürütebilir. Sonraki mimari karar, başarısız denemeden doğmuş olabilir.

Bu nedenle kayıtlar arasında “neden oldu”, “sınadı”, “çürüttü”, “yerine geçti”, “devam ettirdi” gibi teknik ilişkiler aranır. Kronoloji zaman çizgisi olmaktan çıkar, mühendislik akıl yürütmesinin izi hâline gelir.

PROBLEM KAYDI → TEKNİK SORU → ÇÖZÜM GİRİŞİMİ → TEST / SONUÇ → SONRAKİ KARAR

Basitleştirilmiş mühendislik kronolojisi. Gerçek proje kayıtlarının birebir gösterimi değildir. Farklı kayıt türleri arasındaki teknik ilişkinin önemini gösterir.

Kayıtlar arasındaki ilişkiler teknik kronolojiyi yeniden kurabilir.

Burada alan bilgisinin önemi büyüktür. Hangi isimlerin aynı algoritmayı, hangi bileşenin başka bir eski proje adını veya hangi test sonucunun hangi teknik varsayımı ilgilendirdiğini bilmeden arama isabetsizleşir.

Bu yüzden teknik kanıt yeniden kurma çalışmasında arama yalnız anahtar kelime çalışması olamaz. Kayıtlar okunurken yeni varlıklar, eski isimler, kişiler, bileşenler ve tarih aralıkları ortaya çıkar. Arama sorusu her turda biraz daha isabetli hâle gelir.

İyi kanıt araması, teknik bağlam öğrendikçe kendini günceller.

Çelişki kötü kanıt değildir. Gizlenen çelişki kötü teknik temellendirmedir.

Bir teknik iddia “yaklaşım X yeterli olmadı” diyebilir. Fakat erken sprint kaydında X yaklaşımı başarılı olarak tanımlanmış olabilir.

Bu durum otomatik olarak iddiayı çürütmez. Erken başarı sınırlı veri üzerinde olabilir. Sonraki ölçek testi yeni problem ortaya çıkarmış olabilir. Başarı ölçütü değişmiş olabilir.

Aynı ayrım hedef ile gerçekleşen sonuç arasında da yapılmalıdır. Proje planında %95 kesinlik (precision) hedefi yazması, modelin %95 kesinliğe (precision) ulaştığını kanıtlamaz. Hedef kaydı başlangıç niyetini; test kaydı gözlenen sonucu gösterir. İkisi farklı kanıt rolleridir.

Teknik temellendirme bu rolleri birbirine karıştırmamalıdır. Aksi hâlde iyi niyetli bir özet bile hedefi başarıya, planı gerçekleştirilmiş çalışmaya dönüştürebilir.

Yapılması gereken kayıtları saklamak değil, teknik kronolojiyi açıklamaktır.

Benim için kanıt sınıflandırmasında “çelişki” durumunun ayrı görünür olması bu yüzden önemlidir.

Güçlü teknik temellendirmenin ilk koşulu teknik dürüstlüktür.

Yapılmamış çalışma yapılmış gibi anlatılmaz. Hedef sonuç, gerçekleşmiş sonuç gibi sunulmaz. İlişkisiz kayıt dosya sayısını büyütmek için kullanılmaz. Kayıtlar çelişiyorsa çelişki gizlenmez.

AR-GE kanıtı inceleme geldiğinde üretilmemeli

Yıllar sonra kurumsal teknik hafızayı yeniden kurmak mümkündür. Fakat pahalıdır.

Kanıtı tasarımın parçası hâline getirmek daha fazla doküman üretmek demek değildir. Gerçek mühendislik çalışmasının kritik izlerinin kaybolmamasını sağlamak demektir.

Bir mühendislik ekibinden her gün “AR-GE kanıt formu” doldurmasını istemek ters etki yaratabilir. Ama mevcut Jira, Git, test ve haftalık not akışına birkaç doğru ilişki eklemek yıllar sonra büyük fark oluşturur.

Örneğin teknik belirsizlik kaydının çözüm girişimine, çözüm girişiminin test sonucuna ve test sonucunun sonraki karara bağlanması yeterli bir başlangıç olabilir. Amaç belge sayısını değil, geri dönüş yolunu güçlendirmektir.

Örneğin iş akışında şu küçük disiplinler düşünülebilir:

AR-GE kanıtı inceleme başladığında üretilmemeli. Mühendislik çalışırken iz bırakmalıdır.

Bu yaklaşımın amacı denetim için sahte bir iz üretmek değildir. Tam tersine, gerçek mühendislik çalışmasının doğal teknik izlerini kaybetmemektir.

Bu sınır rol ayrımı açısından da önemlidir. Vergi danışmanı veya teşvik uzmanı ilgili mevzuat ve talep sürecini yönetebilir. Teknik ekip mühendisliği yapar. Teknik temellendirme katmanı ise gerçek mühendislik çalışması ile iddianın sorduğu teknik sorular arasındaki bağı kurar.

Kanıt üretmez. Var olan teknik izleri bulur, sınar, ilişkilendirir ve eksik bağları açıkça gösterir.

İLGİLİ ÇALIŞMA ALANI

AR-GE teknik kanıt mühendisliği

Gerçek mühendislik çalışmasını teknik ilerleme, belirsizlik, çözüm girişimi ve kanıt ilişkileri üzerinden görünür, izlenebilir ve savunulabilir hâle getirin.

Çalışma alanını inceleyin →

6 DK OKUMA