Добрый день,
раздумываю над корректным порядком движения задач в системе документооборота софтверной компании. Как пример можно взять Jira или Bugzill-у. Это чтобы ясно обозначить что я имею в виду под "документооборотом".

Раздумывая, как оно дОлжно быть, я неожиданно понял что многие разработчики с моими схемами совершенно не согласны.
Вот аксиомы которые я считаю обязательными к применению. Каково ваше мнение о них?

---------------------------------------
1 Поставленная ПМ задача должна быть принята исполнителем немедленно после прочтения. Для этого может использоваться статус Accepted. Исполняться задача может и через месяц после принятия (статус InProgress) — здесь важно отражение факта, что задача попала правильному лицу и он ее принял на исполнение.

2 если задача попала не в тот департамент (ошибка или исправление в другом компоненте, эту работу должны делать другие люди) — исполнитель ОБЯЗАН вернуть задачу постановщику (Статус return)
Исполнитель не может игнорировать задачу, это категорически запрещено.

руководство периодически ищет подвисшие запросы на которые никто не ответил и принимает меры.

---------------------------------------
Смешно, но в настоящий момент я встретил активное неприятие этих первых аксиом, дальше двигаться просто смысла нет. Вплоть до того что "отвечать на ошибочно поставленные задачи не входит в мои обязанности, вот трудовой договор!"



Интересно мнение сообщества и ссылки на правильные практики.

С уважением,
Андрей

Везде, где я работал было примерно так: если задача поставлена неправильно — она возвращается с кратким обоснованием; если задача не возвращается — она считается принятой, но её статус в системе трекинга не меняется вплоть до начала (а то и окончания) выполнения. "Зависшие" задачи выявляются по дате создания. Мне не очень ясно, чем задачи, подвисшие в статусе "New" отличаются от задач, подвисших в статусе "Accepted".

Отказ отвечать на неправильно поставленные задачи для меня звучит вообще как-то дико.

Здравствуйте, Pizarro, Вы писали:

P>Добрый день,
P>раздумываю над корректным порядком движения задач в системе документооборота софтверной компании. Как пример можно взять Jira или Bugzill-у. Это чтобы ясно обозначить что я имею в виду под "документооборотом".

P>Раздумывая, как оно дОлжно быть, я неожиданно понял что многие разработчики с моими схемами совершенно не согласны.
Чем аргументируют?
Может, недовольство вызывают не правила а сам факт внедрения системы отслеживания заданий?

P>Вот аксиомы которые я считаю обязательными к применению. Каково ваше мнение о них?
Если статус Accepted проставляет испольнитель — то схема, в общем, нормальная.
Но только при условии, что статус return будет не частым явлением

Здравствуйте, Pizarro,

вы правы
разработчики не правы

или вы нам не все сказали

Здравствуйте, Pizarro, Вы писали:

P>Добрый день,
P>раздумываю над корректным порядком движения задач в системе документооборота софтверной компании. Как пример можно взять Jira или Bugzill-у. Это чтобы ясно обозначить что я имею в виду под "документооборотом".

P>Раздумывая, как оно дОлжно быть, я неожиданно понял что многие разработчики с моими схемами совершенно не согласны.
P>Вот аксиомы которые я считаю обязательными к применению. Каково ваше мнение о них?

P>---------------------------------------
P>1 Поставленная ПМ задача должна быть принята исполнителем немедленно после прочтения. Для этого может использоваться статус Accepted. Исполняться задача может и через месяц после принятия (статус InProgress) — здесь важно отражение факта, что задача попала правильному лицу и он ее принял на исполнение.

P>2 если задача попала не в тот департамент (ошибка или исправление в другом компоненте, эту работу должны делать другие люди) — исполнитель ОБЯЗАН вернуть задачу постановщику (Статус return)
P>Исполнитель не может игнорировать задачу, это категорически запрещено.

Да, все правильно, только лучше назвать этот статус Rejected

P>руководство периодически ищет подвисшие запросы на которые никто не ответил и принимает меры.

А вот это — плохо. Подвисшие задачи должен искать человек, не являющийся руководителем исполнителей и напоминать им (в запросе, чтобы фиксировать количество напоминаний) о задачах. Ассистент руководителя проекта, например, или кто-то еще в подобном чине. Если видно, что исполнитель явно забил на задачу, ассистент интересуется — прямо в запросе, принципиальное ли это решение и может ли он доложить руководству о факте игнорирования. И только потом, когда все меры воздействия исчерпаны, идет письмо руководству с описанием обстоятельств и включением ссылки на запрос.

Это — важно. Если вы изначально рассматриваете данную систему как карательную, советую лучше отказаться от нее сразу. Ее не внедрить в этом качестве. Например, вы после постановки запроса можете натолкнуться на нескончаемый флуд с обсуждением каких-то мелочей, а на вопрос, сделана ли задача, получить ответ "я ее уточнял все это время, у нас ведь система есть".

P>---------------------------------------
P>Смешно, но в настоящий момент я встретил активное неприятие этих первых аксиом, дальше двигаться просто смысла нет. Вплоть до того что "отвечать на ошибочно поставленные задачи не входит в мои обязанности, вот трудовой договор!"

Могу заранее предсказать, хоть и не оракул, что внедрение данной системы в организации потребует массы времени и усилий. Если есть возможность — опишите бизнес-процесс, напишите инструкцию по работе с системой, утвердите все это у руководства и направьте в ИТ-отдел, иначе на основную работу вам придется забить. Лучше поручить внедрение кому-нибудь другому, чтобы ненавидели его, а не вас

P>Интересно мнение сообщества и ссылки на правильные практики.

Не понимаю, чему вы удивляетесь. Вы решили уменьшить энтропию в своей организации, и против вас сейчас работают законы Вселенной

А если серьезно — разработчики, вполне справедливо со своей стороны, рассматривают введение системы запросов как уменьшение собственной свободы и ждут введения каких-то KPI после внедрения. Объясните им проблему, стоящую перед вами, не стесняйтесь — только уважать больше будут.

Внедрение пойдет через конфликты и взаимные обвинения, готовьтесь к этому сейчас. У вас пока все это еще только начинается. Нужно иметь большую волю и заручиться поддержкой первых лиц компании для внедрения системы запросов.

Опишу морковку. Самая прекрасная штука — что вы можете только ставить задачи в системе запросов, контролировать процесс их выполнения может другой человек. Например, у меня было одновременно около пятидесяти задач в системе запросов, и моего личного времени на них уходило около часа в день. Работало это так: с утра приходил ассистент, разруливал задачи, которые были в его компетенции (а таких было 90%), и несколько запросов переставлял на меня. Я переставлял запросы на исполнителей, пользуясь своими властными полномочиями, и опять перенаправлял их ассистенту на мониторинг. Я думаю, понятно, что загруженность и зарплата ассистента и РМа несколько отличаются

Ко мне перестали поступать идиотские запросы из других подразделений, потому что я требовал оформлять запросы через эту систему, а когда человек пишет что-то, что может прочитать его руководство, он обычно вначале думает, а потом пишет

Еще одна вкусняшка, не совсем очевидная. Во время сдачи проекта, когда РМ (и архитектор) ночует у заказчика, 90% задач — выполняется по-прежнему, без его участия, при этом ассистент постепенно вырастает в ПМа — ему деваться некуда Хотя, конечно, не всякий вырастает.

Там есть еще много всего хорошего, игра, безусловно, стоит свеч.

Здравствуйте, Pizarro, Вы писали:

P>1 Поставленная ПМ задача должна быть принята исполнителем немедленно после прочтения. Для этого может использоваться статус Accepted. Исполняться задача может и через месяц после принятия (статус InProgress) — здесь важно отражение факта, что задача попала правильному лицу и он ее принял на исполнение.

P>2 если задача попала не в тот департамент (ошибка или исправление в другом компоненте, эту работу должны делать другие люди) — исполнитель ОБЯЗАН вернуть задачу постановщику (Статус return)
P>Исполнитель не может игнорировать задачу, это категорически запрещено.

P>руководство периодически ищет подвисшие запросы на которые никто не ответил и принимает меры.

P>---------------------------------------
P>Смешно, но в настоящий момент я встретил активное неприятие этих первых аксиом, дальше двигаться просто смысла нет. Вплоть до того что "отвечать на ошибочно поставленные задачи не входит в мои обязанности, вот трудовой договор!"

Ну тут все просто, чтобы принять задачу я должен потратить на нее время, чтобы ее понять. Т.е. я сразу ее переведу в In Progress. Ok? Нет, не Ok?
Тогда назовите статус Investigation, а задаче поставьте приоритет. Обяжите разработчиков браться сначала за приоритетные задачи (с этим они согласятся).

А с Accepted есть следующие проблемы:
1. Что будет, если человек, который поставил Accepted а) уволится, б) заболеет, в) уйдет в отпуск?
2. Что делать, если я выполнил все свои задачи, а свободных задач нет (все Accepted кем-то другим)?

Здравствуйте, SE, Вы писали:

P>>1 Поставленная ПМ задача должна быть принята исполнителем немедленно после прочтения. Для этого может использоваться статус Accepted. Исполняться задача может и через месяц после принятия (статус InProgress) — здесь важно отражение факта, что задача попала правильному лицу и он ее принял на исполнение.

P>>2 если задача попала не в тот департамент (ошибка или исправление в другом компоненте, эту работу должны делать другие люди) — исполнитель ОБЯЗАН вернуть задачу постановщику (Статус return)
P>>Исполнитель не может игнорировать задачу, это категорически запрещено.

P>>руководство периодически ищет подвисшие запросы на которые никто не ответил и принимает меры.

P>>---------------------------------------
P>>Смешно, но в настоящий момент я встретил активное неприятие этих первых аксиом, дальше двигаться просто смысла нет. Вплоть до того что "отвечать на ошибочно поставленные задачи не входит в мои обязанности, вот трудовой договор!"

SE>Ну тут все просто, чтобы принять задачу я должен потратить на нее время, чтобы ее понять. Т.е. я сразу ее переведу в In Progress. Ok? Нет, не Ok?

А что, если в организации нет системы запросов, все происходит как-то по-другому?

SE>Тогда назовите статус Investigation, а задаче поставьте приоритет. Обяжите разработчиков браться сначала за приоритетные задачи (с этим они согласятся).

Если начать пользоваться приоритетами, все задачи станут находиться в высшем приоритете. Потому что с течением времени все задачи оказываются на критическом пути — обычное состояние для проекта с запаздывающими сроками (а где вы видели другие проекты?). Но это мой личный опыт. Мне было откровенно лень писать соответствующий регламент по присвоению и изменению приоритетов, а затем добиваться его соблюдения. Проще перевести ставший некритичным запрос в состояние "отложен" или перевести на исполнителя "кто-то, у кого есть время".

Приоритет запросов имеет смысл, если вы обращаетесь с запросом к другому подразделению, предоставляющему некоторый сервис -отделу кадров или ИТ-службе, поскольку "добавить памяти" и "сломался монитор" требуют разного времени реакции. В этом случае действительно пишется регламент, называемый SLA (Соглашение об уровне сервиса), в котором детально расписаны случаи обращения и их допустимые приоритеты.

В принципе, приоритет возможен для задач типа "пофиксить критичный баг" и "заменить Сергею разваливающийся стул", но их лучше разнести по разным системам запросов, чем пытаться с помощью приоритетов скрестить ужа с ежом.

SE>А с Accepted есть следующие проблемы:
SE>1. Что будет, если человек, который поставил Accepted а) уволится, б) заболеет, в) уйдет в отпуск?

а)выявляется по дате последней активности в запросе
б)выявляется при очередном просмотре всех запросов
с)выявляется при группировке запросов по людям и переназначением зомби на оставшихся

Хватит? Я могу еще, мне не трудно Это не проблема, поверьте на слово. В Jira есть множество способов группировки и поиска задач.

SE>2. Что делать, если я выполнил все свои задачи, а свободных задач нет (все Accepted кем-то другим)?

То же самое, если выполнил последнее полученное задание в организации, в которой нет системы запросов

Здравствуйте, SE, Вы писали:

SE>А с Accepted есть следующие проблемы:
SE>1. Что будет, если человек, который поставил Accepted а) уволится, б) заболеет, в) уйдет в отпуск?
Никаких проблем нет. О факте пропажи человека знает PM он и решит, что делать с задачами (оставить ждать выздоровдления или перевести на другого человека сменив статус). Тем более, что вещи это не частые и, кроме болезни, не возникающие внезапно.

SE>2. Что делать, если я выполнил все свои задачи, а свободных задач нет (все Accepted кем-то другим)?
Сказать PM-у. Без задачи не останетесь

Здравствуйте, nvb, Вы писали:

nvb>Если начать пользоваться приоритетами, все задачи станут находиться в высшем приоритете. Потому что с течением времени все задачи оказываются на критическом пути — обычное состояние для проекта с запаздывающими сроками (а где вы видели другие проекты?). Но это мой личный опыт.
Хорошо, что Вы уточнили про личный опыт. Мой личный опыт говорит ровно обратное. Если у всех задач высший приоритет, то это означает, что PM (или тот, кто занимается приоритезацией) забил на свои обязанности. Если, например, обе две задачи обязаны быть сделанныими, то это не всегда значит, что у них одинаковый приоритет. На том же критическом пути ранее стоящая задача будет иметь более высокий приоритет, чем следующая за ней.

nvb> Мне было откровенно лень писать соответствующий регламент по присвоению и изменению приоритетов, а затем добиваться его соблюдения. Проще перевести ставший некритичным запрос в состояние "отложен" или перевести на исполнителя "кто-то, у кого есть время".
Это и есть приоритет Просто, видимо, поле "приоритет" кому-то не понравилось.

nvb>В принципе, приоритет возможен для задач типа "пофиксить критичный баг" и "заменить Сергею разваливающийся стул", но их лучше разнести по разным системам запросов, чем пытаться с помощью приоритетов скрестить ужа с ежом.
А есть организации, где это смешивается?

Здравствуйте, vmpire, Вы писали:

V>Здравствуйте, SE, Вы писали:

SE>>А с Accepted есть следующие проблемы:
SE>>1. Что будет, если человек, который поставил Accepted а) уволится, б) заболеет, в) уйдет в отпуск?
V>Никаких проблем нет. О факте пропажи человека знает PM он и решит, что делать с задачами (оставить ждать выздоровдления или перевести на другого человека сменив статус). Тем более, что вещи это не частые и, кроме болезни, не возникающие внезапно.

SE>>2. Что делать, если я выполнил все свои задачи, а свободных задач нет (все Accepted кем-то другим)?
V>Сказать PM-у. Без задачи не останетесь

Т.е. так или иначе, все замкнулось на ПМа, который должен все разрулить. Система не справилась со своим назначением — упростить работу в компании.
Ну а, если а ПМ заболеет, то наступит хаос и неразбериха, даже если сразу смотут заменить заместителем или еще кем-то.

Я именно на это хотел обратить внимание. Просто сразу сам это не осознал.

Здравствуйте, Pizarro, Вы писали:

P>Смешно, но в настоящий момент я встретил активное неприятие этих первых аксиом, дальше двигаться просто смысла нет. Вплоть до того что "отвечать на ошибочно поставленные задачи не входит в мои обязанности, вот трудовой договор!"

Ничего удивительного. Ваши аксиомы это типичная попытка руководителя облегчить себе жизнь за счет усложнения жизни других.

Если у руководителя манипулирование задачами в Jira это основная функция, то у исполнителя основная функция это анализ, разработка, тестиорвание, и т.д. А вот сопровождение всех своих основных действий отметками в Jira — это уже издержки.

К сожалению, стараниями менеджера очень легко можно превратить Jira из инструмента помогающего в работе в инструмент мешающий. Поэтому с регламентами надо поосторожнее. Начинайте с наипростейшего. Добавляйте новые правила только в случае реальной необходимости, когда эта необходимость выявляется в процессе работы.

Здравствуйте, vmpire, Вы писали:

V>Здравствуйте, nvb, Вы писали:

nvb>>Если начать пользоваться приоритетами, все задачи станут находиться в высшем приоритете. Потому что с течением времени все задачи оказываются на критическом пути — обычное состояние для проекта с запаздывающими сроками (а где вы видели другие проекты?). Но это мой личный опыт.
V>Хорошо, что Вы уточнили про личный опыт. Мой личный опыт говорит ровно обратное. Если у всех задач высший приоритет, то это означает, что PM (или тот, кто занимается приоритезацией) забил на свои обязанности. Если, например, обе две задачи обязаны быть сделанныими, то это не всегда значит, что у них одинаковый приоритет. На том же критическом пути ранее стоящая задача будет иметь более высокий приоритет, чем следующая за ней.

Вы исходите из того, что задач мало, программистов хватает и критический путь один. Завидую Вашему опыту, но в общем случае это не так. Когда программер нарасхват, у него все задачи высокоприоритетные, вне зависимости, раздолбай РМ или нет.

nvb>> Мне было откровенно лень писать соответствующий регламент по присвоению и изменению приоритетов, а затем добиваться его соблюдения. Проще перевести ставший некритичным запрос в состояние "отложен" или перевести на исполнителя "кто-то, у кого есть время".
V>Это и есть приоритет Просто, видимо, поле "приоритет" кому-то не понравилось.

Хм. Получается, да Как-то не думал над этим.

nvb>>В принципе, приоритет возможен для задач типа "пофиксить критичный баг" и "заменить Сергею разваливающийся стул", но их лучше разнести по разным системам запросов, чем пытаться с помощью приоритетов скрестить ужа с ежом.
V>А есть организации, где это смешивается?

Вы переоцениваете мой опыт — я не так много работ менял Там, где работал — не встречал. Наверное, потому что запросы про стул и про баг имеют разные бизнес-процессы их обработки, что влечет за собой разные названия статусов запросов. Это со временем понимают и разносят такие запросы по разным системам. Так что вряд ли смешивается.

Здравствуйте, SE, Вы писали:

SE>>>А с Accepted есть следующие проблемы:
SE>>>1. Что будет, если человек, который поставил Accepted а) уволится, б) заболеет, в) уйдет в отпуск?
V>>Никаких проблем нет. О факте пропажи человека знает PM он и решит, что делать с задачами (оставить ждать выздоровдления или перевести на другого человека сменив статус). Тем более, что вещи это не частые и, кроме болезни, не возникающие внезапно.

SE>>>2. Что делать, если я выполнил все свои задачи, а свободных задач нет (все Accepted кем-то другим)?
V>>Сказать PM-у. Без задачи не останетесь

SE>Т.е. так или иначе, все замкнулось на ПМа, который должен все разрулить. Система не справилась со своим назначением — упростить работу в компании.
SE>Ну а, если а ПМ заболеет, то наступит хаос и неразбериха, даже если сразу смотут заменить заместителем или еще кем-то.
Не могу согласиться.
Роль системы не заменить PM-а, а разгрузить его, упростив его работу в той части, что легко формализуется.
С этим она справляться вполне будет.
В реальном проектек болезнь/увольнение/отпуск будут наступать не чаще, чем раз в неделю. Один раз в неделю прочесать таски одного-пяти известных заранее людей займёт гораздо меньше времени, чем делать это каждый день для всего проекта.

SE>Я именно на это хотел обратить внимание. Просто сразу сам это не осознал.

Здравствуйте, nvb, Вы писали:

V>>Хорошо, что Вы уточнили про личный опыт. Мой личный опыт говорит ровно обратное. Если у всех задач высший приоритет, то это означает, что PM (или тот, кто занимается приоритезацией) забил на свои обязанности. Если, например, обе две задачи обязаны быть сделанныими, то это не всегда значит, что у них одинаковый приоритет. На том же критическом пути ранее стоящая задача будет иметь более высокий приоритет, чем следующая за ней.
nvb>Вы исходите из того, что задач мало, программистов хватает и критический путь один. Завидую Вашему опыту, но в общем случае это не так. Когда программер нарасхват, у него все задачи высокоприоритетные, вне зависимости, раздолбай РМ или нет.
С чего Вы взяли про "задач мало, программистов хватает"? Это вовсе не так. Просто даже программист нарасхват, то в один момент времени он всё равно работает только над одной задачей. А если при этом "все задачи высокоприоритетные", то он будет их выполнять в случайной последовательности, а не в максимально удобной для проекта. Тем более он не будет над этим думать, если у него задач много. Тут как раз и могут помочь грамотно расставленные приоритеты. Вы, как мне кажется, смешиваете понятия "приоритет задачи" и "важность задачи для проекта".

nvb>Наверное, потому что запросы про стул и про баг имеют разные бизнес-процессы их обработки, что влечет за собой разные названия статусов запросов. Это со временем понимают и разносят такие запросы по разным системам. Так что вряд ли смешивается.
Мне тоже так кажется. Система "работы со стульями" в организации обычно завязана на совсем других людей нежели система работы с багами проекта.

Здравствуйте, vmpire, Вы писали:

V>Здравствуйте, nvb, Вы писали:

V>>>Хорошо, что Вы уточнили про личный опыт. Мой личный опыт говорит ровно обратное. Если у всех задач высший приоритет, то это означает, что PM (или тот, кто занимается приоритезацией) забил на свои обязанности. Если, например, обе две задачи обязаны быть сделанныими, то это не всегда значит, что у них одинаковый приоритет. На том же критическом пути ранее стоящая задача будет иметь более высокий приоритет, чем следующая за ней.
nvb>>Вы исходите из того, что задач мало, программистов хватает и критический путь один. Завидую Вашему опыту, но в общем случае это не так. Когда программер нарасхват, у него все задачи высокоприоритетные, вне зависимости, раздолбай РМ или нет.
V>С чего Вы взяли про "задач мало, программистов хватает"? Это вовсе не так. Просто даже программист нарасхват, то в один момент времени он всё равно работает только над одной задачей. А если при этом "все задачи высокоприоритетные", то он будет их выполнять в случайной последовательности, а не в максимально удобной для проекта. Тем более он не будет над этим думать, если у него задач много. Тут как раз и могут помочь грамотно расставленные приоритеты. Вы, как мне кажется, смешиваете понятия "приоритет задачи" и "важность задачи для проекта".

Ок. Берем ситуацию: конец проекта. 20 человек в проекте, что влечет за собой наличие, по меньшей мере, 3 лидов. Есть 2 перегруженных программера, единственных специалистов в своей предметной области. Есть 30 критичных багов в написанном ими коде, по 10 на лида. Вы действительно верите, что лиды между собой договорятся, чей баг более критичен? Не надо припутывать здесь ПМа, ему просто вынесут мозг, и он поставит приоритет на задачи того лида, который его больше всего достал. Ну или программеры будут вначале выполнять задачи тех лидов, с которыми у них лучше отношения.

И один лид для своих 10 задач не расставит приоритеты, т.к, если он это сделает, его задачи будут вытеснены задачами другого лида, который приоритеты не расставил.

Собственно, я описываю кейс, который характеризуется недостатком времени на управление. Как бороться с этим недостатком времени — давайте оставим за пределами обсуждения. В более спокойной обстановке, разумеется, можно работать с приоритетами, но там и проблема приоритезации не стоит, никто статус "Critical" без нужды ставить не будет, по причине элементарной лени, впрочем, как и "Trivial" — у всех будет стоять по дефолту.

Здравствуйте, Pizarro, Вы писали:


P>1 Поставленная ПМ задача должна быть принята исполнителем немедленно после прочтения. Для этого может использоваться статус Accepted.

Во-первых, здесь не оговорен временной интервал между постановкой и прочтением, во-вторых, четкий круг читающих. Кто назначает исполнителя? Сам ПМ или у исполнителей есть возможность мониторить систему на предмет появления новых задач именно по их предпочтениям и компетенции?

Ну, и если все задачи проходят цензуру ПМ, а не поступают напрямую от пользователей, то все равно лучше раздавать их не сразу конкретным людям на пару месяцев вперед. Ничего плохого нет в том, что вся команда в курсе общего фронта работ, но каждый ведет одну-две задачи одновременно, а большинство задач висит в общем пуле. Избавитесь от ситуации, когда один разработчик нахватал (или на него навешали) задач, завис на одной из них по какой-то причине, а остальные, ни себе, ни людям.

Если задачи поступают от пользователей, то статус Accepted должен выставлять ПМ или его помощник, в случае если задача действительно новая, ничего не дублирует, ничему не противоречит и поставленна более менее корректно и внятно (перед выставлением статуса полезно будет ее кратко переформулировать на языке понятном исполнителям, в случае чего). В противном случае, статус Rejected.

Здравствуйте, nvb, Вы писали:

nvb>Ну или программеры будут вначале выполнять задачи тех лидов, с которыми у них лучше отношения.
nvb>И один лид для своих 10 задач не расставит приоритеты, т.к, если он это сделает, его задачи будут вытеснены задачами другого лида, который приоритеты не расставил.

Это где один девелопер нескольким лидам подчиняется?

Функциональная структура присуща скажем заводу, в котором пять электриков, которые выполняют работы в трех цехах. Сегодня здесь, а завтра там....
Работе программистов свойственна проектная или матричная структура. В последнем случае девелоперов все равно между собой "делят" менеджеры проектов.

Здравствуйте, SE, Вы писали:

SE>Здравствуйте, nvb, Вы писали:

nvb>>Ну или программеры будут вначале выполнять задачи тех лидов, с которыми у них лучше отношения.
nvb>>И один лид для своих 10 задач не расставит приоритеты, т.к, если он это сделает, его задачи будут вытеснены задачами другого лида, который приоритеты не расставил.

SE>Это где один девелопер нескольким лидам подчиняется?

Это где я такое писал?

А вот принять задачи от разных лидов он может легко.

SE>Функциональная структура присуща скажем заводу, в котором пять электриков, которые выполняют работы в трех цехах. Сегодня здесь, а завтра там....
SE>Работе программистов свойственна проектная или матричная структура. В последнем случае девелоперов все равно между собой "делят" менеджеры проектов.

Я знаю Довелось работать год функциональным менеджером в матричной структуре. Больше не хочу.

Здравствуйте, nvb, Вы писали:

nvb>Ок. Берем ситуацию: конец проекта. 20 человек в проекте, что влечет за собой наличие, по меньшей мере, 3 лидов. Есть 2 перегруженных программера, единственных специалистов в своей предметной области. Есть 30 критичных багов в написанном ими коде, по 10 на лида. Вы действительно верите, что лиды между собой договорятся, чей баг более критичен? Не надо припутывать здесь ПМа, ему просто вынесут мозг, и он поставит приоритет на задачи того лида, который его больше всего достал. Ну или программеры будут вначале выполнять задачи тех лидов, с которыми у них лучше отношения.
nvb>И один лид для своих 10 задач не расставит приоритеты, т.к, если он это сделает, его задачи будут вытеснены задачами другого лида, который приоритеты не расставил.
Ну та это проблемы не системы и не приоритетов. Это классическая проблема нескольких начальников, среди которых нет "главного". Эту проблему никакая система, конечно, не решит, если они сами не могут договориться.
В таких случаях нужно чётко выстраивать цепочки подчинения. По любому не программер должен решать, какую задачу делать первой, особенно когда в проекте аврал. А если лиды договориться не могут, то они просто оставляют расстановку приоритетов (неявную) программисту. Неэффективно, но никому не обидно. Нездоровая практика.

nvb>Собственно, я описываю кейс, который характеризуется недостатком времени на управление. Как бороться с этим недостатком времени — давайте оставим за пределами обсуждения. В более спокойной обстановке, разумеется, можно работать с приоритетами, но там и проблема приоритезации не стоит, никто статус "Critical" без нужды ставить не будет, по причине элементарной лени, впрочем, как и "Trivial" — у всех будет стоять по дефолту.
Если система не работает в режиме аврала, то она не сильно помогает и в спокойной обстановке. В этом случае она вообще не нужна.
В описанном случае, как я уже сказал, приоритеты никуда не деваются, просто их расставляет исполнитель, не фиксируя в системе. Что во-первых приводит к неоптимальной их расстановке, во вторых — ещё больше нагружает человека, который и так зашивается.

Здравствуйте, vmpire, Вы писали:

nvb>>Ок. Берем ситуацию: конец проекта. 20 человек в проекте, что влечет за собой наличие, по меньшей мере, 3 лидов. Есть 2 перегруженных программера, единственных специалистов в своей предметной области. Есть 30 критичных багов в написанном ими коде, по 10 на лида. Вы действительно верите, что лиды между собой договорятся, чей баг более критичен? Не надо припутывать здесь ПМа, ему просто вынесут мозг, и он поставит приоритет на задачи того лида, который его больше всего достал. Ну или программеры будут вначале выполнять задачи тех лидов, с которыми у них лучше отношения.
nvb>>И один лид для своих 10 задач не расставит приоритеты, т.к, если он это сделает, его задачи будут вытеснены задачами другого лида, который приоритеты не расставил.
V>Ну та это проблемы не системы и не приоритетов. Это классическая проблема нескольких начальников, среди которых нет "главного". Эту проблему никакая система, конечно, не решит, если они сами не могут договориться.

А система внедряется не для решения этой проблемы. Во всяком случае, из письма топикстартера это явно не следует.

Я, например, представляю себе эту систему как бельевую веревку на балконе. Нашел проблему или появилась новая задача — подвешиваю ее на веревке для всеобщего рассмотрения, с уверенностью, что она не потеряется. После чего уже другой человек пристально рассматривает эти задачи и снимает их с веревки, делегируя задачи на исполнителей. Я ограничиваюсь периодическим контролем процесса. Это высвобождает массу моего времени на решение более серьезных задач. Плюс повышается моя мотивация — убирается куча текучки, мечта любого менеджера.

V>В таких случаях нужно чётко выстраивать цепочки подчинения. По любому не программер должен решать, какую задачу делать первой, особенно когда в проекте аврал. А если лиды договориться не могут, то они просто оставляют расстановку приоритетов (неявную) программисту. Неэффективно, но никому не обидно. Нездоровая практика.

Цепочки и так есть. ПМ->лиды. Просто у ПМа нет времени на принятие всесторонне сбалансированного решения. Выход — сделать выполнение проекта безавральным в течение всего времени выполнения, что далеко выходит за рамки этого обсуждения.

nvb>>Собственно, я описываю кейс, который характеризуется недостатком времени на управление. Как бороться с этим недостатком времени — давайте оставим за пределами обсуждения. В более спокойной обстановке, разумеется, можно работать с приоритетами, но там и проблема приоритезации не стоит, никто статус "Critical" без нужды ставить не будет, по причине элементарной лени, впрочем, как и "Trivial" — у всех будет стоять по дефолту.
V>Если система не работает в режиме аврала, то она не сильно помогает и в спокойной обстановке. В этом случае она вообще не нужна.

"Не работает" — слишком широкое обобщение. Я бы сузил — не может выполнять одну из декларируемых ей функций. Ключевая она или нет — каждый решает сам. Для меня — не ключевая.

V>В описанном случае, как я уже сказал, приоритеты никуда не деваются, просто их расставляет исполнитель, не фиксируя в системе. Что во-первых приводит к неоптимальной их расстановке, во вторых — ещё больше нагружает человека, который и так зашивается.

Да кто бы спорил... Только внедрением системы запросов эту проблему не решить.