Спасибо за ваше мнение. Вы совершенно правы, к самому манифесту вопросов никаких нет. Проблемы начинаются как раз таки с внедрением в конкретной компании.
Под клерками и бюрократами я подразумеваю крайние проявления некоторых управленческих ролей (посмотрите у Адизеса, замечательный автор). И крайние проявления: это несбалансированная команда, когда условно говоря один руководитель-клерк тащит одеяло на себя. Это не значит, что администраторы не нужны, напротив -- очень даже нужны, НО в сбалансированной команде.
Что же касается вашего субъективного восприятия моего опыта, я благодарна за ваше мнение, но все же считаю, что не обладая полным контекстом составить мой профессиональный портрет невозможно.
@Batalmvвы преследуете цель поделиться своим опытом или выразить недовольство? Если ваша цель — обмен опытом, то я готова пообщаться, если же вы хотели “указать на недостатки статьи”, то все, что я могу сделать — поблагодарить вас за потраченное время :)
Спасибо за вопросы. Отвечу по порядку: - Requirements freeze - это фиксация требований, необходимая для того, чтобы результат разработки не расходился с ожиданиями заказчика. - На какой срок предполагаете морозить требования - минимум на срок одной итерации.
Поделитесь, почему считаете, что это не работает? Интересно узнать ваш опыт
Это хорошая практика, делиться опытом важно как для роста внутри, так и снаружи команды. Главное не становиться менеджером-снежинкой, замкнув на себе все практики и знания. Члены команды должны быть равными носителями культуры .
Вы совершенно правы. Особенно «дни встреч» раздражают аналитиков, разработчиков и других специалистов, которые непосредственно претворяют в жизнь фичи, доработки и проекты. Для эффективности, как и говорила выше, недостаточно взять инструменты (например админа), у фасилитатора должен быть навык и авторитет, ну или умение этот авторитет наработать.
К сожалению, из моего опыта, это болезнь больших компаний. Когда не нужно выживать каждую секунду, люди расслабляются и получается хаос, из которого плодятся бесконечные встречи. Тут хорошо работает «главный продуктовый вопрос» — чтобы что? Встреча? Чтобы что? Минутки? Чтобы что? И так далее. Помогает держать фокус и не растекаться мыслью по древу
И навыка самоконтроля и самоорганизации у сотрудника
Спасибо за ваше мнение. Вы совершенно правы, к самому манифесту вопросов никаких нет. Проблемы начинаются как раз таки с внедрением в конкретной компании.
это "типа аджайл", т.е. темная сторона. Вообще порядка тридцати процентов задач на спринт принято выделять под фиксы.
Под клерками и бюрократами я подразумеваю крайние проявления некоторых управленческих ролей (посмотрите у Адизеса, замечательный автор). И крайние проявления: это несбалансированная команда, когда условно говоря один руководитель-клерк тащит одеяло на себя. Это не значит, что администраторы не нужны, напротив -- очень даже нужны, НО в сбалансированной команде.
Что же касается вашего субъективного восприятия моего опыта, я благодарна за ваше мнение, но все же считаю, что не обладая полным контекстом составить мой профессиональный портрет невозможно.
Я говорю в статье о том, что принимать решения нужно осознанно и на основе цифр. А не просто потому, что кто-то кому-то напел)
Буду рада, если приведете кейсы из своего опыта. Спасибо!
Добрый день. В статье я высказываю свое мнение. Если у вас есть другое – пожалуйста, пишите статью, указывайте его.
Из моего опыта, это не всегда работает. Замечательно, что вам повезло больше)
Спасибо за подробный рассказ о вашем опыте :)
@Batalmvвы преследуете цель поделиться своим опытом или выразить недовольство? Если ваша цель — обмен опытом, то я готова пообщаться, если же вы хотели “указать на недостатки статьи”, то все, что я могу сделать — поблагодарить вас за потраченное время :)
Спасибо за вопросы. Отвечу по порядку:
- Requirements freeze - это фиксация требований, необходимая для того, чтобы результат разработки не расходился с ожиданиями заказчика.
- На какой срок предполагаете морозить требования - минимум на срок одной итерации.
Поделитесь, почему считаете, что это не работает? Интересно узнать ваш опыт
Это хорошая практика, делиться опытом важно как для роста внутри, так и снаружи команды. Главное не становиться менеджером-снежинкой, замкнув на себе все практики и знания. Члены команды должны быть равными носителями культуры .
Спасибо, что рассказали о своем опыте работы
Вы совершенно правы. Особенно «дни встреч» раздражают аналитиков, разработчиков и других специалистов, которые непосредственно претворяют в жизнь фичи, доработки и проекты. Для эффективности, как и говорила выше, недостаточно взять инструменты (например админа), у фасилитатора должен быть навык и авторитет, ну или умение этот авторитет наработать.
К сожалению, из моего опыта, это болезнь больших компаний. Когда не нужно выживать каждую секунду, люди расслабляются и получается хаос, из которого плодятся бесконечные встречи. Тут хорошо работает «главный продуктовый вопрос» — чтобы что?
Встреча? Чтобы что?
Минутки? Чтобы что?
И так далее. Помогает держать фокус и не растекаться мыслью по древу
Это правда, если сам не делаешь, никто делать не будет. Как и с другими софтами, коммуникация – сложная штука, и оттачивать ее нужно всю жизнь.
Спасибо за комментарий, думаю, я продолжу рассказывать о софтах в разрезе работы менеджера.