למה זריז לא עובד לפי מקינזי

הסיבה לכך שהאג'ייל לא עובד בחברות היא כי הפונקציה העסקית אינה מיוצגת כראוי בצוותי הפרויקט.

Se vi ricordate di come è composto un team agile, il team agile è fatto per essere autonomo nelle decisioni e nell’esecuzione delle attività di progetto, infatti ci dovrebbe sempre essere un rappresentante del business che sostanzialmente decide sulle funzionalità da sviluppare e la priorità degli sviluppi.

Ora, sebbene sembri facile avere un rappresentante del business all’interno dei team agile nella pratica non è né facile né scontato che se presente un rappresentante del business, questa persona abbia le competenze, l’esperienza e l’autorità per decidere le funzionalità da sviluppare e la loro priorità.

In realtà il rappresentante del business all’interno del team agile potrebbe decidere sulle funzionalità da sviluppare e la loro priorità solo nel caso in cui sia lui il responsabile del prodotto che il team sta sviluppando.

Supponiamo che un team stia sviluppando l’applicazione nativa per un retailer e che il product owner dell’app nativa venga assegnato al team agile di sviluppo. Bene, il product owner nel momento in cui viene messo di fronte alle scelte decisionali relative all’applicazione da sviluppare si troverà nella condizione di dover chiedere pareri e autorizzazioni per ogni singola decisione rilevante che abbia un impatto sulle altre funzioni organizzative con cui l’app dovrà necessariamente interagire.

ניקח כמה דוגמאות כדי להבהיר את הדינמיקה:

• Dobbiamo decidere la grafica dell’app –> Bisogna contattare l’art director o l’ufficio immagine dell’azienda per avere il sign off sulla grafica dell’app –> Il team agile deve aspettare le approvazioni del caso.
• Dobbiamo decidere sui metodi di pagamento da attivare sull’app –> Abbiamo bisogno del direttore finanziario che approvi i metodi di pagamento e faccia le configurazioni
• Dobbiamo decidere sui contenuti del catalogo dell’app –> Abbiamo bisogno del direttore merchandising che definisca quali sono i prodotti da mettere in vendita

וכן הלאה.

Tutti questi intoppi possono essere adeguatamente gestiti con un lavoro di pianificazione iniziale e un’attività di stakeholder management che è prassi normale in un progetto gestito in modalità waterfall.

ברור שעבור פרויקטים מורכבים יש צורך לאמץ שיטת תכנון גלים מתגלגלים לתכנן או פשוט לאמץ כמה שיטות עבודה מומלצות, כגון שמירה על רשימה של פעילויות שהוגדרו באופן חלקי וניתוח התלות שלהן כדי להבין אם יש להן השפעה על משך הזמן הכולל של הפרויקט.

הכלים שמתודולוגיות ניהול פרויקטים מסורתיות מאפשרות לניהול מצבים אלה הם:

• שאלות פתוחות (יומן)
• רשימת נושאים (יומן)
• הגדרה של פעילויות חוסמות ולא חוסמות
• מסמך דרישות הפרויקט
• מסמך דרישות המוצר