Мне очень понравилось как вы вводили концепции из книги, что сначала внедряли среди early adopters и потом далее по команде.
У меня был странный опыт, когда на работе внедряли концепции из книги Radical Candor Ким Скотт. Там было все просто- все прочитали и начнем со следующей недели.
Так как не было четко разъяснено, как мы в компании понимаем концепции книги, то народ пошел кто в лес, а кто по дрова, в основном налегая на честный и брутальный фидбек и начался такой хаос, что дольше трех месяцев концепция не продержалась 😂
Я буду думать над вашим опытом и снова вернусь к Ленсиони- аж перечитать захотелось. Спасибо!
Интересная статья и дискуссия. Очень понравилось про птиц, которые поют ночью, чтобы их не заглушали машины и с одной стороны я с этими соглашусь. А с другой- я просыпаюсь в 4.30 утра. Сама. Каждый день.
Мне проще и удобнее поработать именно с 5-7 утра, когда все спят и никто не отвлекает. Знаю разработчиков, которые совы и до 11 вечера им не думается. В рабочее время они занимаются руководством и админом, а ночью начинают кодить. Хорошо это или плохо- не знаю, но асинхронная коммуникация и работа из дома дают нам такую возможность ь и почему бы этим не пользоваться?
Я стараюсь учитывать биологические часы в своей команде, не всегда конечно получается. А с другой стороны, чаще всего разработчики срочно нужны когда что-то поломалась и не работает, текущие задачи запланированы и снесли сдаются в срок с документацией- то хоть во сколько пусть делают
Большое спасибо за интересную статью, но хотела бы добавить от себя несколько моментов в защиту проектного подхода:
Проектный и продуктовый подходы не взаимоисключающие
Проектный подход хорош для проектов, которые инициированы юридическими нуждами - PCI DSS или GDPR. Никакие итерации и улучшения не спасут тебя, если через месяц ты должен предоставить аудитору продукт, который изменён под требования, например, PSI DSS (тут классно сработает обратный отчёт и хороший проджект). Тут или пан или пропал и даже ИТ компании должны резко меняться в связи с изменениями юридических фреймворков с тем, чтобы их продукт соответствовал требованиям.
Если в компании низкий уровень дисциплины, то продуктовый подход сулит риски погрязнуть в бесконечных тестах и неконтролируемых изменениях и пока бизнес постоянно внедряет их в продукт, пользователь идёт к более стабильным конкурентам, потому что такое количество изменений- это для него слишком. Я такое видела в индустрии азартных игр, когда одно серое казино мотало из стороны в сторону и они выдавали по новой казино фиче минимум раз в месяц
Когда в компании нет нормальных тулов, дисциплины и навыков для планирования работы и работы с метриками, то может статься и такое, что 4 команды внедряют изменения в продукт для улучшения той или иной метрики. Итог- никому не понятно, что же всё-таки улучшило показатели 😂
Конечно, последние два примера это из области не самых эффективных компаний, но они существуют и на мой взгляд этим ребятам продуктовый подход внедрять очень опасно.
Короче, в целом согласна с вашей статьей, действительно классно и очень аргументированное написано, но все равно решила немного подискутировать 😂
Большое спасибо за статью- было интересно прочитать. Согласна с тем, что надо улучшать эффективные качества, но и о неэффективных тоже нельзя забывать, иначе это может сильно ударить в будущем.
У меня всегда неэффективным качеством и была сложность уволить неподходящего человека, старалась не думать о том, как научиться увольнять четко и чисто. Итог- пришлось увольнять сотрудника со скандалом и в очень Официальном ключе чтобы избежать судебного иска.
Я стала умнее- изучила лучшие практики по этому вопросу и, хотя стараюсь избежать увольнений, если это возможно, более свободно чувствую себя в процессе увольнения сотрудников. Более того, летом уволила контент менеджера, но помогла ему с разбором причин и его карьерных планов. Сейчас он завязал с it и работает в продажах- очень счастлив и доволен, что я тогда лишила его нелюбимого, но насиженного места.
У меня был начальник, который ввел правило, что все сотрудники должны быть доступны для звонка в течение дня и если ты не отвечаешь- ты не на своем рабочем месте и тебе прилетает штраф.
Я занималась проектами и постоянно прерывалась на совершенно дикие звонки от начальника и секретаря, которые проверяли наличие сотрудника на рабочем месте.
Выдержала 2 месяца- невозможно работать с документацией, когда тебя постоянно прерывают и говорят, что просто проверяют, работаешь ли ты 😂
Очень классно! Спасибо!
Мне очень понравилось как вы вводили концепции из книги, что сначала внедряли среди early adopters и потом далее по команде.
У меня был странный опыт, когда на работе внедряли концепции из книги Radical Candor Ким Скотт. Там было все просто- все прочитали и начнем со следующей недели.
Так как не было четко разъяснено, как мы в компании понимаем концепции книги, то народ пошел кто в лес, а кто по дрова, в основном налегая на честный и брутальный фидбек и начался такой хаос, что дольше трех месяцев концепция не продержалась 😂
Я буду думать над вашим опытом и снова вернусь к Ленсиони- аж перечитать захотелось. Спасибо!
Интересная статья и дискуссия. Очень понравилось про птиц, которые поют ночью, чтобы их не заглушали машины и с одной стороны я с этими соглашусь. А с другой- я просыпаюсь в 4.30 утра. Сама. Каждый день.
Мне проще и удобнее поработать именно с 5-7 утра, когда все спят и никто не отвлекает. Знаю разработчиков, которые совы и до 11 вечера им не думается. В рабочее время они занимаются руководством и админом, а ночью начинают кодить. Хорошо это или плохо- не знаю, но асинхронная коммуникация и работа из дома дают нам такую возможность ь и почему бы этим не пользоваться?
Я стараюсь учитывать биологические часы в своей команде, не всегда конечно получается. А с другой стороны, чаще всего разработчики срочно нужны когда что-то поломалась и не работает, текущие задачи запланированы и снесли сдаются в срок с документацией- то хоть во сколько пусть делают
Большое спасибо за интересную статью, но хотела бы добавить от себя несколько моментов в защиту проектного подхода:
Проектный и продуктовый подходы не взаимоисключающие
Проектный подход хорош для проектов, которые инициированы юридическими нуждами - PCI DSS или GDPR. Никакие итерации и улучшения не спасут тебя, если через месяц ты должен предоставить аудитору продукт, который изменён под требования, например, PSI DSS (тут классно сработает обратный отчёт и хороший проджект). Тут или пан или пропал и даже ИТ компании должны резко меняться в связи с изменениями юридических фреймворков с тем, чтобы их продукт соответствовал требованиям.
Если в компании низкий уровень дисциплины, то продуктовый подход сулит риски погрязнуть в бесконечных тестах и неконтролируемых изменениях и пока бизнес постоянно внедряет их в продукт, пользователь идёт к более стабильным конкурентам, потому что такое количество изменений- это для него слишком. Я такое видела в индустрии азартных игр, когда одно серое казино мотало из стороны в сторону и они выдавали по новой казино фиче минимум раз в месяц
Когда в компании нет нормальных тулов, дисциплины и навыков для планирования работы и работы с метриками, то может статься и такое, что 4 команды внедряют изменения в продукт для улучшения той или иной метрики. Итог- никому не понятно, что же всё-таки улучшило показатели 😂
Конечно, последние два примера это из области не самых эффективных компаний, но они существуют и на мой взгляд этим ребятам продуктовый подход внедрять очень опасно.
Короче, в целом согласна с вашей статьей, действительно классно и очень аргументированное написано, но все равно решила немного подискутировать 😂
Большое спасибо за статью- было интересно прочитать. Согласна с тем, что надо улучшать эффективные качества, но и о неэффективных тоже нельзя забывать, иначе это может сильно ударить в будущем.
У меня всегда неэффективным качеством и была сложность уволить неподходящего человека, старалась не думать о том, как научиться увольнять четко и чисто. Итог- пришлось увольнять сотрудника со скандалом и в очень Официальном ключе чтобы избежать судебного иска.
Я стала умнее- изучила лучшие практики по этому вопросу и, хотя стараюсь избежать увольнений, если это возможно, более свободно чувствую себя в процессе увольнения сотрудников. Более того, летом уволила контент менеджера, но помогла ему с разбором причин и его карьерных планов. Сейчас он завязал с it и работает в продажах- очень счастлив и доволен, что я тогда лишила его нелюбимого, но насиженного места.
У меня был начальник, который ввел правило, что все сотрудники должны быть доступны для звонка в течение дня и если ты не отвечаешь- ты не на своем рабочем месте и тебе прилетает штраф.
Я занималась проектами и постоянно прерывалась на совершенно дикие звонки от начальника и секретаря, которые проверяли наличие сотрудника на рабочем месте.
Выдержала 2 месяца- невозможно работать с документацией, когда тебя постоянно прерывают и говорят, что просто проверяют, работаешь ли ты 😂