Bir TÜBİTAK projesi hazırlamaya başlarken yapılan en yaygın hatalardan birinin, doğrudan başvuru formunu açıp alanları doldurmaya başlamak olduğunu düşünüyorum. Benim yaklaşımım bunun tam tersi: önce proje fikrini, problemi, hedeflenen çıktıyı ve çağrıyla olan ilişkiyi kendi içinde tutarlı bir sistem haline getirmek; formu ise bu sistemin TÜBİTAK tarafından istenen düzende anlatıldığı son aşama olarak görmek.

Çünkü iyi yazılmış bir proje yalnızca teknik olarak güçlü olmakla yetinmiyor. Değerlendiricinin birkaç temel sorusuna açık cevap vermesi gerekiyor: Neden bu projeye ihtiyaç var? Mevcut durum neden yeterli değil? Önerilen çözüm gerçekten yenilik içeriyor mu? Kuruluş veya ekip bunu yapabilecek kapasitede mi? Çıktı ortaya çıktığında ekonomik, bilimsel veya ulusal düzeyde ne değişecek?

TÜBİTAK programları birbirinden ciddi biçimde farklılaşabiliyor. Sanayi odaklı TEYDEB programları ile akademik ARDEB programlarının başvuru yapısı, değerlendirme dili ve beklediği çıktı aynı değil. Bu nedenle bu yazıyı belirli bir programa özel başvuru kılavuzu olarak değil, farklı TÜBİTAK çağrılarına uyarlanabilecek genel bir proje hazırlama yaklaşımı olarak ele alıyorum. 1505, 1705, 1832 veya başka bir çağrı için ayrıntıya girileceğinde mutlaka ilgili çağrı metni ve güncel uygulama esasları ayrıca okunmalı.

Faydalı bağlantı — TÜBİTAK destek programları:

https://tubitak.gov.tr/tr/destekler

Sanayi destek programları:

https://tubitak.gov.tr/tr/destekler/sanayi

1. Projeyi yazmaya çağrıyı okuyarak başlarım

Ben proje fikrini ne kadar güçlü bulursam bulayım, ilk olarak çağrının gerçekten o fikri desteklemek isteyip istemediğine bakarım. Bir projenin teknik açıdan iyi olması, yanlış çağrıya sunulduğunda fazla anlam taşımıyor. Değerlendirme aşamasında ilk dikkat çeken noktalardan birinin proje ile çağrının amacı arasındaki uyum olduğunu düşünüyorum.

Bu nedenle çağrı metnini okurken yalnız “kimler başvurabilir?” veya “bütçe ne kadar?” sorularına bakmam. Şu başlıkları ayrı ayrı not ederim:

• Çağrının amacı tam olarak ne?
• Hangi teknolojik veya sektörel problem hedefleniyor?
• Beklenen proje çıktısı araştırma mı, ürün mü, süreç mi, prototip mi, dönüşüm mü?
• Çağrının öncelik verdiği teknoloji alanları var mı?
• Değerlendirme ölçütleri neler?
• Zorunlu ortaklık, müşteri kuruluş, üniversite veya özel sektör koşulu bulunuyor mu?
• Süre, bütçe ve teknoloji hazırlık seviyesi sınırları var mı?

Bana göre proje metninin ilk sayfalarından itibaren çağrıyla olan ilişki açıkça görülebilmeli. Değerlendiricinin “bu proje neden bu çağrıya gönderilmiş?” sorusunu kendi kendine cevaplamak zorunda kalması iyi bir işaret değildir.

Faydalı bağlantı — TÜBİTAK sanayi destekleri ve güncel programlar:

https://tubitak.gov.tr/tr/destekler/sanayi

2. Projenin merkezinde çözüm değil, iyi tanımlanmış bir problem olmalı

Benim için güçlü bir proje, “şunu geliştireceğiz” cümlesiyle değil, “neden geliştirmemiz gerekiyor?” sorusuyla başlıyor. Problem iyi tanımlanmadığında yenilikçi yön de, yöntem de, bütçe de havada kalıyor.

Problem tanımını mümkün olduğunca veriye dayalı kurmanın değerlendirme aşamasında dikkat çekeceğini düşünüyorum. Örneğin “enerji tüketimimiz yüksek” demek yerine mevcut tüketim seviyesini, kayıp noktasını, sektör karşılaştırmasını veya üretim başına enerji göstergesini vermek çok daha güçlü bir başlangıç oluşturur. Aynı mantık kalite problemi, proses verimsizliği, ithal teknoloji bağımlılığı, ürün performansı veya sürdürülebilirlik problemi için de geçerlidir.

Burada benim kullandığım basit kurgu şu:

1. Mevcut durum nedir?
2. Sorun nerede oluşuyor?
3. Bunun teknik veya ekonomik etkisi nedir?
4. Mevcut çözümler neden yeterli değil?
5. Proje sonunda hangi ölçülebilir farkın oluşması bekleniyor?

Bir proje önerisinin ilk bölümlerinde okuyucu problemi anlamıyorsa, sonraki sayfalardaki teknik ayrıntının etkisi de azalır. Proje metninde önce ihtiyacın önemini, sonra çözümün değerini göstermek daha ikna edici bir akış oluşturur.

3. “Yenilikçi yön” bölümü reklam metni gibi yazılmamalı

TÜBİTAK’ın özellikle sanayi destek programlarında tekrar eden temel değerlendirme boyutlarından biri projenin Ar-Ge içeriği, teknoloji düzeyi ve yenilikçi yönüdür. 1501 ve 1507 gibi programlarda proje önerileri; Ar-Ge ve yenilik, proje planı ve altyapı, ekonomik yarar ve ulusal kazanım boyutları üzerinden değerlendiriliyor.

Resmî kaynak — 1501 değerlendirme yaklaşımı:

https://tubitak.gov.tr/tr/destekler/sanayi/ulusal-destek-programlari/1501-tubitak-sanayi-ar-ge-projeleri-destekleme-programi

Resmî kaynak — 1507 değerlendirme yaklaşımı:

https://tubitak.gov.tr/tr/destekler/sanayi/ulusal-destek-programlari/1507-tubitak-kobi-ar-ge-baslangic-destek-programi

Ben yenilikçi yönü yazarken “daha verimli”, “daha çevreci”, “yerli ve milli”, “yenilikçi bir sistem” gibi tek başına kanıt oluşturmayan sıfatları mümkün olduğunca azaltırım. Bunun yerine karşılaştırma yapmayı daha faydalı buluyorum.

Bence değerlendiricinin görmek istediği şey “bu proje çok yenilikçi” cümlesi değil; mevcut teknoloji ile proje çıktısı arasındaki farkın anlaşılır ve doğrulanabilir biçimde ortaya konmasıdır. Patent taraması, bilimsel literatür, rakip ürün karşılaştırması, teknik veri sayfaları ve mevcut proses ölçümleri bu bölümü ciddi biçimde güçlendirebilir.

Faydalı bağlantı — TEYDEB proje öneri hazırlama kılavuzu ve başvuru yaklaşımı:

https://eteydeb.tubitak.gov.tr/basvurukilavuzu.htm

4. Hedefleri mümkün olduğunca ölçülebilir yazarım

“Ürün kalitesi artırılacaktır” veya “enerji tüketimi azaltılacaktır” gibi hedeflerin tek başına yeterince güçlü olmadığını düşünüyorum. Hedefin mümkünse bir başlangıç değeri, hedef değer ve ölçüm yöntemi olmalı.

Burada özellikle sayı uydurmamak gerekiyor. Hedef değer ya mevcut veriden, literatürden, benchmark çalışmasından ya da yapılmış ön denemeden gelmeli. Hedefin kaynağı yoksa iddialı görünmek yerine güvenilirliğini kaybedebilir.

5. İş paketleri proje hikâyesinin omurgasıdır

Ben iş paketlerini yalnız zaman planını doldurmak için oluşturmanın doğru olmadığını düşünüyorum. Her iş paketinin bir soruya cevap vermesi gerekir ve bir sonraki aşamaya aktarılacak somut bir çıktısı olmalıdır.

Genel bir Ar-Ge projesinde akış örneğin şu mantıkla kurulabilir:

1. Mevcut durum ve gereksinimlerin doğrulanması
2. Tasarım / reçete / model / yöntem geliştirme
3. Laboratuvar veya pilot ölçek doğrulaması
4. Prototip veya proses uygulaması
5. Performans testleri
6. Optimizasyon
7. Nihai doğrulama ve çıktıların değerlendirilmesi

Her iş paketinde ben dört şeyi açıkça görmeyi isterim: yapılacak faaliyet, sorumlu ekip, ortaya çıkacak çıktı ve başarı ölçütü. Bu şekilde yazmanın değerlendirme aşamasında projenin gerçekten planlanmış olduğu izlenimini güçlendirdiğini düşünüyorum.

6. Risk tablosu “proje başarısız olabilir” demek değildir

Bazı proje metinlerinde risk bölümü mümkün olduğunca risksiz gösterilmeye çalışılıyor. Ben bunun tersinin daha güvenilir olduğunu düşünüyorum. Gerçek bir Ar-Ge projesinde teknik belirsizlik zaten vardır. Önemli olan riskin farkında olmak ve alternatif planı gösterebilmektir.

Örneğin bir malzeme hedeflenen performansı sağlamazsa alternatif reçete nedir? Kritik ekipman zamanında alınamazsa hangi laboratuvar kullanılabilir? Pilot denemede kapasite sorunu çıkarsa ölçekleme nasıl değiştirilecektir? Bunların önceden düşünülmüş olması proje yönetimi açısından güçlü bir işarettir.

Risk bölümü, projenin zayıflıklarını itiraf ettiğimiz alan değil; belirsizliği yönetebildiğimizi gösterdiğimiz alandır.

7. Ekip ve altyapı, yazılan yöntemi gerçekten taşıyabilmeli

Proje metninde ileri analizler, karmaşık testler veya özel yazılımlar tarif edilip ekipte bu yetkinliğin karşılığı görünmüyorsa değerlendirme sırasında soru işareti oluşabilir. Ben bu nedenle yöntem ile ekip yetkinliğini birbirine bağlamayı önemli buluyorum.

“Bu işi kim yapacak?”, “daha önce benzer bir çalışma yürüttü mü?”, “hangi cihaz kullanılacak?”, “cihaz kurumda yoksa hizmet alımı neden gerekli?” gibi soruların cevabı proje içinde görünür olmalı. Özgeçmişleri yalnız kişinin eğitim geçmişi değil, projedeki görevini destekleyen kanıt olarak düşünmek daha faydalı.

8. Bütçe, projenin teknik planının mali karşılığıdır

Bütçeyi proje bittikten sonra eklenen bir alışveriş listesi gibi görmemek gerekiyor. Personel, malzeme, cihaz, yazılım, hizmet alımı ve seyahat giderlerinin her biri doğrudan bir iş paketiyle ilişkilendirilebilmeli.

Ben bütçe gerekçesini yazarken “bu cihaz gereklidir” demek yerine hangi faaliyette, hangi amaçla ve neden mevcut altyapının yeterli olmadığıyla birlikte açıklamanın daha güçlü olduğunu düşünüyorum. Özellikle yüksek tutarlı kalemlerde bu bağın görünür olması değerlendirmeyi kolaylaştırır.

9. Ekonomik yarar ve ulusal kazanım kısmı sona bırakılmamalı

Sanayi projelerinde teknik çıktı kadar bu çıktının neye dönüşeceği de önem taşıyor. TÜBİTAK’ın sanayi desteklerinde ekonomik yarar ve ulusal kazanım ayrı bir değerlendirme boyutu olarak tekrar tekrar karşımıza çıkıyor.

Ben bu bölümü proje yazımının sonunda “bir şeyler ekleyelim” diye doldurmak yerine daha proje kurgulanırken düşünmenin doğru olduğunu düşünüyorum. Çünkü proje çıktılarını belirleyen şey yalnız teknik başarı değil; çıktı kullanıldığında oluşacak değer.

• İthalatın azaltılması
• İhracat potansiyeli
• Birim maliyet düşüşü
• Enerji ve kaynak verimliliği
• Yeni müşteri / pazar imkânı
• Üretim kapasitesi veya kalite artışı
• Fikri mülkiyet üretimi
• Yeni teknik yetkinlik kazanımı
• Çevresel kazanım

Burada da mümkün olduğunca nicel veri kullanmak daha ikna edici olur. Ancak pazar büyüklüğü veya satış tahmini gibi verilerin kaynağı belirtilmeli; gerçekçi olmayan büyüme varsayımlarının projeyi güçlendirmek yerine zayıflatabileceğini düşünüyorum.

10. Proje özetini en son yazarım

Ben proje özetini ilk yazılan bölüm değil, son yazılan bölüm olarak görüyorum. Çünkü özetin amacı proje fikrini geliştirmek değil, tamamlanmış projenin mantığını kısa ve net biçimde aktarmaktır.

İyi bir özette şu altı unsurun görünmesini faydalı buluyorum:

• Problem / ihtiyaç
• Projenin amacı
• Önerilen yöntem
• Yenilikçi yön
• Temel teknik çıktılar
• Beklenen ekonomik / bilimsel / ulusal etki

Bir değerlendirici yalnız özeti okuduğunda projenin neyi neden yaptığını anlayabiliyorsa, proje metninin geri kalanına da daha sağlam bir çerçeveyle girer.

11. Projeyi göndermeden önce kendi kendime hakemlik yaparım

Başvuru öncesinde metni yalnız yazım hatası açısından değil, değerlendirme mantığı açısından yeniden okumak gerekiyor. Ben bunun için her ana bölümün karşısına bir soru koymayı faydalı buluyorum.

TÜBİTAK’ın TEYDEB proje öneri hazırlama kılavuzlarında da proje bilgilerinin değerlendiricilerin teknolojik ve ekonomik açıdan tam fikir edinmesini sağlayacak yeterlilikte hazırlanması gerektiği özellikle vurgulanıyor. Bu yüzden metni fazla uzun yazmaktan çok, değerlendirme için gerekli kanıtı doğru yerde vermek önemli.

Faydalı bağlantı — TEYDEB PRODİS başvuru kılavuzu:

https://eteydeb.tubitak.gov.tr/basvurukilavuzu.htm

Faydalı bağlantı — ARDEB Proje Başvuru Sistemi:

https://ardeb-pbs.tubitak.gov.tr/

12. Yapay zekâ kullanılıyorsa gizlemek yerine doğru kullanmak gerekir

TÜBİTAK 2025 yılında destek süreçlerinde üretken yapay zekânın sorumlu ve güvenilir kullanımına ilişkin ayrı bir rehber yayımladı. Rehber; literatür özetleme, dil desteği, kodlama, fikir geliştirme veya görselleştirme gibi destekleyici kullanımlara imkân tanırken başvuru sahibinin doğruluk, özgünlük ve etik uygunluktan sorumlu olduğunu açıkça belirtiyor. Gizli verilerin bu araçlara girilmemesi ve önemli ölçüde kullanımın şeffaf biçimde beyan edilmesi gerekiyor.

Ben yapay zekâyı proje fikrinin sahibi veya teknik kanıtın kaynağı gibi kullanmanın doğru olmadığını düşünüyorum. Buna karşılık yazım kontrolü, alternatif iş paketi kurgularını tartışmak, literatür arama terimleri üretmek veya bir tabloyu daha anlaşılır hale getirmek için kullanılması oldukça faydalı olabilir. Son karar, veri doğrulaması ve teknik sorumluluk yine proje ekibinde kalmalı.

Resmî kaynak — TÜBİTAK Üretken Yapay Zekâ Rehberi:

https://tubitak.gov.tr/tr/kurumsal/hakkimizda/uretken-yapay-zeka-rehberi

Kısa kontrol listem

Bir TÜBİTAK projesini göndermeden önce benim bakacağım son kontrol listesi şu olur:

• Doğru çağrı seçilmiş mi?
• Problem sayısal veya güvenilir veriyle desteklenmiş mi?
• Mevcut çözüm ile önerilen çözüm arasındaki fark açık mı?
• Ar-Ge belirsizliği gerçekten var mı?
• Hedefler ölçülebilir mi?
• İş paketleri birbirini mantıksal olarak takip ediyor mu?
• Her iş paketinin somut çıktısı var mı?
• Riskler ve alternatif planlar tanımlı mı?
• Ekip ve altyapı yöntemi gerçekleştirebilir mi?
• Bütçe iş paketleriyle ilişkili mi?
• Ekonomik / bilimsel / ulusal etki somut mu?
• Kaynaklar ve sayısal iddialar doğrulanabilir mi?
• Metnin farklı bölümlerindeki rakamlar, süreler ve hedefler birbiriyle tutarlı mı?
• Yapay zekâ kullanıldıysa TÜBİTAK rehberine uygun biçimde ele alınmış mı?

Benim genel yaklaşımım şu: iyi bir TÜBİTAK projesi, çok teknik kelime kullanılan proje değildir. Problemi iyi tanımlayan, yeniliğini kanıtlayan, yöntemini planlayan ve projenin sonunda neyin değişeceğini ölçülebilir biçimde gösteren proje daha güçlüdür. Başvuru formundaki her alanı da bu ana hikâyenin farklı bir parçası olarak görmek gerekir.