Обоснование, чтобы выдернуть универсала разработчика приведено в том же куске статьи.
Мне искренне жаль, если моя статья Вас задела. Возможно, это связано с Вашим личным негативным опытом.
И я не вижу смысла Вас разубеждать искать скрытый подтекст, которого нет)
Это возникает из-за того, что при проведении оценки по своей неосновной компетенции могут быть заложены неверные сроки, что приводит к переоценке и сдвигу сроков.
Проблемы «замалчивания нюансов» это не решает.
Позвольте спросить, а у Вас в команде есть отдельные ставки людей экспертов по аналитике и тестированию, досконально знающие все направления, продукты и сервисы, бизнес процесс в конце концов.
Универсалы, это члены команды, занимающие в ней особое место. Вы правы, можно расписать эти типы и про аналитиков, и про разработчиков, и про тестировщиков. Цель данной статьи, попытаться раскрыть понятие универсалов, их категоризировать и показать их слабые и сильные стороны, описать возможные проблемы и предложить к обсуждению возможные варианты решений.
Про bus фактор — если есть универсал, то он повышается. Для его снижения принимаются меры, общими словами описанные в соответствующем разделе статьи.
Посмотрите пожалуйста прошлые комментарии, кого я понимаю под универсалами, и под непрофильной = несвойственной работой.
Те цитаты, которые Вы приводите, всего лишь литературный оборот, не более. Повторюсь, что с появлением срочной задачи, другие задачи у сотрудника сдвигаются. Термин «использование универсалов » упоминается в контексте «использование ресурсов».
Не бывает неинтересных задач- работая над каждой задачей можно почерпнуть что-то новое. Есть отсутствие желания. Человек, желающий развивать свои компетенции может и хочет работать с любой задачей, даже с рутинной ( если Вы вкладываете такое понятие в «неинтересные»). К каждому сотруднику можно найти подход, зная его мотивацию.
Как уже писала выше, акцент был сделан на выявление недостатков и как с ними можно работать (т.к., преимущества универсалов известны), поэтому у Вас могло сложиться обманчивое впечатление.
В разделе «Выводы» подведён итог в части + и — использования универсалов — это Общий вывод, а в разделе «что получилось», результаты конкретных действий по приведённым примерам.
Я всегда на стороне команды, прежде чем принимать решение о необходимости выполнения срочной задачи (если это не требование регулятора), с бизнесом обсуждается целесообразность, возможные альтернативы.
Но мы все понимаем, какова степень влияния представителей бизнеса на команду разработки. Самое главное мы должны понимать для чего это делаем, если понимания нет, то находим контр аргументы для отказа бизнесу.
Срочность и иногда внезапность задач у нас обусловлена двумя факторами: 1. Требованиями регулятора, 2. Требованиями бизнеса.
Более срочная задача вытесняет менее срочные, происходит переприоритезация бэклога.
Под “bus фактором», я понимаю сосредоточение знаний, компетенций в голове у отдельно взятого специалиста. И глобальная цель -уменьшение этого фактора, так скажем, «расшивание компетенций».
К сожалению не все можно предусмотреть, например, нельзя предусмотреть болезнь сотрудника.
Кроме того, наша специфика связана с выполнением задач, связанных с требованиями регулятора, которые очень часто приходят внезапно.
Возможно, это было не совсем понятно из текста статьи: но разбор ошибок с командой, анализ и соответствующую интерпретацию проводит менеджер. Но это не происходит отдельно от участников команды. Работает принцип открытости и доверия.
Эта карта заполняется именно теми, кто принимал участие в решении задачи. Она необходима для того, чтобы разобраться на каком этапе произошёл возможный косяк. И при совместном обсуждении перерождается в понимание истинной причины и того, что нужно усовершенствовать в следующий раз тому или иному человеку.
Если ошибка очень значительная и привела к простою ИС, то к обсуждению привлекаются другие эксперты.
Сразу оговорюсь, что универсал не может быть новичком, это люди уровня мидл, сеньор, уже зарекомендовавшие себя в роли универсала. К таким специалистам очень высок уровень доверия.
Вероятно, Вы сформировали такое мнение, т.к., для того, чтобы показать недостатки в работе универсалов (о преимуществах итак всем известно), я привела примеры, в которых описала узкие места. О том, кого я понимаю под универсалами, я ответила в предыдущем комментарии.
Также, возможно не хватило вводных, поэтому поясню.
Безусловно, когда речь идёт о необходимости выполнения новой задачи, тем более срочной, остальные задачи сдвигаются и человек занимается новой задачей ( либо одним либо несколькими последовательными этапами, как универсал)
Задачи даются человеку только, если он обладает необходимыми компетенциями ( хорошо знаком с направлением, продуктом, ранее писал тз/кодил/тестировал по этому сервису/продукту)
Контроль качества по этапам присутствует. Но здесь речь идёт о том, что в силу особенностей типа личности, наличия необходимого инструментария, компетенций, может происходить «замалчивание нюансов» в тз, пренебрегание правилами, и т.д. Это может быть и узкого специалиста, но если один и тот же специалист выполняет всю задачу, риск выше.
Вчитываться в каждое тз, проверять чек-листы и ревьювить код не по силам техлиду из команды в 12 человек. Конечно, в серьезных проектах предлагаемое решение выносится на экспертный совет. Но при решении рутинных задач достаточно информации с митинга и репутации члена команды.
Также, отмечу, что успешный результат в двух приведённых примерах, это заслуга именно тех, кто работал над задачей и довёл ее до конца.
Это определение отражает третий тип личности универсала, описанный в статье, но Вы отчасти правы — в условиях ограниченности ресурсов может трактоваться именно так, но в этом нет ничего предосудительного.
Как раз в статье я попыталась показать сильные и слабые стороны каждого типа, зная которые можно найти подход по эффективному совмещению ролей и выстраиванию процесса работы с человеком.
Универсал — это человек имеющий свою основную узкую специализацию и приобретённые дополнительные специализации в процессе своего опыта работы в компании.
И вовсе не обязательно, что работа универсала будет выполнена плохо.
И каждому узкому специалисту свойственно ошибаться, просто если заниматься работой, не свойственной для себя работой, то какие-то моменты могут быть упущены(под несвойственной подразумевается: писать ТЗ разработчику, который способен сам взаимодействовать с заказчиком, собрать, формализовать и понять требования заказчика ). Однако, при этом может получиться вполне нормальный продукт, но если бы соблюдалось разделение ролей, то с большей вероятностью, можно получить более высокий результат.
«Мозговой штурм» нужен для того, чтобы разобраться в причинах проблем, предложить идеи, как можно этого избежать, закрепить дальнейшие действия и как результат улучшить свою работу, а НЕ найти и наказать виноватых.
Универсалов нужно беречь и помогать им выявить слабые места и попытаться развить их или отказаться от использования такого «универсала». Обычно, истинные универсалы заинтересованы в своём развитии, тк бесспорно ценятся в команде выше.
Обоснование, чтобы выдернуть универсала разработчика приведено в том же куске статьи.
Мне искренне жаль, если моя статья Вас задела. Возможно, это связано с Вашим личным негативным опытом.
И я не вижу смысла Вас разубеждать искать скрытый подтекст, которого нет)
Это возникает из-за того, что при проведении оценки по своей неосновной компетенции могут быть заложены неверные сроки, что приводит к переоценке и сдвигу сроков.
Проблемы «замалчивания нюансов» это не решает.
Позвольте спросить, а у Вас в команде есть отдельные ставки людей экспертов по аналитике и тестированию, досконально знающие все направления, продукты и сервисы, бизнес процесс в конце концов.
С кодревью все понятно, а остальное очень спорно.
Универсалы, это члены команды, занимающие в ней особое место. Вы правы, можно расписать эти типы и про аналитиков, и про разработчиков, и про тестировщиков. Цель данной статьи, попытаться раскрыть понятие универсалов, их категоризировать и показать их слабые и сильные стороны, описать возможные проблемы и предложить к обсуждению возможные варианты решений.
Как уже писала выше, акцент был сделан на выявление недостатков и как с ними можно работать (т.к., преимущества универсалов известны), поэтому у Вас могло сложиться обманчивое впечатление.
В разделе «Выводы» подведён итог в части + и — использования универсалов — это Общий вывод, а в разделе «что получилось», результаты конкретных действий по приведённым примерам.
Отдельного флоу нет, все в рамках эджайла.
Я всегда на стороне команды, прежде чем принимать решение о необходимости выполнения срочной задачи (если это не требование регулятора), с бизнесом обсуждается целесообразность, возможные альтернативы.
Но мы все понимаем, какова степень влияния представителей бизнеса на команду разработки. Самое главное мы должны понимать для чего это делаем, если понимания нет, то находим контр аргументы для отказа бизнесу.
Срочность и иногда внезапность задач у нас обусловлена двумя факторами: 1. Требованиями регулятора, 2. Требованиями бизнеса.
Более срочная задача вытесняет менее срочные, происходит переприоритезация бэклога.
Спасибо, что поделились своим мнением и привели аргументы. Было очень интересно читать Ваш пост, он описывает насущные проблемы.
Под “bus фактором», я понимаю сосредоточение знаний, компетенций в голове у отдельно взятого специалиста. И глобальная цель -уменьшение этого фактора, так скажем, «расшивание компетенций».
Как уже писала в комментариях выше, цель статьи иная. Не поиск виноватых и их наказание, а выявлении проблем и поиска их решения
К сожалению не все можно предусмотреть, например, нельзя предусмотреть болезнь сотрудника.
Кроме того, наша специфика связана с выполнением задач, связанных с требованиями регулятора, которые очень часто приходят внезапно.
Возможно, это было не совсем понятно из текста статьи: но разбор ошибок с командой, анализ и соответствующую интерпретацию проводит менеджер. Но это не происходит отдельно от участников команды. Работает принцип открытости и доверия.
Эта карта заполняется именно теми, кто принимал участие в решении задачи. Она необходима для того, чтобы разобраться на каком этапе произошёл возможный косяк. И при совместном обсуждении перерождается в понимание истинной причины и того, что нужно усовершенствовать в следующий раз тому или иному человеку.
Если ошибка очень значительная и привела к простою ИС, то к обсуждению привлекаются другие эксперты.
Сразу оговорюсь, что универсал не может быть новичком, это люди уровня мидл, сеньор, уже зарекомендовавшие себя в роли универсала. К таким специалистам очень высок уровень доверия.
Вероятно, Вы сформировали такое мнение, т.к., для того, чтобы показать недостатки в работе универсалов (о преимуществах итак всем известно), я привела примеры, в которых описала узкие места. О том, кого я понимаю под универсалами, я ответила в предыдущем комментарии.
Также, возможно не хватило вводных, поэтому поясню.
Вчитываться в каждое тз, проверять чек-листы и ревьювить код не по силам техлиду из команды в 12 человек. Конечно, в серьезных проектах предлагаемое решение выносится на экспертный совет. Но при решении рутинных задач достаточно информации с митинга и репутации члена команды.
Также, отмечу, что успешный результат в двух приведённых примерах, это заслуга именно тех, кто работал над задачей и довёл ее до конца.
Это определение отражает третий тип личности универсала, описанный в статье, но Вы отчасти правы — в условиях ограниченности ресурсов может трактоваться именно так, но в этом нет ничего предосудительного.
Как раз в статье я попыталась показать сильные и слабые стороны каждого типа, зная которые можно найти подход по эффективному совмещению ролей и выстраиванию процесса работы с человеком.
Универсал — это человек имеющий свою основную узкую специализацию и приобретённые дополнительные специализации в процессе своего опыта работы в компании.
И вовсе не обязательно, что работа универсала будет выполнена плохо.
И каждому узкому специалисту свойственно ошибаться, просто если заниматься работой, не свойственной для себя работой, то какие-то моменты могут быть упущены(под несвойственной подразумевается: писать ТЗ разработчику, который способен сам взаимодействовать с заказчиком, собрать, формализовать и понять требования заказчика ). Однако, при этом может получиться вполне нормальный продукт, но если бы соблюдалось разделение ролей, то с большей вероятностью, можно получить более высокий результат.
«Мозговой штурм» нужен для того, чтобы разобраться в причинах проблем, предложить идеи, как можно этого избежать, закрепить дальнейшие действия и как результат улучшить свою работу, а НЕ найти и наказать виноватых.
Универсалов нужно беречь и помогать им выявить слабые места и попытаться развить их или отказаться от использования такого «универсала». Обычно, истинные универсалы заинтересованы в своём развитии, тк бесспорно ценятся в команде выше.