כיצד לבנות צוות פיתוח תוכנה

Kate Goldberg

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

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

כמה גדול חייב להיות הצוות שלך?

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

נכון, אך עד רמה מסוימת.

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

אך למה זה קורה?

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

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

לדוגמה: סטארט-אפ של 7 אנשים חייב לשמור על 21 קשרים, בעוד 12 אנשים מתמודדים עם 66 קשרים.

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

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

אז מה הגודל האופטימלי?

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

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

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

לסיכום

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

הענקת תפקידים ואחריות

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

באופן קלאסי, צוות פיתוח תוכנה מורכב:

• מעצב UI/UX

• 1-2 מהנדסי ממשק

• 1-2 מהנדסי צד השרת

• איש 1 בהבטחת איכות

• איש 1 בתור מנהל פרויקטים.

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

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

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

תפקידים, תפקידים!

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

ראש צוות

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

ארכיטקט ראשי

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

בעל המוצר

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

תשומת לב לאקלים הפנימי

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

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

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

***

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