מאמר

LEAN
ניקו גולד

|

מי זו לין ולמה כולם אומרים שהיא תעשה לכם טוב?

כולם מדברים על לין

שמעתם על המושג Lean Startup? אם לא, סימן שאתם לא עוקבים אחרי אופנת הסטארטאפים בשנים האחרונות.

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

 

מונח מפתח שחשוב להכיר הוא המונח MVP – minimum viable product – המוצר המינימלי הניתן למימוש והפעלה.
עלינו לשאוף לפתח אותו מהר ככל האפשר על מנת לצאת ולקבל פידבקים מן המציאות.

 

השיטה מעולה – האומנם?

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

 

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

 

אז מה אני מציע לעשות?

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

האם זה הזמן לרוץ ולקודד? זהו. שלא.

 

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

 

איך בודקים מספר אפשרויות לפתרון בשלבים מוקדמים ובלי לכתוב קוד?

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

 

GIRL2

 

פרוטוטייפ קודם לפיתוח

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

 

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

 

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

 

LEAN – לאן?

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

 

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

אולי יעניין אותך גם:

5 תגובות

הוסף תגובה

  1. ויקטור

    תודה על הכתבה, היה מאוד מעניין מחדש 🙂
    וישר בא מספר שאלות:
    1. מה ניתן לעשות עם הפרוטוטייף היפה? האם ישנה פלטפורמה מפורסמת (זה חשוב ביותר) המאפשרת להציג את המודל ולקבל ביקורת בונה? השיטה הזאת לא שווה הרבה בלי מאות ואלפים של תגובות.
    2. מה היתרון של Lean לעומת כל הצגת פרוטוטייף? ארי המתכנת תמיד יכול לבנות מודל – יפה אבל מופשט לחלוטין – פרוטוטייף ;יותר מזה אני סבור רוב חברות פיתוח היום פועלים בדיוק באותה צורת עבודה: דרישה מלקוח – יצירת מודל והצגתה בפני הלקוח – קבלת תיקונים כלליים – ורק אז תכנות מעמיק והכנסת את מלוא הפיצ’רים.
    מה שאני בא לעגיד שצורת עבודה הזו (או כזו – לא ניכנס לוויכוח) ידועה וקיימת, מה חדש ומהפכני Lean מציגה?
    תודה
    ויקטור

  2. איתי בוצ'ן

    איתי בוצ'ן

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

  3. ניקו גולד

    ניקו גולד

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

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

    3. האסכולה הקלסית אכן מדברת על ניתוח מעמיק של דרישות מלקוח, אפיון ארוך ומעמיק, אבטיפוס ו-DR, ורק אחרי זה בניה. יש פה מספר כשלים מובנים. נתחיל מדרישות הלקוח – יש פה הנחה שהלקוח יודע מה הוא רוצה וגם יודע לעלות את זה על כתב בצורה מפורטת. אז זהו שלא. נדירים הלקוחות שיודעים לעשות זאת כמו שצריך. יותר מזה, פעמים רבות לקוחות עצמם לא יודעים מה הם באמת צריכים (אני ממליץ לראות הרצאה של מלקום גלאדוול שמדגים את זה מעולה: http://www.ted.com/talks/malcolm_gladwell_on_spaghetti_sauce.html).

    מקרה נוסף בהוא שאין לקוח שיכול לדרוש. יש ראיון א’ של יזם והנחה שמשתמשים (הלקוחות של מוצר עתידי) ירצו בפתרון א’. קורה הרבה שמפתחים פתרון א’, ומסתבר שהוא לא בדיוק מה שצריך, אז מפתחים שינוי א’1, א’2 וכך אל ה… עד שמוצאים את הדרך הנכונה או שגומרים תקציב R&D. מקרה דומה כאשר הראיון טוב, אך הביצוע לא תואם לציפיות של משתמשים. זה בדיוק המקרה בו הפרוטוטייפ זריז היה חוסך זמן וכסף ומציג תמונה הרבה יותר מציאותית לפני ההחלטה על פיתוח. גילוי נאות – אני איש UX ומאמין שאב טיפוס הזה צריך להיות בנוי על ידי מאפיין חווית משתמש מקצועי. בהצלחה.

    ניקו גולד

  4. אדוארד

    אחלה כתבה ישר רואים שאתה בן אדם מקצועי.

  5. ניקו גולד

    ניקו גולד

    Like