Привіт, друзі.
У цій статті ми розберемо розподіл відповідальності у великих командах. Уявіть собі ситуацію, що ви керівник, в підпорядкуванні якого знаходиться від двох до N потоків розробки, але вся ця розробка - один великий додаток або одна велика система, а кожен потік займається своїм модулем або своєю частиною модуля. Важливо, щоб потоки розробки майже не перетиналися за функціоналом, хоча використовувати код сусідів вони цілком можуть.
Отже, наше завдання створити таку організаційну структуру, при якій у вас, як у керівника, буде максимальна ймовірність успіху. Очевидно, що успіх проекту залежить далеко не тільки від організаційної структури. Водночас правильна org. structure - одна зі складових цього успіху.
Перш ніж ми з вами зануримося в «хто, кому, що і коли» повинен надавати, звітувати і як будуть організовані комунікаційні потоки, розглянемо «класику жанру» - дуже частий розподіл і призначення зон відповідальності, що зустрічається у великій кількості проектів. Виглядає воно зазвичай як на малюнку нижче (Java і Oracle взяті для прикладу, замість них можуть бути абсолютно будь-які інші технології):
Назви посад можуть, звичайно, відрізнятися.
Іноді зустрічаються дуже своєрідні комбінації, начебто такий:
Упевнений, багато хто з вас стикалися з такими структурами, а, можливо, ви прямо зараз працюєте в одній з подібних. Чи все в них добре? Чи виконують вони свою функцію і чи допомагають нам, як керівникам, швидше, ефективніше, з мінімально можливими витратами ресурсів приходити до успіху проекту? Якщо ви ще не керівник, але плануєте ним стати, вам напевно теж цікаво, чому такі структури неефективні і де саме помилка.
Розгляньмо приклади вище.
Яка мета у керівника проектів, програм, департаменту? Крім заробляння грошей (залежить від рівня посади) мета тільки одна - зробити продукт вчасно, в рамках виділеного бюджету і з узгодженим обсягом і рівнем функціоналу та якості.
Тепер подивіться на діаграми вище. Чи дозволять вони зробити, скажімо, реліз, вчасно і з потрібним обсягом функціоналу, та ще й за умовленого рівня якості? Сильно сумніваюся. Чому у мене є сумніви? Причин кілька.
В першу чергу сумніви викликає розмита зона відповідальності. Ось скажіть, хто на діаграмах вище відповідає за терміни, scope і якості релізу/проекту/продукту? У підсумку, за все-все відповідає той, хто на самому верху. І це вірно. А якщо нижче? Чи відповідає Team Lead за реліз? А хоча б за один ticket в JIRA (або в будь-якій іншій системі трекінгу завдань)? Дивлячись на ці дві схеми вище - ні, безумовно не відповідає.
Другий момент в плані сумнівів - це перекидання м'яча між тім-лідами. Наприклад, аналітики завершили вимоги і передали їх у розробку (Analyst Lead - > Dev Lead). У розробників виникли уточнюючі питання і вони повернули вимоги аналітикам на доопрацювання (Dev Lead - > Analyst Lead). Ті допрацювали і знову передали розробникам (Analyst Lead - > Dev Lead). І знову виникли питання (Dev Lead - > Analyst Lead). Так може довго тривати. Але припустимо, через якийсь час розробка таки почалася (я навмисно спрощую схему, виключивши перекидання м'яча між різними підрозділами розробників, таких як у нас на схемі: Java Lead <-> Oracle Lead). Паралельно з початком розробки тестувальники взялися писати тест-кейси. У момент закінчення розробки відбувається передача коду в тестування (Dev Lead - > QA Lead). Виявляються баги (QA Lead - > Dev Lead). Баги чиняться і код знову передається тестувальникам (Dev Lead - > QA Lead). І так по колу.
Якщо в якийсь момент цього нескінченного кола керівнику захочеться дізнатися статус релізу, скажімо, відсоток готовності, то виявиться, що реліз (наш код) готовий на 90%. А на питання, чому ж терміни ось-ось будуть зірвані, піде закономірна відсутність відповіді, адже ніхто не винен. Тестувальники дійсно чесно тестують. А розробники дійсно чесно виправляють всі знайдені баги. Всі дійсно хочуть випустити в життя хороший продукт. Але м'яч постійно перекидається між розробниками і тестувальниками, і кінця цьому не видно. Зовсім така ж ситуація буде між будь-якими іншими підрозділами (аналітики - розробники, розробники - розробники).
А головне - ніхто ні за що не відповідає крім найвищого керівника, який виступає арбітром або координатором між однією групою та іншою. А арбітром він виступати не може з дуже простої причини - неможливо бути в курсі такої кількості потоків розробки і завдань. Якби було можна - структура була б зовсім іншою і тім-ліди були б просто не потрібні - залишився б один найголовніший менеджер і звичайні аналітики + розробники + тестувальники. Але життя говорить нам, що так ще гірше. А значить проблему треба вирішувати. Ключова проблема знаходиться в зонах відповідальності. І саме це ми і обговоримо далі.
Отже, нам необхідно зробити так, щоб Team Lead став дійсно лідером команди (адже саме так перекладається назва цієї посади). Адже в прикладах вище він був ким завгодно, але не тим, ким повинен бути. Він був Development Lead'ом, QA Lead'ом, Analyst Lead'ом, Java Lead'ом і т. п. І відповідав не за повний життєвий цикл завдання від розробки специфікації до неї, через розробку, до етапу здачі після успішного тестування з багфіксингом, а тільки за якийсь з шматочків всього цього життєвого Lifцикла SLLiX LLaX SLc Наше ж завдання, щоб Team Lead відповідав за весь SDLC за завданням - тільки тоді у нього буде можливість забезпечити поставку цього завдання вчасно, з потрібним обсягом функціоналу і з потрібним рівнем якості. Вартість на рівні Team Lead'a зазвичай не розглядається, хіба що в якихось умовних одиницях, на кшталт WU (Work Unit = 1 людино-день) або якихось подібних одиницях.
Не забуваємо, що для того, щоб людина могла за щось відповідати у неї повинна бути одна важлива складова - повноваження. Тобто. відповідальність і повноваження - дві невіддільних один від одного компоненти. Якщо у вас є повноваження, але немає відповідальності - біда для проекту і ми всі бачимо на прикладі багатьох країн, до чого це веде і чим закінчується. Якщо у вас є відповідальність, але немає повноважень - ще більша біда, але тільки вже для вас, тому що ви є всього лише цапом-відбувайлом, на якого звалять провал. А провал точно буде, адже ви не можете ні на що вплинути. Варіант, коли у вас немає ні повноважень, ні відповідальності, я навіть не розглядаю, бо в цьому випадку ви взагалі не Lead. І тільки у випадку, коли у вас є і повноваження і відповідальність, ви можете впливати на ситуацію і нести за це відповідальність, так само як отримувати нагороди за успіх.
Нижче знаходиться схема, що ілюструє взаємовідношення Повноваження-Відповідальність:
Давайте визначимося, які ж обов'язки можуть бути (бувають) у Team Lead'a. Ось вони:
1. Відповідає за JIRA tickets
2. Є власником ресурсів (його підлеглі)
3. Має якийсь список обов'язків в рамках конкретної команди/тікету/релізу (припустимо, reporting робиться якимось спеціальним чином)
4. Відповідає за якість
5. Власник знань
6. Має якісь обов'язки в рамках компетенції (скажімо, є Senior розробником на Oracle і повинен частину свого часу присвячувати розробці)
Ці 6 пунктів дуже зручно діляться на дві великі секції:
Секція завдань
1. Відповідає за JIRA tickets
2. Є власником ресурсів (його підлеглі)
3. Має якийсь список обов'язків в рамках конкретної команди/тікету/релізу (припустимо, reporting робиться якимось спеціальним чином)
Секція якості та знань
1. Відповідає за якість
2. Власник знань
3. Має якісь обов'язки в рамках компетенції (скажімо, є Senior розробником на Oracle і повинен частину свого часу присвячувати розробці)
Секцію завдань має сенс покласти на Dev Lead'a. А для секції якості і знань треба придумати новий термін. І такий термін є - Competence Lead (лідер компетенцій). Таким чином ми отримуємо не перетинаються зони відповідальності, зосереджені на чітких, вимірюваних і предметних речах.
Всі обов'язки із «зони завдань» дозволяють завданням бути зробленими в строк, забезпечують завдання потрібними ресурсами і наділяють власника цієї секції необхідними повноваженнями для реалізації цілей. Завдання з «секції якості» забезпечують якісний моніторинг навичок і розвиток співробітників, ніяк не впливаючи на реалізацію конкретних завдань. Разом же вони дають той виграш і успішність, який так необхідний нам в управлінні проектами.
Навіщо розділяти ці 6 обов'язків на дві групи і навіщо доручати кожну з груп різним людям? Якщо ви займаєте роль Team Lead (або аналогічну) в даний момент або займали її в минулому, то ви знаєте/розумієте/помітили, що кожна з наших двох груп має абсолютно різну спрямованість. Отже, таким лідам необхідно володіти різними якостями, щоб успішно виконувати обидві ці групи обов'язків. Таке поєднання якостей не завжди відразу зустрічається в одній людині, особливо якщо вона недавно стала Team Lead'ом (TL). Так, всі необхідні навички можна і потрібно розвивати, просто на це потрібен час. Найчастіше, на практиці, в реальних проектах, можна зустріти досить багато людей, яким цікава тільки та чи інша група обов'язків, але не обидві групи разом. Отже, чисто статистично, вам, як керівнику, може виявитися помітно вигідніше, швидше і простіше розділити ці обов'язки саме на такі групи і призначити різних відповідальних, причому саме тих, хто найбільше підходить під виконання першої або другої груп обов'язків.
Як це може виглядати на організаційній діаграмі:
Ви можете бачити, що на діаграмі-3 група QA-фахівців обведена пунктирною лінією і всередині цієї групи є людина з позицією «Competence Lead QA». Зверніть увагу, що до QA групи цього Competence Lead'a входять всі наявні в проекті тестувальники. Так само можна подумки обвести аналітиків, джавістів, ораклистів і всіх, хто у вас є в проекті. Якщо проект великої і групи виходять занадто великі, розбийте їх на кілька, керуючись правилом 7 + -2 (від 5 до 9 осіб на групу). Таким чином ви повністю закриваєте питання компетенцій, розвитку людей, перевірок якості коду, коучингу, навчання, крос-рев'ю, обміну знаннями, бекапування людей і багато інших робочих питань, на які часто не вистачає часу в бойових проектах.
Як може виглядати список обов'язків Team Lead'a (TL) і Competence Lead'a (CL).
Відповідальність TL:
1. Delivery конкретних JIRA-тікетів
2. Гілки відповідних релізів
3. * Подача відпусток
4. * Подача овертаймів
5. Інформація про хворобу або запізнення підлеглого
6. Проведення стендапів
7. * * L0, L1 оцінювання тікетів
8. Розподіл завдань у команді:
- Балансування навантаження ресурсів
- Розподіл відповідальних за завдання
Примітки:
* У пунктах 3, 4 є на увазі саме подача, а не «аппрув»
* * Пункт 7 - з обов'язковою участю CL (як мінімум для великих і середніх тікетів)
Відповідальність CL:
1. Відповідальність за технічну та якісну сторону завдань:
- Технології, які використовуються
- Використання стандартів
- Архітектурні питання
- Підходи, концепти тестування. Тест плани. Рев'ю тест кейсів
- Якість специфікацій. Рев'ю специфікацій
- Відповідність рішень вимогам і специфікаціям
- Якість коду. Код рев'ю
2. Проактивна позиція:
- Коучинг інтернів, нью-камерів (і не тільки)
- Пропозиція технічних поліпшень
Відповідні CL повинні так само брати участь у питаннях:
1. Зсув термінів
2. Брейкдаун і його зміна в сфері розробки, тестування,...
3. Плани розвитку людей, навчання, тренінги (разом з TL і PPM)
Найближчі кроки, які можна зробити:
Як тільки ви оновите свою організаційну структуру проекту, виділіть Team Lead'ів і Competence Lead'ів, донесете і погодите з ними їх майбутні обов'язки, наділіть їх відповідними повноваженнями, озвучите команді нову структуру і нові правила гри, з цього моменту ваше життя як керівника стане набагато простіше і легше. Звичайно, ви зустрінете ще багато різних інших складнощів і підводних каменів (ніхто не обіцяв, що буде легко і просто), але як мінімум питання відповідальності у вас будуть чітко вирішені.
Поділився цією статтею з друзями.
Спасибі і успіхів вам!
