הקרב בתעשיית התוכנה: Development vs. Marketing

אז מה יותר חשוב בחברה, הפיתוח או השיווק? והאם התשובה של אנשי המכירות או התוכנה תואמות את תשובותיהם של הלקוחות המקבלים את המוצר?

מקור: cc-by ANTONIO PROHIAS

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

כמות מול איכות

שאלה: כאשר בא אליך איש מוצר ורוצה עוד פיצ’רים על חשבון איכות, מה אתה אומר לו?

  • תשובה פופולארית בקרב כמה אנשי פיתוח יכולה להיות: “בלי דיבורים: אוחז בחפץ כהה וחובט בו. מטמין את הגופה בירקון. PM טוב הוא PM… שמעדיף איכות”
  • תשובה קצת יותר מכובדת היא “אם רוצים פיצ’ר נוסף יש לבטל פיצ’ר קיים או להאריך את הגרסה בזמן הנדרש, זמן פיתוח לא גדל על עצים, ועל איכות לא מתפשרים”.
  • התשובה שלי דווקא היא זו: “זה לא ויכוח ביני לבין הPM. זו שאלה ארגונית שהארגון צריך לענות עליה”

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

Best Practices: פיתוח כנגד שיווק

במשך השנים נוצרו כמה פרקטיקות בעולם הפיתוח שאין מערערים עליהן (כלומר, היינו רוצים שכך יהיה):
  • DRY – אל תחזור על עצמך
  • Bake Quality In – איכות צריכה להיות בכל שלב בתהליך
  • Abstraction / Loose Coupling – צמצם תלויות בקוד כך ששינוי באזור אחד לא יזעזע אזורים אחרים.
  • Naming / Clean Code – קוד “ספרותי” שמתאר את עצמו.
  • וכו’
אנשי השיווק העתיקו מאיתנו, המפתחים, את הרעיון של Best Practices ויצרו רשימה משלהם. הנה כמה הרלוונטיים לדיון:

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

באופן דומה, אנשי שיווק ירצו שתספקו להם פיצ’ר, אולי חלקי ולא עובד, שאיתו יוכלו לגשת ללקוח ולומר “גם לך יש בעיות ABC”? “יש לנו דווקא משהו מעניין לדבר עליו” – יפתחו דיון עם לקוח שזקוק לפ’יצר אך ירגיש הרבה יותר נוח לדבר עם מישהו שיש לו משהו ולא רק רעיון באוויר. עד שיגיע הזמן למסור את הפתרון ללקוח, הפיתוח יוכל כבר לפתח את הפי’צר כמו שצריך – או שלא. יש פה סיכון מסוים. אנחנו בפיתוח נוטים לזכור היטב את המקרים שבהם זה לא עבד – אבל הרבה פעמים זה עובד יפה. בכל זאת זהו Best Practice ולא Flawless practice.

Feature Superiority – הרבה יותר קל למכור מוצר שיש לו רשימה גדולה יותר של פ’יצרים. ללקוח זו מרגישה קנייה בטוחה יותר ומי שמוכר אותה נתפס מנוסה יותר. ב-SAP שמעתי את האמרה הבאה, שנכונה גם לחברות אחרות: “The Suite Always Wins”. כלומר ל-SAP לא חייב להיות מוצר לניהול משאבי אנוש הכי טוב או כלי לניהול פרוייקטים הכי טוב, אך כשהיא מוכרת חבילה שמחליפה 10 מוצרים שונים ויותר – יש לה ייתרון אדיר. עקרון זה נכון כאשר מדובר במוצרים נפרדים תחת אותה קורת גג – “One Stop Shop” – ואפילו קצת יותר כאשר מדובר במוצרים שמדברים אחד עם השני – “Suite”.

ייתכן והרצון להגיע ל Feature Superiority דוחף לבקש עוד פ’יצרים על חשבון סגירת ושיפור הקיימים. למי שמכיר את תאוריית האוקיינוס הכחול[1] או בכלל את פורטר – זו נראית לעיתים קרובה טעות נפוצה של אנשי שיווק ולא Best Practice, אך נראה שאנשי שיווק לא מעטים פספסו את השיעור הזה ב-MBA שלהם. אציין שאנשים נבונים שעבדתי איתם עשו, למיטב הבנתי, את הטעות הזו. נראה שתחת לחץ ותחרות הכוללת אנשי מכירות שמכפישים את שמכם בחברה כי הפסידו עסקה בגלל המחסור בפ’יצר X – קל מאוד להגיע לשם. באופן אירוני, מתחרה שלו יש עדיפות במספר הפ’יצרים ואולי הגיע לשם בעקבות לחץ, עלול לגרור את החברה שלכם לריצה אחר רשימת פ’יצרים במקום להתבונן על התמונה השלמה.

מקור: cc-by alstin.com

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”. לכן כשאנחנו רואים את החומר השיווק של המוצר שפיתחנו, בעוד אנו יודעים מה הוא באמת עושה, אנו עלולים להיות מופתעים. “הם חיים בעננים” אנו מספרים על אנשי השיווק, “רואים סרטים בעננים”, מוסיפים. קרוב לודאי שהסבר כמו “הלקוחות שמחים לקנות את הסיפור, זה נותן להם אמון שאנחנו מבינים אותם ויודעים על מה אנחנו מדברים” רק מעצים את תחושת הניכור.

סיכום

מקור: flickr, cc-by Ken and Nyetta

טעות נפוצה היא לחשוב ש”המוצר מוכר את עצמו” או ש”מספיק מוצר טוב”. אמנם יש מעט מוצרים שנמכרים ללא שיווק, כמו למשל מנוע החיפוש של גוגל, אך את רוב המוצרים עדיין נמכרים בעזרת אנשי מכירות, שיווק וחומר פרסומי ועל המוצר למלא חלק במערכה. הלקוחות שלנו אינם תמיד מבקשים את מה שהם צריכים, השוק לעיתים קרובות “טיפש” (או “לא רציונלי”) וזו הטייה שחשוב להבין להתמודד איתה על מנת להצליח בעסקים, שכן לא מעט סטראט-אפים נופלים על הטעות הזו. אם לא שמתם לב – ברוב חברות ההייטק, לפיתוח מוקצים כ 10-15% מהתקציב ולשיווק – כ 40-60% מהתקציב. לא סתם.

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

בתחומים שבהם איכות היא חיונית להצלחה עסקית, למשל מכשור רפואי, ניהול כספים – תהיה איכות גבוהה ובתחומים בהם הדרישה פחות מחמירה, כמו למשל תוכנה שהמצאותה נדרשת על מנת לעמוד בתקן [2], מה שנקרא Compliance – תהיה איכות נמוכה יותר. הלקוחות יאמרו לנו מה רמת האיכות הנכונה בעבורם והם יאמרו זו בצורה עקיפה. לרוב אלו יהיו מעשים (אי קנייה / קנייה ממתחרה) ולא דיבורים (הרי, מי לא רוצה איכות?).

אפרופו, המנהלים בארגון שלכם כמעט ותמיד יכריזו שהם רוצים איכות – אך המעשים בשטח הם אלו שקובעים. על מה מקדמים אנשים? על יותר פ’יצרים או על יותר איכות? לא מזמן שוחחתי עם VP R&D של חברה קטנה שהפסידו עסקת ענק (עבורם) בגלל באגים שצצו בתהליך בחינת המוצר ע”י הלקוח. “המוצר שלכם נחמד, אבל יש בו יותר מדי תקלות” הסביר הלקוח מדוע הוא דוחה את העסקה. לא נראה שיש מוטיבציה טובה מזו להשקיע באיכות. האם הלקוחות שלכם דוחים מוצר על איכות או רק על מחסור פ’יצרים?

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

תודה לניר דרמר על ההערות המועילות על הפוסט.

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

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

הפוסט פורסם לראשונה ב-Software Archiblog – בלוג ארכיטקטורת תוכנה

Avatar

ליאור בר-און

ליאור בר-און הוא Chief Architect בחברת סטארטאפ ישראלית גדולה.

הגב

7 תגובות על "הקרב בתעשיית התוכנה: Development vs. Marketing"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
ירון נוה
Guest

מאמר בנושא חשוב שלא עוסקים בו מספיק בברנז’ה.

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

Neta
Guest

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

ליאור בר-און
Guest

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

ליאור בר-און
Guest

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

א.כ
Guest
אני כמפתח מאוד מזדהה עם מה שמתואר בפוסט הזה. יש כמה דברים מהצד של המפתח שלטעמי לא מספיק הדגשת: 1. אנשי השיווק מאוד רוצים פיצ’רים אבל כשמשהו מהפיצ’רים האלה בסוף לא עובד כמו שצריך (כי כמובן לא היה זמן לכתוב את זה כמו שצריך ולבדוק את זה כמו שצריך) אז מי אשם? הפיתוח כמובן. 2. אנשי השיווק (וגם מנהלי הפיתוח הרבה פעמים) לא מודעים לכמות העבודה הדרושה כדי לפתח פיצ’ר כמו שצריך. כמה פעמים שמעתי את המשפט “מה הבעיה להוסיף עוד IF ?”. כיוון שהם רואים את המערכת רק מצד הפונקציונליות שלה (מה היא עושה) ולא מצד הארכיטקטורה שלה (איך… Read more »
Neta
Guest
אתה קצת (הרבה) מזלזל באנשי השיווק, שמבינים בד”כ גם ארכיטקטורה וגם מה המשמעות של להוסיף פיצ’ר – או לפחות יודעים לשאול. איש מוצר טוב יבין למה הלקוח דורש משהו, איך אפשר לתת לו את זה בצורה “זולה” (כי לא תמיד מה שהוא רוצה זה מה שהוא באמת צריך, הוא רק לא יודע את זה), מה המשמעויות של זה מבחינת פיתוח ותפעול. אם אנשי השיווק שאתה עובד איתם לא יודעים את הדברים האלו, אז הבעיה היא אצלם ואצל מי ששכר אותם, ןלא אצל “אנשי שיווק” באופן כללי. דרך אגב, איש שיווק טוב גם ידע לשתף את אנשי הפיתוח בתהליכים ובסיבות שמאחורי… Read more »
נאוה שלו
Guest

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

יש רק אמת אחת והיא האמת של הלקוח.

תודה
נאוה.

wpDiscuz

תגיות לכתבה: