דלג לתוכן
ספריית פרומפטים מקצועית

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

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

  • 50 פרומפטים ל-ניהול פרויקטים
  • להעתקה או להרצה בצ'אט

כתיבת מסמך ייזום פרויקט (Charter)

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

נסח מסמך ייזום (Charter) עבור הפרויקט [שם הפרויקט] בחברת [שם החברה]. מטרת הפרויקט: [מטרה]. ספונסר/מזמין: [שם]. צוות: [הרכב]. תקציב: [תקציב]. תאריך יעד: [יעד]. הרקע ליציאה לפרויקט: [הקשר].

מבנה המסמך: הקשר והבעיה לפתרון (3 שורות), מטרה מדידה, טווח הפרויקט (In Scope), ומה מחוץ לטווח (Out of Scope) באופן מפורט כדי למנוע זליגת פרויקט. תוצרים עם קריטריוני קבלה, אבני דרך מתוארכות, תפקידים ואחריות (מודל RACI: מי מחליט, מי מבצע, עם מי מתייעצים), סיכונים מזוהים עם תוכנית מענה לכל אחד ([סיכונים ידועים]), הנחות עבודה ותלויות.

נסח כל סעיף כך שחילוקי דעות יצופו כעת, בשלב הקריאה, ולא באמצע הביצוע. סיים ב-3 שאלות קריטיות להכרעה בוועדת ההיגוי לפני ההשקה.

הפיכת הערות פגישה לסיכום מנהלים

סיכום קצר הכולל החלטות ומשימות לביצוע מתוך הערות גולמיות.

הפוך את ההערות הגולמיות שלי מהפגישה לסיכום מנהלים מובנה. נושא הפגישה: [נושא] מתאריך [תאריך], משתתפים: [משתתפים]. להלן ההערות: [הערות גולמיות].

פורמט פלט: החלטות שהתקבלו (ניסוח חד-משמעי, כולל מי קיבל את ההחלטה), משימות לביצוע (טבלה: משימה, אחראי, תאריך יעד; אם אחד הנתונים חסר בהערות שלי, סמן "לבירור" במקום להמציא), נקודות לדיון ללא הכרעה (עד 2 שורות לכל נקודה), נושאים שנדחו לפגישה הבאה.

כללים: עמוד אחד לכל היותר. ללא ניסוחים דיפלומטיים שמעמימים החלטות (ביטויים כמו "הוסכם לקדם את הנושא" אסורים). סיים ברשימת הנתונים החסרים ("לבירור") שיש לשלוח למשתתפים לאישור.

פירוק פרויקט לחבילות עבודה ותכנון לו"ז

מעבר מהמטרה לתוכנית עבודה: משימות, תלויות ונתיב קריטי.

פרק את הפרויקט הבא לחבילות עבודה ובנה לו"ז. פרויקט: [תיאור הפרויקט ותוצר סופי]. תאריך יעד: [תאריך]. צוות זמין: [אנשים וזמינות, למשל: 2 אנשים בחצי משרה]. אילוצים ידועים: [אילוצים: אישור לקוח, תלות בספק חיצוני, תקופת חגים].

שלבי עבודה: פרק לחבילות עבודה (Work Packages) שכל אחת מייצרת תוצר שניתן לבדיקה, פרק כל חבילה למשימות של 0.5 עד 3 ימים, זהה תלויות בין משימות ואת הנתיב הקריטי (Critical Path). הגדר מרווח ביטחון (Buffer) גלוי למשימות בסיכון גבוה במקום להחביא מרווחים בכל משימה.

הגש: רשימה מובנית של חבילות ← משימות עם הערכות זמן, תוכנית שבועית עם אבני דרך לאישור, הדגשת הנתיב הקריטי, ו-3 המשימות שיש להתחיל מיד כי הן מעכבות את השאר. התרע אם תאריך היעד [תאריך] אינו ריאלי עם הצוות המתואר, בגיבוי נתונים, במקום לדחוס הערכות זמן בצורה לא אמינה.

כתיבת דו"ח סטטוס שבועי (Flash Report)

עדכון של עמוד אחד שמנהלים באמת קוראים: רמזור, עובדות והחלטות נדרשות.

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

פורמט קשיח של עמוד אחד: סטטוס רמזור (ירוק/צהוב/אדום) עם משפט אחד שמצדיק את הצבע. 3 אירועים מרכזיים מהשבוע, התקדמות מול תוכנית (שורה אחת לכל חבילת עבודה פעילה), סיכונים ונקודות תורפה (רק מה שהשתנה מהשבוע שעבר), החלטות נדרשות עם שם המקבל והשפעת העיכוב, סדרי עדיפויות לשבוע הבא.

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

ניהול ישיבת הפקת לקחים (Retrospective)

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

הכן מערך להנחיית ישיבת הפקת לקחים לפרויקט [שם הפרויקט], שהסתיים זה עתה [תוצאה: בזמן, בעיכוב של X, בוטל]. משתתפים: [שמות ותפקידים]. משך הישיבה: [זמן, למשל: שעה וחצי]. נקודות בולטות: [מה עבד טוב, מה השתבש, מתחים בצוות].

הגש: לו"ז מפורט (פתיחה המדגישה "מחפשים סיבות, לא אשמים", איסוף נתונים אישי לפני דיון קבוצתי למניעת הטיית קונפורמיות, דיון בנקודות מרכזיות, החלטות). שאלות מדויקות לשאילה כדי להימנע מסיסמאות (למשל: "באיזו נקודה בדיוק ידענו שהלו"ז מחליק? מה מנע מאיתנו להציף את זה?"), וטכניקה לניהול דיון ב[נושא רגיש] מבלי שיהפוך להאשמות אישיות.

פורמט מסקנות: כל לקח הופך לכלל עבודה לפרויקט הבא ("מהיום אנחנו..."), עם אחראי ליישום. מקסימום 5 כללים כדי להבטיח יישום.

בניית בדיקת היתכנות (Go/No-Go)

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

אתה מנהל פרויקטים מנוסה. עזור לי לבנות בדיקת היתכנות לפרויקט [שם הפרויקט] שנשקל בחברת [שם החברה]. הבעיה או ההזדמנות שבבסיס הפרויקט: [הקשר]. תועלות צפויות: [רווחים/חיסכון]. תקציב מקסימלי אפשרי: [סכום ב-₪]. חלופות ידועות: [חלופות, כולל אי-עשייה].

בנה את המסמך ב-6 חלקים: הבעיה ועלות אי-העשייה (Cost of Inaction), חלופות אפשריות (כולל הסטטוס קוו) עם יתרונות וחסרונות, הערכה גסה של עלויות ולוחות זמנים לכל חלופה (בטווח רחב), תועלות צפויות המקושרות למדדים מדידים (KPIs), סיכונים מרכזיים לכל חלופה, והמלצה מנומקת.

אילוצים: כל תועלת חייבת להיות מקושרת למדד שניתן לאימות, אחרת סווג אותה כ"הימור לא מדיד". נסח 5 קריטריונים להחלטת Go/No-Go. סיים ברשימת המידע החסר שמחליש את הבדיקה ומי אמור לספק אותו.

כתיבת אמנת פרויקט (Project Charter) מהירה

מסמך של עמוד אחד לפרויקטים קטנים ללא הסרבול של מסמך ייזום מלא.

נסח אמנת פרויקט של עמוד אחד לפרויקט קטן שאינו מצדיק מסמך ייזום מלא. פרויקט: [תיאור ב-2 שורות]. מזמין: [שם]. מעורבים: [אנשים וזמינות]. תאריך יעד מבוקש: [תאריך]. תקציב: [סכום או ללא].

פורמט מחייב, עמוד אחד בלבד: מטרה במשפט מדיד אחד, תוצר סופי ואיך נדע שהוא הושלם, מה מחוץ לטווח (לפחות 3 שורות - זה החלק החשוב ביותר), מי מקבל החלטות במקרה של מחלוקת, אבני דרך (מקסימום 3), הסיכון המרכזי ודרכי התמודדות.

כללים: ללא ז'רגון ניהולי מורכב, משפטים שכל עובד יבין בקריאה ראשונה. אם המידע שסיפקתי לא מאפשר למלא סעיף, כתוב "לבירור מול [אדם]" במקום להמציא. סיים ב-2 שאלות שיש לשאול את המזמין לפני תחילת העבודה.

הכנת ראיונות לאיסוף דרישות

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

אני מתחיל את פרויקט [שם הפרויקט] בחברת [שם החברה] ועלי לאסוף דרישות לפני קביעת טווח הפרויקט. אנשים לראיון: [רשימת פרופילים, למשל: הנהלה, משתמשי שטח, תמיכה, IT]. התוצר המצופה מהפרויקט: [תוצר]. זמן זמין לכל ראיון: [משך].

הכן לכל פרופיל מדריך ראיון מותאם: 8-10 שאלות פתוחות מהכללי לפרטי. הבחן בין שאלות על המצב הקיים (נקודות כאב, מעקפים, נפחי עבודה) לשאלות על הצורך העתידי. הוסף לכל פרופיל 2 שאלות "מלכודת" שמציפות צרכים לא מדוברים, למשל: "מה אתם עושים כשהכלי הנוכחי לא מספיק?".

כללים: הימנע משאלות מנחות או שאלות של כן/לא. ספק תבנית לסיכום הראיונות: צרכים שהוצהרו, צרכים שהשתמעו, סתירות בין פרופילים שיש להכריע בהן, וציטוטים (Verbatims) משמעותיים.

כתיבת User Stories וקריטריוני קבלה

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

הפוך את הצרכים הגולמיים הבאים ל-User Stories שצוות הביצוע יכול לעבוד איתם. פרויקט: [שם ותיאור קצר]. משתמשים רלוונטיים: [פרופילים]. צרכים שהועלו: [רשימת צרכים, גם אם כלליים].

עבור כל צורך, הפק: User Story בפורמט "בתור [פרופיל], אני רוצה [פעולה] כדי ש[תועלת]", 3-5 קריטריוני קבלה (Acceptance Criteria) מנוסחים בצורה בינארית (ניתן לבדיקה בכן/לא, ללא מילים כמו "מהיר" או "נוח" ללא רף מדיד), ושאלות לשאול את המזמין אם הצורך עמום מדי.

כללים: סיפור משתמש חייב להיות בר ביצוע תוך ימים ספורים, אחרת הצע פירוק לסיפורים קטנים יותר. זהה פתרונות שמתחפשים לצרכים ונסח אותם מחדש כצורך אמיתי. הצג בטבלה: Story, קריטריוני קבלה, הערכת גודל (S/M/L), שאלות פתוחות. סיים ברשימת תלויות בין סיפורי המשתמש.

תיעדוף Backlog עמוס

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

עזור לי לתעדף את ה-Backlog של פרויקט [שם הפרויקט]. משימות ממתינות: [רשימת בקשות עם תיאור קצר]. קיבולת הצוות (Capacity): [למשל: 15 ימי עבודה בחודש]. מטרה מרכזית לרבעון: [מטרה]. גורמים לוחצים: [הקשר פוליטי/ארגוני].

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

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

בניית מפת דרכים (Roadmap) רבעונית

תוכנית רבעונית ממוקדת תוצאות, הכוללת את הרציונל מאחורי כל בחירה.

בנה מפת דרכים ל-2 הרבעונים הבאים עבור [מוצר או פרויקט] בחברת [שם החברה]. מטרות שנתיות: [מטרות]. פרויקטים מועמדים: [רשימה]. קיבולת הצוות: [גודל וזמינות]. התחייבויות קיימות: [התחייבויות ללקוחות או פנימיות].

ארגן את מפת הדרכים לפי רבעונים, כאשר כל שורה מנוסחת כתוצאה מצופה ולא כפיצ'ר (למשל: "צמצום זמן הטיפול בבקשות" במקום "פיתוח מודול X"). לכל רבעון: 2-3 פרויקטים מרכזיים, התוצאה המבוקשת, המדד להצלחה ותלויות.

כללים: שמור 20% מהקיבולת לבלתי צפוי וציין זאת במפורש. רשום מה הוחלט לא לכלול ולמה, כדי למנוע שאלות "למה לא X?". ספק שתי גרסאות: מפורטת לצוות וגרסת 5 שורות להנהלה. סמן פרויקטים שהערך שלהם עמום מדי לשיבוץ.

הערכת משאבים וזמנים ללא אשליות

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

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

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

כללים: כאשר קיימת היסטוריה, השווה את ההערכה לזמן הביצוע בפועל בעבר והסבר את הפער. הוסף תמיד משאבים שנוטים להישכח: תיקונים לאחר בדיקות (QA), תיאום, למידה, והיעדרויות צפויות. הצג את הסיכום ב-3 תרחישים עם אחוז הפער ביניהם. אם הפער עולה על פי 2, ציין איזה מידע חסר כדי לצמצם את אי-הוודאות.

בניית תקציב פרויקט ומעקב חודשי

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

בנה תקציב מלא לפרויקט [שם הפרויקט] בחברת [שם החברה]. משאבים פנימיים: [ימי עבודה לפי פרופיל ועלות יומית]. רכש וספקים חיצוניים: [רשימה]. משך הפרויקט: [זמן]. מסגרת תקציבית מאושרת: [סכום ב-₪].

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

בנה מנגנון מעקב חודשי: טבלת ניצול מול תקציב, הערכה מחדש של יתרת העבודה (ETC - Estimate to Complete), תחזית לסיום הפרויקט (EAC), ו-2 ספי התראה שמחייבים עדכון ספונסר. סיים ב-3 החריגות התקציביות הנפוצות בפרויקטים כאלו ואיך לזהותן מוקדם.

בניית סקר סיכונים לפרויקט

ניהול סיכונים מתועד ומדורג, כולל תוכנית מענה ואחראי לכל סיכון מרכזי.

בנה סקר סיכונים לפרויקט [שם הפרויקט]. הקשר: [תיאור הפרויקט, יעד, חשיבות]. סיכונים ידועים: [סיכונים שכבר זוהו]. תלויות חיצוניות: [ספקים, צוותים אחרים, אישורים רגולטוריים].

השלם את הרשימה עם סיכונים אופייניים לפרויקטים כאלו ב-4 קטגוריות: אנושיים (עזיבה, עומס, חוסר מיומנות), טכניים, ארגוניים (עיכוב בהחלטות, זליגת טווח), וחיצוניים. לכל סיכון: תיאור קונקרטי של מה יקרה, סבירות (נמוכה/בינונית/גבוהה), השפעה (נמוכה/בינונית/גבוהה), רמת קריטיות, סימן מקדים (Trigger), תוכנית מניעה, תוכנית מגירה (Mitigation), ואחראי למעקב.

כללים: נסח כל סיכון כאירוע ספציפי (למשל: "הספק מאחר בחודש במסירה"), לא כנושא כללי. הגבל את הרשימה ל-10 הסיכונים שבאמת דורשים ניהול. פרט את שגרת הבקרה: תדירות ושאלות מנחות.

מיפוי מחזיקי עניין (Stakeholders)

מיפוי השפעה מול תמיכה של הגורמים המעורבים, עם תוכנית רתימה מותאמת.

מפה את מחזיקי העניין בפרויקט [שם הפרויקט] בחברת [שם החברה]. גורמים מזוהים: [רשימת אנשים או יחידות ותפקידם]. מה הפרויקט ישנה עבורם: [השפעות צפויות]. תמיכה או התנגדות שכבר זוהו: [הקשר].

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

כללים: אל תתבלבל בין המבנה הארגוני להשפעה בפועל - ציין גורמים ללא תואר רשמי שדעתם קובעת. הצג תוכנית רתימה בטבלה: גורם, סטטוס נוכחי, סטטוס נדרש להצלחה, פעולות, אחראי, לו"ז. סיים ב-2 הגורמים שיש לפגוש בעדיפות עליונה השבוע ולמה.

בניית תוכנית תקשורת לפרויקט

מי מקבל מידע, על מה, באיזו תדירות ובאיזה ערוץ, מבלי להציף אף אחד.

בנה תוכנית תקשורת לפרויקט [שם הפרויקט]. קהלי יעד: [קהלים, למשל: ספונסר, צוות, משתמשי קצה, מחלקות אחרות]. משך הפרויקט: [זמן]. רגעים קריטיים ידועים: [אבני דרך, השקות, הודעות]. ערוצים זמינים: [פגישה, מייל, Slack/Teams, פורטל ארגוני].

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

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

בניית מטריצת אחריות RACI

חלוקת סמכויות ואחריות ללא עמימות, כולל זיהוי כפילויות או חוסרים.

בנה מטריצת RACI לפרויקט [שם הפרויקט]. פעילויות מרכזיות: [רשימת תוצרים/פעילויות]. מעורבים: [אנשים או תפקידים]. מתחים או חוסר בהירות שכבר עלו: [הקשר, למשל: שני אנשים חושבים שהם מחליטים על אותו נושא].

לכל פעילות, הקצה תפקידים: R (מבצע), A (אחראי סופי ומדווח, רק אחד לכל שורה), C (מתייעצים לפני), I (מעדכנים אחרי). הסבר בשורה אחת כל הקצאה שאינה מובנת מאליה.

בדיקת איכות: וודא שאין שני A בשורה אחת, שאין שורה ללא R, והתרע על גורמי C שמופיעים כמעט בכל שורה (צוואר בקבוק) או אנשים ללא שום תפקיד. הצג בטבלה, וציין את 3 השורות שעלולות לייצר קונפליקט עם המלצה איך לאבטח אותן, ושאלות להכרעה בצוות לפני הפצת המטריצה.

הכנת פגישת התנעה (Kick-off)

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

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

הגש: לו"ז מפורט (למה הפרויקט קורה עכשיו, התוצר הסופי, מה מחוץ לטווח, מי עושה מה, אבני דרך, כללי עבודה בצוות, שאלות ותשובות). 3 מסרים מרכזיים שכל משתתף חייב לזכור ביציאה. דרך לטיפול ב[נקודה רגישה] מבלי להעיב על הפגישה אך גם מבלי להתעלם ממנה.

כללים: פגישת התנעה אינה הרצאה חד-צדדית; תכנן 2 רגעים שבהם המשתתפים פעילים (זיהוי סיכונים מהיר, סבב אילוצים אישיים). ספק נוסח להזמנה הכולל סדר יום ומה עליהם להכין, ורשימת דברים שחייבים להיות מאושרים לפני הפגישה כדי לא להתניע פרויקט עמום.

הכנת סדר יום וניהול ועדת היגוי (COPIL)

פגישת הנהלה ממוקדת החלטות, לא קריאה משותפת של דו"חות התקדמות.

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

בנה את סדר היום סביב ההחלטות שיש לקבל, לא סביב דיווח הסטטוס: כל החלטה נדרשת הופכת לסעיף עם זמן מוקצב, אופציות מוכנות (2-3, עם יתרונות, חסרונות והמלצה), ומה יקרה אם ההחלטה תידחה שוב. דיווח ההתקדמות יוגבל ל-10 דקות על בסיס מסמך שנשלח מראש.

ספק: סדר יום מתומזמן, ניסוח מדויק לכל בקשת החלטה, טכניקה לחיתוך מנומס של סטיות מהנושא ב[נושא רגיש], ותבנית לסיכום החלטות שיישלח תוך 24 שעות. סיים ברשימת החומרים שיש לשלוח למשתתפים 48 שעות מראש.

מבנה מצגת לוועדת היגוי

שלד למצגת ועדת היגוי קריאה וממוקדת ב-10 שקפים.

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

הפק מבנה שקף אחר שקף, מקסימום 10 שקפים: סיכום מנהלים בשקף אחד (רמזור, מסר מרכזי, החלטות נדרשות), התקדמות לפי חבילות עבודה עם פערים מול תוכנית, מצב תקציבי, סיכונים שדירוגם השתנה, צלילה לנקודת התורפה של החודש עם אופציות והמלצה, החלטות נדרשות (שקף לכל החלטה), צעדים הבאים.

לכל שקף: כותרת המנוסחת כמסר (למשל: "חבילה 2 מצמצמת פערים", לא "סטטוס חבילה 2"), תוכן ב-5 נקודות מקסימום, ומה להגיד בעל-פה שלא מופיע בשקף. כללים: ללא שקפי רקע שהוועדה כבר מכירה, מספרים מעוגלים ומושווים (לתוכנית, לחודש שעבר). סיים בבדיקה: אם הוועדה תקרא רק את שקף 1, האם יש להם את המידע הקריטי?

הקמת תהליך ניהול שינויים (Change Requests)

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

הקם תהליך לניהול בקשות לשינויים בפרויקט [שם הפרויקט]. הקשר: [מקור הבקשות, למשל: לקוח מוסיף דרישות, הנהלה משנה דעה]. פורומים קיימים: [פגישות וועדות]. מרווח ביטחון זמין: [יתרת זמן ותקציב].

הגדר: טופס בקשה מינימלי (תיאור, מבקש, הצדקה, דחיפות אמתית), 4 שאלות בחינה קבועות (השפעה על לו"ז, תקציב, חבילות עבודה אחרות, ומה יקרה אם לא נעשה זאת), מי מחליט לפי גודל ההשפעה (הצע ספי סמכות), ואיך מתעדים החלטות ביומן שינויים.

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

ניהול משא ומתן על לו"ז לא ריאלי

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

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

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

כללים: לעולם לא להגיד "זה בלתי אפשרי" בלי חלופה. לעולם לא להסכים בפגישה לפשרה שלא נבדקה מספרית. הכן תשובות ל-3 התנגדויות צפויות, כולל "תסתדרו" ו"נראה כבר". פורמט: עמוד טיעונים פלוס טבלת 3 אופציות עם השלכות להשוואה.

בניית תוכנית התאוששות לפרויקט בעיכוב

אבחון העיכוב ובניית תוכנית חזרה למסלול ריאלית, ללא דחיסה מלאכותית של הלו"ז.

בנה תוכנית התאוששות (Recovery Plan) לפרויקט [שם הפרויקט], שנמצא בעיכוב של [משך העיכוב] מול יעד ב-[תאריך]. סיבות מזוהות: [סיבות לעיכוב]. יתרת עבודה: [משימות שנותרו עם הערכות]. צוות: [הרכב וזמינות]. מרחב תמרון: [תקציב נוסף אפשרי, טווח גמיש או לא].

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

כללים: אסור להתאושש על ידי "דחיסת" הערכות זמן ללא הצדקה. אסור לבטל זמני בדיקות (QA). הגש: לו"ז חדש עם תאריך אמין, מה הוקרב כדי להשיגו, 2 תנאים להצלחת התוכנית, והודעה לספונסר שלוקחת אחריות על העיכוב ללא הצפה בפרטים מיותרים.

הסלמה (Escalation) של חסם מבלי לשרוף גשרים

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

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

נסח את הודעת ההסלמה: תזכורת לחסם ב-3 שורות עובדתיות ומתוארכות, השלכות קונקרטיות של המצב הקיים במונחים כספיים או זמנים (ימים אבודים, אבני דרך בסכנה), 2-3 אופציות לשחרור החסם עם המלצתי, והחלטה נדרשת עד מתי.

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

ניהול מעקב משימות בין פגישות

מערכת מעקב ותזכורות שמקדמת ביצוע מבלי להרגיש כמו "שוטר".

ארגן את מעקב המשימות בפרויקט [שם הפרויקט] בין הפגישות. מצב נוכחי: [הבעיה, למשל: משימות שמסוכמות בפגישה מבוצעות רק בחלקן, תזכורות נתפסות כהצקה]. תדירות פגישות: [תדירות]. כלים זמינים: [אקסל, Monday/Jira, מייל/ווטסאפ].

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

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

עיצוב לוח בקרה (Dashboard) לפרויקט

מדדי התקדמות שמראים את המסלול האמיתי של הפרויקט, לא אשליה של שליטה.

עצב לוח בקרה לפרויקט [שם הפרויקט]. סוג הפרויקט ותוצר: [תיאור]. משך: [זמן]. נקודות רגישות למעקב: [למשל: לו"ז צפוף, תקציב מוגבל, איכות קריטית]. נתונים זמינים: [מקורות: כלי ניהול משימות, דיווחי שעות, תקציב].

בחר 6-8 מדדים מקסימום, מחולקים ל-3 בלוקים: התקדמות (בוצע מול מתוכנן בתוצרים סופיים, לא באחוזי התקדמות מוצהרים של משימות פתוחות), בריאות הפרויקט (משימות בפיגור, החלטות ממתינות ומשך ההמתנה, סיכונים שדירוגם עלה), ומשאבים (ניצול תקציב, עומס על הצוות).

לכל מדד: הגדרה מדויקת, מקור נתונים, תדירות עדכון, וסף התראה מוצדק. כללים: הימנע ממדדים סובייקטיביים ("80% התקדמות") לטובת מדדים בינאריים של בוצע/לא בוצע. תאר תהליך קריאה שבועי של 15 דקות: סדר הקריאה, שאלות מנחות, ומתי להסלים מעבר לצוות.

כתיבת דו"ח סטטוס חודשי להנהלה

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

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

פורמט מחייב, עמוד אחד: מסלול כללי ב-2 שורות (האם הפרויקט ינחת בזמן ובתקציב, כן/לא, ומה השתנה החודש), הישגי החודש ב-3 נקודות המקושרות לאבני דרך, פערים עם הסיבה והטיפול בהם (אין להציג פער ללא תוכנית מענה), תקציב בשורה אחת עם תחזית לסיום, והתראות הדורשות מעורבות הנהלה עם בקשה מפורשת.

כללים: ההנהלה קוראת עשרות דו"חות כאלו - ללא משפטי שיווק עצמי או מילים מיותרות. כל התראה חייבת להוביל לבקשה מדויקת (הכרעה, משאב, החלטה). פערים ובשורות רעות יופיעו בראש העמוד, לא בסופו.

תיעדוף משאבים בין מספר פרויקטים

שיטה לתיעדוף בין פרויקטים מתחרים תוך הצגת ההשלכות של כל בחירה.

עזור לי לתעדף משאבים בין מספר פרויקטים מתחרים. פרויקטים פעילים: [רשימה עם יעד, חשיבות וסטטוס]. משאבים משותפים: [אנשים שעובדים על מספר פרויקטים וחלוקתם הנוכחית]. הקונפליקט הנוכחי: [תיאור הקונפליקט במשאבים]. מי הגורם המכריע: [פורום או אדם].

בנה קודם כל תמונת מצב כנה: מי עובד על מה באחוזים אמיתיים (לא תיאורטיים), ואיפה יש אנשים שמוקצים ביותר מ-100%. לאחר מכן, הצע מטריצת תיעדוף מבוססת קריטריונים: חשיבות אסטרטגית לחברה, עלות העיכוב בכל פרויקט, חלון הזדמנויות שנסגר, והתחייבויות חיצוניות.

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

הכנת תכנון ספרינט (Sprint Planning)

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

הכן תכנון לספרינט הבא של צוות [שם הצוות] בפרויקט [שם הפרויקט]. משך הספרינט: [זמן]. קיבולת (Capacity): [אנשים נוכחים, היעדרויות צפויות, זמן קבוע מחוץ לספרינט: תמיכה, פגישות]. Backlog מתועדף: [משימות מועמדות עם הערכת גודל]. שאריות מספרינט קודם: [משימות שלא הושלמו].

בנה את מבנה הישיבה: חישוב קיבולת ריאלית (זמן זמין פחות קבוע פחות בלתי צפוי), ניסוח מטרת הספרינט במשפט אחד המתאר את התוצאה (לא רשימת משימות), בחירת משימות במסגרת הקיבולת החל מהשאריות, ואימות קבוצתי שכל משימה מובנת ומוגדרת מספיק להתחלה.

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

ניהול רטרוספקטיבת ספרינט אפקטיבית

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

הכן מערך להנחיית רטרוספקטיבת ספרינט לצוות [צוות]. משך: [זמן, למשל: 45 דקות]. אווירה נוכחית: [הקשר, למשל: טקס שחוק שבו איש לא מדבר, מתח לאחרונה, צוות חדש]. נושאים בוערים: [אירועים מהספרינט האחרון]. פעולות מרטרו קודם: [מה הוחלט ומה בוצע בפועל].

הגש: לו"ז מפורט המתחיל בבדיקת ביצוע המשימות מהרטרו הקודם (רטרו שמשימותיו לא מבוצעות גווע תוך 3 פעמים), פורמט הנחיה מותאם ל[אווירה נוכחית], שאלות המשך כשהצוות נשאר ברמת סיסמאות, ושיטת בחירה: מקסימום 2 פעולות לשיפור, שנבחרו על ידי הצוות, עם אחראי ותאריך יעד בספרינט הבא.

כללים: ללא פעולות מסוג "לתקשר טוב יותר" - כל פעולה חייבת לתאר שינוי שניתן לצפות בו. נושאים שאינם בשליטת הצוות (ארגון, היררכיה) יירשמו בנפרד להסלמה ולא יידונו בלופ. הצע 2 פורמטים חלופיים לגיוון הטקס בעתיד.

הגדרת Daily Standup מועיל

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

הגדר את הפגישה היומית (Daily) של צוות [צוות] בפרויקט [שם הפרויקט]. מצב נוכחי: [הבעיה, למשל: הפגישה נמשכת 30 דקות, הופכת לדיווח למנהל, אנשים מאבדים עניין]. גודל הצוות: [מספר]. מודל עבודה: [מהמשרד, מרחוק, היברידי].

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

ספק: כללי הנחיה שמונעים דיווח למנהל (הצוות מדבר בינו לבין עצמו, רוטציה בהנחיה), משפט לעצירת סטיות מהנושא ללא פגיעה, התאמות ל[מודל עבודה], ו-3 סימנים שה-Daily הפסיק להיות מועיל עם פתרון לכל אחד. סיים בהודעה לצוות על הפורמט החדש שמסבירה את ה"למה" מבלי לפסול את העבר.

הגדרת Definition of Done (DoD) ומדדי איכות

הגדרה משותפת למונח "בוצע" שמונעת תוצרים שגמורים ב-90% אך לא יוצאים לעולם.

עזור לצוות [צוות] להגדיר את ה-Definition of Done (DoD) שלו לפרויקט [שם הפרויקט]. סוג התוצרים: [תוכנה, חומרי הדרכה, מסמכי אפיון]. בעיות שזוהו: [סימפטומים, למשל: תוצרים מוכרזים כגמורים ואז נפתחים מחדש, איכות לא אחידה, בדיקות שמגלות חוסרים בסיסיים].

בנה את ה-DoD ב-3 רמות: מה הופך פריט ל"בוצע" (קריטריונים מדידים: עבר סקירת עמיתים, נבדק, תועד, אושר על ידי מי), מה מוחרג במפורש מההגדרה כדי להישאר ריאליים, ואיזה חריגות מותרות ואיך מתעדים אותן במקום להחביא אותן.

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

ניהול בדיקות קבלה (UAT) ופרוטוקול אישור

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

ארגן את בדיקות הקבלה (UAT) לפרויקט [שם הפרויקט]. התוצר לבדיקה: [תיאור]. בודקים זמינים: [פרופילים וזמינות]. משך מתוכנן: [זמן]. קריטריוני קבלה קיימים: [קריטריונים שהוגדרו מראש, או ללא].

בנה: תוכנית בדיקות עם תרחישים (Test Cases) המבוססים על מסע משתמש אמיתי (לא לפי מסכים או פונקציות), כל תרחיש כולל נתוני קלט, פעולה ותוצאה צפויה. תיעדוף תרחישים (קריטי להשקה, חשוב, נוחות). כלל סיווג תקלות עם דוגמאות לכל רמה למניעת ויכוחים. תהליך תיקון ובדיקה חוזרת.

ספק גם תבנית לפרוטוקול מסירה (PV): מה נבדק, תקלות לפי רמה, החלטה (אישור, אישור עם הסתייגויות מתוארכות, דחייה) וחתימות. כללים: בדיקה ללא נתונים ריאליים אינה מוכיחה דבר - פרט איך להכין סט נתונים. הסתייגויות שאושרו חייבות לכלול אחראי ותאריך לתיקון.

הכנת תוכנית עלייה לאוויר וצ'קליסט מעבר

לו"ז שעה אחר שעה של המעבר לייצור, כולל קריטריוני Go/No-Go ותוכנית נסיגה (Rollback).

הכן תוכנית עלייה לאוויר עבור [תוצר או מערכת] בפרויקט [שם הפרויקט]. תאריך יעד: [תאריך]. משתמשים מושפעים: [מי וכמה]. חלון זמן אפשרי: [למשל: סופ"ש, לילה, שעות עבודה]. משתתפים במעבר: [אנשים ותפקידים]. אפשרות לנסיגה (Rollback): [כן/לא/חלקי, ואיך].

בנה: צ'קליסט לפני מעבר (דרישות טכניות, אישורים, תקשורת שבוצעה, גיבויים שנבדקו, זמינות אנשי מפתח), לו"ז מעבר שעה אחר שעה עם אחראי לכל שלב ומדד הצלחה מדיד לכל שלב, נקודות החלטה Go/No-Go (מי מחליט ולפי מה), תוכנית נסיגה המופעלת לפי אילו סימנים ואיך מבוצעת, וניטור בשעות ובימים הראשונים.

כללים: לכל שלב יש מדד הצלחה ברור, ללא "יהיה בסדר". תוכנית הנסיגה חייבת להיות מפורטת כמו תוכנית המעבר - היא זו שתבוצע תחת לחץ. סיים בהודעות למשתמשים לפני ואחרי המעבר.

הבטחת רציפות עסקית במהלך הגירה (Migration)

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

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

טפל בשאלות המכשילות מעברים: בזמן העבודה המקבילה, איזו מערכת היא ה"מקור המוסמך" (Source of Truth) לכל סוג נתון (כלל ברור לכל מקרה), איך מונעים הזנה כפולה או איך מארגנים אותה נכון אם היא הכרחית, מי מטפל בפעולות שהתחילו בישן ויסתיימו בחדש, ואיך מקפיאים או מסנכרנים נתונים ברגע המעבר הסופי.

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

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

צ'קליסט לסגירה מנהלתית, חוזית ותיעודית של פרויקט שהסתיים.

הכן את סגירת פרויקט [שם הפרויקט], שתוצרו אושר בתאריך [תאריך]. מרכיבי הפרויקט: [ספקים מעורבים, תקציב, תיעוד שהופק, צוות]. הסתייגויות שנותרו: [אם יש].

בנה צ'קליסט סגירה מלא: היבט חוזי (תשלום סופי לספקים, סגירת הסתייגויות, ביטול הרשאות גישה לחיצוניים), היבט פיננסי (עצירת דיווחי שעות, סיכום ניצול מול תקציב עם הסבר פערים, סגירת סעיפים תקציביים), היבט תיעודי (איפה לארכב מה, מה חייב להישאר נגיש בעוד שנתיים ועל ידי מי), היבט אנושי (שיבוץ מחדש של הצוות, מכתבי תודה בדרג המתאים), והיבט העברה (מי הופך לאחראי על התוצר בתפעול השוטף ואיזו תמיכה ניתנת).

כללים: הבחן בין מה שמעכב את הסגירה לבין מה שיכול להסתיים אחריה. פרויקט ש"גמור ב-98%" ונגרר חצי שנה עולה כסף - קבע תאריך סגירה סופי. ספק תבנית לסיכום פרויקט בעמוד אחד: מספרים, הצלחות, פערים ואיפה מאורכבים הלקחים.

ניהול חפיפה בין מנהלי פרויקטים

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

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

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

ארגן את תקופת החפיפה: פגישות היכרות אישיות (ספונסר, לקוח, צוות), סדר נושאים להעברה לפי דחיפות, והודעה על חילופי הגברי שמרגיעה מבלי להבטיח המשכיות מוגזמת. כללים: החפיפה חייבת להיבדק - הכן רשימת שאלות שהנכנס חייב לדעת לענות עליהן לבד בסיום. מה שלא הועבר יירשם במפורש עם איש קשר לחירום.

קליטת חבר צוות חדש לפרויקט

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

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

בנה מסלול לשבועיים הראשונים: ערכת קריאה ליום הראשון מוגבלת לעיקר (מסמך ייזום, דו"ח סטטוס אחרון, סקר סיכונים, מילון מונחים), 4 פגישות מתוזמנות עם האנשים הנכונים ומטרת כל פגישה, משימה ראשונה מועילה ומוגדרת היטב כבר בשבוע הראשון (בחר מה לפי [תפקיד מיועד]), וחונך (Buddy) מוגדר עם פגישת עדכון יומית של 10 דקות.

כללים: הימנע מ-15 פגישות פסיביות - העובד לומד דרך עשייה. ציין במפורש מה שאף אחד לא אומר לחדשים: רגישויות בין מעורבים, נושאים נפיצים, ומסלולי קבלת החלטות בפועל. הגש לו"ז לשבועיים, רשימת קריאה מדורגת, ושאלות שהעובד צריך לדעת לענות עליהן ביום ה-15 לאישור קליטתו.

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

תהליך גישור ב-3 שלבים לטיפול במתח שמתחיל להעיב על הפרויקט.

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

הצע תהליך ב-3 שלבים: פגישות אישיות תחילה (שאלות להבנת הגרסה של כל אחד מבלי לאשר או לבגוד באמון, מלכודות שיש להימנע מהן כמו תפקיד השופט), פגישה משותפת (מסגור הפתיחה, איך להחזיר לעובדות כשהדיון הופך לאישי, איך להגיע להסכמה על 2-3 כללי עבודה קונקרטיים), ומעקב (איך לוודא שההסכם מחזיק מבלי להיראות כעוקב).

כללים: הישאר בתפקיד מנהל הפרויקט - נושאים השייכים למשאבי אנוש (HR) או ניהול ישיר יזוהו ויועברו הלאה. אף אחד מהצדדים לא אמור לצאת מהתהליך כ"אשם" מול הצוות. ציין סימנים המחייבים הסלמה מיידית.

ניהול משבר מול ספק חיצוני

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

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

בנה מדרג פעולות: תחילה פגישת יישור קו (תיק עובדתי של הפערים בין ההתחייבות לביצוע, מתוארך ומגובה; מהלך הפגישה הדורש תוכנית שיפור מתוארכת במקום התנצלויות), לאחר מכן מעקב צמוד (אבני דרך קצרות, קריטריוני יציאה מהמשבר, סיכום כתוב אחרי כל פגישה), ולבסוף הכנת חלופה אם השיפור נכשל (להתחיל בדיסקרטיות אם התלות גבוהה).

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

כתיבת מסמך דרישות (RFP) לבחירת ספקים

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

נסח מסמך דרישות (RFP) להתייעצות עם ספקים בנושא [נושא, למשל: הקמת אתר, הטמעת כלי, שירות שוטף] עבור חברת [שם החברה]. הצורך: [תיאור הצורך והבעיה לפתרון]. הקשר טכני וארגוני: [מצב קיים, אילוצים]. תקציב משוער: [טווח, או לא לפרסום]. לוחות זמנים: [יעדים].

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

כללים: כל דרישה חייבת להיות ניתנת לבדיקה במסירה. הבחן בין דרישות חובה (Must) לרצונות (Nice to have). סיים ב-5 שאלות לשלב המצגות שיחשפו מי מהספקים באמת הבין את הצורך.

השוואת הצעות ספקים בטבלה אובייקטיבית

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

בנה טבלת השוואה להצעות שהתקבלו עבור [נושא ההתייעצות]. הצעות: [מספר הצעות וסיכום של כל אחת: מחיר, לו"ז, גישה, נקודות בולטות]. קריטריונים שחשובים לנו: [עדיפויות, למשל: עמידה בלו"ז, ליווי, עלות כוללת, יציבות הספק]. סימנים שעלו: [רושם לבדיקה, למשל: הצעה זולה משמעותית, תשובה גנרית].

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

יישם על ההצעות שתוארו והתרע על: פערים לא מוסברים במחיר (הצעה נמוכה מדי מסתירה לרוב טווח מצומצם), אנשי צוות שהוצגו במצגת אך לא יהיו בפרויקט, ועלויות נסתרות. הגש טבלה מלאה, שאלות הבהרה לכל ספק, והמלצה מנומקת ב-5 שורות.

בניית תוכנית ניהול שינוי (Change Management)

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

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

לכל קהל: מה משתנה בפועל ביומיום שלו (רווחים מול הפסדים - על הפסדים מושתקים משלמים מאוחר יותר), רמת הליווי הנדרשת (מידע, הדרכה, ליווי צמוד), והמסר המרכזי מנקודת מבטו.

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

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

תכנון מערך הדרכה למשתמשי קצה

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

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

בנה מערך לפי פרופיל ולא הדרכה אחידה: לכל אחד, 5-10 הפעולות הקריטיות מתרחישי האמת שלו (לא מעבר על כל הפיצ'רים), הפורמט המתאים (סשן קבוצתי קצר, סרטון, ליווי אישי בעמדה), משך, וחומרי עזר (דפי עזר של עמוד אחד למשימה במקום מדריך עב כרס).

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

כללים: מדידת ההצלחה תהיה על שימוש בפועל לאחר ההשקה (יכולת לבצע פעולות מפתח, נפח פניות לתמיכה) ולא על אחוז נוכחות. הגש טבלה לפי פרופילים ורשימת חומרים להפקה לפי סדר עדיפויות.

תקשורת בזמן משבר בפרויקט

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

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

נסח רצף תקשורת: הודעה ראשונה מהירה שאומרת מה ידוע, מה לא ידוע, מה נעשה ומתי יינתן העדכון הבא (התחייב לשעה של העדכון הבא, לא לשעת הפתרון שלא ידועה). עדכוני ביניים בקצב שהובטח גם אם אין חדש. הודעת סיום עם הצעדים שננקטו למניעת הישנות.

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

כתיבת OKRs לצוות

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

עזור לצוות [צוות] בחברת [שם החברה] לנסח OKRs לרבעון [רבעון]. עדיפויות החברה לתקופה: [עדיפויות]. משימות שוטפות של הצוות: [פעילות קבועה]. פרויקטים מתוכננים: [רעיונות ויוזמות]. גודל הצוות: [מספר].

הפק 2-3 יעדים (Objectives) לכל היותר: כל אחד מנוסח כשינוי מצב מעורר השראה אך קונקרטי (לא רשימת משימות), המקושר לעדיפות של החברה. לכל יעד, 2-4 תוצאות מפתח (Key Results): מדידות עם ערך התחלה וערך יעד, המודדות תוצאה שהושגה ולא פעילות שבוצעה (למשל: "צמצום זמן טיפול מ-X ל-Y" ולא "הטמעת כלי Z").

כללים: העבודה השוטפת (Run) אינה OKR אלא מנוהלת בנפרד. תוצאת מפתח שלא יודעים איך למדוד היום - תנוסח מחדש או תימחק. ציין יעדים שהצוות לא שולט בהם מספיק כדי להתחייב. הגש את ה-OKRs המוצעים, שאלות לדיון בצוות, ושגרת מעקב: פורמט של 15 דקות ומה עושים כשתוצאה מחליקה.

ניהול ישיבת סיכום רבעון (OKR Review)

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

הכן ישיבת סיכום רבעון ל-OKRs של צוות [צוות]. OKRs של הרבעון החולף: [יעדים ותוצאות עם רמת הביצוע]. אירועים משמעותיים: [הקשר: בלתי צפויים, שינוי עדיפויות, עזיבות]. משתתפים: [שמות]. משך: [זמן].

בנה את הישיבה ב-3 שלבים: דירוג כנה של כל תוצאת מפתח לפי מספרים אמיתיים (תוצאה שלא נמדדה נחשבת כלא הושגה, לא כ"בערך"), ניתוח פערים תוך הפרדה בין איכות הביצוע, שאיפה לא מציאותית או אירועים חיצוניים, והחלטות לרבעון הבא (מה ממשיכים, מה זונחים במפורש, מה מכיילים מחדש).

כללים: הישיבה אינה תרגיל בהצטדקות - ללא שקפי רקע מיותרים, ישר למספרים. יעד שהושג ב-100% כבר ברבעון הראשון מעלה שאלה לגבי רמת השאיפה, בדיוק כמו שיעד של 20% מעלה שאלה לגבי הביצוע. הגש: לו"ז מתומזמן, סולם דירוג, שאלות ניתוח לכל תוצאה, ונוסח הודעת סיכום להפצה.

ניהול תחקיר אירוע (Post-Mortem) ללא אשמה

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

הכן תחקיר (Post-Mortem) לאירוע [תיאור התקלה] שהתרחש בתאריך [תאריך] בפרויקט [שם הפרויקט]. כרונולוגיה ידועה: [פירוט אירועים עם שעות]. מעורבים: [אנשים]. אווירה: [הקשר, למשל: עובד מרגיש מותקף, ההנהלה מחפשת אשמים].

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

כללי הנחיה לפתיחה: מחפשים איך המערכת אפשרה את התקלה, לא מי טעה. מי שאומר "טעיתי" עוזר לכולם ולא ייענש על כך. כללים: מקסימום 5 פעולות לביצוע, לכל אחת אחראי ותאריך יעד. העדף פעולות שמונעות את האפשרות לטעות על פני דרישה ל"ערנות יתרה". הגש תבנית למסמך ולו"ז לישיבה.

הפיכת לקחים לסטנדרטים צוותיים

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

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

שלבי עבודה: קבץ לקחים לפי נושאים וזהה את החוזרים על עצמם (חזרתיות מעידה על צורך בסטנדרט), הפוך כל לקח נבחר לכלל אופטיבי המנוסח במשפט אחד עם טריגר ("בכל התחלת פרויקט, אנחנו עושים X"), והגדר איפה הכללים האלו חיים כדי שייראו בזמן הנכון: בתוך תבניות המסמכים והצ'קליסטים הקיימים ולא במסמך נפרד שאיש לא פותח.

כללים: מקסימום 10 כללים סה"כ, לכל כלל יש בעלים שמעדכן אותו. תכנן בקרה חצי-שנתית למחיקת כללים שהפכו למיותרים - מאגר שרק גדל סופו למות. הגש: כללים מוצעים לפי זמן שימוש, מקום הטמעתם, והודעה לצוות.

הכנה לביקורת או סקירת איכות פרויקט

הכנת תיק פרויקט, הצפת נקודות תורפה וניהול הראיונות מול המבקר.

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

ארגן את ההכנה: תיק הפרויקט שיש להכין (ייזום, החלטות, ניהול סיכונים, סיכומי פגישות, תקציב) עם רשימת מה שסביר שחסר או לא מעודכן ויש לתקן בעדיפות. שאלות שהמבקר צפוי לשאול, ועבור כל נקודת תורפה ידועה - העמדה הכנה שיש לנקוט: להכיר בה, להראות שהיא מזוהה ומנוהלת, ולהציג תוכנית פעולה מתוארת.

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

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

העתיקו פרומפט, הריצו אותו ב-GPTPro והשוו בזמן אמת בין התשובות של Claude, GPT, Gemini ו-Mistral.

להעמיק בנושא

סוכן AIניהול מוצרסוכן AI לניהול מוצר לכתיבת PRD, אפיון User Stories והאצת תהליכי דיסקברי. מותאם למנהלי מוצר בחברות טכנולוגיה ו-PME בישראל.לגלות עוד
סוכן AI ייעודיניהול פרויקטיםסיכומי פגישות שנכתבים לבד, תוכנית פרויקט, מפת סיכונים ודוחות סטטוס: כך סוכן AI מוריד ממנהל הפרויקט את עומס הדיווח היומיומי.לגלות עוד
פרומפטצ'ק ליסט SEO לפני עלייה לאווירבדיקות חובה לפני ואחרי פרסום כדי למנוע תקלות אינדוקס וצניחה במיקומים.לגלות עוד
סוכן לפי מודלChatGPTאיך בונים סוכן AI עם ChatGPT בלי לכתוב קוד: מצב Agent, GPT מותאם, מגבלות אמיתיות ושיטת 3 שלבים. משווים GPT מול Claude ו-Gemini ב-GPTPro.לגלות עוד
מאמרסוכן AI: הגדרה ברורה ודוגמאות מהשטחהמונח 'סוכן AI' משמש היום לכל דבר. הגדרה כנה, ההבדל האמיתי מצ'אטבוט, דוגמאות מהשטח, והמסגרת הרגולטורית הרלוונטית, כדי להבין מה הכלים האלה עושים, ומה לא, נכון ל-2026.לגלות עוד
קטגוריית פרומפטיםניתוח נתוניםלתת למספרים לדבר: חקירה, לוחות בקרה, פרשנות זהירה והצגת מסקנות.לגלות עוד