Привет, друзья.
В данной статье мы разберем распределение ответственности в больших командах. Представьте себе ситуацию, что вы руководитель, в подчинении которого находится от двух до 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’ом и т.п. И отвечал не за полный жизненный цикл задачи от разработки спецификации к ней, через разработку, до этапа сдачи после успешного тестирования с багфиксингом, а только за какой-то из кусочков всего этого жизненного цикла SDLC (Software Development Life Cycle). Наша же задача, чтобы Team Lead отвечал за весь SDLC по задаче — только тогда у него будет возможность обеспечить поставку этой задачи вовремя, с нужным объемом функционала и с нужным уровнем качества. Стоимость на уровне Team Lead’а обычно не рассматривается, разве что в неких условных единицах, вроде WU (Work Unit = 1 человеко-день) или каких-то подобных единицах.
Не забываем, что для того, чтобы человек мог за что-то отвечать у него должна быть одна важная составляющая — полномочия. Т.е. ответственность и полномочия — две неотделимых друг от друга компоненты. Если у вас есть полномочия, но нет ответственности — беда для проекта и мы все видим на примере многих стран, к чему это ведет и чем заканчивается. Если у вас есть ответственность, но нет полномочий — еще большая беда, но только уже для вас, т.к. вы являетесь всего лишь козлом отпущения, на которого свалят провал. А провал точно будет, ведь вы не можете ни на что повлиять. Вариант, когда у вас нет ни полномочий, ни ответственности, я даже не рассматриваю, ибо в этом случае вы вообще не Lead. И только в случае, когда у вас есть и полномочия и ответственность, вы можете влиять на ситуацию и нести за это ответственность, равно как получать награды за успех.
Ниже находится схема, иллюстрирующая взаимоотношение Полномочия-Ответственность:
Давайте определимся, какие же обязанности могут быть (бывают) у Team Lead’а. Вот они:
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’а входят все имеющиеся в проекте тестировщики. Точно так же можно мысленно обвести аналитиков, джавистов, ораклистов и всех, кто у вас есть в проекте. Если проект большой и группы получаются слишком большие, разбейте их на несколько, руководствуясь правилом 7+-2 (от 5 до 9 человек на группу). Таким образом вы полностью закрываете вопрос компетенций, развития людей, проверок качества кода, коучинга, обучения, кросс-ревью, обмена знаниями, бэкапирования людей и многие другие рабочие вопросы, на которые часто не хватает времени в боевых проектах.
Как может выглядеть список обязанностей Team Lead’а (TL) и Competence Lead’а (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’ов, донесете и согласуете с ними их будущие обязанности, наделите их соответствующими полномочиями, озвучите команде новую структуру и новые правила игры, с этого момента ваша жизнь как руководителя станет намного проще и легче. Конечно, вы встретите еще много разных других сложностей и подводных камней (никто не обещал, что будет легко и просто), но как минимум вопросы ответственности у вас будут четко решены.
Поделитесь этой статьей с друзьями.
Спасибо и успехов вам!
В данной статье мы разберем распределение ответственности в больших командах. Представьте себе ситуацию, что вы руководитель, в подчинении которого находится от двух до 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’ом и т.п. И отвечал не за полный жизненный цикл задачи от разработки спецификации к ней, через разработку, до этапа сдачи после успешного тестирования с багфиксингом, а только за какой-то из кусочков всего этого жизненного цикла SDLC (Software Development Life Cycle). Наша же задача, чтобы Team Lead отвечал за весь SDLC по задаче — только тогда у него будет возможность обеспечить поставку этой задачи вовремя, с нужным объемом функционала и с нужным уровнем качества. Стоимость на уровне Team Lead’а обычно не рассматривается, разве что в неких условных единицах, вроде WU (Work Unit = 1 человеко-день) или каких-то подобных единицах.
Не забываем, что для того, чтобы человек мог за что-то отвечать у него должна быть одна важная составляющая — полномочия. Т.е. ответственность и полномочия — две неотделимых друг от друга компоненты. Если у вас есть полномочия, но нет ответственности — беда для проекта и мы все видим на примере многих стран, к чему это ведет и чем заканчивается. Если у вас есть ответственность, но нет полномочий — еще большая беда, но только уже для вас, т.к. вы являетесь всего лишь козлом отпущения, на которого свалят провал. А провал точно будет, ведь вы не можете ни на что повлиять. Вариант, когда у вас нет ни полномочий, ни ответственности, я даже не рассматриваю, ибо в этом случае вы вообще не Lead. И только в случае, когда у вас есть и полномочия и ответственность, вы можете влиять на ситуацию и нести за это ответственность, равно как получать награды за успех.
Ниже находится схема, иллюстрирующая взаимоотношение Полномочия-Ответственность:
Давайте определимся, какие же обязанности могут быть (бывают) у Team Lead’а. Вот они:
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’а входят все имеющиеся в проекте тестировщики. Точно так же можно мысленно обвести аналитиков, джавистов, ораклистов и всех, кто у вас есть в проекте. Если проект большой и группы получаются слишком большие, разбейте их на несколько, руководствуясь правилом 7+-2 (от 5 до 9 человек на группу). Таким образом вы полностью закрываете вопрос компетенций, развития людей, проверок качества кода, коучинга, обучения, кросс-ревью, обмена знаниями, бэкапирования людей и многие другие рабочие вопросы, на которые часто не хватает времени в боевых проектах.
Как может выглядеть список обязанностей Team Lead’а (TL) и Competence Lead’а (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’ов, донесете и согласуете с ними их будущие обязанности, наделите их соответствующими полномочиями, озвучите команде новую структуру и новые правила игры, с этого момента ваша жизнь как руководителя станет намного проще и легче. Конечно, вы встретите еще много разных других сложностей и подводных камней (никто не обещал, что будет легко и просто), но как минимум вопросы ответственности у вас будут четко решены.
Поделитесь этой статьей с друзьями.
Спасибо и успехов вам!
Askofen
1. Если сравнить организационную диаграмму на рисунке 1 с организационной диаграммой на рисунке 3, то за исключением названий пары должностей они одинаковые. Конечно, можно Project Manager'а переименовать в Team Lead'а, а Team Lead'а — в Competence Lead'а. Но вряд ли от такого переименования что-то кардинально изменится.
Пойдём дальше…
2. Утверждение о том, что при организации команды, как на рисунке 1, за сроки отвечает только менеджер, а Team Lead и другие члены команды — нет, несколько голословно. Это утверждение должно быть обосновано. Если у Автора в команде именно так, то это не означает, что в других командах точно такая же проблема. У нас за сроки реализации задачи отвечает человек, на которого она назначена. Если он испытывает какие-то технические сложности, то ему обязан помочь Team Lead. Если имеются какие-то организационные сложности (нет доступа к определённому ресурсу, вовремя не заведён аккаунт и т.д. и т.п.), то к делу подключается Project Manager.
3. Утверждение о том, что аналитик (в нашем случае — продюсер) и программист будут играть в футбол, переназначая задачу друг на друга тоже ни чем не мотивировано. У нас дизайн-документы с описанием требований должны быть подготовлены до начала production или до начала работы над определённым майлстоуном. Если дизайн фичи не готов, то она просто не пойдёт в production. Даже если вдруг потребуется добавить какую-нибудь фичу в середине работы над майлстоуном, то существует такой процесс, как ревью дизайн-документа. Перед ревью дизайн документ рассылается всем заинтересованным лицам так, что они имеют время его изучить. Во время ревью продюсер рассказывает о фиче, а инженеры задают вопросы и высказывают свои замечания. По результатам ревью продюсер вносит в дизайн-документ изменения. Кроме того, наличие замечаний или вопросов не является основанием для приостановки работы над фичей. Она идёт в production, просто продюсер параллельно вносит в дизайн-документ изменения, о которых договорились во время ревью.
4. Аналогично утверждение о футболе багов между тестером и инженером не выдерживает критики. Количества открытых и закрытых багов регулярно мониторятся менеджером проекта. Существуют метрики, позволяющие оценить качество работы инженера и инженера по тестированию. Среди них для оценки качества работы программиста на этапе bugfixing'а — количество исправленных багов в неделю и количество повторно переоткрытых багов (не должно быть больше 4%). Качество работы инженера по качеству оценивается с помощью сравнения количества найденных новых багов с количеством багов, которое планировалось найти к данной дате, а также — с помощью количества возвратов бага со стороны инженера (таким образом проверяется, насколько качественно сделано описание бага и steps to reproduce).
5. В целом, организационная диаграмма и название должностей не дают полного представления о качестве работы команды. Если нужно повысить качество работы команды, то следует начинать описание с зон ответственности, процессов и метрик. Простое переименование должностей ни к чему не ведёт.
Harret
Судя по Вашим комментариям, я не смог донести в своей статье то, что пытался. И диаграммы 1 и 3 не одинаковые.
Мне только немного удивительно, т.к. статья про зоны ответственности, а Вы не довольны названиями должностей. Ну значит будем считать, что с названиями я ошибся. Главное, что у вас все хорошо — и желаю Вам, чтобы так и оставалось.
DrPass
Честно говоря, у меня после прочтения статьи сложилось такое же мнение. Вы просто поменяли местами названия — назвали Team Lead человека с компетенциями РМ'а, а человека с компетенциями Team Lead переиначили в Competence Lead. По моему опыту, проблема корпоративного «футбола» действительно бывает достаточно острой… но такой способ её устранения, как Вы предлагаете, был описан еще в басне Крылова «Квартет». На самом деле эта проблема кроется в мотивации сотрудников и общей корпоративной дисциплине, и она в принципе не зависит от организационной структуры в команде.
Harret
Любимая тема — переводить вопросы ответственности в плоскость мотивации и дисциплины.
За задачу должен отвечать один человек, и не только нести ответственность, но и быть способным сделать задачу. В некоторых случаях (конечно же в придуманных мною :) ) оказывается так, что за некоторые части одной задачи отвечают разные люди. А за сборку частей в целое вообще не отвечает никто. И вот то, что у этих частей никак не получается сыграть в упомянутый Вами «Квартер» — виновато отсутствие у частей мотивации и только в этом причина.
К сожалению, я не могу согласиться с такой точкой зрения. Она загубила множество хороших проектов, команда, и карьер. Одно из работающих решений, как избежать размазывания ответственности — описано в статье.
И вот еще один момент: многие руководители любят придумывать разные позиции и должности, лишь бы как-то мотивировать своих подчиненных красивым «шильдиком», красивым названием должности. Мол, а давайте назовем Team Lead'а Руководителем проектов. Это же круче звучит. И никого совсем не беспокоит, что круг обязанностей такого свежеиспеченного руководителя проектов сильно не дотягивает до стандартного, описанного во многих методологиях. Частично еще и по этой причине находятся люди, не видящие разницы между приведенными в статье схемами.