התלבטות מקצועית

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

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

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

תודה!
 

choo

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

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

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

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

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

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

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

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

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

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

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

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

קלייטון.ש

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


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

קלייטון.ש

Well-known member
בסביבות העבודה שבהן אני עבדתי במהלך השנים (ויש הרבה כאלו) - אין דבר כזה "לא צריכה להבין את התמונה הכללית". כבר מהימים(!!) הראשונים שלי בתחום הציפיה היתה הבנה של התמונה הכללית.


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