Комментарии 14
Аналитики с дизайнерами, значит, появились. Okay.
Вообще-то странный у вас в примере CTO — как так выстроен рекрутинг, что он этого Серёжу не увидел в процессе найма???
Понимаю, что статья чисто рекламная, но… Чтобы чем то хорошо управлять — надо в деталях знать объект управления. Иначе — дефективный менеджмент. Те же сроки выполнения задач. Да, многие из них типовые и время рассчитать — не представляется проблемой, точнее — надо воспользоваться статистикой. Но разработка — это не 16 тонн угля в день. Иногда сложная задача идет «на ура», в 3 — 4 раза быстрее заложенного времени, а порой — простая вещь может отнять недели… Я, имея более 20 лет опыта, не всегда могу точно определить затраты даже для себя, для своих собственных задач в своих pet проектах. И абсолютно не представляю, как менеджить, например, химиков. Это — только про один ресурс.
Чуть-чуть присмотревшись к тому, чем занимаются тестеры, я могу сказать, что у них есть куда более важная роль, чем "ловить баги". Хороший тестер в команде — это архетипическая инвольвация идеального пользователя. Пользователя, который знает продукт насквозь, знает что он должен делать, знает что ожидать от продукта.
В крупных командах бывает так, что только тестеры знают о результате больше, чем пользователи. (Все остальные меньше, особенно, если сами его не используют).
Так что для технических продуктов тестеры — очень даже айтишники.
мало того, хороший тестер вполне может высказывать с 99% вероятностью причины «глюков» и способы их устранения. Особенно когда речь идет о сложных продуктах, в которых взаимодействуют, например, разные модули, написанные разными разработчиками. В этих случаях тестировщик, изучивший эту систему вдоль и поперек, начинает порой быть более полезен чем архитектор…
Почему для ПМ-а вы придумали новый термин?
Всё что вы рассказали про «scrum-мастер» — это задачи грамотного ПМа в команде:
конфликты между сотрудниками — ПМ
конфликты с руководством — ПМ/HR
профессиональное выгорание — ПМ/HR
адекватное и выполнимое планирование — ПМ
упрощение и ускорение рабочих встреч — ПМ
кооперация между различными отделами и подразделениями — тут сложнее, но это тоже по большей части ПМ
Что должен уметь скрам-мастер по сравнению с просто грамотным ПМ? Зачем здесь вообще скрам-кто-то как отдельный человек? Чтобы канбан доски уметь формировать?
Всё что вы рассказали про «scrum-мастер» — это задачи грамотного ПМа в команде:
конфликты между сотрудниками — ПМ
конфликты с руководством — ПМ/HR
профессиональное выгорание — ПМ/HR
адекватное и выполнимое планирование — ПМ
упрощение и ускорение рабочих встреч — ПМ
кооперация между различными отделами и подразделениями — тут сложнее, но это тоже по большей части ПМ
Что должен уметь скрам-мастер по сравнению с просто грамотным ПМ? Зачем здесь вообще скрам-кто-то как отдельный человек? Чтобы канбан доски уметь формировать?
ПМ — начальник
скрам-мастер — секретарь (чай, кофе, встречу организовать, табличку заполнить, желтые бумажки наклеить, уведомления разослать....)
скрам-мастер — секретарь (чай, кофе, встречу организовать, табличку заполнить, желтые бумажки наклеить, уведомления разослать....)
Скрам — это конкретная методология разработки. Каким боком тут чай/кофе и оганизация встречи? Таблички не может заполнять человек оторванный от разработки. То есть это всё равно либо ПМ, либо кто-то из разрабов.
Бумажки клеить и уведомления — действительно работа какого-нибудь секретаря, но при чем тут скрам?
Бумажки клеить и уведомления — действительно работа какого-нибудь секретаря, но при чем тут скрам?
Не совсем верно. РМ — это должность всё-таки, а scrum-мастер — роль, подразумевающая неплохую такую начитку и практику в методологиях управления коллективом, процессами и пр.
Верно. Вот только ПМ и должен быть этим «мастером». Благо в Скрам не то чтобы дофига сложностей, чтобы грамотный ПМ не смог их освоить за пару дней в базе и за пару недель глубоко.
Собственно именно потому, что скрам достаточно простая в своей основе штука — даже в этой статье большая часть задач скрам-мастера на самом деле задачи обычного ПМа и не связаны со скрамом.
Если бы честно написали задачи скрам-мастера не тасуя их с задачами ПМ — получился бы оченькоротки не впечатляющий список, по которому было бы очевидно, что для выполнения этих обязанностей не нужен отдельный человек(а он и не нужен, в рамках скрама разработчики и руководство достаточно равномерно и не много обязанностей на себя берут и всё начинает работать).
Собственно именно потому, что скрам достаточно простая в своей основе штука — даже в этой статье большая часть задач скрам-мастера на самом деле задачи обычного ПМа и не связаны со скрамом.
Если бы честно написали задачи скрам-мастера не тасуя их с задачами ПМ — получился бы оченькоротки не впечатляющий список, по которому было бы очевидно, что для выполнения этих обязанностей не нужен отдельный человек(а он и не нужен, в рамках скрама разработчики и руководство достаточно равномерно и не много обязанностей на себя берут и всё начинает работать).
Очень опрометчиво ставить тестировщиков и аналитиков в ряд людей, не связанных с кодом и не имеющих инженерного образования.
Честно говоря, я подумал, что это какая-то очень тонкая ирония и стеб. Но нет. На полном серъезе рекламируется польза отсутствия базовых инженерных навыков для работы на ключевых ИТ-должностях.
Бред какой-то.
Бред какой-то.
"Да и задачи выполняются бодро и в срок — не приходится ни подгонять, ни смотреть грозно взором командарма 1-ой Конной армии."
Панацею нашли
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Без «Hello, world!» и в IT?