6 צעדים שיהפכו את ה-R&D למנוע מרכזי שמקדם את הביזנס

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

מחלקת ה-R&D יכולה לחשוב על דברים אחרת מיתר הארגון (צילום: Dreamstime)

מאת אורן בילגורי, VP R&D ב-Artlist

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

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

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

אבל איך עושים את זה בפועל?

אינטגרציה בין מחלקת המו"פ ל-Business ב-6 צעדים

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

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

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

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

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

אחרי שמבנה הפיתוח הוגדר בצורה נכונה, אפשר להרחיבו באופן מהיר ולהבין, לדוגמה, מה יכול להיות מפותח ב-Outsource ומה צריך להיות מפותח In House. המבנה יכול לתת לכל צוות וקבוצה Ownership ברור על חלקם בחברה ולייצר Engagement חזק יותר ל-Business.

3. ארכיטקטורה טכנית. כדי שהצוותים יוכלו לפעול במינימום תלויות, בנוסף למבנה הפיתוח יש צורך להתאים את תפיסת הארכיטקטורה הטכנית. לדוגמה, מצב שבו שני צוותים האחראים יחד על אותו Service/Component גורם לכך שאף אחד מהם בסוף לא באמת אחראי על אותו Service/Component. הפרדת התלויות במערכת צריכה להיות כמה שיותר ברורה ומתורגמת למבנה הפיתוח, והשימוש ב-Microservices יכול לעזור לבנות את הארכיטקטורה בצורה הדרגתית בהתאמה לחלוקה המוצרית. אפשר להשתמש גם בעקרונות של Domain Driven Design כדי לתכנן מערכת טכנולוגית לצוותים יותר עצמאיים המכוונים לביזנס.

הארכיטקטורה של Uber (צילום מסך מאתר medium)

4. יחסי Product ו-R&D. במרבית המקרים, ה-Product בחברה יהיה הכי קרוב לצד העסקי. שותפות של מוביל צוות פיתוח ומנהל מוצר היא חיונית להצלחת התהליך. מוביל הפיתוח ומנהל המוצר צריכים לעבוד כל הזמן על השותפות ביניהם ועל חלוקת האחריות, והם חייבים לתת מקום והכלה אחד לשני כדי שהקשר הזה יצליח. כמובן, מוביל הפיתוח צריך להסתכל גם על הצד הביזנסי ומנהל המוצר על הצד הטכני. ה"ניתוק" של מנהל המוצר רוב הזמן מהצד הטכני עוזר לצוות להסתכל על היעדים שלו מבחוץ ולא רק מבפנים, ופעמים רבות כאשר מגיעים מתוך הקוד ומהצד הטכני, האינסטינקט הטבעי הוא לראות את המגבלות.

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

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

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

5. הגדרת יעדים ותהליכים. לכל צוות בפיתוח צריכים להיות יעדים הנגזרים מיעדי החברה. אצלנו לדוגמה נעשה שימוש ב-OKRs על מנת להגדיר את יעדי החברה, ובהתאם כל המחלקות השונות מגדירות את ה-OKRs שלהן. המושג הוא ראשי תיבות של Objective and Key Result – מתודולוגיית עבודה של ניהול מטרות והתמקדות ביעדים הארגוניים, המאפשרת ליצור סביבת עבודה המבוססת על פוקוס ביעדים, להגדיל את השקיפות וליישר קו בין כל המעורבים בארגון בנוגע לאסטרטגיה הרחבה.

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

לדוגמה, העלאת ה-Revenue באמצעות שיפור ה-Page speed משפיע על הדירוג בגוגל, שמשפיע על ה-Traffic האורגני לפלטפורמה, שמשפיע על מספר המבקרים באתר, שיחד עם ה-Conversion Rate משפיע על יעד של הגדלת מספר המנויים לאתר וכמובן בסוף על ה-Revenue. דוגמה נוספת: הורדת עלויות ענן יכולה להיגזר מיעד לשיפור ה-Gross Margin של החברה. בציוץ הזה ניתן לראות כיצד Segment הגדירה את הורדת עלויות הענן כיעד חברה במטרה לשפר את ההכנסות.

עץ המטריקות של גוגל (צילום מסך מאתר medium)

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

המבנה של מסגרת העבודה SAFe (צילום מסך מאתר Scaled Agile)

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

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

הכתבה בחסות Artlist

Artlist היא חברת קריאייטיב וטכנולוגיה מובילה, המספקת ליוצרי תוכן ברחבי העולם תוכנות חדשניות לעריכת וידאו ותמונה בנוסף ליותר מ-880 אלף מדיות דיגיטליות עם רישיון גלובלי ייחודי שמכסה את כל סוגי תכני הוידאו. Artlist מעסיקה כ-300 עובדים בישראל ובעולם, ובמהלך השנה הקרובה צפויה החברה לגייס כ-150 עובדים נוספים, בהם מפיקים מוזיקליים, עורכים ויוצרי וידאו, טכנאי סאונד, Product & Design, אנשי דאטה, מרקטרים, תוכן, R&D, קריאייטיב, BI, שירות לקוחות, HR, Legal ו-Finance.
לחצו כאן כדי להצטרף אלינו

כתב אורח

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

הגב

4 תגובות על "6 צעדים שיהפכו את ה-R&D למנוע מרכזי שמקדם את הביזנס"

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

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

סידור לפי:   חדש | ישן | הכי מדורגים
יוני
Guest
התיאור פשטני למדי וגם מועד לפורענות בנקודות הרגישות, למשל: 1. במידה והצוותים אורגנים לפי מה שמתואר בכתבה, מי אחראי על תשתיות? על פיתוחים קרוס-צוותיים? האם יש צוות infrastructure, האם הוא מחובר לביזנס, מה קורה שהתשתית תופסת חלק ממש משמעותי מה-code base אז האם החלק המשמעותי הזה מנותק מהביזנס? 2. למה צריך מוביל פיתוח? למה לא להסתפק בשילוב של PO ו-tech lead? למה בכלל להפריד בין הPO והצוות, למה שה-PO לא יהיה חלק מהצוות, אולי ראש הצוות. 3. איך שיפור תשתיות מתורגם לביזנס? איך שדרוג גרסה מתורגם לביזנס, האם יש לנו בכלל כלים לתרגם שדרוג package ל-revenue? איך מתמחרים שיפור תשתית… Read more »
Itay
Guest

Well wre! Like!

בננית
Guest

איזה חתיך!! הוא רווק במקרה??

עודד חזן
Guest

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

wpDiscuz

תגיות לכתבה: