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

    

בניהול פרויקטי פיתוח, הנושא העיקרי שצריך לנהל הוא זרימת המידע אשר נבנה ע"י הצוותים במהלך הפיתוח. כל מידע שנבנה, מהוה תשומות לתהליך הפיתוח הבא אחריו. שלא כמו בתהליך היצור שמטפל במוצרים גשמיים שאפשר לראותם ויכולים להמצא רק במקום אחד, את המידע קשה לראות, מכיוון שהוא נמצא בתוך המסמכים, במחשבים, אך ברובו "קבור" בראשם של האנשים. המידע שנוצר במהלך הפיתוח, אינו עובר רק למקום אחד כדוגמת תהליך יצור, אלא צריך לעבור למספר רב של מקומות המשתמשים במידע להמשך תהליכי הפיתוח והיצור. ז"א בניהול הפרויקט אנו חייבים לדעת על כל המקומות שמידע זה צריך לזרום אליו. הבעייה היא שישנם מקומות שמידע זה צריך לזרום אליהם, ואנחנו לא יודעים על כך.
פרויקטים מערכתיים כוללים תתי מערכות אשר מפותחות בארגונים שונים ע"י מחלקות מקצועיות רבות. לרוב פרויקטים אלו מתממשקים למערכות חיצוניות מורכבות הממוקמות בארגונים שונים. ז"א שבנוסף למידע הרב שבפרויקט, קיים מידע נוסף שהוא חשוב ביותר לפרויקט, אשר מוסתר בממשקים בין כל הדיסיפלינות הנ"ל. לכן אם בבניית תוכנית הפיתוח, זרימת המידע אינה מסונכרנת ומתואמת ע"י כל המעורבים, הפרויקט צפוי לכשלים והפתעות לאורך כל תהליך הפיתוח, מה שגורם כמובן לדחיות בלוחות הזמנים והגדלת עלויות הפיתוח.
בעיתיות בבנית תוכנית פיתוח ב- MS Project
בניית תוכנית העבודה בפרויקט נעשית בדרך כלל ע"י מנהל הפרויקט או מהנדס המערכת בשני אופנים: תכנון Top-Down שמתחיל מאפיון על המפורק לרכיבים, תוך התייחסות לאינטראקציות בין הרכיבים. האפשרות השנייה היא תשאול אחד-על-אחד שזה בעצם סוג של Bottom-Up. בשני המקרים מנהל הפרויקט לרוב נפגש בניפרד עם כל אחד מהדסיפלינות המעורבות בפרויקט, ובונה תוכנית פיתוח, פעילויות + לו"ז, על פי האינפורמציה שהוא מקבל מכל אחד מהאנשים. לפעמים מתקיימות גם ישיבות תאום ברמת מקרו כאשר מתגלה סתירה משמעותית בנתונים. בסיכום הפגישות מנהל הפרויקט מסכם את כל הפעילויות ב- MS Project ומקבל גנט של תוכנית הפיתוח עם עשרות או מאות פעילויות. גנט זה משמש אותו בניהול השוטף של הפרויקט. בשיטת בניית תוכנית עבודה זו, חסרונות רבים אשר גורמים לכך שתוכנית העבודה שנבנתה תהיה לא ריאלית, לא אמינה ואפילו לא משקפת את תהליך הפיתוח הנכון שצריך להתקיים בפרויקט. להלן כמה מהחסרונות:
· מנהל הפרויקט המכין את תוכנית העבודה, אינו מסוגל לבדו לראות ולהבין את כל הבעיתיות של הפרויקט. כאשר הוא מתשאל את אנשי הצוות על מנת לבנות את תוכנית העבודה, הוא לא תמיד יודע לשאול את כל השאלות. האדם המוסר את האינפורמציה, לא תמיד זוכר את כל הפרטים. לרוב בשלבים הראשונים גם לא ברור לו כל מהלך הפיתוח. כתוצאה מכך האינפורמציה המתקבלת מתשאול כל אדם ואדם בנפרד היא חלקית בלבד.
· האדם אשר נותן את האינפורמציה למנהל הפרויקט לא מודע, או מודע חלקית, לתוכניות הפיתוח של שאר חברי הצוות מתחומים אחרים. כתוצאה מכך האינפורמציה שהוא מספק, נותנת אופטימיזציה מקומית לתחום שלו. אם היה שומע ומבין לעומק מה אחרים מבצעים בפרויקט, אולי היה פועל שונה והנתונים שהיה נותן למנהל הפרויקט היו אחרים וגם מסונכרנים יותר לתהליך הפיתוח.
· האינפורמציה החשובה ביותר בפרויקט, נמצאת בממשקים של כל הגופים המעורבים בפיתוח וביצור. מכיוון שמכין תוכניות העבודה מקבל מכל אחד בנפרד את האינפורמציה, חסר לו את כל המידע המצוי בממשקים. לכן תוכנית העבודה לוקה בחוסר תכולות חשובות שרק עבודת צוות יכולה לאתר אותן ולשלבן בתכנית העבודה.
· ארכיטקטורת המערכת תלויה בלוחות הזמנים. זאת מכיוון שהיא מורכבת: ממכלול תתי מערכות שנמצאות בשלבים שונים של תהליך הפיתוח, מגירסאות תוכנה המתפתחות בקצב שונה, מטכנולוגיות המשתנות במהירות, ומממשקים הנמצאים לרוב בתהליך של שידרוג. לכן על מנת לקבל החלטות לגבי ההארכיטקטורה של הנדסת המערכת, חייבים לגבש תוכנית עבודה אמיתית וריאלית של שילוב ואינטגרציה של כל המערכות יחד, כי מהם נגזרות תוכניות העבודה.
· פרויקט מורכב לא מאופיין רק ע"י המפרט. במהלך השלבים הראשוניים של פיתוח הפרויקט, הפרויקט צריך לספק אינפורמציה ללקוח, והלקוח צריך להשלים אינפורמציה לפרויקט, תהליך של הלוך וחזור שמסתיים ברובו ב- CDR. תוכנית עבודה זו של העברת האינפורמציה אינה יכולה להיבנות אם מתשאלים כל גוף בנפרד.
· Unknown – Unknown הוא המידע שמנהל הפרויקט לא יודע שהוא לא יודע עליו. אלה הם לרוב אותם נושאים שעוצרים את הפרויקט וגורמים לדחיות בלוחות הזמנים. מידע זה יכול להתגלות רק בניתוח מפורט של הפיתוח שמתבצע יחד ע"י כל המעורבים בפיתוח.
· אם אוספים את האינפורמציה מאנשים בודדים, תמיד יהיו פעילויות או חבילות עבודה אשר "נופלות בין השולחנות" בלי אחראים, או שפשוט נשכחות. חבילות עבודה אינן יכולות להתגלות בתוכנית העבודה שנבנתה מאוסף של אינפורמציות ממקורות בודדים.
· במהלך הפיתוח כל יום צריכות להתקבל החלטות, גדולות וקטנות. אם לגוף המתכנן אין תמונה כוללת של הפרויקט, הוא מבצע תהליך קבלת החלטות המכוון לאופטימום מקומי, שלא תמיד מתאים לאינטרסים של הפרויקט, ולפעמים אפילו נוגד.
· כאשר בניית תוכנית עבודה נעשית "אחד מול אחד", המחוייבויות לעמידה בלוחות הזמנים נעשות רק מול מנהל הפרויקט, ויחסית קל להתנער מהם. אך שבונים תוכנית עבודה כולם יחד, המחוייבויות מתבצעות לעיני כל חברי הצוות, וקשה להתכחש אליהם.
· פרויקט מצליח, מבוסס על צוות מלוכד, עם תקשורת טובה שפועל בהרמוניה ובתאום. אם תוכנית העבודה מבוססת על אוסף פעילויות מאנשים בודדים, לא נבנה לפרויקט צוות וחוסר התקשורת בין חברי הצוות גורם לאי הבנות ותקלות.

בניית תוכנית הפיתוח ע"י כל צוות הפרויקט
המסקנה היא שהאפשרות ההגיונית ביותר לבנות תוכנית עבודה נכונה וריאלית, אשר מסונכרנת ומוסכמת על כולם, היא שכל אנשי צוות הפרויקט יבנו יחד את תוכנית הפיתוח. שיטה זו נהוגה כבר בעולם בפרויקטים גדולים, שבהם צוותי הפרויקט מתכנסים לכמה ימים מרוכזים לסדנה שבה מגבשים את תוכנית הפיתוח. מכיוון שהסדנה כוללת אנשים רבים, משתמשים בכלים ויזואליים פשוטים לשפר את התקשורת וההבנה, ובמנחה המנוסה בניהול פרויקטים והנדסת מערכת אשר מוביל את הסדנה. להלן מוצעת שיטה מעולם ה - Lean הידועה בשם סדנת LPD - (Lean Product Development), לסינכרון תאום וגיבוש תוכניות הפיתוח.
בסדנה משתתפים כל אנשי צוות הפרויקט מכל התחומים: מנהל הפרויקט, מהנדס המערכת, הלקוח, נציגי הממשקים השונים, גופי התיכון, לוגיסטיקה, רכש, יצור, הספקים הראשיים, תפ"י, הרכבות, תוכנה, אינטגרציה ניסויים וכו`. בסדנה ממפים בצורה ויזואליתו את הפעילויות של כל תחום ותחום על ציר הזמן, ואת הממשקים בין כל הפעילויות. בסדנה נוצרת דינאמיקה קבוצתית המביאה ל: סיעור מוחות, סינרגיה, סנכרון העבודה בין הפעילויות השונות, זיהוי סיכונים, הצפת חבילות עבודה שלא ידעו עליהן, קיצור המתנות וחסכון של עבודה הנדסית מיותרת. התוצר הסופי של הסדנה היא תוכנית עבודה אינטגרטיבית אשר כולם מסכימים ומחוייבים לה.
בשיטת עבודה זו, מתגברים כמעט על כל חסרונות שתוארו בפרק הקודם. האמצעי העיקרי הגורם לכך הוא שכולם רואים יחד את כל תוכנית הפיתוח. הסדנה מאגדת ניסיון מצטבר של כל חברי הצוות מה שלא קיים בפגישות אחד על אחד. תוך כדי מיפוי הפעילויות של כל אחד מחברי הצוות, מתקבל משוב משאר חברי הצוות, ותוכנית העבודה מתעדכנת ומשתפרת. כל אחד מחברי הצוות יכול לראות כיצד הוא משתלב בתהליך הכולל, וכיצד עבודתו משפיעה על שאר חברי הצוות והתקדמות הפיתוח. תהליך זרימת המידע ובניית המידע בפרויקט הוא ברור, וכל אחד מבין מה תפקידו וכיצד הוא משתלב. בעזרת המיפוי הויזואלי
קל לזהות ממשקים לא סגורים או "קצרים" בזרימת המידע. ההחלטות על הארכיטקטורה והנדסת המערכת יכולות להתקבל בהסכמה ע"י כל הצוות בהתחשב באילוצי לוחות הזמנים והבעיות שהוצפו במיפוי. הלקוח מעורב בסדנה והוא יכול לזהות את נקודות הצומת שבהם הוא צריך לספק אינפורמציה, או לקבל אינפורמציה מהמפתחים. כתוצאה מהדינמיקה הקבוצתית וסיעור המוחות, מבינים טוב יותר את הדרישות, עולים על נושאים או חבילות עבודה שלא ידעו עליהם או שלא חשבו שהם דרושים לפיתוח, מזהים LLI, מציפים סיכונים שלא היו ידועים קודם וכו`.
סדנה מרוכזת של יום יומיים משפיעה גם על ההיבטים ההתנהגותיים, הופכים מאוסף של בודדים לצוות. התקשורת בצוות משתפרת ושיתוף הפעולה גדל בצורה ניכרת. מכיוון שכל אחד ואחד ממשתתפי הסדנה היה שותף לבניית תוכנית העבודה, המחוייבות שלו לעמידה בלוחות הזמנים גדלה, וגם תהליך קבלת החלטות מתבצע על פי היעדים של הפרויקט.

סיכום
תוכנית העבודה שניבנית בשיטה זו, מקטינה את סבבי הפיתוח ומאפשרת לעמוד בלוחות הזמנים ואפילו להקדים אותם. בפרויקטים מורכבים מומלץ לקיים סדנה בהתנעת הפרויקט, לפני PDR ו- CDR, לפני אינטגרציה ולפני כניסה ליצור. התועלות המתקבלות למנהל הפרויקט הם:
· מקבל תמונה אמיתית ועדכנית של סטאטוס הפרויקט
· מגבש תוכנית עבודה אמיתית וריאלית המקובלת על כולם
· רואה כמעט את כל הכשלים העלולים לצוץ בדרך
· מבין את התהליכים והממשקים המתרחשים אצלו בפרויקט, במפעל ואצל הספקים
· מקבל צוות מגובש לפרויקט המחויב לתוכנית העבודה
· בעיקר, מקבל הרגשה טובה כי הוא שולט בפרויקט ומנהל אותו,
קיימות תועלות גם להנהלת הארגון
· קיצור Time to Market והורדת עלויות פיתוח
· חסכון של ישיבות סטאטוס מתמשכות או ישיבות ניהול משברים לפתירת בעיות בפרויקט, כי לרוב הצוות פותר את הבעיות בעצמו בלי מעורבות הנהלה
· האינפורמציה המוצגת להנהלה היא אמיתית אמינה וריאלית
· הסדנה מתרגלת את האנשים לעבוד כצוות. הם לומדים להקשיב אחד לשני, לתמוך אחד בשני, לקחת מחויבויות, לסמוך אחד על השני ולדעת להתמקד במטרות ובפעילויות שהצוות החליט עליהם.

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

 |  ראשי |  אודות  |  הדרכה  |  ייעוץ ושירותים  |  English  |  יצירת קשר  |  טכנולוגיה  |  שיווק, מכירות ושירות  |  רכש, לוגיסטיקה, תפעול  |  חיפוש מידע באינטרנט  |  מיומנויות ניהול  |  ניהול פיננסי  |  היבטים משפטיים  |  ניהול עסקים בינלאומיים  |  קישורים  |  Privacy  |  מפת אתר  |  הוספה למועדפים  | 
A2B-הדרכה וייעוץ בתחום העסקי, הטכנולוגי והלוגיסטי- www.a2business.co.il © כל הזכויות שמורות
A2B כתובת: המועצה האזורית דרום השרון , ת.ד 347 נווה ירק טלפון: 03-9044077 שלוחה 112 פקס: 03-9044233
  בניית אתרים לעסקים   אינטרדיל