Що означає хорошого архітектора / менеджера / головного розробника?

Я є провідним розробником невеликої компанії з програмного забезпечення. За останні два роки моя команда зросла з одного розробника (мене) до групи з дев'яти людей. Більшість з нас є дуже здібними, старшими інженерами (20+ років досвіду створення програмного забезпечення на людину), тому в цілому потрібно дуже мало рук. Ми використовуємо Scrum для управління нашими зусиллями, і ми зазвичай дуже швидко робимо з мінімальними письмовими вимогами.

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

Моя мета - дозволити моїй групі ще більше зростати (тобто збільшувати швидкість Scrum), додаючи більше розробників , тому я не хочу просто стати "архітектурною поліцією", яка нав'язує свою волю команді. Іншими словами, я хочу бути тим, хто допомагає речам працювати краще / плавніше, а не тим, хто уповільнює роботу, додаючи непотрібний шар бюрократії. І все-таки, один з наших головних ризиків полягає в тому, що все вийде з-під контролю, якщо ми додамо більше людей, не маючи достатньо структури, щоб утримати нас на одній сторінці.

Який найкращий спосіб досягти своєї мети?

Якби ви були в такій команді, що б ви хотіли, щоб ваш начальник займався його часом?

1. Усуньте перешкоди для прогресу.
2. Опосередковуйте суперечки між членами команди.
3. Спілкуйтеся з діловими людьми, тому нам не доведеться.
4. Повідомте нас про цей бізнес / проект проекту вищого рівня, щоб ми не відчували себе ізольованими.
5. Будьте чесними, особливо якщо / коли поганий яблук потрапить до команди.
6. Будьте адвокатом команди в інших відділах.
7. Будьте єдиним голосом відштовхування від необґрунтованих запитів бізнесу.
8. Сприяти спілкуванню в колективі.

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

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

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

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

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

Здійснення переходу до команди "Ведуча"

Як мені досягти успіху як провідний розробник?

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

Я думаю, що це баланс цих рис:

• Технічна майстерність : Ви не хочете, щоб хтось із керівників, який не міг оцінити якість роботи, яку він / вона керує.
• Самостійно керований : вміє визначати цілі та не бути реактивним.
• Знає, як скористатися конфліктом : конфлікт запускає розмови
• Автодидактичні : Не важливо, щоб він / вона знав усе, але вмів вчитися.
• Гарне ставлення та енергія : Ви хочете, щоб хтось мотивував і полегшував роботу кожного, а не діву, яка гавкає на замовлення.
• Досвід з невдачею : можливо, найважливіший. Я бачив дуже молодих лідерів, які можуть не мати проблем зі всіма попередніми, але при перших ознаках невдачі вони заморожуються або уникають відповідальності. Старшість не має нічого спільного з віком, але потрібна кількість правильного досвіду, і невдача, безумовно, є що враховувати.

ОТО, співбесіда є важливою частиною отримання потрібної людини, я б рекомендував вам задати наступні запитання в інтерв'ю:

• "Розкажіть мені про проект, де ви зазнали невдачі, як ви впоралися з ним і чого ви навчилися з нього"
• "Розкажіть мені про час, коли ви порушили правила, щоб зробити справи"
• Застосуйте тест Fizz Buzz з будь-яким легким поворотом, про який ви можете придумати.

Тест FizzBuzz абсолютно необхідний, правильно чи неправильно, це не так важливо, як:

• Час, який йому / їй потрібно відповісти : середній 15 хв, 30 хв прикордонний ок,> 30 хв НЕ ОК
• Якщо він / вона зможе налагодити власний код : У мене колись хлопець з 15-річним досвідом подав заявку на вищу посаду ... йому потрібно було 40 хвилин, щоб зробити тест ... в псевдокоді ... отримав це неправильно і не міг з’ясувати, чому. У мене був ще один випадок, коли інший хлопець витрачав близько 5 хвилин на виправдання себе і не міг прийняти, що він взагалі помиляється.