AI Çağında Tek Sistem: Notion Jira Slack Yerine Alios

AI Çağında Tek Sistem: Notion Jira Slack Yerine Alios

Teknik ekiplerin araç envanteri genellikle şöyle görünüyor: Jira sprint yönetimi için, Notion dokümantasyon için, Slack koordinasyon için, GitHub PR takibi için, Confluence teknik wiki için. Belki bir de Miro vardır mimari diyagramlar için.

Her araç iyi niyetle eklendi. Her araç bir sorunu çözmek için seçildi. Ama zamanla sorun araçların kendisi oldu.

"Bu karar nerede alınmıştı?" sorusu geldiğinde cevap şu oluyor: "Slack'te yazdık ama hangi kanalda bilmiyorum, ya da Notion'da bir yerde var, ya da Jira ticket'ının yorumundaydı." Bu cevap bilginin kayıp olduğu anlamına geliyor.

Araç Dağınıklığının Maliyeti

Araç sayısı artınca koordinasyon maliyeti sessizce büyüyor.

Bağlam kaybı. Bir görev Jira'da, o görevle ilgili karar Slack'te, teknik detay Notion'da. Üçünü birleştirmek için üç araç arasında gezinmek gerekiyor. Yeni ekip üyesi nereden başlayacağını bilemiyor.

Senkronizasyon maliyeti. Jira'da güncellenen görev Notion'daki dokümanı güncelletmiyor. Slack'te alınan karar Jira'ya taşınmıyor. Araçlar arasında veri tutarlılığını sağlamak başlı başına iş haline geliyor.

Toplantı ihtiyacı artıyor. Bilgi dağıldığında insanlar bir araya gelerek senkronize oluyor. "5 dakikalık senkron" toplantıları aslında araç dağınıklığının semptomu. Bilgi tek yerde olsaydı toplantıya gerek kalmazdı.

AI çağında bu maliyet ikiye katlanıyor. AI kararları hızlandırdı, PR sayısını artırdı, paralel iş miktarını büyüttü. Bağlam kaybı ve koordinasyon maliyeti daha fazla karar, daha fazla PR ve daha fazla paralel işle birlikte katlanarak büyüyor.

Tek Kaynak Ne Anlama Geliyor?

Tek kaynak "her şeyi tek araçta yönet" değil. "Her bilginin nerede yaşadığı belli" demek.

Alios'ta bu dört katmanla kuruluyor:

Proje ağacı: Roadmap hedefinden günlük göreve kadar her şey hiyerarşik. Üst hedef → epik → task. Her node'un üst hedefle bağlantısı görünür.

Durumlar: Her görev net bir durumda. Backlog, In Progress, Waiting, Review, Done. "Bu nerede?" sorusu node'a bakılarak yanıtlanıyor.

Sahiplik: Her node'un bir owner'ı var. "Bunu kim yapıyor?" sorusu atanan kişiye bakılarak yanıtlanıyor.

Karar kaydı: Her önemli karar node açıklamasında yaşıyor. Bağlam, seçenekler, gerekçe, sonuçlar. "Bunu neden böyle yaptık?" sorusu node'a bakılarak yanıtlanıyor.

Bu dört katman kurulduğunda Slack koordinasyon için değil bildirim için kullanılıyor. Notion doküman deposu değil; kararlar node'larda yaşıyor. Jira gereksizleşiyor çünkü aynı işi daha az kompleks şekilde Alios karşılıyor.

Senaryo 1: Solo Dev

Solo geliştirici için araç dağınıklığı farklı görünüyor ama aynı derecede maliyetli. "Neyi neden yaptım?" sorusu iki ay sonra yanıtsız kalıyor.

Kurulum

📁 AKTİF PROJELER
│
├── 📁 [Proje A] — SaaS Ürünü
│   ├── 📁 Bu Hafta
│   │   ├── 📌 Auth modülü — JWT implementasyonu
│   │   │   Durum: In Progress
│   │   │   Deadline: Çarşamba
│   │   │   Kabul kriteri: Login/logout/refresh
│   │   │   çalışıyor, token 7 günde expire
│   │   │
│   │   └── 📌 Dashboard API — kullanıcı metrikleri
│   │       Durum: Backlog
│   │       Deadline: Cuma
│   │       Bağımlılık: Auth DONE olmalı
│   │
│   ├── 📁 Backlog
│   │   ├── 📌 Email notification servisi
│   │   ├── 📌 Admin panel CRUD
│   │   └── 📌 Stripe entegrasyonu
│   │
│   └── 📁 Karar Kayıtları
│       ├── 📌 KARAR — Auth: JWT vs Session
│       └── 📌 KARAR — DB: PostgreSQL vs MongoDB
│
└── 📁 [Proje B] — Freelance İş
    └── [Aynı yapı]

Solo Dev Günlük Rutin

Sabah (10 dakika):
→ "Bu Hafta" node'larına bak
→ Bugün ne biteceğini belirle
→ Bağımlılık var mı kontrol et

Gün içi:
→ Görev bitince node kapat
→ Yeni fikir veya karar çıkınca node aç
→ AI ile alınan karar → "Karar Kayıtları"na git

Akşam (5 dakika):
→ Yarım kalan node'lara not düş
→ Yarınki önceliği işaretle

Solo dev için Alios'un temel değeri hafıza. İki ay sonra "neden JWT seçtim, neden bu endpoint'i böyle tasarladım" soruları karar kaydı node'larına bakılarak yanıtlanıyor. Slack yok, Notion yok — her şey projede.

Senaryo 2: 2 Kişilik Ekip

İki kişilik ekipte koordinasyon sorunu ilk sprint'te çıkıyor: kim ne yapıyor, kim neyi bekliyor, ne zaman review yapılacak. Bu sorular Slack'te çözülmeye çalışıldığında her gün "ne durumdasın?" mesajı geliyor.

Kurulum

📁 SPRINT 5 — 17-21 Mart
Sprint hedefi: Ödeme akışı staging'de onaylı,
kullanıcı profili canlıya alındı.
│
├── 📌 Stripe webhook entegrasyonu
│   Owner: Ali (backend)
│   Durum: In Progress
│   Deadline: Salı
│   Kabul kriteri:
│   • Başarılı ödeme webhook'u işleniyor
│   • Başarısız ödeme loglanıyor
│   • Test senaryoları geçiyor
│   Bağımlılık: Yok
│
├── 📌 Ödeme geçmişi sayfası
│   Owner: Mehmet (frontend)
│   Durum: Waiting
│   Deadline: Perşembe
│   Bağımlılık: Stripe webhook DONE olmalı
│   Waiting notu: API endpoint'i bekleniyor.
│   Ali Salı bitireceğini söyledi.
│   Şimdilik mock data ile başlandı.
│
├── 📌 Kullanıcı profil güncelleme
│   Owner: Mehmet
│   Durum: Review
│   Deadline: Bugün
│   PR: #47 — Ali review edecek
│
└── 📋 KARAR KAYITLARI
    └── 📌 KARAR — Stripe amount: Decimal→Integer dönüşüm
        Tarih: 15 Mart
        Bağlam: AI üretilen kod Decimal döndürüyordu,
        Stripe integer bekliyor. INC-001'den öğrenildi.
        Karar: Tüm amount field'larında explicit
        integer dönüşümü zorunlu.

2 Kişilik Ekip Kuralları

1. Her sabah node'lar güncellenir — mesaj atmadan
   "Ne durumdasın?" sorusu node'a bakılarak yanıtlanır

2. Bağımlılık varsa Waiting'e geçilir ve not yazılır
   Waiting notu: ne bekleniyor, kimden, ne zamana kadar

3. PR açılınca görev Review'a geçer, reviewer atanır
   SLA: 24 saat

4. Sprint sonunda her iki kişi 10 dakika:
   → Tamamlananlar, devir edenler, öğrenme notu

İki kişilik ekipte Alios'un değeri "ne durumdasın?" döngüsünü kırmak. Her gün sabah node'lara bakılıyor, senkron toplantı gerekmiyor. Karar alındığında node'a yazılıyor, Slack'e değil.

Senaryo 3: 5 Kişilik Ekip

Beş kişiyle koordinasyon karmaşıklığı katlanıyor. Paralel epikler, çapraz bağımlılıklar, farklı uzmanlık alanları. Jira kurulumu cazip görünüyor ama ağır geliyor. Notion + Slack hibrit çözümü tutarsız kalıyor.

Kurulum

📁 Q3 HEDEFİ — Kurumsal Onboarding
Owner: Selin (PM)
Deadline: 30 Eylül
Başarı kriteri: Onboarding süresi 5 günden 1 güne
│
├── 📁 EPİK 1 — RBAC (Rol Bazlı Erişim)
│   Owner: Ali (Backend Lead)
│   Deadline: 15 Eylül
│   Durum: In Progress
│   │
│   ├── 📌 RBAC veri modeli — Ali — Deadline: 2 Eyl ✅
│   ├── 📌 RBAC middleware — Ali — Deadline: 5 Eyl 🔄
│   ├── 📌 Frontend permission hook — Mehmet — 9 Eyl ⬜
│   ├── 📌 Admin rol yönetimi UI — Mehmet — 12 Eyl ⬜
│   └── 📌 RBAC entegrasyon testi — Zeynep — 15 Eyl ⬜
│
├── 📁 EPİK 2 — Ekip Davet Sistemi
│   Owner: Mehmet (Frontend Lead)
│   Deadline: 22 Eylül
│   Durum: Backlog — EPİK 1 tamamlanınca başlar
│   Bağımlılık: RBAC DONE olmalı
│   │
│   ├── 📌 Davet API'si — Ali — Deadline: 17 Eyl ⬜
│   ├── 📌 E-posta şablonu — Can — Deadline: 17 Eyl ⬜
│   ├── 📌 Davet kabul akışı — Mehmet — Deadline: 20 Eyl ⬜
│   └── 📌 Davet listesi UI — Mehmet — Deadline: 22 Eyl ⬜
│
├── 📁 EPİK 3 — Onboarding Wizard
│   Owner: Mehmet
│   Deadline: 29 Eylül
│   Durum: Backlog — EPİK 2 tamamlanınca başlar
│   │
│   ├── 📌 Wizard adım yapısı — Mehmet — 24 Eyl ⬜
│   ├── 📌 İlerleme kayıt API — Ali — 24 Eyl ⬜
│   └── 📌 Analytics event'leri — Can — 26 Eyl ⬜
│
├── 📁 AKTİF SPRINT — Sprint 8 (1-5 Eylül)
│   Sprint hedefi: RBAC middleware ve veri modeli
│   staging'de onaylı.
│   │
│   ├── 📌 RBAC middleware — Ali — 5 Eyl 🔄
│   ├── 📌 Middleware unit testleri — Zeynep — 5 Eyl 🔄
│   └── 📌 PR Review — RBAC veri modeli — Kerem — ✅
│
└── 📋 KARAR KAYITLARI
    ├── 📌 KARAR — RBAC: Flat vs Hierarchical roller
    ├── 📌 KARAR — Davet: Token expiry 24h vs 48h
    └── 📌 KARAR — Wizard: Multi-page vs Single-page

5 Kişilik Ekip Kuralları

ROLLER VE SORUMLULUKLAR

Selin (PM):
→ Üst hedef ve epik owner'lığı
→ Sprint hedefini yazar
→ Epik kapanış kriterlerini onaylar

Ali (Backend Lead):
→ Backend task'ların owner'ı
→ Mimari karar kayıtlarını yazar
→ Backend PR'lar için reviewer

Mehmet (Frontend Lead):
→ Frontend task'ların owner'ı
→ Epik 2 ve 3 lead'i

Zeynep (QA):
→ Test checklist node'larının owner'ı
→ Entegrasyon test onayı

Can (Full-stack):
→ Cross-cutting task'lar
→ E-posta ve analytics


HAFTALIK RİTİM

Pazartesi (30 dakika — sprint planlaması):
→ Sprint hedefi yazıldı
→ Task'lar owner'lara atandı
→ Bağımlılıklar node'lara yazıldı

Çarşamba (15 dakika — risk kontrolü):
→ Waiting node'ları tarandı
→ SLA aşan Review node'ları tarandı
→ Sprint hedefi risk altında mı?

Cuma (20 dakika — sprint kapanışı):
→ Tamamlananlar, devir edenler
→ Retrospektif notu: 3 satır
→ Karar kaydı eksik var mı?

KARAR KURALI

Her mimari veya önceliklendirme kararı
node'a yazılır. "Slack'te konuştuk" bir
karar kaydı değil.

Notion + Jira + Slack ile Karşılaştırma

Soru: "Auth kararı neden JWT oldu?"

Notion + Jira + Slack:
→ Jira ticket yorumlarında ara
→ Bulamazsan Slack'te ara
→ Bulamazsan o kararı alan kişiye sor
→ O kişi şirkette yoksa cevap yok
Süre: 10-30 dakika, sonuç belirsiz

Alios tek sistem:
→ "KARAR — Auth" arama
→ Node açıl: bağlam, seçenekler, gerekçe yazıyor
Süre: 30 saniye, sonuç kesin

Bu fark günde birkaç kez yaşandığında haftalık koordinasyon maliyeti görünür hale geliyor.

Son Düşünce

Araç sayısı sorunu araç sayısını artırarak çözülmüyor. Çözüm her bilginin nerede yaşadığını netleştirmek.

Alios'ta proje ağacı, durumlar, sahiplik ve karar kaydı bu netliği kuruyor. Solo dev hafızasını kaybetmiyor. İki kişilik ekip "ne durumdasın?" döngüsünden çıkıyor. Beş kişilik ekip epikler arasında koordinasyonu toplantı yapmadan sağlıyor.

AI çağında araç sayısını azaltmak hız kaybı değil — bağlam kazancı.