Чи ефективно "Хірургічна команда" Фреда Брукса справляється з фактором автобуса?

Моя команда з 4 досвідчених розробників працює над великим модульним додатком для Windows (приблизно 200 KLoC). Я зосередився на базовій кодовій базі з початку проекту (3 роки тому) і поступово перейшов на напіввідповідальну позицію розробника, хоча я не менеджер команди.

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

За три дні, відколи ми розпочали роботу, я помітив дві речі:

1. Інші недосвідчені члени команди виконали близько 1 або менше завдань кожен.

2. Закон Брука в дії: я витрачав близько половини свого часу на надання допомоги (намагаючись навчити їх використовувати компоненти). В результаті я закінчив лише 2 завдання замість очікуваних 5 чи 6.

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

1. Обмежте коефіцієнт вантажівки / автобуса - набудьте інших розробників на ці навички, так що в майбутньому будь-яка робота може бути надана будь-кому, не лише мені.
2. Щоб усунути «вузьке місце» (мені) і швидше виконати роботу.

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

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

У Mythical-Man-Month, Brooks 'пропонує « Хірургічну команду », де кожна команда складається з ведучого + підвідділу (керівника та мене) та деяких другорядних ролей. Я відчуваю, що ми, природно, потрапляємо в цю організацію, але мій менеджер працює проти цього. Я відчуваю, що фактор шини вже забезпечений (менеджер добре розбирається в основному коді), і вузьке місце насправді не існує (за рахунок участі більшої кількості розробників не буде працювати швидше). Я думаю, що в цьому плані хірургічний колектив є доброю справою.

Це мої почуття, але я не досвідчений менеджер, і нам не доводилося стикатися з фактором автобуса (стукати по дереву). Чи правильно був Брукс? Чи працювали ви в "Хірургічній команді", де вступив фактор автобуса? Чи є кращі методи управління розподілом досвіду?

Подібні запитання:

• Як одночасно збільшити коефіцієнт шини та спеціалізуватися?
• /software/103718/always-keeping-2-people-expert-on-any-one-chunk-of-code

Власне, я б стверджував, що ви дотримуєтесь моделі «хірургічної команди». Пощастило!

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

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

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

Або юніори можуть помилитися. Це ідеальний час для них, оскільки у них хтось дивиться через плече. - сказав Оскар Уайльд

Досвід - це просто ім'я, яким ми даємо свої помилки.

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

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

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

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

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

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

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

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

Якщо ви знімете час доставки з вашого питання, ви швидко почнете цікавитись, чому ви ставите це питання в першу чергу.

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

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

Я раніше був критичним вузьким місцем; і чесно кажучи, це не приємне місце бути. У моєму випадку з ВП ІТ та я поговорили, і ми придумали план постійного виправлення проблеми. Це боляче, але це боляче набагато менше, ніж у мене перевезли вантажівку.

Легко ввійти в розум всього, що потрібно вибити якомога швидше. Хороший менеджер помічає рідкісні можливості, коли невелика затримка (за перехресне навчання / навчання) може потім виплатити значні дивіденди.