בראד פאוור מציג את שיטות העבודה של חברות העוסקות בפיתוח תוכנה, כמו Google ו-HubSpot, ומסביר מדוע פיתוח מהיר אינו בהכרח מסוכן או רשלני, וכיצד ניתן לחזק את סיכויי הצלחתו
"Jim Jarmusch once told me “Fast, Cheap, and Good…pick two. If it’s fast and cheap it won’t be good. If it’s cheap and good it won’t be fast. If it’s fast and good it won’t be cheap.” Fast, cheap, and good…pick (2) words to live by." (Tom Waits)
הצלחה היא עניין של עיתוי. פיתוח והצגת טכנולוגיות, מוצרים ושירותים חדשים לשוק במהירות הינם תנאי קיומי לכל עסק כיום. בשוק הנמצא בשינוי מתמיד, יצירת ערך ללקוח נמדדת סימולטאנית בשלושה מדדים עיקריים: עיתוי, איכות ומחיר. כישלון באחד משלושת המימדים מסכן, ולעיתים חוסם, את הצלחת המוצר או השירות.
המנצח בתחרות יהיה מי שיגיע לאופטימיזציה מדויקת בין העיתוי, האיכות והמחיר המשקפים את הערך שנוצר ללקוח. איחור בהגעת המוצר לשוק – גם אם הוא נובע מחתירה לטכנולוגיה אלגנטית או לייצור חף מתקלות – עלול להפוך את המוצר למיותר ואת היתרון לבזבוז. מכאן שחדשנות בטבעה תהיה כרוכה בניהול סיכון ובמאמץ להגיע לנקודת האופטימום במועד, באיכות ובמחיר המתאימים.
העקרונות של הייצור המסורתי לפיתוח המוצרים – ובייחוד מעבר המוצר בין היחידות הוורטיקאליות במסלול הפיתוח, ההכנה לייצור, הייצור, האינטגרציה והבדיקות המאוחרות – מעלים את רף הסיכון לאיחור בהגעת המוצר לשוק, לפגיעה באיכותו ועלייה בהוצאות, ומכאן לפגיעה ברווחיות בשל אובדן זמן יקר, עלות בלתי נסבלת של תיקונים והשקעת אנרגיה בכיבוי שריפות. ניהול פיתוח בתהליך אופקי המנסה לחצות יחידות אנכיות (במבנה מטריציוני) לא רק שמערים מכשולים הכרוכים במתח בין היחידות אלא גם יוצר קשיים בתיאום עבודות הפיתוח, המעבדות ומערכי הבדיקות. היעדר יכולת לאתר את מקור הבעיות ואת נסיבות הסטייה מהתוכנית, וקשיי התיאום ב"העברת המקל" בין היחידות המקצועיות (האנכיות), מגיעים לידיעת ההנהלה רק כשמסתבר להנהלת הפרויקט על האיחור, על אי-בשלות המוצר ועל קפיצה משמעותית בעלויות. בסופו של תהליך, בשל הצורך לעמוד בחוזי המסירה ללקוח, מוצר לא בשל יגיע לשוק באיחור ובהשקעת הון בתיקונים והתאמות שיעלו לספק במחיר כספי ואובדן מוניטין יקרים מנשוא.
תפיסת הפיתוח Lean Product & Process Development) LPPD) מוסיפה לחדשנות בפיתוח המוצר גם תפיסת ניהול חדשנית (Management Innovation) שמטבעה מתמודדת עם פיתוח מוצרים בשוק משתנה ובלתי צפוי. תפיסת הפיתוח LPPD עושה שימוש בעקרונות תפיסת ניהול Lean בארבעה מימדים:
1) צוות פיתוח רב-מקצועי הפועל במשולב לאורך מהלך הפיתוח והייצור: שילוב כלל הגופים המקצועיים האנכיים (Verticals) – פיתוח וייצור, ארכיטקטורה והנדסה – לצוות אורגני אחד.
2) מנהל מערך הפיתוח (Chief Engineer): נושא באחריות מערכתית (אופקית) לתרגום צרכי הלקוח לארכיטקטורה, הנדסה, ייצור לאורך כל מחזור חיי המוצר עד למסירה ללקוח.
3) ארכיטקטורת תהליך הפיתוח: הגדרת רצף צמתי אינטגרציה ובדיקה (DRs) החל משלבי הפיתוח המוקדמים לבחינת התקדמות העבודה בתהליך הפיתוח. שילוב יחידות שונות (פיתוח וייצור לדוגמא) יאפשר שיח מעשי בשלב מוקדם וראשוני של המערכת תוך ייצור דגם ראשוני לבחינה פונקציונאלית מעשית (MVP – Minimum Viable Product).
4) בדיקות ולימוד בתהליך (Validation): סבבי בדיקה מוקדמים קצרים, רציפים ומהירים על מנת לשלוט בתהליך, לגדר את הסיכון ולהתאים את תהליך הפיתוח לממצאי הבדיקות והמציאות האמפירית.
עמיתנו בראד פאוור עוסק באתגר האצת קצב הפיתוח בסביבה עסקית המתערערת במהירות ותחת דרישה מתמידה לקיצור משך חיי המוצר (Product Life Cycle). בראד מביא את תפיסת הניהול והכלים בהם משתמשות חברות כמו Google ו-HubSpot בכדי להתמודד עם טבעו של השוק, כלים המהווים דוגמה מעשית לתפיסת ניהול הפיתוח LPPD. התרגום וההתאמות לקורא הישראלי נעשו בשיחה עם בראד ובאישורו.
בעז תמיר, ILE
כיצד להאיץ את קצב הפיתוח מבלי לאבד שליטה?
המאמר פורסם במקור באתר Harvard Business Review
לעיתים קרובות נדמה שהטכנולוגיה הדיגיטלית גורמת לכל חלקה במגזר העסקי לנוע במהירות עצומה. ואמנם, ישנם יתרונות ממשיים בכל הנוגע לאפשרויות עסקיות ב-'זמן-אמת': מוצרים עושים את דרכם לשוק מהר יותר, מעלים את ערכם מהר יותר ומתאימים עצמם במהירות גדולה יותר לצרכי הלקוח. לדוגמה, בפוסט קודם עסקתי בקצב הפיתוח המואץ של 'אמזון' (מדובר בפוטנציאל של כ-8,000 שינויי תוכנה ביום, אחד כל 11 שניות), אשר בזכותו היא צפויה להביס כל מתחרה שמוציאה לפועל שינויי תוכנה במרווחי זמן גדולים במידה ניכרת (אחת לשישה שבועות). אבל מה בדבר הסיכונים? האם המהירות המואצת אינה טומנת בחובה באופן אינהרנטי את הסיכון שבאבדן שליטה?
לא בהכרח. כפי שהסביר לי לאחרונה אנדי סינגלטון (Andy Singleton), מנכ"ל Assembla, התפתחות מתמדת עשויה להיות גם זולה יותר וגם בטוחה יותר. זולה יותר – בזכות אפשרויות המיכון (אוטומציה) ומשום שצוותי פיתוח קטנים זקוקים לפחות תיאום ופיקוח, ובטוחה יותר הודות לכלי חדש לניהול סיכונים ששמו "feature gates".
הרי לכם הצצה חטופה לתהליך שעשו Google ו-HubSpot על מנת להגיע לקצב פיתוח מוצר יוצא מן הכלל תוך מזעור הסיכון למינימום האפשרי.
מערכת הבקרה הממוכנת של Google
במשך עשרות שנים, פרויקטים גדולים של טכנולוגיית המידע (IT) ירדו לטמיון כיוון שהמתכננים לא ידעו לצפות מראש כיצד תעבוד תוכנה חדשה בסבך הקשרים הפנימיים [בין היחידות המקצועיות הוורטיקאליות] האופייני למערכות מורכבות (לעיתים במורכבות רבת-מימדים המשלבת תוכנה עם חומרה). על מנת לבחון תוכנות חדשות לפני צאתן לשוק, נהגו מנהלי הפרויקטים לעבוד עם צוותי מומחים שערכו בדיקות איכות לתוכנה. הבדיקות המסורתיות הללו ארכו בין שבועות לחודשים, אך לא היו יעילות מספיק במניעת שגיאות. על מנת לעמוד בקצב הפיתוח המסחרר של החברה, Google החליפה את מערכות הבקרה המסורתיות הנסמכות על תפעול של עובדים וקבלנים, במכונת בקרה ששמה "continuous integration" (CI – אינטגרציה רציפה). מדובר בהעתק של מערכת הייצור של החברה, ובו תוכנות מיוחדות הבוחנות את האופן שבו תתי המערכות המרכיבות את המערכת – יחידות השירות (component services) – עובדות במשולב. עקרונות האינטגרציה הרציפה, מיכון ואוטומציה של הבדיקות (automated testing) מהווים תמיד חלק חיוני ובלתי נפרד מתהליכי פיתוח תוכנה מודרניים בקנה מידה רחב, אך קצב הפיתוח של Google חריג בכל קנה מידה. מערכת הבקרה שלהם מקבצת ומציבה מחדש למעלה מ-5000 רכיבים (שירותים), ומריצה 100 מליון מקרי בוחן ביום.
מערכת הבקרה של Google נבנית ומתוחזקת על ידי קבוצת "מהנדסי מבחן" ("test engineering") המהווה כ-15 אחוז מתוך כלל המפתחים (developers) בחברה. המהנדסים בקבוצה הזאת אחראים אך ורק על בנייתן של מערכות הבקרה האוטומטיות, ואינם לוקחים חלק בבדיקות עצמן. המהנדסים בקבוצה משקיעים מחשבה רבה ביצירת תמריצים עבור מפתחים לתקן שגיאות (bugs) ולפתח מבחנים יעילים בכוחות עצמם. לדוגמה, המהנדסים מספקים לוחות מחוונים (dashboards) אישיים המדווחים על שגיאות (bugs) לכל מפַתח בנפרד; כל שינוי שמבצע המפתח נבדק עם הגרסה העדכנית ביותר הכוללת כבר את כל השינויים שנעשו עד אותה נקודה; במקרה שבדיקה מעלה בעיות, היא מודיעה למפתח עם מי עליו ליצור קשר על מנת לפתור אותן – ישירות, ללא מתווכים.
Google משלבת בסקירת שינויי הקוד שלה בין בדיקה ממוכנת ובין תהליכים התובעים התערבות אנושית. התוצאה היא מערכת בקרת איכות ברמה גבוהה, כזו המפנה את אנשי המקצוע לעסוק בשינויים עצמם. כל מפתח ב-Google מורשה לשנות כל מוצר – או קבוצת מוצרים – בכפוף לכללי הבדיקה והבקרה בחברה. במקרים מסוימים, ביכולתו להוציא לפועל בנייה ופיתוח של מוצר למן הרעיון הראשוני ועד לשלב ההפצה בתוך 48 שעות.
גרעיני הפיתוח של HubSpot ו-"Feature Gates"
HubSpot מספקת אמצעי שיווק-פנים עבור עסקים קטנים ובינוניים במטרה למשוך לקוחות פוטנציאליים לאתר האינטרנט שלהם. סינגלטון סיפר לי איך HubSpot הפכו את התוכנה המיושנת שלהם – היחידה שהייתה ברשותם – למערך מתוחכם של מאתיים שירותי תוכנה ממוחשבים (software services) כדוגמת אלה של אמזון וגוגל. השינוי הזה איפשר להם להמיר את השיטה המסורתית של סבבי ייצור והפצה, הנמשכים מספר שבועות, בזרם ייצור הפועל בקצב (Takt Time) של 100 שינויים ביום. ההחלפה של התוכנה הישנה בקוד החדש ארכה כשנה, אשר במהלכה עלה קצב הייצור בהתמדה, ובמקביל הלך ושכך העומס על המערכת (codebase) הישנה. המוצר החדש של החברה האפיל תוך זמן קצר על זה הישן, וכיום ממשיך המוצר להתפתח ולהתרחב, ומהווה איום של ממש על המתחרות.
HubSpot חילקה את המפַתחים שלה לצוותים קטנים (טכנאי מוביל ושני מתכנתים) כאשר כל צוות אחראי על חלק קטן מבין תפקודי התוכנה ("שירותים"). מדובר בכ-20 צוותים שכל אחד מהם אחראי על תחזוקתם של כעשרה שירותים. לכל אחד מהצוותים הללו ניתנת אחריות מירבית במהירות מירבית. הסמכויות נעות בין תחומים שונים ומגוונים: עיצוב, תכנות, בקרה, שיווק והפצה, ומתן מענה לבעיות העולות בתהליך הייצור. הם מקבלים מידע מערכתי על שירותים שבאחריותם – כגון מהירות ושגיאות – בזמן-אמת, ומקבלים פניות מלקוחות.
“Feature gates” היא מערכת כלים אישיים (proprietary) ומתוחכמים המשמשים לייצור, הפצה ובקרה. הכלי מאפשר לבטל ולהפעיל מחדש פונקציות מסוימות עבור כולם, עבור קבוצה ספציפית או עבור יחידים. בלחיצת כפתור ניתן לקבוע למי תהיה גישה לתוכנה בהתאם לסטטוס שנקבע: "הסתר" (אף אחד לא רואה), "מבחן" (רק בוחנים של החברה), "Beta" (בוחנים מחוץ לחברה), ו-"הצג" (כולם יכולים לראות). בחינתן של תוספות חדשות עשויה להתארך (במהלכה יעבור המוצר מבדקי בטא, מבדקי שמישוּת, מועילות ויעילות ומבדקי A/B). המערכת של Feature gates מספקת בו-זמנית תמיכה וניהול סיכונים על ידי האצלת סמכויות למפתחים הנוטלים חלק בבנייתם של מוצרים בפיתוח לאורך זמן, מבלי שייאלצו לחכות לתגובות של בוחנים פנימיים או חיצוניים, של ההנהלה מצד אחד ושל הלקוחות מן הצד השני. כמעט כל חברות "Software as a Service" וספקי שירות אונליין יידרשו לעבור לשיטות דומות לאלה של גוגל ו-HubSpot, אם רצונם לשרוד בשוק. חלוצות כמו אמזון ופייסבוק כבר עשו את השינוי בניסיון להתמודד עם אתגרים שהציבו רשתות כמו Linkedin ו-Netflix. תעשיות הנסמכות במידה רבה על שירותים מבוססי-תוכנה (בנקים למשל) לא נשארות הרחק מאחור. על רקע תחרות הולכת וגוברת, הללו עוברות יותר ויותר לשיטות של פיתוח ובקרה אונליין.
יישום השיטות הללו ברחבי התעשייה, בחומרה ובמוצרים שונים, הוא רק עניין של זמן. לדוגמה, מעצבי שבבים יוצרים אינטגרציה מתמדת באמצעות סימולציות, ובחינתן של אפשרויות פיתוח תוך כדי תנועה. בתמונה הרחבה יותר, כשיותר ויותר תפקידי ניהול משנים צורה – עוברים דיגיטציה או מבוצעים בידי תוכנות עדכניות, הרי שאמצעי פיתוח כגון אלה שתיארתי לעיל עתידים לסייע ביצירתה של תרבות ניהול מוצר גמישה ופתוחה יותר.
כתיבת תגובה