תחזוקה בעבודה

[yourockmyworld]

תחזוקה בעבודה

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

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

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

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

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

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

זה נורמלי? זה מראה על איזשהי תופעה לא תקינה בחברה? מה הייתם עושים במצב כזה?

 

[choo]

זה מראה על מוצר בשל בשוק שאין בו חידושים

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

 

[מריגוראונד]

אתה יכול לתת לדוגמא של חברות כאלו?

שבהן יש קבוצת פיתוח לטפל רק בגרסאות ישנות של המוצר.
&nbsp

 

[choo]

יש לי דוגמא לא-עדכנית - סטארטאפ שעבדתי בו - פעל ככה

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

 

[אוהב להתווכח]

יש לי חבר שעובד בסיסקו

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

 

[selalerer]

אני מכיר את זה מאמדוקס.

חצי פרויקט עבד בתמיכה וחצי בפיתוח הגרסה הבאה.

 

[user32]

אני חולק החלוקה שלך

הבחור מתאר מצב שבו הוא אכן נתקע במוצר בשל ומסכים עם מה שאמרת שכנראה אין בו הרבה חידושים. לגבי השאר: מה שכתבת על חברות גדולות עם מוצר אחד הוא רחוק מלהיות נכון. אני יכול להעיד על הדוגמא שנתת (נטאפ) שיש להם קצת יותר מ"מוצר אחד" ואני עצמי סייעתי לפתח שם שני מוצרים חדשים וזה היה נטו 100% פיתוח ומעולם לא ראיתי לקוח שלהם וכמעט כל אנשי הפיתוח שם לא נגעו בלקוחות.
גם צ'קפוינט אמנם ממשיכים לקרוא למוצר שלהם "פיירוול" והוא קיים 25 שנה אבל הם רחוקים מלקפוא על השמרים ובהחלט עובדים כל הזמן בסביבה תחרותית מאוד. זה לא אומר שכל המתכנתים שם מבלים את זמנם במחקר פורץ דרך אבל זה בטח לא מוצר שנכנס לתחזוקה ונרקב ואני די בטוח שR77 לא דומה למוצר שגיל שוויד פיתח בשנות ה90 וR80 שאמור לצאת כנראה יציע דברים חדשים. גם אם תכנס לאתר שלהם תמצא רשימה ארוכה של מוצרים ובתור אחד שמתממשק לרובם אני יכול להעיד שלא מדובר באותו מוצר (אם כי רובם חולקים איזשהו בסיס משותף מטבע הדברים).

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

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

 

[מריגוראונד]

האם אפשר לדעת בבירור בשלב ראיון העבודה או אפילו לפניו

כמה פיתוח חדש אתה הולך לעשות?
במקומות שעושים בהם תחזוקה באמת יגידו לך שזה מה שאתה הולך לעשות?
&nbsp

 

[user32]

לא. אפילו כשאתה עובד אתה לא יודע

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

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

 

[מריגוראונד]

ועוד שאלה

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

 

[user32]

הטווח רחב מדי בשביל לתאר את זה

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

 

[zaske]

דוגמא מ codebase בן 15 תעזור לך?

כי אם כן, אוכל לפרט איך קוד בן 15 יכול להתפתח וגם לכלול בתוכו פיצ'רים חדשים

 

[choo]

בוא ניקח את צ'קפוינט: אתה יכול לתת דוגמאות קונקרטיות יותר?

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

 

[user32]

אתה מדבר מידיעה או מניחוש?

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

זה כמו להגיד איזה פיצ'ר גדול פיתחו בווינדוס מאז שיצאו עם 3.11? מי שיודע ווינדוס כנראה יודע מה השתנה שם ומי שלא אז הכל נראה לו אותו דבר. מניח שאפשר להגיד את זה על כל חברה.

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

 

[choo]

לגבי המובייל - מידיעה. לגבי השאלה על מה עוד - מן הסתם לא

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

 

[user32]

בתור מתכנת אף פעם לא הבנתי את זה

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

 

[הפרבולה]

יש גם פן חיובי בעבודה מול לקוחות

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