בלוג > מאמרים

על חשיבות הצד הניהולי בפיתוח מוצרים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

המסקנה הבלתי נמנעת היא שהאמונה ש"אין לנו זמן לזה", היא מוטעית באופן בסיסי.
האמת היא ש"אין לנו זמן לעבוד בלי זה".


נכתב ע"י רונית סנה
IntelliManage

 

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