70: עקרונות לעיצוב בפשטות 03 - לזקק את המהות

אנחנו מספרים על מקרה בוחן של פיצ׳ר תכנון הקצאת משאבים. אורחים: שי כהן, Product Designer ואיתי כהן, Full Stack Developer במאנדיי.קום

עיצוב

In the previous episode of our Simple Design mini-series, we discussed why it is essential to understand the core problem in every project we work on. In this week’s episode, we talk about what to do after we understand the problem: crystallize the essence. What this means is that we are not defining the solution just yet, but instead take time to define its characteristics, the expected results, and the experience we want to provide for our users.

So, what does the process of crystallizing the essence of a feature looks like? What is the price you pay for not doing this process correctly? Should your design be based on existing solutions in the market, or bring brand new concepts? And above all, how should you approach such a process if you are limited in time and resources?

Today we host Shay Cohen, Product Designer, and Itay Cohen, Full Stack Developer at monday.com, who share how they crystallized the essence of the Resource Allocation feature on our platform - a tool from the classic Project Management world, which is usually considered very bland and boring. Shay and Itay tell us how - after a lot of research, user testing, and design inspiration from unexpected places - we managed to turn this seemingly bland feature into an inseparable part of the monday.com platform.

Scroll down to find photos from the development process, and also - how resource allocation looks like in Excel vs. how it looks like today on monday.com.

Common resource allocation in spreadsheet

Designs of Resource allocation

Resource allocation v01

Resource allocation v02

Resource allocation v03

Inspiration from Shay's building

Resource allocation v04

Final version

Resource allocation - With emojis (TBR)

Resource allocation - Video

Episode transcript

Automatically transcribed — it may contain errors.

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

לא איזה פיצ'ר שנוצר במוחו הקודח של מעצב, ולכן על פה זה שי, שיש לו המון רעיונות כאלה, שהוא בא אליי בבוקר, אומר איתי, בוא תר על מה חשבתי אתמול בלילה, מר לי משהו בפיגמה, ומתפוצץ לי המוח. כאן ב ת היה משהו קצת שונה, היינו צריכים להבין את הבעיה לעומק, ועשינו את זה יחד. אז לכן אני פה. אז הדוגמה שבחרנו להתמקד בה היא בעצם של פיתוח פיצ'ר שנקרא Resource Allocation, שזה בעצם הקצאת משאבים. אנחנו בעצם נעבור שלב שלב ונבין איך בעצם, אם לא היינו מזקיקים את המהות של הפיצ'ר, היינו ממש הולכים לאיבוד. נכון, נכון. שים אותנו על ציר זמן, אז על מתי אנחנו מדברים? אנחנו מדברים על רבעון אחרון של 2019. אנשי הסלס פנו אלינו ו רו, תקשיבו, אנחנו, המון עסקאות שאנחנו מנסים לסגור, אנחנו לא מצליחים לסגור אותן, אומרים, וואי, איזה כיף, יש לכם אוטומציות, יש לכם דשבורדים, אבל אין לכם Resource Allocation. אנחנו לא מוכנים לסגור עסקאות, וזו עסקאות מאוד גדולות, עד שלא יהיה לכם את הפיצ'ר הזה. כלומר, זה היה ממש דילבלוקר. כן. ואנשי הסלס גם התחילו איזשהו תהליך של תיוג עסקאות שנפלו, ולראות למעשה כמה כסף אנחנו מפסידים בגלל כל פיצ'ר. אם חסר לנו סאבטאסקס, שאז היה חסר, אז הם תיגו, חסר סאבטאסקס, בגלל זה נפלה עסקה של 100 אלף דולר. חסר עסקה נפלה בגלל Resource Allocation, מתאגים את זה על Resource Allocation. וגענו למצב שבאותו ריבון, בריבון הרביעי, Resource Allocation היה במקום הראשון בדילבלוקרס, זה היה באזור החצי מיליון דולר של עסקאות של פספסנו. כן, אז אנשים היו עושים בעצם Repair Test למוצר של מנדיי, היו משתמשים בצ'ארטים כדי לחשב את כמות המשימות של כל חבר צוות, היו מייצאים את המידע שלהם לאקסל, ומייצאים את זה אולי למוצרים אחרים גם, ובעצם משתמשים בכמה מוצרים כדי להגיע לפתרון אחד, שאפשר לעשות אותו במוצר אחד. עכשיו רגע, בוא נבין ב ת מהו. כאילו בוא נבין שנייה, תגיד לנו במשפט מה זה אומר Resource Allocation, מה בן אדם מחפש? טוב, אז בסופו של דבר זה כלי מאוד מורכב, טכנית, מורכב מתמטית, אבל הוא מאוד מופשט ויזואלית. והעיקר של המהות שאנחנו משיגים בזה זה בעצם לקבל החלטות טובות יותר, שמבוססות דאטה לגבי כמות המשימות שמוקצות לצוות, וגם את היכולת לעמוד בהם, לראות שעומדים בהם, לבצע שינויים, להתאים את האומסים, ובכך לקבל גם החלטות עתידיות טובות יותר, לראות את התמונה הגדולה, ממבט העל לראות את הצוות, להבחין בבעיות מהר, להבחין בבעיות שעלולות להיווצר בעתיד, בגלל שזה על טיימליין, ולשים ביידים הגיוניים ובריאי השגה לצוות. והאלמנט השלישי זה יצירת שקיפות. כל עובד יודע כמה עבודה הוא מסוגל לבצע ו ור לבצע, וזה נותן לו ביטחון לגבי כמות המשימות והאומס שלהם. ובכלל, הארגון לדעת איזה צוות צריך לחזק או לתגבר כדי לעזור להם לעמוד במשימה. במשפט אחד אפשר להגיד שריסורס אלוקיישן, בשפה הכי הכי פשוטה שיש, זה להבין מי פנוי באלן בי. עכשיו, כשאנחנו מדברים כרגע, הפתרון הזה כבר מומש, נכון? שי, אתה יכול רגע לתאר איך זה נר בפועל בסוף? איך היום נר ריסורס אלוקיישן בתוך מנדיי? בואו נדמיין שלכל בן אדם בכל שבוע יש לו עיגול. ככל שאני יותר עסוק או עמוס, העיגול שלי נהיה יותר גדול. ואם ממש הרגו אותי השבוע בעבודה, העיגול נהיה אדום. ואם אני בול על הקיבולת שלי, אז יש לי V בתוך העיגול. ככה זה בעצם התיאור הכללי של המוצר. של הפתרון שהגעתם אליו בסוף. נכון. אוקיי, עכשיו בואו נבין רגע למה זה לא טריוויאלי. אוקיי. קודם כל, כל הפתרונות הקלאסיים של ניהול משאבים, הם מאוד מאוד מזכירים את עולמות האקסל. זה הרבה שורות, הרבה עמודות, ופשוט נר כמו משחק של רמזורים אחד גדול. יש המון המון מידע, המון מספרים, וגם הוא לא אקשנבילי, הוא לא בר שימוש. זה בעצם כמו דוח סטטי של המשאבים שלי. רוב הפתרונות האחרים די חזרו על עצמה בצורה של המבנה הטבלאי. הם היו מאוד מאוד עמוסים.

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

לא רוצים להתפשר על פחות ממושלם, זה גם לא אינטואיטיבי, בוא, יש לחץ של זמן, פיצ'ר שצריכים, למה בעצם לא העליתם את אחת הגרסאות הראשונות ו רתם יאללה, בוא נשחרר פיצ'ר ונעבוד עליו תוך כדי. מה זה הדבר הזה שהיה חסר לך שם? היה חסר לי בעצם את המהות של מה שאני רציתי להגיע מההתחלה, של משהו שהוא לא כמו העולם העתיק, משהו שהוא נוח לשימוש, משהו שהוא דו-כיווני, שאני יכול לעבוד עליו ולא רק להסתכל עליו כמו איזה דוח, ומשהו שהוא במבט מהיר מאוד ברור. מאוד ברור לי מה התמונה הגדולה של הצוות שלי. כלומר, אתה אומר, זה ממש מקום שבו האתגר של איך מנגישים את זה ויזואלית הוא ההבדל בין פתרון שעובד לפתרון שלא עובד. לגמרי. או לפיצוח הזה. לגמרי. בצורה מהירה לקבל מבט על על הצוות. רציתי לשאול את שי, מה זה אקשנבילי? מה זה אקשנבילי? אוקיי, כשהמוצר אקשנבילי הוא בעצם גם בר שימוש, הוא לא רק לצפות בדוח או להעתיק מספרים, הוא גם לקחת משימות של אדם אחד ולהעביר אותן לאדם אחר, לשנות את הזמנים של המשימה, לבטל את המשימות, לשנות עומסים. זאת אומרת, זו לא תמונה סטטית, אלא ממש כלי. זה כלי עבודה. כן, אני חושב שגם ב ת אחד הפיצוחים שלנו בתהליך, זה ב ת שהלכנו בסוף לפתרון שאפשר לנו את זה יחסית בקלות, והעובדה שהכלי הזה גם הוא אקשנבילי, ב ת העיפה לאנשים את הראש, כאילו, שבן אדם רו בעיה, הוא רו ב ת יום מסוים שעובד מסוים עמוס, הוא פותר את זה on the spot, כאילו. הוא אותו כלי, פותח את זה, יכול לפתור את זה במקום. גם לראות למה זה קורה וגם לפתור את זה. זה משהו כאילו שאנחנו, זה היה עוד בהתחלה, בהתחלה, גם מאנשי הסלס, זה היה כאילו בגדר best effort הדבר הזה. מה זה אומר best effort? זה אומר שכאילו, זה גם נחמד אם תצליחו להגיע גם לדבר הזה. סבבה מאוד יהיה אם יהיה לכם פתרון סטטי שאני יכול לראות. זה ממש מגניב אם תצליחו להגיע למשהו אקשנבילי. מה היה האתגר, אתה יודע, שי מתאר פה איזשהו חזון עיצובי, איפה זה מתארגן מבחינת הפיתוח? אני זוכר שסתם זרקנו, רנו טוב, resource allocation, כמה זמן זה ייקח? זרקנו ריוון. ואז שיירנו לפרטים וגם תוך כדי הגרסאות, בגלל זה גם אולי היה מאוד חשוב שבתהליך הזה יהיה גם פיתוח וגם עיצוב וגם פרודקט. זה לא ששי בא והתחיל לחלום על דברים, כמו שהוא תמיד עושה. זה היה מאוד אליינד עם מה שהתשתיות שיש לנו היום יכולות לתת. ובסופו של דבר הרווחנו מזה, הפרווח כפול. בנינו את זה על ה-timeline, שזה מוצר כבר קיים אצלנו במוצר, מין ציר זמן שעליו יש משימות, מוצר קיים כבר. ואת resource allocation, למעשה הבועות ששייטייר, הנצילות של כל עובד, שמנו ממש על גבי ה-timeline. אז הרווח הכפול פה זה שגם היוזר כבר מכיר את המוצר הזה, את ה-view הזה, ולנו המפתחים היה קל לפתח על גבי הדבר הזה. כבר היה לנו את הדבר הזה, עשינו לו איזשהו enhancement, הוספנו על גביו. ולכן אני אומר, תמיד גם זוכר, רתי לשי, בוא ננסה שזה משהו שמנגן איכשהו עם ה-timeline וזה, וברגע שמצאנו פתרון כזה, אז זה הייתה הצלחה משותפת. אבל גם להבין שה-timeline רלוונטי פה, עבר דרך זה שהבנתם שהבעיה שצריך לפתור והמהות של הבעיה עוברת דרך זמן, אנשים וה-effort. נכון. שי, מאיפה בסוף הגיע הפתרון אגב? כי כזה לא ראית בחוץ, נכון? לא. הרעיון של העיגולים, איכשהו, ככה הבנתי אחרי שהצבתי את זה, נולד אצלי בתת מודע. האגדה מספרת. האגדה מספרת שזה משהו שאני רו אצלי בבניין כל יום, וכנר נשתל אצלי איכשהו בתת מודע. מה אתה רו בבניין כל יום? יש את המדבקות העגולות שמזהירות מפני כניסה בזכוכיות בבניינים. אז בעצם אצלי בבניין יש טור כזה של מדבקות, וזה ממש נר כמו גריד.

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

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