Абсолютно согласен. Кроме одного: людям может быть тяжело воспринять "бизнес" как некую абстракцию, для них и подойдут фреймворки или ментальные модели.
Я никогда не рассматривал выступления как обязанность :) Это интересно мне самому, потому что я люблю делиться знаниями и мне приносит искреннее удовольствие выступать перед аудиторией. Доклады — точно не часть моей ежедневной работы.
Стресс бывает хорошим стимулом, зависит от степени влияния и продолжительности влияния на организм.
По поводу заучивания: если информация засела достаточно глубоко, то в момент стресса она никуда из головы не денется. Пропадают навыки, связанные с эксплицитной памятью и все такое. План это хорошо, но сухо, надо ж будет развернуть в моменте.
Привычно — не значит правильно :) Я конкретной ситуации не знаю и бросаться словами "у вас неправильно настроены процессы" как будто бы не с руки. Но я бы к ним присмотрелся на месте руководителей.
О правильность процесса можно сломать много копий. Мой взгляд: эффективнее наладить взаимодействие между командами и отделами, чем любое взаимодействие вести через руководителя.
Если у разработчика возникла необходимость получить помощь другой команды, например, допилить API их сервиса, то он может пойти и к тимлиду другой команды, и к линейному сотруднику. Оба могут на следующем PBR'е, груминге или даже дейлике внести таску в бэклог спринта (некоторые команды закладывают время на непредвиденные задачи в спринт) или заложить капасити на следующий спринт. Мы живем в мире распределенных систем, и сервисы взаимодействуют друг с другом — поэтому взаимодействие людей неизбежно. Как бы программист не продумал API сервиса, доработки и фиксы будут.
Такой подход работает быстрее, потому что меньше оверхэд на коммуникацию.
Такой подход снижает басфактор, потому что не все упирается в тимлида. Что если тимлид заболеет? Команда будет отрезана от внешнего мира, потому что контакты не налажены.
Такой подход расширяет знание самой команды о сервисах вне ее скоупа. Это полезно и для архитектуры, и в случае инцидента.
Такой подход поможет вырастить людей, которым интересен дальнейший рост в менеджмент.
Тогда, если задача оказалсь просрочена, то ответственный за это тимлид/менеджер другой команды, он не выполнил свои обязанности.
Мне удобнее считать, что за свою задачу отвечаю я, и самый заинтересованный в выполнении человек — тоже я. Менеджер другой команды может забыть, отвлечься, потерять блокнотик с записями, многое может произойти. Так что даже если часть моей задачи лежит в бэклоге другой команды, убедиться, что по ней есть прогресс должен тоже я. Главное, не возводить это в чайка-менеджмент и микро-контроль. Важна умеренность.
Не видите проблем в своей логике?
Искренне — нет. Не троллю :) Если более явно подсветите, будет здорово.
можно выстроить процессы так, чтобы этого не происходило.
Соглашусь, но только в определенных условиях. В реальной жизни команды меняются, компания может нанять целые отделы, которые еще не влились в выстроенные процессы. Тот же тимлид может уволиться и его преемнику потребуется время, чтобы влиться в процессы. Как бы не был крут онбординг, он займет время.
Я люблю повторять, что hope — is not a strategy (спер у гугла) и лучше убедиться, что задачу взяли в работу, чем надеятся, что ее взяли в работу. Тем более, если процессы хорошие, для этого достаточно просто зайти на доску команды и увидеть свою задачу в To Do и потом в In Progress. Это не займет более одной минуты. Тем более, что у любого процесса есть свои точки роста и абсолютного идеала, где все работает как часы, даже условная Toyota не достигла.
А вот тут мы подбираемся к вопросу о хорошем процессе поставки ценности. Если на сотруднике одновременно висит сразу несколько задач и это происходит регулярно, такой процесс нельзя назвать хорошим. Можно выставить WIP-лимит или ограничить поток входящих задач, потому что незавершенная работа — это яд, который постепенно разъедает проект.
И разводить руками менеджеру тут нельзя, его прямая задача — не допустить подобных ситуаций. Хорошего руководителя отличает понимание, что процессные проблемы — это именно его проблемы, и решать их надо ему. Но не любой блокер является процессной проблемой.
На интервью кампания смотрит кандидата, а кандидат — компанию. Если так получается, что в компании не принято брать ответственность за ошибки, а к самим ошибкам относятся как к чему-то непростительному и пытаются замести под ковер, для меня это стало бы красным флагом :)
Ошибка — это шанс стать лучше. Главное, чтобы одни и те же ошибки не повторялись из раза в раз, вот это действительно печально.
В общем, в этом и различие. Самонаводимый человек считает, что его работа — это доставить ценность клиенту.
А если для того, чтобы толкнуть задачу, нужны тимлиды и вышестоящее руководство, то это приведет к росту сроков и тонне лишней коммуникации на ровном месте.
Возможно, для кого-то удобнее список. Радар — это инструмент, и как любой инструмент его нужно использовать для решения определенных задач.
Если вы хотите просто доносить информацию о доступных инструментах до сотрудников, можно обойтись списком. Хотите улучшать инструменты, пробовать новые подходы, вовлекать весь коллектив в стандартизацию, горизонтальное распространять знания — радар.
Абсолютно согласен. Кроме одного: людям может быть тяжело воспринять "бизнес" как некую абстракцию, для них и подойдут фреймворки или ментальные модели.
Я никогда не рассматривал выступления как обязанность :) Это интересно мне самому, потому что я люблю делиться знаниями и мне приносит искреннее удовольствие выступать перед аудиторией. Доклады — точно не часть моей ежедневной работы.
Стресс бывает хорошим стимулом, зависит от степени влияния и продолжительности влияния на организм.
По поводу заучивания: если информация засела достаточно глубоко, то в момент стресса она никуда из головы не денется. Пропадают навыки, связанные с эксплицитной памятью и все такое. План это хорошо, но сухо, надо ж будет развернуть в моменте.
Привычно — не значит правильно :) Я конкретной ситуации не знаю и бросаться словами "у вас неправильно настроены процессы" как будто бы не с руки. Но я бы к ним присмотрелся на месте руководителей.
О правильность процесса можно сломать много копий. Мой взгляд: эффективнее наладить взаимодействие между командами и отделами, чем любое взаимодействие вести через руководителя.
Если у разработчика возникла необходимость получить помощь другой команды, например, допилить API их сервиса, то он может пойти и к тимлиду другой команды, и к линейному сотруднику. Оба могут на следующем PBR'е, груминге или даже дейлике внести таску в бэклог спринта (некоторые команды закладывают время на непредвиденные задачи в спринт) или заложить капасити на следующий спринт. Мы живем в мире распределенных систем, и сервисы взаимодействуют друг с другом — поэтому взаимодействие людей неизбежно. Как бы программист не продумал API сервиса, доработки и фиксы будут.
Такой подход работает быстрее, потому что меньше оверхэд на коммуникацию.
Такой подход снижает басфактор, потому что не все упирается в тимлида. Что если тимлид заболеет? Команда будет отрезана от внешнего мира, потому что контакты не налажены.
Такой подход расширяет знание самой команды о сервисах вне ее скоупа. Это полезно и для архитектуры, и в случае инцидента.
Такой подход поможет вырастить людей, которым интересен дальнейший рост в менеджмент.
Мне удобнее считать, что за свою задачу отвечаю я, и самый заинтересованный в выполнении человек — тоже я. Менеджер другой команды может забыть, отвлечься, потерять блокнотик с записями, многое может произойти. Так что даже если часть моей задачи лежит в бэклоге другой команды, убедиться, что по ней есть прогресс должен тоже я. Главное, не возводить это в чайка-менеджмент и микро-контроль. Важна умеренность.
Искренне — нет. Не троллю :) Если более явно подсветите, будет здорово.
Соглашусь, но только в определенных условиях. В реальной жизни команды меняются, компания может нанять целые отделы, которые еще не влились в выстроенные процессы. Тот же тимлид может уволиться и его преемнику потребуется время, чтобы влиться в процессы. Как бы не был крут онбординг, он займет время.
Я люблю повторять, что hope — is not a strategy (спер у гугла) и лучше убедиться, что задачу взяли в работу, чем надеятся, что ее взяли в работу. Тем более, если процессы хорошие, для этого достаточно просто зайти на доску команды и увидеть свою задачу в To Do и потом в In Progress. Это не займет более одной минуты. Тем более, что у любого процесса есть свои точки роста и абсолютного идеала, где все работает как часы, даже условная Toyota не достигла.
А вот тут мы подбираемся к вопросу о хорошем процессе поставки ценности. Если на сотруднике одновременно висит сразу несколько задач и это происходит регулярно, такой процесс нельзя назвать хорошим. Можно выставить WIP-лимит или ограничить поток входящих задач, потому что незавершенная работа — это яд, который постепенно разъедает проект.
И разводить руками менеджеру тут нельзя, его прямая задача — не допустить подобных ситуаций. Хорошего руководителя отличает понимание, что процессные проблемы — это именно его проблемы, и решать их надо ему. Но не любой блокер является процессной проблемой.
На интервью кампания смотрит кандидата, а кандидат — компанию. Если так получается, что в компании не принято брать ответственность за ошибки, а к самим ошибкам относятся как к чему-то непростительному и пытаются замести под ковер, для меня это стало бы красным флагом :)
Ошибка — это шанс стать лучше. Главное, чтобы одни и те же ошибки не повторялись из раза в раз, вот это действительно печально.
В общем, в этом и различие. Самонаводимый человек считает, что его работа — это доставить ценность клиенту.
А если для того, чтобы толкнуть задачу, нужны тимлиды и вышестоящее руководство, то это приведет к росту сроков и тонне лишней коммуникации на ровном месте.
За весь Купер не отвечу, у меня из ста человек в год уходило по 2-3 в среднем.
У вас, вероятно, очень большой опыт, судя по тону решений. Если не секрет, где вы его приобрели и на каких успешных проектах?
Доводы бывают разными, но главный довод "Ну парни, ну надо". К сожалению, не все выполняют правило "не добавлять таски в спринт".
Если сможете привести пример своей реализации, будет круто :)
В нашем случае угол не имеет значения.
Возможно, для кого-то удобнее список. Радар — это инструмент, и как любой инструмент его нужно использовать для решения определенных задач.
Если вы хотите просто доносить информацию о доступных инструментах до сотрудников, можно обойтись списком. Хотите улучшать инструменты, пробовать новые подходы, вовлекать весь коллектив в стандартизацию, горизонтальное распространять знания — радар.