Многие считают, что задача QA — найти как можно больше багов. И чем будет длиннее список в баг‑трекере, тем «полезнее» тестировщик. В этой статье расскажем, почему QA — не просто ловец багов, а инженер качества. Разберем, как инженерный подход к стабильности помогает команде Modus управлять рисками задолго до первой строчки кода и почему это полностью меняет отношение к процессам тестирования.
За последние годы я несколько раз видел как компания утверждает план в декабре, а к марту он теряет смысл, но продолжает выполняться, потому что план утверждён. Формально всё в порядке, метрики исполнения зелёные. Фактически ресурсы уходят в никуда.
Отсюда логичный вывод, который делают многие: раз всё равно ничего не предскажешь, зачем вообще стратегия.
Считаю, что это ошибка. В нестабильной среде стратегия тоже нужна, просто другая. Не жёсткий план на пять лет, а система ориентиров, которая позволяет быстро принимать решения и корректировать курс, не теряя главного.
Всем привет. Мы решили попробовать нестандартный формат, чтобы поговорить о важных для нас и индустрии ИТ темах. Предлагаем вашему вниманию экспериментальный детектив. Все герои вымышлены, а ситуации собирательны. Не ищите точных совпадений :)
nanoCAD BIM ВК содержит комплексные инструменты для разработки спринклерных и дренчерных установок, соответствующие российским нормативам.
Вчера на HR Product Owners Club обсуждали опыт взаимодействия с AI агентами. Особенно первые шаги. И я попытался посмотреть на это с позиции HR.
У нас есть цепочка создания ценности — какого‑то продукта. В этой цепочке нам нужен труд. Мы его обычно покупаем на рынке труда. Чтобы купить труд — нам надо нарезать задачи — разделить их на рабочие места (позиции и роли).
Сегодня часть этого труда мы можем «купить» у AI агентов. Это такой же сотрудник, которого мы нанимаем для выполнения какой‑то работы.
Периодически мы чувствуем, что предлагаем хорошее решение. Как в меме: «Эта фича будет прибыльной, но я пока не могу этого доказать». В этом случае оценка продукта не учитывает мнение целевой аудитории, как будто мы единственный пользователь нашего решения.
Иногда при формировании новых гипотез мы можем столкнуться с подменой понятий идеи, ценности и спроса. В моменте идея может показаться нам настолько классной, что мы объясняем её ценность команде, но пропускаем этап её фактической проверки и сразу приступаем к разработке.
Последние месяцы я много писал о психологии работы разработчиков: о страхе ошибки, перегрузке, поддержке и конфликтах. Постепенно стала заметна одна закономерность: психологический процесс начинает влиять на работу раньше, чем появляется событие, которое мы уже называем проблемой.
Из этой мысли мы начали собирать Практику эмоциональной профилактики.
Сразу оговорюсь: всё описанное дальше не обязательно относится именно к вам. Возможно, вы давно замечаете такие процессы и умеете с ними работать. Но вполне вероятно, что что-то похожее вы встречали у коллег, руководителей или в других командах.
