אסטרטגיה וניהול פיתוח?
כאשר אנחנו חושבים על ניהול של פיתוח, אנחנו חושבים בד"כ על איך לשפר את הנדסת התוכנה של המוצר, איך לגייס מתכנת טוב, ואיך להוציא גרסה נקייה יותר. לעיתים זה נראה הדבר הרחוק ביותר מאסטרטגיה שאנחנו קוראים עליה במדורי הכלכלה. ובאמת, מה הקשר בין לסגור גרסה חדשה לבין הקנייה האחרונה של 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 ועד הגעה לשרת הייצור, יחלפו בין דקות לשעות שמספר הפעולות הידניות בינהן יהיה מזערי, ויכללו השבתה מינימאלית של סביבת הייצור. כדי להגיע למצב הזה תצטרכו להשקיע משאבים רבים שבהתחלה יהיה קשה אולי להסביר אותם. אבל התוצאה בסוף תחזיר את הכסף בתשואה מכובדת. לנושא זה נקדיש פוסט באחד מהשבועות הקרובים.

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

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

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

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

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

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

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

1. ב - 9/11 כנס של ה - IGT על המודלים העסקיים בתחום SaaS והאתגרים הטמונים בו
2. ב - 16/11 כנס על Cloud Computing בשם CloudCon, שאני גם מרצה בו על תכנון של מערכות Cloud Computing.

1. מה היעד? על הנווט לתאר באופן ממצה את הבעיה שניסה לפתור.
2. מה הדרך? על הנווט להציג בראיית על את המערכת (Top-Down) כולל האסטרטגיה לפיתרון, ארכיטקטורת המערכת, ה - Unit Tests,  ובמקרה הצורך להציג את ה - Class Diagram. ולא, לא צריך לעשות את זה ידנית. כיום רב כלי ה - IDE הנפוצים מאפשרים לעשות את זה אוטומטית.
3. מה הדברים המעניינים שנראה בדרך? גם אם אפשר ורצוי לעבור על כל הקוד, בוודאי שאי אפשר לתת אותה תשומת לב לכל שורה. לכן לפני התחלת הטיסה אל היעד, על הנווט לתאר את הבעיות העיקריות בדרך או בעברית מה האזורים בקוד שהיו כואבים מבחינתו. רב הסיכוי ששמה גם ימצאו הבעיות המשמעותיות במימוש.

החיים זה כמו עיתון
בכל עיתון יש כותרת ראשית, כותרות משנה ולאחר מכן המשך הכתבה. קוד מתנהג בדיוק אותו דבר, אם יש לנו פונקציה ארוכה מדי, אף אחד לא יקרא אותה. לכן אנחנו רוצים להגיע למצב שבו יהיו לנו כותרת מתומצתת (שם הפונקציה הראשית), כותרות משנה (שמות של פונקציות משנה) ותוכן שיתפצל בין פונקציות המשנה. זוהי ה - Newspaper Paradigm שצריכה להנחות אותנו בעת הפיתוח ובעת ביצוע ה - Code Review. פרדיגמה זו מסייעת לנו עם עוד מספר סימנים:

1. אורך פונקציה: פונקציה שחורגת מ - 5 עד 8 שורות מצביעה על פונקציה בעייתית. אם זיהינו שיש פונקציה שלא עונה על ההגדרה הזאת, ניתן לסדר אותה בקלות ע"י כלי ה - Refactors שכלולים בפלטפורמות ה - IDE הנפוצות היום.
2. שמות פונקציות שלא מסבירות שום דבר: ברגע שקוראים לפונקציות עם שמות משמעותיים, אפשר לוותר על רב ההערות בתוך הקוד.
3. עודף הערות: כנראה ששמות הפונקציות שלכם לא ממש ברורים, או שהפונקציות עושות יותר מדי דברים וצריך לחלק אותן
4. אורך מחלקות: כאשר Class גדול מ 50-80 שורות (וכולל מעל 2-3 שדות, ו -5-8 מתודות), כנראה שגם כאן אנחנו בבעיה.

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

1. המנעו מתכנון למשהו שאף פעם לא יקרה... (או KISS): קרה לכם פעם שהתכוננתם למשהו שלא יקרה? עשיתם פיל מבקשה שהגיעה מהשיווק כי חשבתם שזה שרצוי לתמוך בעוד עשר אפשרויות לכל מקרה שלא יקרה? מומלץ להמנע מבניית פילים לפני שמגיעה בקשה חוזרת שהמשמעות שלה שבאמת צריך פתרון בגודל של מפלצת.
2. Shutgun Surgery: אם קורה לכם לעיתים תכופות מדי ששינוי קטן יחסית גורר עדכון במספר רב של מתודות ומחלקות, כנראה שאתם בבעיה. הפתרון לכך הוא ניתוח של הקוד וזיהוי מחלקות חבויות בפנים ו/או התנהגויות שצריך להוציא אותם החוצה. הכלל הבסיסי הוא זיהוי חתיכות קוד החוצה ובדיקה האם באמת הן צריכות להיות איפה שהן נמצאות. אם התשובה שלילית כנראה  שצריך להוציא אותן לשירותים גנאריים. ככה תחסכו תופעות של שינויים מקביליים ובאגים.
3. עטיפה של כלי צד שלישי: כל פעם שפונים למערכת חיצונית, מומלץ לממש את זה דרך שכבה דקה שתעטוף את זה, כך שכאשר תרצו לצאת מהספק (גם כלי NoSQL זה ספק), תוכלו לבצע את ההחלפה בנקודה אחת בקוד ולא תסתבכו עם זה.
4. לא לרוץ לפתור בעיות ביצועים: יש לנו נטייה לרוץ ולהכריז שכל דבר שזז הוא בעיית ביצועים. לפעמים יש דגל שחור מעל אזורים מסויימים (לדוגמה אל תעשו שאילתות על טבלאות לוג שמתנפחות במליוני רשומות ביום), אבל ברב המקרים אנחנו נשקיע מאמצים גדולים בקטעי קוד שבפועל אין בהם בעיות ביצועים. את בעיות הביצועים מומלץ לבדוק באמצעות פרופיילר ובדיקות עומסים בנקודות המסירה של המוצר (ואם אתם עובדים ב - SCRUM תתקלו בבעיות בשלבים מוקדמים יחסית, ולא תתנפצו עם הבעיות הביצועים דקה לפני שאתם מגיעים ללקוח).

 קבוצות מבוזרות
אם אתם עובדים בקבוצות מבוזרות על פני הגלובוס (Off-Shore/Near-Shore), יתכן מאוד שאתם צריכים כלי שיעזר לכם. Review Board בעל הקוד החופשי יכול לעזור לכם במשימה. מדובר על כלי מבוסס Web שמאפשר לכם לשלוח ולקבל בקשות ל - Code Review, לבצע אותן ולרשום הערות, ללא צורך בנוכחות פיזית. הכלי תומך בסביבות ניהול הקוד SVN  ו - Git. בסרטון שלמטה תוכלו ללמוד קצת על הכלי ועל היכולות שלו שכוללות השוואות בין גרסאות:

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

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

 רן ממליץ על מעבר על הקוד קודם לכן בלי העמית, אבל הכל נתון לבחירתכם.

איך שומרים על ה - Code Review אפקטיבי:

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