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

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

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

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

אז מה עושים עם הרשימה האינסופית?

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

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

לכן הדבר הראשון שאנחנו עושים עם כל רשימת פיצ'רים הוא לעזור ללקוחות שלנו לצמצם אותה למינימום ההכרחי: MVP — Minimum Viable Product (מוצר בר-קיימא מינימלי). ברגע שיש לנו רשימה קצרה וממוקדת, אנחנו מחדדים כל פיצ'ר:

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

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

עצה ליזמים לא-טכניים

• אל תצללו לפרטים הטכניים אלא אם אתם באמת חייבים — זו האחריות של צוות הפיתוח.
• תַּעדְּפוּ את הפיצ'רים שלכם ללא רחמים והגבילו בקפדנות את רשימת העדיפות העליונה.
• תכננו ניסויים: מה הדבר הכי קטן שאתם יכולים לבנות שיאמת את הרעיון העסקי שלכם?

יש לכם רעיון עסקי שאתם צריכים עזרה לבנות? אנחנו כאן לעזור.