Team IMU Yeni Dönem için Düzenleme Önerileri

1. Tanımlar

2. Problemler

Domain A: İnsan Kaynağı

Genel Eleman Eksikliği

• Gözlem: Bir kişiye birden fazla görev düştü.
• Etki: Üyeler işlerini aksattığında süreç bütüncül olarak yavaşlıyor.
• Kök Neden: Ön elemelerde potansiyeli olanlar olsa bile düşük değerlendirme alıp elenebiliyor.

Alan Bazında Eleman Eksikliği

• Gözlem: Takımda mekanik süreciyle ilgilenebilecek bir kişi vardı ve o da aktif olamayınca problemler yaşandı.
• Etki: Diğer takım üyeleri mekanik problemlere çözüm üretmeye çalışıyor.
• Kök Neden: Bu alanla ilgilenebilecek hedef kitleye ulaşamıyoruz ve hedef kitle çok düşük.

Know-How Aktarımı ve Yüksek Sirkülasyon

• Gözlem: Üyeler sıfır bilgi ile geliyor. 3 ve 4. sınıflardan alınan üyeler mezuniyet moduna girip kopuyor.
• Etki: Know-how sıfırlanıyor. Bütün mimari kaptanın tekeline kalıyor. Bölümler arası işler senkronize ilerlemiyor.
• Kök Neden: 1 ve 2. sınıflara ulaşamıyoruz.

İdari ve PR İşlerinin Üstlenmesi

• Gözlem: Kaptan hem sosyal medya PR kısmı ile, hem idari yazışma ve belgeleme kısımları ile, hem proje sürecinin genel yönetimi ile, hem de alt sistemlerin detayları ile ilgileniyor.
• Etki: Bir veya birden fazla kısmın aksaması: Bu yıl herhangi bir PR çalışması yapılamadı. Gömülü kısmı ile ilgilenirken bir süre genel yönetim süreci aksadı.
• Kök Neden: Yarışma takımlarında tipik olarak bulunan PR görevlisi / idari işler görevlisi alınmaması

Domain B: Teknik Yeterlilik

Birincil ve İkincil Geliştirme Araçları Kullanımında Bilgi Eksikliği

• Gözlem: Üyeler birincil araçlara bütüncül olarak hakim değil. İkincil araçları kullanmıyorlar veya yanlış ve tehlikeli bir şekilde kullanıyorlar.
• Etki: Süreçte edinilen gelişmeye zarar (kod silme) veya collabrative development’ın ciddi derecede engellenmesi.
• Kök Neden: Birincil araçlar için atılan eğitimler sadece sonuç odaklı, tamamlanma yüzdesine bağlı sayısal değerden ibaret. İkincil araçlar konusunda herhangi bir eğitim henüz atılmadı.

Bilinçsiz AI Kullanımı

• Gözlem: Üyeler meat proxy olarak davranıyor veya agentic AI araçlarını herhangi bir sandbox kısıtlaması olmadan çalıştırıyorlar. Problemi bisect etmek yerine LLM’lere “şu sorunu çöz” ve “olmadı çalışmadı” şeklinde kendilerini sürecin dışına çıkartıyorlar. LLM’lere çalıştıkları ortam hakkında context vermiyorlar. Sadece hata mesajını veya problemin dışarıdan görünüşünün özetini veriyorlar. `ros2 launch` gibi temel bir komut bile LLM’e “aracı çalıştır” denilerek çalıştırılıyor. Planlama konusunda yapay zeka ile coworking yapmak yerine kritik düşünme kısmını modele verip rolleri değiştiriyorlar.
• Etki: Geliştirme sürecinde üyeler yazılan kodun yapısından bihaber kalıyorlar. Bütün geliştirme süreci LLM’in context’ine bağlı çalışıyor. LLM’in mevcut olmadığı durumlarda geliştirme duruyor.
• Kök Neden: LLM’lere prompt hazırlama konusunda bilgi eksikliği mevcut. AI teknolojisinin proje gelişim ve şahsi gelişim sürecinde nerede yer alması gerektiği konusunda fikirleri yok. İstenilen çıktının elde edilmesi için en kısa yöntem aranıyor.

Domain C: Operasyonel Süreç

Lab İmkanlarının Değerlendirilmemesi

• Gözlem: Üyeler ROS Bag alıp evde veya başka ortamda çalışmayı tercih ediyor.
• Etki: Geliştirme sürecinde yüz yüze iletişim gerektiren durumlarda ve takımca kafa kafaya vermeyi gerektiren durumlarda sorun yaşanıyor. İletişim problemlerine sebep oluyor. Üyeler takım kaptanına “x arkadaş şu kısımda nasıl bir düzenleme yaptı?” gibi sorular yöneltiyor.
• Kök Neden: Biltam tarafında yapılan yoğun internet filtrelemesinin sebep olduğu bağlantı sorunları, fiziksel alan ve masa sıkıntısı

Yarışma Sürecinin Takip Edilmemesi

• Gözlem: Üyeler Teknofest başvurusunun form süreçlerini, sonuç tarihlerini ve dönüş olarak verilen feedback’leri takip etmiyor.
• Etki: Projenin işleyişine ilgisizliğe sebep oluyor
• Kök Neden: Tarihlerin ve işleyişsel sürecin baştan anlatılmaması ve süreç takibi konusunda katı kurallar konulmaması

Saha Testi Zorluğu

• Gözlem: Saha testlerinin başlaması için çok geniş vakit ayrılabilecek zaman aralıkları (dönem bitişi) gelene kadar saha testlerine çıkılamıyor.
• Etki: Aracın fiziksel testleri Haziran ayına kadar yapılamıyor.
• Kök Neden: Geliştirme sürecinde aracın kütüphane otoparkında durması dönem içerisinde araca hasar gelme ihtimaline sebep oluyor. Aracın labda durması test başında ve sonunda zorlu kas gücü gerektiriyor.

3. Çözüm Önerileri

Kaptan Yüklerini Dağıtma

İdari işleri, PR çalışmasını ve görsel medya biriktirmesinin üstlenecek bir üye alınmalıdır.

Eğitim ve Alım Sürecinde Revizyon Önerisi

Mevcut sistem nasıl?

1. Eğitim yılı başında başvurular toplanıyor.
2. Bir süre sonra başvurular üzerinden ön eleme yapılıyor.
3. Ön elemeyi geçenler mülakat sürecinden geçiyor.
4. Mülakatların sonuçlanması ile üyeler istedikleri alana göre eğitim gruplarıona dağıtılıyor.
5. Güz dönemi sonuna kadar eğitim ve ödevlendirmeler devam ediyor.
6. Üyeler performanslarına göre takımlara bölüştürülüyor.

Neden değişiklik gerekiyor?

• Gerçek yetkinlikler ölçülmüyor: Üyelerin neyi yapıp yapmadığını ciddi derecede üstün körü olarak kontrol ediyor. Geçerli sistem, nihai çıktı olarak performansları iyi olsa bile uygulamada iş çıkaramayan üyeleri eleyemiyor.
• Potansiyel adaylar diğer kulüplere kaybediliyor: Görevlendirmelerin geç başlaması yüzünden potansiyel üyeler BMT Hidrocar projesine ve diğer kulüplere kaybediliyor.
• Proje süreçlerine vakit kalmıyor: İlk dönem finallerinden sonra takımlara dağıtımlar gerçekleşiyor. Uzun saha testi gerektiren Robotaksi gibi projelerde üyelerin alışma süreci yarışma hazırlığını kötü etkiliyor.
• Efektif filtreleme yapılmıyor: Ön eleme aşamasında mülakata çağırılacak kişileri sınırlandırmak gerektiği için gerçekten istekli olup bunu formda yazılı olarak belirtememiş adaylar eleniyor.

Nasıl bir değişiklik gerekiyor?

1. Uzun süreli eğitim yerine bir-iki aylık sürece sığdırılmış yoğun bir görev istekli ve kararlı olanları öne çıkarır.
2. Birden fazla ufak iş yerine devamlılık sağlanması gereken büyük bir iş paketi adayın collabrative development ve ikincil araçları kullanmadaki performansını görmeye yardımcı olur.
3. Önceden verilen her takımda kullanılabilecek generic ödevler yerine takım ve iş gereksinimleri bazında nokta atışı görevler verilmelidir.

Süreç nasıl işler?

1. Başvuru süreci: Eylül ayının sonuna kadar başvurular toplanır.
2. Görevlendirmeler: Ekim ayının başında bir - iki aylık bir zaman içerisinde bitirmeleri gerekilen görevler verilir. Görevin girdisi, çıktısı, kuralları ve metodolojisi açık bir şekilde belirtilir. Kullanabilecekleri ve çalışacakları kaynaklar verilir ancak zorunlu tutulmaz.
3. Çıktı Kontrolü: Verilen süre dolduktan sonra bir hafta boyunca Git log’ları, kaynak kodunun düzeni, yapay zeka kullanım oranı ve prompt yetenekleri, ikincil araçların nasıl kullanıldığı ve işin zamana nasıl bölündüğü incelenir. Tek büyük commit atanlar direkt elenir. Görev çıktıları tamamen doğru olmasa bile verilen emek durumu incelenir.
4. Yüz Yüze Kod Savunması: Çıktı kontrolünü geçenler laba çağırıp kodunu anlatması istenir. Kodun bölümleri hakkında soru sorulur. İkincil araçlar konusunda bilgileri test edilir.

Aktif Tanıtım Çalışmaları

Yıl başında açılan standlar ve sözlü anlatımlar pasif tanıtımdır. Doğrudan hedef kitleye ulaşabileceğimiz tanıtım çalışmaları yapılmalıdır. EEM 1 ve 2. sınıflar için kısa bir videolu sunum hazırlanıp izlemeleri sağlanabilir. Okuldaki diğer kulüplerin yaptığı tanıtım çalışmalarına benzer olarak afişler ve sık duyurular yapılarak ismin sürekli duyulması sağlanabilir. Nokta atışı görevler söylenerek iş ilanı formatında paylaşımlar ile kişisel yeteneklere hitap edilebilir.