מהו הזמן הנכון לשיחרור מוצר? [משולחנו של סטארטאפיסט]

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

פוסט זה נכתב על ידי אורי להב; יזם, איש טכנולוגיה, ים ומדבר. היום Co-founder ו-CTO של אאוטבריין.

<<< לפוסט הקודם: מכירות ופיתוח? הפכו אוייב לידיד

תמונה: flickr, cc-by, i_yudai

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

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

נשמע דמיוני? אז זהו שלא. זה הכל עניין תרבותי.

שינוי בלוח הזמנים

לא תמיד פיתחנו ככה. היינו במוד של "רכבת ההרים" שבה מתכננים גרסה כל 6 שבועות ובסוף הגרסה מורידים 20% מהתכולה כי לא מספיקים ואז דוחים אותה פעמיים בשבוע כי היא עדיין לא מוכנה בסביבת הבדיקות ובסוף… כשכבר משחררים אותה – הכל מתרסק ומשקיעים שבועיים נוספים ללא שינה כדי ליצב אותה.

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

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

היום, כמעט שנתיים אחרי זה המצב:

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

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

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

אז מה המפתחות לכל זה?

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

מומלץ בחום.

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

אורי להב

אורי להב; יזם, איש טכנולוגיה, ים ומדבר. היום Co-founder ו-CTO של אאוטבריין.

הגב

1 תגובה on "מהו הזמן הנכון לשיחרור מוצר? [משולחנו של סטארטאפיסט]"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 
Sort by:   newest | oldest | most voted
Leonid Purgalin
Guest

ארכיטקטורה טובה היא בסיס ומנוף להרבה דברים טובים…

wpDiscuz

תגיות לכתבה: