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