2 aydır task yazmıyorum — Mustafa Çongara

Başlık biraz clickbait gibi durabilir ama teknik olarak doğru. 2 aydır bir task’ı sıfırdan oturup yazmadım. Bunun neden iyi bir şey olduğunu, nasıl kurduğumu ve ne kazandığımı anlatacağım.

Sorun

ikas’ta Product Manager olarak çalışıyorum. Küçük ama hızlı hareket eden bir ürün ekibimiz var. Design → Backend → Frontend şeklinde ilerleyen bir iş akışımız var, ya da öyle olmaya çalışıyorduk.

Pratikte birkaç şey hep bozuluyordu:

Standart yoktu. Her task farklı bir formatta yazılıyordu. Kimisi çok kısa, kimisi çok uzun, kimisi önemli bir context’i atlıyordu.
Flow her zaman sıralı gitmiyordu. Design çıktıktan sonra backend’de logic değişikliği olabiliyordu. API tasarımı netleşince tasarıma geri dönmek gerekebiliyordu. Bu durumlarda handoff süreci yorucu ve hata yapılan bir noktaya dönüşüyordu.
Her adımda uzun toplantılar gerekiyordu. Özellikle backend → frontend technical handoff bazen saatler alıyordu. Çünkü context her seferinde sözle aktarılıyordu.
PM tarafında bottleneck oluşuyordu. 3 PM olarak çalışıyoruz ama her birimiz farklı formatlarda, farklı seviyelerde detayla yazıyorduk. Tutarsızlık birikmişti ve süreç yavaşlıyordu.

Sorun tooling değildi. Sorun, işi nasıl tanımladığımızdı.

Fikir nereden geldi

2025 sonunda izlediğim bir video* benim için net bir şeyi çerçeveledi: AI’dan kaliteli çıktı almanın yolu, AI’ı iyi yönlendirmekten geçiyor. AI bir chat arayüzü değil; ne kadar iyi input verirseniz o kadar iyi çıktı üretiyor.

O dönemde ekip olarak 2026’ya daha verimli girmek istiyorduk. Bu iki şey birleşince şunu düşündüm: “Biz zaten iyi task yazmak istiyoruz. Bunun için guide ve template’ler oluşturalım. Hem ekip bunları okusun, hem de AI bu yapıları kullanarak süreci hızlandırsın.”

Başta bu yapı şuydu: bir kere okunacak, template manuel doldurulacak, AI sadece yardımcı olacak.

Sonra biraz daha ileri gitti.

Stack ve klasör yapısı

Kullandığım araçlar:

Claude Code — terminalde çalışan AI agent. Tek bir komutla ayağa kaldırıyorum.
Figma MCP — Claude, Figma tasarımlarını doğrudan okuyabiliyor.
Linear MCP — Claude, task’ları doğrudan Linear’a gönderebiliyor.
Bir klasör — templates, guide’lar, çıktılar. Hepsi burada.

Klasör yapısı şöyle görünüyor:

pm-workspace/
├── CLAUDE.md
├── feature-be-template.md
├── feature-be-guide.md
├── feature-fe-template.md
├── feature-fe-guide.md
├── bug-be-template.md
├── bug-be-guide.md
├── bug-fe-template.md
├── bug-fe-guide.md
├── design-yeni-template.md
├── design-ekleme-template.md
├── design-redesign-template.md
├── design-guide.md
├── sources/
│   ├── api-docs-stok-yonetimi.md
│   └── ...
├── output/
│   ├── modal-sozlesme-content.md
│   └── ...
└── tasks/
    ├── feature-be-affiliate-komisyon.md
    ├── feature-fe-siparis-listesi.md
    └── ...

Her task tipi için iki dosya var: template ve guide.

template → doldurulacak şablon. Placeholder’lar köşeli parantez içinde.
guide → template’in nasıl doldurulacağını anlatan rehber. İyi/kötü örnekler, ipuçları, o bölümde nelere dikkat edilmesi gerektiği.

sources/ klasörü dışarıdan gelen materyaller için — API dökümanı, bir toplantı notu, başka bir ekibin hazırladığı içerik. output/ ise task’ın ara çıktıları için: bir modal’ın sözleşme metni, bir email içeriği, doğrudan Linear’a gitmeyen ama sürecin parçası olan her şey.

Toplam 7 tip var: Backend Feature, Frontend Feature, Backend Bug, Frontend Bug, Design (Yeni Özellik), Design (Ekleme), Design (Redesign).

Bunların dışında doğrudan sistemimin parçası olmasa da sürece çok katkısı olan bir şey daha var: Frontend Dökümanı. Backend developer, yazdığı API değişikliklerini ekibe özel bir skill ile hazırlayıp kendi task’ına ekliyor. Ben bir Frontend işine başlarken Claude’u bu dökümanla da besliyorum — Claude’un önünde hem tasarım hem API hem de ikisi arasındaki fark oluyor.

Sistemin beyni: CLAUDE.md

Bu klasörün içinde CLAUDE.md adında bir dosya var. Bu dosya Claude’a şunları söylüyor:

Bu klasör ne için var, nasıl çalışıyor
Task’lar hangi dilde ve tonda yazılacak
Her template tipi için hangi bölümler gerekli, hangiler opsiyonel
Bir bölümü doldururken hangi noktalarda soru sorması gerekiyor
Linear’a gönderirken hangi task tipi hangi team’e, hangi label’a gidecek (ID’leriyle birlikte)

Yani ben “Backend Feature yaz” dediğimde, Claude zaten biliyor: bu task Development team’e gidecek, Feature label’ıyla, Backend Feature template’ine göre doldurulacak. Ekstra bir şey söylememe gerek yok.

AI seni yönlendirir, sen değil

Klasörün içindeyken terminalde Claude’u başlatıyorum. Sonra işi anlatmaya başlıyorum.

Claude, template’i bölüm bölüm geziyor. Her bölüm için bana soruyor. Yazdığı kısmı gösterip “böyle yazdım, uygun mu?” diye teyit alıyor. Bilgi eksikse ama guide’da açıklaması varsa oradan örnekle yönlendiriyor.

Ben AI’ı yönlendirmiyorum — AI beni yönlendiriyor.

Ne kadar çok detay verirsem o kadar az soru geliyor. Az detay verirsem daha çok soru. Ama her iki durumda da sonuçta sistematik, eksiksiz bir task çıkıyor.

Figma MCP + Frontend Dökümanı birlikte devrede olduğunda işler daha da ilginç bir hal alıyor. Örneğin bir Frontend task’ı hazırlarken hem Figma linkini hem de Frontend Dökümanı’nı veriyorum. Claude ikisini okuyup eşleştiriyor. Bana şöyle bir şey diyebiliyor:

“API’de boolean shouldRestock alanı var ama tasarımda bu görünmüyor. Default true mu olacak, yoksa tasarım güncellenmeli mi?”

Ben bunu tarif etmedim. Claude dökümanı ve tasarımı okudu, aralarındaki uyumsuzluğu buldu ve varsayım yapmak yerine soru sordu. “Tasarım güncellenmeli” desem, o an hemen bir Design task’ı da çıkarabiliyoruz.

Dosyadan Linear’a

Her task tamamlandığında bir .md dosyası olarak tasks/ klasörüne kaydediliyor.

tasks/feature-fe-stok-yonetimi.md

Sonrasında elle Linear’a taşımak yerine tek kelime yazıyorum: taskla

Claude, dosyayı okuyup Linear MCP üzerinden issue oluşturuyor. Doğru team, doğru label, Backlog status. Markdown formatında yazılmış, okunabilir bir description.

Buradan sonra Linear içinde ben devralıyorum: task’ın son halini okuyorum, doğru kişiye ve doğru cycle’a atıyorum. Bu noktayı aşırı otomatikleştirmek istemiyorum. Kimin ne zaman ne alacağı kararı bende kalmalı.

Somut çıktılar

Hız. Daha önce backend developer’dan konuyu dinleyip task yazıp frontend’e aktarmak yarım günü bulabiliyordu. Şimdi 10-15 dakika.

Tutarlılık. Her task aynı yapıda.

Gözden kaçan şeyler yüzeye çıkıyor. Bir özelliği tarif ettiğimde aklımda olmayan edge case’ler Claude’un sorularıyla ortaya çıkıyor.

PM bottleneck’i azaldı. Daha az toplantı, daha az sözlü aktarım, daha az “bunu bana bir daha anlatır mısın?”

Özetle

Tüm product ekibi AI’ı aktif kullanıyor — herkes kendi iş alanına göre, kendi ihtiyacına göre. Daha hızlı ve daha doğru sonuçlar çıkıyor. Daha az toplantı yapıyoruz. Yolda karşılaştığımız hata sayısı azaldı.

Bu sistemi kurmak için zaman harcadım ama kazandığım şey sadece hız değildi — netlik ve tutarlılık da geldi. Yolda karşılaştığım durumlara göre geliştirmeye de devam ediyorum. 2 aydır elle task yazmıyorum ama 2 aydır en iyi task’larımı çıkarıyorum.

*Chat is overrated. Here are 4 innovative AI product interfaces