Спасибо за комментарий. Я допускал вопрос про стоимость часа. Надо еще учесть что там был CEO и другие руководители. Плюс, если бы я сделал без подготовки, то все 10 минут были бы бессмысленны в принципе. Т.е. по факту, вместо 10 минут в пустую, 3.5 минуты имели конкретную цель. Еще, это я решил впервые выступить в таком формате, многое переосмыслил и в следующий раз это займет не более часа, а дальше еще меньше.
Основные идеи выделены в каждом разделе. Но без общего контекста они читаются сухо. Кому-то важен контекст. Но в целом, согласен. В следующий раз минимум в два раза короче статью сделаю.
10 человек в прямом подчинении - это действительно сложно.
За 2 недели человек может:
Устать от перегрузки в связи с какой-то задачей, обстоятельством или наложением личных проблем, недовольством кем-то из коллег, которые сотрудник не готов публично озвучивать. Первое с чего мы начинаем встречу - проясняем состояние. Мы держим руку на пульсе, чтобы не допустить выгорание.
Сотрудник может накопить вопросы и темы для обсуждения. Часто люди хотят о чем-то рассказать и получить обратную связь. Озвучить идеи, которые так же не решаются обсудить с командой.
Это возможность руководителю дать обратную связь, о чем-то важном рассказать или обсудить.
И да, бывают случаи, когда мы встречаемся раз в месяц. Вот только это одна 30-минутная встреча, посвященная сотруднику вместо множества мелких отвлечений, которые в совокупности могут привести к большим затратам.
Здесь согласен. Тут уже больше к руководству, считают ли они нормальным, что архитектор отвлекается на митинги, снижая производительность.
Вот прямо сегодня один из трех девелопмент менеджеров попросился на наш митинг, об оптимизации которого я говорил, т.к. тема пересекается с тем, за что он отвечает. Он тоже в таком формате был - работал) Но не думаю что это продуктивно. Будем решать, может ему проще получить какой-то сводный отчет о чем говорили и что решили, чем тратить время.
Очень здорово у вас регламентировано! Я бы тоже за такой формат, но команды хотят встречаться хотя бы виртуально раз в день. У нас удаленка. Вы в офисе работает или удаленно?
Привет! В проектах важно планировать на будущее и быть предсказуемыми. Простое добавление задачи в бэклог не решает проблему. Нужно либо выполнить задачу, либо решить не делать её вовсе. Если задача важна, но не выполняется, следует обсудить отмену, повышение приоритета или необходимость дополнительных ресурсов. Все задачи в бэклоге должны быть рассмотрены, так как их добавление изначально подразумевало важность. Обсуждение отмены может выявить ранее незамеченные аспекты задачи. Возможно, то что кажется важным кому-то, после прояснения потеряет свою важность. Тот кто заводит задачу, может просто не знать весь контекст. Я ответил на вопрос?
Отлично, что вам приглянулась идея! Будет непросто, но результат того стоит. Вопрос как подобное внедрять со стороны разработчиков в сторону менеджеров стоит отдельной статьи. Удачи!
Я бы дал два лайка, если бы это было возможно! Да, я действительно стараюсь поступать так и учу этому своих ребят. Иногда понимаешь, что решать задачу напролом — неэффективно или слишком затратно. Но проходит месяц, а то и неделя, ты читаешь статью или что-то ещё, и вдруг — бац! — приходит идея. И оказывается, что проблему можно решить гораздо проще или как-то иначе. Правда, по моему опыту, ОБЩИЙ бэклог для таких случаев не подходит. А вот личный — да, тот самое то.
Если автор комментария имел в виду, что у тимлида есть право принимать решения, то согласен. Но даже это право требует учета множества факторов, в том числе мнений коллег. Комментарий создает впечатление описания токсичной атмосферы "менеджеры против разработчиков". Был в такой ситуации как со стороны менеджмента, так и со стороны разработчика и понял: это неприятно. Больше не хочу в этом участвовать и не советую другим.
Про два статуса я не до конца понял, что вы имеете в виду. Если вы про "не приоритетно" и про "отмену", то статья скорее про то, что то, что не приоритетно, периодически надо переводить в "отмену". Это важно с позиции управления ожиданиями. Я тут привёл пример про то, как это влияет на команду, но с другой стороны есть бизнес. У него тоже свои ожидания. Если нет прозрачной системы, которая позволяет предсказать, будет ли выполняться задача и если будет, то когда, то представители бизнеса, например сейлзы, тоже замучают вопросами. И вместо работы менеджер, как савраска, будет весь в совещаниях. Т.е. есть категория задач, которая да, нужна, но делать не будем.
Тимлид не всегда является верховным руководителем разработки, и во многих организациях над ним могут стоять вышестоящие технические руководители, такие как начальники разработки или CTO.
У нас, например, с января практически ни одной фичи не написали и это стоило немалых усилий. Приходилось общаться, договариваться и объяснять. Ключевое - договариваться и продавать важность изменений, объяснять их с точки зрения бизнеса.
Если же возникает мысль о необходимости полного игнорирования мнений других и одностороннего принятия решений, это может быть сигналом к переосмыслению своего места в компании и поиску более подходящей рабочей среды, где будет цениться совместное принятие решений и командная работа.
Спасибо за комментарий. Я допускал вопрос про стоимость часа. Надо еще учесть что там был CEO и другие руководители. Плюс, если бы я сделал без подготовки, то все 10 минут были бы бессмысленны в принципе. Т.е. по факту, вместо 10 минут в пустую, 3.5 минуты имели конкретную цель. Еще, это я решил впервые выступить в таком формате, многое переосмыслил и в следующий раз это займет не более часа, а дальше еще меньше.
Основные идеи выделены в каждом разделе. Но без общего контекста они читаются сухо. Кому-то важен контекст. Но в целом, согласен. В следующий раз минимум в два раза короче статью сделаю.
10 человек в прямом подчинении - это действительно сложно.
За 2 недели человек может:
Устать от перегрузки в связи с какой-то задачей, обстоятельством или наложением личных проблем, недовольством кем-то из коллег, которые сотрудник не готов публично озвучивать. Первое с чего мы начинаем встречу - проясняем состояние. Мы держим руку на пульсе, чтобы не допустить выгорание.
Сотрудник может накопить вопросы и темы для обсуждения. Часто люди хотят о чем-то рассказать и получить обратную связь. Озвучить идеи, которые так же не решаются обсудить с командой.
Это возможность руководителю дать обратную связь, о чем-то важном рассказать или обсудить.
И да, бывают случаи, когда мы встречаемся раз в месяц. Вот только это одна 30-минутная встреча, посвященная сотруднику вместо множества мелких отвлечений, которые в совокупности могут привести к большим затратам.
Спасибо большое за обратную связь. Надеюсь, если вы решитесь поделиться моей статьёй, вам не придётся обсуждать её содержание на очередном совещании )
Я тоже не понимаю) Сегодня у меня было 3 часа непрерывных, но важных встречи 1 на 1, начиная с прямых подчиненных, заканчивая CEO. Я очень устал.
Здесь согласен. Тут уже больше к руководству, считают ли они нормальным, что архитектор отвлекается на митинги, снижая производительность.
Вот прямо сегодня один из трех девелопмент менеджеров попросился на наш митинг, об оптимизации которого я говорил, т.к. тема пересекается с тем, за что он отвечает. Он тоже в таком формате был - работал) Но не думаю что это продуктивно. Будем решать, может ему проще получить какой-то сводный отчет о чем говорили и что решили, чем тратить время.
Очень здорово у вас регламентировано! Я бы тоже за такой формат, но команды хотят встречаться хотя бы виртуально раз в день. У нас удаленка. Вы в офисе работает или удаленно?
Сами по себе статьи не помогут. На собеседовании поможет навык структурировать свои мысли, который немного подкачался этими статьями.
Абсолютно правы. Если кто-то не компетентен, то это отдельная тема. Поправил.
Такое случается потому, что руководителям часто есть куда развиваться. Опытные же теряют фокус.
Привет! В проектах важно планировать на будущее и быть предсказуемыми. Простое добавление задачи в бэклог не решает проблему. Нужно либо выполнить задачу, либо решить не делать её вовсе. Если задача важна, но не выполняется, следует обсудить отмену, повышение приоритета или необходимость дополнительных ресурсов. Все задачи в бэклоге должны быть рассмотрены, так как их добавление изначально подразумевало важность. Обсуждение отмены может выявить ранее незамеченные аспекты задачи. Возможно, то что кажется важным кому-то, после прояснения потеряет свою важность. Тот кто заводит задачу, может просто не знать весь контекст. Я ответил на вопрос?
Привет, Илья! Согласен. То о чем ты пишешь достойно отдельной публикации.
Отлично, что вам приглянулась идея! Будет непросто, но результат того стоит. Вопрос как подобное внедрять со стороны разработчиков в сторону менеджеров стоит отдельной статьи. Удачи!
Я бы дал два лайка, если бы это было возможно! Да, я действительно стараюсь поступать так и учу этому своих ребят. Иногда понимаешь, что решать задачу напролом — неэффективно или слишком затратно. Но проходит месяц, а то и неделя, ты читаешь статью или что-то ещё, и вдруг — бац! — приходит идея. И оказывается, что проблему можно решить гораздо проще или как-то иначе. Правда, по моему опыту, ОБЩИЙ бэклог для таких случаев не подходит. А вот личный — да, тот самое то.
Очень хороший способ. Где ведете этот список задач?
Если автор комментария имел в виду, что у тимлида есть право принимать решения, то согласен. Но даже это право требует учета множества факторов, в том числе мнений коллег. Комментарий создает впечатление описания токсичной атмосферы "менеджеры против разработчиков". Был в такой ситуации как со стороны менеджмента, так и со стороны разработчика и понял: это неприятно. Больше не хочу в этом участвовать и не советую другим.
Про два статуса я не до конца понял, что вы имеете в виду. Если вы про "не приоритетно" и про "отмену", то статья скорее про то, что то, что не приоритетно, периодически надо переводить в "отмену". Это важно с позиции управления ожиданиями. Я тут привёл пример про то, как это влияет на команду, но с другой стороны есть бизнес. У него тоже свои ожидания. Если нет прозрачной системы, которая позволяет предсказать, будет ли выполняться задача и если будет, то когда, то представители бизнеса, например сейлзы, тоже замучают вопросами. И вместо работы менеджер, как савраска, будет весь в совещаниях. Т.е. есть категория задач, которая да, нужна, но делать не будем.
По-моему, мы говорим об одном и том же. Кстати, мне нравится статус 'Отменено', даже больше, чем 'Removed'.
Тимлид не всегда является верховным руководителем разработки, и во многих организациях над ним могут стоять вышестоящие технические руководители, такие как начальники разработки или CTO.
У нас, например, с января практически ни одной фичи не написали и это стоило немалых усилий. Приходилось общаться, договариваться и объяснять. Ключевое - договариваться и продавать важность изменений, объяснять их с точки зрения бизнеса.
Если же возникает мысль о необходимости полного игнорирования мнений других и одностороннего принятия решений, это может быть сигналом к переосмыслению своего места в компании и поиску более подходящей рабочей среды, где будет цениться совместное принятие решений и командная работа.
В любом подходе, главное, дружить с головой)