Чи потрібна зріла спритна команда будь-якого управління?

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

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

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

Ви робите тут ряд помилок.

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

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

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

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

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

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

Мине довгий час, перш ніж ви зможете назвати себе повністю зрілою командою Agile та самостійно керувати. Більшість команд ніколи туди не потрапляє.

На моє розуміння, зріла команда повністю самоуправляється.

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

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

Ця людина - менеджер.

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

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

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

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

Ого. Ви останнім часом не працювали з добрими менеджерами, чи не так? (Ми всі працювали з поганими).

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

(Особливо винні в цьому ділові люди - чи отримували ви колись технічні характеристики низької якості І встановлений термін?)

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

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

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

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

Удачі в цьому.

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

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

Частина проблеми полягає в тому, що "Scrum Master" - це, можливо, найменш точно названа роль у всій історії. "Scrum Filitator" був би дещо точнішим, але, як хтось інший зазначав раніше, завдання SM не в тому, щоб керувати командою, а створювати проблеми, щоб команда (самоуправління) могла продовжувати працювати. Так, майстер scrum також несе відповідальність за те, щоби scrum трапився: завдання оновлюються з рештою годин, зберігаються в режимі очікування та додають значення, оновлюються спади, відстежується швидкість і так далі, але це все одно тренування і полегшення ролі, а не керуючої ролі.

Інша частина проблеми полягає в тому, що люди в кутових кабінетах хочуть знати відповіді на запитання типу "коли я можу поставити програмне забезпечення?" і "які функції він буде містити?" і вони звикли задавати «керівнику проекту» ці запитання та отримувати відповіді, підтримані безліччю вражаючих на вигляд діаграм Ганта та мало згадок про незручні речі, такі як конус невизначеності.

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

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

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

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

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

Я повинен створити систему або бути поневоленим іншою людиною; Я не буду міркувати і порівнювати: мій бізнес - це створити.- Вілліям Блейк

EDIT у відповідь на коментар glenatron:
Це більше, ніж просто команда розробників. У нас є генеральний директор, портьє, який відповідає на телефон, та ІТ-хлопець. Ми спілкуємося з клієнтами безпосередньо електронною поштою, телефоном чи зустрічами. Основним нашим бізнесом є створення власного продукту та його продаж, а не збивання контрактів. Але є і контракти.

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

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

Ви не можете керувати своїм способом розваги. Ви не можете керувати своїм оригінальним твором мистецтва.