יצא למישהו לעבוד בסטארט אפ שמתנהל בצורה לא מסודרת?

[ShadowKit]

אני עובדת בסטארט אפ שמונה כ-50 עובדים בערך, כבר מהרגע שהגעתי הרגשתי שמתנהל שם כאוס
1. הרבה דברים נאמרים בעל פה, ללא תיעוד, כולל דברים שאני צריכה לעבוד עליהם וזה גורם לי לפספס דברים שנאמרים
2. התיעוד ברובו לקוני ואי אפשר להבין ממנו כלום, אלא אם כן אתה זה שעובד על הפיצ'ר
3. חלק מהאנשים מאוד לא אינפורמטיבים כששואלים אותם שאלה (גם אם אני תלויה בהם לעבודה שלי ואמורה לקבל מהם את המידע הזה) וממש יש הרגשה שצריך "לרדוף" אחריהם כדי להוציא מידע, בנוסף, לעיתים קרובות מתנהגים כאילו אני הייתי מעורבת לכל אורך תהליך הפיתוח ואני מכירה את כל הכלים, שפות, ספריות וכו וכו שהם עובדים איתם (לא קורה בפועל, כולנו עובדים עם כלים אחרים)
4. רוב הזמן אני מרגישה שאני זאת שלא מקצועית, כי אני לא מצליחה לעקוב אחרי הכאוס... אבל בעיקר, כי מתנהגים כאילו אם לא הצלחתי לעקוב אחרי הכאוס אני זו שלא מקצועית
5. שמעתי את זה מעוד אנשים שהגיעו לחברה בשנה האחרונה

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

 

[ai27]

אני עובדת בסטארט אפ שמונה כ-50 עובדים בערך, כבר מהרגע שהגעתי הרגשתי שמתנהל שם כאוס
1. הרבה דברים נאמרים בעל פה, ללא תיעוד, כולל דברים שאני צריכה לעבוד עליהם וזה גורם לי לפספס דברים שנאמרים
2. התיעוד ברובו לקוני ואי אפשר להבין ממנו כלום, אלא אם כן אתה זה שעובד על הפיצ'ר
3. חלק מהאנשים מאוד לא אינפורמטיבים כששואלים אותם שאלה (גם אם אני תלויה בהם לעבודה שלי ואמורה לקבל מהם את המידע הזה) וממש יש הרגשה שצריך "לרדוף" אחריהם כדי להוציא מידע, בנוסף, לעיתים קרובות מתנהגים כאילו אני הייתי מעורבת לכל אורך תהליך הפיתוח ואני מכירה את כל הכלים, שפות, ספריות וכו וכו שהם עובדים איתם (לא קורה בפועל, כולנו עובדים עם כלים אחרים)
4. רוב הזמן אני מרגישה שאני זאת שלא מקצועית, כי אני לא מצליחה לעקוב אחרי הכאוס... אבל בעיקר, כי מתנהגים כאילו אם לא הצלחתי לעקוב אחרי הכאוס אני זו שלא מקצועית
5. שמעתי את זה מעוד אנשים שהגיעו לחברה בשנה האחרונה

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

אכן יש כאלו - אבל מה שאת מתארת זה לא כאוס.
1. הרבה דברים נאמרים בעל פה - משמע יש תיעוד. מצפים ממך לאחריות בנושא גם אם זה לא הוגן.
2. תוצאה של חוסר ידע בתיעוד גורם לתיעוד גרוע. גם זה נפוץ בחברות בלי עבר מסודר.
3. אפילו הצורך "לרדוף" אחרי בעלי ידע זה נפוץ - אפילו באינטל זה ככה. היום אתה רודף ומחר להפך.
4. זה נכון - בתור מהנדסת מצפים ממך שתלמדי להתמודד עם הכאוס, לסכם/לנסח מה הבנת מהדרישות, לבקש אימות, ולנסח מה את צריכה. למעשה - זה חלק מהליך פיתוח סטנדרטי.

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

 

[ShadowKit]

אכן יש כאלו - אבל מה שאת מתארת זה לא כאוס.
1. הרבה דברים נאמרים בעל פה - משמע יש תיעוד. מצפים ממך לאחריות בנושא גם אם זה לא הוגן.
2. תוצאה של חוסר ידע בתיעוד גורם לתיעוד גרוע. גם זה נפוץ בחברות בלי עבר מסודר.
3. אפילו הצורך "לרדוף" אחרי בעלי ידע זה נפוץ - אפילו באינטל זה ככה. היום אתה רודף ומחר להפך.
4. זה נכון - בתור מהנדסת מצפים ממך שתלמדי להתמודד עם הכאוס, לסכם/לנסח מה הבנת מהדרישות, לבקש אימות, ולנסח מה את צריכה. למעשה - זה חלק מהליך פיתוח סטנדרטי.

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

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

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

 

[ai27]

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

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

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

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

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

 

[ShadowKit]

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

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

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

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

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

 

[ai27]

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

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

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

 

[ShadowKit]

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

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

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

 

[ai27]

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

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

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

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

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

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

 

[ShadowKit]

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

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

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

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

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

 

[ai27]

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

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

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

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

ברור לי שזה לגמרי בדיחה,
אבל אפילו באינטל יש סטארים כאלו - אז הציפיות שלך לא מציאותיות

 

[d70]

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

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

בהקשר לאינטל, הפרויקט שאני השתתפתי בו דווקא התאפיין בהרבה חוסר סדר. הקוד (הגרמני) לא הכיל שום תיעוד. לחלק מהעמיתים מחו"ל לא היה זמן או רצון לעזור, מה שדרש התערבות מנהלים כדי לחבר את הצדדים. הגודל אגב גרם לברדק באספקט אחר. כל פעם החליפו את הצורה בה מתעדים. פעם ב share point פעם ב wiki וכו' .הבעיה - נוצרה פרגמנטציה בתיעוד ואנשים נאלצו לנסות להיזכר באיזו פלטפורמת תיעוד נמצא החומר....
לדעתי חלק מהגודל של אינטל (ומנסיוני בעוד חברה גדולה מאוד) מורכב מחברות שנרכשו ואיתם באו הרגלי עבודה (לטוב ולרע) של עידן הסטארט אפ.
לגבי הטענה שהברדק גורם לבזבוז משאבים - נכון. מצד שני גם עשיית סדר מייצרת הוצאות.
באינטל מדובר בשכבה של כמות נכבדת (והפחות עדינים אומרים מוגזמת) של מנהלי פרויקטים ואנשי סיסטם שעולים כסף ומייצרים המון פגישות סנכרון.

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

 

[חזי2003]

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

 

[ShadowKit]

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

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

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

 

[choo]

האם קראת את הספר "כל סטארטאפ צריך מרפסת"?

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

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

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

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

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

 

[חזי2003]

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

 

[ShadowKit]

האם קראת את הספר "כל סטארטאפ צריך מרפסת"?

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

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

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

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

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

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

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

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

 

[choo]

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

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

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

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

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

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

 

[ShadowKit]

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

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

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

לא יודעת אם הייתי קוראת לזה יוזמה ומוטיבציה, יש לי יוזמה ומוטיבציה לעשות הרבה דברים, ואני יכולה להשקיע בדברים שעות מ-0 ולעשות אותם בצורה הכי טובה ומקצועית שאני יכולה להביא, אבל... זה יותר עובד לי כשאני עובדת *לבד*.

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

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

 

[חזי2003]

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

 

[קלייטון.ש]

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

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