דעה: איך להתקדם בארגונים?

הפוסט הבא, הוא פוסט לא כ"כ שגרתי בבלוג: הוא עוסק יותר בניהול מאשר בטכנולוגיה או ארכיטקטורה.

מדוע אם כן אני כותב אותו?

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

על בסיס איזו מומחיות אני כותב את הפוסט?

• לתפקיד הראשון שלי (ארכיטקט) התקדמתי דיי מהר - פחות מ 4 שנים בתעשייה. מאז קצת יותר לאט :)
• בעיקר בתור צופה, שעובד עם הרבה אנשים וצוותים - וחווה את הדינמיקות הארגוניות כבר שנים.
  בהקצנה: כפי שניקולו מקיאוולי כתב על משילות, למרות שמעולם לא שלט בעצמו.
• על בסיס 2 ה Reviewers שלי לפוסט, בעלי הניסיון הרב הנושא: אליאל שורמן (מנהל קבוצת פיתוח ב SAP) ונמרוד ברק (דירקטור פיתוח ב SAP) אשר קראו, הוסיפו, ותרמו באמת לפוסט. תודה רבה אליאל ונמרוד!

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

תיאום ציפיות קצר: אל תצפו לקסמים.

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

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

המודל הבסיסי 

אני לא מכיר שום מודל קיים בנושא, ולכן אגדיר אחד:

מודל לקידום בארגונים

קידום מתבצע כאשר מתקיימים 3 תנאים:

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

על תנאים 1 ו 3 - אין לכם הרבה שליטה. זה עניין של סבלנות, הזדמנות, ומזל.
תנאי מס' 2 - הוא כולו באחריותכם.

והנה הפתעה: את הקרדיט הזה לא בונים בעזרת "עשיית התפקיד שלכם בצורה הטובה ביותר".

הקרדיט בעצם בנוי מ-2 מרכיבים עיקריים:

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

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

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

כנ"ל לגבי תפקיד טכנולוגי, כגון ארכיטקט:

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

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

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

הקרדיט הכולל שלכם מנוהל בכמה "חשבונות" בצורה מצרפית:

• חשבון "המנהל[ב] הישיר שלכם" - שזה החשבון הפעיל והחשוב ביותר.
• חשבון "העובדים המקבילים לכם (peers)" - אלו שעובדים אתכם בצוות, או עובדים אתכם על אותן המשימות. 
• חשבון "המנהל של המנהל שלכם + מנהלים אחרים בארגון (ההנהלה)" - שניזונים במידע אודותיכם מהעובדים שלהם, מהמנהל שלכם ואחד משני. שלא תטעו במחשבה שהם לא מכירים אתכם: לכל אחד, כמעט, יש אצלם חשבון.

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

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

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

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

טקטיקות נפוצות לקבלת קידום - וניתוחן ע"פ המודל

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

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


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

בקיצור: טקטיקה שנויה במחלוקת.

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


אכפתיות והפתעה לטובה
לעשות דברים קטנים שלא מבקשים מכם, ולהיות אכפתיים יכולים לייצר לכם הרבה קרדיט חיובי.
דוגמה אישית 1: פעם בכל התקנה של מכונה אצלנו, היה צריך לקחת template של XML ולמלא אותו עם פרטי המכונה ולזרוק באיזו תיקיה. כמתכנת - כתבתי servlet שמייצר את ה XML אוטומטית בזמן ריצה ושיניתי את הקוד שיקרא את ה servlet ולא את הקובץ בדיסק. זו הייתה עבודת תכנות קטנה מאוד - אבל שיצרה לי המון קרדיט בקרב peers ומנהלים.
דוגמה אישית 2: בחברה אחרת, היו במטבח 4 קופסאות עוגיות אטומות, שכל יום שמו בהן חטיפים אחרים. כן, עוגיות. כל מי שבא להפסקת קפה היה פותח את כל הארבעה אחת אחרי השנייה - בכדי לבדוק מה המבחר באותו הרגע. זה היה טקס מציק - אך כולם עשו אותו מבלי לשים לב. ביקשתי תקציב וקניתי 4 קופסאות שקופות - והפעולה הקטנה הזו יצרה לי יותר קרדיט מהרבה עשייה מורכבת וקשה יותר. היא לא הייתה קשורה לתוכנה, אבל היא נגעה לכולם והפגינה אכפתיות.

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

walk the walk, talk the talk

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

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

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

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

בקיצור: אפקטיבי רק כאשר יש לכם קרדיט משמעותי.



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

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

בקיצור: להימנע! זוהי טקטיקה יעילה רק בדבר אחד: למנוע מעצמכם קידום.


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

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

תרגיל: קבעו לעצמכם תזכורת שבועית ביומן בשם "לפרגן למישהו". שלא תפספסו. זו טקטיקה טובה.


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

בקיצור: לא מספיק טוב.


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

חשבו גם על המנהל של המנהל שלכם: האם הוא יעדיף לנהל מישהו שמוציא את מנהלו טוב, או רע? - נחשו לבד.

בקיצור: טקטיקת בסיס חשובה.

אבני דרך חשובות

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


צרו לעצמכם הזדמנויות לקבל "קרדיט ניהולי"

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

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

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

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

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


בכל מקרה - כבדו את אסטרטגיה של הארגון

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

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

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

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

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

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

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

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

הפגינו מחויבות לארגון

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

כיצד נמדדת מחויבות לארגון?

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

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

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

אור הזרקורים

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

תכונות עצמיות להן כדאי לשים לב

נראות

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

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

להבין את רמת הנהילות שלכם

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

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

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

Troubleshooting

מנהל לא-טוב

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

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

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

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


המנהל אומר לי שאני מתאים, אך כבר זמן מה לא קורה שום דבר

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

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

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

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

סיכום

עבודה טובה היא לא קרדיט,
קרדיט הוא לא מוכנות לקידום,
מוכנות לקידום היא לא קידום,
קידום הוא לא אושר

כל עוד אתם זוכרים זאת - אזי הכל בסדר :)

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

לאן אשר תלכו - שיהיה בהצלחה!



----


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

[ב] או מנהלת, כמובן.

להבין Maven (הצצה ראשונית)

מייבן (Maven, מלשון "מבין" ביידיש) היא ספריית build ו dependency management לסביבת ה JVM, וג'אווה בפרט.

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

אמנם ל Gradle (ספרייה מתחרה, שהיא הטרנד החם בתחום) יש כמה יתרונות מובנים על פני מייבן (קלות תחזוקה: DSL מול XML + מהירות ריצה) - אבל ייקח עוד זמן עד שהיא תוכל להחליף את מייבן: ל Gradle אין עדיין repositories משלה, וכמות ה plugins הזמינים עבורה - נמוכה בהרבה. היא גם מתבססת על Groovy - שפה עם קהילה לא כ"כ גדולה [א].

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

בואו נתבונן לרגע על מרחב הכלים הקיים.

יש כמה וכמה כלי Build נפוצים:

• Make של C או ++C ו Unix (שנת 1977)
• Ant של ג'אווה (שנת 2000)
• מייבן של ג'אווה (שנת 2002)
• Rake של רובי (לא יודע ממתי בדיוק)
• SBT - קיצור של Simple Build Tool, של סקאלה (שנת 2008)
• Gradle לג'אווה / גרובי (שנת 2012)
• Grunt ו Gulp לג'ווהסקריפט (חדשות למדי).

ויש גם כמה כלים לניהול תלויות:

• מייבן - הכוללת גם כלי ניהול תלויות. אולי הראשון מסוגו.
• Ivy (שנת 2007) - קיימת כתת פרויקט של Ant, אך יש לה זכות קיום עצמאית. משמשת את SBT ואולי גם כלים אחרים.
• Gradle - התחילה כתלויה ב Ivy, אך פיתחה עם הזמן מערכת ניהול תלויות עצמאית.

מערכות לניהול תלויות הן מערכות דומות מאוד ל package managers, כמו אלו של לינוקס, npm של node.js, או bower של ספריות ג'אווהסקריפט. ההבדל הוא שהן מנהלות source code ולא code ל production (כך שאין צורך לבצע התקנה), ושיש להן אינטגרציה לכלי build: כאשר ב build מסומנת תלות בספרייה שלא קיימת - כלי ה build יוריד אותה בצורה אוטומטית, כך שה build יוכל להסתיים בהצלחה.

מה מייבן מספקת, ובמה היא טובה מ Ant?

קרן Apache מנהלת גם את Ant וגם את Maven. מדוע לנהל 2 ספריות מתחרות? מה מייבן (המאוחרת יותר) מנסה לעשות ש Ant לא עשתה?

המודל של Ant דומה למודל של MAKE: סקריפט המפעיל סדרה של פעולות לבניין התוכנה: העתקת קבצים, קומפילציה, מחיקת קבצים זמניים, וכו'. סקריפט פרוצדורלי / אימפרטיבי.

לסקריפט (קובץ build.xml, במקרה של Ant) יש כמה יעדים (Targets / Goals) שנקראים לרוב משהו כמו: build, clean, jar ו test - כ"א הוא תיאור של סדר הפעולות האטומיות (העתקת קבצים, קומפילציה וכו') הנדרש להשגת מטרה זו. בין ה targets השונים ניתן להגדיר תלות, כך שהפעלת אחד (למשל: אריזה ב jar) - תפעיל גם את התהליך בו היא תלויה (למשל: compile). מנגנון התלויות בין ה targets מאפשר לנו לעשות שימוש חוזר בסקריפט ה compile גם ב targets כמו jar או install.

תכונה שימושית נוספת ב Ant היא הגדרה של משתנים - המאפשרים לשנות במקום אחד פרמטר (כמו path מסוים) - ולהשפיע על כל הסקריפט.

דוגמה ל Ant Task פשוטה

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


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

• יש לקמפל את קבצי ה java לקבצי class ולשים אותם בתיקיה זמנית.
• מקמפלים ומריצים את הקוד של בדיקות היחידה.
• במידה והבדיקות עברו בהצלחה - בונים jar או war.
• מנקים את הקבצים הזמניים שנוצרו.

מדוע לכתוב את ה Script הזה כל פעם מחדש? האם האנושות לא יכולה לחסוך לעצמה את "המצאת גלגל ה build" - בכל פעם מחדש?

מייבן מספקת Archetypes (מעין templates) של פרויקטים נפוצים: פרויקט jar, פרויקט ווב, פרויקט ווב של backbone וכו'. שימוש ב Archetypes חוסכת הן עבודת קידוד והן עבודת תכנון - כיצד להרכיב את פרויקט ה build, באיזה מבנות תיקיות להשתמש וכו'.

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

כל פעולות ה build עצמן (יצירת תיקיות, העתקת קבצים, הפעלת קומפיילר וכו') מגיעות כ Plugins - וניתנים להחלפה. מייבן מספקת את המודל, קובץ הקונפיגורציה של מייבן מתאר את ה Strategy (ה design pattern), וה plugins עושים את העבודה.

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

מרגע שמבנה הפרויקט ידוע וקבוע - ניתן לספק הוראות הרבה יותר high level מאשר ב Ant: "בצע קומפילציה" במקום "צור תיקיה זמנית x", "הפעל את javac עם target של x", "העבר קבצים מתיקיה x לתיקיה y", וכו'.

פרויקט פשוט במייבן

יצירת פרויקט של מייבן מתוך Archetype (להזכיר: סוג של template של פרוייקט) יכולה להיעשות בעזרת command line, אבל בפועל כיום יש אינטגרציה לכל IDE נפוץ - כך שאין כ"כ צורך להכיר את ה command line. הבה נבחן את מבנה התיקיות של הפרויקט הגנרי של מייבן:

כמה הסברים:

• תיקיית src נועדה לקוד, ותיקיית target לתוצרי קומפילציה (קבצי class., למשל). 
• תיקיית ה src/main נועדה לקוד שמיועד לדילוור, ותחתיה יש תיקיה לכל שפת תכנות. יכולה להיות, למשל, תיקיה ל java, ל scala ול javaScript. ספריית ה src/test נועדה לקוד של בדיקות יחידה / אינטגרציה. בפנים יש תיקיות של ה java packages - כמו בכל פרויקט java רגיל.
• תיקיית src/main/resources/ נועדה לקבצים אחרים של הפרויקט שאינם קוד, למשל קבצי הקונפיגורציה של Spring Framework.
• את תיקיית ה target מחלקים לתוצרים של קוד שהולך לדילוור (classes) ותיקיית הקוד שלא הולך לדלוור (test-classes).
• pom.xml הוא קובץ הקונפיגורציה של מייבן, המקבילה של build.xml של Ant.

קובץ ה pom.xml (קיצור של Project Object Model) הוא קובץ XML, דקלרטיבי, שמגדיר את ה Strategy של תהליך ה build שלנו.

הנה דוגמה ל pom.xml מינימלי ביותר:

הסברים:

1. כל פרויקט מייבן מוגדר באופן ייחודי ע"י שלושה פרמטרים:
1. groupId - סוג של namespace שאמור להיות globally unique. בד"כ כתובת אתר האינטרנט של החברה שלכם בסדר הפוך של tokens.
2. artifactId - שם ייחודי, פנימי אצלכם, לפרויקט.
3. מספר גרסה, בפורמט: <major ver>.<minor ver>.<incremental ver>-<qualifier>, כאשר ה qualifier הוא טקסט [ב].
   ל qualifier בשם "SNAPSHOT" (אותיות גדולות) - יש משמעות מיוחדת, והיא משמשת לציין גרסה שעדיין בפיתוח שמשתנה כל הזמן. במקום לבדוק אם הגרסה התעדכנה בעזרת מספר הגרסה, הוא יבדוק את התאריך, כך שהמפתח לא נדרש לשנות כל רגע מספר גרסה בכדי שחבריו יקבלו גרסה עדכנית בכל build.
2. הגדרה של תלות בספריה JUnit. כ default קיבלנו את גרסה 3.8.1 - אך אנו יכולים להחליט שאנו רוצים לעבוד עם JUnit 4. שימו לב שגם ספרייה זו מזוהה בעזרת השילוש הקדוש: קבוצה, artifact וגרסה. זהו הזיהוי הייחודי ב repositories של מייבן.
3. זוהי תצוגת ה IDE למייבן של IntelliJ - בכל IDE יהיה משהו שנראה אחרת. אנו רואים את השלבים המרכזיים בתהליך הבילד כפי שהוגדר.

שנייה! לא הגדרנו כמעט כלום בקובץ ה pom.xml שלנו. מאיפה מגיעות ההגדרות הללו?

אם אנסה להריץ אחד השלבים, למשל test, מייבן יוריד לי ערמה של maven plugins הנדרשים להרצה - ויריץ קומפילציה ובדיקות בהצלחה. כיצד הוא יודע מה לעשות?

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

במקרה שלנו אין pom.xml אב, והקובץ שלנו כמעט ריק - אז ההתנהגות בה אנו חוזים מגיע בעיקר מה super pom.xml ומה settings. הרכבה של כל השכבות המוגדרות בקובצי ה pom.xml הרלוונטיים השונים נקראת effective pom.xml, ניתן לראות  אותה ב eclipse בתוך ה IDE. ב Intellij אני לא מכיר דרך לראות אותה, ולכן אני מריץ את ה command line הבא:

mvn help:effective-pom -Doutput=effective-pom.xml

דוגמה ל Effective-pom.xml מינימליסטי

הנה ה effective-pom.xml שנוצר לנו. בואו נבחן אותו. שימו לב שכמה חלקים הם collapsed:

1. ה dependencies היחידים הם אלו שהגיעו מה pom.xml שלנו - תלות ב Junit 3.8.1
2. ה repositories וה pluginRepositories כרגע הם ה central repository של מייבן, קרי http://repo.maven.apache.org/maven2.
   ה repositories מכילים הרבה (מאוד) פרויקטי open source ו/או maven plugins - אותם מייבן ידע להוריד אלינו למחשב ע"פ הצורך. כאשר עובדים ב IDE וזקוקים לאיזו ספרייה - פשוט מוסיפים אותה כתלות ב pom.xml ומייבן יביא אותה לבד ב build הבא. אם הספרייה שציינתם תלויה בספריות אחרות - מייבן תביא גם אותן. כמו כן - אותה הורדה תתרחש גם אצל מפתחים אחרים בצוות. זה היופי של ניהול התלויות של מייבן.
3. כאן ניתן לראות את מבנה הספריות של הפרויקט, כפי שתיארנו אותו קודם (כ full paths). מייבן משתמש ב super pom.xml במשתני-סביבה בכדי להגדיר את הנתיבים, וה effective-pom.xml כבר מכניס בהם את הערכים.
4. כפי שציינו, plugins הם אלו שעושים את כל עבודת ה build בפועל. ניתן לראות בדוגמה למעלה שני core plugins שמתארים את ההתנהגות של שלבי ה clean וה install של מייבן.
   Plugins אחרים שלא נכנסו לצילום המסך הם:
1. maven-resources-plugin
2. maven-surefire-plugin - הפלאג-אין של מייבן להרצת בדיקות-יחידה. אין לי מושג למה הוא קיבל "שם מגניב", ורבים אחרים - לא.
3. maven-compiler-plugin
4. maven-jar-plugin - כפי שהשם מצביע, הוא פשוט אורז קובץ jar.
5. maven-deploy-plugin
6. maven-site-plugin - הפלאג-אין של מייבן ליצירת תיעוד לפרויקט

בהמשך, נרחיב עוד על Plugins והקונפיגורציה שלהם.

Build Lifecycles

המודל של מייבן מגדיר 3 פעולות שמייבן יודע לעשות:

• לבנות תוכנה (ואולי גם להתקין אותה) - מה שנקרא ה default lifecycle
• לנקות שיירים (קבצים זמניים וכו') מבנייה קודמת (בעקרון: ספריית ה target) - מה שנקרא clean lifecycle
• בניית תיעוד לתוכנה (יצירת מערכת דפי html) - מה שנקרא site lifecycle, כלומר אתר אינטרנט (סטטי) הכולל את התיעוד של התוכנה.

כל אחד ממחזורים אלו בנוי מרשימה מוגדרת-מראש של שלבים (phases).
המשתמש יכול לבחור לבצע רק חלק מהמחזור שהוגדר ע"י מייבן. למשל: להפעיל את ה default lifecycle רק עד שלב הקומפילציה. שלבים מוקדמים יותר במחזור, כגון validation של פרויקט המייבן או יצירת ה resources הנדרשים - יופעלו, אבל השלבים המאוחרים יותר (כמו בדיקות או התקנה) - לא יופעלו.

שלבי ה Lifecycle השונים של מייבן, כאשר השלבים החשובים / היותר שימושיים - מוגדשים

כאשר אנו מפעילים את מייבן בכדי לנקות שיירים של בנייה קודמת, אנו מקלידים ב command line:

mvn clean

מה שיגרום למייבן לזהות שזהו שלב (phase) של ה clean lifecycle ולהפעיל את ה livecycle הזה עד שלב ה clean. שלב ה pre-clean יתבצע, אך שלב ה post-clean - לא יתבצע. כמובן ששלבים רבים במחזורי הפעילות של מייבן הם שלבים ריקים - אלא אם נגדיר בהם משהו.

בכדי להפעיל את כל ה clean lifecycle יש להקליד mvn post-clean. בד"כ אנו מסתפקים ב clean, הקצר יותר להקלדה.

האם איי פעם תהיתם מדוע אתם מקלידים (הפקודה הכי נפוצה אולי) "mvn clean install",
אבל לא "maven clean compile install", או משהו דומה?

התשובה עכשיו ברורה: clean נדרש מכיוון שהוא שלב ב lifecycle שונה מה default lifecycle. כאשר מפעילים את mvn install - הוא יבצע את כל 20 ומשהו השלבים מ validate ועוד install. הוא רק לא יעשה deploy.

הנה כמה מלים על מה שמייבן עושה בשלבים השונים של ה default lifecycle:

• validate - מוודא שפרויקט המייבן תקין, למשל: ולידציה של ה pom.xml, שכל המשתנים שבשימוש - מוגדרים, וכו'.
• generate sources / resources - שלבים שהוגדרו בכדי לשמש לשלבי pre-proccesing להתרחש (במידה ואתם משתמשים בכלים שמג'נרטים קוד או resources).
• compile - קומפילציה של קוד תחת ספריית main (לא כולל קוד של בדיקות)
• process-classes - שלבי post processing על קבצי ה class. שקומפלו, למשל "אריגה" של AspectJ על קבצים שכבר קומפלו (יש אפשרות כזו).
• test-compile - מקמפל רק את קבצי הבדיקות. אם אתם לא מתכוונים להריץ בדיקות - חבל על הזמן לקמפל את קוד הבדיקות, לא?
• package - אריזת הקוד ל jar, war, ear וכו'.
• integration-tests - שלב מיוחד של הרצת בדיקות על מערכת "חיה". מתקין את ה deployable שכרגע נארז על מערכת בדיקות, ומריץ מולה בדיקות אינטגרציה / מערכת (איך שאתם קוראים להן). ה plugin של מייבן שמריץ בדיקות אינטגרציה נקרא "failsafe".
• verify - שלב בו ניתן לבצע בדיקות נוספות על ה package הארוז - לוודא שהוא תקין.
• install - השם של השלב הזה הוא מעט מבלבל: ההתקנה היא של ה deployable ל local maven repository - ולא לשרת ה production כמו שאולי זה נשמע. ה local repository הוא צד של מייבן שעדיין לא נגענו בו בפוסט זה. נאמר כרגע שזו איזה תיקייה של מייבן בה הוא שומר deployables, pugins ו ספריות שנדרשות בגלל התלויות.
• deploy - עושה את מה שאפשר לחשוב: מתקין את ה deployable על שרתי ה production.

סיכום

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

• מהם בדיוק ה repositories?
• כיצד ה plugins משתמשים בשלבים השונים שמייבן מגדיר? מהם ה goals?
• ואולי הכי פרקטי: כיצד משנים את הגדרות ה pom.xml ורותמים את מייבן לצרכים הייחודיים של הפרויקט שלנו ?

אני מקווה לכסות לפחות כמה מנושאים אלו בפוסט המשך.


שיהיה בהצלחה!

---

[א] Groovy היא (מלבד ה nested classes) בעצם superset של ג'אווה. לכאורה, מאוד קל למתכת ג'אווה לעבור אליה: לשנות את סיומות הקבצים ל groovy. ולהימנע משימוש ב nested classes. בפועל, כמעט כל דוגמאות הקוד של gradle משתמשים בתחביר מתקדם של שפת Groovy - שיהיה זר ומוזר למתכנת ג'אווה שלא ישקיע זמן ללמוד אותו ואת הדקויות שלו.

[ב] בגלל שמייבן מתייחס ל qualifier כטקסט, יש פה pitfall מסוים:
גירסה:

0.9.9-CR10 

תחשב כמוקדמת יותר מגירסה:

0.9.9-CR2

(בגלל שהתו "1" נמוך בערך ה ASCII שלו מ "2").