תשתית כקוד: כיצד להתגבר על בעיות באמצעות XP

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

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

מי אנחנו, איפה אנחנו ואילו בעיות יש לנו

כרגע אנחנו ב-Sre Onboarding Team, המורכב משישה מתכנתים ושלושה מהנדסי תשתית. כולנו מנסים לכתוב Infrastructure כקוד (IaC). אנחנו עושים זאת כי אנחנו בעצם יודעים לכתוב קוד ויש לנו היסטוריה של מפתחים "מעל הממוצע".

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

ערימת הטכנולוגיה שבה אנו משתמשים ב-IAC שלנו.

• Terraform ליצירת משאבים.
• פקר להרכבת תמונות. אלו הן תמונות של Windows, CentOS 7.
• Jsonnet ליצור מבנה רב עוצמה ב- drone.io, כמו גם ליצור json packer ומודולי ה-terraform שלנו.
• Azure.
• אפשרי בעת הכנת תמונות.
• Python לשירותי עזר ותסריטים להקצאה.
• וכל זה ב- VSCode עם תוספים משותפים בין חברי הצוות.

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

אנו נאבקים כעת בבעיות IaC הבאות:

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

תכנות קיצוני (XP) להצלה

כל המפתחים מכירים את Extreme Programming (XP) ואת הפרקטיקות שעומדות מאחוריו. רבים מאיתנו עבדו עם הגישה הזו, והיא הצליחה. אז למה לא להשתמש בעקרונות ובפרקטיקות שנקבעו שם כדי להתגבר על אתגרי תשתית? החלטנו לנקוט בגישה הזו ולראות מה קורה.

בדיקת הישימות של גישת XP לתעשייה שלךלהלן תיאור של הסביבה ש-XP מתאים לה, וכיצד היא קשורה אלינו:

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

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

3,4. צוות פיתוח מורחב קטן ומשותף. הטכנולוגיה האוטומטית שבה אתה משתמש מאפשרת לבצע בדיקות יחידה ותפקוד. שתי הנקודות הללו לא ממש מתאימות לנו. ראשית, אנחנו לא צוות מתואם, ושנית, אנחנו תשעה, שיכולים להיחשב לצוות גדול. למרות שלפי כמה הגדרות של צוות "גדול", הרבה זה 14+ אנשים.

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

עקרון לולאת משוב XP

לפי הבנתי, משוב הוא התשובה לשאלה, האם אני עושה את הדבר הנכון, האם אנחנו הולכים לשם? ל-XP יש תכנית אלוהית לכך: לולאת משוב זמן. הדבר המעניין הוא שככל שאנו נמוכים יותר, כך נוכל לגרום למערכת ההפעלה להשיב על השאלות הדרושות מהר יותר.

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

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

חשוב: משוב יכול להוות פתרון לכל הבעיות שצוינו לעיל. בשילוב עם שיטות XP, זה יכול לחלץ אותך מתהום הייאוש.

איך לחלץ את עצמך מתהום הייאוש: שלושה תרגולים

בדיקות

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

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

יש פירמידת בדיקות קלאסית, שמראה שצריך להיות יותר בדיקות.

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

• בדיקות יחידה, למרות העובדה שצריכות להיות הרבה כאלה, לא יכולות להיות יותר מדי. או שהם בודקים משהו מאוד עקיף. למעשה, אנחנו יכולים לומר שאנחנו לא כותבים אותם בכלל. אבל הנה כמה יישומים לבדיקות כאלה שהצלחנו לעשות:
  1. בדיקת קוד jsonnet. זה, למשל, צינור הרכבת הרחפנים שלנו, שהוא די מסובך. קוד jsonnet מכוסה היטב בבדיקות.
     אנחנו משתמשים בזה מסגרת לבדיקת יחידות עבור Jsonnet.
  2. בדיקות עבור סקריפטים שמתבצעים כאשר המשאב מתחיל. סקריפטים נכתבים בפייתון, ולכן ניתן לכתוב עליהם מבחנים.
• אפשר אולי לבדוק את התצורה בבדיקות, אבל אנחנו לא עושים את זה. אפשר גם להגדיר כללי בדיקת תצורת משאב באמצעות טפלינט. עם זאת, הבדיקות שם פשוט בסיסיות מדי עבור terraform, אבל תסריטי בדיקה רבים נכתבים עבור AWS. ואנחנו על Azure, אז זה שוב לא רלוונטי.
• מבחני שילוב רכיבים: זה תלוי איך אתה מסווג אותם והיכן אתה שם אותם. אבל הם בעצם עובדים.

  כך נראים מבחני אינטגרציה.

  
  
  זו דוגמה לבניית תמונות ב-Drone CI. כדי להגיע אליהם, יש להמתין 30 דקות עד שתמונת הפקר תיווצר, ואז לחכות עוד 15 דקות כדי שיעברו. אבל הם קיימים!

  אלגוריתם אימות תמונה

  1. על פקר להכין תחילה את התמונה במלואה.
  2. לצד הבדיקה יש terraform עם מדינה מקומית, שבה אנו משתמשים כדי לפרוס את התמונה הזו.
  3. בעת הפתיחה, נעשה שימוש במודול קטן השוכב בקרבת מקום כדי להקל על העבודה עם התמונה.
  4. לאחר פריסת ה-VM מהתמונה, ניתן להתחיל בבדיקות. בעיקרון, הבדיקות מתבצעות ברכב. זה בודק איך התסריטים עבדו בהפעלה וכיצד הדמונים עובדים. לשם כך, באמצעות ssh או winrm אנו נכנסים למחשב שהועלה לאחרונה ובודקים את סטטוס התצורה או אם השירותים פועלים.

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

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

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

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

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

אנחנו כבר יכולים לכתוב לזה מבחנים רגילים, כי זה לא שונה מתוכנה רגילה: לועגים לאיזשהו אפיה, אתה מושך אותו ותראה מה קורה.

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

זוג תכנות

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

בעת כתיבת קוד, אתה רוצה לקבל משוב על איכותו במהירות האפשרית. כן, אפשר לכתוב הכל בסניף פיצ'רים (כדי לא לשבור שום דבר לאף אחד), לבצע בקשת pull ב-Github, להקצות למישהו שלדעתו יש משקל ולחכות לתגובה.

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

להלן סגנונות התכנות הזוגיים והישימות שלהם בעבודה על IaC:

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

בואו נשקול את התאימות של הבעיות שלנו עם הסגנון:

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

הבעיה העיקרית בשימוש בסגנון זה ב-IAC היא קצב העבודה הלא אחיד. בפיתוח תוכנה מסורתי, יש לך תנועה מאוד אחידה. אתה יכול להקדיש חמש דקות ולכתוב N. הקדש 10 דקות וכתוב 2N, 15 דקות - 3N. כאן אתה יכול לבלות חמש דקות ולכתוב נ', ואז לבלות עוד 30 דקות ולכתוב עשירית מ-N. כאן אתה לא יודע כלום, אתה תקוע, טיפש. החקירה לוקחת זמן ומסייחה את הדעת מהתכנות עצמו.

מסקנה: בצורתו הטהורה הוא לא מתאים לנו.

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

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

מסקנה: אבוי, קצב העבודה אינו מאפשר שימוש בפינג-פונג כתרגול תכנות זוגי ב-IAC.

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

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

מסקנה: אפשר להשתמש בו, אנחנו לא מוותרים על הניסיון.

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

תוצאות כלליות על שימוש בתכנות זוג:

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

5. למרות זאת, היו הצלחות. המצאנו שיטה משלנו "התכנסות - התבדלות". אני אתאר בקצרה איך זה עובד.

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

תכנון ותקשורת

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

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

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

היתרונות של ראייה חזותית של משימות:

• סִבָּתִיוּת. כל משימה מובילה למטרה גלובלית כלשהי. המשימות מקובצות למטרות קטנות יותר. תחום התשתית עצמו די טכני. לא תמיד ברור באופן מיידי מה ההשפעה הספציפית, למשל, לכתיבת ספר הפעלה על מעבר ל-nginx אחר על העסק. כרטיס היעד בקרבת מקום עושה את זה ברור יותר.
  
  סיבתיות היא תכונה חשובה של בעיות. זה עונה ישירות על השאלה: "האם אני עושה את הדבר הנכון?"
• מַקבִּילוּת. אנחנו תשעה, וזה פשוט בלתי אפשרי פיזית לזרוק את כולם במשימה אחת. גם משימות מתחום אחד לא תמיד מספיקות. אנו נאלצים להקביל עבודה בין קבוצות עבודה קטנות. יחד עם זאת, הקבוצות יושבות על משימתן זמן מה, הן יכולות לקבל חיזוק על ידי מישהו אחר. לפעמים אנשים נופלים מקבוצת העבודה הזו. מישהו יוצא לחופשה, מישהו עושה דיווח ל-DevOps conf, מישהו כותב מאמר על Habr. לדעת אילו מטרות ומשימות ניתן לבצע במקביל הופך להיות חשוב מאוד.

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

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

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

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

במהלך ההדגמה יש צורך לחשוף את פרטי המשימה ולהקפיד להדגים את פעולתה.

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

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

3. איך אנחנו משפרים את זה. לדוגמה: "תראה, עכשיו יש scriptosik, הנה ה-readme."

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

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

רצוי לכל רמקול לשמור על 5-10 דקות. אם הנאום שלך כמובן חשוב וייקח יותר זמן, תאם זאת מראש בערוץ ההשתלטות.

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

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

מסקנות ארוכות ומה הלאה

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

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

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

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

מסקנות קצרות בשורה אחת

• אנשי משאבי אנוש עובדים ב-IAC, אך ביעילות פחותה.
• לחזק את מה שעובד.
• תמציא מנגנוני פיצוי משלך.

מקור: www.habr.com