פוסט זה נכתב על ידי אורי להב; יזם, איש טכנולוגיה, ים ומדבר. היום Co-founder ו-CTO של אאוטבריין.
מזמן לא כתבתי כי לא יצא, ובעיקר כי הרבה דברים היו בהתהוות. על אחד מהם אני רוצה לספר עכשיו. אני רוצה לדבר על אחריות, העצמה ו-Ownership ("בעלות" היא אולי המילה המתאימה בעברית).
בעבר היה לנו ב-Outbrain סוג של אמירה ש"כל אחד מנכ"ל". לכל אחד תחום אחריות ובו יש לו את המנדט לקבל החלטות. אם מסתכלים על זה בעיניים מציאותיות אז… למה לא? שהרי בשביל מה אנחנו מגייסים אנשים לחברה? אנחנו מגייסים אנשים שמסוגלים לעשות עבודה בצורה טובה יותר מאיתנו. מבינים טוב מאיתנו בתחומם וכתוצאה מכך מסוגלים גם לקבל החלטות טוב מאיתנו. לכן תפקידנו כמנהלים או יזמים הוא לאפשר להם "לעבוד" ולהצליח בתחומם. את הראיה הזו הצלחנו (אני מאמין) להעביר גם למנהלים שגייסנו וכתוצאה מזה נוצרה תרבות מאוד מעצימה (Empowering). ההעצמה הזו יורדת גם לרמת הפרט ולכל עובד.
אמון והרחבת סמכויות
לדוגמא: מפתח ב-Outbrain יכול בהחלטה של עצמו בלבד לדחוף קוד לסביבת פרודקשן בכל רגע נתון – ללא צורך באישור נוסף. איכות הקוד והמוצר שהוא שיחרר הם באחריותו הבלעדית ואנחנו סומכים עליו לגמרי שהוא בדק ונקט בכל האמצעים כדי להבטיח את האיכות. כתוצאה מכך אנחנו משחררים קוד בצורה הרבה יותר בטוחה וקבועה בקצב של בין 5 ל-100 פעמים… ביום(!) ויש לנו יכולת טכנית לשנות את הפרודקשן בכל רגע נתון. שיטה זו נקראת Continuous Deployment ואני ממליץ לצפות בהרצאות של איתי, מנהל הפיתוח שלנו, כדי להבין כיצד היא עובדת באופן טוב יותר.
לאחרונה הצטרף נדבך נוסף לתרבות ה"Ownership" של Outbrain. לא נכחיש שלתנועת ה-DevOps יש השפעה עלינו בעניין הזה. שינוי תרבותי שבעקבותיו אימצנו את האמרה "אתה בונה – אתה מריץ" כלומר… אם בנית מוצר מסויים – אחריותך לא מסתיימת ברגע ששחררת אותו לפרודקשן – חלק מתפקידך הוא ללוות את השירות או המוצר שלך גם ביום יום כשלקוחות משתמשים בו.
עם צמיחת החברה והצלחת המוצר, המחיר של כל דקת השבתה של השירות עלתה ולכן ניצבנו בפני השאלה האם להקים NOC (מרכז תפעול רשת) שהוא מעין מרכז ידיעות מאוייש שבו אפשר לעקוב אחרי מערכות הניטור ולראות אם ישנן התראות ולפעול לפיהן. זו המתודה המקובלת ברוב החברות הדומות לנו. הבעיה נוצרה באופי המערכת ובדינאמיות שלה. בעובדה שהיא יכולה להשתנות בכל רגע נתון אם מפתח מחליט שיש צורך לשנות שירות מסויים. בסביבה כזו דינאמית, העדכון של אנשי ה-NOC בשינויים הפך משימה בלתי אפשרית, דבר שהיה גורם רק להשבתות רבות יותר וארוכות יותר.
לכן החלטנו לקחת את הדברים למקום המעשי יותר ולדחוף את ההתראות ל"בעליו" של כל רכיב במוצר. מכיוון שהבעלים מכיר אותו בצורה הטובה ביותר, הוא גם האדם שיכול לתקן במהירות הגדולה ביותר. אם הבעלים הוא זה שמשנה את אותו רכיב הוא גם זה שראוי שידע ויפעל עם אותו רכיב בבעיה. וכך הגענו לנוהל הבא:
- כל צוות פיתוח הוא הבעלים של מספר רכיבים.
- צוות ה-OPS הוא הבעלים של התשתית (חומרה ותשתיות תוכנה).
- לצוותי הפיתוח יש תורנות (במחזורים של שבוע) של מהנדס On Call.
- לצוות ה-OPS שמפוצל בין ישראל וארה"ב יש גם כן מהנדס במשמרת, ער 24 שעות (חצי יממה מישראל וחצי מארה"ב).
- התראות קריטיות ולוח הזמנים של המשמרות מוגדרים בשירות שנקרא Pager Duty. שמאפשר למערכת להתקשר לתורן.
- התראה קריטית מגיעה קודם כל לאיש OPS במשמרת. אם הוא מבין אותה או מצליח לקשר אותה לבעיית תשתית הוא מאשר שקיבל ומטפל.
- אם הוא לא מאשר תוך 10 דקות ההתראה עוברת לתורן של צוות הפיתוח הרלוונטי ומזעיקה אותו.
- מכאן שניהם יטפלו בתקלה עד לפיתרון.
מה השגנו בכך?
יותר דגש על בעלות ואחריות של הצוות על המוצרים שלו. אם זה לא יעבוד… אתה או חברך לצוות תתעוררו בלילה. יותר דגש על מה קורה עם המוצר שלי אחרי שסיימתי את הפיתוח. הרבה מאוד אפשר ללמוד מזה וזו מראה נהדרת לכולם לגבי "איך נראה התוצר שלי".
מילה אחרונה על מה אפשר לזה לקרות. אנחנו כצוות ניהולי מוביל, בתרבות שמאמינה בהעצמה, רואים את עצמנו כמכשיר לאפשר לדברים לקרות. האמת שצריכה להאמר היא שמי שהוביל והטיף למעבר לשיטות התנהלות כאלו הם אנשי הצוות עצמם. אני לא אשקר אם אומר שחלק מאנשי הצוות שלנו רתמו אותנו להתנהלות כזו. לעיתים אני מרגיש זכות גדולה לעבוד עם אנשים שרוצים ודוחפים לקחת אחריות על עצמם ועל התוצרים שלהם. ואני מאוד גאה בהם על זה.
קרדיט תמונה: Shutterstock.