Инструкция проведения Business review

Важной задачей сотрудников отдела продаж является создание и развитие отношений сотрудничества с ключевыми клиентами.

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

1. Типы Business review

1. Итоговое

2. Промежуточное

3. Целевое

4. Business review активности

2. Структура Business review

1. Итоги/Обзор результатов

2. Дальнейшие действия

3. Этапы Business review

1. Подготовка

· Определи цели и ожидаемые результаты

· Определи/выясни состав участников

· Согласуй повестку, время и место проведения

2. Проведение

· Скажи приветственное слово

· Уточни сколько есть времени на ревью

· Реши срочные вопросы

· Покажи и прокомментируй презентацию

· Инициируй обсуждение предоставленной информации

· Записывай решения в бланк Business review

· Подведи итог, покажи и прокомментируй бланк Business review

· При необходимости договорись о следующей встрече

· Поблагодари и закончи позитивно

3. После

· Отправь по почте бланк Business review с решением всем участникам

4. Цели, периодичность и структура различных типов Business review

Итоговое

Цели:

· Подвести итоги года и сформировать желание реализовать планируемые в следующем году активности

· Подписать контракт на лучших условиях

Периодичность:

Структура:

· Итоги прошедшего года

· Источники роста в следующем году

Промежуточное

Цели:

· Подвести промежуточные итоги

· Подредактировать план мероприятий в текущем году

· Повысить уровень лояльности келиента

Периодичность:

· Раз в полгода, ежеквартально, раз в период

Структура:

· Итоги за прошедший промежуток времени

· Предложение по корректировке (если необходимо)

Целевое

Цели:

· Решить возникшую проблему/реализовать незапланированную активность

Периодичность:

· По мере необходимости

Структура:

· Причина возникновения проблемы/предпосылки для планируемой активности

· Предложение по решению проблемы/предложение по проведению активности

Business review активности

Цели:

· Подвести итоги активности

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

Периодичность:

· Не позднее чем через месяц после окончания активности

Структура:

· Предпосылки для проведения активности (кратко, т.к. подробно уже было, когда предлагали активность)

5. Список клиентов для проведения Business review

Источник

Что такое ревью и какова его структура?

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

Ревью – как обзор

Многочисленные западные издания используют понятие ревью в значении «обзор», то есть структурированный список важных событий, произведений, объединённых каким-то единым фактором, подытоживание каких-либо аналитических работ. Это вполне закономерно, так как и у нас ревью или рецензия является обзорным материалом, значительно меньшего размера, нежели их объект. И всё-таки подобная путаница имеет продолжение. Дело в том, что кроме слова review есть ещё и overview, дословно переводящееся как обзор. Сложно? То ли ещё будет!

К видам ревью или рецензий традиционно относят:
• потребительская рецензия на товар или услугу (значение = отзыв)
• экспертная рецензия (значение = заключение)
• покупная рецензия (значение = аннотация или оплачиваемый маркетинговый ход)

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

Из чего состоит ревью?

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

1. Вступление:
a. интрига – часть текста, заинтересовывающая читателя,
b. объявление рассматриваемого произведения,
c. информация об авторе.

2. Содержание (центральная часть):
a. чем выделяется данное произведение?
b. характеристики важных параметров произведения (многосторонность, чувство юмора автора, стилистические особенности, качество записи и так далее),
c. положительные и отрицательные стороны (в этом пункте всегда разрешается допускать некую субъективность).

3. Заключение:
a. обобщение и анализ высказанных аргументов,
b. вынесение вердикта,
c. какой-то содержательный вывод.

Некоторые сложности может вызвать первый пункт, поэтому постараемся пояснить его на забавном примитивном примере:

«…когда он открыл глаза, вокруг ничего не было. Разве так может быть, спросите вы? В мире, созданном фантазией писателя Н., может быть практически всё. Сегодня мы ознакомимся с новой книгой мастера под названием (…)…»

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

Источник

Как подготовить ревью-сайт к SEO-продвижению

Привет, уважаемые читатели seoslim.ru! На сегодняшний день SEO направление вышло на совершенно новый уровень, оставив позади малоэффективные и устаревшие методы продвижения сайтов.

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

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

Что такое ревью-сайт

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

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

7 этапов для продвижения ревью-сайтов

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

Анализ ниши и конкурентов

Прежде всего необходимо определить, что представляет собой ревью-сайт в нише с позиции SEO.

Определите, с помощью каких запросов пользователи ищут информацию. Как правило это брендовый запрос посещаемого домена и добавка в виде слова review.

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

Примером такого запроса может быть: essay writing service/essay writing service reviews

В комплексном анализе вам могут пригодиться такие сервисы как:

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

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

Формирование семантического ядра + кластеризация запросов

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

Укомплектовывать семантическое ядро можно двумя способами: вручную и с помощью специальных инструментов.

Большинство специалистов предпочитают использовать второй метод, поскольку он дает более быстрый и качественный результат.

В качестве инструментов для сбора ключевых слов вам пригодятся:

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

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

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

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

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

Примерами в нише образования могут быть:

Транзакционные. Используются, когда пользователь планирует совершить действие.

Прочие запросы. Такие, по которым сложно определить намерение пользователя.

Например, когда студент использует ключ research paper, он может просто интересоваться видами работ без желания их купить.

Формирование структуры сайта

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

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

Стандартная структура обзорника: 30-100 страниц, в которой каждую внутреннюю страницу точат под один ключ вч_brand_name + reviews, а главную страницу — под essay writers reviews, essay reviews и т.д.

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

Оптимизация (внешняя и внутренняя)

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

Для внутренней оптимизации сайта необходимо реализовать следующие задачи:

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

Для этих целей хорошо подойдет сервис: Гогетлинкс и Кворк.

Внутренняя перелинковка

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

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

Оптимизация контента

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

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

Поисковая оптимизация базируется на нескольких критериях:

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

Анализ поведенческих факторов

Успешное продвижение ревью-сайта включает в себя и анализ поведенческих факторов:

Поведение пользователь напрямую воздействует на результаты продвижения.

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

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

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

Именно поэтому для продвижения ресурса важно постоянно пополнять багаж собственных знаний в области SEO и никогда не останавливаться на достигнутом результате.

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

Источник

Ревью с клиентами до и во время пандемии

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

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

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

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

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

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

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

Наконец, если есть, что показать клиентам, вы проводите UX Test. Пользователям предлагается в течение 20-30 минут решить ряд задач, а команда наблюдает, как у них это получается: какие сложности возникают в процессе, сколько времени уходит на решение и так далее. Задачи для тестирования интернет-банка могут выглядеть, например, так: 1. войти в интернет-банк; 2. скачать выписку для налоговой; 3. перейти в раздел «Контрагенты»; 4. импортировать контрагентов; 5. посмотреть операции по контрагенту.

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

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

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

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

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

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

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

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

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

Чек-листы — отличная вещь для переиспользования знаний о процессе исследования для компаний с большим количеством продуктовых команд.

Очевидно, рекомендации чек-листа не железобетон:

■ Оптимизируйте рекомендации под нюансы своих процессов и команды.

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

Источник

Код ревью, как внедрить и не испытывать боль

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

20% времени мы пишем новый код.

80% времени поддерживаем старый. Поддержка в себя включает фиксы багов, обновление кодовой базы (переезд на новые библиотеки например).

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

Способы иметь хорошо поддерживаемый код:

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

Что же такое код ревью?

Что нам даёт код ревью:
​ Проверку кода по многим критериям.
Автор не всегда видит неочевидные места в его коде (по разным причинам).
В результате написания и переписывания может быть потеряна композиция.
Автор, находясь в контексте задачи может недостаточно оставить комментариев.
Эти и многие другие проблемы может решить код ревью.

​ Шаринг знаний о проекте.Не только автор знает, что там пишется в другом проекте или части проекта, а все.

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

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

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

Советы по организации процесса

Условные обозначения:
— Как делать не нужно
+ Как делать нужно

​- Ревьюить только джунов и новых коллег
​+ Проводить ревью для всех и всеми

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

-​ Обсуждать на код ревью стиль
+​ Настроить у себя на проекте инструменты, которые автоматически будут исправлять стиль перед коммитом

В JS это eslint и prettier. Не тратьте время своё и коллег на споры о вкусах. Договоритесь заранее и пропишите правила. В случае разногласий голосуйте.

Не обсуждайте стиль на ревью

-​ Ревьюер запускает руками билд или проверяет код на баги.
​+ Автор сам несет ответственность за поставленный код.

Автор тщательно проверил свой код на работоспособность и залил в удаленный git репозиторий

На сервере CI/CD проверяет тесты, сборку, работоспособность в целом.

Проверка со стороны ревьюера.

-​ Ревьюер не читает код
+​ Обращать внимание на композицию, магические переменные, оптимизацию (там где это имеет смысл)

Обращайте внимание на код ревью.

​- Агрессия, негатив, «токсичное» поведение в комментах
+​ Старайтесь отмечать не только негативные стороны, но и хвалить за позитивные.

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

Стрессу и страху совершить ошибку

Примеры плохих комментов:

Примеры хороших комментов:

«Давай попробуем сделать …» «Может попробуем вынести…»

То же самое касается и ответов на комменты автором. Если автор не согласен, то необходимо объяснять с помощью аргументов, а не фраз в духе «я так делать не буду». Если не получается текстом, иногда проще подойти или сделать короткий созвон, чтобы понять друг друга.

Чаще хвалите код в ревью

-​ Все комментарии обязательны к исправлению
+​ Помечать необязательные комментарии

​ Пытаться объяснить алгоритмы на словах
​ Написать пример псевдокода

Особенно актуально, если автор не совсем понимает что от него хочет ревьюер. Не нужно полностью писать реализацию. Напишите небольшой пример псевдокода. Gitlab, github и bitbucket позволяют вставлять в комментарии разметку markdown. Ваш код будет хорошо отформатирован и более понятен, чем длинная цепочка комментов.

-​ Оставлять больше 50 комментариев
+​ Оставлять до 50 комментариев

Если комментариев накапливается очень много, то у вас:

Или не настроены линтеры, и вы не определились со стилем, поэтому комменты о вкусовщине

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

Во втором случае оставьте 1 комментарий с рекомендациями как и что нужно переписать. В таком случае лучше закрыть мердж реквест, переписать код и открыть новый.

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

-​ Отправлять огромные фрагменты кода на ревью
+​ Дробить большие участки кода на несколько реквестов и вливать постепенно

Задачи бывают разными по объему. Может быть задача исправить 1 строчку кода, а может быть задача отрефакторить весь проект. Во втором случае не отправляйте реквест в котором исправлены 500 файлов и 4000 изменений. Никто в здравом уме не сможет это нормально проверить, и желания такое проверять вы тоже не найдете.

Сделайте ветку feature/epic-name

Изменения делайте в ветке feature/epic-name-implement

Pull реквесты делайте в ветку feature/epic-name. Порционно.

В конце реализации фичи подлейте feature/epic-name в мастер. Да, в этом случае пулл реквест тоже будет огромный, но всё уже будет заранее проверено

Другой вариант как этого избежать: feature flags. Вы вливаете изменения на прод, но не даете им пользоваться. Нормально это реализовано мало у кого. Поэтому с этим подходом нужно быть осторожнее.

Уважайте тех, кто будет проверять ваш PR

-​ Pull Request висит без ревью трое суток
+​ Выработать расписание

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

В заключении

В этой статье я хотел рассказать и показать плюсы проведения код ревью. Будучи старшим разработчиком я всегда за то, чтобы мой код проходил code review. Лично для меня это отличный способ “увидеть” свой код чужими глазами. еще до того как ветка отправляется на ревью. Не говоря уже о том, что для команд это недорогой и эффективный способ иметь кодовую базу, с которой можно будет эффективно работать.

Если в вашей команде нет код ревью, то самое время его внедрить ​.

Ссылки и благодарности

По теме рекомендую почитать:Статья How to Do Code Reviews Like a Human
Спасибо лису и kirjs из @learnInPublic за ревью статьи про ревью.

Источник