אסטרטגיה זאת לא מילה גסה

29 באוקטובר 2010


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


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


איך בונים את האסטרטגיה שלך?




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


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


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

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




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


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


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

מה הסדר? מה שמפריע היום, לפני מה שמפריע מחר, ובוודאי לפני מה שמפריע עוד שנה.


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


אם תשימו לב, שני הצעדים המשמעותיים ביותר שתדרשו לבצע במסגרת האסטרטגיה הם:




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


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

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


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




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


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


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


  4. האם באמת צריך כל כך הרבה פלטפורמות? בתחום המובייל לדוגמה יש נטייה לפתח לכל פלטפורמה פתרון ייעודי ובכך להמציא את הגלגל כל פעם מחדש. האם באמת חייבים לפתח פתרון שייתן חווית משתמש מיטבית על כל אחת מהפלטפורמות? או לבחור באסרטגיה של  פתרון גנרי (לדוגמה HTML5 WebApp) שתיתן מענה לכלל הפלטפורמות ופתרונות נקודותיים עבור פלטפורמות עם ערך לקוח גבוה מספיק (לדוגמה iPhone) על מנת להצדיק פיתוח יעודי.

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


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


רוצים דוגמאות למהלכים אסטרטגיים?


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


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


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




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


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


ממשיכים לפתח,
משה קפלן Follow MosheKaplan on Twitter

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


שני אירועים מעניינים יערכו בקרוב:




  1. ב – 9/11 כנס של ה – IGT על המודלים העסקיים בתחום SaaS והאתגרים הטמונים בו


  2. ב – 16/11 כנס על Cloud Computing בשם CloudCon, שאני גם מרצה בו על תכנון של מערכות Cloud Computing.

הוסף תגובה
facebook linkedin twitter email

להגיב על Moshe Kaplan לבטל

האימייל לא יוצג באתר. שדות החובה מסומנים *

2 תגובות

  1. יוני29 באוקטובר 2010 ב 23:59

    תודה, נהנה לקרוא את הבלוג שלך כל פעם מחדש!

    הגב
  2. Moshe Kaplan30 באוקטובר 2010 ב 11:44

    תודה יוני,

    ממשיכים לפתח,
    משה קפלן

    הגב