אחת השאלות שחוזרות כמעט בכל פגישת פתיחה היא מי בעצם אחראי לכתוב מפרט דרישות למוצר: היזם שמכיר את הצורך, או חברת ההנדסה שתבצע את הפיתוח. התשובה המעשית היא ששניהם, אבל לא באותו חלק של המסמך. היזם מגדיר מה המוצר צריך לעשות ובאילו תנאים, והמהנדסים מתרגמים זאת לדרישות מדידות שאפשר לתכנן ולבדוק לפיהן. אנחנו בפרוג'קטס האוס מתחילים כמעט כל פרויקט בתהליך הזה, כי מסמך דרישות חלש הוא הסיבה הנפוצה ביותר לחריגות תקציב ולוויכוחים בסוף הדרך.
מה בדיוק כולל מסמך דרישות טוב
מסמך דרישות אינו רשימת משאלות ואינו תיאור פתרון. הוא מגדיר את הבעיה בצורה שניתן לאמת אותה. מסמך מסודר כולל בדרך כלל:
- דרישות פונקציונליות: מה המוצר עושה, אילו מצבי הפעלה יש לו ואיך המשתמש מפעיל אותו.
- דרישות ביצועים: ערכים מספריים כמו טווח מדידה, זמן תגובה, משקל מרבי או זמן עבודה על סוללה.
- דרישות סביבה: טווח טמפרטורות, לחות, רמת אטימות, עמידות בנפילה ותנאי אחסון.
- דרישות ממשק: חיבורים חשמליים, פרוטוקולי תקשורת, ממדים חיצוניים והתאמה לציוד קיים.
- דרישות רגולציה ותקינה, לפי השווקים שאליהם המוצר מיועד.
- אילוצי עלות וכמות, שכן עלות יעד ליחידה בסדרה של 5000 יחידות מכתיבה החלטות תכנון שונות לגמרי מסדרה של 300 יחידות.
חלוקת האחריות בין הלקוח למהנדסים
היזם הוא מקור האמת לגבי הצורך, המשתמש והשוק. הוא זה שיודע מי הלקוח, מה הוא מוכן לשלם, ומה חייב לקרות כדי שהמוצר ייחשב מוצלח. אלה נקראים לרוב אפיוני דרישות הלקוח, והם נכתבים בשפה עסקית. חברת ההנדסה לוקחת את אלה והופכת אותם לדרישות טכניות בדידות, לכל אחת מספר מזהה, ערך יעד ושיטת אימות. השלב הזה הוא בדיוק אפיון המוצר, ובלעדיו כל הערכת עלות היא ניחוש. בפועל נדרשות שתיים או שלוש סבבי עבודה משותפים עד שהמסמך מתייצב, ותהליך זה מתואר גם במאמר על הגדרת דרישות פרויקט.
איך מנסחים דרישה שאפשר לבדוק
דרישה טובה היא חד משמעית, מדידה וניתנת לאימות. הניסוח שהמוצר יהיה עמיד למים אינו דרישה, כי אי אפשר לבדוק אותו. הניסוח שהמוצר יעמוד בדרגת אטימות מוגדרת בבדיקה של שלושים דקות בעומק מטר הוא דרישה. אותו כלל חל על כל סעיף: במקום שהמוצר יהיה קל, כתבו משקל שאינו עולה על 450 גרם כולל סוללה. במקום שהמוצר יהיה זול לייצור, כתבו עלות חומרים יעד ליחידה בטווח מוגדר. לכל דרישה יש לצרף גם את שיטת האימות, כלומר בדיקה, חישוב, סימולציה או ביקורת. כך מפרט דרישות למוצר הופך בהמשך לבסיס ישיר של בדיקות הקבלה ומסירת הפרויקט. עוד כלל חשוב הוא לדרג את הדרישות לפי חובה, רצוי ועתידי. לא כל סעיף שווה בערכו, וכאשר מתגלה התנגשות בין דרישות, והיא תמיד מתגלה, הדירוג הוא שמאפשר להחליט מהר במקום לפתוח דיון מחדש. דרישה שמסומנת כרצויה ניתן לדחות לגרסה הבאה בלי לסכן את הפרויקט כולו.
מה עושים כשהדרישות משתנות באמצע
שינויים הם חלק טבעי מפיתוח, במיוחד אחרי שהאב טיפוס הראשון פוגש משתמשים אמיתיים. הבעיה אינה השינוי אלא שינוי לא מתועד. לכן מנהלים גרסאות למסמך הדרישות, ומכל שינוי נגזר עדכון של לוח הזמנים והתקציב. תהליך מסודר לכך מתואר במאמר על ניהול שינויים הנדסי, והוא נשען על ניהול פרויקט פיתוח ולוחות זמנים תקין. פרויקט שבו כל צד זוכר את הדרישות אחרת מסתיים תמיד באותו מקום: מוצר שעונה על ציפיות של אף אחד.
המלצה מעשית ליזמים בתחילת הדרך
אם אין לכם רקע הנדסי, אל תנסו לכתוב מפרט דרישות למוצר מלא לבד. כתבו מסמך צורך של שניים או שלושה עמודים: מי המשתמש, מה הוא עושה היום, מה מפריע לו, ואיך נראית הצלחה. הביאו אותו לפגישה ההנדסית, ומשם התהליך ממשיך יחד. הוסיפו גם רשימה של מוצרים דומים שאתם מכירים, עם הערה קצרה מה טוב ומה חסר בכל אחד, כי השוואה קונקרטית מקצרת דיונים ארוכים. אל תגדירו פתרון טכני שאינכם מומחים בו, שכן דרישה שמכתיבה טכנולוגיה מסוימת מצמצמת מראש את מרחב הפתרונות ולעיתים מייקרת את הפרויקט ללא צורך. שאר הכלים בשלב הזה מרוכזים במדור שירותי פיתוח מוצר, כולל הבנת ההיקף והתמחור.
רוצים להתחיל מהמקום הנכון ולהגדיר את הדרישות לפני שמשקיעים בפיתוח? קבעו פגישה ראשונית ונבנה יחד מסמך שמכוון את כל הפרויקט.
רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.
