Ситуация - гордиев узел "на минималках". Всё же, ситуация требует довыяснения произошедшего: анализа требований, проверки коммуникаций. + Нужно понимание того, как выстроены процессы и система ответственности.
В первом приближении основными "виновниками" кажутся:
исполнитель,
менеджер курирующий задачу (ПМ или кто-то такой),
серьёзный изъян в рабочих процессах.
С QA ситуация не очень понятна. Если база тестовая, то логично, что её будут шатать. Другое дело "тестировщики случайно уронили базу" - как? : ) да ещё и вместе с бекапами. Тут напрашивается более внимательное изучение инцидента.
Мой опыт (тестирование и анализ требований) показывает, что тех.заданию редко стоит доверять. Иногда, самые дорогие задачи - это сформулированные <<на "отвали">> с позицией "и так всё понятно". В таких ситуациях формулировщик требований - тоже несёт частичную ответственность.
Очень смутило в этой истории: идея делать виноватым одного человека и тем более, транслировать это в чатах - довольно странно. Кстати, тоже звоночек более высокому руководству для изучения.
Название, конечно, провокационное — сначала кажется, что 80% тестов бесполезны. Но, как понимаю, к такому итогу приводит либо отсутствие планирования, либо бездумная генерация тестов. Вопрос масштабирования тестов проблема не только автоматического, но и ручного тестирования. А вот живого опыта не хватает. Интересно было бы почитать про реальные случаи — свои или те, где автор был наблюдателем.
мне кажется, не хватает хэштега #московские_мифы :-)
А если серьёзно, то, возможно, эти "мифы" и позиционируются как "имхо", но они вполне актуальны в целом по России. Фразочки "на тему", часто, можно встретить от тех, кто разработкой не занимается. Те, кто поварится в этом 2-3 года хотя бы, потихоньку заинтересуется рынком всёрьёз и поймёт как много всяких факторов. Хотя, конечно, это всё почти сразу понятно..
Проблема не совсем в поколении. От ровестников-миллениалов не раз встречал истории в формате "ушёл с работы на первой же неделе". Истории эти как правило о временах, когда им было по 20-25 лет. Времена сменились, экономическая ситуация мягче, чем в 00х и 10х - вот и у молодёжи на которое выпали нынешние времена стали избирательнее.
Плохо в этом ничего не вижу. Станет хуже чем в 90-х и зарплаты также годами не будут выплачивать - изменится и отношение к работе. Надеюсь, такого не случится.
Другое дело, что приученность к труду другая (в среднем "по больнице"), но тут винить надо поколение, что их вырастило. Работаю с поколением зумеров и никаких разительных отличий от других полоколений не вижу.
Дополню. Через когнитивное выгорание проходил лишь раз и как эффект профлитературу несколько лет не мог читать вообще -- текст не воспринимался совсем. Сменил профиль. Теперь работаю в ИТ и часто подвожу себя близко к умственному переутомлению (2-3 раза в год). Тогда я вспоминаю про золотое трио и достаточно быстро восстанавливаюсь (2-3 недели).
Есть "когнитивное выгорание", есть "умственное переутомление", "накопленная усталость".
Когда "когнитивное выгорание" уже случилось, то считайте, что это финиш. Обычные методы уже не подойдут, а любые "дополнительные усилия" в лучшем случае не будут давать никакого эффекта, но скорее всего только усугублять.
"умственное переутомление" и "накопленная усталость" -- идут рука об руку. То, что ведёт к "выгоранию" к айтишников.
Базовая профилактика у всего достаточно общая:
здоровый режим сна с достаточной продолжительностью. Новичкам рекомендую относиться к вызову "поддержания режима сна" как серьёзной задаче профессионала;
хорошие физические нагрузки;
избегать умственных переработок.
Понятное дело, что подавляющее большинство плевать хотело на соблюдение этих списков. И большинство справляется как попало. Никого не осуждаю, понятно, что условия и обстоятельства жизни бывают разные. Но такой минимум позволяет избегать очень многих проблем когнитивного характера.
Отличный кейс, внушающий опыт. Охотно почитал бы ваши статьи на тему менеджмента.
Если в течение пары-тройки вернусь к своему основному профилю, то менеджерский опыт для меня будет крайне полезным опытом и в разработке. Ибо то, до чего я бы годами доходил, глядя с позиции исполнителя; с позиции руководителя многие процессы стали понятны почти "моментально" (каких-то 1,5 года) сразу в глубину.
ИМХО, вне зависимости от того продолжить рост в менеджменте или вернуться "в поля" -- профессионал нисколько не потеряет от полученного опыта. Разве что перспективы раскроются в других плоскостях.
п.с. совещания (когда эффективны) и планирование - мне по душе, но вот отчёты - это боль. У любой профессии есть свои издержки :)
Тимлид — это менеджер младшего звена. Мой кейс один из самых распространённых: тимлид и техлид в одном лице. Главная моя мотивация стать лидом была возможность наладить процессы, некоторые из них аккуратно отстроить с нуля; вырастить себе замену и уйти в техлиды, делегировав пост тимлида своему протеже. Сейчас я в середине пути. Выстраивать процессы работа щепетильная и очень деликатная.
Становясь тимлидом, полезно обозначить свой профит и цену за него. Я заранее знал на что подписываюсь, потому двухкратные перегрузки на старте не были внезапными. По итогу полученный опыт для меня оказался предельно полезным.
По сабжу. Тимлид это вполне себе карьерный рост, но не профильный для трудяг (программистов, тестировщиков, аналитиков и т.п.), а потому это почти всегда отдаление от профиля в сторону менеджмента.
Я достаточно молод как тимлид (1,5 годика), а потому ещё не определился — хочу ли остаться в этом должности или срочно возвращаться к любимому делу.
Ситуация - гордиев узел "на минималках". Всё же, ситуация требует довыяснения произошедшего: анализа требований, проверки коммуникаций. + Нужно понимание того, как выстроены процессы и система ответственности.
В первом приближении основными "виновниками" кажутся:
исполнитель,
менеджер курирующий задачу (ПМ или кто-то такой),
серьёзный изъян в рабочих процессах.
С QA ситуация не очень понятна. Если база тестовая, то логично, что её будут шатать. Другое дело "тестировщики случайно уронили базу" - как? : ) да ещё и вместе с бекапами. Тут напрашивается более внимательное изучение инцидента.
Мой опыт (тестирование и анализ требований) показывает, что тех.заданию редко стоит доверять. Иногда, самые дорогие задачи - это сформулированные <<на "отвали">> с позицией "и так всё понятно". В таких ситуациях формулировщик требований - тоже несёт частичную ответственность.
Очень смутило в этой истории: идея делать виноватым одного человека и тем более, транслировать это в чатах - довольно странно. Кстати, тоже звоночек более высокому руководству для изучения.
Название, конечно, провокационное — сначала кажется, что 80% тестов бесполезны. Но, как понимаю, к такому итогу приводит либо отсутствие планирования, либо бездумная генерация тестов. Вопрос масштабирования тестов проблема не только автоматического, но и ручного тестирования.
А вот живого опыта не хватает. Интересно было бы почитать про реальные случаи — свои или те, где автор был наблюдателем.
мне кажется, не хватает хэштега #московские_мифы :-)
А если серьёзно, то, возможно, эти "мифы" и позиционируются как "имхо", но они вполне актуальны в целом по России.
Фразочки "на тему", часто, можно встретить от тех, кто разработкой не занимается. Те, кто поварится в этом 2-3 года хотя бы, потихоньку заинтересуется рынком всёрьёз и поймёт как много всяких факторов. Хотя, конечно, это всё почти сразу понятно..
Проблема не совсем в поколении. От ровестников-миллениалов не раз встречал истории в формате "ушёл с работы на первой же неделе". Истории эти как правило о временах, когда им было по 20-25 лет. Времена сменились, экономическая ситуация мягче, чем в 00х и 10х - вот и у молодёжи на которое выпали нынешние времена стали избирательнее.
Плохо в этом ничего не вижу. Станет хуже чем в 90-х и зарплаты также годами не будут выплачивать - изменится и отношение к работе. Надеюсь, такого не случится.
Другое дело, что приученность к труду другая (в среднем "по больнице"), но тут винить надо поколение, что их вырастило. Работаю с поколением зумеров и никаких разительных отличий от других полоколений не вижу.
Опечатка: "с присоской" 2 раза подряд написано.
Интересно как "open source" отличают от "pet-project"
Дополню. Через когнитивное выгорание проходил лишь раз и как эффект профлитературу несколько лет не мог читать вообще -- текст не воспринимался совсем. Сменил профиль.
Теперь работаю в ИТ и часто подвожу себя близко к умственному переутомлению (2-3 раза в год). Тогда я вспоминаю про золотое трио и достаточно быстро восстанавливаюсь (2-3 недели).
Есть "когнитивное выгорание", есть "умственное переутомление", "накопленная усталость".
Когда "когнитивное выгорание" уже случилось, то считайте, что это финиш. Обычные методы уже не подойдут, а любые "дополнительные усилия" в лучшем случае не будут давать никакого эффекта, но скорее всего только усугублять.
"умственное переутомление" и "накопленная усталость" -- идут рука об руку. То, что ведёт к "выгоранию" к айтишников.
Базовая профилактика у всего достаточно общая:
здоровый режим сна с достаточной продолжительностью. Новичкам рекомендую относиться к вызову "поддержания режима сна" как серьёзной задаче профессионала;
хорошие физические нагрузки;
избегать умственных переработок.
Понятное дело, что подавляющее большинство плевать хотело на соблюдение этих списков. И большинство справляется как попало. Никого не осуждаю, понятно, что условия и обстоятельства жизни бывают разные. Но такой минимум позволяет избегать очень многих проблем когнитивного характера.
Отличный кейс, внушающий опыт. Охотно почитал бы ваши статьи на тему менеджмента.
Если в течение пары-тройки вернусь к своему основному профилю, то менеджерский опыт для меня будет крайне полезным опытом и в разработке. Ибо то, до чего я бы годами доходил, глядя с позиции исполнителя; с позиции руководителя многие процессы стали понятны почти "моментально" (каких-то 1,5 года) сразу в глубину.
ИМХО, вне зависимости от того продолжить рост в менеджменте или вернуться "в поля" -- профессионал нисколько не потеряет от полученного опыта. Разве что перспективы раскроются в других плоскостях.
п.с. совещания (когда эффективны) и планирование - мне по душе, но вот отчёты - это боль. У любой профессии есть свои издержки :)
Тимлид — это менеджер младшего звена.
Мой кейс один из самых распространённых: тимлид и техлид в одном лице. Главная моя мотивация стать лидом была возможность наладить процессы, некоторые из них аккуратно отстроить с нуля; вырастить себе замену и уйти в техлиды, делегировав пост тимлида своему протеже.
Сейчас я в середине пути. Выстраивать процессы работа щепетильная и очень деликатная.
Становясь тимлидом, полезно обозначить свой профит и цену за него. Я заранее знал на что подписываюсь, потому двухкратные перегрузки на старте не были внезапными.
По итогу полученный опыт для меня оказался предельно полезным.
По сабжу. Тимлид это вполне себе карьерный рост, но не профильный для трудяг (программистов, тестировщиков, аналитиков и т.п.), а потому это почти всегда отдаление от профиля в сторону менеджмента.
Я достаточно молод как тимлид (1,5 годика), а потому ещё не определился — хочу ли остаться в этом должности или срочно возвращаться к любимому делу.
Да, в статье всё к месту и актуально. Но если всё прочее так или иначе приходит, а вот про инициативность многие не понимают.
Спасибо за статью! Пишите ещё!
Отличные советы джуну, даже если ты не один. Особенно бы выделил про инициативность.