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

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

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

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

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

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

בהנחה שיש לכם תשובות סבירות לשאלות הללו, אפשר לגשת לעיצוב המוצר. אם יש משהו שלא ניתן ללמד בכתבה קצרה זה עיצוב נכון, אבל אפשר לפחות לדעת לשאול כמה שאלות מנחות, לדוגמא: בעמוד הבית, האם אפשר להבין תוך שניות ספורות מה האתר/שרות מציע (Proposition)? מהו ה- Unique Selling Point? או במילים אחרות, למה שהמשתמש יהיה מעוניין להישאר באתר?

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

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

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

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

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

המטרה: עיצוב אינטראקציה:
הטוב: להגיע למישהו עם ידע בעיצוב חוויה שייתן לכם כיוון.
הרע: לתת למתכנת הצעיר להמציא משהו – זה הרי זול ומקובל, לא? אולי כן, אבל זה עדיין רעיון רע.
האלטרנטיבה המהירה: "A camel is a horse designed by a committee" – או במילים אחרות: לא מעצבים במשותף. שבו ביחד והשיבו לשאלות המשתמשים. הגדירו ביחד גם את הצרכים, אבל תנו למעצב הטוב מבינכם לעבוד לבד. שינויים ותיקונים תעשו אחר כך.

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

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

אודי רביד הוא מנהל מוצר ואחראי על תחום חווית החיפוש ב- eBay אירופה, שימש בעבר כיועץ בכיר בתחום שימושיות וחווית משתמש והוא כותב אורח בבלוג היזמים accelerate.co.il

הכתבה פורסמה בשיתוף עם עיתון דה מרקר

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

הויכוח הוא תמיד אותו ויכוח: PHP הוא נחות לעומת ASP בטח עם .NET. ג'אווה היא הדרך לכתוב שרתים! רק ג'אווה! לינוקס יותר טוב מחלונות, יותר יציב, שלא לדבר על מק והפאנאטים שלו, או שחלילה ניגע בשאלת השאלות: למה VI הוא טוב יותר מEMACS ולמה מי שמשתמש בGREP הוא הומו (כן, לא יכולתי להתאפק).

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

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

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

אבל אני סוטה מהעיקר.

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

וכן – ASP.NET שם בכיס PHP. מה תעשה לי?

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

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

אין חכם כבעל נסיון

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

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

הוכחה לכך ניתנה לנו לא מזמן עם שירות אחר שצבר גידול משמעותי, מעבר ליכולת המערכת – Twitter, כמשתמש דיי וותיק של השירות זכורים לי לא מעט ימים של אותו fail whale שמודיע כי טוויטר למטה בכל קליק שני או שלישי שלי במערכת, שלא לדבר על אינספור עדכונים על פיצ'רים איזוטריים כמו שיחות בינך לבין חברים אחרים שפשוט נוטרלו בצורה ברוטאלית על-מנת להתמודד עם העומס והבעייתיות של המערכת. מה שהפתיע אותי ולדעתי גם הרבה אחרים היה שלמרות כל אלו ולמרות ש-Friendfeed נכנס כאלטרנטיבה והחל לצבור תאוצה, בסופו של יום משתמשים נשארו נאמנים לשירות של twitter והסתפקו במערכת מקרטעת ומנוונת לפרקים במשך לא מעט חודשים עד שהגיעה נקודת המפנה בעמידה בעומסים ובביצועים של המערכת.

כשהכלי היחיד בידיך זה פטיש, אתה מתייחס לכל בעיה כמסמר

המקרה של Twitter הוא מקרה קלאסי של בחירת פלטפורמה שנעשתה בשל הייפ (Ruby on Rails במקרה הזה), ארכיטקטורה שלא התאימה לפרופיל הגדילה של האתר ואופי השימוש בו במשולב עם פיקסציה ורצון להוכיח כי הבחירה ניתן לגרום לעסק לעבוד אם רק נעשה עוד סבב של אופטימזציות או שינויים ארכיטקטוניים כאלו ואחרים. בפועל, נדמה היה שלצוות הטכנולוגי של Twitter קודם שהוחלף היו כלים מועטים להתמודדות עם הבעיה שצפה היות והיא נמשכה שבועות רבים. בשיא הבעיה Twitter שירתו 11,000 דפים בכל שנייה, מספרים שמציגים אתגר אמיתי בייחוד כשמצרפים להם את מבנה השירות (לכל אחד מאיתנו יש למעשה פיד משלו הכולל את כל העדכונים של האנשים אחריהם הוא עוקב), זה נתון מפלצתי שמערכת טיפוסית המבוססת על Relational Database תתקשה לעמוד בו בלי מאמצי גדילה ועלויות חומרה ותחזוקה מפלצתיים עוד יותר.

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

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

• בחר הובלה טכנולוגית עם ארגז כלים רחב – חשוב שלרשות האחראים על הטכנולוגיה שלך יעמוד ארגז כלים טכנולוגי רחב של פתרונות ונסיון בהתמודדות עם סוגיות scaling בעבר.
• בחר כלים שהוכיחו את עצמם – ככל שזה ניתן, עדיף להימנע מלהמציא את הגלגל מחדש, חשוב להכיר best practices ו-patterns מקובלים ולבחון שימוש בכלים ותשתיות המבוססים עליהם.
• שאל את עצמך – האם אני פותר את הבעיה שלי? באיזשהו שלב נדמה היה שטוויטר מתעקשים להוכיח שהשירות שלהם יכול לעבוד על Ruby on Rails ולהתבסס על Database קונבנציונאלי בעוד הבעיה שלהם היתה איך לספק שירות איכותי לגולשים שלהם בעומסים גבוהים
  
• העדף ארכיטקטורה איכותית על-פני פלטפורמה מדוברת – השתדלו להתעלות מעל לדיון מה עדיף – Ruby / LAMP / Microsoft וזיכרו שבכל אחת מהפלטפורמות הללו ניתן לתכנן פתרון מוצלח ופתרון גרוע, הרבה יותר תלוי בארכיטקטורה עליה תבססו את השירות שלכם.

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

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

הדופק של האתר – vital stats
זהו אחד העקרונות החשובים ביותר בשמירת ביצועים ויציבות של אתרים- ראשית הגדר לעצמך מהם הפרמטרים החשובים ביותר אחריהם אתה צריך לעקוב. מהם 5-10 הגרפים/נתונים שלפיהם תדע מה מצבך. הנתונים האלה משתנים מחברה לחברה, וככל שמשתכללים, כל נושא תפקיד בחברה יכול לעשות זום ולהגדיר פרמטרים משלו. פרמטרים שאני אוהב לעקוב אחריהם למשל הם:

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

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

כדי לענות על השאלות האלה צריך משמעת אדוקה באיסוף לוגים. מאוד חשוב לדעת מה קורה במערכת שלך. הדרך היחידה לדעת את זה היא באיסוף חכם של מידע מהמשתמשים, השרתים וכל דבר אחר שיושב לך במערכת. הלוגים הם היסודות לשיפור ביצועים, לטיפול בבעיות, לאבחון נכון של בעיות וליכולת מדידה עצמית. לא יכול להיות מצב שבו מועלית אפליקציה חדשה, או פיצ'ר חדש, אבל לא מוספים לוגים למדוד אותו. התפיסה הזו חייבת להשתרש בחברה ולהפוך לחלק מה DNA של העובדים בה. כל פעילות חייבת להיות ברת מדידה.
ניתוח וDASHBOARD
מרגע שמדווחים הלוגים, צריך לרכז לסכם ולנתח אותם. הדיווח והאיסוף הם אבן יסוד, אבל בלי ניתוח והצגה איכותית שלהם הם בגדר עץ שנופל ביער. ישנם כלים מעולים לניתוח איסוף וניטור של מערכות, רבים מהם הם קוד פתוח וחינמיים (cacti למשל). הכלים האלה מאפשרים ליצר גרפים מגוונים ונותנים גמישות בניתוח הנתונים הנאספים, כמו גם מאפשרים מתן התרעות במקרים שהנתונים חורגים מקריטריונים שהוגדרו.
אני ממליץ לייצר dashboard שמרכז את הגרפים/הנתונים הקריטיים שהוגדרו. דף זה יהפוך למד הדופק של החברה. זה הדף שכל אחד יבדוק כשהוא מדליק את המחשב, או כשהוא רואה מישהו רץ בטירוף במסדרון…

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

לסיכום
התהליך שמתואר פה הוא למעשה מעגלי:

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

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

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