Внимательный читатель заметил, что тестирование и работу тестировщиков снова свели в поиск багов, с финалочкой в виде «уговорите ПО не катить релиз» (а к этому у меня отдельно ТАКОЕ количество вопросов и междометий).
Чемпионат для QA инженеров построенный по принципу «кто больше багов найдёт» - это примерно то же самое, что чемпионат по программированию, где главный критерий - кто больше строчек кода напишет.
Ещё больше удивляет, конечно, что всё это дело рук не каких-нибудь там HR/DevRel, а руководителя центра компетенций QA. Казалось бы.
Я вполне уловил то, о чём вы пишете. Примеры правил, которые вы приводите, понятны и даже относительно работают (я затрудняюсь их назвать "конкретными", т.к. по каждому из них есть миллион вопросов и вариантов воплощения). Я говорю о том, что сама проблема "как сделать так, что бы оценка производительности не противоречила ОКР" видится мне довольно надуманной.
ОКР призваны давать прозрачность в вопросе "В каком направлении нам нужно двигаться и какие шаги должны привести нас к этим целям". Процесс оценки производительности должен отвечать на вопрос "Насколько хорошо сотрудник выполняет взятые на себя обязательства". Эти два вопроса пересекаются лишь в том, что взятые сотрудником обязательства могут включать в себя участие в достижении целей из OKR, но почти никогда не ограничиваются оными. При этом если убрать из этой модели ОКР, то примерно ничего в процессе оценки эффективности работы не поменяется - просто один из источников коммитментов сотрудника из формализованных ОКР превратится в менее формализованный "цели команды", "стратегические задачи" или ещё чего-нибудь там.
Как правильно оценивать сотрудников, что бы не ломать OKR? Правильно, не используйте для оценки сотрудников OKR. Например, на сайте на который вы ссылаетесь в самом начале есть прекрасная статья, как проводить performance review не завязываясь на OKR: тык И ещё миллион аналогичных статей в этих ваших интернетах, напр.: вот эта статья на медиуме Где приводится прекрасная цитата Энди Гроува, который эти самый ОКРы и придумал: > OKRs are not synonymous with employee evaluations. OKRs are about the company’s goals and how each employee contributes to those goals. Performance evaluations — which are entirely about evaluating how an employee performed in a given period — should be independent from their OKRs.
OKR - это инструмент целеполагания, а не оценки эффективности работы. Ни для конкретного сотрудника, ни для команды. Степень выполнения OKR может служить индикатором для того, что бы копнуть глубже что пошло не так, но "сотрудник недостаточно заперформил, что бы их затащить" - одна (и то не полностью честная) из возможных причин для такого результата. Самая большая проблема OKR, как и KPI (который часто противопоставляют ОКРам, но вообще они не противоречат друг другу и совсем про разное) - это низкий профессионализм менеджеров, создавших вокруг них карго-культ и не умеющих ими пользоваться. В итоге получаем то, что получаем - буллшит бинго, в которое играют инженеры крупнейших и "топовых", казалось бы, компаний, вместо того, что бы работу работать.
Да ладно с ними с нейронами, кажется, не строить маршрут через мост, который разведен согласно расписанию — уже более работающее решение, чем то, что есть сейчас.
Больновато читать размышления в комментариях о том, что условный Яндекс.Навигатор может всё это просчитывать в реальном времени, в то время как Яндекс.Навигатор так и не научился не строить маршруты через разведенные мосты в Питере.
После просмотра сайта появилось желание съездить на Камчатку.
Купить вещи желания не появилось.
Ну, и как справедливо заметили — если господа хотят пиарить свои вещи «помощью Камчатке» — неплохо бы об этом рассказать подробнее. Что, как, кому помогаете, по какому принципу, сколько денег, etc. А пока выглядит как глупый пиар.
От прочтения статьи впечатления примерно такие же, как у главного героя при получении первой записки.
Вроде все символы выглядят знакомо, но какая-то тарабарщина.
Если я не путаю, то это ситуация «ФСБ утверждает, что человек пользовался телеграм», а не доказательства.
Во всей этой схеме слишком много допущений для того, что бы считать утверждение «телеграмм используется террористами» верным.
Имею в виду популярность продукта у запрещённых группировок и противодействие этому со стороны государств.
Использование Телеграма террористами становится гарантом конфиденциальности сервиса.
Я, конечно, дико извиняюсь. Но будут ли с вашей стороны какие-либо доказательства, что Телеграмм популярнее у террористов, чем все остальные мессенджеры?
Или что террористы чаще его используют в обсуждении своих злоключений?
Да ладно, что уж там. У вас есть хотя бы одно доказательство что террористы вообще когда-нибудь использовали Телеграмм для обсуждения и воплощения своих замыслов?
Если нет, то давайте прибережем формулировки «популярен у террористов», «используется террористами»и пр. для Первого Канала? Зачем у людей хлеб отбирать.
Всё сильно зависит от специфики.
Если вы выпускаете картриджи для нинтендо, то 3 дня фриза и тестирования — отличный результат. Потому что риски высокие, откатиться просто так нельзя, багфиксы не выкатишь и вот это всё.
3 дня регрессии для продукта, в котором обновление которого у всех клиентов занимает 10 минут — неприлично много.
Веб, клиент-серверные приложения десктоп-приложения, вот это всё. Вы можете выкатывать и откатывать фиксы, управлять версионностью, мониторить качество продукта и пользовательский опыт.
Нон стопом, быстро и безболезненно. Вам выгоднее и пользователям выгоднее получить полезную нагрузку ASAP, пусть даже сначала она станет полезной для 80% пользователей, потом для 90, потом для всех.
Даже в мобильных приложениях, где с принудительным обновлением клиентов всё относительно плохо, сейчас стараются делать всё, что бы можно было максимально гибко изменять поведение приложения не меняя клиент.
Разработка ускоряется, никто не готов работать по вотерфоллу где каждый этап водопада занимает месяц. Это не выгодно, не эффективно и не нужно ни разработчикам, ни заказчикам, ни пользователям.
Есть отдельные категории продуктов, где цена ошибки слишком высока, что бы от этого можно было полностью уйти, но таких продуктов — реальный минимум.
Ещё раз. Как таковой DevOps ничего не убивает.
Любые изменения в процессах, будь то внедрение аджайла, девопс практик, или ещё чего-нибудь могут убить проект.
Я точно так же видел проекты, которые загибались под гнетом тестирования. Просто потому, что продукт требовал быстрой поставки в продакшен, простых но быстрых изменений, проверки гипотез на проде и прочего.
А регрессия на нем шла в ручную в среднем три дня.
Потом там находились баги, они правились, и регрессировали ещё три дня.
Потом всё таки выкатывались в прод, находили баг в проде, и выпускали три дня хотфикс.
На развитии продукта в такой схеме можно просто поставить крест и разойтись по домам.
В России всё плохо с QA. В принципе ОЧЕНЬ плохо.
Компаний, которые у себя внутри держат не специалистов по тестированию, а QA инженеров — предельно мало (в Питере, например, их можно по пальцам посчитать).
И естественно, внедрение ДевОпс практик в команде, где единственным гарантом хоть какой-то работоспособности приложения является то, что N человек X часов гонят тесты — не приведет ни к чему хорошему.
Не потому, что ДевОпс это плохо. А потому, что ДевОпс призван ускорять деливеринг. А в таких условиях ускорять его нереально.
Точно так же внедрение аджайла в компании, где никто ничего не может без четко расписанного ТЗ и микроменеджмента — убьет всё нафиг. Но это не значит, что аджайл — это зло.
Просто любая методология, практика разработки или инструмент требует определенных условий, для её использования.
Но всегда есть карго культ, когда люди тупо копируют практики у успешных товарищей по отрасли и думают, что это решит все их проблемы.
Но это не изъян практик, это изъян людей.
Ну, по поводу «никому» это вы, конечно, очень смело обобщили.
Есть довольно большое количество компаний, где роль куаки включает в себя и ручное тестирование, и автоматизацию, в разных пропорциях.
В таких случаях, компании, очевидно, интересно прокачивать людей в эту сторону не роняя им грейд при этом.
Гхм, так и запишем, в качестве пути развития для “QA” сибур предлагает сменить профессию.
Спасибо, спасибо.
2023 год, ребята из Тинькофф узнали, что оказывается тестирование требований - норм тема.
Кайф.
Внимательный читатель заметил, что тестирование и работу тестировщиков снова свели в поиск багов, с финалочкой в виде «уговорите ПО не катить релиз» (а к этому у меня отдельно ТАКОЕ количество вопросов и междометий).
Внимательному читателю грустно от этого.
Чемпионат для QA инженеров построенный по принципу «кто больше багов найдёт» - это примерно то же самое, что чемпионат по программированию, где главный критерий - кто больше строчек кода напишет.
Ещё больше удивляет, конечно, что всё это дело рук не каких-нибудь там HR/DevRel, а руководителя центра компетенций QA. Казалось бы.
Я вполне уловил то, о чём вы пишете.
Примеры правил, которые вы приводите, понятны и даже относительно работают (я затрудняюсь их назвать "конкретными", т.к. по каждому из них есть миллион вопросов и вариантов воплощения).
Я говорю о том, что сама проблема "как сделать так, что бы оценка производительности не противоречила ОКР" видится мне довольно надуманной.
ОКР призваны давать прозрачность в вопросе "В каком направлении нам нужно двигаться и какие шаги должны привести нас к этим целям".
Процесс оценки производительности должен отвечать на вопрос "Насколько хорошо сотрудник выполняет взятые на себя обязательства".
Эти два вопроса пересекаются лишь в том, что взятые сотрудником обязательства могут включать в себя участие в достижении целей из OKR, но почти никогда не ограничиваются оными.
При этом если убрать из этой модели ОКР, то примерно ничего в процессе оценки эффективности работы не поменяется - просто один из источников коммитментов сотрудника из формализованных ОКР превратится в менее формализованный "цели команды", "стратегические задачи" или ещё чего-нибудь там.
Как правильно оценивать сотрудников, что бы не ломать OKR?
Правильно, не используйте для оценки сотрудников OKR.
Например, на сайте на который вы ссылаетесь в самом начале есть прекрасная статья, как проводить performance review не завязываясь на OKR:
тык
И ещё миллион аналогичных статей в этих ваших интернетах, напр.: вот эта статья на медиуме
Где приводится прекрасная цитата Энди Гроува, который эти самый ОКРы и придумал:
>
OKRs are not synonymous with employee evaluations. OKRs are about the company’s goals and how each employee contributes to those goals. Performance evaluations — which are entirely about evaluating how an employee performed in a given period — should be independent from their OKRs.OKR - это инструмент целеполагания, а не оценки эффективности работы. Ни для конкретного сотрудника, ни для команды.
Степень выполнения OKR может служить индикатором для того, что бы копнуть глубже что пошло не так, но "сотрудник недостаточно заперформил, что бы их затащить" - одна (и то не полностью честная) из возможных причин для такого результата.
Самая большая проблема OKR, как и KPI (который часто противопоставляют ОКРам, но вообще они не противоречат друг другу и совсем про разное) - это низкий профессионализм менеджеров, создавших вокруг них карго-культ и не умеющих ими пользоваться.
В итоге получаем то, что получаем - буллшит бинго, в которое играют инженеры крупнейших и "топовых", казалось бы, компаний, вместо того, что бы работу работать.
А ещё синьору (а уж Head of QA тем паче) неплохо бы понимать, что не все тест-кейсы стоит автоматизировать, даже когда такая возможность есть. :)
Купить вещи желания не появилось.
Ну, и как справедливо заметили — если господа хотят пиарить свои вещи «помощью Камчатке» — неплохо бы об этом рассказать подробнее. Что, как, кому помогаете, по какому принципу, сколько денег, etc. А пока выглядит как глупый пиар.
Такая себе success story, честно говоря.
Вроде все символы выглядят знакомо, но какая-то тарабарщина.
Пока что всё, что я вижу, это как вы проецируете собственные предрассудки на те или иные категории граждан.
Во всей этой схеме слишком много допущений для того, что бы считать утверждение «телеграмм используется террористами» верным.
Я, конечно, дико извиняюсь. Но будут ли с вашей стороны какие-либо доказательства, что Телеграмм популярнее у террористов, чем все остальные мессенджеры?
Или что террористы чаще его используют в обсуждении своих злоключений?
Да ладно, что уж там. У вас есть хотя бы одно доказательство что террористы вообще когда-нибудь использовали Телеграмм для обсуждения и воплощения своих замыслов?
Если нет, то давайте прибережем формулировки «популярен у террористов», «используется террористами»и пр. для Первого Канала? Зачем у людей хлеб отбирать.
Если вы выпускаете картриджи для нинтендо, то 3 дня фриза и тестирования — отличный результат. Потому что риски высокие, откатиться просто так нельзя, багфиксы не выкатишь и вот это всё.
3 дня регрессии для продукта, в котором обновление которого у всех клиентов занимает 10 минут — неприлично много.
Веб, клиент-серверные приложения десктоп-приложения, вот это всё. Вы можете выкатывать и откатывать фиксы, управлять версионностью, мониторить качество продукта и пользовательский опыт.
Нон стопом, быстро и безболезненно. Вам выгоднее и пользователям выгоднее получить полезную нагрузку ASAP, пусть даже сначала она станет полезной для 80% пользователей, потом для 90, потом для всех.
Даже в мобильных приложениях, где с принудительным обновлением клиентов всё относительно плохо, сейчас стараются делать всё, что бы можно было максимально гибко изменять поведение приложения не меняя клиент.
Разработка ускоряется, никто не готов работать по вотерфоллу где каждый этап водопада занимает месяц. Это не выгодно, не эффективно и не нужно ни разработчикам, ни заказчикам, ни пользователям.
Есть отдельные категории продуктов, где цена ошибки слишком высока, что бы от этого можно было полностью уйти, но таких продуктов — реальный минимум.
Любые изменения в процессах, будь то внедрение аджайла, девопс практик, или ещё чего-нибудь могут убить проект.
Я точно так же видел проекты, которые загибались под гнетом тестирования. Просто потому, что продукт требовал быстрой поставки в продакшен, простых но быстрых изменений, проверки гипотез на проде и прочего.
А регрессия на нем шла в ручную в среднем три дня.
Потом там находились баги, они правились, и регрессировали ещё три дня.
Потом всё таки выкатывались в прод, находили баг в проде, и выпускали три дня хотфикс.
На развитии продукта в такой схеме можно просто поставить крест и разойтись по домам.
В России всё плохо с QA. В принципе ОЧЕНЬ плохо.
Компаний, которые у себя внутри держат не специалистов по тестированию, а QA инженеров — предельно мало (в Питере, например, их можно по пальцам посчитать).
И естественно, внедрение ДевОпс практик в команде, где единственным гарантом хоть какой-то работоспособности приложения является то, что N человек X часов гонят тесты — не приведет ни к чему хорошему.
Не потому, что ДевОпс это плохо. А потому, что ДевОпс призван ускорять деливеринг. А в таких условиях ускорять его нереально.
Точно так же внедрение аджайла в компании, где никто ничего не может без четко расписанного ТЗ и микроменеджмента — убьет всё нафиг. Но это не значит, что аджайл — это зло.
Просто любая методология, практика разработки или инструмент требует определенных условий, для её использования.
Но всегда есть карго культ, когда люди тупо копируют практики у успешных товарищей по отрасли и думают, что это решит все их проблемы.
Но это не изъян практик, это изъян людей.