Posts tagged ‘פרדיגמה’

לשבור את הקיר

clip_image002[4]

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

אז בואו נתן דוגמאות לכמה קירות כאלה באירגונים חלקם פיזיים וחלקם וירטואלים:

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

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

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

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

הרצאה בכנס PMI

image

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

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

תשטויות

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

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

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

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

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

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

clip_image002

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

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

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

בואו נחבר את הנקודות עד כה + הבהרה

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

יופי !

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

מה היא הפרדיגמה? או…הבהרה לג’וני ולכולם

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

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

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

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

ושוב….. תודה רבה ג’וני.

לחיי המהפכה (המדעית) שבדרך

“המבנה של מהפכות מדעיות” הוא ספר העוסק בפילוסופיה של המדע שנכתב על ידי תומאס קון (Thomas Kuhn) בשנת 1962.

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

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

קון מתאר את התהליך המוביל לשינוי פרדיגמה בארבעה שלבים:

  1. 1. פרה-פרדיגמה עדיין אין שיטה מקובלת, מדובר בתחום חדש במדע, יש מספר קונבנציות ואין עיסוק המוני בנושא.
  2. 2. עליית פרדיגמה ותחילת תקופה של מדע תקני – המצב שבו ישנה פרדיגמה מקובלת על הרוב, מתוך הויקיפדיה : “הפרדיגמה היא מסגרת שהקהילה המדעית מקבלת על עצמה והיא מתווה לקהילה את אופי המחקר בתקופת המדע התקני. הפרדיגמה כוללת את תיחום בעיות המחקר הרלוונטיות לתחום המדעי, את חוקי המחקר בתחום, דרכי פתרון לדוגמה, שקון מכנה “אקסמפלארים”, את המכשור המתאים לצרכי המחקר, את היישומים הנלווים לו, את ההכללות הצורניות (נוסחאות וכו’), ואת האמונות המטאפיזיות המשותפות לקהילה (למשל: יש/אין ואקום, העולם מורכב מארבעה יסודות/חלקיקים/חלקיקים וגלים). קון מדגיש כי כדי שתאוריה תתקבל כפרדיגמה עליה להיראות טוב יותר ממתחרותיה, אבל אין היא נדרשת להסביר את כל העובדות בתחום. למעשה, עליה להשאיר “קצוות פרומים”, על מנת לאפשר את המשך העיסוק המדעי בתחום.
  3. 3. אנומליות – מצב זה קורה כאשר ישנן אי התאמות בין הצפוי למצוי, כלומר, מתגלות טעויות מסוימות בפרדיגמה. בד”כ חריגות אלה מוסברות ע”י אנשי המדע בעזרת הוספת חריגים לתאוריה המזוהה עם הפרדיגמה, אך לעיתים, מתפתח משבר.
  4. 4. משבר – כאשר מגיעים למצב שקיימות אנומליות רבות, ואין מצליחים להסביר את החריגות בצורה שמתקבלת על הדעת, בשלב זה בד”כ משקיעים אנשי המדע הרבה מאמצים בהוכחה שהפרדיגמה עדיין רלוונטית, וישנו קושי פסיכולוגי עצום המלווה בתסכול כאשר למעשה מתבררת האמת ה”לא נוחה”. שלב זה מוביל בד”כ למהפכה מדעית או “שבירת הפרדיגמה”. לאחר שלב זה אנו למעשה חוזרים לשלב 2 – המדע התקני.

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

למשל : הקזת דם (ראה הפוסט הקודם) אופטיקה לפני ניוטון, ואולי אפילו… פרויקטים של תוכנה ?

מתחילים להבין על מה אני מדבר ?