ניהול יזמות


30
אוק' 10

בניית מערכת שותפים ואינטגרציות לאתר–למה, מתי ואיך

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

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

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

בסטארטאפ, לרוב תעשו שיתופי פעולה מאחת הסיבות הבאות:

  1. יתרון תחרותי – השלמת הסיפור (use case)
  2. הרחבת שווקים וערוצים
  3. רגל בדלת – הפיכה לחלק בלתי פריד בחיי המשתמש

אני רואה בכל אחת מהדרכים מעין תוספת וירטואלית לחלק אחר בחברה שלכם: מכירות, שיווק וCustomer Success:

יתרון תחרותי

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

הרחבת שווקים וערוצים

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

רגל בדלת

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

לסיכום

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


27
יולי 10

התנהלות וקביעת עדיפות לטיפול בבעיות בזמן קריטי

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

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

הנה עוד כמה נקודות שתעזורנה לכם לעבור את התקופות האלה:

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

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

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

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