Müşterinin bir ürünü teslim almaya hazır olmasıyla araştırma ekibinin teknik belirsizliği açıklaması aynı sonuç değildir. Bir prototip ticari ihtiyacı kısmen karşılayabilir; buna karşılık deney sırasında başlangıç varsayımının yanlış olduğu anlaşılabilir. İki sonucu ayrı kaydetmek, projenin ne ürettiğini daha doğru anlatır.
Siparişe dayalı Ar-Ge desteği araştırmasında müşteri ve geliştiricinin testten ne beklediğini erken konuşun. Bu rehber bir başvuru değerlendirmesi veya sözleşme önerisi sunmaz. Hibe Raporu ile hazırlık görüşmesinde müşteri ihtiyacı, teknik araştırma sorusu ve test kanıtlarını ayrı dosyalar olarak ele alabilirsiniz.
Müşteri ihtiyacını ölçülebilir bir kullanım durumuna çevirin
“Daha hızlı ürün istiyoruz” cümlesi tek başına test planı kurmaya yetmez. Hangi işlem, hangi koşul ve hangi başlangıçla karşılaştırılacak? Müşterinin kullanım ortamını, uyguladığı malzemeyi ve süreçte yaşadığı sorunu açıklayın. Doğrulanmamış hedef değerleri mevcut performans diye göstermeyin.
Ar-Ge projesi desteği için hazırlanan anlatımda müşteri talebi bir başlangıç girdisidir. Teknik ekibin hangi bilinmeyeni araştıracağı ayrıca yazılmalıdır. Bir bileşenin satın alınmasıyla çözülebilen ihtiyacın araştırma gerektiren kısımla ilişkisini açıkça kurun. Her müşteri isteğinin aynı teknik belirsizliği taşıdığını varsaymayın.
TÜBİTAK 1707 sayfası müşteri ve tedarikçi kuruluş rollerini birlikte açıklıyor. Somut başvuru koşulları güncel çağrı metninden alınır. Kendi test toplantınızda da kullanımı açıklayan tarafla araştırma yöntemini geliştiren tarafın sorumluluklarını birbirine karıştırmayın.
Kabul ölçütü ile deney ölçütünü farklı sütunlara yazın
Temsili bir projede müşteri ürünün kendi hattında belirli bir işi yapmasını bekliyor olsun. Araştırma ekibi ise bu sonuca ulaşmak için malzeme veya tasarım seçeneklerini karşılaştırabilir. Müşteri kabulü kullanım sonucuna, deney ölçütü seçenekleri karşılaştıran veriye odaklanır. Birinin kaydı diğerinin yerine geçmez.
Prototip geliştirme hibesi araştırmasında fotoğraf veya teslim tutanağıyla yetinmeyin. Testin hazırlığı, kullanılan sürüm, gözlem ve sonuç verisi de teknik açıklamanın parçaları olabilir. Bunlar önerilen şirket içi kayıtlardır; kurumun istediği raporların formatı ve kapsamı kendi belgelerinden alınır.
Kabul ölçütü daha sonra değişirse önceki sürümü koruyun. Müşterinin yeni talebiyle ilk testin başarısız olmasını aynı olay gibi raporlamayın. Neyin değiştiği, değişikliği kimin istediği ve yeni testin neyi araştıracağı ayrı açıklanmalıdır. Teknik kayıt, sözlü görüşmenin hatırlanmasına dayanmamalı.
Başarısız denemeyi yalnız sonuç etiketiyle kapatmayın
Beklenen performans elde edilmediğinde deneyin hangi varsayımı sınadığını yazın. Ölçüm verisinin güvenilir olup olmadığı ile tasarımın hedefi karşılamaması farklı sorulardır. Cihaz kurulumu veya veri kaydı sorunluysa önce deney koşullarını değerlendirin; doğrudan tasarım hakkında kesin sonuç çıkarmayın.
TEYDEB başvurusu hazırlığında iş paketlerini açıklayan ekip, deneme sonunda hangi kararın verileceğini önceden tanımlayabilir. Bir seçenek elenecek mi, yeni malzeme mi araştırılacak, aynı test başka koşulla mı tekrarlanacak? Bu karar çerçevesi öğrenilen bilgiyi proje akışına bağlar.
Ar-Ge projesi desteği için başarısız her denemenin gideri kabul edilir gibi bir sonuç çıkarılamaz. Bu rehber yalnız araştırma kaydının açıklığına odaklanır. İlgili giderin, faaliyetin ve raporlamanın uygunluğu program kuralları ve kurum değerlendirmesiyle ayrıca incelenir.
Bütçe değişikliğini teknik karara bağlayın
Yeni bir deneme gerektiğinde kullanılacak malzeme, personel zamanı veya dış hizmet değişebilir. TÜBİTAK proje bütçesi üzerinde yalnız toplamı güncellemek yerine değişikliğin hangi teknik karardan doğduğunu gösterin. İlk planla yeni plan arasındaki farkı açıklayan kısa bir kayıt ekleyin.
Dış laboratuvara gönderilecek örneğin kimliği, istenen test ve teslim raporunun kapsamı belirli olsun. Aynı test hem iç ekip hem dış hizmette yapılacaksa farklı amaçları açıklayın. İki farklı faturanın bulunması, iki ayrı araştırma işinin bulunduğunu kendiliğinden göstermez.
Ar-Ge danışmanlık ücreti için alınan hizmetle teknik ekibin araştırma sorumluluğu ayrı tarif edilmelidir. Danışmanın dosyayı düzenlemesi deneyin gerçekleştirilmiş olduğunu kanıtlamaz. Teknik veri kaynağı, inceleyen kişi ve kullanılan sürüm proje arşivinde bulunmalıdır.
Test toplantısını açık karar listesiyle kapatın
Toplantı sonunda müşteri kabul durumu, deneyin teknik sonucu ve sonraki araştırma kararı ayrı satırlarda bulunsun. Her satırın dayanak dosyası ve sorumlusu belli olsun. Müşteriyle imzalanacak belgelerin kapsamını ise kendi hukuki ve ticari danışmanlarınızla değerlendirin.
Hibe Raporu ile proje hazırlık kapsamını görüşürken bu karar listesini paylaşabilirsiniz. Teknik belirsizlik rehberi ve iş paketi ve dış hizmet yazısı hazırlığın diğer parçalarını tamamlar. Siparişe dayalı Ar-Ge desteği araştırmasını kanıtlanabilir proje akışıyla birleştirmek, görüşmenin yalnız program adına odaklanmasını önler.
Resmî kaynaklar ve kontrol yolu
1707 sayfası rol ve program araştırmasının başlangıç kaynağıdır. Burada önerilen test kayıtları çağrının zorunlu raporlarının yerine kullanılmaz.
Test kararını proje dosyasına bağlayın
Müşteri kabulü, deney sonucu ve sonraki karar kayıtlarınızı Hibe Raporu proje hazırlığı görüşmesine birlikte getirin. Teknik çıktı ile ticari teslimin farkını dosyanızda görünür tutun.
Müşteri gösteriminde ayar elle düzeltilmişse
Bir dolum makinesi müşteri gösteriminde on şişeyi hedef seviyede doldursun. Videoda operatörün altıncı şişeden önce basıncı elle ayarladığı görülüyor. Müşteri bu şekilde çalışmayı kabul edebilir. Ancak siparişe dayalı Ar-Ge desteği için hazırlanan deney defterinde otomatik kontrolün on şişe boyunca kararlı kaldığı yazılırsa sonuç yeniden üretilemez. Ayar anını videonun zaman koduyla işaretleyin, müdahale öncesi ve sonrası ölçümleri ayrı dizilerde saklayın. Sonraki denemede operatör yalnız izlesin ve basınca dokunursa deneyi hangi anda keseceğinizi baştan belirleyin.
