Posts tagged ‘אלעד סופר’

לא בשביל כסף

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

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

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

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

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

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

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

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

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

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

 

הבהרה מס’ 1: ברור ביותר שאני מדבר “מתוך פוזיציה” ולכן קחו בערבון מוגבל כל מה שכתוב בפוסט הנ”ל

הבהרה מס’ 2: לא כל יועץ אג’ילי מתאים לכל חברה יש עניין של “כימיה”  – אם לא הצליח לכם עם יועץ מסוים זה לא אומר שהוא “מתחזה” למומחה..

כלים אג’ילים – יש דבר כזה?

לא פעם ולא פעמיים אני נשאל:
“אנחנו מתחילים לעבוד בסקראם (או כל שיטה אג’ילית אחרת) באיזה כלי כדאי להשתמש בכדי לנהל את הפרויקט שלנו?”
וכמעט תמיד התשובה שלי היא משהו בסגנון “מה רע בלוח עם פתקים או כרטיסיות?” או במקרה הגרוע “מה רע באקסל או בכל גיליון אלקטרוני אחר?”  למה אני חושב ככה?

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

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

נסקור את הסיבות לשימוש ב”כלים אג’ילים” שאני נתקל בהן:

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

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

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

ניתוח נתונים: כלי אג’ילי מאפשר לי לנתח את הנתונים בפרויקט שלי: איזה נתונים בדיוק צריך לנתח שלא ניתן לעשות בכלים פשוטים? עלות פרויקט ליום? אני מוכן לתת לכם את הנוסחה הפשוטה (מספר אנשים שעובדים ליום * עלות של אדם ליום + תקורה יומית). הנתון הכי חשוב בפרויקט הוא Velocity והוא מחושב מעצמו ע”י ניהול נכון של פרויקט. ממנו קל לגזור נתונים חשובים כגון עלויות, זמנים ועוד.לצורך ניתוח נתונים אין צורך בכלי!

עקרון חשוב ומנחה במניפסט האג’ילי (עקרון 5) הוא:

Build projects around motivated individuals, give the environment and the tools they need, and trust them to get the job done.

עקרון נוסף חשוב (עקרון 11) הוא:

The best architectures, requirements and design emerge from self-organizing teams

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

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

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

לסיום אני רוצה לצטט משפט מתוך ספר של בס וודה וקרייג לרמן:
If you automate a mess, you will get an automated mess.

הרצאה בכנס PMI

image

לאחרונה הצגתי בכנס PMI הרצאה שנותנת מבוא לאג’יל (Agile) וסקראם.

אם אתם מוצאים את זה מעניין, אז הנה לינק למצגת.

תהליך הטמעת סקראם

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

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

בקווים כלליים לתפיסתי הטמעה מתחלקת לארבעה חלקים עיקריים:

– הדרכה
– הצבה של תשתית מתאימה לשינוי
– ליווי ותמיכה
– כוונון (Tuning).

הדרכה – שלב ההדרכה הוא באורך יומיים בד”כ, וכולל העברה של המושגים הבסיסיים של Agile ו-Scrum והבנה עמוקה יותר של הסיבות והתמריצים לאמץ את הדברים.

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

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

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

פתח דבר

אז נשאלת השאלה, מה גורם לאדם להחליט לפתוח בלוג ?
במקרה שלי, כפי שתיראו בהמשך – פשוט כי אני חייב. כן, חייב!

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

במשך שמונה השנים הללו תמיד הייתה לי הרגשה שהדרך שבא אנחנו מייצרים תוכנה היא לא…. איך אומרים… לא משהו.
כלומר – או שהאיכות לא משהו, או שלא עומדים בזמנים, או בתכולה.
אתם בטח יודעים על מה אני מדבר.

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

אני חושב שמצאתי משהו שיעזור לנו (וכבר עוזר לארגונים שונים בעולם) לשפר את הצורה שבא אנחנו מייצרים מפתחים תוכנה, ואולי אף לפתור חלק מהבעיות.

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

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

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

המלצות להמשך הדרך: אל תאמינו לאף מילה שאני אומר, תפקפקו בהכל.

בקשות להמשך הדרך: שתפו אותי, תאתגרו אותי, תלמדו אותי.