לעשות את זה כמו גוגל

22 בינואר 2011


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


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


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


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


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


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


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

כתיבת תגובה

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

9 תגובות

  1. Tamir31 בינואר 2011 ב 23:26

    איפה פה הלייק?
    אהבתי

    הפוסט אינפורמטיבי (בהנחה שהמידע הפנימי של גוגל שהבאת אכן מהימן) ונתן לי כמה רעיונות מעניינים בנוגע ל- Agile, Continuous Integration ** ו – Best practices (ואני לא מחברת ייעוץ)

    ** לפני כמה שבועות העברתי webinar בעברית, ללקוחותינו, שעסק ב- Agile ו – Cont. Integration
    למעוניינים, ניתן לראות אותו כאן:
    http://bit.ly/i2vevO

    הגב
  2. Moshe Kaplan31 בינואר 2011 ב 23:56

    תודה תמיר,

    הלייק למעלה 🙂

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

    תודה על תוספת המצגת, אני מקווה שבקרוב נייחד פה פוסט על נושא ה – Cont. Integration

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

    הגב
  3. ניר רוטשטיין1 בפברואר 2011 ב 10:35

    מעניין מאוד, תודה.

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

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

    הגב
  4. Moshe Kaplan1 בפברואר 2011 ב 11:32

    שלום ניר,

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

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

    הגב
  5. רומי3 במרץ 2011 ב 14:36

    אהבתי 🙂
    כמה הערות:
    1. הרסו לך את ההסחה של תתי-הסעיפים בניוזגיק, לכן קשה לשים לב מה תחת מה.
    2. בבליוגרפיה? מאיפה לקחת את כל הנתונים על גוגל?
    3. הרחבת ניסויים לצוות פיתוח: אחרי שמפתח אחד עבד על פרויקט בזמנו החופשי והפרויקט מתרחב, כיצד מצטרפים אליו אחרים?
    4. בדיקת אב-טיפוס על חלק ממשתמשי האינטרנט, אם בדחיפה, ואם באיפשור ב-labs.
    5. כשמקימים סטרטאפ, איך גודלים תוך כדי שמירה על העבודה בצורה שטוחה בכל השלבים?
    6. תסכול של עובדים, גם בגוגל, מכך שהם לא יכולים לעשות מזלג אלא חייבים לקבל אישור מ-7 גורמים לאישור בקוד.
    7. תסכול של עובדים, בגוגל, מכך שיוצא להם לעבוד על 3-4 פרויקטים כושלים עד שהם מגיעים לאחד מוצלח.
    8. הקבלה לשב"כ שבו, לפי עובדה עם אילנה דיין, יש לוחם, מפקד, וראש השב"כ – כנ"ל ארכיטקטורה שטוחה, גם אם לא של מהנדסים.
    9. נהלים להקצאת משאבים לניסויים של מהנדסים – אישור של איזה דרג צריך כדי לרכוש 100 שרתים בשביל מהנדס עם רעיון בזמנו הפנוי?
    10. האם באמת כולם בגוגל עובדים באותה שפת תכנות ובאותם כלי פיתוח?

    הגב
  6. Moshe Kaplan3 במרץ 2011 ב 21:47

    הי רומי,

    תודה על ההזדמנות לענות:
    1. מה לעשות, זה מחיר התהילה 🙂
    2. הנתונים על גוגל הם מתוך שיחות עם אנשי גוגל, הרצאות וכו', המיעוט מתוך חומר כתוב
    3. תהליך ה – 20% די מובנה, זה לא שכל אחד מפתח את הפרויקט שלו ב – 20%, אלא שאתה מחליט על מה אתה עובד (וזה יכול להיות גם רעיון שאתה המצאת), ההצלחה של פיתוח הרעיון שלך תנבע גם מההשקעה שלך וגם מהבאזז שהצלחת לעשות. אחרי שצולחים את מבחני המוק המוצר הופך למוצר אמיתי ולא רק פרויקט.
    5. כנראה שאי אפשר לשמור על עבודה שטוחה בכל השלבים, ככל שאתה נהיה גדול יותר, העסק נהיה גדול מדי לניהול שטוח לחלוטין. הדרך לשמור על זה שטוח היא בניית תרבות, קוד אחד פתוח בכל החברה, העברת ידע וכו'… בעצם זה די מתואר בפוסט…
    6. בנושא התסכול, אתה צודק זה יכול להיות די מתיש. מצד שני אם תזכה לשנות את ה – GFS כנראה שזה שווה את זה 🙂
    7. ועל זה נאמר עדיף 20% הצלחה מ – 0% הצלחה :-)…
    9. אחד היתרונות הגדולים של גוגל זה ההשקעה האדירה בתשתית, מה שמאפשר להחזיק את אחד העננים הגדולים. כשיש לך מליון שרתים, כנראה שאף אחד לא ישים לב אם תניח יד על 100… ברצינות, בשביל זה בדיוק את שלבי האישור והפיתוח שמתחיל במוק, ונגמר במוצ עובד.
    10. לא כולם עובדים על אותה שפת פיתוח, אבל ה – Code Base הוא אחד והקונבנציות אחידות.

    מקווה שעניתי לכל השאלות 🙂

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

    הגב
  7. Moshe Kaplan30 במרץ 2011 ב 16:04

    למתעניינים בקשיים שחווה חברה גדולה כמו גוגל כאשר היא גדלה, מומלץ לכם לקרוא את הפוסט הבא: http://slacy.com/blog/2011/03/what-larry-page-really-needs-to-do-to-return-google-to-its-startup-roots/comment-page-1/

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

    הגב
  8. אדי7 בפברואר 2013 ב 7:01

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

    הגב
  9. Moshe Kaplan3 ביוני 2013 ב 7:57

    הי אדי,

    אני בהחלט מסכים איתך,
    מעניין מי יביא את הדברים המדהימים הבאים,

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

    הגב