Strateji / Ürün Yönetimi #52
openStrateji / Ürün Yönetimi #49: Oturum 4 - MyWay Redmine Master Template, L0-L12 Faz Yapısı ve Demo Görev Kırılımı
Status ve Workflow Durumlarının Tanımlanması
0%
Description
Amaç:
Görevlerin yaşam döngüsünde kullanacağı standart durumları belirlemek.
İçerik:
New, Planned, In Progress, Waiting Dependency, On Hold, Blocked, In Review, Rework Required, Resolved, Closed, Cancelled durumları kullanılacaktır. Demo’da özellikle gecikme, bağımlılık, blokaj ve onay durumları gösterilecektir.
Çıktı:
Status listesi ve kullanım açıklamaları.
RA Updated by Redmine Admin about 6 hours ago
- Status changed from New to In Progress
RA Updated by Redmine Admin about 6 hours ago
5. Status Yapısı¶
Redmine’da durumlar tüm tracker’larda mümkün olduğunca standart olmalı.
Önerilen status listesi¶
| Status | Anlamı |
|---|---|
| New | Görev oluşturuldu, henüz planlanmadı |
| Planned | Planlandı, başlangıç bekliyor |
| In Progress | Aktif çalışılıyor |
| Waiting Dependency | İç/dış bağımlılık bekliyor |
| On Hold | Geçici olarak durduruldu |
| Blocked | Kritik engel var |
| In Review | Kontrol/onay bekliyor |
| Rework Required | Revizyon/yeniden çalışma gerekiyor |
| Resolved | Teknik olarak tamamlandı |
| Closed | Onaylandı ve kapatıldı |
| Cancelled | İptal edildi |
Demo için önemli status kullanımı¶
- Satın alma gecikmesini göstermek için: Waiting Dependency
- Kritik malzeme yoksa: Blocked
- Tasarım kontrolündeyse: In Review
- Revizyon gerekiyorsa: Rework Required
- AI gecikme yakaladığında: status değişmese bile AI Agent issue açabilir.
RA Updated by Redmine Admin about 6 hours ago
Ek Açıklama:
Bu görev kapsamında yalnızca status listesi değil, demo ortamında kullanılacak workflow geçiş matrisi de tanımlanacaktır. Normal görev akışı New → Planned → In Progress → In Review → Resolved → Closed şeklinde kurgulanacaktır. Sapma akışları olarak Waiting Dependency, Blocked, On Hold, Rework Required ve Cancelled durumları kullanılacaktır. Faz parent issue’ları için daha kontrollü New → Planned → In Progress → In Review → Closed akışı uygulanacaktır. Mobil MES başla/bitir aksiyonları Redmine status değişimleriyle ilişkilendirilecek; AI Agent ise kendi analiz görevlerini Resolved seviyesine kadar getirecek, insan onayı gerektiren işleri Closed yapmayacaktır.
Güncellenmiş Çıktı:
- Status listesi
- Status kullanım açıklamaları
- Görev workflow geçiş matrisi
- Tracker bazlı workflow kullanım notları
- Rol bazlı geçiş yetkisi
- Faz parent issue workflow’u
- AI Agent workflow davranışı
- Mobil MES → Redmine status ilişkisi
- ERP olayları → Redmine status ilişkisi
- Demo’da gösterilecek 4 workflow senaryosu
Güncellenmiş Acceptance Criteria:
- Tüm status’ların kullanım amacı açıklandı.
- Normal görev akışı belirlendi.
- Sapma/istisna akışları belirlendi.
- Faz parent issue workflow’u tanımlandı.
- Rol bazlı geçiş yetkileri belirlendi.
- AI Agent’ın workflow sınırları tanımlandı.
- Mobil MES aksiyonlarının Redmine status etkisi tanımlandı.
- ERP olaylarının Redmine status etkisi tanımlandı.
- Demo’da gösterilecek workflow senaryoları seçildi.
RA Updated by Redmine Admin about 5 hours ago
- Status changed from In Progress to Resolved
Redmine Demo Workflow Yapısı¶
1. Workflow Tasarım Prensibi¶
Demo ortamında workflow çok karmaşık olmamalı; ancak MyWay’in “kontrollü süreç yönetimi” kabiliyetini gösterecek kadar disiplinli olmalı.
Temel prensip:
Her görev New ile başlar, Planned ile planlanır, In Progress ile yürütülür, In Review ile kontrol edilir, Resolved ile teknik olarak tamamlanır ve Closed ile onaylanarak kapatılır.
Ancak gerçek operasyonlarda görevler bekleyebilir, blokaj yaşayabilir, revizyona dönebilir veya iptal edilebilir. Bu nedenle demo workflow içinde Waiting Dependency, Blocked, On Hold, Rework Required ve Cancelled durumları da kullanılmalıdır.
2. Ana Workflow Akışı¶
Demo için önerilen ana akış:
New
↓
Planned
↓
In Progress
↓
In Review
↓
Resolved
↓
Closed
Bu ana akış, normal ilerleyen bir görevin yaşam döngüsünü temsil eder.
3. Sapma ve İstisna Akışları¶
Gerçek proje yönetiminde her görev düzgün ilerlemez. Bu nedenle aşağıdaki alternatif akışlar da tanımlanmalı.
In Progress → Waiting Dependency
Waiting Dependency → In Progress
In Progress → Blocked
Blocked → In Progress
In Progress → On Hold
On Hold → Planned / In Progress
In Review → Rework Required
Rework Required → In Progress
New / Planned / In Progress → Cancelled
4. Status Geçiş Matrisi¶
Aşağıdaki tabloyu demo Redmine workflow mantığı olarak kullanacağız.
| Mevcut Status | Geçebileceği Status | Kullanım Amacı |
|---|---|---|
| New | Planned | Görev planlandı |
| New | Cancelled | Görev gereksiz/iptal edildi |
| Planned | In Progress | Çalışma başladı |
| Planned | On Hold | Planlandı ama beklemeye alındı |
| Planned | Cancelled | Planlanan görev iptal edildi |
| In Progress | Waiting Dependency | İç/dış bağımlılık bekleniyor |
| In Progress | Blocked | Kritik engel oluştu |
| In Progress | On Hold | Çalışma geçici durduruldu |
| In Progress | In Review | Çıktı kontrol/onaya gönderildi |
| In Progress | Resolved | Basit görev teknik olarak tamamlandı |
| Waiting Dependency | In Progress | Bağımlılık çözüldü, çalışma devam ediyor |
| Waiting Dependency | Blocked | Bekleyen bağımlılık kritik engele dönüştü |
| Waiting Dependency | On Hold | Bekleme uzun süreli duruşa çevrildi |
| Blocked | In Progress | Engel kaldırıldı |
| Blocked | On Hold | Kritik engel nedeniyle görev beklemeye alındı |
| On Hold | Planned | Yeniden planlama gerekiyor |
| On Hold | In Progress | Çalışma tekrar başladı |
| In Review | Resolved | Kontrol başarılı, teknik olarak tamamlandı |
| In Review | Rework Required | Revizyon veya düzeltme gerekiyor |
| Rework Required | In Progress | Revizyon çalışması başladı |
| Resolved | Closed | Sorumlu/onaylayan kişi görevi kapattı |
| Resolved | Rework Required | Tamamlandı sanılan işte eksik bulundu |
| Closed | Rework Required | Kapanmış iş müşteri/kalite geri bildirimiyle yeniden açıldı |
| Herhangi bir açık status | Cancelled | Görev iptal edildi |
5. Demo İçin Basitleştirilmiş Workflow¶
Demo ortamında bütün geçişleri göstermek zorunda değiliz. Demo için özellikle şu akışlar yeterli olur:
Normal görev akışı¶
New → Planned → In Progress → In Review → Resolved → Closed
Satın alma gecikmesi akışı¶
Planned → In Progress → Waiting Dependency → In Progress → In Review → Resolved → Closed
Üretim blokajı akışı¶
Planned → In Progress → Blocked → In Progress → Resolved → Closed
Tasarım revizyonu akışı¶
Planned → In Progress → In Review → Rework Required → In Progress → In Review → Resolved → Closed
İptal edilen görev akışı¶
New / Planned / In Progress → Cancelled
6. Tracker Bazlı Workflow Kullanımı¶
Demo MVP’de tüm tracker’lar için aynı workflow kullanılabilir. Ancak kullanım vurgusu farklı olmalı.
| Tracker | En Çok Kullanılacak Status’lar | Not |
|---|---|---|
| 00 — Proje Yönetimi | Planned, In Progress, In Review, Closed | Toplantı, karar, risk ve koordinasyon işleri |
| 01 — Proje Başlatma | New, Planned, In Progress, Closed | Kickoff ve kapsam netleştirme |
| 02 — Mühendislik Tasarımı | In Progress, In Review, Rework Required, Closed | Tasarım kontrol ve revizyonları için kritik |
| 03 — Tasarım Revizyonu | New, In Progress, In Review, Rework Required, Closed | Revizyon döngüsünü göstermek için |
| 04 — BOM & Operasyon Hazırlığı | In Progress, In Review, Waiting Dependency, Closed | ERP/BOM eşleşmesi için |
| 05 — Planlama | Planned, In Progress, Waiting Dependency, Closed | Termin ve kaynak planı için |
| 06 — Satın Alma | Planned, In Progress, Waiting Dependency, Blocked, Closed | Tedarikçi/termin gecikmesini göstermek için |
| 07 — Üretim & Montaj | Planned, In Progress, Blocked, Resolved, Closed | Mobil MES ve üretim kayıtları için |
| 08 — Kalite & Test | In Progress, In Review, Rework Required, Closed | Test ve uygunsuzluk döngüsü için |
| 09 — Lojistik & Sevkiyat | Planned, In Progress, Closed | Sevkiyat hazırlıkları |
| 10 — Kurulum & Servis | Planned, In Progress, Waiting Dependency, Closed | Saha operasyonları |
| 11 — AI Agent | New, In Progress, Resolved, Closed | AI analiz/uyarı çıktıları için |
7. Rol Bazlı Geçiş Yetkisi¶
Demo’da rol bazlı geçiş yetkilerini çok karmaşık kurmaya gerek yok; ancak enterprise hissi vermek için temel yetkiler ayrılmalı.
Önerilen rol bazlı workflow yetkisi¶
| Rol | Yapabileceği Geçişler |
|---|---|
| Admin | Tüm geçişler |
| Proje Yöneticisi | New → Planned, Planned → In Progress, In Review → Resolved, Resolved → Closed, açık görev → Cancelled |
| Disiplin Lideri | Planned → In Progress, In Progress → In Review, In Review → Rework Required, Rework Required → In Progress |
| Uzman / Mühendis | Planned → In Progress, In Progress → In Review, In Progress → Waiting Dependency |
| Üretim Operatörü | Planned → In Progress, In Progress → Resolved |
| Kalite | In Review → Resolved, In Review → Rework Required, Resolved → Closed |
| Satın Alma | Planned → In Progress, In Progress → Waiting Dependency, Waiting Dependency → In Progress, In Progress → Resolved |
| AI Agent | New → In Progress, In Progress → Resolved; ayrıca yorum/uyarı oluşturur, doğrudan Closed yapmaz |
| Yönetim | Resolved → Closed, In Review → Rework Required, kritik işlerde yorum/eskalasyon |
8. Faz Parent Issue Workflow’u¶
L0-L12 faz parent issue’larında görevlerden farklı daha kontrollü bir akış da kullanılabilir.
Faz parent issue akışı¶
New → Planned → In Progress → In Review → Closed
Fazlarda Resolved kullanmak şart değil. Çünkü fazın kapanması genellikle onayla olur.
Faz kapanış kuralı¶
Bir L fazı kapanmadan önce:
- Alt görevlerin kritik olanları kapanmış olmalı.
- Açık Blocked görev olmamalı.
- Required Approval alanı “Yes” ise ilgili onay alınmalı.
- Acceptance Criteria alanı doldurulmalı.
- Proje yöneticisi veya ilgili faz sahibi kapatma yapmalı.
Faz geçiş örneği¶
L5 — BOM & Tedarik Planı
↓
Tüm kritik BOM ve tedarik planlama görevleri tamamlanır.
↓
L5 In Review yapılır.
↓
Proje Yöneticisi + Üretim Planlama kontrol eder.
↓
L5 Closed olur.
↓
L6 — Malzeme Tedarik In Progress yapılır.
9. AI Agent Workflow Davranışı¶
AI Agent, demo’da bir “kullanıcı/disiplin” gibi görünmeli ama görev kapatma yetkisi sınırlı olmalı.
AI Agent’ın yapabilecekleri¶
- Yeni AI analiz görevi açmak
- Görev açıklamasını iyileştirmek
- Risk yorumu eklemek
- Geciken görev için uyarı yorumu yazmak
- Eskalasyon seviyesi önermek
- Görevleri AI Support Level’a göre sınıflandırmak
- AI Agent tracker’ındaki kendi görevlerini Resolved yapmak
AI Agent’ın yapmaması gerekenler¶
- İnsan onayı gereken işleri Closed yapmamalı.
- Faz parent issue kapatmamalı.
- ERP’ye doğrudan kritik veri yazmamalı.
- Kalite/FAT/SAT kararını tek başına vermemeli.
- Uzmanlık gerektiren mühendislik çıktısını onaylamamalı.
AI Agent workflow örneği¶
New → In Progress → Resolved
AI Agent görevi Resolved yaptıktan sonra Proje Yöneticisi veya ilgili disiplin lideri bunu Closed yapabilir.
10. Mobil MES Workflow Bağlantısı¶
Mobil MES’teki başla/bitir aksiyonları Redmine status’larına bağlayacağız.
Mobil → Redmine status ilişkisi¶
| Mobil Aksiyon | Redmine Status Etkisi |
|---|---|
| Operasyon operatöre atandı | Planned |
| Operatör Başla dedi | In Progress |
| Operatör Duraklat dedi | On Hold |
| Operatör sorun bildirdi | Blocked veya Waiting Dependency |
| Operatör Bitir dedi | Resolved |
| Kalite onayladı | Closed |
| Kalite uygunsuzluk verdi | Rework Required |
Bu akış demo’da özellikle L7 Üretim & Montaj fazında gösterilebilir.
11. ERP Workflow Bağlantısı¶
ERP’deki bazı olaylar Redmine status’larını etkileyebilir.
| ERP Olayı | Redmine Etkisi |
|---|---|
| Sipariş ERP’de açıldı | L0 parent issue New / Planned |
| Proje kodu oluştu | L0 In Progress |
| BOM onaylandı | L5 In Review / Resolved |
| Satın alma siparişi açıldı | L6 In Progress |
| Malzeme gecikti | L6 Waiting Dependency |
| Malzeme kritik eksik | L6 Blocked |
| Üretim iş emri açıldı | L7 Planned |
| Operasyon başladı | L7 ilgili görev In Progress |
| Operasyon bitti | L7 ilgili görev Resolved |
| FAT tamamlandı | L10 In Review / Resolved |
| Sevkiyat tamamlandı | L11 Resolved |
| SAT tamamlandı | L12 In Review / Resolved |
12. Demo’da Özellikle Göstermemiz Gereken 4 Workflow Senaryosu¶
Demo sırasında bütün workflow anlatılmayacak. Şu 4 örnek gösterilirse yeterince güçlü olur.
Senaryo 1 — Normal proje görevi¶
New → Planned → In Progress → In Review → Resolved → Closed
Mesaj:
MyWay’de her görev kontrollü ilerler ve onaylanmadan kapanmaz.
Senaryo 2 — Satın alma gecikmesi¶
In Progress → Waiting Dependency
Mesaj:
Tedarik gecikmesi sadece satın alma problemi olarak kalmaz; proje fazı ve termin riskiyle ilişkilendirilir.
Senaryo 3 — Üretim blokajı¶
In Progress → Blocked
Mesaj:
Üretimdeki kritik engeller Redmine, ERP ve mobil MES bağlamında görünür hale gelir.
Senaryo 4 — Kalite revizyonu¶
In Review → Rework Required → In Progress
Mesaj:
Kalite veya müşteri geri bildirimi, görevi kontrollü şekilde tekrar çalışma döngüsüne sokar.
Kapanış¶
Bu ekle birlikte Oturum 4’teki Status ve Workflow görevi artık daha tamam hale geliyor.
Özellikle şu ayrımı Redmine’da net olarak tutacağız:
| Yapı | Workflow Mantığı |
|---|---|
| Normal görevler | New → Planned → In Progress → In Review → Resolved → Closed |
| Faz parent issue’ları | New → Planned → In Progress → In Review → Closed |
| AI Agent görevleri | New → In Progress → Resolved → insan kontrolü sonrası Closed |
| Mobil operasyon görevleri | Planned → In Progress → Resolved → Kalite/PM sonrası Closed |
Bu yapı demo için yeterince güçlü, ama gereksiz karmaşıklık yaratmayacak kadar sade olur.