גוף הידע בניהול פרויקטים (PMBOK Guide), מכיל עשרה תחומי ידע.
כל תחום ידע מכיל פרקטיקות, אותן יש לבצע לאורך מחזור החיים של הפרויקט.
מסיבות מתודיות, ה-PMBOK כתוב ב"קוביות", דהיינו – כל תחום ידע מתחלק לנושאים; כל נושא לאוסף של פרקטיקות אותן יש לבצע לאורך כל חיי מחזור הפרויקט.
כדי להיות ארגון שהוא 10 בניהול פרויקטים, על הנהלת החברה לספק למנהלי הפרויקטים תשתית תומכת לביצוע הפרקטיקות. דהיינו תהליכים תומכים ומשולבים. תשתית טובה מכילה את כל "קוביות" ה-PMBOK בתוך מספר קטן של תבניות (Templates). את התבניות מפתחים מומחים במתודולוגיית ניהול פרויקטים לטובת מנהלי הפרויקטים.
כדי להיות 10 בניהול פרויקטים, עלינו:
בהצלחה לכולנו !
אחת מדרישות החובה בתקן 9001:2008 ISO הייתה פעולה מונעת. ארגון מטמיע תהליך שיטתי לפעולה מונעת כדי לקבוע פעולות לסילוק גורמים לאי-התאמות פוטנציאליות, כדי למנוע את הופעתן. דוגמאות לאי התאמות: ביצועים נמוכים, תלונות של לקוחות, אי עמידה ביעדים, אי שביעות רצון עובדים או ספקים ועוד.
בגרסת התקן 9001:2015 ISO.הוחלפה הדרישה לפעולה מונעת לתהליך של ניהול סיכונים.
כדי ענות על השאלה, נשווה את שני התהליכים, לפי שלביהם:
פעולה מונעת: קביעת אי-התאמות פוטנציאליות והגורמים להן
ניהול סיכונים: זיהוי הסיכון, ניתוח הסיכון
פעולה מונעת: הערכת הצורך בפעולה למניעת הופעתן של אי-התאמות
ניהול סיכונים: הערכת הסיכון (אומדן הנזק)
פעולה מונעת: קביעת הפעולה הדרושה ויישומה,
ניהול סיכונים: החלטה על אסטרטגית הפעולה לשיכוך נזקי הסיכון
פעולה מונעת: רישום תוצאות הפעולה שננקטה; סקירת האפקטיביות של הפעולה המונעת שננקטה
ניהול סיכונים: פיקוח ובקרה על הסיכון ובדיקת אפקטיביות הפעולות שננקטו
לאור האמור שלעיל נראה שלמעשה שניהול סיכונים הוא בעצם פעולה מונעת. בכל זאת, מדוע טורחים חכמי מועצת התקן ועושים שינוי שכזה?
מניסיוני בייעוץ לארגונים המעוניינים בתקן 9001 ISO למדתי כי במקרים רבים, אין הבנה ובטח שלא הטמעה של תהליך שיטתי לפעולות מונעות. מנהלי איכות בארגונים מתאמצים כדי להראות יישום של תהליך שכזה. ייתכן שהדבר נובע מכך שהתהליך לא ממש ברור וחסר את ההנחיה מה נדרש בעצם לעשות. לעומת זאת, תהליך ניהול סיכונים הוא תהליך מאד סדור ואף אפקטיבי.
תהליך ניהול סיכונים מוסיף שתי פעולות חשובות מעבר לפעולה המונעת:
כלומר, תהליך ניהול סיכונים מוסיף נדבך של ניתוח סיכונים כדי לטפל רק בסיכונים עם פוטנציאל נזק גבוה, ולאחר שזוהו הסיכונים מכניס בחירת אסטרטגיית פעולה לטיפול בסיכון. כלומר – חשיבה בשלב הניתוח ולאחריו. חשיבה זו היא חשובה כי אין לנו משאבים לטפל בכל הסיכונים ולכן נבחר את אלה בעלי פוטנציאל הנזק הגבוה ביותר.
אין הבדל מהותי. תהליך ניהול סיכונים הוא תהליך שמונע אי התאמות. כל פעילות יזומה לשיפור איכות של מוצר או תהליך, מניחה שיש סיכון ומחיר לאי-עשייה של אותה פעולת מניעה או שיפור. תהליך ניהול סיכונים מוסיף נדבכים של שיטתיות ובהירות לתהליך.
הפעולה המתקנת היא חלק מתהליך ניהול סיכונים. תהליך ניהול סיכונים שיטתי מחייב לתעד את תהליך הבחירה לפעולה המתקנת ואת ההחלטה על אסטרטגיית הפעולה. תיעוד זה נסקר בישיבות צוות וסקרי הנהלה. תהליך התיעוד והסקירה מאפשר שיתוף וקבלת החלטה מושכלת. תהליך של פעולה מונעת מבוצע בדרך כלל בראשו של מנהל מסוים ומה שצף מעל פני השטח הוא בעיקר תוצאת הפעולה המתקנת.
לטעמי, חשוב ביותר. ניהול סיכונים הוא תהליך ממוקד ושיטתי שניתן להפעילו בכל רמות הארגון. האתגר הוא לנהל סיכונים בצורה נכונה. לדעת להבדיל בין אירוע עתידי שמהווה סיכון לבין כל מצב מסוכן או בעייה ניהולית שלא טופלה בזמן ונקראית בטעות סיכון. גרסת התקן החדש אינה מכתיבה תהליך ניהול סיכונים שיטתי, אלא דורשת שתהיה חשיבה בכיוון (Risk-Based-Thinking). ככל שעובר הזמן מרגע שהתקן הושק לעולם, ארגונים בכל זאת עוברים לאט לאט מחשיבה מבוססת סיכונים לניהול סיכונים.
לאחרונה היינו עדים לאירוע מפחיד בכל קנה מידה: שריפה פרצה במפעל פלסטיק בקיסריה. בכתבה של Ynet מיום 22.6.14 נכתב שעל כיבוי השריפה עמלו 123 לוחמי אש, 69 כבאיות ו-6 מסוקי כיבוי שגויסו מכל הארץ. האש, שהגיעה לגובה 20-25 מטר, התפשטה למפעל שכן וכילתה גם אותו. היה חשש להתפשטות האש למפעלים סמוכים נוספים. עשרות עובדים שהו במפעל ולמרבית המזל רובם חולצו ללא פגע, למעט שני עובדים שנפגעו במצב קל ובינוני. תושבי הסביבה נאלצו להסתגר שעות רבות בבתיהם ללא מזגן ולסגור את כל הפתחים כדי שלא ישאפו עשן רעיל. בהתאם למסקנות ראשוניות מהאירוע, מדובר בהתלקחות באזור אחסון ששופץ לאחרונה וכנראה טרם התקבל אישור שירותי הכבאות להפעלת המקום. המפעל נשרף כליל ואיתו הכסף שהושקע בשיפוץ. מחדל בטיחותי זה הסב לבעלי המפעלים נזקים עסקיים כבדים בעקבות הרס המפעלים ואי יכולתם לעמוד בהתחייבויות לאספקת סחורה. עובדי המפעל נשארו ללא פרנסה לתקופה ממשוכת.
בשנים אחרונות קרו כבר כמה וכמה אירועים שקשורים למחדלים בתחום הבטיחות: לפני שנה וחצי מנהל סניף בנק הפועלים נספה בשריפה שפרצה במועדון SPA שפעל ללא רישיון עסק (שניתן לקבל רק אם המקום עומד בכל הדרישות הקפדניות של שירותי כבאות והצלה). מסתבר שבארץ יש כ- 40% בתי עסק שפועלים ללא רישיון עסק. אפשר גם להיזכר בקריסת במה בהר הרצל, קריסת גשר במשחקי המכבייה ועוד שורה ארוכה של אירועים שנגרמים כתוצאה מאי-טיפול בגורמי סיכון לאירועים בטיחותיים.
גישת ה"סמוך" / "אין מה לדאוג" / "יהיה בסדר" / "נסתדר" / "נזרום ונאלתר" גורמת לחלקנו לא לייחס חשיבות לזיהוי מוקדם של סיכונים ולנקיטת פעולות כדי למנוע אותם או לפחות להפחית את הנזק הפוטנציאלי במידה והתממשו. המחדלים שפורטו לעיל נגרמו כתוצאה מהתממשות סיכונים בטיחותיים / תפעוליים.
בוודאי!
אחד האמצעים למנוע אירועים שכאלה, או לפחות להיערך לשיכוך הנזק והכאבים שאירועים כאלה יכולים לגרום הוא תהליך של ניהול סיכונים. החשיבות של מיסוד תהליך שכזה זוהה על ידי גופי תקינה רבים. זאת, כדי למזער ככל שניתן את נטייתנו הטבעית להאמין ש"לי זה לא יקרה". להלן רשימה של דרישות חוק ותקינה המחייבות ארגונים לבצע הערכת סיכונים:
מטמיעים תהליך של ניהול סיכונים, אותו מבצעים תקופתית. ניהול סיכונים אפשר לעשות עם מומחה מהארגון, או יועץ חיצוני שמגיע לזמן קצר ומשאיר לארגון דו"ח עם מפגעים פוטנציאלים בהם יש לטפל.
OK, מהו סיכון ולמה לנו להתעסק עם זה בכלל?
סיכון הינו הסתברות להפסד כתוצאה מ-:
במסגרת ניהול סיכונים בארגון נדרש להתייחס לכל הסיכונים האפשריים בכלל תהליכי העבודה בארגון, תוך זיהוי והערכת סיכונים, מדידת החשיפה לסיכון והסתברות להתממשותו. לאחר זיהוי והערכת הסיכון, מזהים פעילויות בקרה קיימות או מומלצות ומתכננים תכנית ניטור וטיפול בחשיפות.
הסיכון הכספי / העסקי הוא נגזרת מהתממשות הסיכון התפעולי / הבטיחותי. כאשר הסיכון מתממש – תמיד הארגון ישקיע משאבים רבים כדי להשיב את המצב לקדמותו. לפעמים, השבת המצב לקדמותו לא אפשרית כיוון שהמוניטין נפגע והלקוחות עוברים למתחרים.
המיתוס העיקרי שמרבית המנהלים מאמינים בו הוא שביטוח שיש לארגון יכסה את ההפסדים / ייתן כיסוי כספי לתביעות. הטענה נכונה חלקית, כי הביטוח תמיד מכסה עד גובה מסוים ונותן מענה במסגרת תביעות לפיצוי כספי. אבל במקרה ונפתח תיק פלילי בגין רשלנות הביטוח לא עוזר.
השקעה במניעה היא לעולם תהיה נמוכה יותר. איפה הקאטץ? ההשקעה במניעה היא בלתי נראית ולא תמיד מתוגמלת כיוון שאסונות שנמנעים לא נראים ולא נשמעים. כאן המקום לאחריות אישית ומנהיגות של הנהלת הארגון הבכירה. לא לוותר! לא לסמוך על המזל!
תהליך ניהול סיכונים הוא תהליך של מספר צעדים:
צעד ראשון – הערכת עוצמת הסיכונים
ראשית, מעריכים את עוצמת הסיכונים. הטבלה שלהלן מציגה שיטה אחת (מיני רבות) לאמוד את הערך האפשרי של נזק במקרה של התממשות הסיכון לעומת ערך הסיכוי/הסתברות שהאירוע יקרה.
הצעדים הבאים – נקבעים בהתאם לרמת הסיכון והפעילות שמתאימה לארגון.
הסיכונים שהערכת הסיכון שלהם נצבעה באדום – דורשים טיפול מיידי ע"מ למנוע את התממשות הסיכון. יתר הסיכונים דורשים טיפול בהתאם לסדרי עדיפויות שייקבעו ע"י הנהלת הארגון.
תהליך השלם לטיפול בסיכונים – ראו במאמר אחר – כאן.
האם קיים בארגון שלכם תהליך ניהול סיכונים כולל? איך אתם מתמודדים עם הנושא? נשמח לשמוע את תגובתכם באחת הרשתות החברתיות שקישורן להלן.
דרישה: תכונה של המוצר/השירות, המהווה תנאי לקבלה ע"י המזמין |
למוצר או שירות תהיינה הרבה מאד תכונות, אך לא כולן תהיינה תנאי לקבלה ע"י המזמין, ולכן לא כולן תהיינה דרישות. יש להיזהר, במיוחד בעבודה עפ"י חוזה, לא רק לתת מענה לכל הדרישות, אלא גם שלא להתחייב לתכונות שאינן דרישות.
לכן דרישה צריכה להיות אמירה מדויקת, תמציתית, שניסוחה חד וברור. ערפול בניסוח הוא מתכון לצרות: האם הדרישה הובנה ע"י הספק בדיוק כפי שהתכוון המזמין ? אם לא – הוויכוחים יהיו אינסופיים.
איך יוצרים דרישה מדויקת ? כללי העבודה בקטגורית "דיוק (Precision)" יעזרו לנו ליצור דרישות כאלה.
יידוע שמות עצם: השתמש אך ורק בשמות עצם מיוּדעים (מלווים בה"א הידיעה). שימוש במונחים ללא יידוע מוביל לריבוי משמעויות.
דוגמה:
המערכת תספק תצוגת זמן |
מושא הדרישה (תצוגת זמן) צריך להיות מיודע כדי שיהיה חד-משמעי:
המערכת תציג את השעה-הנוכחית |
לשון פעיל: השתמש בלשון פעיל ובישות מבצעת מוגדרת לפעולה. שימוש בלשון סביל מקשה על אימות הדרישה.
דוגמה:
זהות הלקוח תיבדק |
נטל האימות מונח על כתפי הגורם המבצע. אם המבצע אינו מזוהה במפורש, לא ברור מי צריך לבצע את הפעולה. לכן יש לכתוב:
מערכת-ניהול-החשבונות תוודא את זהות-הלקוח |
הרכב ינגן קבצי שמע מהתקני USB. |
מערכת השמע תנגן קבצי שמע מהתקני USB. |
הכספומט יציג את מצב החשבון. |
הסיכוי לטעות בפרשנות של המונח "מצב החשבון" הוא גבוה. השימוש במילון מאפשר לקורא לדעת בדיוק למה התכוון הכותב כשבחר מלה מסוימת:
הכספומט יציג את מצב-החשבון. |
מצב-החשבון | אוסף נתונים אודות חשבון הבנק של הלקוח, המורכב מהפריטים הבאים:
|
המאזניים הביתיים יציגו את המשקל עד לדיוק של בערך 10 גרם. |
המאזניים הביתיים יציגו את המשקל ± 10 גרם. |
למעגל-המודפס תהיה טמפרטורת אחסנה של לא יותר מ-30 מעלות |
לכל מספר יש לציין במפורש את היחידות בהן הוא נמדד:
למעגל-המודפס תהיה טמפרטורת אחסנה של לא יותר מ-30 מעלות צלזיוס |
מערכת-נתוני-הטיסה תהיה בדרך כלל מקוונת |
תארי פועל מעורפלים עלולים להוביל לדרישות רב משמעיות, שלא ניתן לאמת:
"בדרך כלל", "בערך", "מספיק", "באופן טיפוסי"
למערכת-נתוני-הטיסה תהיה זמינות של לפחות xx% במשך של לפחות yy שעות ברציפות |
מערכת-נתוני-הטיסה תציג את נתוני-המעקב עבור כלי טיס רלבנטיים |
מערכת-נתוני-הטיסה תציג את נתוני-המעקב עבור כל כלי-טיס הנמצא במרחק של 20 ק"מ או פחות מהמנחת |
ה-GPS יציג את מיקום-המשתמש, ככל שירשה המקום |
ה-GPS יציג את מיקום-המשתמש. |
Sוגמה:
הכספומט יציג את מספר חשבון הלקוח, היתרה וכן הלאה |
|
# | שם הכלל | הסבר |
1 | יידוע שמות עצם | השתמש בשמות עצם מיוּדעים (מלווים בה"א הידיעה) |
2 | לשון פעיל | השתמש בלשון פעיל ובישות מבצעת מוגדרת לפעולה |
3 | נושא הדרישה | הקפד שנושא הדרישה יהיה תואם לרמה המוצר או השירות אליה הדרישה מתייחסת |
4 | מונחים מוגדרים | השתמש אך ורק במונחים המוגדרים במילון (Glossary) |
5 | כַּמָּתים | המנע מכַּמָּתים (Quantifiers) לא מדויקים |
6 | יחידות | השתמש ביחידות מוגדרות ומפורשות לציון כמויות |
7 | תואר הפועל | המנע משימוש בתארי פועל מעורפלים |
8 | תואר השם | המנע משימוש בתארי שם |
9 | פסוקיות לוואי | המנע משימוש בפסוקיות לוואי מעורפלות |
10 | פסוקיות פתוחות | המנע משימוש בפסוקיות פתוחות |
אם כל דרישה באוסף הדרישות מקיימת את כל התכונות המאפיינות דרישה "טובה" – האם זה אומר שאוסף הדרישות כולו הוא "טוב" ? נשמח לתשובה בתיבה למטה
מומחה לתהליכים הנדסיים. בוגר תואר שני מאוניברסיטת Carnegie Mellon ובעל 30 שנות ניסיון בארגוני פיתוח שונים, בארץ ובעולם. מזה 12 שנים עוסק בשדרוג תהליכי הנדסת המערכות בתעשייה האווירית, בהדרכה ובהטמעה.
תכונה | הדרישה צריכה להיות |
חיונית | הכרחית |
בלתי-תלויה ביישום | מבטאת את הצורך, לא את אופן מתן המענה |
חד-משמעית | בעלת פרשנות אחת בלבד |
שלמה | עומדת בזכות עצמה |
ייחודית | מבטאת רעיון יחיד וברור |
ישימה | ברת יישום |
כמו כן אנו מכירים שני כללים חשובים העוזרים בניסוח דרישות "טובות":
דרישות נכתבות בצרוף מילון מונחים מפורט. במילון מרוכזות במקום אחד, לפי סדר אלפאבתי, ההגדרות של כל המונחים שבשימוש על פני כל הדרישות. |
הקפד שהדרישה תהיה מורכבת ממשפט אחד, הבנוי על פי כללי התחביר: תנאי + נושא + נשוא + מושא [ + סייג] |
בסיום פרק זה נכיר את שלושת המאפיינים האחרונים של דרישה "טובה".
המוצר יתופעל באופן ידידותי למשתמש. |
במקום זאת נציע למזמין ניסוח כדלקמן:
המוצר יאפשר למשתמש שקיבל הדרכה בת חצי יום לבצע בהצלחה כל אחת מיכולות המוצר תוך 30 שניות. |
על ניסוח כזה אפשר להגיע להסכמה ואז גם קל לאמת את הדרישה.
תחנת השאיבה תשמור על זרם מים בעוצמה של 120 ליטר לשנייה למשך 30 דקות. |
תחנת השאיבה תשמור על זרם מים בעוצמה של ±10120 ליטר לשנייה למשך לפחות 30 דקות. |
הלהקה תנגן שירים בלקניים ומזרחיים. |
התזמורת תופיע במהלך כל הערב. |
אנסמבל "עורבא פרח" ינגן שירים בלקניים ומזרחיים. |
התזמורת תופיע במהלך כל הערב. |
התכונה | הדרישה צריכה להיות |
---|---|
חיונית | הכרחית |
בלתי-תלויה ביישום | מבטאת את הצורך, לא את אופן מתן המענה |
חד-משמעית | בעלת פרשנות אחת בלבד |
שלמה | עומדת בזכות עצמה |
ייחודית | מבטאת רעיון יחיד וברור |
ישימה | ברת יישום |
ברת-אימות | ניתן לאמת אותה |
נכונה | ביטוי נכון ומדויק של צרכי בעלי העניין |
תואמת למוסכמות | מתיישבת עם סטנדרטים ומוסכמות ארגוניים |
מומחה לתהליכים הנדסיים. בוגר תואר שני מאוניברסיטת Carnegie Mellon ובעל 30 שנות ניסיון בארגוני פיתוח שונים, בארץ ובעולם. מזה 12 שנים עוסק בשדרוג תהליכי הנדסת המערכות בתעשייה האווירית, בהדרכה ובהטמעה.
תכונה | הדרישה צריכה להיות |
חיונית | הכרחית |
בלתי-תלויה ביישום | מבטאת את הצורך, לא את אופן מתן המענה |
חד-משמעית | בעלת פרשנות אחת בלבד |
דרישות נכתבות בצרוף מילון מונחים מפורט. במילון מרוכזות במקום אחד, לפי סדר אלפאבתי, ההגדרות של כל המונחים שבשימוש על פני כל הדרישות. |
בפרק זה נפגוש עוד מספר מאפיינים של דרישה "טובה" ועוד כמה כללי עבודה. שימו לב שחלק מהכללים נוגעים לשפה ולתחביר. עוד על כך – בהמשך.
פעולה | הסבר |
גזירה | החלפה של דרישה בסט דרישות מפורטות וספציפיות יותר, השקולות ביחד לדרישה המקורית. |
הקצאה | שיוך דרישה של מוצר או שירות לאחד או יותר ממרכיביו. |
אימות | פעולה המוכיחה שהדרישה מתקיימת במוצר או בשרות. |
תיקוף | פעולה המתבצעת בתנאים היעודיים של המוצר או השרות, ומוכיחה שהמוצר או השרות עונה לצרכים. |
עקיבות | קישור של דרישה לפריטי מידע אחרים, כגון: דרישת המקור, פעולת אימות, מטלת מימוש. |
דרישה "טובה" מוגדרת ע"י התכונות הבאות:
פעמון האזעקה יצלצל למשך לא יותר מ-20 דקות |
הדרישה הזאת מסתמכת על הכותרת שמעליה כדי להבין על מה מדובר. זה לא קביל. במקום זאת צריך להיות:
פעמון האזעקה פעמון האזעקה יצלצל למשך לא יותר מ-20 דקות |
מערכת הבקרה תסגור את שסתום כניסת המים עד שהטמפרטורה תרד ל-850 צלזיוס ואז תפתח אותו. |
1. מערכת_הבקרה תסגור את שסתום_כניסת_המים, בתוך פחות מ-3 שניות, כאשר טמפרטורת המים בדוד גבוהה מ-850 צלזיוס. 2. מערכת_הבקרה תפתח את שסתום_כניסת_המים, בתוך פחות מ-3 שניות, כאשר טמפרטורת המים בדוד נמוכה מ-850 צלזיוס. |
למוצר תהיה אמינות של 100%. |
אמינות של 100% כמעט שאיננה ברת-השגה. אם נחשוב קדימה לאימות הדרישות – איך נוכיח אמינות של 100% ? וגם לו יכולנו לבנות מערכת כזאת – האם נוכל להרשות זאת לעצמנו מבחינת העלות ?
השוו לעומת זאת את הדרישה שלהלן:
למוצר תהיה אמינות גדולה או שווה ל-98%. |
הקפד שהדרישה תהיה מורכבת ממשפט אחד, הבנוי על פי כללי התחביר: תנאי + נושא + נשוא + מושא [ + סייג] תנאי – תבנית המציינת באילו תנאים הדרישה צריכה להתקיים, למשל: "כאשר טמפרטורת המים בדוד נמוכה מ-C850" נושא – תבנית המתארת את מבצע הפעולה שבדרישה, למשל: "מערכת הבקרה" נשוא – תבנית המתארת את הפעולה המתבצעת, למשל: "תפתח" מושא – תבנית המתארת את היישות שעליה הפעולה מתבצעת, למשל: "את שסתום כניסת המים" סייג – תבנית אופציונלית המתארת מיגבלה כלשהי על ביצוע הפעולה, למשל: " בתוך פחות מ-3 שניות" |
כאשר טמפרטורת המים בדוד נמוכה מ-C850, מערכת_הבקרה תפתח את שסתום_כניסת_המים בתוך פחות מ-3 שניות. |
בצורה כזאת מתקבלת דרישה שיש בה משפט אחד פשוט, המביע מחשבה אחת.
אוסף התכונות של דרישה "טובה" שבנינו עד עתה הוא:
תכונה | הדרישה צריכה להיות |
חיונית | הכרחית |
בלתי-תלויה ביישום | מבטאת את הצורך, לא את אופן מתן המענה |
חד-משמעית | בעלת פרשנות אחת בלבד |
שלמה | עומדת בזכות עצמה |
ייחודית | מבטאת רעיון יחיד וברור |
ישימה | ברת יישום |
צברנו גם שני כללים לכתיבת דרישה "טובה", והם:
דרישות נכתבות בצרוף מילון מונחים מפורט. במילון מרוכזות במקום אחד, לפי סדר אלפאבתי, ההגדרות של כל המונחים שבשימוש על פני כל הדרישות. |
הקפד שהדרישה תהיה מורכבת ממשפט אחד, הבנוי על פי כללי התחביר: תנאי + נושא + נשוא + מושא [ + סייג] |
מומחה לתהליכים הנדסיים. בוגר תואר שני מאוניברסיטת Carnegie Mellon ובעל 30 שנות ניסיון בארגוני פיתוח שונים, בארץ ובעולם. מזה 12 שנים עוסק בשדרוג תהליכי הנדסת המערכות בתעשייה האווירית, בהדרכה ובהטמעה.
דרישות הן אמצעי תקשורת בין הצד המזמין לבין הצד המספק, באשר לתכולת המוצר או השרות המסופק. דרישות טקסטואליות אינן פורמאליות, ולכן מעצם מהותן הן חשופות לבעיות רבות של הבנה ופרשנות. עם זאת, דרישות טקסטואליות נמצאות בשימוש נרחב מאד במקומותינו.
האיור שלהלן ממחיש השתלשלות עניינים טיפוסית כתוצאה מחוסר הגדרת דרישות מדוייקת למוצר תוכנה. דברים דומים קורים גם במוצרים או שירותים מסוגים אחרים.
בפינה זאת ניגע בכל פעם בחלק מהכללים העוזרים למזער את הבעייתיות הגלומה בדרישות הכתובות בטקסט. בהדרגה, נצבור אוסף כללי עבודה שהשימוש העקבי בו ישיג את המטרות הבאות:
משתמשי כללי "המדרשה לדרישות טובות" חווים:
דרישה "טובה" מוגדרת ע"י התכונות הבאות:
כל דרישה צריכה להיות חיונית.
הרציונאל: דרישה שכוונתה מובעת בדרישות אחרות יוצרת סכנה של סתירה. אין סיבה להביע משהו יותר מפעם אחת. כמו כן, דרישה שמצטטת עובדה מטעה את הקורא לחשוב שהוא אמור לספק משהו. בנוסף:
דוגמא:
המוצר המסופק יצרוך חשמל בכל מהלך פעולתו |
מה הסיבה לדרישה הזאת ? למי היא נחוצה ? האם קיים בעל עניין למוצר שמאד מעוניין שהוא יצרוך חשמל ? ואם המוצר לא יצרוך חשמל בכל משך פעולתו אלא רק בחלק – האם מישהו יהיה בלתי מרוצה? ואם נסיר את הדרישה הזאת – האם זה ישנה משהו בפתרון ? זאת דוגמא לדרישה מיותרת.
אם נפעיל את כישורי הניחוש שלנו, יתכן שנגיע למסקנה שהדרישה בעצם התכוונה להיות:
המוצר יפעל על אנרגיה חשמלית |
זוהי דרישה המגבילה את המוצר להשתמש באנרגיה חשמלית (ולא, למשל, באנרגיה סולארית).
דרישה צריכה לבטא את הצורך ולא את אופן מתן המענה. כל פתרון שייבחר צריך לתת מענה לדרישה.
הרציונאל: כאשר בדרישה מובע אופן היישום – הקורא צריך לנחש ממנו את הצורך האמיתי. ואם לא ברור הצורך בנקודה מסוימת, החלחול שלו הלאה למרכיבי הפתרון יהיה לקוי.
דוגמא:
להכוונת התנועה בצומת יש להשתמש במערכת רמזורים |
במקום לבטא צורך – הדרישה קובעת את הפתרון: רמזורים. אבל מה הצורך כאן ?
צורך הוא משהו מעולם הבעיה. להלן דוגמא של צורך:
מערכת בקרת התנועה תאפשר לכלי רכב הנוסעים ממזרח למערב לחצות את הצומת עם 2 דקות המתנה לכל היותר. |
זהו צורך אמיתי: שכלי הרכב החוצים את הצומת לא יאולצו להמתין יותר משתי דקות. זה לא מכתיב שום פתרון.
לדרישה צריכה להיות פרשנות אחת בלבד, המשותפת לכל הגורמים הרלבנטיים.
הרציונאל: כאשר הדרישה ניתנת לפרשנות במספר דרכים, היא מפסיקה להיות כלי תקשורת. הסכנה היא שהקורא יבין ויספק כהבנתו בעוד שהכותב התכוון למשהו אחר.
דוגמא:
דוגמא:
בפאנל הקדמי תהיה תצוגת זמן |
הדרישה היא רב משמעית: האם כל זמן שהוא יהיה קביל ? האם הבהוב רגעי של השעה יהיה מספק ?
רוב הסיכוי שכוונת הכותב הייתה שרוצים תצוגה רציפה של השעה הנוכחית. אם נספק תצוגה רציפה של השעה "10:00AM", נוכל לטעון שעמדנו בדרישה. אבל בפרוש לא נתנו מענה לצורך.
לעומת זאת:
להיות:
בפאנל הקדמי יוצג באופן רציף הזמן_הנוכחי |
שימו לב שהזמן_הנוכחי הוא מונח שצריך להיות מוגדר במילון המונחים, מכיוון שייתכנו מספר פירושים למונח הכללי "זמן":
מונח | הסבר המונח |
הזמן_הנוכחי | השעה הנוכחית לפי שעון ירושלים, בפורמט "HH:MM 24 שעות" |
זה הזמן לציין כלל חשוב לכתיבת דרישות:
דרישות "טובות" נכתבות בצרוף מילון מונחים מפורט (Glossary). במילון מרוכזות במקום אחד, לפי סדר אלפבתי, ההגדרות של כל המונחים שבשימוש על פני כל הדרישות. |
אי הקפדה על כלל זה תביא לכך שכל מיני קטעי הגדרות, הסברים, ואפילו הגיגי לב שונים של הכותב, יהיו "מרוחים" ללא אבחנה על פני הדרישות ויקשו עד מאד את הבנתן.
עשינו הכרה עם 3 מאפיינים של דרישה "טובה" והם: שהדרישה תהיה חיונית, בלתי תלויה ביישום, וחד משמעית.
כמו כן למדנו כלל חשוב העוזר ביצירת דרישות "טובות": שימוש במונחים סטנדרטיים, המוגדרים במילון מונחים מצורף, והקפדה על כך שהסברים יופיעו בהגדרת המונח ולא בתוך הדרישה.
בפינה הבאה של "המדרשה לדרישות טובות" נכיר מספר מאפיינים נוספים לדרישה טובה ונלמד כמה כללי עבודה חדשים.
מומחה לתהליכים הנדסיים. בוגר תואר שני מאוניברסיטת Carnegie Mellon ובעל 30 שנות ניסיון בארגוני פיתוח שונים, בארץ ובעולם. מזה 12 שנים עוסק בשדרוג תהליכי הנדסת המערכות בתעשייה האווירית, בהדרכה ובהטמעה.
במקרים רבים, נושא החזון מטופל בציניות על ידי המנהלים, ומנוסח מהשפה אל החוץ כדי לצאת ידי חובה. נושא החזון הינו מאתגר במיוחד עבור מנהלים משימתיים, חדורי מוטיבציה להצליח בתחומם בטווח הקצר של הקדנציה שלהם. מנהלים אלה ממוקדים בהשגת האופטימום הלוקלי שבתחום אחריותם ואינם רואים את התמונה הרחבה. במקרים רבים, בהיעדר מטרה כללית רחבה, עסוקים המנהלים בניהול משימות שוטף תוך שימוש בטקטיקות ממיטב ניסיונם.
מטרת החזון היא לסנכרן ולהחדיר מוטיבציה אצל מנהלים ועובדים סביב מטרה משותפת של הארגון. חזון סוחף מצייר את תמונת המציאות אליו רוצה הארגון להגיע בצורה מעוררת השראה, מנוסח בקצרה, אפשר לתקשר אותו בדקה מקסימום והשומע מגלה עניין בהצלחתו.
דוגמאות לחזון מעורר השראה של חברות מצליחות שכולנו מכירים:
1. גוגל – לארגן את כל המידע בעולם כך שיהיה נגיש ושימושי לכל
“To organize the world‘s information and make it universally accessible and useful.” — Google
2. אמזון – להיות החברה הכי ממוקדת בתבל בלקוחותיה; ליצור מקום שבו אנשים יכולים לבוא כדי למצוא ולגלות את כל שיחפצו לקנות באינטרנט.
"To be earth’s most customer centric company; to build a place where people can come to find and discover anything they might want to buy online. "— Amazon
"Facebook's mission is to give people the power to share and make the world more open and connected." —Facebook
חברות מצליחות אלה סגננו את החזון שלהם במונחי שירות יוצא דופן ללקוחות שלהם. החזון שלהם הינו לטווח הארוך ואינו תלוי בדבר שהינו בר חלוף כגון: צורך ספציפי, טכנולוגיה או כל דבר עכשווי.
דוגמאות לחזון תלוי טכנולוגיה נוכחית, חסר השראה שאינו מעודד לצאת מהקופסה:
הדרך לחלחל את החזון לעשייה היומיומית של הארגון היא על ידי הרחבה, העמקה ופירוט. את החזון מעורר ההשראה מתמירים למספר מטרות אותן רוצים להשיג בטווח הקרוב. המבנה הארגוני מותאם להשגת החזון הכולל. הארגון מחולק לתחומים/אגפים; כל אחד מהם ממוקד בהשגת מטרת על מרכזית אחת. כל אגף מנסח את האסטרטגיה שלו כדי להשיג את אותה מטרת על שהוקצתה לו, ובהלימה לחזון ולאסטרטגיה הכוללת. בסופו של תהליך, נעשה תכנון להוציא לפועל את האסטרטגיה האגפית במגוון טקטיקות שמתורגמות לפעילויות. חלק מהפעילות יכולות להיות פרויקטים או תוכניות בגדלים ובטווחי זמן שונים. חשוב ביותר שתהליך הפירוק יעביר את החזון והאסטרטגיה מלמעלה למטה, כך שכל מנהל ועובד יבין את התרומה של פעילותו להצלחה הכוללת.
כדי שהתהליך המתואר לא יהיה יבש וטכני, ובתהליך הפירוט והפירוק לא תאבד הדרך – נדרש להשקיע מחשבה בניסוח תמציתי השומר על החזון הכולל, וכן לתקשר שוב ושוב את הסיבה לפרויקטים ולפעילויות שנעשות. במקרים רבים, המידע שמועבר לעובדים הינו ברמת משימות כך שהמאמץ שהם משקיעים אינו מחובר למטרה הגדולה שלשמה יצא הארגון לדרך.
תהליך החלחול נעשה במגוון צורות, ובחזרה תמידית. כמו כן, המנהלים חייבים במעשיהם לדבוק במסר בעקביות, ולשמש דוגמה אישית שכן אם פיהם וליבם אינם שווים, העובדים מפנימים את מעשיהם ולא את המסרים המילוליים המועברים אליהם.
ראשית, אתאם עימכם ציפיות לגבי כוונתי למהות תוכנית השינוי. כוונתי לשינוי משמעותי שנעשה בארגון, כגון: הכנסת מתודולוגיות חדשות לניהול פרויקטים, או ניהול פיתוח, או ניהול איכות וכדומה. כלומר – הכנסת שיטת עבודה שמשנה את צורת העבודה בחברה. בדרך כלל השינוי כולל מעבר מעבודה אינטואיטיבית, המסתמכת על הניסיון וההבנה של המנהלים לגבי תהליכי העבודה הנכונים, לעבודה בצורה שיטתית, המסתמכת על תהליכי עבודה מיטביים שהוכח שהם משפרים באופן ניכר את הביצועים העסקיים של החברה. מוביל השינוי, הוא מנהל שבסמכותו להפעיל בעלי עניין לטובת הצלחת פרויקט השינוי. אותם בעלי עניין בדרך כלל עסוקים במשימות אחרות, עליהן הם נמדדים, וכן בדרך כלל הם לא מדווחים למנהל פרויקט השינוי.
יש סיבות רבות לצערנו לכישלון של תוכניות שינוי. דובר על כך רבות, קראו על כך במאמר שמונה הטעויות שיגרמו ליוזמת השינוי שלכם להיכשל. מאמר זה מתמקד בזווית נוספת והיא ההבדלים בציפיות של בעלי העניין לגבי מהות השינוי.
להלן עשר טעויות בתיאום ציפיות המפריעות להצלחה. לכל בעל עניין ראייה שונה וציפיות בשמיים, בהתאם לראייתו, שבאופן טבעי ומובן ממוקדת בעצמו-הוא, ואלו הן:
לכן, בטרם נצא לדרך, חשוב לתאם ציפיות, ולהעלות את פרויקט השינוי על דרך המלך, כאשר כל בעלי העניין מסונכרנים ומיושרים עם האג'נדה שלו. תיאום הציפיות כולל קישור יוזמת השינוי לאסטרטגיה או לפורטפוליו של הפרויקטים, תוך הבנת התועלות שבו, לחברה וליחידות העסקיות השונות. לפני היציאה לדרך, חשוב ביותר להבין את גודל הפער בין הרצוי למצוי, שגרם לפרויקט השינוי להיוולד. כמו כן, מחשבים מראש את גודל ההחזר על ההשקעה בפרויקט זה, הלוקח בחשבון את זמן ההבשלה שלו. לפרויקט ספונסור בהנהלת החברה, המסייע לו להתגבר על הקשיים שבדרך.
כלי מעולה לתיאום ציפיות הוא כתיבת כתב מינוי (Charter) המתאר בשלב הייזום (בטרם יוצאים לדרך) את מהות הפרויקט, מטרותיו, אבני הדרך שלו, תוצריו, מדדיו, צוות הפרויקט, בעלי העניין. כתב המינוי מאושר (או לא) בתחילת הדרך כך שכולם מסונכרנים ומתואמים.
האם אתם מכירים טעויות נוספות בתיאום ציפיות המפריעות להצלחה? אשמח לשמוע ולהוסיף לרשימה.
המאמר פורסם בגיליון אפריל 2014 של עיתון Information World
מזמינה אותך להצטרף לקבוצת WhatsApp שקטה שבה אני משתפת אחת לשבוע מאמר קצר או טיפ בנושא איכות ומצויינות בארגונים. קישור להצטרפות – כאן |
כנגד ארבעה בנים דברה תורת הניהול, אחד חכם, ואחד רשע, ואחד תם, ואחד שאינו יודע לשאול.
מנהל חכם מה הוא אומר? "מה העדות, החוקים והמשפטים אשר ציווה הניהול השיטתי אתכם? אני רוצה ללמוד כיצד לנהל כהלכה! " ואף אתה אמור לו – חזור למקורות מהות הניהול. בסס את הידע שלך על מודלים שמגלמים ניסיון שהצטבר בתעשייה שנים רבות, השתמש בשיטות וכלים שיובילו אותך למטרה במהירות ויעילות, ונהל נכון את משאביך.
מנהל רשע מה הוא אומר?: "מה העבודה הזאת לכם? אני לא צריך את זה!" ובכך הוא מוציא את עצמו מהכלל. הוא מלגלג ולועג לכל תהליכי הניהול. הכול נתפס כבדיחה בעיניו; הוא בעצם לא שואל אף שאלה. הוא רק מקווה שאין לכם תשובה.
למרות שהמנהל הרשע נלחם בנו, הוא לפחות משתתף בדיון ויש עם מי לדבר. הוא חושב, הוא ערני. ואם מצליחים להוציא אותו מ"רשעותו", הוא יוכל להפוך למנהל חכם.
מנהל תם מה הוא אומר? "מה זאת?" הוא לא יודע הרבה על ניהול, אבל הוא מבקש להבין את הסיבות לתהליכים. המנהל התם אינו לומד מהספר, אלא קשור להיבט היומיומי. כדי שסקרנותו תתעורר, הוא צריך לראות את יתרונות השינוי במו עיניו קודם שיקום ויעשה מעשה. למנהל כזה צריך להביא Benchmark מארגונים אחרים שעשו שינוי ונהנים מפירותיו.
ומנהל שאינו יודע לשאול מה הוא אומר? מנהל כזה נראה אדיש ופסיבי, ואנו אומרים לו: אם אינך חלק מהפיתרון, אתה חלק מהבעיה.
ואיזה מנהל/ת את/ה ??
מזמינה אותך להצטרף לקבוצת WhatsApp שקטה שבה אני משתפת אחת לשבוע מאמר קצר או טיפ בנושא איכות ומצויינות בארגונים. קישור להצטרפות – כאן |
אשמח לשיתוף באחת הרשתות החברתיות שקישורן להלן.