Со своей стороны отмечу несколько моментов:
1. Примерно половина участников опроса ответила, что регулярно (раз в N времени) им пригодилась бы помощь ментора.
Вторая половина - за теми, кому ментор нужен в основном тогда, когда человек берется изучать что-то новое.

2. Среди ожиданий относительно того, кто мог бы быть ментором заметно лидируют требования к экспертизе и софтскиллам - способности объяснять нужные вещи просто и понятно.
Формальные регалии, типа сертификатов, участия в конференциях и занимаемых позиций критичны для значительно меньшего числа людей.

3. В вопросе о том, какую помощь вы ожидаете от ментора я сознательно поставил мультиселект, потому что очевидно, что одним пунктом тут не ограничишься.
Результаты распределились более-менее равномерно, но чаще всего в менторе видят источник дополнительной экспертизы, а уже потом - помощника в вопросах обучения и решении рабочих задач.

4. Почти половина участников опроса сказала, что готовы платить ментору за его помощь.
Ещё 40% - что это зависит от того, насколько помощь будет полезной.

Последнее и, наверное, самое главное:
Всё это довольно хорошо укладывается в ту гипотезу, которая заставила меня создать этот опросник.
Значит, пора переходить от идеи к воплощению. :)

Анонс и все подробности - в завтрашнем посте.

А теперь, собственно, обещанный вчера анонс.

Многие из вас знают, что я довольно активно дискутирую в профессиональных сообществах и стараюсь делиться знаниями и идеями там, где моя экспертиза это позволяет.
Даже этот канал, в общем-то, появился из желания делиться мыслями, опытом и видением с коллегами по цеху.
Менторство - ещё один способ помогать коллегам по отрасли разбираться с проблемами, делиться знаниями и делать мир чуточку лучше.

Сегодняшний анонс ровно про это - менторство от Шуу.
В ближайшие дни готов взяться за менторинг 10 человек.
Помогать, советовать, делиться опытом, давать фидбэк и т.д.

Что всё это значит:
- Я не могу заставить вас учиться, прокачивать скиллы или стать классными специалистами, но могу помочь в выборе направления, материалов и планов для обучения.
- Я не могу сделать так, что вы будете писать классный код и зарабатывать миллиарды, но сделать ревью, дать фидбэк или просто поделиться опытом - всегда пожалуйста.
- Я не буду решать за вас ваши задачи, но могу поделиться опытом, накидать ссылок "на почитать" или посоветовать, с какой стороны лучше подойти к той или иной проблеме.  

Как всё это будет выглядеть:
- У вас будет закрытый чатик, где я буду отвечать на вопросы, давать советы и фидбэк.
- Два раза в месяц мы будем созваниваться 1-to-1, чтобы обменяться фидбэком и обсудить планы, результаты, и/или другие волнующие истории.

Условия:
Ежемесячная подписка за 5к руб./месяц.

Что ещё надо знать:
- Как уже говорил, количество мест ограничено моим capacity. Только 10 человек.
- Большая часть общения будет в чатике, ибо асинхронное общение и нетворкинг с другими участникам.
- Если вам понадобится больше 1-to-1 созвонов - будем договариваться и обсуждать индивидуально.
- История, скорее всего, продлится месяца 3-4.


Всем желающим - пишите мне в личку @azshoo
Если после прочтения всего этого у вас остались вопросы - так же.

И так, друзья.
Ещё осталось несколько мест в программе менторства.
В понедельник стартуем тем составом, который будет собран и на ближайшие несколько месяцев записи больше не будет.
Да и позже, возможно, тоже. :)

Поэтому, все кому интересно - пишите в личку, с удовольствием поотвечаю на вопросы и расскажу что и как.

Всем остальным - немного терпения.
Скоро посты про менторство кончатся и я вернусь к публикации всяких полезных, на мой взгляд, штук.

Всем добра.

Это, конечно, оффтоп и совсем не по теме канала.
Но это слишком прекрасно, что бы об этом не упомянуть:

https://t.me/denissexy/3203

Пара слов про визуальное тестирование.

Так получилось, что последние несколько лет я мало занимался тестированием UI.
Верстка, лэйауты, тексты и всяческий пиксель пёрфект тестировался по остаточному принципу.
Зацепился глаз - хорошо, нет - позже исправим.

Поэтому, моё восприятие визуального тестирования и его полезности осталось на уровне многострадального Sikuli.
Использовать его было больно.
Тесты вели себя нестабильно, сравнения часто выдавали false-negative результаты, а создание, обновление и поддержка baseline сжирало кучу ресурсов.
Итоговый объем проблем от такого тестирования зачастую перевешивал профит.  

Сейчас пришлось столкнуться заново с этой задачей.
Мы довольно бодро меняем и допиливаем UI.
Здесь поменяли текст, здесь тултип добавили, здесь порядок элементов поменяли.
А здесь при мерже потеряли обновленный текст, например.
Банальное высматривание интерфейсов начинает сбоить, или требует массу времени.
При этом на продуктовых метриках последствия таких ошибок заметны.

Посмотрев, что нового появилось в области визуального тестирования за последние несколько лет я, надо признать, приятно удивился.
Инструментов появилось довольно много, начиная от надстроек над UI тестами, вроде Cypress Visual Regression и заканчивая AI-powered-модно-молодежными продуктами, типа Functionize.

После некоторого времени на ресерч и нескольких проб и ошибок, пока что остановил свой взор на Percy от Browserstack.
По двум основным причинам.
Во первых, мне понадобилось примерно 30 минут, что бы раскидывать по уже существующим E2E тестам нужные вызовы.
Естественно, чем больше специфичных кейсов ты покрываешь, тем больше времени на это тратится.
Но быстрый старт для получения первых результатов - это классная фича для любого продукта.

Во вторых, это, всё таки, semi-automated тесты, а не полностью автоматизированное тестирование.
В разных обстоятельствах это может быть и плюсом, и минусом, но в моём конкретном случае - я не хочу, что бы падение pixel-perfect проверки роняло мои тесты.
Я хочу получать репорт ввиде "вот на этом экране у вас изменился UI" и принять решение, что с этим делать.
По факту, это просто инструмент, помогающий мне найти аномалии в UI, а не тестирующий его вместо меня.

Вопросов по этому поводу, конечно, тоже хватает.

Первый и главный это, конечно, прайсинг.
Прайсинг привязанный к количеству скриншотов, которые ты делаешь в месяц - очень коварная штука.
По мере того, как продукт растёт и увеличивается количество тестов, ты начинаешь тратить всё больше денег.
А когда итоговая сумма перестает тебя устраивать, отказываться от инструмента уже не очень комфортно - всё таки уже работает и приносит пользу.

Второй - чувствительность к данным.
Любые визуальные очень сильно зависимы от контента, который ты отображаешь.
Разные объемы текстов, разные изображения, кастомизация интерфейсов - всё это рождает "другой" UI, который надо обрабатывать отдельно.
Это увеличивает количество тестовых сценариев.
Что ещё хуже - это требует гораздо более строгой подготовки тестовых данных.

Третий - фича флаги, A/B-тесты и комбинаторика состояний.
Как и предыдущий пункт, эта проблема общая для визуальных тестов.
По мере того, как вы добавляете всё новые и новые кастомизации интерфейсов, количество "уникальных" состояний каждой страницы растёт.
И даже если ты не покрываешь тестами их все, тебе нужно гарантировать, что на визуальный тест попадёт пользователь с нужным тебе набором флагов и АБ-тестов.
Для визуальных тестов поверх E2E это требует дополнительных настроек и логики, которую не всегда просто поддерживать.

В итоге, пока что всё это живёт как proof-of-concept.
Смотрим на результаты, объем поддержки и затраты и, потихоньку, собираем метрики, что бы понять, будем ли дальше развивать визуальное тестирование.

А вы пользуетесь инструментами визуального тестирования?
Делитесь опытом и впечатлениями.
Какими инструментами пользуетесь, с какими проблемами сталкивались и как их решали?

Что такое "хорошо"?

Какое-то время назад я писал пост, главной мыслью которого было "сначала делай самое простое решение, потом улучшай".
Вопросы по этому поводу всплывали в ходе менторства и уже несколько раз мне писали в личку с вопросами про то,
зачем хорошим инженерам делать "плохие" решение и размышлениями о том, что костыль, воткнутный однажды в код останется там навсегда.
Поэтому держите немного моих размышлений на эту тему.

Первое - "простое" не значит "плохое".
Это далеко не всегда костыль, говнокод и некачественная работа.
Это просто самый примитивный способ решения поставленной задачи, без усложнений, оптимизации и всяческой красоты.
При выборе алгоритма для решения задач ты всегда начинаешь с "наивного" алгоритма - самого простого и очевидного способа решить задачу.
Затем, шаг за шагом, оптимизируешь его и усложняешь исходя из потребностей и условий задачи.
Самое важное в этом процессе то, что после каждого шага у тебя остается решение, которое работает.
У тебя всегда есть возможность сравнить, чем новая версия лучше предыдущей и возможность остановиться, если дальнейшие шаги не работают.
Если ты сразу берешься за создание "идеального" алгоритма - у тебя нет ни того, ни другого.

Второе - это глобальный вопрос про то, что же такое "хорошее" решение и чем оно отличается от "плохого".
Есть люди, которым нравится думать, что программирование - это искусство.
Они хотят писать чистый, красивый и оптимизированный код, использовать интересные и элегантные решения и делать "правильно".
Потому что могут. Потому что это "правильно", красиво, классно.
Но проблема в том, что разработка ПО - не про это. Она про то, что бы используя инженерные навыки решать задачи и потребности бизнеса.
И это, на самом деле, гораздо сложнее.
Искусство существует вне ограничений.
Ты можешь двигать дедлайны, переписывать всё с нуля,
использовать какой хочешь стэк технологий, забить на документацию и писать красивый код ради красивого кода.
Инженерные задачи, в свою очередь, существуют в пространстве ограничений.
Вот тут у тебя - куча легаси в продакшене, эта задача нужна ещё вчера, а ещё тебе надо будет потом нанимать людей на поддержку всего этого, так что лучше всё таки не использовать Nim, даже если он тебе очень нравится.
Хорошим решением становится то, которое позволяет потратить меньше всего ресурсов, максимально эффективно при этом закрыв потребность бизнеса.
Писать красивый, оптимизированный и расширяемый код, когда ни одно из этих качеств не нужно - настолько же плохое решение, как и выкатывать хреново оптимизированный код, когда от него требуется производительность.

Третье - про костыли, антипаттерны и следование best practices.
Костыли, хардкод и god-object'ы не являются злом сами по себе.
Они могут генерировать риски и технический долг.
Этот код может работать менее стабильно, его может быть сложнее расширять и поддерживать.
Всё это сводится к тому, что потом тебе может понадобиться потратить больше времени на рефакторинг, разработку последующих фичей и ночные хотфиксы.
Ну, или в то, что баг в продакшене будет стоить компании кучу денег.  
При этом выбор между "правильно" и "костыльно" всегда является решением о том, нужно ли тратить ресурсы на то, что бы закрыть эти риски и технический долг сейчас,
или лучше отложить это на потом.
Здесь и проявляется то, что отличает действительно хорошего специалиста.
Способность адекватно оценить последствия каждого из вариантов, донести их до команды и бизнеса и способность вместе принять взвешенное решение.
Перекос в любую сторону, будь то "всегда втыкать костыли" или "всегда писать чистый код" - одинаково вреден.

В общем, будьте молодцами, решайте задачи бизнеса, учитесь доносить информацию до коллег, вместе принимать взвешенные решения и помните, что техническая реализация - это инструмент, а не цель.

What's  the plan?

Некоторое время назад мне задавали вопросы по поводу планирования тестирования - что вообще за тест-планы, зачем нужны, как их писать.
На самом деле, это гигантская тема, о которой можно довольно долго рассказывать, но я постарался максимально сжато и структурированно описать свои мысли на этот счёт.

Я не сторонник большого количества документации.
Это касается и проектной, и продуктовой, и тестовой документации.
Документация решает много проблем и значительно упрощает жизнь, когда тебе надо выяснить
"как вообще эта фигня вообще работает", "как это проверять" и т.д.
Она позволяет сэкономить время себе и окружающим, не дергая их вопросами и не пытаясь по крупицам
собрать знания о работе системы со всех участников процесса.
Проблема в том, что создание и поддержка документации - это огромный кусок работы,
который требует отдельных ресурсов, отдельных процессов и ещё кучу всего.
Это большое количество сложной регулярной работы, которую далеко не всегда может
себе позволить команда.
Более того, документацию тоже надо уметь писать. Что бы она была простой, понятной и информативной.
Делать это умеют далеко не все.
В результате далеко не всегда польза от документации действительно стоит тех усилий, которые команда тратит на её создание и поддержание в актуальном состоянии.

Но важно понимать, что план есть всегда.
Так или иначе, когда вы собираетесь тестировать новую фичу, релиз или продукт - у вас уже есть план.
Он может быть максимально абстрактным, неформализованным и никак не документированным, например - пройтись исследовательскими тестами по приложению и если "вроде работает", то можно релизить.
Но этого уже достаточно, что бы считаться тест планом.

Что же такое тест-план?
Тест план - это документ, призванный отвечать на три ключевых вопроса:
- Что мы планируем проверять (скоуп тестирования).
- Как мы планируем это проверять (методология тестирования и описание тестовых подходов).
- Как мы оцениваем результаты (критерии прохождения тестирования).

В зависимости от размеров команды, сложности продукта, количества зависимостей и строгости критериев качества к этим вопросам добавляется ещё несколько.
Если процесс тестирования имеет большое количество зависимостей, например разные команды должны выполнять разные этапы тестирования в строго определенном порядке - это необходимо фиксировать.
Без этого ты не только не сможешь планировать работу команд, но и несколько раз выстрелишь себе в ногу, когда команды будут блокировать друг друга из-за того, что заранее не проговорили зависимости.

Чем более комплексным является объект тестирования (и как результат само тестирование), тем более подробного описания требует методология тестирования, применяемые подходы и практики - просто за счёт увеличения объема того, что необходимо проверить.
Без этого сложно оценивать объемы работ, давать эстимейты и строить планы по релизам.

Чем более точно и строго необходимо оценивать уровень качества, тем более детально должны быть описаны критерии прохождения тестирования, ключевые метрики и quality gate`ы.
Потому что без их формализации нельзя будет однозначно оценить результаты тестирования.

Всё это - часть той самой "прозрачности качества", о которой я уже много говорил ранее.

Люди, находящиеся за пределами команды тестирования (а иногда и команды разработки в целом) хотят понимать, что вообще происходит на этапе тестирования и как обеспечивается качество продукта.
Иногда это связано с регуляторикой отрасли, иногда для согласования объемов работы с заказчиком, иногда из-за высокой степени рисков или просто потому, что работа этих людей напрямую зависит от результатов процесса обеспечения качества.
При этом бывают ситуации, когда такой потребности просто нет - у вас маленькая команда, все и так прекрасно знают и видят, что именно проверяется и как.
В таком случае документирование тест-планов может быть бесполезной тратой времени и пригодиться,
разве что, для передачи знаний новым участникам команды.

Как писать тест-планы?

Нет единственно правильного шаблона или формата для написания тест-планов.

Как и любой документ (особенно для внутреннего использования) он может быть написан миллионом разных способов и с разной степенью детализации.
Единственный критерий "правильности" - действительно ли созданный вами тест-план отвечает на те вопросы, ради ответов на которые вы начали его писать.
Более того, часто вместо описания тех или иных блоков тест-плана может быть полезнее оставить в нём ссылку на внешний документ, содержащий всю нужную информацию.
Так, Лиза Криспин, в своей прекраснейшей книжке "Agile Testing" резонно отмечает, что если тебе не нужно каждый раз переписывать тест-план с нуля для очередного релиза (а в случае с итеративной моделью разработки так обычно и происходит), то значительную
часть вопросов из тест-плана ты можешь вынести в отдельные документы - описание принципов тестирования, тестовую стратегию, quality gate`ы и прочее.

Когда их нужно писать?

Как я уже говорил выше - если вы можете обойтись без документации (её отсутствие не доставляет проблем),
значит вам не нужно её писать.
До тех пор, пока в вашей команде не появляется необходимость в документе, отвечающем на перечисленные выше вопросы - вы можете спокойно обходиться без тест-планов как отдельного документа.
Когда такая потребность появляется - подумайте, составьте список того, на какие вопросы должен
отвечать получившийся документ, кто и как им будет пользоваться и старайтесь поддерживать тест-планы настолько простыми, минималистичными и информативными, насколько это возможно.

Довольно часто встречаются команды, которые пишут "строгие" и максимально бюрократические тест-планы, с описанием кучи подходов и метрик, которые на практике игнорируются.
Иногда потому, что к команде пришли с запросом "напишите что-угодно лишь бы было", иногда потому, что людям кажется каким-то не серьезным фиксировать в документе подход "тестировщик посмотрел, субъективно оценил, ему норм".
Важно отдавать себе отчёт в том, что это крайне деструктивная практика.
Не просто потому, что рано или поздно несовпадение задокументированного процесса и реального выстрелит тебе в ногу, но и потому, что это не позволяет тем, для кого предназначается этот тест-план здраво оценивать риски и строить управление продуктом исходя из них.

Проблемы перфекционизма.

Совсем недавно у меня уже был пост про то, что зачастую "хорошее" решение задачи - это максимально простое решение из всех возможных.
Возможно, потом это решение придётся выкинуть и переписать заново, основательно отрефакторить или просто какое-то время тратить на его поддержку и сопровождение больше ресурсов чем хотелось бы.
Но в противном случае вместо того, что бы деливерить что-то полезное, ты тратишь время и ресурсы на создание "красивого" решения, которое может быть и не нужно.

Последние две недели моя команда тратит довольно много сил и времени на финальные правки по лэндингу для наших продуктов.
Это действительно важный проект, который формирует первое впечатление о компании и продуктах.
Любой UI-ный баг может стоит компании потенциальных клиентов и, конечно же, хочется что бы сайт был прекрасен и отполирован до блеска.
И вот, проходит N-ная итерация того, что называется polishing - отлавливание всяческих дизайн багов, проверка на всех возможных девайсах и браузерах, и т.п.
За это время с доски обратно в бэклог улетело несколько функциональных user stories, в очередной раз подвинулись приоритеты для юнит тестов на фронтенде, а у всех, кто над этим работает, кажется, добавилось седых волос и немножечко профессионального выгорания.

Проблема в том, что мы никогда не узнаем, стоило ли оно того.
Действительно ли неидеальное соответствие макетам могло отпугнуть потенциальных пользователей,
или им гораздо важнее было бы увидеть в списке продуктовых фичей одну из тех задач, которые мы в итоге перенесли на потом.
Действительно ли обеспечение правильной адаптивности таблиц принесёт компании больше пользы, чем стабилизация логики фронтенда за счёт большего покрытия тестами.
Так ли важен тот пользователь, который обратит внимание на используемые шрифты и из-за этого проигнорирует то value, которое продукт может ему принести?
И сколько их вообще, таких пользователей?

Мне абсолютно понятны обе точки зрения и желание сделать всё "красиво".
Но при этом я понимаю, что всегда есть куда лучше. Отполировать вот тут, добавить анимаций вот тут, а вот здесь мы посмотрели и решили что лучше будет по другому.
Это может продолжаться вечно.
Всё сводится к чувству меры и осознанию момента, когда надо остановиться и катить as is.
Это исключительно продуктовое решение, которое должен принимать человек, готовый нести за него ответственность, но так или иначе, вся команда участвует в его принятии - озвучивая проблемы, высказывая мнения, давая эстимейты и пр.
Среди QA часто встречаются те, кто в таком случае начинает негодовать, бить себя кулаком в грудь и стараться не дать команде катить в продакшен то, что, по их мнению, не надо туда катить.
Но проблема в том, что лучшее - враг хорошего.

День рождения канала и немного рефлексии.


Ровно четыре года назад я опубликовал первый пост в этом канале.
В тот момент мне просто показалось, что проще один раз написать об ожиданиях от джуниоров, чем раз за разом отвечать на этот вопрос во всех возможных чатах и сообществах.
И вот, уже четыре года я делюсь с вами своими мыслями, рассуждениями и видением того, как стоит подходить к решению тех или иных задач и проблем, куда двигаться и как помогать своим командам делать классные продукты.

За эти четыре года я получил огромное количество крутого опыта, сменил несколько работ, поменял своё восприятие многих рабочих моментов, попробовал себя в роли ментора (и продолжаю менторить желающих), начал работать над курсом по построению процессов, а количество подписчиков вот-вот перевалит за полторы тысячи человек.
Поменялась куча всего, кроме, разве что, тех самых ожиданий от джуниоров, с которых всё началось. :)

Спасибо вам всем, дорогие друзья.
За то, что читаете, что делитесь фидбэком, что поддерживаете и донатите, реквестируете темы для постов и раз за разом добавляете мотивации написать очередной пост, пусть иногда и после длительного молчания.

Следующий пост будет завтра, а сегодня - ещё раз спасибо всем, кто меня читает.

Научитесь решать проблемы правильно.

Умение решать проблемы - один из самых ценных навыков для любого члена команды.
Спектр задач и способы их решения очень сильно меняются в зависимости от занимаемой роли, но так или иначе, это именно то, зачем тебя нанимают на работу - решать проблемы бизнеса и команды.

Сложность кроется в том, что решение проблем - не только про профессиональную экспертизу, хард скиллы и знание, какими способами можно решать те или иные задачи.
Это, в том числе, и про способность увидеть проблему, проанализировать, правильно её локализовать,
сформулировать несколько возможных решений и уже после этого выбрать то, которое лучше
подойдет в текущей ситуации.
Плюс, часто эти решения нужно принимать не единолично, а значит необходимо уметь донести до коллег всю картину, разные варианты решения.
Раньше я бы назвал это способностью "продать нужное тебе решение", но на самом деле это про "помочь выбрать оптимальное", даже если лично тебе нравится другой вариант.

Про этот процесс и хочется сегодня поговорить.
Если постараться как-то систематизировать процесс решения проблемы, то его можно разделить на несколько последовательных этапов.
Первым из них, безусловно, является осознание того, что проблема есть.
Некоторые проблемы довольно сложно не заметить - продакшен чаще лежит, чем работает, спринт ещё не начался, а дедлайны по нему уже провалены, и т.д.
Другие проблемы менее очевидны.
Задачи вроде бы делаются, релизы катятся, дедлайны немножко страдают, но некритично, и вроде бы всё более-менее неплохо.
Тут можно и не заметить, что среднее количество реопенов по задачам давно уже перевалило за число Пи.
"Проблема" в данном контексте - это не про нарушение каких-то процессных или инженерных практик.
Это про то, что добавляет боли команде, негативно влияет на продукт, в худшую сторону отличается от целевой модели работы или целевых результатов.
Необходимо научиться правильно и честно отвечать себе на вопрос "действительно ли это проблема?" и почему она является таковой.

После того, как стало понятно, что что-то всё таки идёт не так, можно переходить к следующему шагу.
Локализации проблемы.
Затрагивает ли она все продукты, или это специфичная проблема одного сервиса?
Это общая проблема для всей команды или завязана на конкретных людей?
Она возникает регулярно и независимо от контекста, привязана к каким-то событиям или определенному типу задач?
Здесь важно помнить, что это не про поиск виноватых с целью всяческого порицания.
Это делается для того, что бы понять скоуп проблемы. Как часто она возникает и в каких случаях.

Когда у нас есть формализованное понятие проблемы (что идёт не так) и её скоупа (в каких случаях), можно перейти к третьему шагу.
Оценке масштабов.
Многие из вас прекрасно знают разделение на Priority и Severity в контексте оценки багов.
В случае с проблемами всё работает так же - "сколько боли приносит эта проблема" и "как часто эта проблема добавляет боли".
Отталкиваясь от этих двух параметров (подкрепленных дальнейшим анализом) нужно будет принимать решение о том, действительно ли эту проблему нужно решать сейчас и какие решения подойдут лучше.

Сложность этого шага в том, что бы постараться дать максимально адекватную оценку.
С одной стороны, она должна быть максимально измеримой - "из-за вот такой фигня мы потратили лишние N часов разработки за последний месяц".
И надо понимать, что правильно оценивать ущерб (или упущенную выгоду) от проблем и инцидентов - не самая тривиальная задача.
Я, например, знаю только две айти компании в России, у которых этот процесс более-менее поставлен на рельсы.
С другой стороны, нужно помнить о том, что есть ещё и субъективное восприятие проблем, которое точно так же может аффектить работу - "вот из-за такой фигни у нас выгорают люди, пол команды уже уволилось нафиг".

Четвертый шаг - root cause analysis, т.е. попытки выяснить почему именно возникает эта проблема.
Зашкаливающий re-open rate у задач может возникать по многим причинам: неясные требования, высокая связанность кода, отсутствие sanity проверок перед пушем в мастер, отсутствие понимания что и зачем нужно делать, вечно горящие дедлайны и необходимость сделать "прям щас" и т.д.
Часто причиной может быть сразу несколько факторов, каждый из которых определенным образом аффектит то, что создает команда.
Выделив наиболее частые и значимые из таких факторов можно понять, где и что нужно менять в процессах или системе.

Как и в предыдущих шагах здесь есть свои сложности.
В первую очередь - это способность и готовность честно разбираться в причинах возникновения проблем.
Не стараясь переложить ответственность на других, не подменяя реальные проблемы желаемыми и объективно оценивая что пошло не так.
Не скатываясь в генерализацию и глобальные проблемы разбирать конкретную ситуацию.
Не все могут честно сказать "Ну, тут я не правильно понял описание, поэтому сделал фигню", ведь мало кому нравится признавать свои ошибки, несмотря на то, что все мы их совершаем.
Второй момент - необходимость отслеживать цепочку причин и умение вовремя остановиться.
Разбираясь в том, что пошло не так можно копать всё глубже и глубже, переходя от частных проблем к более общим.
С одной стороны, это может подсветить глобальные проблемы и узкие места в процессах и продукте, с другой стороны это может увести от проблем, которые можно решить быстро и просто, в сторону глобальных историй, которые не получится поменять за один день, месяц или год.
Здесь важно поддерживать баланс и отслеживать точки, в которых ты действительно можешь что-то поменять.

Пятый шаг - формирование ожидаемого результата для решения.
Благодаря предыдущим шагам у нас уже есть понимание того, как выглядит "плохо" работающее решение и того, как оно влияет на конечный результат работы.
Теперь задача в том, что бы сформировать понятное представление о том, как выглядит "целевое" решение, т.е. точка в которую нам хочется придти, что бы процессы или продукт работали лучше.
Вместе с этим мы формируем и критерии оценки этого решения - как мы будем отличать "плохое" от "хорошего" и какие метрики покажут, что вносимые изменения действительно приближают нас к целевому результату.
Как и с любыми целями - важно, что бы у вас были конкретные и измеримые метрики, с которыми можно будет сравнить результат.
Без этого понять стало ли лучше, или вы только усугубили проблему внесенными изменениями, невозможно.

Шестой шаг - формирование решений.
Каждую проблему, будь то инженерная или процессная задача, можно решить разными способами.
На основе всех данных, которые были собраны выше, мы можем сформировать несколько решений и оценивать их по ответам на ряд вопросов:
- Как это решение поможет устранить, или по крайней мере снизить, количество проблем в точках A, B и C?
- Какой результат мы ожидаем получить, т.е. насколько сформированные ранее метрики должны сдвинуться в сторону целевого состояния?
- Насколько масштабные и трудоемкие изменения требуются, что бы это сделать?
- Какие есть возможные проблемы и сайд-эффекты от реализации?
Обладая таким набором данных по каждому из возможных решений, выбрать то или иное становится значительно проще, а шансы получить позитивный эффект от реализации возрастают, просто потому, что часть гипотез, на самом деле не способных помочь в решении этой проблемы, отвалится на этапе обсуждения и оценки.

Нужно помнить, что совсем не обязательно браться сразу за самое "эффективное" решение.
Выбирая между масштабным изменением процессов, которое замедлит весь цикл разработки, но позволит
снизить re-open rate почти до нуля, и примитивным, быстрым решением, которое поможет снизить его на 20% - довольно часто стоит начать со второго.
Просто потому, что ты получишь положительный эффект быстро и относительно безболезненно, после чего сможешь переключиться на более приоритетные проблемы, или продолжить постепенно двигаться в нужном направлении.

Седьмой шаг - реализация и оценка результатов. Решение выбрано, ожидания от его реализации сформированы, остается только взять и сделать.
Но, так же важно не забывать о том, что результат любых изменений необходимо отслеживать.
Действительно ли внесенные изменения помогли вам приблизиться к цели, насколько правильным был прогноз эффекта, которые эти изменения должны оказать, нужно ли работать над этой проблемой дальше, или можно считать что на текущий момент она решена.
Всё это нужно не только для того, что бы избежать "изменений ради изменений", которые не несут реальной пользы, а лишь создают иллюзию того, что над проблемой работают, но так же и для того, что бы анализировать и калибровать процессы работы над проблемами.
Если раз за разом принятые вами решения не приносят эффекта, или эффект от них хуже, чем вы рассчитывали - значит где-то в процессе локализации проблем или формировании решений кроется ошибка.
Возможно, вы ушли не туда в поисках root cause. Возможно, вы даете слишком оптимистичные оценки и прогнозы.
В любом случае, нужно видеть ROI от тех изменений, которые вы вносите - сколько времени и ресурсов было потрачено, какие результаты были получены и чего не хватило, что бы получилось лучше.

Ещё один момент, который важно понимать - этот процесс может быть бесконечным и не всегда решения будут помогать.
Всегда есть куда улучшить продукт, процессы или работу команды. Целевой результат, к которому хочется придти, всегда будет эволюционировать по мере того, как вы к нему приближаетесь.
И, конечно же, ошибаться и принимать решения, которые делают только хуже - нормально.
Всё, что нужно - это работать над тем, что бы процент таких решений постепенно снижался, а узнавали вы об их существовании как можно раньше, просто что бы снизить количество потраченных зря ресурсов.

Что можно почитать по этому поводу:
1. Root Cause Analysis.
Здесь есть много статей и книжек, разной степени детализации и объема.
Можно начать с обзорных статей и сборников, вроде этого, почитать про связанные с RCA техники, вроде 5 Whys, 6 Sigmas, диаграммы Ишикавы и пр.
The New Science of Fixing Things

2. Problem Solving и System Thinking.
Как и с предыдущим пунктом, местами всё довольно сложно.
Большинство материалов по этому поводу довольно далеко от айти, а местами вообще похоже на какой-то коучинг "успешных успех за 30 дней".
При этом надо понимать, что интересных тезисов, практик и подходов, которые можно применять в работе там всё равно описано довольно много.
Что бы я посоветовал?
- Problem Solving 101 от Ken Watanabe
- Strategic Thinking от Шевалье
- Reengineering the Problem-Solving Process

3. Quality Management.
Управление качеством довольно тесно связано с поиском и решением проблем, анализом инцидентов и их влияния.
Неплохой сборник статей, в т.ч. про Quality Management, есть вот тут.
- Software Testing and Continuous Quality Improvement
- An Executive’s Guide to Software Quality in an Agile Organization
- Metrics and Models in Software Quality Engineering

Очередной занимательный и полезный пост от Феди Борщева про прорисовку и визуализацию сервисов, систем, архитектуры и всего остального.
Как это обычно и бывает - большинство этих вещей ты уже знаешь и, так или иначе, используешь.
Но стороннее мнение и опыт часто помогают немного структурировать всё это в голове и более осознанно подходить к использованию разных инструментов.

Для меня пост оказался вдвойне полезен, потому что выходные как раз прошли за прорисовкой архитектуры, сценариев и моделей данных для очередного pet project, который должен захватить мир.

В общем, советую.
И сам пост, и ссылочки к нему прилагающиеся.

Задачу нормально поставьте.

Многие разработчики и тестировщики очень не любят работать с плохо проработанными задачами.
Неустанно повторяя древнюю мантру про "нет ТЗ - ..." они выступают на конференциях с рассказами о том,
как классно у них получилось перевоспитать аналитиков и менеджеров, что б им приносили хорошо проработанные задачи.
Или наоборот делятся болью в профессиональных чатиках мол "бардак, прилетают задачи без описания".

Меня эти дискуссии неизменно печалят.
В основном потому, что многие люди действительно считают, что вот так - это хорошо, а по другому - это плохо.
Реальность, конечно, немножко сложнее.

Тут есть несколько моментов, о которых надо помнить.

Первый:
Каждый раз, когда вы хотите, что бы вам принесли идеально проработанную задачу - вы просто перекладываете ответственность.
Вы хотите упростить себе жизнь, не ломая голову над тем, что от вас хотят, избежать всех этих уточняющих вопросов и, заодно, минимизировать риски.
Что бы если к вам придут и спросят "почему это работает вот так?" можно было просто сказать "я сделал как в ТЗ было написано".
В желании упростить себе жизнь нет ничего плохого, но надо понимать, что в данном случае вы делаете это в ущерб команде и продукту.
Потому что ответственность, риски и проблемы вы снимаете с себя, но перекидываете на кого-то другого.

Второй:
Каждый раз, требуя детальное ТЗ вы сужаете собственное пространство решений.
Сначала люди жалуются, что хотят идеально проработанные задачи, потом сокрушаются, что их работа - это бездумное перекладывание джейсонов между моделями данных.
Но если задуматься, то вы самостоятельно загнали себя в ситуацию, когда у вас нет пространства для творчества и свободы выбора.
Потому что свобода выбора напрямую связана с ответственностью за принимаемые решение, от которой вы так старательно открещивались, требуя идеальной проработки задач.

Третий:
Способность (и готовность) работать в условиях неявных требований - это конкурентное преимущество.
Даже при хорошо отлаженных процессах  требования всегда будут неполными.
Задачи без описания и definition of done "Работает хорошо" будут периодически появляться.
Вопрос только в том, какую цепочку проработки они будут проходить прежде, чем окажутся в продакшене.
Переоткрывая задачу в формате "требования опишите нормально" вы просто докидываете ещё одно звено в эту цепочку и увеличиваете time to market.
Инженеры, способные получить слабо формализованную задачу, взять за неё ответственность и выдать результат ожидаемого уровня качества - на вес золота.
Они стоят гораздо дороже и ценятся компаниями гораздо выше, чем инженеры, просто транслирующие ТЗ в код.

Помните, что разные подходы работают для разных команд.

Я много работал с ребятами, которым можно было поставить задачу в формате "сделай вот такую вот фигню" и быть уверенным, что человек её сделает хорошо.
За счёт технической экспертизы, за счёт погружения в продукт, за счёт взаимопонимания и cultural fit, за счёт наличия софт-скиллов и способности вовремя задать вопросы, если возникают проблемы.
Но, этот подход плохо масштабируется.
Собирать такие команды долго и дорого.

Классический подход "вот вам супер-подробное ТЗ, превратите это в код" - обратная крайность.
Это стандартные проектные рельсы, которые легко масштабировать и можно получать прогнозируемый результат.
Минус в том, что результат - средненький, скорость - тоже.
Создать что-то действительно классное с таким подходом довольно сложно.

И, конечно же, есть целый спектр промежуточных состояний.
Все они по разному подходят для разных команд, разных продуктов и разных этапов жизни компании.
В этом, собственно, и основной поинт, который хотелось бы донести:

Детально проработанные задачи могут нести за собой не меньший набор проблем и ограничений, чем задачи, прилетающие без описания вообще.

Поэтому, каждый раз, когда слышите истории успеха и сладкие речи про идеально проработанные ТЗ и вот это всё - задавайтесь вопросом, а действительно ли это плюс?