Чи потрібна команда розробників менеджера?

Фон:

Наразі я є частиною команди з чотирьох: 1 менеджер, 1 старший розробник та 2 розробники. Ми пропонуємо різноманітні внутрішні системи / проекти (наприклад, 6-8 тижнів) для організації близько 3500 співробітників, а також всі необхідні технічне обслуговування та підтримка систем, які були створені раніше. Нас не вистачає для того, щоб виконати всю роботу, яка потенційно йде на наш шлях - ми не маєте достатнього рівня. Керівництво це визнає, але обмеження в бюджеті обмежують нашу здатність набирати в команду додаткових членів (навіть якщо ми повертаємо зарплату заощадженнями).

Зміна

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

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

Я думаю, остаточне питання:

Чи можливо запустити команду розробників без менеджера? У вас був досвід цього? І які речі можуть піти не так / можуть бути корисними для нас?

В ідеалі я хотів би "побачити світло" та переваги, як робити це таким чином, або придумати деякі моменти для аргументу проти цього.

Чим більше ризиків, тим більше вам потрібно «повітряне покриття». Це те, що насправді повинен надати менеджер. Поки команда виконує роботу, керівник повинен переконатися, що немає нічого, що не дозволить команді досягти командних цілей. Будь то налаштування розкладу, втручання між командою та персоналом з продажу, або просто переконання, що команда сплачена вчасно та що кавоварка залишається в робочому стані. Справді чудовий менеджер дозволяє команді функціонувати майже так, як ніби менеджера там немає.

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

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

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

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

Пропоноване читання: Рік без штанів . Навіть великий проект програмного забезпечення (WordPress) може обійтися без безпосередніх менеджерів, але є деякі завдання (ніхто не хоче робити / дуже важко) або вимагати інтеграції великої кількості розробників для одного завдання, може бути дуже важким без деяких центральне управління.

Проста відповідь на ваше запитання - так, як вказали інші.

Більш повна, але більш складна відповідь на ваше запитання:

"Керівництво визнає це, але обмеження бюджету обмежують нашу здатність набирати в команду додаткових членів"

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

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

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

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

Я погоджуюсь з відповідями вище, але тут важливий розгляд.

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

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

Con's - Можливо також, що ніхто з вас не бажає бути менеджером. У цьому немає нічого поганого. Багато розробників вважають за краще насолоджуватися клавіатурою та іншими розробниками, ніж "витрачати час" на звіти, діаграми та зустрічі. Повірте, п'ять хвилин з кричущим начальником кожного ранку надзвичайно демотивує! :)

Отже, я б переказав ваше запитання приблизно так:
чи можна запустити команду розробників без завзятого менеджера? - Так .
Чи готова ваша команда до цієї зміни? - Не можу сказати.
Спробуй це. Це просто варто спробувати.

Зараз я працюю над невеликою командою без менеджера. Невелика компанія. Це добре працює.

Ваш пробіг може відрізнятися.

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

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

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

Сказавши, що завжди допомагає хтось із старших, хто може додати цінність. Навіть генеральний директор звітує перед командою менеджерів (рада директорів).

Мої 2 копійки ...

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

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

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

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

коротка відповідь: так, це може.

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

Можливо, вам потрібно об'єднати свою команду розробників з іншою, чи є у вас тестова команда> чи було б краще використовувати одного і того ж менеджера для обох, зберігаючи команду розробників напівавтономною?

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

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

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

Менеджер, як правило, є відсутнім зв’язком між організацією та вашою командою розробників.

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

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

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

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

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

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

Джерело: особистий досвід роботи з груповими проектами та керованими та некерованими командами.

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

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

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

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

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

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

Я працюю в компанії, де ми застосовуємо спритні практики, зокрема Scrum. Це чудово працює у всіх напрямках: команди розвитку та керівництво виконавчої влади задоволені. Вони отримують те, що хочуть.

1. Усі інженери звітуються з інженером-менеджером. Менеджер з питань інженерії - надзвичайно технічна та функціональна роль, при цьому роль вимагає більше бізнесу для підрозділу. Ця роль еквівалентна власнику продукту.
2. Керівник проекту - це окрема роль, схожий на майстра розробки, і зазвичай є підрядником на визначений час (від 12 місяців до 18 місяців, без продовження контракту)
3. Керівник проекту - майстер scrum - повністю відповідає за нефункціональну та неінженерну діяльність

Це спрацювало чудово, оскільки команда розробників зосереджується на інженерних аспектах, а бізнес-аналітики / власники продуктів зосереджуються на бізнес-аспектах. Керівник проекту відповідає за відстеження завдань, звітування та інші типові обов'язки Scrum Master.

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

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

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

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