יש הצעות שקשה לסרב להן

12 בנובמבר 2010


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




  1. אנשי המכירות מתחילים לשאול שאלות איך למכור ללקוחות של השוק הראשון את המוצר של השוק השני.


  2. כמות הבקשות ליישם תכונות של המוצר הראשון במוצר השני ולהיפך הולכת וגדלה.

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


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


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




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


  2. חברת Radware, שעל פי מקורות זרים מועמדת למכירה ל – IBM ו – HP לפי שווי של מליארד דולר, מתמחה בהתקני תקשורת בכניסה למרכזי מחשבים. פתרון ה – OnDemand Switch שהחברה הציגה לפני כשנתיים, פועל בצורה דומה, התקן התקשורת נמכר במחיר ראשוני נמוך עבור תמיכה בנפח תקשורת נמוך יחסית. עם הזמן הלקוח יכול להוסיף יכולות נוספות או להגדיל את נפח התקשורת הנתמך וזאת ע"י הכנסת רשיון תוכנה בלבד ללא שינויי חומרה.


  3. מערכות SaaS כדוגמת Gmail מבוססות על מתן פתרון ראשוני בחינם ו/או במחיר נמוך, כאשר המגבלות (מספר משתמשים, נפח אחסון וכו') משוחררות תמורת מחיר אטרקטיבי יותר או פחות. דוגמה טובה היא חברת Kampyle אשר מספקת פתרון חינמי לקבלת תגובות ממשתמשים באתר ונותנת פתרון חינמי (שומחבא בתחתית העמוד) וסדרה של תמחירים שהבדל העלויות בינהם מבחינת החברה מזערי, אבל מבחינת השורה התחתונה משמעותי מאוד.

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


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


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

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




  1. ייצרו הצלחות: התחילו בניצול הזדמנויות קטנות ויצרו הצלחות מהירות במקומות עם סיכון נמוך.


  2. הסבירו את ההגיון האסטרטגי מאחורי העניינים.


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

איך מצמצמים סיכון?




  1. מגדילים את ההשקעה ב – QA בפרק הזמן הרלוונטי.


  2. מייצרים מומנטום של הצלחה.


  3. חושפים את היתרונות כלפי חוץ, כולל שיקוף של ההצלחות והצגה של תכונות חדשות שנוספות למוצר ושידור של היתרונות לאנשי השיווק והמכירות. קבלת הרוח הגבית מגורמים אלו, תסייע להקטין התנגדויות בשל חוסר יציבות ו/או ירידת איכות שיכולות להתלוות לתהליך. אם אנשי השיווק שלכם ממוקדים ביכולות עתידיות, הסבירו להם כיצד הפיתוח הבא ימומש לשני המותגים במקביל תוך חסכון של 40-50% בזמני ועלויות הפיתוח.

למה HTML5 הולך להצליח בגדול?
בד"כ אני לא נוטה לקחת הימורים, אבל אני מאמין גדול בהצלחתו של תקן ה – HTML5. מה הקשר של זה לפוסט?
אחת הבעיות הקשות ביותר בפיתוח למערכות מובייל כיום הוא ריבוי פלטפורמות הפיתוח, עבור Symbian תידרשו לכתוב ב – C או ב – Java, עבור BlackBerry ו – Android ב – Java, עבור iPhone תאלצו ללמוד Objective C ואם מיקרוסופט תצליח עם Windows Phone תאלצו להתמודד גם עם Silverlight. אם יש לכם תחושה שתאלצו להמציא את הגלגל לפחות 5 פעמים אתם צודקים.
מה היה קורה אם יכולתם לפתח פעם אחת לכל הפלטפורמות? כנראה שתראו ירידה של 80% בעלות תחזוקת התוכנה למוצרי ה – Mobile שלכם.
HTML5 יתן את פתרון הקסם הזה, ולכן הוא ידחף באגרסיביות ע"י גופי פיתוח התוכנה, שהפתרון הזה יחסוך להם עלויות גדולות.


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


מה האסטרטגיה שלכם? מה היתרון שאתם יצרתם? האם ניהלתם מהלך של מיזוג? שתפו אותנו…


נהנית מהפוסט? רישום לבלוג הפתוח למנהל הפיתוח יבטיח לכם עדכונים חדשים ישירות לדוא"ל!


ממשיכים לפתח,
משה קפלן


Follow MosheKaplan on Twitter


הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

4 תגובות

  1. רן בר-זיק14 בנובמבר 2010 ב 21:14

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

    1. לוקחים את שני המוצרים ועושים רשימה של הפיצ'רים הטובים והבאגים.
    2. מפטרים מיידית צוות מפתחים אחד.
    3. מודיעים לצוות השני ש'שעכשיו צריך להשקיע יותר' ומבטלים את כל החופשות. כולל את ירח הדבש של אשת ה-QA בת ה-37.
    4. כותבים מסמך דרישות ומצרפים כמה צילומי מסך. זה מספיק.
    5. מציבים לוח זמנים בלתי הגיוני.
    6. מכנסים ישיבת צוות כל שבוע וצורחים על ראש הצוות מדוע הוא לא עומד ביעדים. מן הסתם בנוכחות אנשי הצוות שלו.
    7. ממתינים עד שראש הצוות ושני מפתחים מובילים מתפטרים. מגייסים בבהילות עוד ראש צוות ושני מפתחים ומחכים שהם או אחרים מהצוות יעזבו. ממשיכים עד שיצא לחברה שם כל כך רע שהיא לא מצליחה לגייס מפתחים מהתחום הרלוונטי גם בעבור משכורת כפולה מהמשכורת הממוצעת בשוק.
    8. מגייסים מפתחים מתחום אחר ומכשירים אותם לעבוד בתחום הזה.
    9. מאשימים את מנהל הפרויקט וגורמים לפיטוריו.
    10. מוציאים את המוצר המאוחד. בשלב הזה יש לו את כל הבאגים משני המוצרים האחרים.

    הגב
  2. Moshe Kaplan14 בנובמבר 2010 ב 22:49

    שלום רן,

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

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

    ממשיכים לפתח,
    משה קפלן

    הגב
  3. רון קליין3 בינואר 2011 ב 18:13

    פוסט יפה ומעניין, תודה!
    ולגבי ה HTML5 – כאן אני דווקא מסתייג: למרות ההבטחה הגדולה, זה לא יפתור לנו את כל הבעיות שקיימות כבר זמן רב, כולל streaming video ועוד עניינים.
    נאלץ לחכות, כנראה, ל HTML5.1 או לפחות ל service pack
    🙂

    הגב
  4. Moshe Kaplan4 בינואר 2011 ב 19:44

    שלום רון,

    תודה,
    לגבי HTML5 כנראה שעד סוף השנה נדע יותר עם העסק תופס נפח או שיגמר כמו ה – WiMax…
    אנחנו מתחילים בבדיקות של הנושא בקרוב, מבטיח לעדכן 🙂

    ממשיכים לפתח,
    משה קפלן

    הגב