tohum
TR
Panele Git
← Blog’a dön

Tohum AB Teknik Gereksinimleri Nasıl Dönüştürdü, Teknik Borcun Üstesinden Nasıl Geldi ve Öğrenmeyi Bir Kariyer Motoruna Nasıl Çevirdi

1. Bu Hikâyeyi Neden Yazdık?

Her girişim eninde sonunda şunu keşfeder: Teknolojisi ürünün yalnızca yarısıdır; diğer yarısı, o teknolojiye hayat veren mühendislerin bilgisidir. Göteborg (İsveç) ve İzmir (Türkiye) merkezli Tohum AB’de, ESP32 beynini hassas NPK sensörleri, Li-ion bataryalar, yüksek verimli güneş panelleri, SIM tabanlı veri aktarımı ve MQTT veri hatlarıyla eşleştiren, sahaya hazır toprak ölçüm düğümleri tasarlıyoruz. Özellik listesi büyüdükçe kendimizi firmware fork’ları, aceleyle yapılmış PCB revizyonları ve giderek uzayan bir “bunları sonra düzeltiriz” listesiyle cebelleşirken bulduk.

Bu yazı, şunları nasıl yaptığımızın bir muhasebesi:

  1. Teknik gereksinimlerimizi, agronomik doğruluk, ultra düşük güç ihtiyaçları ve üretim kısıtları arasında denge kuracak şekilde tanımladık.

  2. Teknik borcumuzu denetleyip sayılara döktük — hatalı BLE driver’larından kopyalanmış güç ağacı şemalarına kadar.

  3. Eksikleri stres kaynağı değil, büyüme fırsatına çeviren bir yetkinlik matrisi öğrenme planı kurduk.

  4. Her çalışanın geleceği, her ürünün geleceği kadar ciddiye alınsın diye kariyer gelişimini günlük mühendislik ritmimize gömdük.

İster ilk sensör düğümünüzü tasarlıyor olun, ister on binlerce cihazlık bir filoyu ölçeklendiriyor olun, bu yol haritasının işinize yaramasını umuyoruz.

2. Misyonu Çerçevelemek — “Havalı Bir Cihaz”dan Ölçülebilir Sonuçlara

Kuruluş vizyonumuz gayet netti: Çiftçilere toprak sağlığına dair uygun maliyetli, telemetri açısından zengin içgörü sun ki gübreyi ve sulamayı bilimsel hassasiyetle optimize edebilsinler. Bu vizyonu bir mühendislik backlog’una çevirmek, tüm paydaşların anlayabileceği bir dil gerektiriyordu — pazarlamacılar, saha agronomistleri, firmware hacker’ları ve donanım tasarımcıları dahil.

Bu yüzden her üst düzey gereksinimi, kullanıcının göreceği bir sonuç ve ardından mühendislik metrikleri olarak yazdık:

Sonuçlar netleşince ödünleşimler de görünür hale geldi: Daha büyük bir yerel buffer BOM maliyetini artırıyor; daha sık örnekleme agronomik çözünürlüğü yükseltiyor ama bataryayı tüketiyor. Her gereksinim somut sayılara bağlanabildiği için, “olsa iyi olur” özelliklerin revizyon A kartlarına sızma tuzağından kurtulduk.

3. Teknoloji Yığınını Parçalara Ayırmak

Ardından çözümü altı odak alanına böldük; her birinin gereksinimlerinden, risk kayıtlarından ve Jira epic’lerinden sorumlu bir “teknoloji sorumlusu” oldu:

Odak Alanı

Temel Teknoloji

Başarı Metriği

İşlemci ve RTOS

ESP32-S3, FreeRTOS, ESP-IDF

Döngü başına %100 CPU kullanımı < 20 ms

Toprak Sensörleri

İyon seçici elektrot dizisi

Laboratuvar referansına karşı ±%2 tam ölçek doğruluk

Enerji

3,7 V Li-ion, MPPT buck-boost güneş şarj cihazı

250 mA’de ≥%95 şarj verimliliği

Bağlantı

SIM7600 LTE-CAT-M1 + Wi-Fi

> %98 başarılı publish oranı

Bulut ve Protokol

AWS IoT Core’a MQTT/TLS

Gecikme < 3 s p95

Muhafaza ve Uyum

IP67 PC-ABS + potting

CE, FCC, ROHS, IP67 püskürtme testlerini geçmek

Tek sayfalık bir “Mimari Kanvas” bağımlılıkları görselleştirdi: Toprak sensör kartı MCU’ya I²C verisi besliyor; güç alt sistemi coulomb sayacıyla SoC raporluyor; modem, UART veri yolunu RS-485 debug hattıyla paylaşıyor; bulut kural motoru veriyi Grafana için InfluxDB’ye dağıtıyor.

Bu kanvas, sonraki tüm tasarım dokümanlarının içindekiler tablosu haline geldi; silo düşünmeyi engelledi ve bir spesifikasyon değiştiğinde her mühendisin kime yazacağını bilmesini sağladı.

4. Teknik Borcu Sayılara Dökmek — Anekdotlardan Rakamlara

Birçok girişim gibi bizde de “demo gününden sonra düzeltiriz” kestirmeleri birikmişti:

Ward Cunningham’ın teknik borç metaforuna benzer üç adımlı bir denetim benimsedik:

  1. Envanter – Tüm ekibin katıldığı bir “borç safarisi”, bir Confluence sayfasında 126 kalem üretti.

  2. Ciddiyet ve Faiz Oranı – Her kalem, etki için 1-5 ve sonra düzeltmenin maliyeti için 1-5 puanlandı.

  3. Anapara Tahmini – Hemen düzeltilse kaç saat gerekeceği.

Sonuç şuna benziyordu:

Borç Kalemi

Etki

Faiz

Anapara (saat)

Ağırlıklı Puan

BLE driver fork’u

5

5

40

1 000

Tutarsız ADC ölçeği

4

3

8

96

Flash script’i

2

2

6

24

Yüksek puanlı kalemler sprint backlog’larına terfi etti. Düşük puanlılar “kar yığınında” kaldı, ama açık son kullanma tarihleriyle. Bu sayısal mercek tartışmaları kişisellikten arındırdı: Önceliğe en gür ses değil, sayılar karar verdi.

5. Yetkinlikleri Ürünle Eşleştirmek — T Şeklinde Matris

Borç denetimine paralel olarak, bazı “borçların” aslında bir yetkinlik açığı olduğunu fark ettik. Daha önce gördüğünüz beş seviyeli çerçeveyi (Tam Acemi → Uzman) ödünç aldık ve 25 yetkinlik listeledik (C/C++, ESP-IDF, FreeRTOS, Git, PlatformIO, Linux CLI, Unity Test, CI/CD, Jira/Confluence, Elektronik, PCB tasarımı, Güç bütçeleme, Batarya yönetimi, Hücresel haberleşme, IoT protokolleri, TLS, Sensör kalibrasyonu, Veri kaydı, OTA, Kontrol teorisi, Python/Bash, Bulut panoları, Yasal uyum, Dokümantasyon araçları).

Her mühendis kendini değerlendirdi, bir teknoloji lideri de kalibrasyon için moderatörlük yaptı. Sonuçlar bir ısı haritası oluşturdu:

Name   C/C++ ESP‑IDF LTE  PCB  MQTT Cloud ...
Ali      4      3      2    5    4     2
Elif     2      2      4    3    3     5
Mert     5      4      1    2    3     2

Buna T Şeklinde Matris diyoruz — herkes bir alanda derin, temellerde geniş. Riski anında ortaya çıkardı: Ali (LTE seviye 2) tatile giderse hücresel sorunlar bir sprint’i durdurabilirdi. Büyüme yollarını da aydınlattı: Elif, Mert’ten ESP-IDF öğrenirken bulut konusunda mentorluk yapabilirdi.

6. Öğrenme Planını Kurgulamak — Açıklardan Hedeflere

Bir öğrenme planı, ancak ürün ihtiyaçlarına ve bireysel motivasyona bağlanırsa inandırıcı olur. Üç somut adım attık:

  1. Yol Haritası Kilometre Taşlarına Hizalı Yetkinlik Kümeleri
    Q3: secure boot ve flash şifreleme → herkes mbedTLS’te Seviye 3’e.
    Q4: delta-OTA yayını → iki firmware geliştiricisi veri kaydı ve partition sanatında Seviye 4’e.

  2. İşe Gömülü Pratik
    – Haftada iki kez, mentor/menti rolleri dönüşümlü pair-programming seansları.
    – “Cuma Spike’ı”: Haftanın temasıyla ilgili herhangi bir şeyi kurcalamak için 4 saatlik serbest alan — Kalman filtresi denemeleri, PlantUML kart diyagramları vb.

  3. Görünür İlerleme Metrikleri
    – Aylık “öğrendiğin şeyi göster” yıldırım sunumları.
    – “Elif ESP-IDF’i 3’e yükseltti: OTA örneği yayında.” gibi kişisel epic’lerin olduğu bir Jira Goals panosu.

Sprint hızının %10’unu açıkça öğrenme görevlerine ayırdık. Finans başta kapasite kaybına gözlerini kırpıştırdı, ama elde tutma rakamları düzeldi: Gönüllü işten ayrılma 18 ay boyunca %0’a indi.

7. Kariyer Gelişim Döngüsü — Önce İK Değil, Mühendislik

Geleneksel değerlendirme döngüleri yetersiz kalıyordu. Onların yerine hafif bir Kariyer Kanban’ı koyduk:

Sütun

Definition of Done

Keşfet

Ürün kilometre taşına bağlı öğrenme hedefini belirle

Planla

Mentor, kaynak ve son tarih seç

Uygula

Kursu/kitabı/pair görevini tamamla

Göster

Çalışan kodu, şemayı veya dokümanı sun

Yansıt

Mentorla 15 dakikalık retro; yetkinlik matrisini güncelle

Mühendisler kartları kendi hızlarında ilerletiyor; liderler yalnızca önü açmak ya da kutlamak için devreye giriyor. Bu akışkanlık, pull request’lerin işleyişini yansıtıyor — öğrenme de sadece bir başka branch.

8. Sahadaki Sonuçlar — Daha Az Kesinti, Daha Mutlu Çiftçiler

Çerçeveyi devreye aldıktan on iki ay sonra:

En çarpıcısı, spesifikasyondan ilk doğrulanmış prototipe geçiş süresi sekiz haftadan 4,5 haftaya indi. Mühendisler bunu çapraz eğitime bağladı: Python’da Seviye 3’e ulaşan PCB tasarımcısı, bir haftalık test tezgâhı emeğini kurtaran bir kalibrasyon script’i yazdı.

9. Geleceğe Sahip Çıkmak — Öğrenme Neden ESG Tüzüğümüzün Parçası

Sürekli öğrenmeyi yalnızca bir İK ayrıcalığı olarak değil, çevresel ve sosyal bir zorunluluk olarak konumlandırıyoruz:

Her çeyrek, eğitim saatleri ile kilit OKR’lar (hata yoğunluğu, enerji verimliliği) arasındaki korelasyonları gösteren dahili bir “Öğrenme Etki Raporu” yayımlıyoruz. Yönetim kurulu bunu gelir rakamlarının yanında inceliyor — insan metriklerinin yönetim kurulu masasında eşit söz hakkı kazandığının kanıtı.

10. Çıkarılan Dersler ve Diğer Ekipler İçin İpuçları

  1. Önce sonuç odaklı gereksinimler yazın; teknoloji seçimleri doğal olarak peşinden gelir.

  2. Teknik borcu sayılara dökün ki tartışmalar duygu değil, matematik olsun.

  3. Görsel yetkinlik matrisleri, yetenek darboğazlarını organizasyon şemalarından daha hızlı ortaya çıkarır.

  4. Öğrenmeyi inandırıcı kılmak için odaklanmış zaman ayırın (biz %10 seçtik).

  5. Öğrenmeyi canlı koda bağlayın — merge edilmiş bir PR, her MOOC’tan daha çok öğretir.

  6. Küçük zaferleri kutlayın; örtük bilgiyi paylaşmakta yıldırım sunumlar, slayt destelerini döver.

  7. Yönetim desteğini kazanmak için öğrenmeyi ürün KPI’larına açıkça bağlayın.

11. Tohum AB İçin Sırada Ne Var?

2026 yol haritamızda NB-IoT + LoRa çift bağlantı, yapay zeka destekli besin tahminleri ve IP69K yüksek basınçlı yıkamalı tarım operasyonlarını hedefleyen dayanıklı bir v6 muhafaza var. Her yeni cephe, yetkinlik matrisine yeni sütunlar doğuruyor — ultra düşük güçlü ML, LoRaWAN MAC derinlemesine incelemeleri, yüksek basınçlı sızdırmazlık laboratuvarları. Çerçeve yaşamaya devam ediyor: Her sıçrayışta gereksinim-borç-öğrenme döngüsünü tekrarlayacağız.

12. İnsanlar Üzerine Son Bir Söz

Silikon çipler yaşlanır; güneş panelleri yıpranır; en verimli toprağın bile eninde sonunda beslenmesi gerekir. Değeri sonsuza kadar katlanarak büyüyen tek varlık, insan potansiyelidir. Öğrenme sürecimizi, şemalara ve koda uyguladığımız titizlikle mühendislik ederek erdemli bir döngü keşfettik: Daha iyi ürünler daha çok öğrenmeyi finanse eder, bu daha iyi kariyerler doğurur, o da daha iyi ürünler üretir.

Hikâyemizden tek bir şey alacaksanız, o da şu olsun: Mühendislerinize, batarya kimyanıza yatırım yapar gibi yatırım yapın. İkisi de enerji depolar, ama yalnızca biri geleceği icat edebilir.