ארכיון

ארכיון של אוגוסט, 2010

שינויים

10 אוגוסט, 2010 אין תגובות

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

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

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

למה הכוונה ?

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

וכמובן שיש עוד נקודות של שינוי הנחות יסוד בחברות שונות .

אז מה אנחנו עושים עם זה?

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

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

ההכנה מורכבת מכמה רבדים.

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

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

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

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

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

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

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

קטגוריות:מתודולוגיות, ניהול, תהליכים תגיות: