http://consultpm.com/team-leads-responsibility/

Привет, друзья.

В данной статье мы разберем распределение ответственности в больших командах. Представьте себе ситуацию, что вы руководитель, в подчинении которого находится от двух до N потоков разработки, но вся эта разработка — одно большое приложение либо одна большая система, а каждый поток занимается своим модулем или своей частью модуля. Важно, чтобы потоки разработки почти не пересекались по функционалу, хотя использовать код соседей они вполне могут.
Итак, наша задача создать такую организационную структуру, при которой у вас, как у руководителя, будет максимальная вероятность успеха. Очевидно, что успех проекта зависит далеко не только от организационной структуры. В то же время правильная org. structure — одна из составляющих этого успеха.
Прежде чем мы с вами погрузимся в «кто, кому, что и когда» должен предоставлять, отчитываться и как будут организованы коммуникационные потоки, рассмотрим «классику жанра» — очень частое распределение и назначение зон ответственности, встречаемое в большом количестве проектов. Выглядит оно обычно как на рисунке ниже (Java и Oracle взяты для примера, вместо них могут быть совершенно любые другие технологии)
картинка в статье на сайте http://consultpm.com/team-leads-responsibility/ Уверен, многие из вас сталкивались с такими структурами, а, возможно, вы прямо сейчас работаете в одной из подобных. Все ли в них хорошо? Выполняют ли они свою функцию и помогают ли нам, как руководителям, быстрее, эффективнее, с минимально возможными затратами ресурсов приходить к успеху проекта? Если вы еще не руководитель, но планируете им стать, вам наверняка тоже интересно, почему такие структуры неэффективны и где именно ошибка.
Рассмотрим примеры выше.
Какая цель у руководителя проектов, программ, департамента? Помимо зарабатывания денег (зависит от уровня должности) цель только одна — сделать продукт вовремя, в рамках выделенного бюджета и с согласованным объемом и уровнем функционала и качества.
Теперь посмотрите на диаграммы выше. Позволят ли они сделать, скажем, релиз, вовремя и с нужным объемом функционала, да еще и при условленном уровне качества? Сильно сомневаюсь. Почему у меня есть сомнения? Причин несколько.
В первую очередь сомнения вызывает размытая зона ответственности. Вот скажите, кто на диаграммах выше отвечает за сроки, 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%. А на вопрос, почему же сроки вот-вот будут сорваны, последует закономерное отсутствие ответа, ведь никто не виноват. Тестировщики действительно честно тестируют. А разработчики действительно честно исправляют все найденные баги. Все действительно хотят выпустить в жизнь хороший продукт. Но мяч постоянно перебрасывается между разработчиками и тестировщиками, и конца этому не видно. Совершенно такая же ситуация будет между любыми другими подразделениями (аналитики — разработчики, разработчики — разработчики).
А главное — никто ни за что не отвечает кроме самого высокого руководителя, выступающего арбитром или координатором между одной группой и другой. А арбитром он выступать не может по очень простой причине — невозможно быть в курсе такого количества потоков разработки и задач. Если бы было можно — структура была бы совсем другой и тим-лиды были бы просто не нужны — остался бы один самый главный менеджер и обычные аналитики + разработчики + тестировщики. Но жизнь говорит нам, что так еще хуже. А значит проблему надо решать. Ключевая проблема находится в зонах ответственности. И именно это мы и обсудим дальше.
Далее → http://consultpm.com/team-leads-responsibility/ (Илья Рабчёнок)
Привет, друзья.В данной статье мы разберем распределение ответственности в больших командах. Представьте себе ситуацию, что вы руководитель, в