הקרב בין מחלקת השיווק ([1]Marketing) למחלקת הפיתוח מתנהל כבר שנים, במשך דורות, אבות ובנים. אלה רוצים "עוד פיצ'רים ומהר" אלו רוצים "איכות, דיוק ושיטתיות" (ע"פ המפתחים. אנשי שיווק יספרו את הסיפור קצת אחרת). נקודת ההכרעה אינה נראית באופק.
האם זה קרב מחוייב המציאות? האם לא ברור שהפעם "אנחנו" צודקים?
שאלה: כאשר בא אליך איש מוצר ורוצה עוד פיצ'רים על חשבון איכות, מה אתה אומר לו?
רגל בדלת
בניגוד לקונוטציה האגרסיבית של "לדחוף את הרגל" כדי לחסום דלת נסגרת (שמתאימה לתיאור של איש מכירות אגרסיבי במיוחד), "רגל בדלת" לרוב מתייחס לצורה המנומסת (האמריקאית אולי) של נקודת הכניסה לבית הלקוח. במקום לשאול: "האם אתם רוצים לקנות שואב אבק חדש?" יפתח איש המכירות בשאלה "האם גם לכם האובך האחרון לכלך את הבית?" - שאלה תמימה ולא מחייבת. "כן בוודאי - פשוט נורא" המשכתם, פתחתם את הדלת לרווחה ואפשרתם לאיש המכירות לחצות פיסית את קו הדלת ולהניח שם רגל. הקרבה המעטה הזו (והכניסה בהסכמה למרחב האישי שלנו) היא כבר נקודת פתיחה טובה בהרבה להצעה עסקית.
באופן דומה אנשי שיווק ירצו שתספקו להם פיצ'ר, אולי חלקי ולא עובד, שאיתו יוכלו לגשת ללקוח ולומר "גם לך יש בעיות ABC"? "יש לנו דווקא משהו מעניין לדבר עליו" - יפתחו דיון עם לקוח שזקוק לפ'יצר אך ירגיש הרבה יותר נוח לדבר עם מישהו שיש לו משהו ולא רק רעיון באוויר. עד שיגיע הזמן למסור את הפתרון ללקוח, הפיתוח יוכל כבר לפתח את הפי'צר כמו שצריך [2].
Feature Superiority
הרבה יותר קל למכור מוצר שיש לו רשימה גדולה יותר של פ'יצרים. ללקוח זו מרגישה קנייה בטוחה יותר ומי שמוכר אותה נתפס מנוסה יותר. ב SAP שמעתי את האמרה הבאה (שנכונה גם לחברות אחרות): "The Suite Always Wins". כלומר ל SAP לא חייב להיות מוצר לניהול משאבי אנוש הכי טוב או כלי לניהול פרוייקטים הכי טוב, אך כשהיא מוכרת חבילה שמחליפה 10 מוצרים שונים ויותר - יש לה ייתרון אדיר. עקרון זה נכון כאשר מדובר במוצרים נפרדים תחת אותה קורת גג ("One Stop Shop") ואפילו קצת יותר כאשר מדובר במוצרים שמדברים אחד עם השני ("Suite").
ייתכן והרצון להגיע ל Feature Superiority דוחף לבקש עוד פ'יצרים על חשבון סגירת ושיפור הקיימים. למי שמכיר את תאוריית האוקיינוס הכחול[3] (או בכלל את פורטר) - זו נראית לעיתים קרובה טעות נפוצה של אנשי שיווק ולא Best Practice, אך נראה שאנשי שיווק לא מעטים פספסו את השיעור הזה ב MBA שלהם. אציין שאנשים נבונים שעבדתי איתם עשו, למיטב הבנתי, את הטעות הזו. נראה שתחת לחץ ותחרות (אנשי מכירות שמכפישים את שמכם בחברה כי הפסידו עסקה בגלל המחסור בפ'יצר X) - קל מאוד להגיע לשם. באופן אירוני, מתחרה שלו יש עדיפות במספר הפ'יצרים ואולי הגיע לשם בעקבות לחץ, עלול לגרור את החברה שלכם לריצה אחר רשימת פ'יצרים במקום להתבונן על התמונה השלמה.
Check-box Feature
לעיתים קרובות, תהליך מכירה של תוכנה ארגונית עובד כך: הלקוח שולח RFP - Request For Proposal לכמה ספקי תוכנה שנשמע שיש להם תוכנה שמתאימה לצורכיו. ה-RFP הוא מסמך עם רשימה ארוכה של דרישות "יש"/"אין" שעל הספק למלא. מי שעומד בדרישת הסף עובר לשלב הבא בו משוחחים על הפתרון, עושים פיילוט וממשיכים למכירה. אם חסר לכם ברשימת הדרישות פ'יצר שמוגדר כקריטי - יסננו אתכם עוד בשלב ה RFP, לעיתים ללא הבנה מה אתם במקום לאותה הבעיה, ללא ודאות שזה באמת מה שנחוץ וכו'. על מנת לעבור את התהליך יש לסמן כמה שיותר סימני V.
זה תהליך דומה מאוד לשילחת קורות חיים. מתכנת עם 10 שנות ניסיון ב Web יציין ידע ב JQuery, Comet, Ajax ו Cross-Browser DOM אבל אולי ידלג על HTML ו CSS. הוא עלול לגלות שאשת כח-האדם שעושה Pattern-matching על קורות החיים שלו פשוט מסננת אותו "אין לו מספיק ידע" כי "צריך ידע ב CSS" או CSS3 או XHTML (מול HTML - הבדל סמנטי) וכו'.
מה הפתרון? על מנת לעבור את הסינון הזה אותו מתכנת יכתוב אינסוף מושגים הקשורים לווב, שחלקם אולי לא כ"כ נכונים על מנת להגיע למראיין המקצועי (כלומר - טכנולוגי) הראשון שיוכל להתרשם באמת מכישוריו.
באופן דומה מנהלי מוצר רוצים להציג רשימה ארוכה של יכולות במוצר. לעיתים הם יאתרו פ'יצרים שאותם לקוחות מבקשים אבל אף פעם לא משתמשים בהם. כיצד ייתכן שלקוח דורש פ'יצר שהוא לא מתכוון להשתמש בו?
פי'צר כזה מסומן כ Check-box Feature - תחמושת חשובה שאיש השיווק רוצה לספק לאנשי המכירות שלו. הם יוכלו לטעון "בטח - גם לנו יש Mobile Cloud EAI Service Integration 2.0 ואולי יוכלו לעבור איזה Demo של כמה דקות. אבל הפ'יצר עצמו לא באמת צריך לעבוד על מנת למכור או אפילו ליצור לקוח מרוצה - חבל לבזבז עליו זמן פיתוח.
מה עדיף? לחנך את הלקוחות/שוק (והגרורות שלהם) שזה פ'יצר מיותר (קשה מאוד) או לבקש מהמפתחים פ'יצר חלקי ונבוב בהשקעה מינימלית (יחסית קל)? האופצייה השנייה ישימה יותר ועובדת טוב יותר (לצערנו, המפתחים).
מיותר לציין שהמפתחים שנתקלים ב Check-box Feature נוטים להסיק שאיש המוצר פשוט טיפש, חסר ערכים ומדרדר את החברה לתהום.
למכור סיפור
מנהלים בכירים הם לרוב אינם אנשי-פרטים. כבר מזמן הפסיקו לעסוק בפרטי התפעול של החברה - הם אנשי חזון. ואם הם המנהלים בחברת הלקוח - יש סיכוי טוב שהם אלו ש"יחתכו" בעסקאות גדולות. במקום להגיע לליבם עם פ'יצר כזה או אחר - קל יותר להגיע לליבם בעזרת חזון. סיפור. "החברה שלנו תחבר את כל מערכות המחשוב ותיצור תמונה אחידה" הוא סיפור טוב. מנהל טוב מבין את הייתרון ביכולת כזו. לעיתים קרובות מאוד הסיפור איננו התיאור הטוב ביותר של המציאות, אלא הרחבה רעיונית משמעותית של עובדה קיימת (קרי - הגזמה פרועה).
לדוגמא, ייתכן והסיפור הנ"ל מסופר על מערכת שאוספת סטטוסים ב SNMP ממגוון מערכות, כ"א בשפה שלה, הנתונים לעיתים לא מסופקים ע"י המערכות, וכדי להגיע לתובנה איש ה IT צריך לחפור לא מעט בנתונים שנאספו. בכל זאת, אם המתחרים מוכרים סיפור - לא תרצו לשלוח את אנשי המכירות שלכם עם "פ'יצר": "לא באים עם סכין לקרב אקדחים", אומרים באמריקאית.
אנחנו בפיתוח מעדיפים לדייק בפרטים ולא "לנפח". אנו נעדיף לקרוא לאובייקט "SnmpMessage" ולא "SystemWellBeingReport" (קצת מוגזם - לא?). אנו נעדיף "XmlParser" ולא "Cross-SystemTranslator". לכן כשאנחנו רואים את החומר השיווק של המוצר שפיתחנו, בעוד אנו יודעים מה הוא באמת עושה, אנו עלולים להיות מופתעים. "הם חיים בעננים" אנו מספרים על אנשי השיווק, "רואים סרטים בעננים", מוסיפים. קרוב לודאי שהסבר כמו "הלקוחות שמחים לקנות את הסיפור, זה נותן להם אמון שאנחנו מבינים אותם ויודעים על מה אנחנו מדברים" רק מעצים את תחושת הניכור.
סיכום
טעות נפוצה היא לחשוב ש"המוצר מוכר את עצמו" או ש"מספיק מוצר טוב". אמנם יש מעט מוצרים שנמכרים ללא שיווק (למשל מנוע החיפוש של גוגל) ולמשתמש ישירות, אך את רוב המוצרים עדיין מוכרים בעזרת אנשי מכירות, שיווק וחומר פרסומי ועל המוצר למלא חלק במערכה. הלקוחות שלנו אינם תמיד מבקשים את מה שהם צריכים [4], השוק לעיתים קרובות "טיפש" (או "לא רציונלי") וזו הטייה שחשוב להבין להתמודד איתה על מנת להצליח בעסקים. לא מעט סטראט-אפים נופלים על הטעות הזו. אם לא שמתם לב - ברוב חברות ההייטק, לפיתוח מוקצים כ 10-15% מהתקציב ולשיווק - כ 40-60% מהתקציב. לא סתם.
בכדי לסגור מעגל, אחזור לנושא האיכות מול פ'יצרים שממנו התחלתי.
מחקר מעניין שקראתי (לא מצאתי את המקור) הציג עובדה מעניינת: מה הגורם שמסביר בצורה טובה את איכות התוכנה?
יותר מותק החברה,
יותר משנות הנסיון של המפתחים,
יותר מגודל החברה,
ויותר מרמת המפתחים (נמדד ע"י רמת השכר),
- התחום שבו עוסקת החברה משפיע על האיכות.
בתחומים שבהם איכות היא חיונית להצלחה עסקית (למשל מכשור רפואי, ניהול כספים) - תהיה איכות גבוהה ובתחומים בהם הדרישה פחות מחמירה (למשל תוכנה שהמצאותה נדרשת על מנת לעמוד בתקן [5], מה שנקרא Compliance) - תהיה איכות נמוכה יותר [6].
הלקוחות יאמרו לנו מה רמת האיכות הנכונה בעבורם, והם יאמרו זו בצורה עקיפה. לרוב אלו יהיו מעשים (אי קנייה / קנייה ממתחרה) ולא דיבורים (הרי, מי לא רוצה איכות?).
אפרופו, המנהלים בארגון שלכם כמעט ותמיד יכריזו שהם רוצים איכות - אך המעשים בשטח הם אלו שקובעים. על מה מקדמים אנשים? על יותר פ'יצרים או על יותר איכות? לא מזמן שוחחתי עם VP R&D של חברה קטנה שהפסידו עסקת ענק (עבורם) בגלל באגים שצצו בתהליך בחינת המוצר ע"י הלקוח. "המוצר שלכם נחמד, אבל יש בו יותר מדי תקלות" הסביר הלקוח מדוע הוא דוחה את העסקה. לא נראה שיש מוטיבציה טובה מזו להשקיע באיכות. האם הלקוחות שלכם דוחים מוצר על איכות או רק על מחסור פ'יצרים?
מה שחשוב להבין הוא שכדי להצליח אנו זקוקים לשני הצדדים של המשוואה, מוצר טוב + שיווק / אסטרטגיה טובה, ושאנשי שיווק טובים מבינים את הלקוחות - ולא בהכרח את המפתחים. אני מקווה בפוסט זה לגשר עוד קצת על הפער בין הפיתוח ולשיווק ולהגביר את ההבנה ההדדית.
תודה לניר דרמר על ההערות המועילות על הפוסט.
[1] שיווק נשמע לי תמיד קשור לשוק, פרסום/מכירות ופחות תכנון אסטרטגי או הגדרת המוצר - אך כשמדובר בשיווק מדובר על שניהם.
[2] או שלא. יש פה סיכון מסוים. אנחנו בפיתוח נוטים לזכור היטב את המקרים שבהם זה לא עבד - אבל הרבה פעמים זה עובד יפה. בכל זאת זהו Best Practice ולא Flawless practice.
[3] תאוריית האוקיינוס הכחול גורסת שבמקום להלחם עד זוב דם עם כרישים אחרים (להלן, אוקיינוס אדום) כדאי לנו למצוא נישה ייחודית בה לא תהיה לנו תחרות. מה שנקרא בידול. מי שמכיר את אבי האסטרטגיה העסקית, מייקל פורטר, יודע שהוא אמר אותם דברים שלושים שנה קודם לכן, רק בצורה פחות מגניבה.
[4] ב XP נוהגים לומר: תן ללקוח מה שהוא צריך, לא מה שהוא מבקש.
[5] לדוגמא, כשאתם עושים ביטוח לרכב ומבקשים מכם לבדוק את האזעקה, אתם רק רוצים לקבל את האישור. האזעקה רק עצבנה והטרידה וכבר שמעתם סיפורים שהיא לא כ"כ יעילה. מבחינת רבים מאיתנו עדיף שיתנו לנו אישור ושהאזעקה לא תפעל יותר לעולם. כמה הקפדה אתם צופים מיצרן האזעקות שנזרק מלקוחות כי המוצר שלו פעל מספר רב מדי של פעמים? בעיקר הקפדה שהאזעקה לא תפעל לשווא - אני מאמין.
[6] מדידה של איכות תוכנה הוא דבר מורכב ובעייתי, במיוחד מכיוון שאין מדדים מוסכמים ל"מהי איכות". לכן לכל מחקר או נתון על איכות תוכנה יש להתייחס בזהירות.
האם זה קרב מחוייב המציאות? האם לא ברור שהפעם "אנחנו" צודקים?
שאלה: כאשר בא אליך איש מוצר ורוצה עוד פיצ'רים על חשבון איכות, מה אתה אומר לו?
- תשובה פופולארית בקרב כמה אנשי פיתוח יכולה להיות: "בלי דיבורים: אוחז בחפץ כהה וחובט בו. מטמין את הגופה בירקון. PM טוב הוא PM... שמעדיף איכות"
- תשובה קצת יותר מכובדת היא "אם רוצים פיצ'ר נוסף יש לבטל פיצ'ר קיים או להאריך את הגרסה בזמן הנדרש, זמן פיתוח לא גדל על עצים, ועל איכות לא מתפשרים".
- התשובה שלי דווקא היא זו: "זה לא ויכוח ביני לבין הPM. זו שאלה ארגונית שהארגון צריך לענות עליה"
באופן אישי אני אעדיף להילחם על האיכות, אך אני מנסה להתעלות לפעמים על הנטייה הטבעית - ולראות את התמונה הכוללת. אם הארגון בוחר באיכות אז בוודאי יהיה קל לחזור לאופצייה מס' 2.
במבט יותר מפוכח ופחות דרמטי אפשר לומר שיש פה ניגוד עיניינים מובנה ומכוון שתורם לרוב תוצאה טובה יותר של הארגון.
Best Practices: פיתוח כנגד שיווק
במשך השנים נוצרו כמה פרקטיקות בעולם הפיתוח שאין מערערים עליהן (כלומר, היינו רוצים שכך יהיה):
- DRY - אל תחזור על עצמך
- Bake Quality In - איכות צריכה להיות בכל שלב בתהליך
- Abstraction / Loose Coupling - צמצם תלויות בקוד כך ששינוי באזור אחד לא יזעזע אזורים אחרים.
- Naming / Clean Code - קוד "ספרותי" שמתאר את עצמו.
- וכו'
אנשי השיווק העתיקו מאיתנו, המפתחים, את הרעיון של Best Practices ויצרו רשימה משלהם. הנה כמה הרלוונטיים לדיון:
רגל בדלת
בניגוד לקונוטציה האגרסיבית של "לדחוף את הרגל" כדי לחסום דלת נסגרת (שמתאימה לתיאור של איש מכירות אגרסיבי במיוחד), "רגל בדלת" לרוב מתייחס לצורה המנומסת (האמריקאית אולי) של נקודת הכניסה לבית הלקוח. במקום לשאול: "האם אתם רוצים לקנות שואב אבק חדש?" יפתח איש המכירות בשאלה "האם גם לכם האובך האחרון לכלך את הבית?" - שאלה תמימה ולא מחייבת. "כן בוודאי - פשוט נורא" המשכתם, פתחתם את הדלת לרווחה ואפשרתם לאיש המכירות לחצות פיסית את קו הדלת ולהניח שם רגל. הקרבה המעטה הזו (והכניסה בהסכמה למרחב האישי שלנו) היא כבר נקודת פתיחה טובה בהרבה להצעה עסקית.
באופן דומה אנשי שיווק ירצו שתספקו להם פיצ'ר, אולי חלקי ולא עובד, שאיתו יוכלו לגשת ללקוח ולומר "גם לך יש בעיות ABC"? "יש לנו דווקא משהו מעניין לדבר עליו" - יפתחו דיון עם לקוח שזקוק לפ'יצר אך ירגיש הרבה יותר נוח לדבר עם מישהו שיש לו משהו ולא רק רעיון באוויר. עד שיגיע הזמן למסור את הפתרון ללקוח, הפיתוח יוכל כבר לפתח את הפי'צר כמו שצריך [2].
Feature Superiority
הרבה יותר קל למכור מוצר שיש לו רשימה גדולה יותר של פ'יצרים. ללקוח זו מרגישה קנייה בטוחה יותר ומי שמוכר אותה נתפס מנוסה יותר. ב SAP שמעתי את האמרה הבאה (שנכונה גם לחברות אחרות): "The Suite Always Wins". כלומר ל SAP לא חייב להיות מוצר לניהול משאבי אנוש הכי טוב או כלי לניהול פרוייקטים הכי טוב, אך כשהיא מוכרת חבילה שמחליפה 10 מוצרים שונים ויותר - יש לה ייתרון אדיר. עקרון זה נכון כאשר מדובר במוצרים נפרדים תחת אותה קורת גג ("One Stop Shop") ואפילו קצת יותר כאשר מדובר במוצרים שמדברים אחד עם השני ("Suite").
ייתכן והרצון להגיע ל Feature Superiority דוחף לבקש עוד פ'יצרים על חשבון סגירת ושיפור הקיימים. למי שמכיר את תאוריית האוקיינוס הכחול[3] (או בכלל את פורטר) - זו נראית לעיתים קרובה טעות נפוצה של אנשי שיווק ולא Best Practice, אך נראה שאנשי שיווק לא מעטים פספסו את השיעור הזה ב MBA שלהם. אציין שאנשים נבונים שעבדתי איתם עשו, למיטב הבנתי, את הטעות הזו. נראה שתחת לחץ ותחרות (אנשי מכירות שמכפישים את שמכם בחברה כי הפסידו עסקה בגלל המחסור בפ'יצר X) - קל מאוד להגיע לשם. באופן אירוני, מתחרה שלו יש עדיפות במספר הפ'יצרים ואולי הגיע לשם בעקבות לחץ, עלול לגרור את החברה שלכם לריצה אחר רשימת פ'יצרים במקום להתבונן על התמונה השלמה.
Check-box Feature
לעיתים קרובות, תהליך מכירה של תוכנה ארגונית עובד כך: הלקוח שולח RFP - Request For Proposal לכמה ספקי תוכנה שנשמע שיש להם תוכנה שמתאימה לצורכיו. ה-RFP הוא מסמך עם רשימה ארוכה של דרישות "יש"/"אין" שעל הספק למלא. מי שעומד בדרישת הסף עובר לשלב הבא בו משוחחים על הפתרון, עושים פיילוט וממשיכים למכירה. אם חסר לכם ברשימת הדרישות פ'יצר שמוגדר כקריטי - יסננו אתכם עוד בשלב ה RFP, לעיתים ללא הבנה מה אתם במקום לאותה הבעיה, ללא ודאות שזה באמת מה שנחוץ וכו'. על מנת לעבור את התהליך יש לסמן כמה שיותר סימני V.
זה תהליך דומה מאוד לשילחת קורות חיים. מתכנת עם 10 שנות ניסיון ב Web יציין ידע ב JQuery, Comet, Ajax ו Cross-Browser DOM אבל אולי ידלג על HTML ו CSS. הוא עלול לגלות שאשת כח-האדם שעושה Pattern-matching על קורות החיים שלו פשוט מסננת אותו "אין לו מספיק ידע" כי "צריך ידע ב CSS" או CSS3 או XHTML (מול HTML - הבדל סמנטי) וכו'.
מה הפתרון? על מנת לעבור את הסינון הזה אותו מתכנת יכתוב אינסוף מושגים הקשורים לווב, שחלקם אולי לא כ"כ נכונים על מנת להגיע למראיין המקצועי (כלומר - טכנולוגי) הראשון שיוכל להתרשם באמת מכישוריו.
באופן דומה מנהלי מוצר רוצים להציג רשימה ארוכה של יכולות במוצר. לעיתים הם יאתרו פ'יצרים שאותם לקוחות מבקשים אבל אף פעם לא משתמשים בהם. כיצד ייתכן שלקוח דורש פ'יצר שהוא לא מתכוון להשתמש בו?
- פ'יצר נשמע מועיל, אך רק לאחר ניסיון שימוש של כמה שנים ניתן להבין שהוא לא ישים.
- המתחרה זיהה שלו יש פ'יצר ייחודי (חסר שימוש) והוא מפרסם ומקדם אותו בכל אירוע השקה - הלקוח מושפע מהלחץ ומבקש גם ("אם הם מדגישים את זה כך - כנראה יש פה משהו חשוב שאני לא מבין עדיין")
- פ'יצרים שנדרשים על ידי גורמים בעלי השפעה בארגון הלקוח, ללא הבנה עמוקה של הנושא. ללא סיפוק הפ'יצר - יקשו על העסקה מלהתקיים.
פי'צר כזה מסומן כ Check-box Feature - תחמושת חשובה שאיש השיווק רוצה לספק לאנשי המכירות שלו. הם יוכלו לטעון "בטח - גם לנו יש Mobile Cloud EAI Service Integration 2.0 ואולי יוכלו לעבור איזה Demo של כמה דקות. אבל הפ'יצר עצמו לא באמת צריך לעבוד על מנת למכור או אפילו ליצור לקוח מרוצה - חבל לבזבז עליו זמן פיתוח.
מה עדיף? לחנך את הלקוחות/שוק (והגרורות שלהם) שזה פ'יצר מיותר (קשה מאוד) או לבקש מהמפתחים פ'יצר חלקי ונבוב בהשקעה מינימלית (יחסית קל)? האופצייה השנייה ישימה יותר ועובדת טוב יותר (לצערנו, המפתחים).
מיותר לציין שהמפתחים שנתקלים ב Check-box Feature נוטים להסיק שאיש המוצר פשוט טיפש, חסר ערכים ומדרדר את החברה לתהום.
למכור סיפור
מנהלים בכירים הם לרוב אינם אנשי-פרטים. כבר מזמן הפסיקו לעסוק בפרטי התפעול של החברה - הם אנשי חזון. ואם הם המנהלים בחברת הלקוח - יש סיכוי טוב שהם אלו ש"יחתכו" בעסקאות גדולות. במקום להגיע לליבם עם פ'יצר כזה או אחר - קל יותר להגיע לליבם בעזרת חזון. סיפור. "החברה שלנו תחבר את כל מערכות המחשוב ותיצור תמונה אחידה" הוא סיפור טוב. מנהל טוב מבין את הייתרון ביכולת כזו. לעיתים קרובות מאוד הסיפור איננו התיאור הטוב ביותר של המציאות, אלא הרחבה רעיונית משמעותית של עובדה קיימת (קרי - הגזמה פרועה).
לדוגמא, ייתכן והסיפור הנ"ל מסופר על מערכת שאוספת סטטוסים ב SNMP ממגוון מערכות, כ"א בשפה שלה, הנתונים לעיתים לא מסופקים ע"י המערכות, וכדי להגיע לתובנה איש ה IT צריך לחפור לא מעט בנתונים שנאספו. בכל זאת, אם המתחרים מוכרים סיפור - לא תרצו לשלוח את אנשי המכירות שלכם עם "פ'יצר": "לא באים עם סכין לקרב אקדחים", אומרים באמריקאית.
אנחנו בפיתוח מעדיפים לדייק בפרטים ולא "לנפח". אנו נעדיף לקרוא לאובייקט "SnmpMessage" ולא "SystemWellBeingReport" (קצת מוגזם - לא?). אנו נעדיף "XmlParser" ולא "Cross-SystemTranslator". לכן כשאנחנו רואים את החומר השיווק של המוצר שפיתחנו, בעוד אנו יודעים מה הוא באמת עושה, אנו עלולים להיות מופתעים. "הם חיים בעננים" אנו מספרים על אנשי השיווק, "רואים סרטים בעננים", מוסיפים. קרוב לודאי שהסבר כמו "הלקוחות שמחים לקנות את הסיפור, זה נותן להם אמון שאנחנו מבינים אותם ויודעים על מה אנחנו מדברים" רק מעצים את תחושת הניכור.
סיכום
טעות נפוצה היא לחשוב ש"המוצר מוכר את עצמו" או ש"מספיק מוצר טוב". אמנם יש מעט מוצרים שנמכרים ללא שיווק (למשל מנוע החיפוש של גוגל) ולמשתמש ישירות, אך את רוב המוצרים עדיין מוכרים בעזרת אנשי מכירות, שיווק וחומר פרסומי ועל המוצר למלא חלק במערכה. הלקוחות שלנו אינם תמיד מבקשים את מה שהם צריכים [4], השוק לעיתים קרובות "טיפש" (או "לא רציונלי") וזו הטייה שחשוב להבין להתמודד איתה על מנת להצליח בעסקים. לא מעט סטראט-אפים נופלים על הטעות הזו. אם לא שמתם לב - ברוב חברות ההייטק, לפיתוח מוקצים כ 10-15% מהתקציב ולשיווק - כ 40-60% מהתקציב. לא סתם.
בכדי לסגור מעגל, אחזור לנושא האיכות מול פ'יצרים שממנו התחלתי.
מחקר מעניין שקראתי (לא מצאתי את המקור) הציג עובדה מעניינת: מה הגורם שמסביר בצורה טובה את איכות התוכנה?
יותר מותק החברה,
יותר משנות הנסיון של המפתחים,
יותר מגודל החברה,
ויותר מרמת המפתחים (נמדד ע"י רמת השכר),
- התחום שבו עוסקת החברה משפיע על האיכות.
בתחומים שבהם איכות היא חיונית להצלחה עסקית (למשל מכשור רפואי, ניהול כספים) - תהיה איכות גבוהה ובתחומים בהם הדרישה פחות מחמירה (למשל תוכנה שהמצאותה נדרשת על מנת לעמוד בתקן [5], מה שנקרא Compliance) - תהיה איכות נמוכה יותר [6].
הלקוחות יאמרו לנו מה רמת האיכות הנכונה בעבורם, והם יאמרו זו בצורה עקיפה. לרוב אלו יהיו מעשים (אי קנייה / קנייה ממתחרה) ולא דיבורים (הרי, מי לא רוצה איכות?).
אפרופו, המנהלים בארגון שלכם כמעט ותמיד יכריזו שהם רוצים איכות - אך המעשים בשטח הם אלו שקובעים. על מה מקדמים אנשים? על יותר פ'יצרים או על יותר איכות? לא מזמן שוחחתי עם VP R&D של חברה קטנה שהפסידו עסקת ענק (עבורם) בגלל באגים שצצו בתהליך בחינת המוצר ע"י הלקוח. "המוצר שלכם נחמד, אבל יש בו יותר מדי תקלות" הסביר הלקוח מדוע הוא דוחה את העסקה. לא נראה שיש מוטיבציה טובה מזו להשקיע באיכות. האם הלקוחות שלכם דוחים מוצר על איכות או רק על מחסור פ'יצרים?
מה שחשוב להבין הוא שכדי להצליח אנו זקוקים לשני הצדדים של המשוואה, מוצר טוב + שיווק / אסטרטגיה טובה, ושאנשי שיווק טובים מבינים את הלקוחות - ולא בהכרח את המפתחים. אני מקווה בפוסט זה לגשר עוד קצת על הפער בין הפיתוח ולשיווק ולהגביר את ההבנה ההדדית.
תודה לניר דרמר על ההערות המועילות על הפוסט.
[1] שיווק נשמע לי תמיד קשור לשוק, פרסום/מכירות ופחות תכנון אסטרטגי או הגדרת המוצר - אך כשמדובר בשיווק מדובר על שניהם.
[2] או שלא. יש פה סיכון מסוים. אנחנו בפיתוח נוטים לזכור היטב את המקרים שבהם זה לא עבד - אבל הרבה פעמים זה עובד יפה. בכל זאת זהו Best Practice ולא Flawless practice.
[3] תאוריית האוקיינוס הכחול גורסת שבמקום להלחם עד זוב דם עם כרישים אחרים (להלן, אוקיינוס אדום) כדאי לנו למצוא נישה ייחודית בה לא תהיה לנו תחרות. מה שנקרא בידול. מי שמכיר את אבי האסטרטגיה העסקית, מייקל פורטר, יודע שהוא אמר אותם דברים שלושים שנה קודם לכן, רק בצורה פחות מגניבה.
[4] ב XP נוהגים לומר: תן ללקוח מה שהוא צריך, לא מה שהוא מבקש.
[5] לדוגמא, כשאתם עושים ביטוח לרכב ומבקשים מכם לבדוק את האזעקה, אתם רק רוצים לקבל את האישור. האזעקה רק עצבנה והטרידה וכבר שמעתם סיפורים שהיא לא כ"כ יעילה. מבחינת רבים מאיתנו עדיף שיתנו לנו אישור ושהאזעקה לא תפעל יותר לעולם. כמה הקפדה אתם צופים מיצרן האזעקות שנזרק מלקוחות כי המוצר שלו פעל מספר רב מדי של פעמים? בעיקר הקפדה שהאזעקה לא תפעל לשווא - אני מאמין.
[6] מדידה של איכות תוכנה הוא דבר מורכב ובעייתי, במיוחד מכיוון שאין מדדים מוסכמים ל"מהי איכות". לכן לכל מחקר או נתון על איכות תוכנה יש להתייחס בזהירות.
מעולה.
השבמחק