מה הכוונה ב-team player ?

  • פותח הנושא wolik
  • פורסם בתאריך

wolik

New member
מה הכוונה ב-team player ?

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

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

לכן לא מובן לי המושג team player. האם מישהו יכול לתת לי דוגמה למצבים שבהם יש באמת עבודת צוות אמיתית.

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

ai21

New member
הדבר הקלאסי הוא 2 מודולים שמפותחים במקביל

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

rontech

New member
עבודת צוות בהייטק....

1. אתה הולך לשבת בצפיפות עם עוד 20 אנשים (כמעט כתף לכתף) בחדר/חלל אחד ואתה חייב להשתלב בחבר'ה....

 

rontech

New member
עבודת צוות זה גם...

שאתה נראה מגניב ומשתלב היטב באירועים חברתיים ומסיבות...

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

rontech

New member
עבודת צוות זה גם...

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

 

user32

Well-known member
מנהל
האמת שרונטק די קלע למציאות

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

choo

Active member
בכל חברה ובכל צוות זה אחרת

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

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

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

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

3. כמה יש code reviews שבהם מעבירים ביקורת והצעות לשיפור בקוד שכתבת? ככל שזה יותר הדוק ויותר מחייב - אתה צריך להתארגן על זה.

4. יש חברות (מעטות יחסית) שמשתמשות בשיטה של pair programming במהלך כתיבת הקוד.

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

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

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

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

אפשר להמשיך את הרשימה....
 

wolik

New member
אני כותב בעיקר קוד POC בחברה קטנה

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

לכן כל הקטע של team player זה משהו שאני אפילו לא מדמיין איך זה עובד במקום רציני.
 

AnarchistPhilosopher

Well-known member
עזוב הייטק, כדורסל זה משחק סוליסטי

אתה נגד 5 שחקנים אחרים.
&nbsp
והצוות התומך בצד מסתכל
 

Astroo

New member
team player זה מישהו מקובל חברתית

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

jellymean

New member
אז הנה המצב....

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

 

jellymean

New member
להלן הגדרת team player מכתבה בגלובס

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

 
למעלה