Comments 2
Интересный тезис про ответственность за результат и принятие ошибок. По опыту действительно непросто сообщить об ошибке или признать ошибку. В статье есть скрин как это может выглядеть на уровне эксперта. Интересно как принцип применяется на уровне менеджмента, например, как обычно поступают техлиды, чтобы поддерживать данный принцип у ребят? Ведь у них наверняка есть противоречие: ошибка = "плохо" (в том числе пред заказчиком или руководителем), с другой стороны ошибка действительно может способствовать развитию.
Ещё интересный тезис про роли и в частности документацию.
Про роли: кажется часто новичок может иметь потребность в определении роли за него, поскольку нуждается в помощи в этом вопросе, так как неопределённость велика и предложенный вариант с волонтёрством или выбором предложений от техлидов может быть не простой задачей. Как тогда поступаете?
Про документацию: "есть ребята, что совсем не любят писать документацию, при этом все задачи выполняют очень качественно. Мы по максимуму освободили их от писанины", - пример показался рисковым, так как будут те, кто делают что-то "классное" и те, кто делает что-то типа "писанина". И ещё цитата: "на потом мы откладываем работу с документацией. «Потом» наступает, когда задач мало", - выглядит как отложенная работа с техдолгом; в народе говорят, что техдолг лучше не накапливать... Возможно детальнее можете пояснить свой пример, картинка пока не сложилась, но заинтересовало (может это команды формата Джордан + Пипен, если уместна такая аналогия).
В моём случае стараюсь в замен предлагать принцип сервиса "под ключ": чтобы работа была сделана качественно и полноценно, надо быть готовым решить в том числе рутинные задачи, не только сливки собирать.
Добрый день! Спасибо за комментарий и вопросы :))
Интересный тезис про ответственность за результат и принятие ошибок. По опыту действительно непросто сообщить об ошибке или признать ошибку. В статье есть скрин как это может выглядеть на уровне эксперта. Интересно как принцип применяется на уровне менеджмента, например, как обычно поступают техлиды, чтобы поддерживать данный принцип у ребят? Ведь у них наверняка есть противоречие: ошибка = "плохо" (в том числе пред заказчиком или руководителем), с другой стороны ошибка действительно может способствовать развитию.
Мы обычно проговариваем на планерках, что ошибка - это нормальный рабочий процесс, главное ошибаться всегда в чем-то разном. И после ошибки, обязательно проговариваем, что мы вынесли из неё, и ошибка уже выглядит не как ошибка, а как полученный и усвоенный урок, а это уже выглядит совершенно иначе.
Про роли: кажется часто новичок может иметь потребность в определении роли за него, поскольку нуждается в помощи в этом вопросе, так как неопределённость велика и предложенный вариант с волонтёрством или выбором предложений от техлидов может быть не простой задачей. Как тогда поступаете?
Перефразирую Ленина: Пробуем. Пробуем. Пробуем.
Про документацию: "есть ребята, что совсем не любят писать документацию, при этом все задачи выполняют очень качественно. Мы по максимуму освободили их от писанины", - пример показался рисковым, так как будут те, кто делают что-то "классное" и те, кто делает что-то типа "писанина".
Всегда будут те, те, кто делают что-то "классное" и те, кто делает что-то типа "писанина". Мы тех, кто делает "писанину", растим до "делают что-то "классное".
И ещё цитата: "на потом мы откладываем работу с документацией. «Потом» наступает, когда задач мало", - выглядит как отложенная работа с техдолгом; в народе говорят, что техдолг лучше не накапливать... Возможно детальнее можете пояснить свой пример, картинка пока не сложилась, но заинтересовало (может это команды формата Джордан + Пипен, если уместна такая аналогия).
Сейчас задач мало практически не бывает. Поэтому мы внедрили практику выделять 1 день в неделю на техдолг.
Работа в идеальной команде по версии «Автомакон»: как создать, а главное – не сломать