Здравствуйте друзья.
В этой статье мы рассмотрим распределение обязанностей в больших командах.
Представьте себе ситуацию, когда вы менеджер, который курирует от двух до N потоков разработки, но вся эта разработка — это одно большое приложение или одна большая система, и каждый поток занимается своим модулем или своей частью модуля.
Важно, что потоки разработки практически не пересекаются по функциональности, хотя вполне могут использовать код своих соседей.
Итак, наша задача — создать такую организационную структуру, при которой вы как руководитель будете иметь максимальную вероятность успеха.
Очевидно, что успех проекта зависит не только от организационной структуры.
В то же время правильная орг.
Структура является одной из составляющих этого успеха.
Прежде чем мы углубимся в вопрос «кто, кому, что и когда» должен предоставлять, отчитываться и как будут организованы коммуникационные потоки, давайте посмотрим на «классику жанра» — весьма распространенное распределение и распределение зон ответственности, встречающееся в большое количество проектов.
Обычно это выглядит так, как на рисунке ниже (в качестве примера взяты Java и Oracle; вместо них могут быть совершенно любые другие технологии): 
Названия должностей, конечно, могут быть разными.
Иногда встречаются весьма своеобразные комбинации, например: 
Я уверен, что многие из вас сталкивались с такими структурами и, возможно, вы сейчас работаете в одной из них.
Все ли у них хорошо? Выполняют ли они свою функцию и помогают нам, как менеджерам, быстрее, эффективнее и с минимально возможными затратами ресурсов добиться успеха проекта? Если вы еще не являетесь лидером, но планируете им стать, вы наверняка тоже задаетесь вопросом, почему такие структуры неэффективны и в чем именно ошибка.
Давайте посмотрим на примеры выше.
Какова цель руководителя проекта, программы или отдела? Помимо зарабатывания денег (в зависимости от уровня должности) цель одна — сделать продукт в срок, в рамках выделенного бюджета и с оговоренным объемом и уровнем функциональности и качества.
Теперь посмотрите на диаграммы выше.
Позволят ли они нам сделать, скажем, релиз в срок и с необходимым объемом функционала, да еще и на оговоренном уровне качества? Я в этом очень сомневаюсь.
Почему у меня есть сомнения? Есть несколько причин.
В первую очередь вызывает сомнения размытость зоны ответственности.
Скажите, кто на диаграммах выше отвечает за сроки, объём и качество релиза/проекта/продукта? В конце концов, за все отвечает тот, кто на самом верху.
И это правда.
А если ниже? Несет ли руководитель группы ответственность за выпуск? И хотя бы на один тикет в JIRA (или в любой другой системе отслеживания ошибок)? Глядя на две диаграммы выше – нет, определенно не ответ. Второй момент сомнений – переброска мяча между лидерами команд. Например, аналитики выполнили требования и передали их в разработку (Analyst Lead -> Dev Lead).
У разработчиков возникли уточняющие вопросы, и они вернули требования на доработку аналитикам (Dev Lead -> Analyst Lead).
Доработали его и снова передали разработчикам (Analyst Lead -> Dev Lead).
И снова возникли вопросы (Dev Lead -> Analyst Lead).
Это может продолжаться долго.
Но допустим, через какое-то время началась разработка (я намеренно упрощаю схему, исключив перебрасывание мяча между разными отделами разработчиков, как, например, на нашей схеме: Java Lead <-> Руководитель Oracle).
Параллельно с началом разработки тестировщики начали писать тест-кейсы.
По окончании разработки код передается на тестирование (Dev Lead -> QA Lead).
Обнаружены ошибки (QA Lead -> Dev Lead).
Исправлены ошибки и код снова передан тестировщикам (Dev Lead -> QA Lead).
И так по кругу.
Если в какой-то момент этого бесконечного круга менеджер захочет узнать статус релиза, скажем, процент готовности, то окажется, что релиз (наш код) готов на 90%.
А на вопрос, почему вот-вот срываются сроки, естественно будет отсутствие ответа, ведь никто не виноват. Тестеры тестируют действительно честно.
И разработчики действительно честно исправляют все найденные ошибки.
Каждый действительно хочет выпустить хороший продукт. Но мяч постоянно перебрасывается между разработчиками и тестировщиками, и конца этому не видно.
Точно такая же ситуация будет и между любыми другими отделами (аналитики-разработчики, разработчики-разработчики).
И самое главное, никто ни за что не отвечает, кроме высшего лидера, который выступает арбитром или координатором между одной группой и другой.
Но он не может выступать в качестве арбитра по очень простой причине - невозможно угнаться за так много тем и задач разработки.
Если бы это было возможно, структура была бы совсем другой и тимлиды были бы просто не нужны — был бы только один главный менеджер и обычные аналитики+разработчики+тестировщики.
Но жизнь подсказывает нам, что это еще хуже.
Это означает, что проблему необходимо решить.
Ключевая проблема заключается в зоны ответственности .
И именно об этом мы и поговорим дальше.
Итак, нам нужно сделать так, чтобы Team Lead действительно стал лидером команды (а именно так и переводится название этой должности).
Ведь в приведенных выше примерах он был кем угодно, но не тем, кем должен быть.
Он был руководителем разработки, руководителем контроля качества, ведущим аналитиком, руководителем Java и т. д. И он не отвечал за полный жизненный цикл задачи от разработки спецификации к ней, через разработку, до стадии поставки после успешного тестирования с помощью исправление ошибок, но только для некоторых частей всего этого SDLC (жизненного цикла разработки программного обеспечения).
Наша задача – Руководитель группы отвечал за весь SDLC. по задаче – только тогда он сможет обеспечить сдачу этой задачи в срок, с необходимым объемом функционала и с необходимым уровнем качества.
Затраты на уровне руководителя группы обычно не учитываются, за исключением, возможно, определенных условных единиц, таких как WU (рабочая единица = 1 человеко-день) или некоторых подобных единиц.
Не будем забывать, что для того, чтобы человек мог за что-то отвечать, у него должна быть одна важная составляющая – авторитет. Те.
Ответственность и полномочия – две неразделимые составляющие.
Если у тебя есть полномочия, но нет ответственности – это катастрофа для проекта, и мы все видим на примере многих стран, чем это ведет и чем заканчивается.
Если у тебя есть ответственность, но нет полномочий, это еще большая проблема, но только для тебя, потому что.
ты просто козел отпущения , на которого будет возложена ответственность за неудачу.
Но неудача обязательно будет, потому что вы ни на что не можете повлиять.
Вариант, когда у тебя нет ни полномочий, ни ответственности, я даже не рассматриваю, потому что в этом случае ты вообще не Лид. И только когда у вас есть и полномочия, и ответственность, вы сможете повлиять на ситуацию и взять на себя ответственность за нее, а также получить вознаграждение за успехи.
Ниже приведена диаграмма, иллюстрирующая соотношение полномочий и ответственности: 
Давайте определимся, какие обязанности может иметь руководитель группы.
Вот они: 1. Ответственный за билеты JIRA 2. Является владельцем ресурсов (его подчиненными) 3. Имеет определенный список обязанностей в рамках конкретной команды/тикета/релиза (например, отчетность ведется определенным особым образом) 4. Ответственность за качество 5. Владелец знаний 6. Имеет определенные обязанности в рамках своей компетенции (например, он является старшим разработчиком Oracle и должен уделять часть своего времени разработке) Эти 6 пунктов очень удобно разделены на два больших раздела: Раздел задач 1. Ответственный за билеты JIRA 2. Является владельцем ресурсов (его подчиненными) 3. Имеет определенный список обязанностей в рамках конкретной команды/тикета/релиза (например, отчетность ведется определенным особым образом) Отдел качества и знаний 1. Ответственность за качество 2. Владелец знаний 3. Имеет определенные обязанности в рамках своей компетенции (например, он является старшим разработчиком Oracle и должен уделять часть своего времени разработке) Имеет смысл поручить раздел задач руководителю разработки.
А для раздела качество и знания нужно придумать новый термин.
И есть такой термин — Competence Lead. Таким образом мы получаем непересекающиеся зоны ответственности, ориентированные на четкие, измеримые и содержательные вещи.
Все обязанности в «области задач» позволяют выполнять задачи вовремя, обеспечивают задачи необходимыми ресурсами и дают владельцу этого раздела необходимые полномочия для достижения целей.
Задачи из «раздела качества» обеспечивают качественный контроль навыков и развития сотрудников, никоим образом не влияя на выполнение конкретных задач.
Вместе они обеспечивают пользу и успех, которые нам так нужны в управлении проектами.
Зачем делить эти 6 обязанностей на две группы и поручать каждую группу разным людям? Если вы в настоящее время занимаете должность руководителя группы (или аналогичную) или занимали ее в прошлом, то вы знаете/понимаете/заметили, что каждая из двух наших команд имеет совершенно разную направленность.
И, следовательно, такие лиды должны обладать разными качествами, чтобы успешно выполнять обе эти группы обязанностей.
Такое сочетание качеств не всегда сразу обнаруживается в одном человеке, особенно если он недавно стал Team Lead (TL).
Да, все необходимые навыки можно и нужно развивать, просто на это нужно время.
Зачастую на практике в реальных проектах можно встретить довольно много людей, которых интересует только та или иная группа обязанностей, а не обе группы вместе.
Поэтому чисто статистически вам, как руководителю, может быть заметно выгоднее, быстрее и проще разделить эти обязанности именно на такие группы и назначить ответственными разных людей, причем именно тех, кто наиболее подходит для выполнения первого или второго.
группы обязанностей.
Вот как это может выглядеть на организационной диаграмме: 
Вы можете видеть, что на диаграмме 3 группа специалистов по обеспечению качества обведена пунктиром и внутри этой группы есть человек с должностью «Ведущий специалист по обеспечению качества».
Обратите внимание, что в группу контроля качества этого руководителя компетенции входят все тестировщики, доступные в проекте.
Таким же образом вы можете мысленно обвести вокруг себя аналитиков, джавистов, оракулистов и всех остальных, кто есть у вас в проекте.
Если проект большой и группы оказываются слишком большими, разбейте их на несколько, следуя правилу 7+-2 (от 5 до 9 человек в группе).
Таким образом, вы полностью освещаете вопрос компетенций, развития людей, проверки качества кода, коучинга, обучения, перекрестного обзора, обмена знаниями, резервного копирования людей и многие другие рабочие вопросы, на которые в боевых проектах часто не хватает времени.
Как может выглядеть список обязанностей руководителя группы ( ТЛ ) и руководитель компетенции ( К.
Л.
).
Ответственность ТЛ : 1. Доставка конкретных билетов JIRA 2. Ветки соответствующих релизов 3. * Отправка отпусков 4. * Сверхурочная подача 5. Информация о болезни или опоздании подчиненного 6. Проведение стендапов 7. ** Оценка билетов L0, L1 8. Распределение задач в команде: — Балансировка нагрузки ресурсов — Распределение ответственных за задачи Примечания: *В пунктах 3 и 4 имеется в виду подчинение, а не «одобрение».
**Пункт 7 – при обязательном участии К.
Л.
(по крайней мере, для больших и средних билетов) Ответственность К.
Л.
: 1. Ответственность за техническую и качественную сторону выполнения задач:
- Используемые технологии
- Использование стандартов
- Архитектурные вопросы
- Подходы, тестирование концепций.
Планы испытаний.
Обзор тестовых примеров
- Характеристики качества.
Обзор спецификации
- Соответствие решений требованиям и спецификациям
- Качество кода.
Обзор кода
- Коучинг для стажеров, новые камеры (и многое другое)
- Предложение технических улучшений
Л.
также должен принять участие в решении следующих вопросов: 1. Сдвиг сроков 2. Разбивка и ее изменения в сфере разработки, тестирования,.
3. Планы развития персонала, обучение, тренинги (вместе с ТЛ И ППМ ) Следующие шаги, которые вы можете предпринять: Как только вы обновите организационную структуру проекта, определите руководителей команд и руководителей по компетенциям, донесете и согласуете с ними их будущие обязанности, наделите их соответствующими полномочиями, объявите команде новую структуру и новые правила игры, начиная с этого момент в вашей жизни как лидера станет намного проще и легче.
Конечно, вы столкнетесь со многими другими трудностями и подводными камнями (никто не обещал, что будет легко и просто), но, по крайней мере, вопросы ответственности будут четко решены.
Поделитесь этой статьей с друзьями.
Спасибо и удачи вам! Теги: #Управление проектами #управление проектами и командой #карьера в нем #IT #управление проектами и людьми #управление проектами #управление персоналом #Карьера в IT-индустрии
-
Настройка Сервера Времени Windows
19 Oct, 24 -
Заслуживает Ли Поиск На Рабочем Столе?
19 Oct, 24 -
Гибкий Анализ. Мифы И Реальность
19 Oct, 24 -
10 Способов Улучшить Бас
19 Oct, 24
