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

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

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

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

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

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

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

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

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

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

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

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

ה-PMBOK מתייחס לתכולה בשני אופנים:

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

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

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

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

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

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

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

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

גוף הידע בניהול פרויקטים (PMBOK Guide), מכיל עשרה תחומי ידע.

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

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

אחד מעשרת תחומי הידע של ה- PMBOK הוא ניהול אינטגרציה.

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

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

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

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

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

גוף הידע בניהול פרויקטים (PMBOK Guide), מכיל עשרה תחומי ידע.

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

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

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

כדי להיות 10 בניהול פרויקטים, עלינו:

בהצלחה לכולנו !

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

בגרסת התקן 9001:2015 ISO.הוחלפה הדרישה לפעולה מונעת לתהליך של ניהול סיכונים.

האם לדעתכם יש הבדל בין פעולה מונעת לניהול סיכונים? אם יש הבדל – מהו?

כדי ענות על השאלה, נשווה את שני התהליכים, לפי שלביהם:

זיהוי

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

הערכת נזק

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

החלטה על פעולה

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

מעקב ובקרה

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

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

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

סוף מעשה במחשבה תחילה

תהליך ניהול סיכונים מוסיף שתי פעולות חשובות מעבר לפעולה המונעת:

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

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

יש הבדל או אין הבדל?

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

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

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

האם השינוי חשוב?

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

ארגונים רבים בארץ ובעולם עוברים תהליך התעדה לפי תקן 9001 ISO. עד כה, ברוב הארגונים, תהליך ניהול סיכונים שיטתי אינו מוטמע בחלק גדול מהארגונים, במיוחד בארגונים קטנים. הכנסת התהליך לתקן הבסיסי והפופולארי גורמת להרבה מאד ארגונים למסד תהליך שכזה, לתועלתם. עד כה, תהליך ניהול סיכונים היה חובה רק בתקני ISO אחרים יותר כגון: ISO 27001 לבטיחות מידע, ISO 14001 לבטיחות הסביבה ועוד. המלצתי – גם אם הדרישה היא "רק" ל- Risk-Based-Thinking – מסדו תהליך ניהול סיכונים שיטתי. אל תסתפקו בדרישה המנינמלית. שהרי – לא מספיק למסד חשיבה על… מיסוד תהליך שיטתי מביא תועלת רבה.

מי צריך להגדיר דרישות?

כל מי שמעוניין לקבל את התועלות הבאות, או לפחות את חלקן:

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

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

מקובל לחשוב שהידע כיצד להגדיר דרישות אמור להיות נחלת מנהלי מוצרים שמגדירים לגוף הפיתוח את תכונות המוצר החדש, או נציגי גופים עסקיים שמגדירים לארגון מערכות מידע את תכונות המערכת החדשה. ובכן, נכון! אך לא רק אלה. אפשר להוסיף לרשימת "הלקוחות" של ידע זה – מנהלי משאבי אנוש שמגדירים דרישה לתהליך אותו יעשה יועץ; גופי פיתוח, תפעול ושירות שמגדירים תכולת עבודה למכרז או מיקור חוץ, גופי בדיקות שמאשרים את המוצר/שירות לפני השקתו, גופי תמיכה ועוד.

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

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

איך מגדירים דרישות?

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

שלושת המאמרים הבאים פותרים את התעלומה – כיצד מגדירים דרישה טובה ?

חלק ראשון המתחיל לפתור את התעלומה

חלק שני – ממשיך בעקביות בפיתרון התעלומה

חלק שלישי – הפיתרון במלואו !

ומאמר בונוס נוסף – עשרת הכללים להגדרת דרישה מדויקת

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

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

תם ולא נשלם… המשך יבוא !

קריאה נעימה ומועילה,

שלכם,

אורנה קמין

לאחרונה היינו עדים לאירוע מפחיד בכל קנה מידה: שריפה פרצה במפעל פלסטיק בקיסריה. בכתבה של Ynet מיום 22.6.14 נכתב שעל כיבוי השריפה עמלו 123 לוחמי אש, 69 כבאיות ו-6 מסוקי כיבוי שגויסו מכל הארץ. האש, שהגיעה לגובה 20-25 מטר, התפשטה למפעל שכן וכילתה גם אותו. היה חשש להתפשטות האש למפעלים סמוכים נוספים. עשרות עובדים שהו במפעל ולמרבית המזל רובם חולצו ללא פגע, למעט שני עובדים שנפגעו במצב קל ובינוני. תושבי הסביבה נאלצו להסתגר שעות רבות בבתיהם ללא מזגן ולסגור את כל הפתחים כדי שלא ישאפו עשן רעיל. בהתאם למסקנות ראשוניות מהאירוע, מדובר בהתלקחות באזור אחסון ששופץ לאחרונה וכנראה טרם התקבל אישור שירותי הכבאות להפעלת המקום. המפעל נשרף כליל ואיתו הכסף שהושקע בשיפוץ. מחדל בטיחותי זה הסב לבעלי המפעלים נזקים עסקיים כבדים בעקבות הרס המפעלים ואי יכולתם לעמוד בהתחייבויות לאספקת סחורה. עובדי המפעל נשארו ללא פרנסה לתקופה ממשוכת.

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

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

האם אפשר למנוע התרחשויות שכאלה?

בוודאי!

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

תקן 9001 ISO – תקן ניהול איכות – במסגרת המהדורה החדשה של התקן שצפויה להתפרסם בשנת 2015 צפוי להתווסף פרק שמחייב את הארגון העומד בתקן לבצע סקר סיכונים במקום ההנחיה הקודמת שדיברה על פעילות מונעת בצורה ערטילאית.
תקנות ארגון הפיקוח על העבודה (תכנית לניהול הבטיחות), התשע׳׳ג-2013 – במסגרת תכנית בטיחות שכל ארגון מחויב להכין עד אוגוסט 2014 נדרש לבצע הערכה מלאה של כלל סיכוני הבטיחות שיש לארגון.
תקן ת"י 18001 או בגרסתו החדש – תקן ISO 45001:2018– מערכת בטיחות וגהות – התקן מחייב ביצוע סקר סיכונים מלא לכל תהליכי עבודה שקשורים לבטיחות.
תקן 14001 ISO – מערכת סביבתית – התקן מחייב ביצוע סקר סיכונים מלא לכל ההשפעות הסביבתיות של הארגון.
תקן 27001 ISO – תקן אבטחת מידע – התקן מחייב התייחסות לכלל סיכונים שיכולים לפגוע במערכות מידע ומאגרי מידע של הארגון.

איך עושים את זה?

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

OK, מהו סיכון ולמה לנו להתעסק עם זה בכלל?

סיכון הינו הסתברות להפסד כתוצאה מ-:

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

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

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

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

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

מהו תהליך של ניהול סיכונים?

תהליך ניהול סיכונים הוא תהליך של מספר צעדים:

צעד ראשון – הערכת עוצמת הסיכונים

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

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

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

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

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

רקע לניהול דרישות

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

דרישה: תכונה של המוצר/השירות, המהווה תנאי לקבלה ע"י המזמין

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

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

איך יוצרים דרישה מדויקת ? כללי העבודה בקטגורית "דיוק (Precision)" יעזרו לנו ליצור דרישות כאלה.

המסתורין של שמות העצם

יידוע שמות עצם: השתמש אך ורק בשמות עצם מיוּדעים (מלווים בה"א הידיעה). שימוש במונחים ללא יידוע מוביל לריבוי משמעויות.

דוגמה:

המערכת תספק תצוגת זמן

מושא הדרישה (תצוגת זמן) צריך להיות מיודע כדי שיהיה חד-משמעי:

המערכת תציג את השעה-הנוכחית

חיים ומוות ביד הלשון

לשון פעיל: השתמש בלשון פעיל ובישות מבצעת מוגדרת לפעולה. שימוש בלשון סביל מקשה על אימות הדרישה.

דוגמה:

זהות הלקוח תיבדק

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

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

מי הנושא בעול?

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

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

דוגמה:

הרכב ינגן קבצי שמע מהתקני USB.

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

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

מערכת השמע תנגן קבצי שמע מהתקני USB.

זאת דרישה ממערכת השמע ברכב.

כבודו במקומו מונח

מונחים מוגדרים: השתמש אך ורק במונחים המוגדרים במילון (Glossary).

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

דוגמה:

הכספומט יציג את מצב החשבון.

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

הכספומט יציג את מצב-החשבון.

מהמילון:

מצב-החשבון

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

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

כמה ? שבע ! מה שבע ? מה כמה !

כַּמָּתים: המנע מכַּמָּתים (Quantifiers) לא מדויקים. דרישה צריכה להיות מכומתת במדויק.

דוגמה:

המאזניים הביתיים יציגו את המשקל עד לדיוק של בערך 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 דקות.

מהו טווח הקבילות ?

עד כמה להיצמד לכמות המצויינת?
- כמה מעל 120 ליטר לשנייה יהיה קביל?
- כמה מתחת ל- 120 ליטר לשנייה יהיה קביל?
עד כמה להיצמד לטווח המצויין?
- כמה מעל 30 דקות יהיה קביל?
- כמה מתחת ל- 30 דקות יהיה קביל?

"נכונות" של גדלים בדרישות באה לידי ביטוי בכך שלכל גודל מציינים את הטווח הקביל שלו:

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

כעת ברור:

שהטווח הקביל של הביצועים מבחינת הזרימה הוא 10± ליטר לשנייה
ש-30 דקות הוא מינימום הביצועים הקביל מבחינת משך הזמן

תואמת למוסכמות

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

הרציונל: כאשר לכל הדרישות אותו פורמט ואותו "מראה" (Look-and-Feel), הרבה יותר קל לכתוב, להבין, ולסקור כל דרישה.

דוגמא:

הלהקה תנגן שירים בלקניים ומזרחיים.

התזמורת תופיע במהלך כל הערב.

"הלהקה" ו"התזמורת" הם שמות שונים לאותו ספק שירות, וזה עלול לבלבל.

כל הדרישות צריכות להתיישב עם תשתית אחידה:

אנסמבל "עורבא פרח" ינגן שירים בלקניים ומזרחיים.

התזמורת תופיע במהלך כל הערב.

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

סיכום: תכונות של דרישה "טובה"

לסיכום, להלן ריכוז כל התכונות שפגשנו לאורך שלושת המאמרים האחרונים:

ובפירוט:

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

מה למדנו ?

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

מה הלאה ?

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

על המחבר, אלון מודעי

מומחה לתהליכים הנדסיים. בוגר תואר שני מאוניברסיטת Carnegie Mellon ובעל 30 שנות ניסיון בארגוני פיתוח שונים, בארץ ובעולם. מזה 12 שנים עוסק בשדרוג תהליכי הנדסת המערכות בתעשייה האווירית, בהדרכה ובהטמעה.

רקע

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

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

למדנו גם את כלל כתיבת הדרישות הראשון:

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

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

מה בכלל עושים עם דרישות?

לפני שנמשיך, בואו נתבונן במספר פעולות שמתבצעות באופן טיפוסי על דרישות:

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

תכונות של דרישה "טובה" (המשך)

דרישה "טובה" מוגדרת ע"י התכונות הבאות:

שלמה (Complete)

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

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

דוגמא:

פעמון האזעקה

יצלצל למשך לא יותר מ-20 דקות

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

פעמון האזעקה

פעמון האזעקה יצלצל למשך לא יותר מ-20 דקות

כעת אפשר להבין את הדרישה גם ללא הכותרת.

יחודית (Singular)

דרישה צריכה לבטא רעיון יחיד וברור.

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

דוגמא:

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

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

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

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

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

ישימה (Feasible)

דרישה צריכה להיות ברת ישום.

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

דוגמא:

למוצר תהיה אמינות של 100%.

אמינות של 100% כמעט שאיננה ברת-השגה. אם נחשוב קדימה לאימות הדרישות – איך נוכיח אמינות של 100% ? וגם לו יכולנו לבנות מערכת כזאת – האם נוכל להרשות זאת לעצמנו מבחינת העלות ?

השוו לעומת זאת את הדרישה שלהלן:

למוצר תהיה אמינות גדולה או שווה ל-98%.

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

כללים לכתיבת דרישה "טובה" (המשך)

זה הזמן לציין עוד כלל חשוב לכתיבת דרישות:

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

תנאי + נושא + נשוא + מושא [ + סייג]

תנאי – תבנית המציינת באילו תנאים הדרישה צריכה להתקיים, למשל: "כאשר טמפרטורת המים בדוד נמוכה מ-C85⁰"

נושא – תבנית המתארת את מבצע הפעולה שבדרישה, למשל: "מערכת הבקרה"

נשוא – תבנית המתארת את הפעולה המתבצעת, למשל: "תפתח"

מושא – תבנית המתארת את היישות שעליה הפעולה מתבצעת, למשל: "את שסתום כניסת המים"

סייג – תבנית אופציונלית המתארת מיגבלה כלשהי על ביצוע הפעולה, למשל: " בתוך פחות מ-3 שניות"

והמשפט השלם:

כאשר טמפרטורת המים בדוד נמוכה מ-C85⁰, מערכת_הבקרה תפתח את שסתום_כניסת_המים בתוך פחות מ-3 שניות.

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

מה למדנו ?

אוסף התכונות של דרישה "טובה" שבנינו עד עתה הוא:

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

צברנו גם שני כללים לכתיבת דרישה "טובה", והם:

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

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

מה הלאה ?

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

הערה לפני סיום

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

על המחבר, אלון מודעי

מומחה לתהליכים הנדסיים. בוגר תואר שני מאוניברסיטת Carnegie Mellon ובעל 30 שנות ניסיון בארגוני פיתוח שונים, בארץ ובעולם. מזה 12 שנים עוסק בשדרוג תהליכי הנדסת המערכות בתעשייה האווירית, בהדרכה ובהטמעה.