Read on Twitter
1/ בחרתי אצלנו גישה של אין-הערכות-זמנים ומדי פעם אני חוטף על זה 
https://abs.twimg.com/emoji/v2/... draggable="false" alt="🔥" title="Vuur" aria-label="Emoji: Vuur">. אני לפעמים גם מפקפק בעצמי על הבחירה. אז קצת על פיתוח בלי הערכות זמנים https://abs.twimg.com/emoji/v2/... draggable="false" alt="🧵" title="collectie" aria-label="Emoji: collectie">
2/ אני מסייג שלפעמים כן צריך הערכות. למשל אם אתם עובדים בחברת פרוייקטים, או אם יש התחייבות שיש לתת ללקוח וחייבים לדעת שהזמן שנבטיח לו יספיק. אבל רוב הזמן - considered harmful
3/ מהניסיון שלי בחברות מוצר, רוב השימוש להערכות זמנים הוא לא כדי לדעת מתי משהו הולך להסתיים לצרכי תכנון עתידיים, אלא משמש כאמצעי ליצירת ״לחץ חיובי״. כלומר, יש שחושבים שזה יגרום למפתחים לפתור בעיות מהר יותר (ספויילר: זה לא).
4/ בדרך כלל (=תמיד) הערכות לא מדוייקות. הן מפספסות מכל מיני סיבות (אופטימיות, הכוונה חיצונית, חוסר חשיבה על אירועים כמו חופשים, דברים בלתי צפויים וכו׳).
5/ בנוסף, ברוב המקומות ״הערכות === התחייבויות״ ברגע שהן יצאו מהפה של המפתחים. לכן כל שכבת ניהול מוסיפה באפר להערכה.
6/ זה גורם לחברה לשנות סדרי עדיפויות על בסיס הערכות לא נכונות. למשל: ״יש לנו רעיון לשינוי חשוב שיכול לגרום לחברה להצליח פי 100״. ואז ״זה יקח חודשיים לפחות״. ״אז לא משנה, בוא נעשה דברים פחות חשובים״
7/ מעבר לזה, חותכים פיצ׳רים לפני שהם נותנים value ללקוח כי ״אנחנו עובדים על זה מעבר למה שאמרנו״. בוא נשחרר משהו צולע ונעבור לדבר הבא כמו שקבענו מראש.
8/ ידוע גם שמפתחים שלא רוצים לעשות משהו יגידו שזה ייקח חודשיים וצריך לכתוב הכל מחדש כדי לתמוך בזה. אם הם רוצים (נניח לעבור ל-rust/microservices/other_hype) אז הערכה תהיה של יומיים שלושה, גג שבוע.
9/ חטפתי על זה מכל הכיוונים (לפעמים רק מבטים). פרודקט, מכירות, שיווק, תמיכה. בעצם כולם. לפעמים גם מפתחים לא אוהבים את זה. מרגיש שמשהו חסר. אולי אנחנו לא באמת עובדים באופן נכון?
10/ אז איך אפשר לעבוד בלי הערכות? פשוט עובדים על הדבר הכי חשוב. ומורידים ממנו כל דבר שהוא אקסטרה. ומשחררים ללקוחות בכמה שלבים שכל אחד מהם נותן ערך בפני עצמו. ככל שנתקדם נבין מתי המשימה תסתיים ונוכל לתאם את ההמשך.
11/ אני כן שואל מדי פעם כמה נראה שמשהו ייקח אבל באופן מכוון לא כחלק מהתחייבות או משהו שמכניסים למערכת ניהול המשימות. אני גם יודע לכוון אנשים להיות יותר שאפתניים או לכוון להיות יותר סקפטיים לפי הניסיון שלי.
12/ ואז עובדים באמת במקום להתעסק בתמחורי משימות והלקאה עצמית על אי עמידה בהערכות של עצמנו. אם יש מפתחים ומפתחות טובים בצוות, ויש להם את ההכשרה המוטיבציה והתנאים לעבוד, הערכות לא יגרמו להם לנוע מהר יותר.
13/ כן שמים לב אם דברים מתבדרים ואז מנסים להבין יותר טוב למה. האם האנשים הנכונים נמצאים בפרוייקט? האם ה-scope גדול מדיי? האם אנחנו מפוקסים ומבינים את הבעיה באמת.
14/ גם ראשי צוותים שואלים לפעמים למה אין הערכות זמנים - אנחנו רגילים לזה. הם בעצם שואלים ״איך אנחנו יכולים לגרום למפתחים לנוע מהר יותר?״. לזה יש לי הרבה תשובות (הכוונה, הכשרה, מוטיבציה), ולעיתים רחוקות התשובה תהיה על ידי התחייבות לזמנים.
15/ לפעמים אני משתמש בהערכה הפוכה. מבקש לעבוד על משהו מספר ימים ואם זה לא מתכנס עד תאריך מסויים, בוא נשב ונבין את הבעיה בצורה טובה יותר.
16/ לפעמים אני מרגיש צורך להתנצל בפני עובדים חדשים עם המון ניסיון שלא מבינים ״wtf, איך אפשר להתנהל ככה? למה שלא נהיה כמו כולם?״
17/ אבל כל פעם שאני חוזר ליסודות אני נזכר שהערכות זמנים לא עוזרות לנו להעריך את העתיד באמת. אם כבר, הרבה פעמים הן מסיטות אותנו מהדרך הנכונה לצעוד בה. ואם חשוב לנוע מהר קדימה: אנשים טובים, משימות טובות, מוטיבציה גבוהה.
