מאת יואב אחיעם, מנכ״ל ומייסד GuardianEYE.
כאשר הגיע הזמן בסטארטאפ שלי לפתח חומרה ואפליקציה, ולהמשיך ליצור אלפה של המוצר, היה צורך בכתיבת מסמך שיכיל את כל תכולת העבודה (SOW). מכיוון ואני ושותפי הגענו עם רקע של עבודה בחברה הנדסית גדולה, ידענו איך לכתוב SOW לפיתוח פנימי בחברה. אך כשהתיישבנו לכתוב מסמך כזה לקבלן חיצוני גילינו במהלך הכתיבה והדיון עם קבלני החוץ עד כמה חשוב המסמך. ולכן, כהמשך ישיר לפוסט הקודם שלי לגבי איך לנהל מיקור חוץ (outsourcing) נכון, החלטתי להקדיש את הפוסט הנוכחי ל-Statement of work – מה הוא, למה הוא משמש והכי חשוב, שיתוף עם חמישה טיפים לכתיבת מסמך כזה.
אז מהו SOW?
ה-SOW נועד להציג ולפרט בצורה ברורה את המוצר (אפליקציה, חומרה וכו') שאנו רוצים לייצר או שמישהו ייצר לנו. המסמך כולל פרטים טכנים, כגון מה אמורים לפתח (מידות, פעולות, עיצוב וכו',) אבל גם פרטים כללים יותר, כגון מטרת העל של המוצר, מי קהל המשתמשים, מחיר לפיתוח ותנאים בהם המוצר אמור לעבוד (שטח, בית, נישא וכו').
למי מיועד ה-SOW ומה הוא מממש?
לרוב המסמך נכתב כדי שהמבצע יוכל לפתח את הנדרש. הוא נכתב כדי שהקבוצה שיוזמת את הפיתוח תוכל לפרט אותו למפתחים או לקבלן. המסמך מאפשר לכלל הקבוצות המעורבות במיזם להבין את הרעיון הכללי ולאלו שמעוניינים גם את הפרטים. קיים סיכוי ממשי בו אלו הנדרשים לכתוב את המסמך הזה עושים זאת בפעם הראשונה, בהם הם ממש כותבים את הרעיון שלהם, ואיך לממש אותו ברמת השימוש והעיצוב. בעבודה מול קבלן המסמך משמש לרוב לכתיבת החוזה (כי הוא מגדיר את ה-scope של העבודה) ולפעמים הוא מצורף כחלק בלתי נפרד מהחוזה.
עכשיו שהבנו למה המסמך משמש ולמי הוא מיועד – הנה 5 טיפים לתכנון וכתיבת המסמך. אני אקח לדוגמא יצירת מסמך כזה לאפליקציה שאתם רוצים שקבלן יפתח לכם:
1. תכנון, תכנון, תכנון – אני לא יכול להדגיש כמה התכנון חשוב פה. אתם אומרים לעצמכם – אבל אני יודע מה המוצר אמור לעשות ואיך לתאר את זה, כבר ביררתי ויש שוק – אז מה הבעיה? ברגע שכותבים את זה על נייר הכל מתחיל להסתבך. התכנון אמנם צריך להיות ב-high level ואין צורך לציין כל פרט קטן, אבל כן חשוב לעשות סכמה שתראה לכם איך הכל מתחבר. מהר מאוד תבינו שלמרות שבראש הכל היה נראה נוח וברור, על הנייר פתאום רואים שיש כמה אופציות – איזו הכי טובה/נכונה למימוש? האם אחת עלולה להיות יותר מסובכת למימוש מאחרת? איזה מסך מתחבר לאיזה מסך? האם יש מסכים שזהים במהותם? לדוגמא באפליקציה מתחום הספורט – יכול המשתמש להכניס את סוג הפעילות שהוא עושה ולהפעיל שעון עצר למשך הפעילות. נכון, יכולים להיות כאן אין ספור מסכים, אבל מאחורי הקלעים הם מאוד דומים – לכל אחד יש שעון עצר וטקסט שונה, אבל הם דומים מאוד. זה אומר שגם יש פחות קידוד למפתח וגם שאתם צריכים לדעת איך לחבר בין המסכים האלו בצורה נוחה – צורה גנרית לכל המסכים שלא תאבד מכוחו של כל מסך.
2. בשלב הזה כבר תכננו את כל מה שהיינו רוצים שהאפליקציה שלנו תוכל לעשות. רוב הסיכויים שעכשיו הכל נראה פשוט וטריוויאלי אבל יש סיכוי שלא באמת פשוט לבצע כזה קידוד, כפי שזה נשמע. בשלב הזה עדיף להחליט מה באמת חייב שיהיה באפליקציה ואי אפשר לוותר עליו, ומה רצוי אבל לא חובה (nice to have). העקרון הזה נובע מתפיסת ה״סטארטאפ הרזה״, כלומר להתחיל לתכנת רק את מה שהכרחי. את כל השאר אנחנו עדיין נפתח, רק בתור שלב ב' בפרוייקט שלנו אחרי שנסיים את כל פיתוח החובה ולאחר בדיקתו הן על ידינו והן עם משתמשים אמיתיים. תאמינו לי, אתם תלמדו המון מזה שיתחילו להשתמש באפליקציה שלכם, והלימוד הזה ישפיע מאוד על שלב ב' שכנראה כבר לא יראה כמו שתכננתם אותו בשלב הקודם של תהליך כתיבת ה-SOW.
3. אל תשאירו כלום (עד כמה שאפשר) לדימיון. אתם יודעים איך אתם רוצים שהמסכים שלכם יראו. וכמו שאומרים – תמונה אחת שווה 1,000 מילים. אז במקום לכתוב 1,000 מילים תציגו את המסכים. באופן הפשוט יותר ניתן להשתמש אפילו בתוכנה כמו power point באמצעות ריבועים וטקסטים. אם בא לכם להשקיע מעט יותר, יש הרבה אתרים שמאפשרים יצירת MockUp בחינם, ולדעתי יספיקו לרובינו (לדוגמא gomockingbird או fluidui. כמובן שאפשר בתשלום זעום לקבל עוד פונקציות ואופציות. בכל מקרה ככל שתצליחו להמחיש (צבעים, מיקום וכו') כך תחסכו בעיות בשלבים מאוחרים יותר. כמו כן, כדאי שתזכרו ברמה כללית כל טקסט שאתם רוצים לכתוב (בערך מה תכתבו, מיקום, וכמה מקום יתפוס).
4. המסמך שכתבתם עד כה יראה לכם ממש ברור כשאתם קוראים אותו (ואתם תקראו את זה הרבה במשך התהליך, בין אם תרצו או לא תרצו). אבל רוב הסיכויים שלמישהו שלא "חי" את הרעיון זה, המסמך לא יהיה הכי ברור. לכן שווה להשקיע עוד מעט: (א) תכתבו הקדמה – מה הרעיון הכללי שלכם, כיצד יעבוד – תדאגו לציין את הנקודות החשובות ביותר כך שיבינו אותם בצורה הכי בסיסית. (ב) תוסיפו חלק (לדעתי הכי נוח טבלה) שמסביר לגבי כל מסך, בלא יותר מ 3-4 מילים, מה הוא עושה, ואם יש הערה מיוחדת לגביו (לדוגמא, צריך להופיע בעמוד הראשי, קיים לינק אליו, זהו דף עיקרי שחייב שתהיה אליו גישה מכל מקום באפליקציה, או שזהו דף שמופיע רק פעם אחת – כמו הרשמה).
5. החלק האחרון (אחרי שכמובן קראתם את זה כמה פעמים, תיקנתם שגיאות, ואתם מרוצים) הוא לתת למישהו אחר, שלא מכיר את הרעיון לעומק, לקרוא את זה. מבט חיצוני הכרחי כדי לדעת האם אתם באמת ברורים גם למי שאינו מעורה בפרטים. לאחר שאותו גורם חיצוני יקרא את המסמך, בקשו שיסביר לכם (אל תספרו לו או לה את זה לפני) מה הרעיון, מה הכי חשוב שיבוצע, ואיך. תראו איפה יש פערים ותתקנו. את השלב הזה עשו מספר פעמים, עם אנשים שונים – לפי ראות עינכם.
כעת אתם מוכנים לשלוח את המסמך לקבלן/מתכנת ה-in-House שלכם או כל אדם אחר אשר צריך את המסמך בכדי לפתח את המוצר. כמובן שאפשר לשנות את המסמך אחר כך. זכרו שהמשמעות של מסמך ברור וקריא על טיב העבודה שלכם עם הצד השני עשויה להיות קריטית לשיתוף הפעולה ביניכם.