תיק מוצר: המדריך ליצירת התיק המושלם לייצור

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

זה לא קורה כי הרעיון לא טוב. זה קורה כי היצרן לא קיבל מוצר. הוא קיבל רמזים.

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

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

הקדמה למה תיק מוצר הוא הנכס החשוב ביותר שלך

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

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

למה הכאוס מתחיל דווקא במסמכים

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

תיק מוצר חלש לא יוצר רק טעויות. הוא יוצר ויכוחים על מה בכלל הוסכם.

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

תיק מוצר טוב מספר סיפור אחד ברור

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

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

רואים את זה מהר מאוד בשטח:

• תיק מבולגן מייצר שאלות מאוחרות, חוסר התאמה בין מחלקות והפתעות בעלות.

• תיק סגור היטב מקצר שיחות, מבהיר אחריות, ומאפשר ליצרן לתת תשובות טובות יותר.

• תיק חלקי כמעט תמיד דוחף החלטות קריטיות לשלב מאוחר מדי.

• תיק קוהרנטי שומר על הפרויקט מפני אלתור יקר.

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

המסד איך כותבים מפרט פונקציונלי שמדבר בשפת מהנדסים

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

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

השאלה הנכונה היא לא מה אתה רוצה לומר

השאלה היא מה אדם אחר צריך להבין בלי לדבר איתך.

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

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

דוגמה אחת שמבהירה הכול

ניקח מכשיר אלקטרוני פשוט להפעלה מהירה.

טקסט חלש ייראה כך:

• דרישה עמומה המשתמש צריך להפעיל את המכשיר בקלות

• בעיה אף אחד לא יודע מה זה "בקלות"

טקסט שימושי ייראה אחרת:

• דרישה ברורה המכשיר יידלק בלחיצה אחת

• תנאי סף זמן מעבר מהפעלה למצב עבודה יהיה קצר וברור למשתמש

• משוב משתמש נורית חיווי תציג שהמערכת מוכנה

• מצב כשל אם הרכיב לא עלה, המשתמש יקבל חיווי מובחן

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

כלל מעשי אם דרישה לא יכולה להפוך לבדיקה, היא עדיין לא דרישה טובה.

מה חייב להופיע במפרט כזה

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

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

מה לא עובד

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

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

השרטוט מיפוי המוצר עם שרטוטים, עץ מוצר והוראות הרכבה

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

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

השרטוטים מגדירים את הצורה

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

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

עץ המוצר הוא המתכון

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

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

הדרך הנכונה לבנות BOM היא לחשוב בשתי שכבות:

• שכבת מבנה אילו תתי מכלולים קיימים ואיך הם מקושרים

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

• שכבת תחליפיות אילו רכיבים קריטיים ואילו אפשר להחליף

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

הוראות ההרכבה הן המקום שבו המציאות פוגשת את הכוונה

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

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

BOM בלי הוראות הרכבה הוא רשימת קניות. הוראות הרכבה בלי BOM הן אלתור.

המסמך הזה משרת יותר ממחלקת ייצור

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

אפשר לראות את החלוקה כך:

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

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

הבדיקה הגדרת פרוטוקולי בדיקה ובקרת איכות

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

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

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

כל דרישה צריכה לפגוש בדיקה

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

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

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

• בדיקה פונקציונלית בודקת שהמוצר מבצע את הפעולה שלשמה נבנה

• בדיקת ביצועים בוחנת עד כמה המוצר עומד בהתנהגות שהוגדרה

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

איכות טובה נבנית מוקדם

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

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

מה קורה כשלא מגדירים מספיק

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

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

1. מטרת הבדיקה מה בודקים ולמה

2. ציוד נדרש באילו כלים משתמשים

3. שלבי ביצוע מה הסדר הנכון

4. קריטריון קבלה מה נחשב תקין

5. תיעוד תוצאה איך רושמים, שומרים ומעבירים הלאה

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

המעטפת DFM ניהול גרסאות ודרישות רגולטוריות

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

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

DFM בודק אם התכן ישרוד את רצפת הייצור

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

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

מי שרוצה לבחון את זה לעומק יכול לקרוא על DFM בתכנון לייצור.

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

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

ניהול גרסאות קובע מהו המקור הרשמי

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

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

הבסיס צריך להיות פשוט וברור:

• שם קובץ עקבי שכולל מספר חלק, תיאור וגרסה

• יומן שינויים שמסביר מה השתנה, למה, מי אישר ומתי

• סטטוס מסמך ברור טיוטה, לשחרור, מאושר, מבוטל

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

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

קובץ נכון בגרסה לא נכונה מייצר מוצר לא נכון.

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

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

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

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

אפשר לסכם את המעטפת הזאת כך:

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

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

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

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

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

מסירה טובה מתחילה באחריות ברורה

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

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

תיק מוצר טוב לא אמור להיות "מת"

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

• שמרו על מסירת בסיס נקייה בלי קבצי טיוטה מיותרים

• תעדו כל שינוי אחרי המסירה גם אם הוא נראה קטן

• בקשו מהספק לשקף פערים מוקדם לפני שהוא מחליט לבד

• בדקו הבנה, לא רק קבלה "קיבלתי" זה לא "הבנתי"

מסירת תיק מוצר היא לא סוף המשימה. היא תחילת מערכת היחסים.

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

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

---

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