4 כללים למדידת פשטות של תוכנה

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

אחת ההגדרות שאני אוהב היא של בחור בשם J.B. Rainsberger, הגדרה של ״מבנה פשוט של תוכנה״.

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

ע״פ ריינסברגר (עוד), ישנם ארבעה אלמנטים (עם סדר עדיפויות ברור) המובילים לתוכנה פשוטה:

  1. כל הבדיקות עוברות. 
  2. צמצום כפילויות קוד. 
  3. הקוד מתאר כוונה (clarity). 
  4. צמצום  מספר האלמנטים בקוד למינימום האפשרי  אלמנטים שאינם משרתים את מטרות 1-3.

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

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

הנה דוגמה של קוד \"ללא כפילויות\" שהפריע לי והפכתי לכפול:

אני מסכים, זה לא קוד \"מושלם\", וספריית templating הייתה יכולה להפוך אותו ליפה יותר, אך זו דוגמה אמיתית מהחיים.

הנה הקוד לאחר השינוי:

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

קוד המתאר כוונה
אם מזקקים את הכלל של \"כתיבת קוד המתאר כוונה\", לרוב עיקר העבודה היא מסביב לשמות: שמות של פונקציות או משתנים, או שמות חדשים הנוספים ע\"י פעולות \"extract method\" או \"introduce variable\".

ישנן 4 \"דרגות\" של שם:

  1. שם סתמי
  2. שם נכון
  3. שם מדויק
  4. שם בעל משמעות (\"meaningful\").
עצלנות ולחץ גורמים לנו להיצמד לתחתית הסקאלה (1,2), בעוד הקפדה ומקצועיות דוחפים אותנו לראש הסקאלה (3,4).
מאוד נהניתי, כשקראתי את ריינסברגר, כשהוא מתאר בדיוק רב הרגל שגם אני רכשתי: כאשר אני רואה קוד כפול אני מבצע extract method לשורות הכפולות, גם מבלי להבין לעומק מה המשמעות שלהן. פעולה טכנית גרידא.
אני נותן לפונקציה שנוצרה את השם \"foo\". מבלי לחשוב. תוך כדי עבודה אני מבין מה הפונקציה עושה ומשנה את שמה. לאחר 10 דקות עבודה ייתכן והשם שונה כבר שלוש או ארבע פעמים, אך אני מרגיש בבירור שאלו עליות דרגה ברמה של השם. לעתים פשוט צריך לנסות איזה שם ו\"לחיות\" איתו כמה דקות על מנת למצוא שם מוצלח יותר.
צמצום אלמנטים שאינם משרתים את מטרות 1-3. 
למי שנתקל ברעיונות אג\'יליים – אני מניח שעקרון זה הוא מובן מאליו: Eliminate Waste. עדכון המטרה בעיקרון זה היא להימנע ממרכיבים בקוד שלא משרתים את הפונקציונליות, לא מונעים קוד-כפול ולא מסבירים את התנהגות המערכת, כל מיני \"הכנות למזגן\"[ג].

מי שעובד ב (Test Driven Development (TDD נהנה באופן מובנה מעקרון 1 (\"כל הבדיקות עוברות\") ועקרון 4 (\"צמצום אלמנטים לא-חיוניים\"). זו הדרך המהירה ליצירת קוד פשוט, שגם יישאר פשוט לאורך זמן.
מכאן נותרו רק 2 פעולות לשים לב אליהן:
צמצום כפילויות קוד [ב] ו כתיבת קוד המתאר כוונה / קוד ברור. המשיכו לעשות את אלו בצורה תמידית – והמבנה של הקוד שלכם, או ה \"design\" של הקוד שלכם – יהיה פשוט. זו הדרך היעילה ביותר שאני מכיר.
זה אולי נשמע קצת פשוט מדי: אולי ציפיתם לשימוש במחשבון של Cyclomatic complexity וטכניקות של ספירת Weighted Micro Function Points (ממש כמו ספירת קלוריות). 
צר לי לאכזב אתכם: כמה אנשים טובים השקיעו שנים ביצירת מודלים מתמטיים לתיאור סיבוכיות של תוכנה – אך בפועל כמה עקרונות פשוטים הם אלו שיגרמו לקוד שלכם להיות פשוט יותר, וקל יותר לתחזוקה.

שיהיה בהצלחה!

—-

[א] יש המשתמשים במילה Design על מנת לתאר מצב של תוכנה חיה, ולא רק את התוכניות. לדוגמה: \"Refactoring: Improving the Design of Existing Code\". אם הרעיון הזה ברור לכם – הרגישו חופשיים להשתמש במילה design ולא ב structure.

[ב] אזהרה!: יש המבלבלים בין צמצום כפילות קוד בתוך המערכת, לבין שימוש-חוזר בקוד (code re-usability) או \"צמצום כפילות קוד בעולם האנושי\". בעוד ביטול כפילות-קוד בתוך הקוד שאתם כתבתם הוא כמעט-תמיד דבר טוב, שימוש חוזר בקוד (\"חיצוני\") הוא נושא מורכב עם הרבה ייתרונות וחסרונות. אני מתכנן לעסוק בנושא זה לעומק בפוסט נפרד.

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

קאנבאן (Kanban) – תהליך שמתנהל מעצמו

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

שייך לסדרה: אג\'ייל – מתודולוגיות פיתוח רזות


\"מדוע אנו זקוקים ל*עוד* מתודולוגיה? עדיין לא השתלטנו על סקראם!\"

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

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

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

מקורות
המילה קאנבאן היא מילה יפנית שמשמעה ״כרטיס חזותי״. היא משמשת בטויוטה (החברה שהמציאה את האג׳ייל[ב]) לתאר תהליך ניהול המלאי מופלא שקורה מעצמו. את התהליך של טויוטה כותבים בעזרת k קטנה (kanban) בעוד את תהליך התוכנה שמבוסס עליו כותבים בעזרת K גדולה (Kanban).

תהליך ניהול המלאי שהיה מקובל במערב נראה בערך כך:

  1. החברה מגדירה ומאיישת תפקיד בשם ״מנהלי מלאי״.
  2. כשהמלאי מגיע לרמה הנמוכה (\"מלאי מינימום\") מנהל המלאי מבצע הזמנה על מנת למלא את המלאי לרמה הגבוהה (מה שנקרא בטעות \"מלאי אופטימום\"[ג]). 
  3. \"מלאי האופטימום\" היא תחזית סטטיסטית, של מנהלי המלאי, על הביקוש העתידי לחלק. 
  4. מנהלי המלאי הם בעלי הבנה קטנה בייצור. ה\"חלקים\" ומבחינתם אלו יכולים להיות מנועי בואינג 747 או עגבניות. Same Same. 
  5. חלק גדול מהעבודה של מנהלי המלאי מושקע בזיהוי הפריטים והזמנת החלק הנכון. לכל חלק יהיה שם, מספר קטלוגי פנימי, מספר קטלוגי יצרן, פרטים לזיהוי היצרן, תמונות שיסייעו (למנהלי המלאי – האנשים במפעל כבר יודעים) לזהות את החלקים וכו\'. אופרציה שלמה. הזמנות מלאי לרוב נעשות באצוות (batch) על מנת \"לקבל מחיר טוב יותר ולחסוך כסף במחלקת המלאי\".

    הגישה המערבית לייעול התהליך היה רכישת תוכנה יקרה עם מיליון אפשרויות (ניהול מלאי הוא עסק מסובך) שתסייע למנהלי המלאי לעבוד מהר יותר (\"Send an order by one-click\").
    גישת ה LEAN, שצמחה מיפן, הייתה לשלוח את כל מנהלי המלאי להיות עובדי ייצור – ולבטל כמעט כליל את תפקיד ניהול המלאי.

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

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

    קאנבאן (kanban), שהחל כתהליך של טויוטה, הפך עם השנים לתהליך עולמי:

    • כשאתם מזמינים קפה בסטארבקס – ההזמנה נרשמת על הספל (החד פעמי) ומועברת למטבח. כשיחזור הספל לקופה – ידעו למי לתת אותו. בקשות מיוחדות – פשוט כותבים על הספל.
    • הגן הקיסרי בטוקיו נדרש להגביל את מספר המבקרים בו. הוא מחזיק מספר מתאים של tokens שכל אורח מקבל בכניסה ומוסר ביציאה. התנאי לכניסה לגן היא הימצאותו של token פנוי – אחרת יש להמתין בתור. בקרת עומס שמתרחשת מעצמה.
    קאנבאן. מקור:  http://mylesbraithwaite.com/journal/2011/03/new-starbucks-coffee-cup-design/ 

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

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

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

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

    • גרמו לתהליך להיות נראה (visible) ע\"י פרסום גלוי של מידע-מפתח[ד].
    • הגבילו את מספר הפריטים שבעבודה (Work In Progress = WIP)
    • הגדירו מדדי הצלחה ופרסמו אותם.
    • שפרו, באופן עקבי, את התהליך.

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

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

    אם ראיתם פעם את רשימת המטלות של ארגון סאפורט (כלומר Product Backlog), אתם בוודאי יודעים שיכולים להיות עשרות קייסים בטיפולו של כל צוות. אי-ניהול ה Sprint Backlog יכול ליצור מצב לא יעיל בו אנשי-הצוות במקביל על הכל (חוק התיכנותיקה: \"ל Context Switch תמיד יש מחיר\"). באירגון סאפורט קשה מאוד \"להתחיל קייס ולסיים\" – מכיוון שיש תלויות חיצוניות.
    לשם כך מגדירים בקאנבאן מגבלה בשם Work In Progress. המגבלה מחייבת את הצוות, מצד אחד, לא לעבוד במקביל על יותר ממספר פריטים (כל צוות קובע עם הזמן את ה WIP שלו). מצד שני היא מחייבת את הצוות \"לסיים\" נושאים ויהי-מה, אחרת כל ה slots של ה WIP יתמלאו – והצוות לא יוכל להמשיך לעבוד.

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

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

    למרות שקאנבאן נתפרה לצוות ללא Deliverables – גם צוותי פיתוח יכולים לעשות קאנבאן והיטב. באופן אישי אני מעדיף  לעשות \"קאנבאן עם ספרינטים\". לקחת את קאנבאן כפי שהוא, ללא תפקידים מיוחדים (Scrum Master) או טקסים (Stand-Up Sit-Down meeting ואחרים), אבל עדיין עם תצוגת התקדמות יזומה בצורת ספרינט רביו: \"מה עשינו בשבועיים-שלושה האחרונים\".

    שיהיה בהצלחה!

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

    [ב] תוכלו לקרוא על כך בקיצור תולדות הסקראם.

    [ג] רכישה של חלקים שיושבים במחסן במשך זמן ללא שימוש = מינוס בבנק וריביות. הרבה רכיבים כאלו זה בהחלט לא \"אופטימום\".

    [ד] ברוח ה Waterfall האהוב, הצעד הראשון של ארגונים רבים במימוש Scrum או Kanban הוא השגת תוכנה (יקרה) שתעזור לנהל את התהליך בצורה Efficient (= מהירה לכאורה). ניהול הסטטוס של הצוות בתוך תוכנה, כך שצריך לגשת למחשב וללחוץ כמה קליקים על מנת לראות נתון כלשהו, היא הדרך ליצור חוסר-נראות. האאא הרגלים רעים…

    .lior_comment { background-color: #fff2cc; border: 1px solid #BFBFBF; margin: 4px 0; padding: 4px; }

    שיקולים בעיצוב אפליקציות מובייל

    תודה לאלה שמיר, מאפיינת Mobile UI, שייעצה וסייעה בכתיבת פוסט זה.
    ——

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

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

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

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

    The Hotzone – האזור בו אצבע המשתמש חופשיה ועלולה להקיש (tap) בטעות. כדאי להרחיק את האזורים הלחיצים ממנה. מקור: http://answers.oreilly.com/topic/1802-designing-iphone-apps-the-rule-of-thumb/


    חשבו היכן ניתן לצמצם, לא היכן ניתן לעשות יותר
    נקודת פתיחה לא טובה לאפליקציית מובייל, כך נראה, היא מצב בו כבר קיים כבר מוצר Desktop.
    \"פרויקט התאמה\" קוראים לזה, Mobile Adaptation או Mobile Enablement ומנסים, בעזרת צוות של כמה מפתחים ואיש UI חסר מזל, \"לדחוס\" את האלמנטים הגרפיים ממסך של \"22 למסך של \"4.
    בעוד ב Desktop יש עכבר שהוא כלי הצבעה דיי מדויק, במובייל אזורים לחיצים צריכים להיות גדולים בהרבה – מה שמותיר מקום מועט אפילו יותר לתוכן שעל המסך.

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

    ראיתי ארגון ש\"התאים\" כמה אפליקציות למובייל. הוא העתיק טופס חיפוש עם 8 שדות להקלדה גם לגרסת המובייל וציפה שהמשתמש ישתמש במקלדת המוגבלת של הסמארטפון להקליד את כל השדות.
    בניגוד לגרסה השולחנית בה המשתמש יושב במשרד נוח עם מקלדת ומסך גדול, כאן המשתמש (אותו אדם, אך בסיטואציה שונה) אמור לבצע את אותה ההקלדה תוך כדי הליכה במסדרון, כשלרשותו מסך קטן ומקלדת שחוץ מזה שהיא מסתירה חצי מסך – היא מוגבלת ביותר להקלדה.
    לא מפליא שהגרסה המובילית של האפליקציה זכתה לשימוש זניח ביותר. אותו הלקוח עדיין מאמין שרוב הבעיה בכך שהאפליקציה היא בקושי בשימוש היא חוסר ב PR [א] ואלי קצת \"עיצוב גרפי נעים יותר\". המסקנה שלנו הייתה שהאפליקציה פשוט לא שימושית.

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

    ככלל אצבע, לאפליקציית מובייל טובה לרוב יהיו:

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

    חשבו לדוגמה על ההבדל בין אאוטלוק ל Mail ב iPhone: כמה עשרות, אולי מאות, פונקציות של אאוטלוק לא מצאו מקבילה בגרסת המובייל? בכל זאת, השימוש באפליקציה הוא נוח למדי ומתאים למרחב רחב מאוד של משתמשים. 
    דוגמה נוספת: חשבו על המקלדת של המובייל מול מקלדת של Desktop, איפה כל כפתורי ה F-masheu? כיצד ביטלו את כפתור ה del (מחיקה ימנה) וניתן להסתדר רק עם מחיקה שמאלה[ב]?


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


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

    הקלדה היא מאמץ מוגבר – שמור עליה

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

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

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

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

    ססמאות בנייטיב אפ – במערכות ווב שדורשות הקלדת משתמש / סיסמה, דבר מקובל הוא לייצר מעטפת (למשל PhoneGap) שתשמור את הסיסמה ב Secured Storage של המכשיר. יכולת זו בלבד מצדיקה שימוש ב PhoneGap ופיתוח Hybrid App.

    אל תצפה ממשתמש לנווט במסך של 4 אינץ\'

    חיפוש – הוא סוג הניווט המועדף. ללא פירורי לחם (breadcrumbs) ובטח ללא עץ ניווט. רשימת הפריטים האחרונים / הנפוצים יכולה להיות גם נקודת פתיחה טובה (חשבו על ה App Store).


    שמור קצת מידע בצד ליום סגריר (connectivity issues)

    אלו אלמנטים שקצת יותר קשורים למימוש הטכני מאשר להגדרת השימושיות per se.

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

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

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

    בהצלחה!

    —-

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


    [ב] בעברית, כמובן, הכיוונים הפוכים.

    על יזמות ואמונה

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

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

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

    מודל קיצוני (מודל השורטיסט) – מודל זה מבוסס על הימור בסיכון גבוה, וסיכוי נמוך להצלחה מטאורית. השורטיסט יאכיל את הוריו בקוקיז מאמסטרדם, יקבל את הסכמתם למשכן את ביתם – וילך להשקיע [א] את הכסף.
    בגרסה המוצלחת הוא ישקיע ב\"אפל\" או פייסבוק ב 2007 (אין לי שום מושג מה היא השקעה נבונה ב 2012). בגרסה הפחות מוצלחת הוא ישקיע בשוק הטקסטיל כי \"המחירים ברצפה ומכאן הם יכולים רק לעלות!\".

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

    סאנסה: מאמינה. מקור: wallpapers.com

    הטיית השרידות

    באנגלית: Survivorship Bias. דוגמה טובה להטיית השרידות היא ביצועים של קרנות נאמנות. אם תשבו עם יועץ השקעות, קרוב לודאי שהוא יציג בפניכם מספר של קרנות בעלות ביצועים יפים ועוד כמה \"חדשות\". התחושה היא טובה – \"הנה זו הרווחיה 5% וזו 7% – בממוצע של ארבע שנים. קרן נאמנות היא רווח בטוח!\" – אתם עלולים להסיק.
    מה שלא מספרים לכם היא שכל קרן שביצועיה לא היו טובים (נאמר 3% ומטה) – נסגרת ונפתחת בשם חדש, כך שההיסטוריה הכושלת שלה \"נמחקת\". אתם רואים מדגם לא מייצג של \"הקרנות השורדות\" ויכולים להסיק, בצורה שגויה, שאתם יכולים להניח על ממוצע ביצועים של 6% בשנה, מכל קרן כלשהי. כשמציגים בפניכם נתונים, נסו לשאול את היועץ כיצד יש כ\"כ הרבה קרנות \"חדשות\", ללא נתונים היסטוריים משמעותיים…
    אין שום סיבה להניח שקרנות שהצליחו במשך 4 שנים – ימשיכו להצליח בהמשך. סביר יותר שהן מהמרות עם סיכון בינוני+, וביום שהם יתחילו להפסיד – הן ימחקו ויופיעו בשם חדש.

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

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

    סינדרום \"סאנסה\"

    סאנסה היא דמות הנאיבית מהסדרה \"משחקי הכס\"[ג]. היא שמעה כ\"כ הרבה סיפורי אגדות על נסיכים ואבירים – עד שהיא לא נותנת למציאות אחת בודדה לשנות את דעתה. בכל מחיר – היא ממשיכה להאמין.

    אם מר צוקרברג מספר לכם ש\"בפייסבוק לא ניסינו לעשות עסק – רק עשינו מה שכיף לנו\" – אוי לכם אם תסיקו ש\"רק לעשות כיף\" הוא המתכון להצלחה. גוגל מאפשר לעובדיה לעבוד 20% על נושא לבחירתם. היא אמנם חברה חדשנית מאוד – אך את הכסף שלה היא עושה מעובדים שעבדו ב 120% על מטרה מוגדרת היטב.

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

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

    • האם אותם מנכ\"לים באמת יודעים לשים את האצבע על המקור להצלחה שלהם?
    • אם הם יודעים – האם הם ישתפו את זה עם כל העולם?
    • אם הם משתפים – האם מה שהיה נכון להם, בשלב ההוא, נכון עבורכם, ועכשיו?

    צריכים להיות מספר תנאים שיתקיימו, על מנת שעצה שאתם שומעים מ \'מנכ\"ל של חברה מגה-מצליחה\' – תהיה עצה טובה.
    סאנסה, הייתה מתעלמת מהתנאים, ופשוט – מאמינה.

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

    מקור: https://hbr.org/2009/04/are-great-companies-just-lucky

    דברי סיכום

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

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

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

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

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

    אם אתם רוצים לדעת איך עושים את זה – כדאי שתכירו את ה \"Lean Start-up\", אחד הדברים המעניינים שמתרחשים פה בשנים האחרונות.

    אני אנסה בפוסטים הקרובים לעסוק ב Lean Startup. אני מסתובב מסביבו כבר זמן רב [ב] – והגיע הרגע לגשת אליו ישירות.

    כל טוב.

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

    —-

    [א] בעברית תקנית, \"להמר\" היא המילה הנכונה לתיאור מצב זה.

    [ב] פוסטים קודמים מסביב לנושא:

    [ג] ע\"פ הספר היא קצת פחות תמימה.

    כיצד ייתכן?!

    שייך לסדרה: אג\'ייל – מתודולוגיות פיתוח רזות


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

    כיצד ייתכן, אם כן, שהאייפוד הראשון תמך רק ב MacOS עם חיבור Firewire?
    ושהוא היה כ\"כ לא אמין עד שכ 20% המכשירים התקלקלו בטווח שימוש סביר?

    כיצד ייתכן שרק ב iOS 4 (אמצע 2010) האייפון קיבל תיקיות לארגון האפליקציות? האם אתם מדמיינים אתכם מפתחים מערכת הפעלה ללא תיקיות?

    “If Apple can launch a smartphone without Find or Cut-and-Paste, what can you cut out of your product requirements?” – Sramana Mitra

    כך נראה Youtube בשנת 2005. לא, זו לא תקלה – כך באמת הוא נראה.
    מקור: http://www.telegraph.co.uk/technology/6125914/How-20-popular-websites-looked-when-they-launched.html

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

    כיצד ייתכן שרק בסוף 2010 Gmail שחררה את הפ\'יצר הבא: Context Sensitive Help. עד אותו רגע ה Help תמיד נפתח בדף הראשי, ללא קשר. האם אתם מדמיינים את עצמכם משחררים תיעוד של מוצר שלא מקושר לתוכן?

    העיצוב של וויקיפדיה בשנת 2001.
    מקור: http://www.telegraph.co.uk/technology/6125914/How-20-popular-websites-looked-when-they-launched.html 

    אפרופו תיקיות, Gmail אפשרה לארגן הודעות מייל בתיקיות רק ב 2009, שנתיים אחרי ששוחררה לקהל הרחב. אני מופתע כי אני עבדתי על כמה מוצרים שלא הסכמנו לשחרר לפני שהיו תיקיות, תוויות ועוד כמה התחכמויות שהסתבכו וביטלנו ברגע האחרון. כיצד ייתכן שגוגל הצליחה עם Gmail ללא תכונה שאצל כ\"כ הרבה מנהלי מוצר / פיתוח יהיה ב \"Must-Must Have\"?

    כיצד ייתכן שהארכיטקטורה של גרופון הייתה דף בבלוג WordPress ציבורי, עם Widget של ThePoint שכולל מקטע AppleScript ששולח קופונים ב PDF? איזה מתכנת היה מוכן לשחרר דבר שכזה? שלא לדבר על איזה ארכיטקט היה מאשר את זה…

    כך נראה טוויטר בשנת 2006. האם הייתם משחררים אתר שנראה כך?
    מקור: http://www.telegraph.co.uk/technology/6125914/How-20-popular-websites-looked-when-they-launched.html

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

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

    מנכ\"ל דרופבוס מדבר על הקמת החברה.
    מקור (שווה קריאה): http://www.slideshare.net/gueste94e4c/dropbox-startup-lessons-learned-3836587?from=ss_embed

    The lesson of the MVP is that any additional work beyond what was required to start learning is waste, no matter how important it might have seemed at the time.