סטארטאפ 101: 7 מוקשים לעמידה ביעדי זמן פיתוח

מאילו פעולות מומלץ להמנע בכל הנוגע ללוחות זמנים והתנהלות מול לקוחות? אלון שבט מונה שבעה מוקשים שכדאי לשים לב אליהם

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

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

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

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

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

ליקטתי ”worst practices” להנאתכם:

1. קבעו מחדש יעדים לא ריאליים לצוות הפיתוח

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

2. החליפו מנהל פיתוח לדמות יותר סמכותית, אולי בעלת רקע צבאי

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

3. הפעילו לחץ על לחץ כדי להניע אנשים

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

4. דרשו הרבה דו”חות ברזולוציה גבוהה

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

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

5. דכאו אמירות פסימיות

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

6. שדרו אופטימיות ללקוח

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

7. אל תנהלו trade-offs שיקצרו את זמן הפיתוח

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

כתב אורח

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

הגב

5 תגובות על "סטארטאפ 101: 7 מוקשים לעמידה ביעדי זמן פיתוח"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

* היי, אנחנו אוהבים תגובות!
תיקונים, תגובות קוטלות וכמובן תגובות מפרגנות - בכיף.
חופש הביטוי הוא ערך עליון, אבל לא נוכל להשלים עם תגובות שכוללות הסתה, הוצאת דיבה, תגובות שכוללות מידע המפר את תנאי השימוש של Geektime, תגובות שחורגות מהטעם הטוב ותגובות שהן בניגוד לדין. תגובות כאלו יימחקו מייד.

סידור לפי:   חדש | ישן | הכי מדורגים
Eitan Shabtay
Guest

מאמר מעניין מאוד.

שטויות
Guest

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

נמרוד
Guest

נקודות חשובות בהחלט.

Ellen Ben-Tvi
Guest

מרתק!

אלי
Guest
כמי שלא ישן לילות מדאגה ומה יהיה…אני יכול לומר שהנקודה הראשונה שצריך לטפל בה – היא איש המכירות או המנהל שמבטיח תאריך יעד לא סביר. לקוח שתמעקש ואמאיים ואתה לא רוצה לאבד את העסקה לפעמים שווה לאבד עיסקה מאשר צוות שלם. בנק וחברת אשראי הגיעו אלינו עם קמפיין מדהים הכולל משחקים, אפליקציות חברתיות ומערך שלם של עסקאות. המחיר היה מפתה בטירוף פי ארבע ממה שאנו מקבלים לפרוייקט דומה, אולם עם לוח זמנים של חודשיים. ניתחנו את כל המשמעות במיוחד הבאטחה והגענו למסקנה שצריך לפחות 4 חודשים. לא הסכמתי לקבל את הפרוייקט ללא שינוי בלוחות זמנים. הם חיפשו מפתחים אחרים ואני… Read more »
wpDiscuz

תגיות לכתבה: