סוגיה בחיי מפתח תוכנה..

lital10000

New member
סוגיה בחיי מפתח תוכנה..

היי. נקודה שחשבתי להתייעץ לגביה:

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

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

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

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

מה דעתכם?

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

lital10000

New member
תודה

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

hadooper

New member
זה תלוי במקצועיות המנהלים... יש גם מנהלים לא מקצועיים

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

lital10000

New member
יש הרבה, לצערי..

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

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

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

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

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

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

choo

Active member
לקרוא וליישם

 

lital10000

New member
תודה

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

הפרבולה

New member
לא צריך להתרגש מזה יותר מידי

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

Grosseto

New member
שיטת פיתוח לגיטימית שנקראת "ספירלה"

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

lital10000

New member
נשמע סבבה..

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

liron50

New member
מתעדים הכל

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