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

שיטת העבודה: ספרינט, agile וסתם חפיף

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

השמות הבאים מדברים על מתודולוגיות זהות או מקבילות של סוג זריז יותר של פיתוח:

agile  -(או גמיש) שובר את שיטת העבודה הכרונולוגית הישנה – שבה החבילה עוברת (כמו נהר או מפל) מאחד לשני. במקום זאת מנהלים שני קווים מקבילים של תכנון וביצוע (בו זמנית).אחת הנקודות החשובות בניגוד לשיטת המפל – היא שהשיטה הזאת היא שיטה “איטרטיבית” – כלומר היא מבוססת על בדיקה וביקורת של התוצאות בכל “סיבוב”.

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

lean startup – הוא מושג נוסף שמתאר שיטת עבודה -ספיציפית לסטרטאפים לייצר MVP בסוג של agile רק שהאיש שכתב ת’ספר רצה למכור אותו אז הוא שינה את זה ל lean.;)

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

design sprint – היא שיטת עבודה שמטרתה לייצר מוצר מורכב, בזמן קצר יחסית. כמו שמתייחסים לריצת ספרינט מדובר בעוד סוג של שיטת “agile”. השיטה של ספרינט מוגדרת כזמן של שבוע או שבועיים ויש מאחורי “ספר חוקים” שלם. כל ספרינט הוא בעצם “לופ” שבו פיתחנו וגם בדקנו את המוצר מחדש ולאחריו נתחיל עוד אחד.

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

הבעיות – לנסות לרוץ ולצאת להליכה

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

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

sprint

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

  1. understand
  2. Define
  3. Diverge
  4. Decide
  5. Prototype
  6. Validate

כמה מהם כוללים לדעתכם אשכרה לכתוב קוד? הטעות הנפוצה היא להתייחס לתהליך העיצוב רק לprototype ולהתעלם מ5 החלקים האחרים.

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

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

הבעיה של לוחות משימות וחלוקה לצוותים: tunnel vision, וחוסר תקשורת.

פתרונות

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

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

כלים לעבודת צוות (כמו trello jira slack) הם טובים כי הם מאפשרים תקשורת בין צוותים שנים – אבל חשוב להדגיש שכולם צריכים גם לדעת להשתמש באותם כלים באותם דרכים – אחרת ניהול המשימות יכול להיות מגדל בבל בו כל אחד עושה מה שהוא חושב לנכון ואין שום תועלת בתהליך. עוד משהו שחשוב לזכור שהכלים הללו משתמשים במתודולוגיות שלא דורשות חשמל בדרך כלל, כמו לוח kanban או scrum שבהם ניתן גם לעשות שימוש על ידי תלייה על הלוח..

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

חשוב לזכור

אני רק מנסה לדבר על ייעול.

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

לקריאה נוספת: