You are currently viewing ניהול פרויקטים – פרויקט בניה ופרויקט תוכנה – או – "אצלנו זה קשה, אצלם – זה קל!"

ניהול פרויקטים – פרויקט בניה ופרויקט תוכנה – או – "אצלנו זה קשה, אצלם – זה קל!"

"אצלנו, לנהל פרויקטים זה מסובך, אצלם – זה פשוט!"

מי לדעתך אמר לי את המשפט הזה? מנהל פרויקט בבניה ותשתיות או מנהל פרויקט בסטארט-אפ (חברת הזנק)?

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

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

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

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

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

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

אז מה קורה פה? מי צודק ומי טועה? ואולי שניהם טועים? או ששניהם צודקים?

מה ההבדל בין פרויקטי הייטק וסטארט-אפ – המתמקדים בנושאי תוכנה, לבין פרויקטי בניה ותשתיות?

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

ניהול פרויקטים – פרויקט בניה ופרויקט תוכנה או "אצלנו זה קשה, אצלם – זה קל!"

הקושי המרכזי בפרויקט בניה ובפרויקט תוכנה

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

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

התשובה הראשונה היא בעלי העניין. לא משנה מה גודל פרויקט הבניה – באם מדובר בבית פרטי, בניין מגורים בן כמה קומות, מגדל רב קומות למגורים או למשרדים, בית מלון ואולי גשר, מנהרת כלי רכב או מנהרת תשתיות – לכולם יש המון בעלי עניין. מה ההגדרה ל׳בעלי עניין׳, ובמלים אחרות – מי הם בעלי העניין?
בעל עניין = כל אדם / גוף שיש לו נגיעה או קשר לפרויקט.

מי הם בעלי העניין בפרויקט בניה ותשתיות?

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

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

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

יש עוד הבדלים בין פרויקטי תוכנה ופרויקטי בניה ותשתיות?

כן.

משאבים - זמינות משאבים

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

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

בפרויקט בניה ותשתיות, הבעיה – אילו משאבים נדרשים לבניית הפרויקט – על פי רוב פתורה. הקושי נמצא, פעמים רבות, במענה לשאלות הבאות:
א. מה הן דרכי הגישה לפרויקט שדרכן אפשר לשנע את כל המשאבים הנדרשים? האם הן מתאימות?
ב. האם ניתן לשים את כל המשאבים הנדרשים במקום המוגדר לפרויקט? למשל, אם שטח הפרויקט צר – לא ניתן יהיה למקם את הכלים ולשנע אותם כדי לבצע את העבודה הנדרשת.
ג. האם המשאבים זמינים? למשל, בתחילת שנות ה- 2000, היו בארץ מכונות קידוח כלונסאות בקוטר 45 ס"מ, אך לא ניתן היה להשיג יותר מ- 4 מכונות לפרויקט. היו מעט מאד מכונות 60 ס"מ בארץ ומכונות 80 ס"מ היה צריך ליבא לפרויקט במיוחד. היום, מגבלות אלו לא קיימות למכונות קידוח וקיימות מגבלות אחרות.
ד. כמה זמן נדרש למשאב – שאנחנו לא מנהלים אותו…? למשל, קבלת אישורים מהעירייה או מהמשטרה.

לוחות זמנים

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

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

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

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

לכן, בניית לוח זמנים בשיטת המפל בפרויקטי תוכנה – כמעט ואינה אפשרית. הפתרון לכך נמצא בשיטות אחרות, כגון Agile.
בשיטת Agile מחלקים את החידה לבעיות קטנות. לכל 'בעיה קטנה', מגדירים טווח זמן קצר בו מבצעים sprint – ריצה מהירה למרחקים קצרים – כדי לפתור את אותה 'הבעיה הקטנה'.
במסגרת הספרינט, מבצעים את אותן האיטרציות – חזרות עם שינויים – עד אשר מוצאים פתרון לבעיה 'הקטנה'.
כמה זמן ידרש לספרינט? זו שאלת השאלות – שאין עליה 'פתרון בית ספר'. יכול להיות שימצא הפתרון בשתי איטרציות, ואולי ידרשו 6 או 7? ואולי יותר? מי יודע? אף אחד. הרי זו בעיה שלא מצאו לה קודם פתרון. הסיבה לכך פשוטה: אם היו מוצאים לה קודם פתרון – כבר היו לוקחים אותו, ואז זו לא היתה בעיה…

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

אף אחד לא יגלה לך פרטים חדשים על הלו"ז שלך?

תקציב

ככל שיש נעלמים רבים יותר – כך הגדרת התקציב קשה יותר.

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

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

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

בוודאי!

ניהול אנשים

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

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

עם HCP-Go מנהלי פרויקטים מסיימים את הפרויקט בהצלחה. רוצה לדבר עם טל לבנון על כך?

תקשורת

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

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

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

מרווח בטחון

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

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

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

אי וודאות וסיכונים

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

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

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

בקרה

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

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

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

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

סיכום - פרויקטי תוכנה ופרויקטי בניה ותשתיות – אצלם זה קל ואצלנו קשה...

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

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

וישנם תחומים – שיהיו קשים גם באלו וגם באלו.

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

אהבת את המאמר?

אנחנו מזמינים אותך לקרוא את המאמר הבא:
Share on facebook
Share on linkedin
Share on whatsapp

יש אנשים שאכפת לך מהם? זה הזמן לשתף! 
רוצה לשאול משהו או להגיב? בכיף! פה, בתגובות
רוצה לומר רק לי משהו? יש לציין זאת בתחילת התגובה והתגובה לא תפורסם

כתיבת תגובה