Мне совершенно неинтересно с вами общаться, Сергей - для этого у меня любимые люди есть ))
А у вас вот, похоже, как-то с ними не сложилось ))))) судя по данной теме...

Не-не, ничего личного, просто забавно.

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

Так а зачем вы начали так общаться, чтобы стало неинтересно?

Вы сами написали в эту тему, и зачем в первом же сообщении сразу про доктора?
Мне не то что было неинтересно, мне было неприятно.
Тем не менее я продолжил, и корректно у вас спросил что вы имеете ввиду.
Вы и во второй раз написали про доктора. Вы считаете это приемлемым?

Не вижу ничего забавного в том, что вы в теме написали много неприятных вещей без всяких объяснений,
заглушив тем самым обсуждение темы по сути.

Сергей (es3000)

сразу после этого:

За деньги - с удовольствием расскажу.
Бесплатно - ищите в литературе.

можно было бы не продолжать "кормить"...
а то действительно получается слишком много текста и тема не читабельна(

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

Так а зачем вы начали так общаться, чтобы стало неинтересно?

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

Зато мы имеем уже три страницы обсуждений того, что все присутствующие и так знают - кто на практике, кто интуитивно. Итоговая полезность темы = 0,1 ))

можно было бы не продолжать "кормить".

это очень хорошо, что вы так внимательны.

Поясню свою позицию.

За 10 лет коммуникационной работы со специалистами в разных ролях и разного уровня подготовки, не считая неформальных коммуникаций (с людьми из разных социальных и профессиональных слоев), я научилась довольно быстро выделять категорию клиентов, которым отказываю в консультации. Сергей по своим параметрам в эту категорию входит, что и выяснялось по мере того, как он отвечал на задаваемые вопросы. А чтобы не делать преждевременных выводов, вопросов было задано несколько, не всегда с целью получить ответ на сам вопрос - иногда с целью понаблюдать за ходом рассуждений.

Это вовсе не означает, что какой-то другой специалист Сергея не проконсультирует, за деньги или без денег - просто у всех есть свои вкусы.

Вот так в двух словах...

кризис.

люди сидят и отказывают в консультациях.

сегодня — этому откажу.

завтра — вот этому.

Денис, я никогда не консультирую определенную категорию людей )))
Не буду детализировать, чтобы никого не обижать.

Мне нравится получать удовольствие от всего, что я делаю )) коммуникации в т.ч.

Сергей, о каком количестве задач идёт речь? Десятки? Сотни? Тысячи? Десятки тысяч?

Расскажу о системе, которую применяем мы, оперируя десятками тысяч задач при работе над очередной версией приложения.

1. Разбиваем задачи на несколько видов. Например:

- Feature (несколько десятков)
- Sub-Feature (несколько сотен)
- Sub-Feature Element (несколько тысяч)
- Milestone Deliverable - это Feature, Sub-Feature или Sub-Feature Element, который нужно реализовать к определённому майлстоуну (несколько тысяч)
- Development Task (как правило, техническая задача, которую нужно сделать и проверить её реализацию при помощи QA, несколько десятков или сотен)
- Problem Report - баг (несколько десятков тысяч)
- Localization Issue (баг, связанный с локализацией, несколько сотен)
- Техническая задача (проверяется другим инженером во время code review, QA проверяет в рамках feature, от нескольких сотен до нескольких тысяч)

2. Задачи вносятся в систему контроля задач в соответствии с их видом. Каждый вид имеет свой workflow.

3. Приложение "дробится" на области по разным основаниям. Мы используем одновременно две классификации: пользовательскую и техническую. Пользовательская классификация позволяет "раздробить" приложение на части с точки зрения пользователя. Техническая "дробит" приложение на технические части.

Например, навигационная система GPS может быть разделена с точки зрения пользователя на такие подсистемы:

1) Карта.
2) Построение маршрута.
3) Навигация по маршруту.
4) Поиск адреса.
5) Поиск мест.

Та же самая навигационная система может быть разделена с технической точки зрения на такие части:

1) База данных.
2) Аудио.
3) Рисование карты.
4) Алгоритмы.
5) UI.

4. Каждая задача содержит маркеры - к какой области она относится. Одновременно используются 2 классификации - пользовательская и техническая.

5. Также в качестве маркера можно использовать и feature, к которой относится задача.

Кирилл, так на сколько я понял основной вопрос именно в системе контроля задач (п.2). Если не сложно - можно подробнее? а то самое "вкусненькое" описано так скупо(

Milstud,

Мы используем одновременно 2 системы управления задачами + Excel:

1. Hansoft - для управления девелоперскими задачами, для распределения нагрузки, планирования спринтов, контроля сроков.
2. DevTrack - для управления дефектами и фичами. Разница с Hansoft - выполнение задачи из DevTrack'а проверяется продюсерами и QA. В Hansoft заносятся технические задачи. Они особо никем не верифицируются, кроме самого девелопера.
3. Excel - для построения отчетов, графиков. А также - для управления рисками, продюсерскими задачами и прочим.

Коллеги, понимаю, что мое мнение отличается от мнения большинства, но тем не менее:

В деле управления задачами на первом месте стоят знания и умения. По степени влияния на качество процесса управления, система управления задачами стоит примерно на шестом месте. Ее влияние менее 5%. Т.е. пренебрежимо мало. Надежда "на синюю таблетку" / "бога из машины" является классическим заблуждением. Невероятно популярным.

Доказательство методом "Если то..."
Если главным по степени влияния является трекер, то высокооплачиваемые менеджеры просто не нужны. Понабрать продавщиц из Макдональса, дать им "правильный трекер" и вуаля!

Доказательство из статистических исследований.
На западе статистику собирают и анализируют. Грех не воспользоваться.  Роберт Гласс в книге "Факты и заблуждения профессионального программирования" приводит факт, что на текущий момент никакая технология не может увеличить эффективность разработки более чем на 5%.

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

Получается, что за счет разбиения задач на уровни,
количество задач на конкретном уровне значительно сокращается и работать с ними легче.
Согласен.

Но все равно в рамках каждого уровня приходится выполнять похожие операции над совокупностью задач данного уровня: группировка, сортировка, декомпозиция, приоритезация, поручение, и т.д.

Или в вашем случае нет такой команды?

небольшая команда есть, но все равно количество задач у меня получилось очень значительное

Сергей, о каком количестве задач идёт речь? Десятки? Сотни? Тысячи? Десятки тысяч?

Высокоуровневых задач наверно 100-200,
а задач более низких уровней - несколько тысяч.

Расскажу о системе, которую применяем мы, оперируя десятками тысяч задач при работе над очередной версией приложения.
1. Разбиваем задачи на несколько видов. Например:
...
2. Задачи вносятся в систему контроля задач в соответствии с их видом. Каждый вид имеет свой workflow.
3. Приложение "дробится" на области по разным основаниям. Мы используем одновременно две классификации: пользовательскую и техническую. Пользовательская классификация позволяет "раздробить" приложение на части с точки зрения пользователя. Техническая "дробит" приложение на технические части.
...
4. Каждая задача содержит маркеры - к какой области она относится. Одновременно используются 2 классификации - пользовательская и техническая.
5. Также в качестве маркера можно использовать и feature, к которой относится задача.

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

Мы используем одновременно 2 системы управления задачами + Excel:
1. Hansoft - для управления девелоперскими задачами, для распределения нагрузки, планирования спринтов, контроля сроков.
...

Как вы распределяете нагрузку?
Есть какой-то подход? Или просто хаотично?

Коллеги, понимаю, что мое мнение отличается от мнения большинства, но тем не менее:

В деле управления задачами на первом месте стоят знания и умения.

Знания и умения чего?
В деле управления задачами надо знать что? и уметь что?

Я за это время нашел один из методов, который позволяет упорядочивать задачи:
https://ru.wikipedia.org/wiki/Метод_анализа_иерархий.

Но его применение наверно будет очень трудозатратным.

Но все равно в рамках каждого уровня приходится выполнять похожие операции над совокупностью задач данного уровня: группировка, сортировка, декомпозиция, приоритезация, поручение, и т.д.

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

Значит нужно из всех задач (как вы пишете - из десятков тысяч) выбрать именно те, которые наиболее актуальны на данный момент.
Как вы делаете этот отбор? По каким признакам вы отбираете первоочередные задачи? Вот это меня интересует.
Как вы распределяете нагрузку?

Ну вообщем-то каждая задача должна быть оценена (непосредственным исполнителем, заказчиком, тим лидом) как минимум по таким параметрам как: критичность (на сколько критична эта задача в рамках текущего состояния дел), приоритетность (а по-сути очередность) и трудоемкость (оценивается обычно разработчиками), или другие параметры на свой выбор.
Что касается моей практики, то после оценки задач берем наиболее трудоемкую из наиболее приоритетных, когда она выполняется (разработка закончена) и переходит на другие стадии (тестирование), разработчики выполняют задачи из менее приоритетных (на ступень ниже)  и самые низкие по трудоемкости (сколько успеют сделать за время тестирования крупной задачи). и т.д.
Эта система позволяет постоянно держать нагрузку на все звенья разработки.

Высокоуровневых задач наверно 100-200,
а задач более низких уровней - несколько тысяч.

а действительно ли есть желание или необходимость следить лично за каждой из задач?

Ну вообщем-то каждая задача должна быть оценена (непосредственным исполнителем, заказчиком, тим лидом) как минимум по таким параметрам как: ... и трудоемкость (оценивается обычно разработчиками),

Что согласно статистическим исследованиям, приведет к снижению производительности в 1.5 - 2 раза. Смотри книгу "Peapleware". У Голдратта в "Критической цепи" приведено теоретическое обоснование для этих наблюдений.

Эта система позволяет постоянно держать нагрузку на все звенья разработки.

Что согласно "теории ограничений" совсем не хорошо.

Ну вообщем-то каждая задача должна быть оценена (непосредственным исполнителем, заказчиком, тим лидом) как минимум по таким параметрам как: критичность (на сколько критична эта задача в рамках текущего состояния дел), приоритетность (а по-сути очередность) и трудоемкость (оценивается обычно разработчиками), или другие параметры на свой выбор

То о чем вы сейчас говорите - это очень "горячо" - в смысле очень близко к тому ради чего я начинал тему.
Вы правильно говорите, что каждая задача должна быть оценена.
Я с вами согласен.

Мне даже кажется, что в управлении задачами именно это является самым важным - дать некие оценки задачам:
Дать такие оценки, которые бы позволили четко выделить как вы пишите "критичные" задачи из всего множества.
Когда есть эти оценки - дальше уже дело "техники" - выполнить самую критичную, проконтролировать и т. д.

Теперь возникает вопрос: как делать оценку задач? Какие признаки задач надо выделить, какие значения этих признаков рассматривать?
Вы говорите о "критичности" "приоритетности" и "трудоемкости".
Из них "критичность" и "приоритетность" - это уже результат оценки задачи, это не "первичные" признаки задач.

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

В упомянутом "Методе анализа иерархий" предлагается придумать какие-то критерии, назначить им коэффициенты, и т.д. В итоге получим числовую оценку "критичности".
То есть предлагается какой-то формальный подход.
А вы как делаете такие оценки?