Комментарии 14
Похоже у кого-то бага прямо в каждой фитче…
Re: «И руководитель проекта, стараясь устранить угрозу [срыва сроков] как можно раньше, озвучивает ее команде, а далее просто пытается ускорить процесс напутствующим словом и частным мониторингом.»
Такие менеджера напоминают новых русских из анекдота:
Купил «новый русский» Мерс. Начал заводить, а он не заводится. Ну вышел, взял тряпку, вытер лобовое стекло. Не заводится! Вышел, побил по колесам — все равно не заводится! Вышел, вытер фары — опять не заводится! Подъезжает такой же мерс. Выходит другой «новый русский» и спрашивает:
-Что, не заводится!?
-Нет.
-А ты стекло протирал?
-Протирал.
-Колеса бил?
-Да, бил, бил.
-А фары протирал?
-Протирал.
-Ну тогда тебе уже ничего не поможет.
Такие менеджера напоминают новых русских из анекдота:
Купил «новый русский» Мерс. Начал заводить, а он не заводится. Ну вышел, взял тряпку, вытер лобовое стекло. Не заводится! Вышел, побил по колесам — все равно не заводится! Вышел, вытер фары — опять не заводится! Подъезжает такой же мерс. Выходит другой «новый русский» и спрашивает:
-Что, не заводится!?
-Нет.
-А ты стекло протирал?
-Протирал.
-Колеса бил?
-Да, бил, бил.
-А фары протирал?
-Протирал.
-Ну тогда тебе уже ничего не поможет.
Ого, подобного рода аналитика УП редкость в хабе. Респект.
К слову, Парето можно использовать не только для анализа сдвига сроков, но и для анализа отклонений затрат и качества. Парето всем хорош, но только как анализ практически посмертный (т.е. когда уже есть отклонения) в случае одного проекта. Поэтому анализ такой стоило бы проводить в разрезе технологического (а не проектного) подразделения, для которого соответствующая деятельность на потоке, предупреждая проблемы тем самым в других проектах (Парето, как и любой статистический подход, хорошо работает там, где имеют место не уникальные обстоятельства).
К слову, Парето можно использовать не только для анализа сдвига сроков, но и для анализа отклонений затрат и качества. Парето всем хорош, но только как анализ практически посмертный (т.е. когда уже есть отклонения) в случае одного проекта. Поэтому анализ такой стоило бы проводить в разрезе технологического (а не проектного) подразделения, для которого соответствующая деятельность на потоке, предупреждая проблемы тем самым в других проектах (Парето, как и любой статистический подход, хорошо работает там, где имеют место не уникальные обстоятельства).
Спасибо за комментарий.
Согласна, если его проводить при завершении проекта (хотя и такой вариант бывает полезным). Но при итерационном подходе к проекту (хотя это и не поток), применение анализа оправдано. Во всяком случае у нас он показывает хорошие результаты.
Парето всем хорош, но только как анализ практически посмертный (т.е. когда уже есть отклонения) в случае одного проекта
Согласна, если его проводить при завершении проекта (хотя и такой вариант бывает полезным). Но при итерационном подходе к проекту (хотя это и не поток), применение анализа оправдано. Во всяком случае у нас он показывает хорошие результаты.
Выгдялит как подгон результата под несуществующий закон.
Прежде всего надо было установить корреляцию «успех проекта — количество багов в трекере», и стало бы понятно, что важность ваших факторов несколько преувеличена.
Я не знаю, кто у вас распределял почти 500 багов по категориям, но этот человек вряд ли был сильно доволен этой работой и отвлекался от основных обязанностей.
Прежде всего надо было установить корреляцию «успех проекта — количество багов в трекере», и стало бы понятно, что важность ваших факторов несколько преувеличена.
Я не знаю, кто у вас распределял почти 500 багов по категориям, но этот человек вряд ли был сильно доволен этой работой и отвлекался от основных обязанностей.
по-моему, из третьей таблицы все ясно уже
Главный вопрос — что с этими проблемами делать-то?
>1. Возникновение бага из-за недостатка времени на тестирование задачи;
Как, интересно, это определилось? Тестировщики сказали, что было мало времени?
> 2. Перерасход времени в связи с появлением багов при закрытии задачи;
И дальше что?
>3. Возникновение бага из-за невозможности тестирования фичи
Замечательная формулировка. Сразу возникает образ функционала, который невозможно использовать. Зачем вообще делать фичи, которые нельзя протестировать? Как это понимать?
>1. Возникновение бага из-за недостатка времени на тестирование задачи;
Как, интересно, это определилось? Тестировщики сказали, что было мало времени?
> 2. Перерасход времени в связи с появлением багов при закрытии задачи;
И дальше что?
>3. Возникновение бага из-за невозможности тестирования фичи
Замечательная формулировка. Сразу возникает образ функционала, который невозможно использовать. Зачем вообще делать фичи, которые нельзя протестировать? Как это понимать?
Приведенные факторы всего лишь частный случай одного из проектов. Для каждого проекта факторы (причины) будут своими и обычно не возникает препятствий, чтобы их определить. Как менеджер, так и команда с легкостью называют в чем были проблемы в общем, так и в частных случаях. Но если требуется пояснение по приведенным примерам (а нужно ли?!), то собственно смотрите ниже:
Собственно — да.
Данный фактор означал, что задачу закрыли, отдали на тестирование и в ней обнаружились ошибки.
Т.к. пример взят из игрового онлайн проекта, то были определенные сложности с моделированием определенных кейсов.
Для этого и нужен менеджер. Анализ показал на какие проблемы надо обратить внимание, а менеджер принимает решения каким способом будет их устранять.
>1. Возникновение бага из-за недостатка времени на тестирование задачи;
Как, интересно, это определилось? Тестировщики сказали, что было мало времени
Собственно — да.
> 2. Перерасход времени в связи с появлением багов при закрытии задачи;
И дальше что?
Данный фактор означал, что задачу закрыли, отдали на тестирование и в ней обнаружились ошибки.
>3. Возникновение бага из-за невозможности тестирования фичи
Замечательная формулировка. Сразу возникает образ функционала, который невозможно использовать. Зачем вообще делать фичи, которые нельзя протестировать? Как это понимать?
Т.к. пример взят из игрового онлайн проекта, то были определенные сложности с моделированием определенных кейсов.
Главный вопрос — что с этими проблемами делать-то?
Для этого и нужен менеджер. Анализ показал на какие проблемы надо обратить внимание, а менеджер принимает решения каким способом будет их устранять.
Да все эти проблемы есть в любом проекте. Анализ прямо скажем мало полезен такого рода. Выглядит как зря потраченное время. Тестировщики быстрее тестировать не начнут, в закрытых задачах практически всегда были и будут баги.
Если к этому подходить так, тогда действительно анализ не нужен. Но в такой случае для чего на проекте менеджер?! Программисты лучше писать код не будут, тестировщики быстрее работать не начнут.
Ну, а если серьезно, то для каждой конкретной проблемы есть варианты решения. Вспоминая, что «20% усилий дают 80% результата, а остальные 80% усилий — лишь 20%». Берем 20% и, к примеру, решаем проблему «Возникновение бага из-за невозможности тестирования фичи» тем, что тратим дополнительное время программистов, но предоставляем возможность тестировщикам искусственно моделировать кейсы. Время потраченное на реализацию сторицей окупится уменьшение времени на багфикс.
Ну, а если серьезно, то для каждой конкретной проблемы есть варианты решения. Вспоминая, что «20% усилий дают 80% результата, а остальные 80% усилий — лишь 20%». Берем 20% и, к примеру, решаем проблему «Возникновение бага из-за невозможности тестирования фичи» тем, что тратим дополнительное время программистов, но предоставляем возможность тестировщикам искусственно моделировать кейсы. Время потраченное на реализацию сторицей окупится уменьшение времени на багфикс.
>Но в такой случае для чего на проекте менеджер?!
И в самом деле. Может быть они не нужны?
>«20% усилий дают 80% результата, а остальные 80% усилий — лишь 20%»
С чего вы взяли, что это применимо для разработки ПО?
И в самом деле. Может быть они не нужны?
>«20% усилий дают 80% результата, а остальные 80% усилий — лишь 20%»
С чего вы взяли, что это применимо для разработки ПО?
Можете доказать обратное?
Вообще говоря не обязательно 80/20 — может быть 70/30 или 90/10. Это всего лишь название правила, а не конкретные числа. Но не суть. Вон в примере тоже не ровно 80/20.
Есть факторы определяющие выход системы в большей степени, чем другие. На вход подаются исходные условия, и какие-то из этих условий определенно больше влияют на отклонения. Факторы не влияют равномерно на результат, хотя бы потому что если бы они влияли равномерно, то все задачи отклонялись бы на равное количество единиц. То есть каждый фактор приводит к разным потерям, и Парето-анализ — всего лишь анализ совокупности потерь в разбивке по факторам. И разработка ПО, и конвейер с конфетами — с этой точки зрения одинаковые объекты. На входе одни объекты, идут их преобразования, на выходе измеряется уровень отклонений от целевых значений для преобразованных объектов.
Есть факторы определяющие выход системы в большей степени, чем другие. На вход подаются исходные условия, и какие-то из этих условий определенно больше влияют на отклонения. Факторы не влияют равномерно на результат, хотя бы потому что если бы они влияли равномерно, то все задачи отклонялись бы на равное количество единиц. То есть каждый фактор приводит к разным потерям, и Парето-анализ — всего лишь анализ совокупности потерь в разбивке по факторам. И разработка ПО, и конвейер с конфетами — с этой точки зрения одинаковые объекты. На входе одни объекты, идут их преобразования, на выходе измеряется уровень отклонений от целевых значений для преобразованных объектов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Применение диаграммы Парето для анализа причин отставания от графика разработки