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

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 – отношенията между хората стават неуправляеми.

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

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

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

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

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

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

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