Моё мнение, что нужно найти баланс между высказаться и запрещать любые разговоры. Тем кому особенно тяжело не обсуждать или фокусироваться на роботе, лучше всего дать время на отдых.
На работе – работают. Эффективная работа позволит сохранить в определенной степени стабильность и фокус на будущее.
Мы уже писали ранее статью по команды и ценности, и про то, как ценности помогают командам преодолевать кризисы или разрушать команды, если ценности разные.
Важно теоретические знания применять на практике, анализировать полученный результат (опыт) и совершенствовать эти практики. У тех, кто старается, обычно получается лучше.
В теоретических знаниях начать надо с того, чтобы прочитать книгу или длинную статью от начала и до конца :).
Да, действительно, нужно смотреть на ключевые метрики, при этом можно и нужно работать персонально с каждой. В данном случаи выбрали TTM для примера.
Если в ваших задачах есть ценность для пользователей при мелкой нарезки, лучше нарезать так. Если задачи двигаются быстрее, при этом пользы нет, то мы поработали с релизным циклом, а не с TTM.
Когда на проекте или в процессе много проблем начать надо с корневой причины (проблемы), а для этого точно диагностировать.
Смысл в фокусе прикладываемых усилий – если разрешить сперва именно корневую причину проблем, остальные могут решаться сами или оказывать меньшее негативное влияние на процесс в целом.
Отличный комментарий. Да, это правда, важно не просто поставить оценки, а оценить компетенции объективно и взвешенно.
Самооценка, интервью с тимлидом, тестирование, закрытые задачи, опрос 360 – всё это инструменты оценки со своей эффективностью и стоимостью. Всё это может быть, скорее даже, должно быть часть системы управления компетенциями, грейдированием и мотивацией, наравне с системой каскадирование KPI и управления индивидуальными планами развития (ИПР). Про всё это мы еще напишем в будущих статьях.
Как ранее уже ответил @FastGrandmother – для любых матриц подходят редакторы таблиц, мы обычно это делаем в Google Таблицах, для интерактивного обновления хорошо доходит Miro.
Вы правы, умение писать хороший код – очень ценный навык, даже ключевой. Поэтому всегда фокус на этом и можно забыть про цели, ценности и эмоциональный интеллект.
Умение давать конструктивную критику и обратную связь на код-ревью – еще более ценный навык. Я видел, как резкая критика кода "звезд" выжигала мидлов и вредила команде, поэтому хочется говорить об этом и делать на этом акценты.
По опыту, Скрам требует много командных усилий и вовлеченности. Сами по себе гибкие методологии работают, когда вся команда так умеет и это определенный уровень зрелости каждого члена команды.
«В сущности, все модели неправильны, но некоторые полезны». Действительно, я считаю, что нет готовых рецептов и серебреных пуль, при этом есть накопленный опыт и вполне удачные попытки систематизировать типовые процессы и ситуации.
То, что вы прочитали и порефлексировали – уже большой успех этой статьи.
Да, есть созвучность с корпоративной атрибутикой. Корпоративная культура может и должна влиять на команды, которые в этих компаниях работаю, а мотивы этого влияние – выбор топ-менеджеров.
Есть много примеров компаний, где миссия и цели помогают собрать прекрасные команды и мотивировать их на результат, предлагая хорошие условия труда и оплаты.
Отличный комментарий «поэтому основная методика именно повышение стоимости атак, а не их стопроцентное предотвращение».
Действительно, совершенствуются и средства защиты, и методы «нападения» – важно понимать финансовые и репутационные риски при планировании бюджета на защиту от вредоносных ботов.
В команде разработки, техлид может забрать на себя роль архитектора решения (в процессе код-ревью может осуществлять архитектурный надзор), а выделенный архитектор решения обязанности техлида забрать, скорее всего, не сможет, да и команде, скорее всего это не нужно.
Техлид – старший разработчик, готовый брать на себя больше ответственности.
На этапе проработки требований системным аналитиком, чаще всего, тимлид подключается к валидации требований, подключает техлидов и QA-специалистов при необходимости.
Тимлиду важно читать то, что приходит от аналитиков, тимлиду и всей команде – вот это я называю «говорить на одном языке».
Да, тимлид может допустить ошибку, важно минимизировать эти ошибки и у тимлида есть для этого все возможности. Важно понимать, что именно тимлид отвечает за техническое качество проекта и может делегировать команде (техлиду, архитектуру, QA и т.д.) задачи, а не свою ответственность.
Да, это правда. Есть проекты, где архитектор – это отдельная роль.
При заказной разработке Enterprise-решений, архитектор есть и со стороны клиента. Часто предложение по архитектуре защищаются на архитектурном комитете.
T&M – это модель работы, при которой оплачивается не результат, а время исполнителя.
В целом T&M плохо продаётся в т.ч. из-за сложности заключения контрактов, особенно государственных в рамках ФЗ о закупках.
Моё мнение, что нужно найти баланс между высказаться и запрещать любые разговоры. Тем кому особенно тяжело не обсуждать или фокусироваться на роботе, лучше всего дать время на отдых.
На работе – работают. Эффективная работа позволит сохранить в определенной степени стабильность и фокус на будущее.
Мы уже писали ранее статью по команды и ценности, и про то, как ценности помогают командам преодолевать кризисы или разрушать команды, если ценности разные.
Важно теоретические знания применять на практике, анализировать полученный результат (опыт) и совершенствовать эти практики. У тех, кто старается, обычно получается лучше.
В теоретических знаниях начать надо с того, чтобы прочитать книгу или длинную статью от начала и до конца :).
Да, действительно, нужно смотреть на ключевые метрики, при этом можно и нужно работать персонально с каждой. В данном случаи выбрали TTM для примера.
Если в ваших задачах есть ценность для пользователей при мелкой нарезки, лучше нарезать так. Если задачи двигаются быстрее, при этом пользы нет, то мы поработали с релизным циклом, а не с TTM.
Спасибо за комментарий. Теперь упомянули на картинке и в комментариях :)
Когда на проекте или в процессе много проблем начать надо с корневой причины (проблемы), а для этого точно диагностировать.
Смысл в фокусе прикладываемых усилий – если разрешить сперва именно корневую причину проблем, остальные могут решаться сами или оказывать меньшее негативное влияние на процесс в целом.
Отличный комментарий. Да, это правда, важно не просто поставить оценки, а оценить компетенции объективно и взвешенно.
Самооценка, интервью с тимлидом, тестирование, закрытые задачи, опрос 360 – всё это инструменты оценки со своей эффективностью и стоимостью. Всё это может быть, скорее даже, должно быть часть системы управления компетенциями, грейдированием и мотивацией, наравне с системой каскадирование KPI и управления индивидуальными планами развития (ИПР). Про всё это мы еще напишем в будущих статьях.
Как мне написал мой коллега после прочтения статьи:
Иван теперь для меня не авторитет, позовите Михаила. По мотивом той же таблицы.
На месте Дарьи может быть каждый :)
Для построения лепестковая диаграммы обычно используем Google Таблицы. Для иллюстраций используем магию наших дизайнеров :)
Как ранее уже ответил @FastGrandmother – для любых матриц подходят редакторы таблиц, мы обычно это делаем в Google Таблицах, для интерактивного обновления хорошо доходит Miro.
Надо быть самым скилловым лидером, а не самым скилловым технарём, при этом конечно же разбираться в предметной области и быть экспертом.
Вы правы, умение писать хороший код – очень ценный навык, даже ключевой. Поэтому всегда фокус на этом и можно забыть про цели, ценности и эмоциональный интеллект.
Умение давать конструктивную критику и обратную связь на код-ревью – еще более ценный навык. Я видел, как резкая критика кода "звезд" выжигала мидлов и вредила команде, поэтому хочется говорить об этом и делать на этом акценты.
Если всё получается само собой – это прекрасно.
По опыту, Скрам требует много командных усилий и вовлеченности. Сами по себе гибкие методологии работают, когда вся команда так умеет и это определенный уровень зрелости каждого члена команды.
Очень интересная позиция, спасибо, что поделились. Вы правы, нельзя ставить себя выше команды.
Я считаю, что хорошего тимлида видно и его всегда много, даже тогда, когда тимлид всё еще разработчик :).
Отличный комментарий, спасибо.
«В сущности, все модели неправильны, но некоторые полезны». Действительно, я считаю, что нет готовых рецептов и серебреных пуль, при этом есть накопленный опыт и вполне удачные попытки систематизировать типовые процессы и ситуации.
То, что вы прочитали и порефлексировали – уже большой успех этой статьи.
Спасибо за комментарий.
Да, есть созвучность с корпоративной атрибутикой. Корпоративная культура может и должна влиять на команды, которые в этих компаниях работаю, а мотивы этого влияние – выбор топ-менеджеров.
Есть много примеров компаний, где миссия и цели помогают собрать прекрасные команды и мотивировать их на результат, предлагая хорошие условия труда и оплаты.
Действительно, совершенствуются и средства защиты, и методы «нападения» – важно понимать финансовые и репутационные риски при планировании бюджета на защиту от вредоносных ботов.
Спасибо!
Техлид – старший разработчик, готовый брать на себя больше ответственности.
Тимлиду важно читать то, что приходит от аналитиков, тимлиду и всей команде – вот это я называю «говорить на одном языке».
Да, тимлид может допустить ошибку, важно минимизировать эти ошибки и у тимлида есть для этого все возможности. Важно понимать, что именно тимлид отвечает за техническое качество проекта и может делегировать команде (техлиду, архитектуру, QA и т.д.) задачи, а не свою ответственность.
При заказной разработке Enterprise-решений, архитектор есть и со стороны клиента. Часто предложение по архитектуре защищаются на архитектурном комитете.