Як слід розподіляти вміння через команди?

Прочитавши це, Я побачив, що, мабуть, існує велика розбіжність з приводу того, як спритні команди повинні бути структуровані в групі розробників з різними можливостями (так само майже у всіх командах). Чи повинні всі кращі розробники надходити у власні команди та отримувати найвищу пріоритетність роботи? Це в значній мірі забезпечить виконання найважливіших завдань. У той же час, ви залишаєтесь з "менш ніж досконалими" командами в інших місцях, які накопичують технічну заборгованість, навіть якщо це стосується лише завдань із низьким рівнем пріоритетності. З іншого боку, рівномірно розподілені команди можуть мати користь зробити ваші відстаючі розробники трохи кращими, але мають потенціал для демотивації ваших найважчих нападників. Крім того, якщо ви поєднаєте купу хороших моделей дизайну з купою жахливих анти-шаблонів, ви можете дійсно закінчити щось, що може бути також купою анти-візерунків.

Є деякі відомі ризики з A-Teams, але якщо динаміка правильна, то я думаю, що так, я б поставив своїх найсильніших людей на найважливіші проекти, а також молодших розробників (ів) з найбільшим потенціалом. Для проектів з низьким рівнем пріоритетності вам потрібен хороший керівник команди, якщо він взагалі можливий, щоб утримати їх не вдалося далеко від рейок. Технічна заборгованість не відбудеться незалежно від того. Не всі технічні борги рівні; вартість / відповідальність технічної заборгованості пропорційно вартості проекту в першу чергу, тому, хоча ваші проекти з нижчим пріоритетом можуть мати більше бородавок, вартість цих проектів, ймовірно, все ще набагато менша, ніж значні проблеми ваших пріоритетних проектів бути.

Я пам’ятаю, коли я був в університеті, один з наших професорів розповідав нам анекдот про структуру команди (я шукав папір, про яку він зараз говорив, але, здається, не знаю).

В основному, історія пройшла так:

Групу програмістів розділили на групи на основі здібностей, при цьому найгірші x програмісти згруповані разом, наступні x згруповані разом і т.д., а найкращі згруповані разом.

Їм було призначено одне і те ж завдання та встановлено встановлений часовий проміжок, у якому вони повинні виконати його.

Наприкінці часових рамків організатори розглядали рішення поставлених завдань, і вони, на подив, виявили, що найкраще рішення вирішує команда, що складається із пересічних людей. На відміну від цього, команда, що складалася з програмістів A *, зробила одне з найгірших рішень, оскільки вони витратили весь свій час, сперечаючись про те, що було найкращим рішенням .

Якщо вам потрібна команда, яка збирається виконати справи, отримайте купу середніх хлопців і домінуючого хлопця, який може вести, був висновок дослідження (якщо я правильно пам’ятаю), інакше більш домінуючі члени витратять більше часу на боротьбу, ніж отримання речі зроблено!

Переважна більшість недосвідчених розробників може не в змозі самостійно придумати надійні, елегантні конструкції, але вони можуть розпізнати та зрозуміти це, побачивши його. Якщо вони не можуть, то їм, як правило, не вистачає ні здібностей, ні підготовки до наймання в першу чергу.

Є також більш досвідчені розробники, які здатні зрозуміти дуже складні програми програмного забезпечення, але їм не вистачає розсуду, щоб знати, коли щось простіше було б краще.

На мій досвід, у вас зазвичай є постійні проблеми зі змішаними командами, якщо вони містять непідготовлених членів, непотрібних складних членів або обох. В іншому випадку, якщо у вашої команди є проблеми, їх зазвичай можна виправити за допомогою кращого спілкування або призначення відповідних ролей.

Об’єднання кращих людей в одну команду може виглядати як чудове короткотермінове рішення, але це невдача в довгостроковій перспективі і це додаткові витрати. Наприклад, моя компанія вважає за краще, коли люди навчаються у своїх більш кваліфікованих колег, а не платять за навчання. Якщо ви розділите найкращих людей, вони не зможуть передати знання менш кваліфікованим людям. За короткий термін ваші найкращі команди можуть виступити добре, але через відсутність передачі знань кількість кваліфікованих людей не збільшиться. Набагато краще мати меншу кількість команд на початку та підвищити продуктивність у всіх командах, оскільки люди стають більш кваліфікованими.

Крім того, що станеться, якщо кваліфіковані люди вирішать піти? Хто буде приймати їхні проекти?

Ще один момент - команда повинна складатися з людей з різними наборами навичок. У вас завжди будуть легкі завдання (і нудні завдання), які є надто дорогими для виконання самими старшими розробниками.

Ті, хто не вчить, роблять ...

Я думаю, що є більше факторів, які слід враховувати.

Ви отримаєте найбільшу цінність, розповсюдивши ті, які можуть викладати як керівники команди. Вони можуть навчити інших членів колективу та допомогти підвищити якість їх роботи.

Не всі старші програмісти добрі успіхи. Це вміння передавати інформацію - це вміння саме по собі. Цей навик не є чимось, що розвивається через досвід програмування. Вона розвивається через викладання та пояснення.

Призначення команди "А" має два важливі питання. По-перше, це сумісність. Наявність команд, які добре ладять та працюють разом, набагато важливіше, ніж їх "здатність". Тепер це можуть бути два "високих" програмісти, два програмісти "низької" кваліфікації або мікс. Те, що вони можуть добре працювати разом, означає, що вони будуть більш продуктивними.

Друге питання стосується зростання. Двоє "низьких" програмістів не будуть багато чому вчитися, окрім шкідливих звичок. Так само двоє "висококваліфікованих" програмістів не будуть багато вчитися один у одного. Однак змішування рівня "низький" і "високий" допоможе покращити здібності "низького" вміння. Вони також поліпшать здібності "високо" кваліфікованих. Як? Намагаючись навчити предмет, швидко знайдете ваші слабкі місця Я не вважаю вміння "засвоєним", поки ви не зможете навчити його комусь іншому.

З іншого боку монети, я думаю, що є сенс тримати команди, які можуть "йти в ногу" один з одним. Програмісти типу A-Team не хочуть чекати типів B-Team, щоб виконати свої біти. Ваші типи B-Team можуть інтимуватися робочим процесом у стилі A-Team.