5 נקודות קריטיות בבניית מחלקת פיתוח מנצחת

1. הטמעת מתודולוגיות בפיתוח

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

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

מתודולוגיות במחלקת הפיתוח מחולקות למספר נושאים עיקריים:

1. Application Life Management) ALM): ניהול מחזור החיים של המוצר/התוכנה מיומה הראשון ועד למסירה ללקוח והמשך התמיכה בו. בנוסף אני ממליץ להיעזר בכלי פיתוח ובדיקות מובילים כגון TFS של מיקרוסופט או Mercurial על מנת להטמיע ולתחזק לאורך זמן את המוצר בין הצוותים השונים.
2. הטמעת סטנדרטים של תיעוד ומסמכים כגון: דרישות מוצר חדש או גרסה (ממנהל המוצר בד"כ), מסמכי Design טכניים ממחלקת הפיתוח, Unit Tests, תיעוד בקוד ומעבר ל QA.
3. הטמעת ארכיטקטורה והנדסת תוכנה: רצוי מאד לבסס קונספט של ארכיטקטורה זהה. לדוגמא בחברת מוצר המפתחת ליין של מוצרים מומלץ מאד לבסס מכנה משותף ברמת ארכיטקטורה על-מנת להביא לפיתוח יעיל ומהיר יותר, פחות באגים ועוד. ניידות בין מפתחים תוביל למינימום קשיי הסתגלות ברמת הפיתוח.
4. תוכניות עבודה: MS-Project או כל כלי אחר לניהול מבוזר של משימות בנוסף להטמעת מתודולוגיות פיתוח מתקדמות ודינמיות כגון – Agile / SCRUM יוביל להשגת המטרה שהיא דלוור של הפרויקט באיכות גבוהה ובזמן.

2. גיוס עובדים

חוזקה של כל קבוצה באשר היא, כחוזק החוליה החלשה ביותר שלה.

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

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

1. תרבות ארגונית וערכים, לדוגמא – אמינות ונאמנות לחברה, תרבות דיון ומתן עזרה לעמיתיו, האם הוא מתאים לאופי האירגון? ואף יותר מזה, האם מתאים לאופי צוות הפיתוח?
2. האם הוא מתאים לנו ברמה המקצועית? C++ או .NET סביבת WEB?
3. מהם הרגלי העבודה שלו? האם יש לו יכולות של ארכיטקט? מהם הרגלי התיעוד שלו?
4. האם הוא מוביל או דווקא מובל?
5. מהם שאיפותיו לשנה-שנתיים הקרובות? האם הוא בה לריצה ארוכה או לאיזה "חפוז" ולהמשיך למקום הבא.
6. אם מדובר בגיוס של מפתח בתחילת דרכו, תמיד כדאי לבחון אותו מקצועית ולהבין מהן כוונותיו.
7. כמה זמן צריך להשקיע בהכשרה עד שנקבל תפוקה מלאה.
8. מהי דרישת השכר שלו, והאם היא עומדת בתקציב שהוקצע למשרה זו.
9. מהו הערך המוסף שאנו מקבלים מגיוס של עובד זה.

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

3. חלוקה לצוותים הטרוגניים

 

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

 

מניסיוני צוות מצליח ופורה זהו צוות שמורכב ממפתחים ותיקים וממפתחים צעירים עם יכולות שונות מכמה טעמים עיקריים:

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

4. האצלת סמכויות

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

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

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

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

5. הכשרת עובדים

 

נושא זה לעיתים רבות זוכה במירכאות כפולות להזנחה בלא מעט חברות.

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

אני ממליץ על השלבים הבאים:

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

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

 

בנוסף כדאי מאד למסד הכשרות לכלל עובדי הפיתוח בשגרה.

 

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

 

1. הרצאות פנים ארגוניות ע"י אחד מחברי הצוות בעל ממוחיות מיוחדת לדוגמא DBA, מפתח RT/EMBEDED.
2. הרצאה פנים ארגונית ממחלקה אחרת על נושאים שלא בהכרח קשורים לפיתוח, כגון משאבי אנוש, שיווק, מכירות. הרצאות אילו תורמות מאד גם להכרות מעמיקה יותר של שאר המחלקות בחברה וגם הבנה של המשמעות וההשפעה של התוצרים של מחלקת הפיתוח על המחלקות האחרות ולקוחתהים.
3. זימון מרצים חיצוניים להרצאות ספציפיות בטכנולוגיות חדשות.
4. וכמובן תמיד אפשר לשלוח עובד אחד או יותר לקורס או כנס בהתאם לתקציב וכצ'ופר.

 

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

מרגישים שאתם צריכים עוד טיפים? עשיתם את זה ורוצים לשתף אותנו בהצלחה? אתם מוזמנים להשאיר הערות, התגובה מובטחת!

 

איציק צנדוק

itzik.zandok@gmail.com

http://www.linkedin.com/in/itzikzandok