AR-GE TEKNİK KANIT MÜHENDİSLİĞİ

AR-GE yaptınız. Teknik ilerlemeyi gerçek mühendislik kanıtlarıyla gösterebiliyor musunuz?

Mühendisler bir yöntem denedi. Yetersiz kaldı. Başka model karşılaştırıldı. Veri seti tekrar gözden geçirildi. Etiketleme yöntemi değişti. Mimari yeniden tasarlandı. Test sonuçları üretildi.

Aylar veya yıllar sonra teknik iddia “yeni ve yenilikçi bir AI çözümü geliştirildi” cümlesine sıkışabilir.

Gerçekte yapılan mühendislik çalışmasını teknik olarak görünür, izlenebilir ve savunulabilir hâle getirmek.

MÜHENDİSLİK VE TEKNİK İDDİA

Proje formu, projenin kendisi değildir.

Teknik iddia; başlangıçtaki bilgi ve yeteneğin ne olduğunu, hangi teknik ilerlemenin hedeflendiğini, çözümün neden doğrudan çıkarılamadığını, hangi yaklaşımların denendiğini ve sonucun nasıl değerlendirildiğini sorabilir.

Mühendis ise “önceki model büyük girdilerde yavaştı”, “bu yaklaşım veri setinde yeterli olmadı” veya “vektör modele geçtik” diyebilir.

Aynı teknik gerçeklik. Farklı dil.

Teknik temellendirme bu iki dünya arasında çalışır.

KANIT İLİŞKİSİ

Jira kaydı tek başına teknik kanıt değildir.

Bir Jira kaydı rutin geliştirme, hata düzeltme, AR-GE faaliyeti veya başka bir projenin işi olabilir. Aynı durum commit ve pull request için de geçerlidir.

Bir kaydın varlığı ile teknik iddiayla ilgisi aynı şey değildir.

Şu ilişki kurulabilmelidir: Bu teknik iddia ne söylüyor? Bu kayıt iddianın hangi bölümünü neden destekliyor?

KANIT KEŞFİ

Daha fazla dosya, daha güçlü kanıt anlamına gelmez.

Yüzlerce Jira PDF’i, pull request, mimari klasörü, haftalık not ve test sonucu bulunabilir.

Hepsini inceleyenin önüne koymak mümkündür. Ama soru kalır: Nereye bakmalı ve neden?

Canbek, kanıt keşfi, nitelendirme ve teknik ilişki üzerinde çalışır.

Kanıt üretilmez. Var olan mühendislik çalışmasının izleri bulunur, sınanır, ilişkilendirilir ve anlaşılabilir hâle getirilir.

İTERASYON VE BAŞARISIZLIK

Başarısız denemeler teknik hikâyenin parçası olabilir.

Mühendislik doğrusal değildir.

Başarısızlık her zaman zayıflık değildir. Bazen teknik belirsizliğin en güçlü izidir. Ama yalnızca gerçekten yaşandıysa.

DÖRT UK R&D DÖNEMİ

Teknik ekip ile AR-GE danışmanı arasındaki mühendislik boşluğunu kapatmak.

Çalışma başlamadan önce ne biliniyor ve ne yapılabiliyordu?

Mevcut teknik yeteneği, yalnızca ürün durumunu değil, teknik kapasiteyi açıklayacak biçimde sınırla.

Hangi yetenek ileri götürülmeye çalışıldı?

“Daha iyi ürün” yerine teknik olarak neyin değişmesinin hedeflendiğini açıkla.

Çözüm neden doğrudan çıkarılamıyordu?

Yetkin bir mühendisin standart adımlarla çözemeyeceği teknik bilinmezliği ayır.

Ne denendi ve ne değişti?

Başarısız girişim, veri üretimi, model değişikliği, mimari karar ve test sonuçlarını teknik kronoloji içinde ilişkilendir.

Global bir SaaS ortamındaki dört UK R&D döneminde coğrafi işleme, otomatik haritalama, yürünebilir güzergâh üretimi, konumlandırma altyapısı, makine öğrenmesi ve LLM tabanlı sınıflandırma çalışmalarına ilişkin teknik girdiler koordine edildi.

2024 DÖNEMİNDEN GENELLEŞTİRİLMİŞ ÖRNEK

Teknik hedef ile gözlenen sonuç birbirine karıştırılmamalıdır.

Bir havacılık haritalama AR-GE çalışmasında daha yapılandırılmış ortamlara yönelik yöntemlerin büyük ve heterojen terminal ortamlarına genişletilmesi hedeflendi.

160’ın üzerinde sınıflandırma sınıfı analiz edildi; özel coğrafi istatistik ve görselleştirme araçları geliştirildi; etiketleme turları ve tekrar eden uygunsuzluklar incelendi; farklı görsel model yaklaşımları ve vektör tabanlı mekânsal yöntemler karşılaştırıldı.

Hedef metrikler ile gözlenen teknik sonuçlar ayrı tutuldu.

“AI ile haritalama geliştirdik” yeterli teknik anlatı değildir.

İNCELEME GELDİĞİNDE

Süreç tersine döner.

Teknik iddia daha önce hazırlanmıştır. Şimdi soru şudur: Bu iddiayı gerçek mühendislik geçmişi içinde hangi kayıtlar destekliyor?

Önceki bir inceleme bağlamındaki teknik kanıt çalışmasında Jira, GitHub pull request’leri, commit kayıtları, haftalık AR-GE notları, teknik rehberler, mimari diyagramlar, test ve analiz kayıtları ile katkı sağlayan kişilere ilişkin bilgiler incelendi.

Ham kayıtlar önce geniş biçimde keşfedildi. Ardından teknik iddiayla ilgileri açısından süzüldü ve teknik bağlamla ilişkilendirildi.

Kanıt keşfi ile kanıt nitelendirmesi aynı iş değildir.

KANITI TASARIMIN PARÇASI HÂLİNE GETİRMEK

AR-GE kanıtı denetim geldiğinde üretilmemeli. Mühendislik çalışırken iz bırakmalıdır.

Bu, mühendislere yeni uyum formları doldurtmak anlamına gelmez.

Teknik belirsizlik, başarısız girişim, mimari karar, deney, benchmark, pull request, iş kaydı ve teknik sonuç arasında hafif ama sürdürülebilir ilişkiler kurulabilir.

Amaç daha fazla doküman üretmek değil, gerçek mühendislik çalışmasının kritik izlerini kaybetmemektir.

YÖNTEM

Gerçek mühendislik çalışması ile teknik iddia arasındaki mesafeyi sınırlarız.

Değerlendirme sorusunu sınırla

İddia hazırlığı mı, teknik inceleme mi, inceleme yanıtı mı, kanıtı tasarımın parçası hâline getirme mi?

Teknik proje sınırlarını çıkar

Ürün geliştirme ile iddia edilen AR-GE faaliyetini ayır.

Kanıt kaynaklarını keşfet

Jira, Git, belgeler, mimari, testler, notlar ve katkı sağlayan kişiler.

Teknik kronolojiyi yeniden kur

Ne önce oldu? Hangi başarısızlık sonraki değişikliği doğurdu?

Başlangıç noktası, ilerleme ve belirsizliği incele

Zayıf iddiayı güzelleştirmek yerine zayıflığı görünür kıl.

Teknik faaliyetleri kanıtla ilişkilendir

Her kaydın iddiayla ilgisini ayrı değerlendir.

Çelişki ve boşlukları sorgula

Farklı anlatılar aynı teknik geçmişi farklı tarif ediyor olabilir.

Teknik temellendirme paketini oluştur

İnceleyen kişinin teknik hikâyeyi izleyebileceği yapı kur.

Gerekirse sürdürülebilir kanıt modeli tasarla

Sonraki AR-GE dönemi için kritik teknik izlerin kaybolmasını önle.

Çalışma biçimleri

AR-GE teknik kanıt kurtarma sprinti

Tipik olarak 7–10 iş günlük odaklı başlangıçta geçmiş proje kaynakları keşfedilir; teknik iddia, kronoloji ve kanıt ilişkileri kurulur; boşluklar görünür hâle getirilir. Süre, dönem ve kanıt hacmine göre teyit edilir.

AR-GE iddiası teknik koordinasyonu

Mühendislik ekibi ile AR-GE danışmanı arasındaki teknik girdiler ve teknik soru koordinasyonu.

Kanıtı tasarımın parçası hâline getirme

Mühendislik iş akışı içinde kritik AR-GE izlerinin sürdürülebilir biçimde korunması.

Danışmanlık firmalarına teknik uzmanlık

Vergi ve AR-GE danışmanlarının hukuki/mali sorumluluğunu üstlenmeden; mühendislik gerçeğinin anlaşılması, teknik ekip görüşmeleri, faaliyet ayrımı ve teknik temellendirme için white-label veya uzman çözüm ortağı desteği.

BU ÇALIŞMA NE DEĞİLDİR?

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

• Vergi danışmanlığı değildir.
• Kurumlar vergisi hesaplaması değildir.
• Hukuki temsil değildir.
• Yapılmamış teknik çalışmayı yapılmış gibi gösteren anlatı üretmez.
• Rutin geliştirmeyi zorla AR-GE diye etiketlemez.
• Jira veya Git dışa aktarma hizmeti değildir.

NEDEN CANBEK?

AR-GE’yi yalnızca raporlayan değil, yapan mühendisin teknik incelemesi.

Üretim ortamında yazılım ve uzman sistem geliştirme; veri seti, etiketleme ve model karşılaştırma; üç TEYDEB 1501 projesi; Innovate UK aday proje koordinasyonu; dört UK R&D dönemi; inceleme bağlamında teknik kanıtın yeniden yapılandırılması ve beş verilmiş ABD patentinde ortak mucitlik.

Mühendislikten teknik iddiaya. Teknik iddiadan yeniden kanıta.