Як сформувати команду розвитку

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

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

• Запропонуйте молодшим розробникам звітувати старшим. Це скорочує час, витрачений на розробку кращими фахівцями.
• Розділіть команду за програмним продуктом, наприклад, розробники 1-6 працюють над інтранет та 7-11 працюють на зовнішніх сайтах, при цьому кожен розділ має нове керівництво команди (можливо, новий опис роботи з більшою відповідальністю за управління / наставництво / коучинг, ніж нинішні старші розробники ). Це додає штучні силоси, і, можливо, це ускладнить роботу розробника інтрамережі на зовнішньому веб-сайті, якщо я хочу.
• Тримайте структуру рівною та додайте управлінську підтримку у формі керівників проектів / адміністраторів команд лише для того, щоб зняти тиск. Це не вирішує проблему, оскільки команда не може постійно зростати таким чином.

Чи є стандартний спосіб вирішення цієї проблеми, який мені не вистачає?

Якщо ні, то як інші з вас вирішили цю проблему?

Кілька швидких думок:

• Підгрупи - хороша ідея: 11 прямих звітів без будь-якої структури занадто великі для працездатної команди (у вас не буде достатньо часу для прямого тренування, а зустрічі команди з цим багатьма людьми, як правило, непродуктивні).
• Подумайте про відмежування операцій від розробки - це дещо інший набір навичок і переривання оперативних питань цілий день може серйозно зашкодити продуктивності розвитку проектів.
• Як результат перших двох пунктів, я думаю, у вас повинно бути, можливо, 3 підтеми - Інтранет, Зовнішні сайти та Операції. Хлопці з операцій вирішуватимуть щоденні проблеми / виправлення технічного обслуговування тощо, в той час як дві команди розробників зосереджуються на наданні нових проектів / цінності для бізнесу.
• Регулярно обмінюйте людей між командами. Це може бути як випадковим (наприклад, люди переглядають код в іншому підтемі), так і для проекту або на постійній основі. Але переконайтеся, що розуміється, що команди команди змінюватимуться, коли є потреба в бізнесі - ніхто не володіє конкретною роллю назавжди.
• Не додайте більше менеджерів / адміністраторів - це надійний спосіб знизити загальну ефективність / продуктивність ваших команд. Запропонуйте найдосвідченішій особі у кожному підрозділі грати роль команди / тренера команди. Переконайтесь, що вони бачать тут свою роль як коучинг і змушення успіху всієї команди, і переконайтесь, що вони готові вести себе таким чином, а не діяти як «керівник завдань».
• Ваша роль повинна бути зосереджена на управлінні зовнішніми зацікавленими сторонами, визначення пріоритетності ресурсів / завдань у групі та виступ «головного тренера». Вам потрібно буде вирішувати епізодичні проблеми з підгрупами, але в цілому ви повинні заохочувати їх самостійно вирішувати проблеми, не звертаючись до вас.
• Якщо ви самі високотехнологічні, ви також можете грати роль архітектора / гарантії дизайну. Якщо ні, знайдіть когось, хто зможе, в колективі чи деінде .....

Крім того, завжди варто піти і (повторно) прочитати маніфест "Agile" , і особливо дванадцять принципів .

Ця структура в основному буде depend on project specifications

В ідеалі в команді повинно бути 3 юніори на старшого розробника. Отже, є 2-3 старших розробника на навчання.

Таким чином, лише технічні лідери будуть звітувати прем'єр-міністру про стан виконання проекту. Описана структура все ще передбачає, що для нетехнічних питань (відпустка, вихідний час, конфлікти тощо) кожен може мати доступ до ПМ.

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

Менеджер з розробки програмного забезпечення / Старший розробник / Вихователь, якому всі інші повідомили безпосередньо.

• Керівник проекту, який дотримувався графіків, полегшував вимоги та приймав переговори, а також спілкувався. Кожна пунктирна лінія також повідомляла цю особу. Особа, яка займається документацією (яка періодично також була прем'єр-міністром, але лише тоді, коли експертиза дозволила).
• Суміш 1-3 розробників або старших розробників, залежно від потреб проекту.
• Молодший розробник при наявності.
• Хтось призначений з пулу QA.
• Людина з інфраструктури (роль, яку часто виконує менеджер, оскільки він також мав солідну компетенцію щодо СА).

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

Розглянемо наступний зразок організації функціонального персоналу . Це може говорити про ваш другий варіант розбиття команди на програмний продукт.

Щоб процитувати статтю у вашому контексті:

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

Фактична структура управління / управління персоналом не має жодного значення.

Чи є стандартний спосіб вирішення цієї проблеми, який мені не вистачає?

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

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

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

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

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

Для вашого конкретного сценарію я рекомендую створити 2-3 команди та мати технічні рекомендації щодо технічних аспектів, а ви зосередитесь на адміністративних. Так, це скорочує час з коду, який насправді пише код, але вони повинні (якщо вони роблять хорошу роботу) відшкодувати цей час, зробивши молодших розробників більш ефективними / продуктивними. Це надає їм більшої мотивації та почуття досягнень із фактичним просуванням. І практично практично, це легше продати керівництву, ніж відкривати нову позицію.