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

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

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

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

כמובן שבחיים שום דבר אינו שחור או לבן וברוב האירגונים אם לא בכולם נמצא איזשהו שילוב של המבנים.

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

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

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

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

• מנהל הקבוצה/ראש צוות
• מהנדס ובכיר
• מהנדסים ותיקים
• מהנדסים חדשים

וכשאני אומר “מהנדסים” אני מתכוון ל”אנשי צוות” שיכולים להיות תוכניתנים/בודקים/מהנדסים וכו.

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

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

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

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

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

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

דרך צלחה.