עצה דיפלומטית

[החיים בכלל]

עצה דיפלומטית

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

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

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

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

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

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

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

 

[choo]

מאוד פשוט - בלי פוליטיקה, עם מלוא הפרגמטיות

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

 

[החיים בכלל]

אנחנו מנסים לשלב Pair Programming באופן שוטף....

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

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

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

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

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

 

[choo]

מה הבעיה לקחת קטע אחד קטן מתוך משימה שוטפת, ולעבוד עליו בזוג

&nbsp
where there's a will - there's a way.
&nbsp
ביחרו משימה אחת, כל משימה, קחו קטע אחד שלה, קחו יום שבו לאף אחד מכם אין ישיבות (איו יום כזה? פנו יום אחד כזה) ושניכם מגיעים באותה שעה לעבודה, ועשו ניסוי.
&nbsp
לגבי הצוות התחרותי שלכם - אם תחרותיות מביאה להסתרת מידע - בעיני זה חוצה קו אדום, וזה משהו שצריך להעלות אותו מול ראש הצוות, או מול האנשים האחרים. אפשר גם לנסות לנהוג בצורה מוסתרת - לעסוק הרבה בשיתוף מידע (גם בשוטף, גם לארגן הרצאות פנימיות על תחומי ידע שיש לך ורלונטיים לאנשים אחרים) וליצור אוירת שיתוך מידע - ולקוות שזה יגרום לאנשים אחרים להיפתח ולשתף יותר בעצמם.
&nbsp
ולבסוף, צריך לזכור שאם את חוששת לדבר עם ראש הצוות בגלל פיגעה בקריירה שלך, גם כשזה נוגע לנושאים שפוגעים בקריירה שלך - משהו פה חייב להשתנות. התנהלות האנשים,ההתנהלות שלך, צורת התנהלות כלל הצוות, מעבר צוות או החלפת מקום עבודה. לטאטא בעיות מתחת לשטיח לא מוביל לדברים טובים - או שפותרים אותן, או שלומדים להסתדר איתן, או שעוברים למקום פחות בעייתי.

 

[החיים בכלל]

אין הסתרת מידע...

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

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

 

[choo]

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

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

 

[החיים בכלל]

לגבי הכותרת - אתה צודק

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

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

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

 

[choo]

"אי אפשר לחלק לחלקים" - הוא מפלטו של הנבל

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

 

[החיים בכלל]

אני יכולה להבטיח לך שאני ממש לא טרולית

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

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

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

 

[choo]

אם זו משימה של יום אחד - היא מצויינת ל-pair programming

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

 

[החיים בכלל]

השתי הנקודות אתה צודק

 

[Grosseto]

נשים...

 

[החיים בכלל]

תודה

 

[liron50]

שיטת הפיתוח זה רק תירוץ

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

 

[החיים בכלל]

בגלל זה יש תכנון מראש...

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

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

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

 

[user32]

לקחת אחריות על ההחלטות שלך

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

 

[choo]

יש בעיות שדיבוג שלהן בזוג מרחוק הוא עדיין אפקטיבי

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

 

[user32]

אפילו המציאו מקצוע כזה: תמיכת לקוחות

 

[choo]

תן לי תומך שידבג את הקוד שלנו כשאיננו בעבודה, ואהיה מבסוט :0

 

[החיים בכלל]

רק כמה הבהרות...

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

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

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