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

 

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

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

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

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

 

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

 

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

 

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

 

 

 

"שיטת סרג'יו לכיבוש מהיר בשלושה תשלומים"
הגדרנו לעצמנו שלשה שלבים עיקריים בגיבוש התכנית החדשה:

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

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

 

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

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

 

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

 

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

 

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

בפתיחה הצגנו פתחנו בהסבר כללי קצר שכלל:

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

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

 

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

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

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

 

 

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

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

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

אם נוסיף על כך את נטיית השיווק לשלב מאפייני Social באתרים ולייצר קמפיינים משולבי Offline ו - Online (כדוגמת קמפיין המסלולים של ישראכרט), אנחנו יכולים לגלות שגם האתר התמים של אתמול הופך לפוטנציאל לבעיות ביצועים. והרי אף אחד מאיתנו לא רוצה להגיע לעמוד הראשון בעיתון ב Ynet, TheMarker ו - BizPortal... (יכול שאתם רוצים אבל לא בנסיבות הללו).

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

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

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

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

יש! יש לנו צורך עסקי. מה עושים?
קודם כל מזל טוב!

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

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

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

Mike Krieger, Instagram at the Airbnb tech talk, on Scaling Instagram

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

1. מהם רכיבי המערכת? בארכיטקטורה העתידית שנבחר (גם אם נפתח מחדש וגם אם נבצע Refactoring) רצוי שנגיע לתצורה שבה רכיבי המערכת מופרדים וחסרי תלות. בצורה כזו ניתן יהיה לשלוף ולהחליף אותם במקרה הצורך (מישהו אמר SOA בקהל?).
2. מהם התהליכים העסקיים במערכת ומה רמת אינטסיביות השימוש בכל אחד מהם? ברב המערכות ישנם תהליכים עסקיים שקורים פעמים ספורות וכאלו שאחראים ל - 99% מהפעולות במערכת (לדוגמה במערכת לניהול משכנתאות, פתיחת תיק משכנתא מתבצעת פעם אחת ואילו הגבייה מתבצעת מדי חודש בחודשו). מניסיוני ההתפלגות קיצונית בהרבה מפארטו (80/20).

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

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

1. זיהוי והגדרת הסף הקריטי לכל רכיב במערכת: הדרך הטובה ביותר היא בניית בדיקת עומסים לכל רכיב קריטי שתוודא לפני מסירה של כל גרסה שהרכיב יכול להתמודד עם העומסים הרלוונטים. אזהרה! אם המערכת לא מורכבת מסדרה של רכיבים בדידים, היכולת לבצע בדיקת עומסים אפקטיבית היא כמעט ובלתי אפשרית. אם אין לכם אפשרות לבנות בדיקת עומסים אפקטיבית, תדרשו לנטר בזהירות את צריכת המשאבים של המערכת ולזהות מאפיינים כמו תעבורת רשת, צריכת I/O, CPU וזיכרון ולזהות מתאם ביניהם לבין הפעילות במערכת (לדוגמה אם כל משתמש מחייב 0.5MB RAM, כנראה ששרת של 2GB יוכל לתמוך לכל היותר ב - 4,000  משתמשים).
2. שילוב מערכת ניטור והתראה: מערכת זו תמדוד את צריכת משאבי המערכת שתוארו קודם ואת התהליכים הקריטיים כדוגמת מספר העסקאות בשנייה (בדיוק כמו שתארתי בפוסט על Continuous Deployment) ותתן התראה בעת התקרבות על הסף. אל דאגה, אין צורך בפיתוח מערכת ניטור משלכם או החזקה של מספר מערכות ניטור. כל מה שתדרשו הוא לקרוא ת ה - API של מערכת הניטור שבה אתם משתמשים ולחשוף את הנתונים בצורה מתאימה.

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

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

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

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

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

נ"ב אם נתקלתם בבעיית SEO באתר מבוסס AJAX (כולל שימוש ב - Widgets של ספקים חיצוניים), אני אשמח אם תיצרו איתי קשר.

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

 

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

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

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

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

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