הפעם רציתי לכתוב על משהו קצת שונה.

 

בפוסטים הקודמים דיברנו על הטעויות שרבים עושים בבחירת שיטת ניהול פרויקטי התוכנה המתאימה להם, למדנו מתי להשתמש בשיטת מפל המים (Waterfall) ודיברנו על שיטת ה - SCRUM שסוחפת את השוק בשנים האחרונות. הפעם רציתי שנשוחח על שיטה מעט שונה: פריסה מתמשכת או בשמה הלועזי Continuous Deployment. אבל לפני שנתחיל רציתי להודות לרן תבורי שחלק מהחומרים בפוסט לקוחים מהרצאה שהוא נתן במסגרת ILTechTalk.

 

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

 

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

 

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

 

 

אז איך עושים את זה?
השיטה הזאת היא אחת משיטות ניהול פיתוח התוכנה הצעירות ביותר, וחמשת השלבים למימושה נוסחו בתחילת 2009 ע"י אריק רייס:

למי זה מתאים?
השיטה הזאת מתאימה בעיקר לארגונים המספקים תוכנה כשירות (בנקים, חברות אינטרנט וכו') שבהם היכולת למסור תכונה ו/או תיקון חדש בכל רגע נתון לייצור היא בעלת ערך עסקי רב. בארגונים כאלו CD מאפשר את הקטנת עלות המלאי בתהליך ל - 0. חברות שמפתחות מוצר להתקנה אצל לקוחות יזכו ליתרון בשימוש בשיטה הזאת בכך שיוכלו להקטין את זמן האינטגרציה וישפרו את הגמישות בהחלטה על נקודת הקפאת התכולות (Feature Freeze).

 

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

 

בפוסט הבא נדבר על Case Study מהתעשייה על מימוש של פריסה מתמשכת. אין לכם חשק להמתין? תעיפו מבט על התהליך ב - Outbrain.

 

 

 

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

 

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

 

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

 

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

שילוב השיטות הללו הקרוי Lean שינה את העולם התעשייתי בשנות השישים והשבעים, כאשר המובילות באימוץ השיטה הזאת היו התעשיות היפניות בכלל ותעשיית הרכב בפרט.

 

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

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

 

 

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

 

 

 

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

 

 

נ"ב רציתי להמליץ לכם על בלוג חדש בנושאי ארכיטקטורת תוכנה של ליאור בר-און

 

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

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

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

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

 

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

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

אז מתי כן משתמשים במפל המים?

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

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

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

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

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

ממשיכים לפתח,

משה קפלן 

משה קפלן הוא יזם, יועץ ומרצה בתחום ניהול פיתוח תוכנה

טיפים והערות של קוראים

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

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

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

 

מיתוס מספר 1: כל פרויקטי התוכנה נכשלים
לא כל הפרויקטים נכשלים. אבל הנתונים של של Leading Answers שמוצגים למטה ומתבססים על נתוני Standish Group (*) מצביעים ש - 95% מהפרויקטים שנמשכים מעל שנתיים נכשלים! אלו כמובן החדשות הרעות. החדשות הטובות הן שאם נבין למה יש 5% שמצליחים, נוכל לבצע את הדברים הנכונים גם אצלנו. לשם כך נצטרך לשבור כמה מיתוסים.

 

(*) Standish Group היא חברת ייעוץ מובילה בתחום ניהול הפרויקטים הממוקמת בבוסטון. החברה אוספת נתונים על פרויקטי תוכנה מאז שנת 1994, ומפרסמת אחת לשנה סטטיסטיקות עדכניות. נתוני 2011 פורסמו בגיליון PM Network August 2011 של אגודת ה - PMI. הנתונים בגרף למטה הם משנת 2005 (לא כל כך ישן למאמר אקדמי), אבל הם בהחלט תקפים כפי שתוכלו ללמוד מהמאמר ב - PM Network וההשוואה של הנתונים הכוללים לשנים הקודמות (37% מהפרויקטים עומדים בזמן ובתקציב, 42% "מאותגרים הצלחתית" ואילו ב - 21% מהמקרים הכירו בכישלון המוחלט של הפרויקט).

 

 

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

 

מיתוס מספר 3: יש רק שיטת ניהול פרויקטים אחת והיא עובדת לכל פרויקטי התוכנה
בקורסי ניהול פרויקטים מתרכזים בעיקר בשימוש בגאנט וניהול פרויקטים בשיטה הקלאסית Waterfall. בשנים האחרונות החלו להופיע מספר שיטות חדשות שמביאות מענה לצרכים עסקיים שונים של חברות. הראשונה בהן היא מתודולוגיית ה - Agile המתמקדת בעבודה עסקית בסבבים קצרים יותר, תוך שימוש בהיזון חוזר מהסביבה (אנחנו נעסוק בה בפוסטים הבאים, אבל בינתיים מומלץ שתעיפו מבט בבלוג המצויין של אלעד סופר שעורך גם את מפגשי ה - Agile practitioners IL). מתוך מתודולוגיה זו צמחה שיטת ה - SCRUM שדוגלת בשחרור גרסאות עובדות מדי 2-5 שבועות. שיטה חדשה עוד יותר שהופיעה רק בשנתיים האחרונות היא ה - Continuous Deployment. שיטה זו מוטמעת כבר במספר חברות בישראל ודוגלת בשחרור גרסאות לייצור מסביב לשעון (או בעברית פשוטה יותר עשרות גרסאות חדשות בייצור מדי יום). השיטה הזאת מתאימה בעיקר לגופי תוכנה שמספקים שירות ללקוחות פנימיים או חיצוניים וגם בה נדון בשבועות הקרובים.

 

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

 

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

 

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

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

 

 

 

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

 

 

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

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

 

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

 

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

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

 

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

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

אז אחרי האזהרות, הגיע הזמן לצלול פנימה

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

ובכל זאת?
העולם העסקי והטכנולוגי מאיצים כל הזמן. אם בעבר התרגלנו שזמן החדירה של טכנולוגיה לשוק ארך מספר עשרות שנים (לטלפון לקח כ - 100 שנה לחדור לכל בית בארה"ב), הרי זמן זה מתקצר כל הזמן (לסלולארי זה לקח 20 שנה ולאינטרנט 10 שנים) ומגיע למספרים מאתגרים בשנים האחרונות (שנתיים לפייסבוק ו - 20 מליון משתמשים ל - Google Plus בשבועיים). משמעות תהליכים אלו היא שאנחנו צריכים להתמודד עם הצורך להגיע לשוק מהר יותר, לתקן ולחזור שוב. יתכן שהימור רחוק מדי, יתברר כהימור על טכנולוגיה ו/או פלטפורמה שלא יהיו רלוונטיים יותר בעת ההגעה לשוק.

כמה טיפים מרכזים לארכיטקטורה בריאה יותר:

טיפ 1: שמרו על פשטות
מחבר הנסיך הקטן Antoine de Saint-Exupery ניסח את זה בצורה הטובה ביותר: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away". לכן אם לוקח לכם יותר מחמש דקות להסביר את הארכיטקטורה שאפיינתם, אז כנראה שאתם צריכים לקחת אותה לסיבוב נוסף על שולחן השרטוטים. רק אחרי שתורידו את כל ההכנות למזגן, תוכלו להרגיש שהוצאתם מתחת לידיכם עבודה מושלמת.

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

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

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

טיפ 3: אולי אתם לא באמת צריכים בסיס נתונים
אחת הטכנולוגיות האהובות ע"י מהנדסי תוכנה היא ORM: Object-relational mapping. טכנולוגיה זו מאפשרת למפות ישירות ובאופן אוטומטי בין מבנה הנתונים בזיכרון (Classes) לבין הדיסק (בד"כ בסיס הנתונים). היכולת כמעט באופן אוטומטי לבצע Persistency לדיסק מאפשרת לחסוך זמן רב בפיתוח ולעיתים אף להפטר מהנטל של ה - DBA. כפי שהבנתם בפסקה הקודמת, הכיוון הזה עלול להיות מסוכן, כיוון שמבנה הטבלאות שלכם בבסיס הנתונים יהיה דומה באופן מחשיד למבנה המחלקות שלכם, וזה כאמור לא בהכרח רעיון חיובי.
אבל, אם המטרה שלכם היא אך ורק לשמור את המידע בדיסק ולשלוף אותו באותה צורה הרי ORM יהיה פתרון מצוין. מצד שני במקרה שכזה שימוש בבסיס נתונים לא יהיה בריא. איך יוצאים מהפלונטר? הבשורה החיובית היא שיתכן שאתם כלל לא צריכים את בסיס הנתונים. במקרה כזה הפתרון הנכון ביותר יהיה לבצע Serialize למידע והפיכתו לקובץ בפורמט JSON לדוגמה ושמירתו על הדיסק. מכיוון ששמירה על הדיסק ישירות היא לא בהכרח סימפטית, פתרון שמירת מידע ממשפחת ה - NoSQL יבוא לעזרתכם. מוצרים אלו שומרים את הנתונים לפי מבנה של Key/Value Store, כאשר ה - Key במקרה זה יכול להיות המפתח המזהה של רשומת המידע, והערך יהיה ה - Serialization של הנתונים.

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

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

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

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

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

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

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

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

טיפ 9: רכשו חיסון כנגד וירוס ה - NIH
מחלת ה - Not Invented Here (או בעברית "המצאת הגלגל מחדש") היא אחת מהמחלות הקשות ביותר שחברת תוכנה יכולה לחלות בה. אם אתם לא מסוגלים להשתמש במוצרי מדף קיימים או בקוד שמצאתם באינטרנט אלא חייבים לשנות הכול ולפתח הכול מאפס, יש סיכוי טוב שתתקשו להגיע ליעד. התסמונת הזאת קטלנית במיוחד במקרים שבהם אנחנו מתעקשים לפתח Cache או בסיסי נתונים ייעודיים. רכיבים אלו הינם רכיבים רגישים מאוד, והיכולת שלנו לייצר אי אחידות במידע או נעילות במקומות לא רצויים יכולה לגרום נזק גדול יותר למערכת מאשר אי השימוש בהם (אלא אם אתם פייסבוק ומחזיקים אלפי שרתי MySQL וצריכים פתרון NoSQL). לכן המלצתי, אם אתם צריכים לעשות שימוש ב - Cache ואחסון מידע, השתמשו בהם כשצריך ועל בסיס מוצרי מדף (לשם הבהרה, גם קוד פתוח זה מוצר מדף).

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

מסכימים? לא מסכימים? יש לכם טיפ מנצח? אשמח אם תשתפו את כולנו

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

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

משה קפלן הוא יזם, יועץ ומרצה בתחום ניהול פיתוח תוכנה

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

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

 

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

 

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

 

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

דרכי התמודדות המומלצות הן פיתוח מנגנונים של ארגונים שחסינים לכשל:

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

הדרך הנכונה לתגובה היא החזרת האינסטיקטים לארגון:

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

אז איך עושים את זה נכון?

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

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

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

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

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

 

 

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

 

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

 

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

 

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

 

נ"ב אם המשבר שלכם כולל בעיות מערכת ואתם לא יודעים אם מדובר על בעיה בתקשורת, ב - Web, בשרתים או בתשתיות? ב - 12/7 אני עורך סמינר מיוחד בשם Where the H#$& is My Performance Bottleneck במסגרת ה -  Expert Days 2011. מדובר סדנה בת יום אחד שבה נכנס לקרביים של מערכת Web ונבין איפה הבעייה יכולה להיות ואיך מוצאים אותה. בין הנושאים שנדבר עליהם: תקשורת בין הדפדפן לשרת, הדפדפן, שרת האפליקציה, בסיס הנתונים ותשתיות השרתים. למי זה רלוונטי? לכל מי שמנהל מערכת Web (שזה בעצם כולם) ורוצה להבין מה יכול להשתבש, ואיך מזהים במהירות את צוואר הבקבוק במערכת ומשחררים אותו.

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

 

ונקודה אחרונה... אני לא בטוח אם נשארו מקומות, אבל אם בעת הרישום תגידו שמשה שלח אתכם, תקבלו הנחה של 20% ממחיר הסדנה. איך עושים את? בעת הרישום ציינו את העובדה הזאת ואת הקוד 112 ותזכו בצ'ופר הזה. (הבהרה: ההטבה תקפה רק לסדנאות שאני מעביר במסגרת Expert Days 2011). נתראה...

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

אני לא הולך ללמד אותך איך לתכנת. יותר מכך נראה שאתה יכול להעביר הרצאה לא רעה בכלל על ניהול צוות, פיתוח ב - Java או .Net או על Design Patterns.

אבל מה הלאה?

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

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

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

אם הם יכולים, אז אתם בוודאי יכולים!
בדיוק בשביל זה קיבצתי לכם 10 טיפים שיהפכו אתכם למותג

 

1. מיקוד: לפני שאתם רצים לפרסם, לכתוב ולהרצות, שבו מספר דקות עם עצמכם ו/או אנשים שאתם סומכים עליהם והחליטו מה אתם רוצים לעשות בחיים? או יותר נכון, במה אתם באמת טובים? השאלה הזאת לכאורה נראית קשה, אבל בפועל היא די פשוטה: חשבו רגע מתי אמרו לכם שעשיתם עבודה מדהימה ואתם הפטרתם אותם באמירה שזה באמת משהו קטנטן. אם יש משהו כזה (ואני מבטיח לכם שיש) זהו הדבר שמבדיל אתכם מהשאר! זה הדבר שבו יש לכם את הערך המוסף הגדול ביותר, כיוון שאתם עושים בקלילות דברים שנראים מסובכים לאנשים אחרים. הבנתם מהו הדבר הזה? זה באמת מעניין אתכם? הייתם רוצים לעשות אותו גם בעוד חמש שנים? אם כן, אפשר לעבור לטיפים הבאים!
2. לינקדאין: מי שמחפש אותך בענייני עבודה יחפש אותך קודם כל שם, לכן רצוי לשמור על פרופיל נקי, שם תקין באנגלית (moshe kaplan לדוגמה היא צורה לא טובה, רצוי מאוד להתחיל שמות עם Capital Letters), חברות בקבוצות רלוונטיות שיציגו את תחומי העניין שלך (איך אתה עדיין לא חבר בקבוצת Agile או SCRUM?).
3. רשתות חברתיות אחרות: אמנם אנחנו חושבים על Twitter ו - Facebook כמקום שבו אנחנו מנהלים את החיים הפרטיים שלנו. אבל בפועל אם נסתכל על רשימת החברים שלנו, נגלה שרבים מהם מלווים אותנו משלבים שונים בחיים שלנו, חלקם מהחיים המקצועיים וחלקם ממעגלים עסקיים רחבים יותר. קראת מאמר טוב? יש לך טיפ מצויין? שתף את החברים שלך, ויתכן שאחד מכם יזכור את זה.
4. שיפור תוצאות החיפוש עליכם ב - Google: מתברר  ש - Linkedin הוא לא אתר הפרופילים היחיד באינטרנט. יש אתרים נוספים כדוגמת CrunchBase, VisualCV ו - ZoomInfo שמומלץ להשקיע כמה דקות כדי למלא בהם את קורות החיים שלכם. הסיבה המרכזית לעשות את זה, היא שהאתרים הללו מאפשרים לכם לעצב את תוצאות החיפוש על השם שלכם, כך שהתוצאות הראשונות יהיו התוצאות שאתם רוצים שיראו.
5. הרצאות: אתם יושבים כל היום במשרד, כותבים קוד ועושים משהו שונה. יש לפחות 5 אנשים במשרדים (או קיוביקלס) לידכם שיתעניינו בזה, ואם תהיו הוגנים עם עצמכם, כנראה שכמה עשרות אנשים בארץ שמאוד יתעניינו בזה (רב הסיכויים שאלו האנשים שיתעניינו בכישוריכם בעתיד אם תחפשו עבודה). זה יכול להיות אלגוריתם חכם, זה יכולים להיות Design Patterns שאתם מממשים בהצלחה וזה יכולה להיות שיטת הבדיקות האוטומטית שהטמעתם אצלכם בפרויקט. איך מוצאים מי יתעניין בזה? המקום להתחיל בו זה רשימת הקבוצות שציינו בפוסט מתי פעם אחרונה שדרגת את עצמך. אם לא מצאת שם, שאל את עצמך לאילו כנסים ואירועים אתה הולך, עשה בירור קצר ופנה למארגנים, רובם ישמחו להרצאה חדשה ומעניינת.
6. ארגון Meetups: גם אם אתם לא מרצים בחסד עליון, יש לכם אפשרות טובה להיות מעורבים בחיי הקהילה. בחרו את הקבוצה שמעניינת אתכם וסייעו לניהול שלה, הקשרים והשם שלכם ישתפרו בעקבות כך. לא מצאתם קבוצה מעניינת? יכול להיות שיש לכם פה הזדמנות להקים קבוצה חדשה. עשו סקר שוק בין האנשים מסביבכם והבינו אם לא טעיתם בניווט. אם אתם בכיוון הנכון כל מה שאתם צריכים זה לארגן 2-3 מרצים, חדר ישיבות גדול ולהפיץ את השמועה!
7. תרומה לפרויקט קוד פתוח: אם אתם מאמינים שמהנדס תוכנה טוב נמדד בקוד שהוא כותב, ואתם לא מאמינים בלתת הרצאות (וגם אם אתם כן מאמינים זה), פרויקטי קוד פתוח הם כר מצוין להפגנת היכולות שלכם. למה זה טוב? קודם כל אתגרים חדשים יעזרו לכם לפתוח את הראש. אם אתם מרגישים שאתם רוצים לבצע שינוי בקריירה, השתלבות בפרויקט מעין זה תאפשר לכם צבירת נסיון אמיתי. והדבר החשוב ביותר: המותג שלכם מושפע מהמותגים שעבדתם בהם, אין ספק ששורה בקו"ח ממיקרוסופט, גוגל או יאהו! עוזרת למותג שלכם. אם אין לכם את אחת מהשורות הללו בקו"ח, שורה חלופית כדוגמת Apache Software Foundation, Django Software Foundation, Drupal, Mozilla או Linux Kernel בודאי תעזור לכם. כי בינינו, מי לא ירצה להעסיק את האדם שהיה שותף בפיתוח הגרסה האחרונה של FireFox או Apache? עוד טיפ קטן, מעסיק עתידי לא יצטרך לנחש את איכות הנדסת התוכנה שלך אלא יוכל לדעת שהוא באמת מקבל את אחד המהנדסים אם לא ה... (והרי אתם לא תוכלו להוכיח לו את זה ע"י הבאת קטעי קוד מהמעסיק הנוכחי). וכן אני יודע שתתפלאו, אבל מספר גדול יותר ויותר של חברות בודק את זה כחלק ממבדקי הקבלה שלו.
8. בלוג: אם שיחה לא נמצאת אצלכם בדם, ואתם עייפים אחרי 10 שעות כתיבת קוד במשרד או שאתם דווקא יותר בענייני ניהול או ארכיטקטורה, זה המקום לשתף את התעשייה בהגיגייכם. רצוי מאוד למצוא תחומים שיעניינו את התעשייה וקהל היעד שלכם, למצוא נישה שלא מכוסה (התחום של בלוג למנהלי פיתוח כבר תפוס, עמכם הסליחה) ולבסוף והכי חשוב משהו שגורם לכם לקום בבוקר בשבילו ולכתוב עליו (אם זה מזכיר לכם את טיפ מספר 1, אתם צודקים). ראיתי כבר כמה מקרים שבהם קיום של בלוג בקו"ח הפך את המועמד ממהנדס תוכנה מוכשר ל"המומחה".
9. השתתפות בבלוגים אורחים:
1. Podcast אצל רברסים של רן תבורי ואורי להב, אם אתם לא אוהבים לכתוב ומעדיפים לדבר זה המקום בשבילכם (אני התארחתי בפודקאסט 96 על ביצועים של מערכות Web והיה מצוין).
2. טורי אורח בגלובס, TheMarker או NewsGeek יפיצו את השם שלכם בצורה נרחבת יותר. אם הצלחתם להגיע למעמד המכובד הזה, תזכו לחשיפה ואולי בעתיד אפילו לקרירה חדשה (אם אתם בעניין של אנגלית, יש מספר מקומות מאוד מכובדים שישמחו לארח אתכם).
10. Mentoring: חניכה של יזמים ומתכנתים חדשים בתעשייה היא אחת מהדרכים הטובות ללמוד תחומים חדשים, ולפתח קשרים מחוץ לארגון. באופן אישי, דווקא כשעזרתי לאנשים אחרים בפתרון הבעיות שלהם, מצאתי פתרונות לבעיות שניצבתי בפנייהן. איך עושים את זה:
1. תוכנית החניכה של Software Craftsmanship in Israel שמאפשרת לכם לחנוך מהנדסי תוכנה חדשים בתעשייה ולהקפיץ אותם דרגה.
2. השתתפות ב - Advisory Board של סטארט אפ חדש. סטארט אפ כזה לא יוכל לשכור את שירותיך כמנהל פיתוח, אבל בהחלט יוכל להנות מהכוונה ועזרה שלך. אתה מהצד השני תזכה להנות מהשתתפות בתהליך של הקמת צוות פיתוח מאפס כולל בחירת האנשים, הכלים ומגע עם הטכנולוגיות החדשניות ביותר.
3. הצטרפות לגופי מיקרו השקעה כדוגמת VentureGeeks הגופים הללו בנויים על השקעה כספית קטנה, והשקעה אנושית גדולה והם תמיד ישמחו לצרף מומחה לשורותיהם.

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

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

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

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

נ"ב: חדשות טובות! במסגרת ה - Expert Days 2011 שיערכו באמצע יולי אני עורך בפעם הראשונה שתי סדנאות מיוחדות שיכולות לעזור לכל מנהל פיתוח (וגם לכאלו שרוצים להיות כאלו):

1. הסמינר הפתוח למנהל הפיתוח: מנהלים פרויקט פיתוח: סדנה בת יום אחד שבה נדון באיזו שיטת ניהול פרויקט מתאימה לכם (התשובות תלויות במי שישתתף ביום הזה ולכן צפויות הפתעות!). בין הנושאים שנדבר עליהם: ניהול פרויקטים קלאסי, SCRUM, Agile, Continuous Deployment ו - MVP. הסדנה תערך ב - 14/7 בפארק אזורים בפ"ת. למי שירצה להתמקד בנושאי בניית צוות, אני יכול להמליץ לכם על הסדנה Leading a Software Engineering Team של אורי לביא המצויין, שתערך שלושה ימים קודם לכן.
2. Where the H#$& is My Performance Bottleneck: סדנה בת יום אחד שבה נכנס לקרביים של מערכת Web ונבין איפה הבעייה יכולה להיות? בין הנושאים שנדבר עליהם: תקשורת בין הדפדפן לשרת, הדפדפן, שרת האפליקציה, בסיס הנתונים ותשתיות השרתים. למי זה רלוונטי? לכל מי שמנהל מערכת Web (שזה בעצם כולם) ורוצה להבין מה יכול להשתבש, ואיך מזהים במהירות את צוואר הבקבוק במערכת ומשחררים אותו. הסדנה תערך ב - 12/7 בפארק אזורים בפ"ת.

ונקודה אחרונה... אם בעת הרישום תגידו שמשה שלח אתכם, תקבלו הנחה של 20% ממחיר הסדנה. איך עושים את? בעת הרישום ציינו את העובדה הזאת ואת הקוד 112 ותזכו בצ'ופר הזה. (הבהרה: ההטבה תקפה רק לסדנאות שאני מעביר במסגרת Expert Days 2011). נתראה...

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

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

1. הקטנות שמתחת לרדאר: חברות אלו לא מגלגלות מספיק כסף והנזק בהשקעה באתר גיבוי מול התשואה שהן היו יכולות לשאת בהשקעה בתכונות חדשות או שווקים חדשים בטל בשישים. לגבי החברות הללו עומד כלל שאמר לי יזם לפני כשנתיים "טוב לי להיות באמזון, כי כשמשהו יקרה, עוד 10 יותר גדולים ממני יפלו, ידברו עליהם, כולם יהיו מושבתים ואני לא אהיה חריג..." אם זה מזכיר לכם את האמירה שאף מנהל מחשוב לא פוטר כי הוא קנה IBM אתם יותר מצודקים.
2. הקטנות שגדלו: הדירקטוריון וההנהלה בחברות אלו יצטרכו לשבת כמה דקות בזמן הקרוב ולחשוב לאיזו קבוצה הן משתייכות? האם הן יכולות להשיג תשואה טובה ע"י השקעה ביכולות נוספות? או שצמצום הסיכון של השבתה חשוב יותר כי הן רוצות לשחק בליגה של הגדולים.
3. הגדולות שהתעוררו מאוחר מדי: החברות הללו מגלגלות הרבה מאוד כסף באינטרנט. המחיר הכלכלי הישיר ו/או העקיף של כמה שעות השבתה לחברות אלו גבוה משמעותית מעלות הקמת מערך גיבוי מסודר שידע להתמודד עם כשל במערכות התשתית. לשחקניות הללו האירוע השבוע יהווה קריאת השכמה. בשבועות ובחודשים הקרובים נראה פעולות נחושות של החברות הללו לסגירת הפער.
4. הגדולות שבאו מוכנות לחגיגה: החברות הללו הפנימו את עקרונות הפיתוח לענן והיו מוכנות לכשל במערכות התשתית. Netflix לדוגמה, מבססת חלקים גדולים מתשתית הפצת המדיה שלה על אמזון, ודיווחה שלקוחותיה לא נפגעו מהאירועים.

 

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

כיצד בנויה מערכת התשתית של אמזון?
לחטיבת שירותי הענן של אמזון (AWS) מרכזי מחשב ב - 5 איזורים גיאוגרפיים (וירגיניה/החוף המזרחי, צפון קליפורניה/עמק הסיליקון, אירלנד, סינגפור וטוקיו).
כל איזור גיאוגרפי כזה מתחלק למספר Availability Zones (להלן "AZ") שעל פי טענות אמזון הם בלתי תלויים אחד בשני. בפועל על פי פרסומים זרים, בכל אזור גיאוגראפי לאמזון אין יותר ממרכז מחשבים אחד, אלא ה - AZ מתבססים על תשתיות עצמאיות בתוך מרכז מחשבים פיזי אחד. מה המשמעות? כל איזור כזה מתבסס על תשתית חשמל, מיזוג, תקשורת ואחסון עצמאיות פחות או יותר. לדוגמה תשתית הניתוב הפנימית של אמזון היא ככל הנראה עצמאית בכל אזור, אבל מצד שני החיבור לשדרת האינטרנט תלוי בכמות הטבעות האופטיות שיש באזור. למה זה טוב לנו? אם מערך האחסון הפיזי באחד ה - AZ יקרוס, שאר האזורים עדיין יעבדו, מצד שני הצפת מים של המתקן כולו לא תשאיר אף אחד יבש.

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

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

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

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

1. הכנת תוכנית פעולה: גם אם אין לכם כוונה להשקיע שקל בהתאוששות של ספקית ענן, אתם צריכים תוכנית ליום פקודה: איך מודיעים למשתמשים על ההשבתה ואיך מעדכנים אותם כשהאתר או חלקו למטה. ערוצים כמו Twitter, Facebook או אפילו אתר סטטי עם שקופית תקלה יעשו את העבודה.
2. בדיקת הניירת המשפטית והביטוח: אם אתם גובים כספים מלקוחותיכם, הבטיחו כי החוזה בינכם מונע אפשרות שיתבעו אתכם בגין השבתה מעין זו. אם אתם לא בטוחים שאתם מוגנים לחלוטין, זה הזמן להרים טלפון לסוכן הביטוח ולבדוק את האפשרויות.
3. ניטור מערכות: ודאו שאתם יודעים לפני המשתמשים שלכם שהבעיות החלו כדי שתוכלו להפעיל את תוכנית הפעולה שהכנתם.
4. שיפור מוכנות: הכינו את כל אחד מרכיבי המערכת שלכם לנפילה, הפרידו את מערכות ה - Online שלכם ומערכות ה - Offline ומינעו השפעה של נפילה של רכיב אחד על רכיבים אחרים.
5. הקמת מערך גיבוי בתוך אזור גיאוגרפי יחיד: בצורה זו תוכלו להתאושש מנפילה של שרת או עומס חריג ע"י הרמת שרתים נוספים ושימוש בכלי איזון עומסים.
6. הקמת מערך גיבוי בין אזורים גיאוגרפיים על בסיס אותו ספק: במקרה הזה תצטרכו להתמודד עם עבודה מעל תווך WAN עם כל האתגרים הטמונים בכך.
7. הקמת  מערך גיבוי על בסיס ספקיות ענן שונות: במקרה הזה תצטרכו להתמודד עם אוסף של API ושירותים שאינם תואמים בין הספקיות השונות עם האתגר הטמון בכך.

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

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

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

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

משה קפלן הוא יזם ומומחה ארכיטקטורת ענן המייעץ לחברות אינטרנט וארגונים

עדכונים ותגובות של קוראים

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

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

1. כלל התקלות המדווחות הן מהאיזור של החוף המזרחי. השבתות מדווחות ממערכות ה - EBS (דיסקי ה - SAN וה - Boot from Lan) וה - RDS (בסיסי הנתונים המנוהלים), הודעות שגיאה התקבלו גם משירותי ה - Elastic MapReduce ה - CloudWatch (מערכת הניטור) וה - Elastic Beanstalk (מערכת הקונפיגורציה האוטומטית).
2. דיווחים אלו תואמים את הדיווח של אמזון שמקור התקלה הוא התקני האחסון: שני השירותים המושבתים תלויים מיידית בזמינות אחסון והקצאות אחסון חדשות, בעוד שאר השירותים נפגעים פחות מזמינות נמוכה של אחסון מרכזי.
3. אם נחקור מעט יותר בדיווחי אמזון נגלה שמקור התקלה בהתקן האחסון הוא תקלת תקשורת שגרמה לבעיות בתהליך הרפליקציה (Disk Mirroring). לכאורה אין קשר בין השניים, אבל השוואה לתקלת ייצור שהייתה באחת מחברות האינטרנט הגדולות בישראל לפני כשנה וחצי יכולה ללמד את הסיבה:
1. על מנת לשמור על זמינות המידע, אנו מחזיקים דיסקים שמשוכפלים לדיסקים אחרים, למקרה שאחד הדיסקים יפגע (בד"כ מדובר על שני התקני אחסון מרכזי שמגבים אחד את השני).
2. תהליך ההעתקה מבוצע ע"י יצירת קבצי דלתא. קבצים אלו מועתקים מדיסק הראשי לדיסק הגיבוי.
3. בשגרה העתקת הקבצים מתבצעת מיידית ואלו נמחקים מהדיסק הראשי.
4. במקרה של נתק, הדיסק הראשי (בד"כ התקן האחסון המרכזי) צובר את קבצי הדלתא על מנת שהוא יכול להשלים את הפערים בדיסק הגיבוי כאשר נתק התקשורת יסתיים.
5. במקרה שהנתק נמשך זמן רב מדי, התקן האחסון המרכזי צורך את כל נפח האחסון הנותר במכונה ע"י קבצי הדלתא ולבסוף גורם לקריסתה כאשר לא נותר מקום במכונה.
4. דיווחי המהנדסים של אמזון על הצורך בהכנסת דיסקים נוספים למכונות והמתנה עד לסיום הרפליקציה תואמים גם הם את ההשערה כי זה המקרה שקרה גם כאן: על מנת להעלות את המכונה לאחר הקריסה נדרשים דיסקים נוספים, ובנוסף כל עוד תקלת התקשורת לא נפתרה נדרש גם שטח נוסף לצבירת קבצי הדלתא. ניתן גם להבין מתהליך זה מדוע הנפגעים הראשונים היו לקוחות שנדרשו לדיסקים חדשים.
5. לסיכום ניתן ללמוד מהתהליך שקרה שני דברים: 1) כיצד גם פתרון HA יכולים לגרום לנפילות (ואפילו חמורות), ו - 2) כיצד ההיסטוריה חוזרת על עצמה גם בשחקניות ענן וגם בשחקניות מסורתיות יותר. נותר לי לקוות ששתי השחקניות לא עשו שימוש באותם התקני אחסון, כיוון שאז זה יהפוך מחוסר מזל לסיפור עצוב.

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

העדכון של אור: השתלשלות העניינים והרשימה המלאה של החברות שנפגעו (וסיפרו על זה)

תקציר התחקיר המלא של אמזון שפורסם ב - 29/4/2011: התקלה החלה מתקלת ניתוב בנתב הליבה (או מתג L3 של רשת האחסון) בעת שדרוג הרשת ב - DC של החוף המזרחי. כתוצאה מהתקלה בקרי האחסון לא הצליחו למצוא את התאומים שלהם והפסיקו להגיב (וזאת מכיוון שהם עובדים ב - Sync Mode שמחייב קבלת Ack מהתאום לפני שניתן יהיה להמשיך בפעילות על הדיסק). עוד מסקנות מהתחקיר הן שלאמזון יש DC אחד ככל הנראה בחוף המזרחי, ושההפרדה בין ה - AZ לא מלאה אלא יש תלות בינהם.

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

 

 

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

 

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

 

 

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

 

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

 

נ.ב ביום שלישי הקרוב, בשעה 18:00 יערך מפגש אלפאגיקס ה - 9. אם אתם מהנדסי תוכנה (וסביר להניח שזה המצב אם אתם קוראים את הפוסט הזה) ומעניין אתכם איך עובד שיווק באינטרנט, איך זה משפיע על צורת הפיתוח שלכם ואיך בעצם עושים כסף מהקוד שלכם, אתם מוזמנים להצטרף. בתוכנית: איך עושים SEO ואיך זה משפיע על הקוד, איך עושים A/B Testing וסיפור אמיתי על איך מצליחים לשווק אפליקציה ב - AppStore.

האירוע עלינו, והאוכל עליכם, אם זה מעניין אתכם תעשו RSVP באירוע בפייסבוק.

שלכם,

אנשי האלפאגיקס. תודה לכל מי שהשתתף! וידאו ומצגות יועלו בקרוב :-)

 

Redmine הוא כלי מדהים (מבוסס רובי) אשר מנהל משימות, וויקי וניהול קבצים פר פרויקט. לכלי אינטגרציה מעולה ל - source control – גיט וכדומה, עם יכולת לראות Commits ו - Diff וויזואלי של ההבדלים בין גרסאות.
אנו עובדים עם רדמיין כבר יותר מ - 3 שנים. לאחרונה הרצאתי על מספר פלאגינים מתקדמים שלו ועל השימוש שלנו בהם בדרופלקון בשיקאגו – מומלץ!

 

הטיפ של ישי סמיט

 

רצוי לשים לב לכלי Review Board (ביחוד בקבוצות מבוזרות) לצרכי Code Review. פרטים מלאים על הכלי וסרטון בפוסט אז מה היה לנו?

 

ההבדלים בין Git לבין Mercurial קטנים יחסית. לעומת ההבדלים בינם ל – SVN משמעותיים יחסית וזאת מכיוון ש - SVN עובד בצורה מרכזית, ואילו האחרים בתצורה מבוזרת. למרות זאת במאמר מוסגר אני אומר שפרויקט האחרון שניהלתי, בחרנו לעשות שימוש בפתרון מבוסס SVN שהיה דומה מאוד למהותו לקונספט של Git (כל אחת מהמפתחים עובד על Branch משלו שאליו הוא מבצע Commit לכל אורך הדרך גם אם הפתרון לא יציב. רק לאחר שהתכונה החדשה או תיקון הקוד בשלים הם מאוחדים לתוך ה – Trunk). היתרון הגדול לצורה המבוזרת היא היכולת של כל מפתח לבנות לעצמו ארגז חול שבו הוא יכול להרוס את הקוד כאוות נפשו, ורק כשהעסק בשל להכניס את זה לייצור. מתלבטים
ישנם מספר פוסטים טובים על הנושא, כולל פוסט על ניהול קוד מבוזר של זהר ארד שכתב גם פוסט מצוין על כלי ניהול פרויקטים.

ישנם מספר מקומות שמשתמשים בארץ ב – Mercurial, אבל Git באופן עקרוני נכנס יותר טוב לתעשייה, ולכן הייתי ממליץ לך לבחור בין SVN ל – Git.

 

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

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

 

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

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

 

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

 

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

 

איך מכשירים (או יוצרים תרבות ארגונית)?
הבנו שתהליך הגיוס הוא שלב ראשון בבניית התרבות הארגונית. השלב השני הוא ההכשרה: בגוגל שולחים אותך ללא נודע ומכניסים אותך לתרבות הארגונית ע"י ביצוע Code Review אינטנסיבי לכל שורת קוד שכתבת. בפייסבוק מסע החניכה מבוצע ע"י טירונות, שנמשכת ארבע עד ששה שבועות. טירונות זאת כוללת הרצאות וטרטורים בדמות פתרון באגים במערכות החברה. במהלך הטירונות כ - 10% מהמשתתפים נושרים, ואילו הנותרים מקבלים כומתה.... סליחה... הרשאות לבסיס הנתונים האמיתי...
השלב השלישי הוא שמירה על שקיפות: גם בגוגל וגם בפייסבוק כל מהנדס יכול לגעת בכל חתיכת קוד במערכת ולבצע Check In. התרבות הזאת קיימת גם בחברות אחרות דוגמת Red Hat. בכל מקרה, כל שורה עוברת Code Review.
השלב הרביעי הוא Dogfooding: כמו בגוגל גם בפייסבוק עושים שימוש אגרסיבי בכלי הזה. עובדי החברה עובדים תמיד על גרסה שמקדימה בשעה עד שתיים עשרה שעות את הגרסה שזמינה למשתמשים החיצוניים.

 

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

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

 

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

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

 

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

 

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

 

נ.ב בימים אלו אני מתחיל בהרפתקאה חדשה. בינתיים אם אתם מעוניינים בייעוץ על ארכיטקטורה של מערכות אינטרנט וענן, יישום של מענה Scaleout, ייעוץ ניהולי או עזרה בהאצת הביצועים של המערכת, אתם יותר ממוזמנים לפנות: mokplan[at]gmail[dot]com.

 

השאלה של קארן שליין:

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

 

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

אחד הדברים החשובים כאשר אנחנו מקימים סטארט אפ חדש או פשוט כאשר אנחנו רוצים לשדרג, הוא ללמוד איך הטובים ביותר עושים את זה (חברת ייעוץ היתה מוכרת לכם את זה תחת המותג Best Practices). גוגל היא בהחלט מקרה מצויין ללמוד ממנו ולכן הפוסט יתמקד בפילוסופיית הפיתוח והניהול של גוגל. הפוסט מתבסס על הרצאה של  Miki Herscovici על מוצר ה - Google Instant Search, שיחות רקע ובלוגים באינטרנט. בעתיד בודאי נקדיש פוסט דומה לתהליך הפיתוח במיקרוסופט.

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

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

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

1. התחלה מרעיון פשוט: הרעיונות בגוגל מגיעים בד"כ מהמהנדסים, אבל לא בהכרח. תהליך ניהול ההמצאתיות מתנהל בצורה מובניית באמצעות כלי בשם Google Ideas שמשמש להפצת רעיונות, דירוג, שיתוף ומדידת באזז. כלי זה מאפשר להתחיל להריץ רעיונות בצורה מהירה ע"י אנשים שונים מקצוות שונים בחברה.
2. ביצוע Mock: אוסף של Story Boards שמציגים את האינטראקציה בין המשתמש למחשב. איך עושים את זה? כל דבר מקשקוש על מפית דרך Photoshop וכלה בסיוע ממעצבי ממשק המשתמש בגוגל מתקבל בברכה.
3. אב טיפוס (Prototype): פיתוח מוצר מנוון שיתכן שיאפשר הבנה טובה יותר של המוצר, היכולות שלו, המגבלות שלו והאתגרים שטמונים בו. לדוגמה במקרה של Instant Search, אב הטיפוס של המוצר ביצע עבור כל הקלדה גישה לשרת לשם הבאת תוצאות החיפוש הרלוונטיות.
4. Explorations: אחרי שבנינו אב טיפוס, הגיע שלב המשחק עם האב טיפוס. המטרה: ללמוד עד כמה המוצר באמת טוב. שתי השיטות שבהן משתמשים בגוגל הן:
1. Dogfooding: בעברית:  נותנים לאנשים שפיתחו את המוצר לאכול את הדייסה שהם בישלו: מפיצים את המוצר בתוך החברה ונותנים לאנשים להשתמש בו. הבעייה בשיטה זו שעובדים בחברות הם על פי רב הומוגניים ולעיתים לא תואמים את קהל היעד, במקרה של גוגל מי שנותן את הרעיונות ואת ההערות הם בד"כ המהנדסים שנמנים על אוכלוסיית ה - Hyper IT Savvy שנוטה להתעלם מבעיות Usability.
2. Usability Studies: הפצה לקהילה הטרוגנית (או הומגנית שתואמת את קהל היעד של המוצר) ע"י הושבתם על יד מחשב ובקשה לקבל פידבק. דוגמה: ב - Instant Search השיטה הזו שימשה להבנת אופן התגובה של משתמשים להשלמה האוטומטית: המשתמשים הקליקו עד שראו באפור מה שהם מצפים, ואז אוטומטית הורידו את העיניים לראות את ההמשך.
5. החלטות (Decisions. Decisions. Decisions): קבלת החלטות ברמה הבכירה ביותר לסגירת הדרישות (LockOut). מהיכרותנו עם מוצרי גוגל, כנראה שהדבר העיקרי שמבוצע בשלב זה הוא הריגת תכונות מיותרות ושמירה על מינימאליזם.

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

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

1. הבנה של עולם האינטרנט: בעולם האינטרנט כמויות המשתמשים והטרנזאקציות היומיות גדולות משמעותית מאלו שבמערכות ארגוניות. לדוגמה במקרה של חיפושים מדובר על מליארדי פעולות ביום: לכן מימוש נאיבי של Instant Search שיניב קפיצה של פי 20 במספר החיפושים הוא בלתי אפשרי מבחינה תפעולית ותקציבית ולכן נדרש לבצע תהליך אופטימיזציה מסודר שיביא את הגידול במספר החיפושים למספר סביר.
2. הבנה של זמן התגובה: כל אלפית שנייה מתרגמת לחווית משתמש וכסף בבנק, לכן הדרישה של Google Instant Search היא הגעה ל - RTT של 0.25s (ואנשי המוצר ממשיכים לדרוש לחתוך במספר הזה).
3. הבנה של השוני: עולם האינטרנט כולל סוגים שונים של דפדפנים בגרסאות שונות ולכן מחייב לפני היציאה מאמץ גדול על מנת לתמוך בשיטות השונות שמקובלות בדפדפנים השונים על מנת להמנע מגליצ'ים.

פוליש בשלב זה מבצעים ניקוי אחרון לפני סיום וגורמים למוצר להיראות כפי שמוצר צריך להיראות (ראו ערך Suck Factor)

שחרור ואיטרציות
החלק העיקרי בחיי המוצר שבו מבוצע שיפור המוצר ומענה ללקוחות על בסיס האינטראקציה שלהם עם המוצר.

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

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

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

1. כל אדם הוא ראש צוות של עצמו
1. ניהול Bottom Up: שולחים את האנשים לעשות מה שהם רוצים, ללא ביצוע Micro Management.
2. ציפייה ותרבות ארגונית: כל אדם ימצא את האנשים שהוא צריך לעבוד מולם.
3. בניית עניין: התפקיד שלך זה לעניין קבוצה גדולה שתהיה מעוניינת בזה ולהקים קונצנזוס מסביב למוצר ו/או הרעיון שלך.
2. פתיחות
1. כל אחד (כמעט בחברה) יודע מה (כמעט כל) האחרים עושים, דבר שמאפשר לתת פידבק מצד אחד, ומצד שני לגלות שאחרים עושים דברים דומים אפילו ברמת מקטעי קוד.
2. שקיפות מירבית: כל אחד מציג מטרות וצריך להצדיק את הפעילות שלו.
3. תהליכים דינאמיים
1. הדינמיקה מונעת מבנה סטטי מדי, ולמעשה מונעת יכולת לשמור על מבנה קבוע.
2. עבודה בתצורת Agile באיטרציות קצרות. ועל ידי כך המנעות מבניית תוכניות לשנתיים קדימה שמחייבות תכנון מחדש כל מספר חודשים.
4. תשתיות מסודרות
1. סטנדרט קוד אחיד מאפשר לכל אחד להבין את הקוד שנכתב בכל פרויקט אחר.
2. עבודה על בסיס קוד אחד שפתוח לכולם המאפשר משלוח תיקונים לצד השני של העולם, ללא מלחמות אגו.
3. גרסת קוד אחת: דבר שמונע תחזוקה של גרסאות שונות עם באגים שונים ומאפשר מיצוי של המאמצים.
4. מערכת Continuous Integration מתוחכמת, שמבצעת Build  ולאחר מכן מזהה עבור כל חתיכת קוד ששונתה, מה הושפע ממנה, ועל בסיס זה מריצה את הבדיקות הנדרשות על אלפי מכונות במקביל. התוצאה היא אחוז שבירת קוד נמוך יותר (ואם הקוד נשבר, צפו לטלפון גם בשתיים בלילה).
5. Review
1. תהליך ה - Review מתחיל עוד בשלבים המוקדמים ביותר של הפרויקט באמצעות סקרים לא פורמליים. לדוגמה בעת הגיית הרעיון, ממציא הרעיון נדרש להציג אותו ולקבל חוות דעת: אנחנו מתכוונים לעשות X, מה דעתכם?
2. כל הכנסת שורת קוד מלווה בתהליך של (Code Review (CR על ידי בעלי הקוד. למעשה במקרים קיצוניים תהליך ה - Code Review יכלול עד 7 סבבים שונים עם אנשים שונים בחברה.
3. לגוגל יש מערכת תשתיתית מסודרת לביצוע CR כך שניתן לבצע אותה מכל אזור בעולם ללא צורך בשיחה פנים אל פנים.
4. לכל חתיכת קוד יש בעלים אחד או יותר. כדי להכניס שינוי צריך לעבור CR אצל הבעלים. החלטה על הכנסת שינויים מבוססת על שכנוע בין השאר ע"י מדידה של השיפור בין הגרסאות.
5. השילוב של תשתיות מסודרות, מניעת הכנסת קוד ללא ביצוע CR והעובדה שהקוד שלך חשוף לעיני כל מאפשרת ביצוע Reuse מקסימלי.
6. הנהלה חזקה כולל החלטות אילו פרויקטים צריכים להמשיך ואיזה לא.
7. הערכה שנתית שמובססת יותר על הערכות העמיתים שלך מאשר על הערכת הממונה.
6. איכות
1. גוגל מתנהלת עם מספר מצומצם מאוד של בודקי תוכנה. למעשה רב בדיקות האיכות מתבססות על קוד בדיקה שכותבים מהנדסי התוכנה על מנת להשיג יעד של 70% כיסוי קוד.
2. בדיקות לפני העלאת גרסה מתבצעות גם הן ע"י מהנדסי התוכנה. לעיתים הבדיקות מבוצעות אף בצורות שמפתיעה כשחושבים על חברה בגודל שכזה (חשבתם על בדיקה על בסיס האתר הפרטי של אחד מחברי הצוות? צדקתם!).

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

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

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

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

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

נ"ב: רוצים ללמוד עוד שיטות, אתם מוזמנים להעיף מבט על ההרצאה של Sky.com.

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

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

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

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

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

איך עושים את זה?

1. Scale Out: הרעיון העומד בבסיס תפיסה זו הוא ששרת חזק פי 4 עולה פי 16. לכן כאשר נרצה לתמוך בפי 4 משתמשים נרצה לעשות זאת באמצעות 4 שרתים זולים ולא באמצעות שרת גדול יותר.
2. Sharding: מידע הוא בד"כ צוואר הבקבוק במערכות תוכנה, וזאת מכיוון שאפיון קלאסי של מערכות מרכז את כלל המידע בנקודה אחת (יש כאלו שקוראים לזה בסיס נתונים או Database). אם זה המצב אצלכם, בחרו במה שהגדולים כבר עשו לפניכם: בצעו Sharding לבסיס הנתונים שלכם, ללא תלות אם מדובר ב - MySQL או SQL Server.
3. In Memory Databases: שימוש בזיכרון מהיר פי 5-10 משימוש בדיסק. לכן אם אתם יכולים לבצע פעולות בזיכרון כמו צבירה של צפיות במודעה ולרדת לדיסק רק פעם בכמה שניות, זאת יכולה להיות אסטרטגיה מצויינת. זהו פתרון מצויין גם במקרה שאתם יכולים להתמודד עם אובדן של מספר שולי של טרנזאקציות. במקרה שאתם לא יכולים להתמודד עם כזה אובדן, שימוש ברפליקציה של הזיכרון בין שרתים שונים יכולה לתת את המענה הרצוי.

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

הגדירו אסטרטגיית יציאה (Exit Strategy)
אתם חייבים לזכור שספק מחשוב הענן שבחרתם (Cloud Operator) הוא ספק ככל ספק אחר. יתכן שהשותף המצויין שלכם כשהייתם מערכת קטנה יהפוך למכשלה כאשר אתם בעצמכם תהפכו לענק. לכן בחרו בזהירות את הפתרונות הטכנולוגיים שבהם אתם משתמשים מתוך מבחר הכלים אותם מציע ספק מחשוב ענן. לדוגמה, אני ממליץ לחשוב פעמיים לפני בחירה בפתרון שמירת מידע קנייני כדוגמת ה - SimpleDB של אמזון. במקרה שאתם בוחרים בכלים מסויימים, הקפידו לייצר ממשק שיעטוף את הכלי וודאו שיש לכם תוכנית יציאה למקרה הצורך.

ומה אם אני מומחה מיקרוסופט?
בוודאי שמעתם כבר שכולם מפתחים ב - Open Source. גוגל עושה שימוש אגרסיבי ב - Python, פייסבוק עושה שימוש ב - PHP וטויטר בכלל דוגלת ב - Ruby.
כמו שכתבתי לפני כן, ההמלצה שלי היא להתחיל עם מה שאתם מכירים. יש כיום ספקי מחשוב ענן רבים שמספקים פתרונות של Windows+.Net. כאשר תגדלו, תוכלו להחליף את אותם מנגנונים שמהווים 20% מהקוד שלכם ומייצרים 80% מעלויות המחשוב שלכם לפתרונות חלופיים כדוגמת Erlang ל - Push ו - LAMP ל - Web ולשמור על עלויות סבירות.

ומה עם איזה טיפ של אלופים?

1. CDN: הוציאו את התוכן הסטטי של האתר (תמונות, עמודי HTML וסרטונים) ו - Streaming Media לספק CDN. המהלך הזה יקטין את תעבורת הרשת, ניצולת השרתים וישפר את חווית המשתמש של האתר שלכם.
2. משתמשים חכמים: הפכו את האפליקציה שלכם לבעלת מודעות לבעיות ברשת ונצלו אותה להתגבר על נפילות. אם השתמשתם ב - Gmail וקיבלתם הודעת Loading... במקום עמוד 404, אתם בודאי יודעים למה אני מתכוון (ואם לא, גגלו על JQuery)
3. גידול אלסטי: אם צריכת המשאבים שלכם לא אחידה לאורך שעות היום ו/או לא צפויה, נצלו את היכולת של להעלות שרתים ולכבות אותם על מנת לשמור על ההוצאות נמוכות ולתת מענה לשיאים בדרישה גם אם הם רגעיים.
4. רפליקציה: אל תשכחו לגבות את הנתונים גם בגיבוי קר וגם בגיבוי חם. אבל אל תשכחו לעשות את זה גם באמצעות חומרה ותוכנה בסיסיים.
5. התכוננו להשבתות ושדרוגים. במערכות ענק תמיד יש תקלות. וגם הבלתי צפוי תמיד יקרה ושרתים יפלו, יכשלו ויהיו תקלות. לכן התכנון שלכם צריך להיות בנוי שגם במקרה של שדרוג תוכנה, לעולם, לא כל האתר ישובת.
6. NoSQL: התחילו עם בסיס נתונים סטנדרטי (SQL בעברית). כאשר תתחילו לספוג עומסים בבסיס הנתונים, זהו מה מהנתונים מתאים לאחסון לצרכי OLTP בתצורה של Key-Value וישמו עבורו פתרון NoSQL.

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

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

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

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

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

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

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

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

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

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

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

1. חברת NetApp היא אחת מחברות האחסון הגדולות ביותר בעולם. החברה מוכרת מוצרים המבוססים על ארונות של  דיסקים קשיחים וידועה מתחילת דרכה בכך שהיא מוכר "ראש חכם" אשר תומך בגדלים שונים של אחסון, ובתכונות שונות וזאת רק ע"י הכנסת רשיונות תוכנה המאפשרים אותם וזאת ללא צורך שינוי החומרה של ה"ראש החכם".
2. חברת Radware, שעל פי מקורות זרים מועמדת למכירה ל - IBM ו - HP לפי שווי של מליארד דולר, מתמחה בהתקני תקשורת בכניסה למרכזי מחשבים. פתרון ה - OnDemand Switch שהחברה הציגה לפני כשנתיים, פועל בצורה דומה, התקן התקשורת נמכר במחיר ראשוני נמוך עבור תמיכה בנפח תקשורת נמוך יחסית. עם הזמן הלקוח יכול להוסיף יכולות נוספות או להגדיל את נפח התקשורת הנתמך וזאת ע"י הכנסת רשיון תוכנה בלבד ללא שינויי חומרה.
3. מערכות SaaS כדוגמת Gmail מבוססות על מתן פתרון ראשוני בחינם ו/או במחיר נמוך, כאשר המגבלות (מספר משתמשים, נפח אחסון וכו') משוחררות תמורת מחיר אטרקטיבי יותר או פחות. דוגמה טובה היא חברת Kampyle אשר מספקת פתרון חינמי לקבלת תגובות ממשתמשים באתר ונותנת פתרון חינמי (שומחבא בתחתית העמוד) וסדרה של תמחירים שהבדל העלויות בינהם מבחינת החברה מזערי, אבל מבחינת השורה התחתונה משמעותי מאוד.

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

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

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

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

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

איך מצמצמים סיכון?

1. מגדילים את ההשקעה ב - QA בפרק הזמן הרלוונטי.
2. מייצרים מומנטום של הצלחה.
3. חושפים את היתרונות כלפי חוץ, כולל שיקוף של ההצלחות והצגה של תכונות חדשות שנוספות למוצר ושידור של היתרונות לאנשי השיווק והמכירות. קבלת הרוח הגבית מגורמים אלו, תסייע להקטין התנגדויות בשל חוסר יציבות ו/או ירידת איכות שיכולות להתלוות לתהליך. אם אנשי השיווק שלכם ממוקדים ביכולות עתידיות, הסבירו להם כיצד הפיתוח הבא ימומש לשני המותגים במקביל תוך חסכון של 40-50% בזמני ועלויות הפיתוח.

למה HTML5 הולך להצליח בגדול?
בד"כ אני לא נוטה לקחת הימורים, אבל אני מאמין גדול בהצלחתו של תקן ה - HTML5. מה הקשר של זה לפוסט?
אחת הבעיות הקשות ביותר בפיתוח למערכות מובייל כיום הוא ריבוי פלטפורמות הפיתוח, עבור Symbian תידרשו לכתוב ב - C או ב - Java, עבור BlackBerry ו - Android ב - Java, עבור iPhone תאלצו ללמוד Objective C ואם מיקרוסופט תצליח עם Windows Phone תאלצו להתמודד גם עם Silverlight. אם יש לכם תחושה שתאלצו להמציא את הגלגל לפחות 5 פעמים אתם צודקים.
מה היה קורה אם יכולתם לפתח פעם אחת לכל הפלטפורמות? כנראה שתראו ירידה של 80% בעלות תחזוקת התוכנה למוצרי ה - Mobile שלכם.
HTML5 יתן את פתרון הקסם הזה, ולכן הוא ידחף באגרסיביות ע"י גופי פיתוח התוכנה, שהפתרון הזה יחסוך להם עלויות גדולות.

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

מה האסטרטגיה שלכם? מה היתרון שאתם יצרתם? האם ניהלתם מהלך של מיזוג? שתפו אותנו...

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

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

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

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

 

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

 

כולם יודעים לעשות Code Review?
אנחנו בחרנו בשימוש שיטת ה - Peer Review שמאפשרת עבודה במבנה ארגוני שטוח ופתוח יותר. על מנת להפוך את השיטה ליעילה הזמנתי את אורי לביא, סמנכ"ל הפיתוח של PicScout, ומייסד קבוצת ה - Software Craftmanship in Israel להרצות לאנשי הפיתוח על Code Review, איך עושים את זה נכון? ממה צריך להמנע? ולמה צריך לשים לב?
ההרצאה נערכה במשרדי החברה כחלק מתוכנית החלפת ההרצאות ILTechTalk@, שאליה אתם יכולים להרשם, להזמין הרצאות שאתם מעוניינים בהן, לבוא להקשיב להרצאה או להציע הרצאה בתחום המומחיות שלכם, והכל ללא תשלום (אם אתם מתעקשים, אתם ממש לא חייבים להרצות כדי לקבל הרצאה אצלכם במשרד).
ההרצאה התמקדה בפיתוח מונחה עצמים, אך כמובן שכל אחד מכם יכול להתאים את תוכן הטיפים לצרכיו.

 

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

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

Software Craftsmanship - 2

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

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

 

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

 

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

 

נ"ב ביום שני (היום) יערך מפגש נוסף של ה - Software Craftmanship in Israel. אתם מוזמנים.

 

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

 

הטיפים של רן תבורי (מתוך ההרצאה באומני התוכנה, המצגת המלאה זמינה ב - http://bit.ly/scilcodereview):

מי יכול לעשות Code Review:

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

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

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

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