ניהול פרויקטים

בתוכנת Project-MS משמעות הפקודה Respect היא:

להתייחס לקשרים בתרשים הרשת לשם חישוב הנתיב הקריטי

לכבד את עלויות המשאבים ולהתריע על הקצאת חסר שלהם.

לכבד את מרכיבי הפרוייקט (SOW (ולוודא שכל המטלות בפרוייקט מטופלות.

לכבד את כמות המשאבים ולא לאפשר הקצאת יתר שלהם

אבני דרך חוזיות בפרוייקט חשובות לספק מכיוון ש:

הן עוזרות בחיזוי מועד הסיום של הפרוייקט.

בהן מעורבים משאבים קריטיים

מתבצע בהן תשלום. הפרתן עלולה לגרום להפסקת הפרוייקט

בהן נבחנת האינטגרציה של הפרוייקט

בעיצוב מסכי ניהול ל-4 כרטיסים כיצד עדיף להקצות את המשימה?

להקצות כרטיס אחד. לבדוק איכות. להקצות כרטיס נוסף וחוזר חלילה.

להקצות את פיתוח ארבעת הכרטיסים כמשימה אחת שלמה. לקבל רק פתרון שלם לכולם

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

לעצב ארכיטקטורה משותפת לכל הכרטיסים, להעביר ל-QA ,במקביל לפתח כרטיס ראשון – להעביר ל-QA וחוזר חלילה

כיצד מתמודדים עם פרוייקט שאורך זמן מעבר למועד שהובטח ללקוח?

מודיעים בשלב מוקדם שהגדרת הפרוייקט אינה ישימה.

מנהלים את הדרישות בשיטת Pull - Kanban כך שהעובדים מושכים את המשימות.

בשלב ראשון מפתחים רק תכונות חיוניות. במהלך ההטמעה מפתחים תכונות נוספות חיוניות פחות.

מחלקים את כלל מרכיבי הפרוייקט (SOW (בין כל אנשי הצוות.

המהלך להשבחת ערך הפרוייקט שעל מנהל הפרוייקט לעשות הוא:

לממש את כלל הדרישות של אנשי השיווק.

לדמיין דרישות שעדיין לא אופיינו אך צפויות לעלות בעתיד.

לבצע Overspecification וכן Overdesign

Minimum Viable Product להגדיר

מרכיבי פרישת פונקציית האיכות – Deployment Function Quality הם:

1 .זיהוי תכונות קריטיות 2 .פרישה של סוגי לקוחות פוטנציאליים. 3 .הגדרת רמת איכות מתקבלת. 4.בחינת איכות מתחרים. 5 .הגדרת לוחות זמנים

1 .זיהויי איכויות אנשי הצוות השונים. 2 .פרישה של תכונות קריטיות להצלחת הפרוייקט. 3 .בניית עץ המוצר. 4.בחינת שביעות רצון הלקוחות. 5 .חלוקת המשימות בין אנשי הצוות.

1 .זיהוי פרסונה. 2 .זיהוי פונקציית האיכות. 3 .פרישה לתכונות. 4 .בחינת ביצועי מתחרים. 5 .הגדרת יעדי פיתוח

1 .הגדרה איכותית של המוצר. 2 .פרישה של סוגי לקוחות פוטנציאליים. 3 .הגדרת הפער. 4.בחינת תכונות מתחרים. 5 .הגדרת לוחות זמנים

חמש הרמות במודל הבשלות model maturity capability הן:

Initial, Optimizing, Defined, Managed, Repeatable

Initial, Repeatable, Defined, Managed, Optimizing

Managed, Defined, Optimizing, Supported, Repeatable

Defined, Managed, Optimizing, Supported, Agile

למוצרים הבאים מהי זווית התקיפה התואמת - התשובות משמאל לימין: תרופה חדשה, מדפסת הזרקת דיו,מכונית סינית, Tesla - מכונית חשמלית

Skimming, Storming, Piercing, Flooding

,Piercing, Storming Skimming, Flooding

Skimming, Storming, Flooding, Piercing

Storming, Flooding, Piercing, Skimming

מה עקרון ה-Flow מבחינת המנהיגות של מנהל הפרוייקט?

הזרמת מטלות חדשות ככל שהעובד מסיים את המטלות הנוכחיות.

שמירה שוטפת על רמת קושי קבועה על המטלות בפרוייקט

התאמת משימות לעובד כך שיתלהב לעשות אותן. הוספת קושי עם עלית הכישורים.

מעקב שוטף אחר עמידת העובד בייעדים

חסרונות המבנה המטריציוני הם:

יעילות הקצאת משאבים, אבטלה סמוייה, שינוי עומסים בציר הזמן, חוסר מקצוענות

יעילות, גמישות, מקצוענות, כפל מנהלים

מחוייבות רק למשימה אחת, קו פיקודי, נהול לפי ייעדים, מהירות

דלת מסתובבת, חוסר מחוייבות, ריבוי משימות, קושי לאמוד לוחות זמנים.

חמשת השלבים בפרויקט Solicited מבחינת הספק הם:

Resources, Process, Gap, Taper, Negotiate

Materials, Cost, Outsourcing, Offshoring, Non-Development-Items

Materials & SOW, BOM, Non-Development-Items, WBS, Time

RFI, Taper, RFQ, Negotiate, Deliver

כאשר לפרוייקט אין מועד מסירה קשיח:

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

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

יש לרכז את מלוא הדרישות, להקצות אותן למשאבים שאינם צואר בקבוק, לוודא איכות, להביא למצויינות

מסירה מוקדמת, הצוות מתגייס, הפלטפורמה ייקרה מידי, הביצועים בינוניים.

בפיתוח Agile ,לאחר שאופיינו דרישות בתחילת הפרוייקט:

במפגש היומי (יישיבה בעמידה) מתווספות לעיתים מזומנות דרישות של הלקוח.

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

אין הוספה או גריעה של דרישות.

עלולות להתווסף דרישות נוספות של הלקוח ובעקבותיהן אי עמידה בייעדי הספרינט.

בניהול פרוייקט מסוג C:

הקפאת הדרישות בשלב מאוחר, יש בנייה של הוכחת היתכנות, המפגשים תכופים, מספר רב של סבבים.

הקפאת הדרישות בטרם תחילת הפרוייקט, שני סבבים לכל היותר, תשלום ב-Plus Cost ,הקפדה על עמידה במפרט

אין הקפאת דרישות, אי ודאות ברמה בינונית, בניית ארכיטקטורות חלופיות, Concept Of P

הקפאת דרישות בתום רבעון ראשון, שני סבבי שיפורים, תשלום בשיטת Time & Materials ,מפגשים פורמליים.

בתוכנת Project-MS כאשר חבר צוות מתחלף באחר מקובל:

לעדכן החלקת משאבים (שרשרת קריטית).

אין צורך לעדכן משום שחברי הצוות לרוב אנונימיים, התייחסות רק למקצועיות שלהם.

לעדכן גרף עומס משאבים לפי כישוריהם היחסיים.

עדכן כתובת דוא"ל לתכתובות במהלך הפרוייקט.

ניהול יומיומי של הפרוייקט מבוצע באמצעות:

חישוב המאמץ שחלף מהייזום

ניהול לפי יעדים, מפגשי One on One ללא עדכון שוטף של התוכנה.

תרשים הגאנט.

חישוב פרק הזמן עד לסיום.

אחד הכלים המקשים על "תפירת" מכרז הוא:

הפרדה בין תכונות הביצוע לבין מימד העלות.

הפרדה בין הצוות המאפיין את התכונות ומשקלן לצוות שנותן ציונים לחלופות.

אנונימיות של החברות שניגשות למכרז.

. שיקלול "תשואה שולית פוחתת" בנתינת הציונים להצעות השונות.

תופעת Multitasking Bad היא תוצאה של:

מנהל פרוייקט עם נטיה ל-MicroManagement

מנהל פרוייקט שאינו מתעדכן בהתקדמות הפרוייקט.

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

עבודה במבנה מטריציוני

בעיה הנגזרת מפרישׂת פונקציית האיכות– Deployment Function Quality:

היווצרות אוקיינוס כחול.

עליית רמת הדרישות של הלקוחות מהפלטפורמה.

התפשרות הלקוחות עם מוצרים ברמה נמוכה.

התכנסות כלל הייצרנים למוצרים חסרי בידול – commodity.

:כאשר Stuck in the Middle הוא מוצר

אין לו יתרון של עלות נמוכה או של בידול.

כאשר האסטרטגיה הגנרית שלו אינה מובהקת.

כאשר הוא גם איכותי וגם זול (דוגמת Ikea.(

כאשר מחירו אינו זול אך גם איננו גבוה.

ב"המחרה":

המחיר נקבע על פי העלות לייצרן.

מתבצע משא ומתן מול הספקים הסופיים.

מבוצע תהליך של מכרז הולנדי.

המחיר נקבע על פי ערכו ללקוח.

משמעות המונח פרישׂה – Deploy בפרישׂת פונקצית האיכות היא:

אבחון משימות שונות שביחד יביאו להשגת מרכיב בפונקצית האיכות.

הגדרת ייעדי השבחה לפרוייקט – ה-Gap.

זיהוי המרכיבים השונים של פונקצית האיכות.

בחירת ה-Persona שלה מייעדים את המוצר.

הבעיה ברמת הבשלות Initial היא:

בירוקרטית יתר של התהליך.

חזרה על טעויות שנעשו, חוסר אחידות וחוסר שליטה.

. מנהל הפרוייקט הופך לצוואר בקבוק.

לא זמינה תוכנה לתמיכה במודל זה.

משמעות שלב הרידוד – Taper בחיי הפרוייקט היא:

צמצום המאמץ באינטגרציה עם המערכות האחרות בארגון.

בחירה מושכלת של דרישות שהוצעו בשלב ה-RFI.

צמצום דרישות הספק בנושאים של תקציב וזמינות לקוחות.

משא ומתן לאפשור שינויים מסויימים לאחר סיום הפרוייקט

תפקיד הפלטפורמה הוא:

לאפשר ריבוי פרוייקטים מסוג B :Generation Next.

פיתוח משפחת מודולים שניתן למכור ללקוח גם לאחר ההתקנה הראשונית.

פיתוח רכיב משותף שתומך באסטרטגיות גנריות שונות.

פיתוח מודולים שונים שצירופם יספק דרישות של לקוחות שונים.

בפיתוח Agile ,לקראת סיום הפרוייקט:

ש לנפות דרישות כך שהמאמץ יתרכז להשלים פונקציונליות חדשה.

במפגש היומי (ישיבה בעמידה) מתווספות לעיתים מזומנות דרישות של הלקוח.

יש רק הוספה של דרישות – Way the By Oh.

אין הוספה או גריעה של דרישות.

בניהול פרוייקט מסוג A:

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

א. הניהול פורמלי, התקשורת בצוות לעיתים רחוקות, הדגש על עמידה מדויקת בהתחייבויות.

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

ב. מונעים סבבי פיתוח על ידי פירוק עבודה חוזרת לתת מכלולים.