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

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

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

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

במקום זאת, צוות הפלטפורמה מספק כבישים סלולים, דרכים סטנדרטיות, בדוקות ומאובטחות לטיפול במשימות נפצות. הם בונים ומתחזקים את הכביש בזמן שצוותי המוצר פשוט נוסעים עליו. התוצר המרכזי של הנדסת פלטפורמה הוא משהו שנקרא פלטפורמת מפתחים פנימית, או IDP בקיצור. חישבו על זה כמערכת בשירות עצמי שממקנת את כל העבודה החוזרת הזו. הקצאת תשתיות, צינורות C, CD, בדיקות הבטחה וניטור הכל מובנה וסטנדרטי. הנה דוגמה מוחשית. כשמפתח רוצה להטמיע שירות חדש ללא פלטפורמה, הוא מבלי ימים בהקמת תשתית, כתיבת צינורות והגדרת ניטור. עם IDP הוא פשוט לוחץ על התמאה בממשק או מריץ פקודה אחת, והפלטפורמה מטפלת בהכל הקצאה, בדיקות, ניטור והתמאה הכל בדקות במקום בימים. אז מה זה אומר עבורכם? אתם מפסיקים להיות מומחים להקל בתשתית ומתחילים להיות מומחים במוצר האמיתי שלכם. העבודה שלכם חוזרת לבניית פיצ'רים שחשובים ללקוחות שלכם במקום לנפות בגים ב-Terraform State File שמושחת. זו כל הנקודה. פלטפורמת מפתחים פנימית בשפה פשוטה. אז בואו נפרק מה היא באמת פלטפורמת מפתחים פנימית.

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

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

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

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

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

שירות עתיר תעבורה, הנה הגדרה שונה. המפתח לא מבצע את הבחירות האלה כי הוא לא צריך. למה זה משנה? כי שחיקה יורדת כשמפתחים לא צריכים ללהטת בין 15 דאגות שונות בבת אחת. צוותי פלטפורמה בוגרים הפחיתו את העומס הקוגניטיבי בכמעט חצי. 40 עד 50 אחוז פחות תקורה מנטלית. זה שינוי עצום. זה ההבדל בין לעזוב את העבודה עם אנרגיה לבין לבין לבהות במסוף בית 10 בלילה ולדהות למה הפייפליין נכשל. אבל הנה ההזהרה. אל תיצרו אשליות. כמה צוותי פלטפורמה נופלים למלכודת. הם מסתירים הגדרות בלי לתת למפתחים דרך להבין מה קורה מתחת למכסי המנוע. זו לא הפשטה, זו תרמית. וזה מתפוצץ ברגע שמה שהוא משתבש. מפתחים נתקלים בקיר שהם לא יכולים לראות דרכו ופתאום הפלטפורמה מרגישה כמו קופסה שחורה שעובדת נגדם. המונח לזה הוא הפשטה דולפת Leaky Abstraction. אתם מסתירים מורכבות. אבל בסוף המורכבות הזו דולפת החוצה. בסיס נתונים נהיה איתי, פריסה נכשלת, מדיניות הבטחה חוסמת מה שהוא בלתי צפוי. ולמפתח אין מודל מנטלי של מה שקורה כי הפלטפורמה מעולם לא נתנה לו אחד.

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

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

גלה מה באמת כואב. בני דבר אחד שפותר בעיה אמיתית, ואז בצע התרציות. כך בונים משהו שאנשים באמת רוצים להשתמש בו. למה דווקא עכשיו? גל ה-AI. אז למה אנחנו מדברים על זה דווקא עכשיו? למה לא לפני חמש שנים? התשובה היא AI. כלי פיתוח מבוססי AI כמו גיטהאב קופיילוט, מאפשרים למפתחים להוציא קוד בקצב שמעולם לא ראינו. פי עשר, פי עשרים יותר קוד ביום ממה שהיה אפשרי רק לפני כמה שנים. זה נשמע מדהים וזה אכן כך. אבל, הנה העבל. כל הקוד הזה עדיין צריך תשתית. הוא עדיין צריך הבטחה. הוא עדיין צריך לעבור פריסה, בדיקות ותפעול. יותר קוד בלי מערכת טובה יותר לא הופך אותך למהיר יותר. זה רק הופך את הקאוס למהיר יותר. אם המפתחים שלך כבר טובים ב-YML וב-Reform, ה-AI לא יתקן את זה. זה רק אומר שהם יתבעו מהר יותר בזמן שהם מייצרים יותר קוד שצריך לתחזה. נכון לעכשיו, קף מינוס 55% מהארגונים כבר ימצו הנדסת פלטפורמה בצורה כלשהי. גרטנר צופה שהמספר הזה יגיע למד מינוס 80% עד סוף שנת 2026. זו לא מגמה איטית. זהו שינוי שקורה ממש עכשיו. חברות מבינות שהן לא יכולות להרחיב את צוותי ההנדסה שלהן ללא שכבת פלטפורמה.

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

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

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

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