План ревью

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

Что это такое и с чего начать

Рецензия — это критический анализ и оценка культурного объекта, написанная в научном или публицистическом стиле.

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

• цитаты из произведения;
• подтверждения из других источников;
• мнения экспертов;
• факты общественной жизни (если книга их искажает или противоречит им).

Поэтому перед тем, как начать писать рецензию на книжку, обязательно прочтите ее. Чтения «по диагонали» или знакомства с кратким содержанием для хорошей рецензии недостаточно. Только полное (а лучше неоднократное, с выделением ключевых моментов) прочтение позволит сформировать собственную оценку и подтвердить ее доказательствами.

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

План рецензии на книгу

Чтобы правильно написать рецензию на книгу, советуем придерживаться следующего плана:

1. Библиографическое описание (название, автор, его предыдущий опыт, год выхода книги, объем, издательство).
2. «Технические» характеристики: дизайн, обложка, иллюстрации.
3. Краткий пересказ сюжета (без «спойлеров» или раскрытия главной интриги).
4. Художественные особенности литературного произведения.
5. Личные впечатления от прочитанного.
6. Аргументация этих впечатлений: разбор содержимого.
7. Главные преимущества и недостатки книги.
8. Вывод о том, стоит ли читать книгу, насколько она интересна/полезна и для какой аудитории.

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

Структура рецензии на книгу

Перед тем как написать рецензию на книгу, проверьте, владеете ли вы информацией, чтобы дополнить все структурные элементы работы:

• данные об авторе (псевдоним/настоящее имя, годы жизни, творческое наследие);
• сюжет книги (герои, их высказывания и поступки);
• цитаты, характеризующие проблематику книги и идеи автора;
• собственное мнение о книге, которое будет подтверждено доказательствами.

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

Что касается объема работы, то оптимальным считается 2000-4000 знаков.

Для наших читателей сейчас действует скидка 10% на любой вид работы

Правила написания рецензии на книгу

Чтобы написать хорошую рецензию, которая будет интересна другим читателям, придерживайтесь нескольких правил:

1. Внимательно прочитайте книгу, желательно 2 или 3 раза (да, мы уже говорили об этом, но это действительно важно).
2. Личное мнение о прочитанном подтверждайте отрывками текста.
3. Формируйте окончательную оценку, не путайте читателя неопределенностью.
4. Анализируйте конкретный текст, а не книги автора в целом.
5. Указывайте целевую аудиторию книги.
6. Не допускайте грамматических и фактических ошибок, тщательно проверяйте материал (вот где пригодятся подчеркивания, закладки и стикеры: с ними вы быстро найдете нужное место).

Рецензия на книгу на английском

Особое внимание стоит уделить рецензии на книгу на английском языке:

1. Убедитесь, что в книге не осталось неясных слов и вы все поняли верно.
2. Если есть возможность, ознакомьтесь с официальным русским переводом.
3. Проверьте транскрипцию перевода имен героев (из-за невнимательности переводчиков Уотсон может на долгие годы стать Ватсоном).

Ошибки, которые помешают правильно написать рецензию на книгу

Главная ошибка начинающего рецензента — излишний субъективизм. Чтобы не допустить этого, придерживайтесь следующих рекомендаций:

1. Не беритесь за рецензию на книгу, в теме которой не разбираетесь.
2. Не увлекайтесь пересказом сюжета, ваша задача — сделать анализ.
3. Приводите достаточное количество аргументов, не заменяйте их эмоциями.
4. Не употребляйте жаргонные слова, используйте нейтральную лексику и придерживайтесь делового тона.
5. Помните, что вы пишете рецензию на книгу и не переходите на личность автора. Не позволяйте мнению о писателе влиять на отзыв о его работе.

Пример рецензии на книгу

В сети можно найти шаблон и образец рецензии на книгу. Рекомендуем обратить внимание на рецензии, выложенные на сайтах издательств (например, Альпина).

Помните, что залог хорошей рецензии — интересное начало. Не допускайте банальностей вроде «Несколько дней назад в свет вышла новая книга известного автора». Лучше начните с необычного факта: «Согласно статистике тату-салонов, наибольшей популярностью у женщин пользуются татуировки семейства кошачьих: львов, тигров и обычных кошек. Тем не менее, самой популярной книгой 2009 года стала «Девушка с татуировкой дракона» шведского автора Стига Ларссона».

То же касается и завершения. Вместо традиционного «Книга будет интересна любителям остросюжетных детективов», напишите «Книгу наверняка по достоинству оценят те, кто не боятся интеллектуальных вызовов и готовы сражаться за правду вместе с обаятельным сыщиком».

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

Что такое перформанс ревью и с чем его едят?

Сегодня мы с вами начинаем погружаться в Performance Review (далее по тексту ревью или PR) — любимым на Западе методом повышения эффективности персонала за счет индивидуальной оценки рабочего периода с упором на сотрудника. Сразу стоит отметить, что мы из мира IT, поэтому все примеры будем приводить оттуда, но эта практика так же подходит многим другим командам, занимающихся интеллектуальным производством. Для этого мы подготовили для вас цикл из трех статей, охватывающих как теоретическую часть вопроса, так и практические рекомендации. В этой статье мы расскажем, что же такое Performance Review, как его проводят и ради чего вообще затевают всю эту кашу. В следующих частях мы окунемся в суровые эйчарские будни и поговорим о том, как же стоит подходить к самым непростым моментам в создании своего ревью. Подробно затронем как методологию и вычисления, так и способы внедрения практики или варианты проведения 1:1. Уверены, будет познавательно как тем, кто только собирается запускать перформанс ревью, так и для эйчаров/тимлидов/деврилов, желающих проверить свою систему оценки.

Что это такое?

Как уже было сказано, PR — ретроспективный процесс, направленный на оценку сильных и слабых мест каждого сотрудника и компании в целом. Проводится он обычно в формате опросов 180 или 360 градусов, то есть оценку сотрудника вы получаете как от него самого, так и от коллег и начальства — количество и роли оценивающих на ваше усмотрение. Формат и методология разнятся от компании к компании и жестких требований к ним нет — каждый бизнес на основе своих моделей компетенции и метрик процесса сам решает, что же оценивать в своих сотрудниках. Как правило, в рамках одного ревью проводят опрос, анализ результатов и индивидуальные встречи, итогом которых становится план развития — об этом чуть позже, а сейчас..

Зачем это делают?

Казалось бы, интуитивно понятно, зачем бизнесу оценивать своих сотрудников. Однако, если вы попробуете сами для себя составить список выгод от внедрения системной оценки, то после 3-4 пункта, пополнить список станет непростой задачей. Поэтому, мы решили отдельно остановиться на причинах и выгодах от проведения перформанс ревью. Надеемся, что некоторые пункты дадут вам пищу для размышлений. Итак, почему компании внедряют Performance Rewiev:

• Performance Review это средство напомнить людям о важности некоторого набора параметров/метрик. В случае с IT и профильными специалистами это могут быть качество кода, качество коммуникации, соблюдение сроков и т.п. Так вы не только будете держать коллег в тонусе, но и намекнете им о том, что же от них ждет компания.
• PR это средство профессионального развития сотрудников. Ревью позволяет сравнить самооценку сотрудника и мнение окружающих, на основе этого выделить точки профессионального роста
• Это средство контроля за производительностью труда и производственными событиями.
• PR используют как часть систем well being — признание заслуг/провалов в работе очень важная и недооценённая практика в России.
• Ревью может быть средством обмена мнениями между компанией и сотрудником.- PR — индикатор неявных проблем в компании — системных, межличностных или личных. Вы не только получаете срез состояния дел в компании, но и можете замечать недовольство отдельными сотрудниками или конфликтующих между собой людей.

Шаг нулевой — готовим почву

Метрики и опрос

Итак, в начале текста мы с вами проговорили, что источником информации для оценки сотрудника являются сразу несколько людей — его начальники, коллеги, подчиненные. Можно по старинке собирать информацию в личных беседах, а можно переместиться в 2022 год и проводить опросы. Для этого, кто-то использует бумажные анкеты, кто-то переносит опросники в гугл-формы, а наиболее продвинутые уже пользуются специальными сервисами. Про инструменты поговорим в конце нашего цикла, сначала давайте о содержании. В каждой компании понимают, какие именно компетенции, хард скиллы и поведение они ожидают от сотрудника в зависимости от его должности и уровня. Возможно, у вас уже имеются модели компетенций для каждой из позиций, а может быть только образ идеального сотрудника в голове — в любом случае, именно на основе этой информации мы и определяем набор ключевых метрик для оценки сотрудника. Составьте список как общекорпоративных, так и узкоспециальных метрик, а затем оставьте где-то 10-15 из них — они и лягут в основу перформанс ревью. После того, как вы определились с метриками, вам необходимо составить опрос, который позволит оценить каждую из них. Для этого, вам необходимо придумать вопрос, ответом на который будет оценка соответствия оцениваемого вашему образу идеального сотрудника в контексте конкретной метрики. Задайте контекст в теле вопроса, либо в вариантах ответа — так респондентам будет проще понять, с каким именно образом сотрудника нужно сравнить человека. Ну а затем — создайте свой опрос или анкету и распространите ее среди оценивающих. Дальше вы будете работать уже с результатами и самим оцениваемым. Важным аспектом performance review является привязка к рабочему периоду. Компании оценивают не просто навыки сотрудника, а то, как он проявлял их в в последнее время. Поэтому, советуем вам проводить ревью почаще, чем раз в год — не только людей в тонусе держать будете, но и информация, с которой вам работать, будет свежей. Конечно, мы тут очень поверхностно поговорили о методологии ревью. Но мы отложим это на нашу вторую статью, в которой мы подробно разберем вопросы, вызывающие у эйчаров большинство трудностей. А сейчас предлагаем переместиться в недалекое будущее — вы провели опрос и теперь думаете, что же вам делать дальше:

Обработка результатов — тайное становится явным

Допустим, у вас не очень большая айти-компания, а целью ревью были только разработчики — человек так 25. Давайте посчитаем, что же вы получите — после проведения опроса у вас на руках окажутся по одной анкете с селф-ревью, оценка от менеджера (допустим, ПМа), техлида и, опять же допустим, трех коллег. В сумме это даст 150 заполненных анкет — целая гора! А для эйчара, который в таких компаниях обычно один, это не одна неделя работы по разгребанию и сведению всей полученной информации. Многие сейчас примерили ситуацию на себя, оценили предстоящий объем работы и непроизвольно повели курсор к крестику на вкладке браузера. Однако же не торопитесь, не все так страшно и тяжело. В первую очередь, на помощь вам придут инструменты автоматизации. Даже используя бесплатные и всем привычные гугл формами и экселем, вы ускорите подсчет многих результатов. Особенно гладко это пройдет, если вы использовали шкальные вопросы — численную оценку соответствия оцениваемого и метрики. Но даже если вы использовали вопросы с вариантом ответа, у вас все равно есть некоторая градация от “близок к идеалу” до “все очень плохо”, а значит вы тоже можете закодировать ответы, присвоив каждому из них оценку. Итак, ваши ответы превратились в баллы — на что стоит смотреть? В первую очередь вы оцениваете человека — а значит вас должна интересовать его средняя оценка, желательно в сравнении с средним баллом коллег на той же позиции. Если у позиции есть более важные компетенции, то точно так же вы можете сравнить оценки сотрудника и коллектива по ним. К тому же, обратите внимание на развернутые ответы (а для этого включите один или несколько открытых вопросов с просьбой добавить информации о том, что не было охвачено опросом). Пройдитесь по похвалам или критике, сделайте небольшой дайджест — и вы не только поймете место сотрудника относительно его коллег, но и получите дайджест обратной связи от тех, кто с этим человеком работает и видит гораздо больше. В дальнейшем, когда ваши требования к PR возрастут, вы можете добавить систему весов, смотреть на корреляции финансовых показателей/eNPS и метрик ревью и многое другое. Звучит непросто, но вполне достижимо, особенно если есть у кого проконсультироваться (подмигивающий смайлик). Аппетит приходит во время еды, так что начните с простого, а дальше вы и сами не сможете отказаться от использования всего потенциала PR.

1 с сотрудником — закрепляем результаты

Как мы обозначили в начале нашей статьи, целью перформанс ревью является уточнение позиции и роли человека в коллективе и формирование планов его развития, лично проговоренных и принятых в работу. Для этого, заключительным этапом является встреча в формате 1:1 между оцениваемым и человеком, ответственным за проведение ревью (условно эйчаром). Что же должно произойти на этой встрече и как стоит к ней подготовиться обоим участникам?Первым шагом подготовки может стать запуск рефлексии у участников опроса — поделитесь с ними личными результатами в сравнении с средними значениями в коллективе. Можете включить в результаты и обратную связь от оценивающих (анонимно, если хотите). Укажите на разницу значений с предыдущим performance review. Таким образом, еще до начала ваших 1:1, сотрудники будут понимать свой результат и будут более подготовлены к диалогу. К тому же, оцениваемые смогут заранее подумать о том, как же им лучше использовать свои сильные стороны и улучшить слабые — их мнение тоже стоит учитывать при планировании их ближайшего будущего. Непосредственно на собрании следует обсудить обратную связь, поступившую из опроса самооценки человека — что его беспокоит, что ему нравится или не нравится и как можно исправить негативные моменты. Заодно вы сможете узнать о чем-то, что не вошло в опрос по той или иной причине. Затем перейдите к обзору обратной связи от его коллег — обсудите достоинства и недостатки человека в глазах его начальства, коллег и подчиненных и оцените степень согласия с взглядом на себя со стороны. Возможно, в ходе разговора вы или сотрудник измените взгляды на те или иные аспекты его работы, что позволит вам скорректировать как оценку, так и планы в отношении сотрудника.

Немного о постановке целей

От планов развития сотрудника вы ожидаете выполнения в оговоренные сроки. И в какой бы мягкой форме вы бы ни проводили ваше перформанс ревью, все же стоит зафиксировать договоренности — так они будут восприниматься гораздо серьезнее. Если вы используете OKR, ваши цели можно оформить соответствующим образом и включить в задачи сотрудника. Если нет — просто попросите записать их на бумаге/доске в ходе разговора (и перепишите их себе, забыть может не только респондент). И если вы видите прогресс по этим пунктам — не забывайте его отметить, пусть даже словами — это мотивирует работать и развиваться дальше, в том числе и самостоятельно, без толстых намеков от лида/эйчара. Ваши сотрудники должны понимать, что все эти на первый взгляд обременительные и усложняющие им жизнь телодвижения нужны не только начальству, ваша работа направлена на то, чтобы им лучше жилось и работалось. Поверьте, люди оценят ваши намерения и непременно вас за них отблагодарят. И напоследок, связывать ли окончание ревью с материальными бонусами или повышениями — вопрос дискуссионный, однако мы не советуем: практика показывает, что такая привязка искажает отношение сотрудников к процессу, сводя его к своеобразной “сдаче экзамена” ради получения выгоды.

Все ли так просто?

В «Лиге А.» в конце января прошло ревью по методу «360°», направленное на оценку каждого сотрудника его коллегами и руководителями.

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

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

Для «Лиги» это исследование стало не первым. Мы проводили подобное ревью около года назад, когда в команде было 8 человек, в тот раз тест показал себя не очень эффективным, хотя это не стало для нас сюрпризом.

Тогда для нас важнее было обкатать технологию. 360° помогает получить по-настоящему полезную информацию, когда в исследовании участвует достаточное количество людей (начиная от 20). Если коллектив маленький, всё и так довольно прозрачно: у кого какие слабые и сильные стороны.

Мы специально не повторяли ревью, пока команда не достигла 20 человек. В крупных компаниях такие исследования проходят раз в полгода. А мы маленькие, но очень быстро набираем обороты, и для нас его можно проводить раз в три-четыре месяца. Это как раз совпадает с нашими запланированными циклами развития каждого сотрудника.

Я хочу, чтобы ребята оставались в команде «Лиги» надолго и при этом имели возможность развиваться внутри компании. В этом смысле ревью — это повод и напоминание о том, что нужно всегда продолжать прокачивать свои скиллы.

Зачем нам это нужно

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

И как тогда понять, что происходит в команде на уровне каждого сотрудника: кто тянет работу за двоих, а кто отстает, не понимая своих точек роста?

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

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

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

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

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

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

Например, в «Лиге» у менеджера проектов основные скиллы — умение планировать ресурсы на проекте, понимание сферы, в которой он работает, способность действовать в условиях изменений, а также навыки общения с клиентом, отработка негатива.

Коммуникация, доверие, авторитет — эти пункты оценивались у каждого сотрудника. А дальше шло разделение: у менеджеров смотрели на менеджерские скиллы, навыки работы с клиентом, у тестировщиков — на тестирование. Если это руководитель тестировщиков, у него оценивались как навыки тестирования, так и навыки управления.

Как мы выбирали, кто будет оценивать

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

Мы придерживались принципа, что сотрудника должны оценивать все его непосредственные подчиненные (если такие есть), его непосредственные руководители и горизонтальные коллеги, с кем он постоянно или периодически взаимодействует.

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

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

Как мы собирали обратную связь

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

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

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

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

Анонимность — обязательная составляющая ревью. Ни на одном из этапов, в том числе при проверке анкет, ни одна из сторон не знает, кто именно заполнял анкету (кроме заполненных на себя).

Как проходило ревью

Активная фаза исследования длилась в «Лиге» на протяжении суток. Индивидуально подобранный список анкет для заполнения был выслан каждому сотруднику в шесть вечера одного дня, и через 24 часа все результаты оказались у меня на руках.

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

Сначала люди оценивали свои собственные профессиональные качества, затем переходили к оценке коллег.

По итогу ревью каждый сотрудник Лиги получил табличку со своими баллами по каждой из шкал – усредненные результаты того, что о его качествах думает команда. Для наглядности были сформированы графики в виде паутинок, наложенные друг на друга: как тебя оценили, и как ты сам себя оцениваешь.

Если между графиками сильная разница — это повод задуматься о том, насколько ты адекватно себя воспринимаешь. Если человек оценивает себя выше, чем его оценивает команда, у него есть слепые зоны: он думает, что все ок, а на самом деле это не так. От ревью к ревью слепые зоны должны закрываться, а личностные результаты сотрудника — улучшаться.

Наши плюсы и точки роста

Исследование показало, что у нас в «Лиге» почти максимально высокие показатели по трем пунктам: доверие друг к другу, готовность прийти на помощь и комфорт коммуникации. Еще одна наша маленькая общая победа – всех руководителей высоко оценили с точки зрения авторитета и эмпатии.

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

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

А низкие баллы в «Лиге» чаще всего ставили за энергичность. И, пожалуй, к этому сложно придираться, потому что уровень энергичности относится к врожденным психологическим качествам человека. При этом в нашей компании менеджеру нужно стремиться быть активным, чтобы продвигаться по карьерной лестнице.

Еще нередко низкие баллы ставили за вклад сотрудников в развитие отдела. Сейчас у нас в команде над улучшением процессов чаще задумываются руководители среднего и высшего звена.

Мне бы хотелось, чтобы компания развивалась за счет оптимизации процессов. Если тебе что-то неудобно и это можно исправить, скажи.

У нас не жесткая система, где сотрудники приходят и тупо сидят перед своими мониторами, боясь на 10 минут отвлечься от рутины. Есть возможность улучшить, придумать, развить. Инициатива принимается исключительно благосклонно.

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

Что мы сделали не так и хотим поменять

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

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

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

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

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

Еще мы решили отказаться от десятибалльной системы оценки в пользу шестибалльной. Десять баллов — слишком большой разброс, оценки могут быть невалидными. При этом мы подготовим общую интерпретацию каждого балла.

Также в конце каждой анкеты будет добавлено поле, где в свободной форме можно будет написать мнение о сотруднике, добавить штрихи к его профессиональному портрету, пожаловаться или похвалить.

Для анкетирования мы хотим подобрать сервис, который будет быстрее и удобнее Google-форм.

Любая продуктовая команда регулярно проводит встречи с реальными клиентами, чтобы собрать обратную связь, выявить проблемные зоны, проверить гипотезы и получить инсайты. Ценность таких систематических ревью в личном контакте разработчиков с пользователями, проявлении эмпатии и понимании для кого делается продукт. Но что делать, когда встречаться лично больше нельзя? Рассказываю все, что нужно знать об идеальном ревью, какие лайфхаки использовать, как быстро и качественно организовать интервью с клиентами в офисе и удаленно.

Ревью с клиентами, или, как мы иногда называем такие неформальные встречи, Pizza Testing, нужны для того, чтобы понять, насколько вашим продуктом или сервисом удобно пользоваться в текущий момент времени. Исследования, которые запускаются под конкретную задачу, обычно проводятся не так часто – раз в квартал, полгода, год. Однако для команды, которая постоянно делает новое, выпускает релизы, ищет баги и исправляет их, этого мало. Ей нужно постоянно быть на связи с конечными пользователями. Один из инструментов для этого – ревью с клиентами. Как любое другое ревью, оно проводятся часто – один-полтора раза в месяц. Pizza Testing выявляет даже самые мелкие нюансы опыта взаимодействия с продуктом и дает команде возможность быстро проверить гипотезы потребностей и решений.

Как проходят ревью Pizza Testing

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

Первый ответственный этап интервью – это активация. Его задача разговорить, раскрыть респондента, настроить на доверительное общение, чтобы получить максимум полезной информации. На этот этап в зависимости от категории и личных качеств респондента уходит от 10 до 15 минут.

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

Третий этап – валидация гипотез. Команда заранее готовит список гипотез на проверку, а также вопросы, которые помогут их подтвердить или опровергнуть. К примеру, мы предположили, что клиенты не хотят менять банк, так как им придется вручную переносить данные всех контрагентов. Вопросы будут строиться вокруг этой гипотезы. К примеру: «Что может подтолкнуть вас к решению сменить банк?», «Как вы переносите данные партнеров из одного банка в другой?». Обычно на ответы достаточно 20-30 минут.

После интервью с клиентами команда вносит найденные инсайты и баги в сводный документ для приоритезации – ICE (Impact, Confidence, Ease). Веса могут распределяться по-разному в зависимости от целей команды, различных обстоятельств. Помимо стандартных критериев, таких как продажи, UX, сложность реализации, мы учитываем повторяемость – насколько часто клиенты упоминали эту проблему. Такой документ удобно передать другой команде, если в ходе исследования вы обнаружили инсайты, которые могут заинтересовать и ее.

Основные выводы исследования входят в отчеты, доступные всем сотрудникам банка на внутреннем портале.

Что нужно для организации Pizza Testing в обычной жизни

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

Проведите как минимум три встречи с командой перед ревью с клиентами. Первую, установочную – в начале спринта (в нашем случае — за 2,5 недели), чтобы все участники точно зафиксировали время в календарях и не вышло ситуации, что все респонденты придут уже завтра, а половина команды не сможет. Вторую – для проработки скрипта интервью с респондентами. Ее лучше провести за неделю до исследования, чтобы было время на получение обратной связи от команды и владельца продукта. Третью, статусную – за один-два дня до ревью. На ней команде нужно сообщить, что реcпонденты найдены, все в силе, ответить на вопросы, если такие будут. На первую и последнюю обычно уходит не более 15-30 минут.

Вовлекайте в общение с клиентами всю команду, а не только исследователей и дизайнеров. Это повышает уровень эмпатии команды к клиенту и понимание какие проблемы у клиентов есть при взаимодействии с продуктом и сервисом не по наслышке.

На каждого респондента должно быть два человека из команды: один общается и задает вопросы по скрипту – обычно это владелец продукта, дизайнер или исследователь; второй фиксирует ответы – нередко вызываются разработчики. Организацией всего процесса занимается обычно активный и инициативный коллега или, как мы его называем, мэйнтейнер.

В подавляющем большинстве случаев достаточно 5 респондентов. Ребята из Nielsen Norman Group еще в 2012 году доказали, что тестирование 5 человек позволит найти почти столько же проблем с юзабилити, сколько вы нашли бы с гораздо большим количеством участников, при этом соотношение выгоды-затраты будет оптимальным. Наш опыт это подтверждает, поэтому на свои ревью мы приглашаем 5 основных респондентов и 2 запасных – на случай, если кто-то не сможет.

Поручите подбор респондентов опытному сотруднику. Очень важно, чтобы профиль респондента четко соответствовал гипотезам, которые вы хотите проверить, иначе команда потратит деньги и время впустую. К примеру, нам важно, чтобы в выборку попадали люди в возрасте 25-50 лет обоих полов, которые активно пользуются мобильным или интернет-банком (в зависимости от того, что проверяем), то есть самостоятельно совершают не менее трех платежей в неделю – это константа, отражающая профиль нашего клиента. Но если у команды есть гипотезы, например, связанные с переходом клиентов в другой банк, то среди респондентов должны быть люди с релевантным опытом. Работать над профилем и брифовать агентство на поиск участников (в случае, если вы поручаете это не штатному рекруту) должен опытный сотрудник, иначе вы рискуете не получить ничего ценного по итогам Pizza Testing.

Составляйте чек-листы и пользуйтесь ими. Чек-лист поможет не забыть о мелочах, которые могут обернуться небольшой неприятностью, а могут –настоящей катастрофой для результатов исследования. Забронировать просторные переговорки; заранее поставить встречу в календарь; создать чат рабочей группы, куда могут входить люди из разных команд банка; предупредить ресепшн; добавить телефоны респондентов в контакты; подготовить все необходимое, в том числе оборудование для записи, – вот только скромная часть чек-листа. Им можно поделиться с другими командами, чтобы не наступать на одни и те же грабли, или вооружить новичка, чтобы не переживать за исход встречи.

Корректировка на удаленку

Что изменилось на удаленке, помимо того, что встречи «переехали» из переговорок в Zoom и всем стало удобнее: клиентам не нужно тратить время на дорогу, а команда может проводить интервью с респондентами более эффективно и меньше уставать? Проводя исследование удаленно, нельзя показать клиентам новые возможности в тестовой среде банка, потому что доступ к ней есть только с корпоративных устройств. Выхода два: выводить функциональность в прод на тестовых пользователях или отправлять респондентам ссылку на прототип в сервисах для разработки интерфейсов, в нашем случае – Figma.

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

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

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

Принцип «Пяти почему»

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

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

Принимайте все, что говорит респондент о компании, а не только то, что касается вашей команды. Бывает, что клиент начинает делиться с вами всем, что накопилось за время взаимодействия с банком: в отделении не помогли, сотрудник контакт-центра неправильно проконсультировал и так далее. Не стоит говорить ему, что вас это не касается, ведь с точки зрения клиента вы в первую очередь представитель организации, а уже потом дизайнер мобильного банка или front-end разработчик.

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

Иногда респонденту нужно выговориться. Если клиент во время ответа уходит в сторону, не спешите прерывать его и задавать другой вопрос. Это может испортить доверительный настрой. Постарайтесь «провалиться» в то, что он рассказывает, найти в этом полезное, дайте выговориться и только потом плавно возвращайтесь в нужное русло.

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

Интервью с клиентами не даются легко, это сложная, не всегда самая приятная часть работы продуктовой команды. Однако очень полезная и абсолютно необходимая. Помимо основной задачи – быстро выявить проблемы и проверить гипотезы – Pizza Testing выполняют ряд других, не менее важных для команды функций. Они помогают всей команде выйти из вакуума технических и других ограничений и начать мыслить потребностями клиентов, непосредственно участвовать в развитии продукта, не говоря уже о банальной тренировке навыков коммуникации.

Зачем нужен и как его правильно готовить

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

Меня зовут Андрей Ходырев, и в профессии я достаточно давно — с 2011 года. Сейчас моя должность — ведущий инженер по тестированию. В последнее время занимаюсь не только тестированием и автоматизацией, но и разработкой. Я наставник в Практикуме на курсе автоматизатор тестирования на Java с августа прошлого года и занимаюсь там процессом улучшения код-ревью. 

Почему код-ревью — это так важно

В Практикуме код-ревью — неотъемлемая часть процесса обучения. Ревьюер — это человек, у которого есть реальный коммерческий опыт, и он проводит ревью студенческих проектов, чтобы передать свои знания и best practices. 

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

Есть вещи, которые не относятся к особенной предметной области или конкретному проекту. Например, как правильно оформлять Java-код. Это тоже влияет на оптимальность: можно использовать существующую библиотеку, а можно написать решение с нуля. Как правило, за такими вещами следит не коллега, а специальный человек в компании, который проверяет качество кода. Он следит за соблюдением стандартов написания и оформления кода — чтобы между командами использовались best practices. Проверяет соблюдение naming conventions — это принятые в компании правила обозначения имён переменных, типов, функций в исходном коде и документации.

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

Если разработчик мёрджит код в репозиторий, даже тесты, он обязательно должен пройти ревью. В этом отличие коммерческой разработки от написания кода для себя.

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

Как стать ревьюером

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

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

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

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

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

Правила хорошего фидбэка

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

Способность увидеть картину целиком. Мастерство ревьюера заключается в том, чтобы не придираться к деталям, видеть общую картину. Обратную связь лучше давать в целом про код — соответствует ли он стандартам компании.

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

В ревью не должно быть:

• слишком резких формулировок;

• неоднозначных или непонятных советов;

• негативных / деструктивных эмоций;

• абстрактных комментариев, не связанных с конкретным куском кода.

Как реагировать на код-ревью

Не воспринимать слишком лично. «Твой код не оптимален» — прочитав такое, многие начинают винить себя, а не свою работу. Важно отделять личность человека от того, что он делает.

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

Из документации Google’s Engineering Practices

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

• Стандарт код-ревью
• Что проверять в коде
• Навигация по списку изменений (CL)
• Скорость код-ревью
• Как писать комментарии
• Как преодолевать сопротивление

См. также Руководство автора CL, в котором даются подробные советы разработчикам, чьи коммиты проходят ревью.

Стандарт код-ревью

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

Здесь необходим ряд компромиссов.

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

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

Кроме того, рецензент несёт ответственность за рецензируемый код. Он хочет убедиться, что кодовая база остаётся последовательной, поддерживаемой и соответствует всему остальному, что упомянуто в разделе «Что проверять в коде».

Таким образом, мы получаем следующее правило в качестве стандарта для код-ревью:

Обычно рецензенты должны одобрить CL, как только он достигает состояния, когда определённо улучшает общее качество кода системы, даже если CL не идеален.

Это главный среди всех принципов код-ревью.

Конечно, у него есть ограничения. Например, если CL добавляет функцию, которую рецензент не хочет видеть в системе, то рецензент, безусловно, может отказать в коммите, даже если код хорошего качества.

Ключевым моментом здесь является то, что не бывает «идеального» кода — бывает только код получше. Рецензент не должен требовать от автора полировать каждый крошечный фрагментик. Скорее, рецензент должен сбалансировать необходимость дальнейшего прогресса по сравнению с важностью предлагаемых изменений. Вместо того, чтобы стремиться к идеалу, рецензент должен стремиться к непрерывному улучшению. Коммит, который в целом улучшает ремонтопригодность, читаемость и понятность системы, нельзя задерживать на дни или недели, потому что он не «идеален».

Примечание. Ничто в этом документе не оправдывает CL, которые определённо ухудшают общее качество кода системы. Такое возможно только в чрезвычайной ситуации.

Принципы

• Технические факты и данные перевешивают мнения и личные предпочтения.
• В вопросах стиля абсолютным авторитетом является руководство по стилю. Любая чисто стилевая деталь (пробел и др.), что не входит в руководство по стилю, является вопросом личных предпочтений. Стиль должен соответствовать тому, что есть. Если нет предыдущего стиля, примите авторский.
• Аспекты программного дизайна практически никогда не проблема чисто стиля или личных предпочтений. Они основаны на основополагающих принципах и должны определяться по этим принципам, а не просто на личном мнении. Иногда есть несколько допустимых вариантов. Если автор может продемонстрировать (либо с помощью данных, либо на основе твёрдых инженерных принципов), что определённые подходы одинаково эффективны, рецензент должен принять предпочтение автора. В противном случае выбор диктуется стандартными принципами разработки.
• Если никакое другое правило не применимо, то рецензент может попросить автора соблюдать единообразие с текущей кодовой базой, если это не ухудшает общее состояние системы.

Разрешение конфликтов

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

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

Что проверять в коде

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

Дизайн

Самое главное — учесть в код-ревью общий проект (дизайн). Имеют ли смысл взаимодействия разных частей кода? Это изменение относится к вашей кодовой базе или к библиотеке? Хорошо ли CL интегрируется с остальной частью системы? Время ли сейчас добавлять эту функциональность?

Функциональность

Делает ли этот CL то, что задумал разработчик? Хорошо ли оно для пользователей этого кода? Под «пользователями» подразумеваются и конечные пользователи (если их затрагивает изменение), и разработчики (которым придётся «использовать» этот код в будущем).

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

Если хотите, то можете проверить работоспособность. Наиболее важно сделать это, если код оказывает влияние на пользователей, например, изменение UI. Трудно понять, как некоторые изменения повлияют на пользователей, когда вы просто читаете код. Для таких изменений можете попросить разработчика предоставить демо, если вам слишком сложно углубляться в код и испытать его самостоятельно.

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

Сложность

Является ли CL более сложным, чем должен быть? Проверьте это на каждом уровне: отдельные строки, функции, классы. «Излишняя сложность» обычно означает невозможность быстрого понимания при чтении. Это также может означать, что разработчики, скорее всего, будут вводить ошибки при попытке вызвать или изменить этот код.

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

Тесты

Запросите модульные, интеграционные или сквозные тесты, соответствующие изменению. В общем случае тесты следует добавить в тот же CL, что и производственный код, если CL не обрабатывает чрезвычайную ситуацию.

Убедитесь, что тесты правильны, разумны и полезны. Тесты не проверяют сами себя, и мы редко пишем тесты для наших тестов — человек должен сам убедиться, что тесты валидны.

Действительно ли тесты не проходят на сломанном коде? Если код изменится, не появятся ли ложные срабатывания? Делает ли каждый тест простые и полезные утверждения? Правильно ли тесты разделены между различными методами тестирования?

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

Именование

Разработчик везде выбрал хорошие имена? Хорошее имя достаточно длинное, чтобы полностью передать то, чем является или что делает элемент, не будучи настолько длинным, что становится трудно читать.