Числата на Дънбар и размера на софтуерния екип

team

R. I. M. Dunbar е бил антрополог в University College of London и на базата на изследвания на хора и примати е стигнал до извода, че максималния брой контакти, които човек може да поддържа активно в съзнанието си, е приблизително 150. Т.е. всяка една група може да бъде витална и да оцелее, ако има по-малко от 150 члена. Историята показва, че по-големите групи започват да се делят на по-малки щом броят на членовете им започне да надвишава това число. Оттук числото 150 започва да се нарича “числото на Дънбар”.

Christopher Allen разказва много обширно в своя блог за теорията на Дънбар и всички последвали изследвания след това. Той отива доста по-далеч в своите разсъждения, разглеждайки ефективността на софтуерните екипи и се опитва и там да намери някаква закономерност между броя на техните членове и ефективността на комуникацията и производителността.

Моят опит показва, че най-малкият размер, при който групата е жизнена, е някъде между 5 и 9 човека.

Ако погледнем по-малките групи, можем да забележим, че група от двама може да бъде изключително креативна (попитайте който и да е родител), но често страда от недостиг на ресурси и поради това налага много голяма отдаденост и от двете страни. Естествено оттук трудностите на едно бизнес партньорство от двама души често да бъдат сравнявани с тези на един брак. Група от трима често е нестабилна, тъй като единият човек се чувства изолиран от другите двама или пък единия контролира другите двама накланяйки везните в полза на единия или другия партньор при вземането на решения. Група от 4-ма пък често се разделя на две двойки.

По мое мнение, едва при 5-ма члена започва усещането за “екип”. При група от 5 до 8 човека можете да имате събрание, на което всеки да може да се изкаже за работата на цялата група и всеки да се чувства упълномощен. Но при групи от 9 до 12 човека усещането започва да се разпада – вниманието, което всеки един член получава, вече не е достатъчно и срещите стават все по-шумни, по-скучни или по-дълги.

Същият принцип важи и в бизнеса. Падът, който настъпва при екипи над 12 човека налага създаването на специализирани отдели, които да се поемат от делегирани мениджъри. Проблемът е, че групата все още е малка и съответния мениджър става тежък overhead за екипа. Едва при разрастване над 25 човека разделението на отдели започва да става рентабилно, твърди Кристофър. При достигане на членска маса от 80 човека трудностите в комуникацията започват да се увеличават отново, докато при достигане на “числото на Дънбар” – 150 – отношенията между хората стават неуправляеми.

Кристофър Алън предлага и една графика, в която показва зависимостта на чувството за удовлетвореността на групата от броя на нейните членове.

Group satisfaction

Подобни идеи има заложени и в някои от гъвкавите методологии за разработка на софтуер – Scrum препоръчва екипите да бъдат от 5 до 9 човека, за да бъдат най-ефективни, други препоръчват 3 до 7 човека.

Моят професионален опит се простира от екипи от по двама до 30 човека, но аз също споделям мнението, че по-малкият екип е по-ефективен. Тук, обаче, трябва да се отчете, че в съвременния начин на разработка на софтуер има няколко роли, които е добре да се изпълняват от различни хора, тъй като изискват различно мислене и подход към работата – бизнес анализатор, тестер, документатор, проджект мениджър. Дори програмистите вече имат различна специализация – бази от данни, потребителски интерфейс, бизнес логика – така че съществува и минимален размер, под който екипът също не може да бъде ефективен.

Моята оценка е чисто емпирична, но съвпада с мнението на Кристофър Алън, че бройката трябва да е някъде между 5 и 9. При по-големи екипи започват да се сформират по-малки групички и групировки и често се получава нездрава конкуренция помежду им. Ако работата е голяма и налага много хора да се включат в разработването на даден продукт, добра практика е да се създават “feature teams”, т.е. екипи, които се занимават с разработката на отделен модул или feature и които да бъдат отново толкова малки, че да могат да се управляват ефективно. Проджект мениджмънта в този случай се изразява в управлението на няколкото екипа, които разработват отделните компоненти на продукта.

Тук му е мястото да потърся и вашето мнение. Какъв е вашият практически опит – в какви екипи сте работили и какъв смятате, че е оптималния размер за един софтуерен екип? Въпросът, който съм поставил в анкетата е насочен само към вашето виждане за оптималния екип, но ви приканвам и към по-подробни коментари.

Гласувайте за тази статия в Svejo.net: [wp:svejo-net]

Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл.

7 Comments

  • […] Числата на Дънбар: R. I. M. Dunbar е бил антрополог в University College of London и на базата на изследвания на хора и примати е стигнал до извода, че максималния брой контакти, които човек може да поддържа активно в съзнанието си, е приблизително 150. Т.е. всяка една група може да бъде витална и да оцелее, ако има по-малко от 150 члена. Тази микро-статия е съставена от Тодор Христов , публикувана е на 08.04.08 at 21:04 и е записана в категория Работа в екип. Post a comment or leave a trackback: Trackback URL. […]

  • gstoychev says:

    Аз нямам опит като програмист, но мога да споделя известен опит. Моите наблюдения са предимно върху малките екипи. Изключително ефикасни са екипи от по 4 човека, в които няма изявен ръководител, който да наблюдава другите и да дава насоки. Загуба на време!

  • Георги, предполагам имаш предвид екипи, в които няма “назначен” формален лидер. Иначе, изявен лидер винаги има, независимо колко е малък екипа. Дори и да са само двама, винаги единият се стреми да доминира над другия.

    По принцип съм съгласен с теб, че при малките екипи няма нужда от човек, който само да командва – той просто не е ефективен. Но, от друга страна, има и доста големи проекти, при които на един малък екип ще му трябва много време и това предпоставя риска от промяна в обстоятелствата.

    Представи си проект, който е оценен на 10 човеко-години труд. Това означава, че ако имаш 10 човека, те ще свършат работата за 1 година, а твоят екип от 4-ма ще трябва да работи 2,5 години, което е твърде дълъг срок и създава предпоставки за много рискове в това време. Ако имаш екип от 20 човека, работата би могла да бъде свършена за 6 месеца, което е по-добрият вариант. Въпросът е доколко ефективно би могъл да бъде управляван един такъв екип.

  • gstoychev says:

    Аз доста съм оплескал горният си коментар. Работех като админ преди, бяхме трима администратори. Добре, че бяхме много добри приятели и се разбирахме перфектно. Общо взето никой освен нас тримата не беше наясно за какво става въпрос, дори и шефа. Сега се “преквалифицирах” в програмист. Фирмата е малка, а в нея има още по-голямо разбиване на екипи, по отделни задачки. Чувствам липсата на човек, който да ни води, особенно групата на начинаещите, в която членувам аз. Та все пак си е хубаво да има един изявен лидер, а конкуренцията само ще покачи качеството.

  • […] връзка с темата за размера на екипа, попаднах на един интересен пост в PM Hut, в който авторът […]

  • […] рискувате с неговата продуктивност и ефективност. Майк Рам, добре е описал колко е максималният размер на… Основните роли в даден екип и на които трябва да […]

  • […] постоя достатъчно дълго време, анкетата за оптималния размер на екипа успя да събере доста гласове (цели 96) и придоби някаква […]

Leave a Reply

Your email address will not be published. Required fields are marked *