Proje sonu dağınık notları, paylaşıma hazır lessons-learned kapanış raporuna çevir
Dağınık proje notlarından, başlıklara ayrılmış ve paylaşıma hazır bir kapanış (lessons-learned) raporu iskeleti; her ders "sorun → bir sonraki sefer" formatında, eksik yerler açıkça işaretli.
Proje bitti, herkes bir sonrakine koştu. Elinde bir sürü dağınık not var ama kimse oturup "ne öğrendik" raporunu yazmıyor; aynı hatalar sessizce bir sonraki projeye miras kalıyor.
Sen deneyimli bir proje yöneticisisin. Sana bir projenin sonunda tuttuğum ham, dağınık notları vereceğim. Görevin bu notları yapılandırılmış bir "lessons-learned" (çıkarılan dersler) kapanış raporuna çevirmek.
Kurallar:
- Sadece notlarda yazan bilgiyi kullan. Tahmin yürütme, olay uydurma, notta olmayan sayı/tarih/isim ekleme.
- Bir başlık için notlarda bilgi yoksa oraya "EKSIK: [neyin sorulması gerektiği]" yaz, boş bırakma.
- Ton nötr olsun; kişi suçlama, isim hedef gösterme. Sorunu davranışa veya sürece bağla.
- Her "ders" aksiyona dönük olsun: bir sonraki projede ne farklı yapılacağını tek net cümlede söyle.
- Çıktı Türkçe ve olduğu gibi kopyalanıp paylaşılabilir olsun.
Raporu tam olarak şu başlıklarla ver:
1. Proje özeti (2-3 cümle: ne yapıldı, hedef neydi, sonuç ne oldu)
2. Hedefe göre sonuç (planlanan vs gerçekleşen: kapsam, süre, bütçe — notta hangisi varsa onu yaz, olmayana EKSIK)
3. İyi giden 3-5 madde (her biri: ne oldu + neden işe yaradı)
4. Kötü giden 3-5 madde (her biri: belirti + görünen kök neden)
5. Çıkarılan dersler — her biri şu formatta: "Sorun → Bir sonraki sefer: ..."
6. Bir sonraki projeye taşınacak somut kurallar (kısa, checklist maddesi gibi işaretlenebilir cümleler)
7. Açık kalan riskler / takip edilecekler
En sonda "Netleştirilmesi gereken sorular" başlığı aç ve EKSIK işaretlediğin her yeri tek maddelik liste halinde topla.
Ham notlarım:
"""
[PROJE SONU NOTLARINI BURAYA YAPIŞTIR]
"""Dağınık proje notlarından, başlıklara ayrılmış ve paylaşıma hazır bir kapanış (lessons-learned) raporu iskeleti; her ders "sorun → bir sonraki sefer" formatında, eksik yerler açıkça işaretli. Notların derliyse birkaç dakikada elde edilir; sen sadece kök neden ve eksikleri doğrularsın.
Kapanışı yazan PM ekibin kurumsal hafızasını kuran kişi olur; aynı hatayı iki kez yapmayan ekip, o yöneticinin çıktısı olarak görülür.
AI sadece senin yazdığın notları düzenler; notta olmayan gerçek kök nedeni bulamaz, o yüzden "neden" analizini yine sen doğrulamalısın — ayrıca notlarda müşteri/çalışan adı veya gizli veri varsa yapıştırmadan önce temizle.
A firması için yeni mobil sipariş uygulaması. amaç: manuel telefon siparişini uygulamaya taşımak, çağrı merkezi yükünü azaltmak. mart başı başladık, canlıya haziran sonu çıktı. planlanan mayıs ortasıydı yani geç kaldık. - ilk sprintlerde iyiydik, tasarım ekibiyle beraber çalışmak hızlıydı, prototip erken çıktı herkes beğendi - ödeme entegrasyonu tam bir kabus, 3. parti sağlayıcı dokümantasyonu eksikti, test ortamı sürekli düştü. burada 2 haftadan fazla kaydık - gereksinimler net değildi, iş birimi "şunu da ekleyelim" deyip durdu, kapsam sürekli büyüdü - QA'e geç başladık, son 10 gün panik oldu - devreye alma gecesi sorunsuzdu aslında, rollback planı hazırdı - Ekip Üyesi 2 aralarda 1 hafta izne çıktı ama kritik değildi - bütçe konusunda net bilgim yok sonuç: uygulama canlı, ilk hafta sipariş geldi ama çağrı merkezi yükü ölçmedik henüz
1. Proje özeti
A firması için, telefonla alınan manuel siparişleri müşterinin kendi kullanabileceği bir mobil uygulamaya taşımak amacıyla yeni bir mobil sipariş uygulaması geliştirildi. Hedef, siparişleri uygulamaya kaydırarak çağrı merkezi yükünü azaltmaktı. Uygulama canlıya alındı ve ilk hafta sipariş almaya başladı.
2. Hedefe göre sonuç (planlanan vs gerçekleşen)
| Boyut | Planlanan | Gerçekleşen |
|---|---|---|
| Süre | Mayıs ortası | Haziran sonu (gecikme) |
| Kapsam | EKSIK: Başlangıçta anlaşılan kapsam yazılı değil | Sürekli büyüdü ("şunu da ekleyelim" talepleri) |
| Bütçe | EKSIK: Planlanan bütçe belirtilmemiş | EKSIK: Gerçekleşen harcama belirtilmemiş |
3. İyi giden maddeler
- Erken prototip çıktı ve beğenildi — Tasarım ekibiyle birlikte çalışma hızlıydı, bu yüzden ilk sprintlerde hızlı ilerlendi.
- Devreye alma gecesi sorunsuz geçti — Rollback planı önceden hazırdı, bu yüzden geçiş risksiz yönetildi.
4. Kötü giden maddeler
- Ödeme entegrasyonunda 2 haftadan fazla kayma — Belirti: sürekli düşen test ortamı ve tıkanma. Görünen kök neden: 3. parti sağlayıcının eksik dokümantasyonu ve kararsız test ortamı.
- Kapsam sürekli büyüdü — Belirti: iş biriminden gelen "şunu da ekleyelim" talepleri durmadı. Görünen kök neden: gereksinimlerin baştan net tanımlanmamış olması.
- QA'e geç başlandı — Belirti: son 10 gün panik halinde geçti. Görünen kök neden: test aşamasının takvimde geç konumlanması.
5. Çıkarılan dersler
- Ödeme/3. parti entegrasyonu → Bir sonraki sefer: Dış sağlayıcı entegrasyonunu ve test ortamı sağlığını daha ilk sprintte doğrula, dokümantasyon eksikse işi başlatmadan sağlayıcıdan netleştir.
- Belirsiz gereksinim → Bir sonraki sefer: Kapsamı yazılı olarak dondur ve yeni talepleri ancak resmi bir değişiklik kararıyla içeri al.
- Geç QA → Bir sonraki sefer: Test aşamasını takvimin sonuna değil geliştirmeyle paralel başlat.
6. Bir sonraki projeye taşınacak somut kurallar
- [ ] 3. parti entegrasyonların test ortamını proje başında sağlığını doğrula.
- [ ] Kapsamı yazılı olarak sabitle; her yeni talep değişiklik kaydı olarak ele alınsın.
- [ ] QA'i geliştirmeyle paralel başlat, son haftaya bırakma.
- [ ] Devreye alma için rollback planını önceden hazırla (bu projede işe yaradı).
7. Açık kalan riskler / takip edilecekler
- Çağrı merkezi yükü henüz ölçülmedi; projenin asıl hedefine ulaşıp ulaşmadığı belirsiz.
- Canlı sonrası ödeme entegrasyonunun kararlılığı izlenmeli (geliştirmede en sorunlu alandı).
Netleştirilmesi gereken sorular
- Başlangıçta anlaşılan kapsam neydi? (Yazılı temel yok)
- Planlanan bütçe ne kadardı?
- Gerçekleşen harcama ne oldu?
ÜRETİM: TEM 2026 · CLAUDE Bu kayıt eşlenmiş örnek girdi ve çıktı içerir. Model koşumu kanıtı yoktur — kendi verinle doğrulamadan karar girdisi yapma.
Sen deneyimli bir proje yöneticisisin. Sana bir projenin sonunda tuttuğum ham, dağınık notları vereceğim. Görevin bu notları yapılandırılmış bir "lessons-learned" (çıkarılan dersler) kapanış raporuna çevirmek.
Kurallar:
- Sadece notlarda yazan bilgiyi kullan. Tahmin yürütme, olay uydurma, notta olmayan sayı/tarih/isim ekleme.
- Bir başlık için notlarda bilgi yoksa oraya "EKSIK: [neyin sorulması gerektiği]" yaz, boş bırakma.
- Ton nötr olsun; kişi suçlama, isim hedef gösterme. Sorunu davranışa veya sürece bağla.
- Her "ders" aksiyona dönük olsun: bir sonraki projede ne farklı yapılacağını tek net cümlede söyle.
- Çıktı Türkçe ve olduğu gibi kopyalanıp paylaşılabilir olsun.
Raporu tam olarak şu başlıklarla ver:
1. Proje özeti (2-3 cümle: ne yapıldı, hedef neydi, sonuç ne oldu)
2. Hedefe göre sonuç (planlanan vs gerçekleşen: kapsam, süre, bütçe — notta hangisi varsa onu yaz, olmayana EKSIK)
3. İyi giden 3-5 madde (her biri: ne oldu + neden işe yaradı)
4. Kötü giden 3-5 madde (her biri: belirti + görünen kök neden)
5. Çıkarılan dersler — her biri şu formatta: "Sorun → Bir sonraki sefer: ..."
6. Bir sonraki projeye taşınacak somut kurallar (kısa, checklist maddesi gibi işaretlenebilir cümleler)
7. Açık kalan riskler / takip edilecekler
En sonda "Netleştirilmesi gereken sorular" başlığı aç ve EKSIK işaretlediğin her yeri tek maddelik liste halinde topla.
Ham notlarım:
"""
[PROJE SONU NOTLARINI BURAYA YAPIŞTIR]
"""Yapıştırdığın veri tarayıcından çıkmaz — WhiteYaka'ya gönderilmez. Prompt panoya kopyalanır; açılan sohbete Ctrl/⌘ + V ile yapıştırırsın.
Bülten kaydı kapalı.
Bu sayfa e-posta adresi toplamaz ve liste kaydı başlatmaz. 160 hamlenin tamamı giriş yapmadan açık.