Какие катастрофы бывают у нас в IT-мире? Самые популярные — это срывы сроков, сырые релизы и дублирование одной и той же работы. Я хочу рассказать страшные истории из своего опыта и показать на их примере, какие катастрофы могут ожидать, если не организовать базовые коммуникации, и почему именно эти коммуникации являются критичными.
Если вы хотите понять, все ли у вас в порядке в отделе QA — моя статья для вас. Я рассказываю об этом потому, что 14 лет работаю в IT, и большую часть из них — в качестве QA-лида. Я собирала QA-отделы с нуля и запускала процессы как в продуктовой компании, так и в аутсорсе, поэтому все кейсы масштабируются для компаний разных типов.
Коммуникации, по своей сути, похожи на квест. Судите сами: вы выполняете задачи, сталкиваетесь со сложностями, получаете level-up-ы, а в конце есть финальный приз, в виде налаженных процессов взаимодействия в вашем отделе. Давайте пройдем этот квест вместе. А чтобы этот путь был максимально полезным, возьмем для примера новых сотрудников, выходящих к вам в команду.
Итак, представим, что у вас уже есть QA-команда, и она занята на различных проектах (в продуктовых компаниях вместо проектов можно представить отдельные команды или большую функциональность).
И у вас появляется еще один новый проект. Для него вам нужны, конечно же, люди, которые на нем будут работать, и в том числе — два тестировщика. Допустим, вы их нашли и прособеседовали, они вышли на работу и готовы причинять пользу. Однако, у них первый рабочий день, и они не представляют, что и как у вас в компании устроено.
Чтобы разобраться, что делать и с чего начать, им необходимо будет взаимодействовать с коллегами. Давайте посмотрим, какие коммуникации стоит выполнить новым QA.
Если новые сотрудники у вас выходят редко, например, раз в год, то зачастую удобнее пересказать информацию устно. Однако, если ваша компания активно растет, и новые сотрудники выходят каждую неделю, то гораздо эффективнее иметь актуальные документы для онбординга, собранные в одном месте. Мы проверяли на практике, такие документы позволяли ускорить онбординг с двух недель до 2-3 дней. Заодно сотрудники сразу получают достоверную информацию вместо разговоров в виде сарафанного радио с возможными искажениями.
Что мы сделали у себя?
Хорошо, у нас есть Welcome book, а что же там должно находиться? Какие знания в нем должны быть?
Несколько лет назад мы взяли юного сотрудника, который в свой первый рабочий день не вышел на работу. На наши сообщения и звонки он ответил только вечером, сообщив, что уходил по своим делам в университет. И что нет, ничего не случилось, просто ему так было удобно. Мы обсудили с ним ситуацию, объяснили, что стоит предупреждать заранее, если надо отойти по делам. Следующий день он отработал нормально, но на третий день опять пропал. После третьего такого пропадания за полторы недели мы с ним, конечно, простились, и на финальном разговоре я его спросила: «Как же так? Ты планировал ходить на работу, учиться новому, у тебя ожидалась обычная рабочая пятидневка и обычные рабочие часы, с которыми ты был согласен. Почему же ты не выходил на работу?» На что получила интересный ответ: «Ну, на предыдущей работе тоже говорили, что надо будет работать и ходить в офис, а я не ходил — и ничего».
То есть опыт бывает совершенно разный. Если вы не хотите застать пустой стол (или, в случае удаленки - неактивный аккаунт и зависшие таски), потому что ваш сотрудник ушел по своим делам, то хорошо бы про это прокоммуницировать на берегу.
Конечно, если у вас важный релиз, то ответственный сотрудник, как правило, выйдет поработать даже заболев — чтобы точно никого не подвести и успеть проверить свою часть. Но на самом деле, это приводит к тому, что человек в плохом состоянии совершает больше ошибок, и, как следствие, это негативно влияет и на качество релиза, и на скорость выздоровления самого сотрудника.
Поэтому то, как отмечать больничный, мы рассказываем тоже на первом уровне нашего квеста. У нас это реализовано в интранете в достаточно несложной форме:
Чтобы не сорвать релиз, вам надо срочно передать его задачи и знания другому разработчику. И хорошо, если у вас есть свобоный фронтендер. А если нет? Тогда его сначала надо найти и нанять. Скорее всего, у вас сдвинутся сроки деплоя, если не сорвутся все дедлайны вообще. Это один из примеров катастрофы. Чтобы минимизировать такие риски, мы решаем вопрос с отпусками как с больничными — аналогичной формой:
Важно, что у нас автоматически настроены нотификации в Slack для менеджеров, и они заранее получают уведомления, что у Пети, например, через месяц будет отпуск — есть время подготовиться и передать экспертизу.
Отлично, теперь все сотрудники ходят на работу, не болеют и не в отпуске. Остается решить вопрос о треках.
Когда проходит первый шок, то сотрудник задается вопросом: «А как их вносить-то?», поскольку «работал работу на работе» обычно не подходит. Поэтому мы для новеньких описали, что такое хороший worklog (трек с описанием выполненной работы), дав конкретные примеры. Мы опираемся на то, что в идеале трек должен включать не больше 8 часов и быть подробно описан по сути:
Пример хорошего worklog
И эти примеры с конкретикой, как показала практика, дают зачастую гораздо больше толковых треков, чем все теоретические описания. Наша команда разработки обычно вносит треки в Jira в задачи, над которыми они работали.
ОК, допустим, мы знаем, как и куда надо вносить в worklog. Но что делать, чтобы их реально все-таки вносили? Потому что кричать и топать ногами, конечно, не наш метод. Более того, этот метод никогда не работает и никому не помогает.
Для этого у нас есть восхитительные люди — аккаунт-менеджеры. Каждую пятницу они проверяют, кто внес треки и хвалят тех, кто молодец. А к тем, кто треки еще не внес, они ищут индивидуальный подход. С разрешения моих коллег покажу маленький кусочек такого подхода из переписки коллег:
На самом деле Никита — потрясающий сотрудник, и единственная его слабость — это своевременное внесение треков. И пирожные из Ростова он привозил, вкусные )
Вход в проект. Полный текст: bit.ly/First_Day_QA
Общий документ по регламентам и процессам — QA-guide — у нас находится в wiki компании. Приведу его оглавление:
Итак, допустим, тестировщик прочитал весь QA-guide и разобрался со всеми его пунктами. Его следующим логичным вопросом будет: «А с кем я работать-то буду? Кто все эти люди?» И наступает черед знакомства с командой на проекте.
А еще очень важно иметь здоровую коммуникацию между отделами. У меня был случай, много лет назад, когда ко мне пришла QA-лид из соседней команды и сказала: «Знаешь, что у нас отдел Security сейчас натворил? Они нашли критическую уязвимость на проде. Говорят, что прямо ужас-ужас то, что они нашли. И срочно сделали фикс, он уже на стейдже. Пришли к нам, попросили проверить фикс. Пока все идет нормально, да?» Мы говорим, что конечно, проверим, всё остальное отложим. Но в чем бага-то?! И получаем ответ: «Мы не можем вам рассказать, про что эта бага. Потому что она очень-очень секьюрная!»
В итоге у нас было два недовольных друг другом отдела, открытый конфликт и заблокированный релиз критичноего фикса на прод. Конечно, в итоге всех помирили, и фикс через несколько часов оказался на проде. Однако, если этого можно было избежать, договорившись заранее о регламенте проверки задач по безопасности, то это было бы в разы выгоднее и по времени, и по нервам сотрудников. Точно так же можно заранее наладить регламенты по взаимодействию с другими отделами.
Отлично, с командой мы познакомились, регламенты выяснили. Казалось бы, можно уже работать! Но у нас же еще есть заказчик.
Если на проекте несколько QA, то общаться с заказчиком будет QA-lead. А если QA один, и новенький, то идет общаться он, заодно и опыта набирается. Почему это необходимо? Потому что не любой PM ориентируется в важных для разработки деталях.
Приведу пример. Допустим, у вас стартует новый проект с новой командой. На старте PM узнал у заказчика, что проект надо будет проверять только в браузерах, и никаких мобилок и планшетов не будет. Когда QA уточнил, в каких браузерах проверять, PM ответил: «Ну, в самых популярных, наверное, как обычно: Chrome и Safari». И если в этот момент QA не насторожился и не стал перепроверять, то дальше может произойти грустная история.
Я знаю историю, когда прошла пара месяцев, пришел заказчик и сказал: «Ребята, у вас так много багов в IE11!» — «Да, в IE11 много багов, но мы его и не поддерживаем!» — «А я считаю, что надо поддерживать! Это же очевидно, что нам нужен IE11!» Получается, что один браузер они потеряли, и теперь все фиксы багов для этого самого IE11 будут идти за их счет.
Конечно, это очень печально. Поэтому у нас есть целый сет вопросов, по которым надо договариваться с заказчиком, начиная с документации и заканчивая географией команды:
Все эти вопросы у нас включены в базовый документ о входе в проект для QA
А после того, как информация собрана, есть еще один крайне важный этап, которую делают не все, но который очень помогает при рабочих спорах, и это — фиксация договоренностей. Неважно, где вы это сделаете: это может быть email, Confluence, Google doc или любое другое место, удобное вам и заказчику. Важно, чтобы с обеих сторон было подтверждение, что работаем мы именно так, и все с этим согласны.
Так, в истории выше, проекту бы очень помогло, если бы они с заказчиком прописали на берегу, что проверка качества будет только в Chrome и Safari последних версий, и больше нигде. И заказчик либо вспомнил бы уже на этом этапе про IE11 (в 9 случаях из 10 так и происходит), либо согласился на эти два браузера, и команда бы не пострадала.
Итак, с заказчиком мы договорились, и наконец-то наступает момент, когда тестировщик может начать «работать работу» — то, ради чего он и устроился к нам.
В этом случае ваши сотрудники начинают думать друг про друга плохо. Чтобы этого избежать и иметь мир среди QA, мы договариваемся о разделении задач и зон ответственности. Например, мы договариваемся, что QA назначает на себя задачу, которую он сейчас проверяет, чтобы было видно, кто за эту задачу в ответе, и заодно — в каком она статусе. Также может быть разделение ответственности по функционалу и сложности задач, если у вас большой проект: например, Вася проверяет функции А, B и С, а Петя — D и E.
Чтобы сохранить нервы и разработчиков, и PM — мы ввели общий регламент по форматам написания багов и тест-кейсов. И о, чудо! — количество перекрытых задач и доработок по ним заметно сократилось. Бонусом мы получаем довольных разработчиков, которые иногда пишут в личку: «Спасибо, что так понятно пишешь баги. Я такое встречаю редко».
One-to-one встречи
С новенькими очень полезно проводить регулярные One-to-one, пусть даже в сокращенном варианте. Очень важно понять — вашему тестировщику у вас хорошо или плохо? И почему? Ему нравится тестировать мобилки или api? Ему хочется движуху стартапа или тихую монотонную регрессию? Он лучше работает в большой или в маленькой команде? И если вы не взаимодействуете с вашим новым коллегой, то легко можно пропустить тот момент, когда окажется, что лично для него что-то пошло не так.
Например, у нас был сотрудник, который был отличным, толковым специалистом. И в первый месяц мы, к сожалению, взаимодействовали с ним только по функционалу («Даешь релиз новых фич! А остальная логика работает вот так-то»). И... он ушел от нас через полтора месяца, потому что оказалось, что он привык работать по отлаженным процессам, а у нас тогда как раз был стартап.
Тогда я поняла, что очень важно приходить к человеку и спрашивать: «Как у тебя дела? Что не получается? Чем помочь?» Вопросы простые, однако так вы показываете человеку, что он нужен и важен, что о нем думают, помогают, и что своими проблемами лучше делиться, потому что так их можно решить быстрее.
Вдруг они выглядят как-то так?
Здесь очень важно сделать «развиртуализацию», чтобы ваши сотрудники не нафантазировали себе, что руководители страшные, непонятные и, может быть, могут укусить. Поэтому мы у себя проводим Welcome Day.
Это мероприятие, когда все пришедшие за месяц новенькие созваниваются с нашими топами, которые рассказывают, как и на каких ценностях была основана компания, какие сейчас есть проекты и куда мы планируем развиваться. А потом отвечают на все вопросы и знакомятся в неформальной обстановке.
Особенно это важно в распределенной команде с ребятами из разных городов (а сейчас и на удаленке), когда вы не можете просто встретиться на кухне и пообщаться за чаем-кофе.
А вот если у вас много сотрудников (100+), сам проект идет уже больше года, у вас много Legacy-кода, есть отделы маркетинга и технической поддержки, то, с высокой долей вероятности, база знаний — это то, что вам прямо показано.
И если база данных все-таки вам нужна, то как ее делать? В первую очередь надо определиться с целью — а она вам зачем? Какую цель вы закрываете? Может быть, вам нужен полный список актуальных девайсов во всех городах, учитывая, что у вас распределенная команда? Или вы хотите иметь базу с видео всех внутренних обучающих митапов? Цели у всех разные, и именно они лежат в основе хорошей базы.
Еще важно учесть то, что без всех предыдущих коммуникаций, о которых мы сегодня говорили, работа с базой знаний, к сожалению, не взлетает. Именно поэтому я говорю о базе знаний только сейчас. Однако, если у вас выполнены все предыдущие шаги, то настало время определиться: а где мы базу знаний будем вести? Чаще всего выбирают Confluence. Однако важно помнить, что под разные данных данных хорошо бы использовать предназначенные именно для них области хранения (макеты, например, в figma, а тест-кейсы — в TestRail).
Еще один важный момент: нам важно, чтобы база знаний не просто была, а чтобы ей пользовались. Как правило, работа с базой знаний «не взлетает» из-за двух причин: непонятно, как искать информацию и куда ее записывать.
Самое простое, чем здесь можно помочь: составьте структуру папок в Confluence (если вы решили делать базу знаний в нем) и проведите небольшой созвон на 10-15 минут со всей командой. Расскажите всем, какая папка у вас для чего, что и куда вы записываете, а также — где вашим коллегам можно создавать их документы. Соберите фидбек, удобно ли им это, и доработайте формат с его учетом. Волшебным образом это помогает команде начать действительно работать с вашей базой знаний, потому что она перестает быть непонятной.
А еще очень важно показать вашим сотрудникам, чем лично им может быть полезна база знаний? Им-то она зачем? Лучше всего показывать на примерах. В первую очередь, это может быть банальная экономия времени, чтобы не пересказывать новому сотруднику, зачем он пришел и что ему делать (так обычно и рождается гайд по онбордингу). Также это может быть быстрый доступ к актуальной информации — к тому же списку всех девайсов, например. А может быть польза самому же себе на будущее: «Вот сейчас напишу тест-кейсы, а потом по ним же сделаю автотесты, как я и хотел». И, конечно же, это может быть, в том числе, помощь другим. Очень ценно, когда Петя приходит к Васе и говорит: «Спасибо тебе большое, Вася, твой тест-кейс мне уже три раза пригодился, классно написан! Я кучу времени сэкономил».
А еще популярный вопрос: а с чего начинать внедрение коммуникаций, если пока нет ничего? Начать можно с минимума. Например, если у вас компания расширяется, то можно сделать гайд для онбординга сотрудников. Затем, если у вас нет стендапов, попробуйте их провести в течение месяца. Команда привыкнет, и через месяц можно будет добавить, например, ревью.
А как это всё внедрять? Лучше всего — постепенно, а не как обычно: «Хочу все и сразу, немедленно!». Поэтому, чтобы не бросить во вторник начатую с понедельника новую жизнь, внедряйте изменения небольшими шагами.
Наш мозг так устроен, что к новым изменениям ему надо привыкать постепенно, поэтому наилучшие результаты получаются именно так. И, с таким планомерным введением коммуникаций, имея в голове общую картину уровней квеста, вы и сами не заметите, насколько сильно уже через полгода поменяется ваш QA-отдел.
habr.com
Если вы хотите понять, все ли у вас в порядке в отделе QA — моя статья для вас. Я рассказываю об этом потому, что 14 лет работаю в IT, и большую часть из них — в качестве QA-лида. Я собирала QA-отделы с нуля и запускала процессы как в продуктовой компании, так и в аутсорсе, поэтому все кейсы масштабируются для компаний разных типов.
Коммуникации, по своей сути, похожи на квест. Судите сами: вы выполняете задачи, сталкиваетесь со сложностями, получаете level-up-ы, а в конце есть финальный приз, в виде налаженных процессов взаимодействия в вашем отделе. Давайте пройдем этот квест вместе. А чтобы этот путь был максимально полезным, возьмем для примера новых сотрудников, выходящих к вам в команду.
Итак, представим, что у вас уже есть QA-команда, и она занята на различных проектах (в продуктовых компаниях вместо проектов можно представить отдельные команды или большую функциональность).
И у вас появляется еще один новый проект. Для него вам нужны, конечно же, люди, которые на нем будут работать, и в том числе — два тестировщика. Допустим, вы их нашли и прособеседовали, они вышли на работу и готовы причинять пользу. Однако, у них первый рабочий день, и они не представляют, что и как у вас в компании устроено.
Чтобы разобраться, что делать и с чего начать, им необходимо будет взаимодействовать с коллегами. Давайте посмотрим, какие коммуникации стоит выполнить новым QA.
Level 1. Вход в компанию
В первый день, когда сотрудники приходят в компанию, вопросы у всех одни и те же: «Как тут все устроено, и где про это можно почитать?», в какой бы отдел они при этом ни вышли.Если новые сотрудники у вас выходят редко, например, раз в год, то зачастую удобнее пересказать информацию устно. Однако, если ваша компания активно растет, и новые сотрудники выходят каждую неделю, то гораздо эффективнее иметь актуальные документы для онбординга, собранные в одном месте. Мы проверяли на практике, такие документы позволяли ускорить онбординг с двух недель до 2-3 дней. Заодно сотрудники сразу получают достоверную информацию вместо разговоров в виде сарафанного радио с возможными искажениями.
Что мы сделали у себя?
Welcome book
Мы в Evrone завели Welcome book, где храним всю информацию, которую надо знать новеньким. Важно, что это пространство универсально и доступно в любой момент для всех — распределенной команде с разными тайм-зонами нужно иметь возможность получить доступ к информации в любой момент.Хорошо, у нас есть Welcome book, а что же там должно находиться? Какие знания в нем должны быть?
Не думай о секундах свысока
В первую очередь я бы включала в Welcome book договоренности о рабочих днях и часах. Казалось бы, слишком очевидно и банально — все же ходят на работу. Но, оказывается, не всем всё понятно.Несколько лет назад мы взяли юного сотрудника, который в свой первый рабочий день не вышел на работу. На наши сообщения и звонки он ответил только вечером, сообщив, что уходил по своим делам в университет. И что нет, ничего не случилось, просто ему так было удобно. Мы обсудили с ним ситуацию, объяснили, что стоит предупреждать заранее, если надо отойти по делам. Следующий день он отработал нормально, но на третий день опять пропал. После третьего такого пропадания за полторы недели мы с ним, конечно, простились, и на финальном разговоре я его спросила: «Как же так? Ты планировал ходить на работу, учиться новому, у тебя ожидалась обычная рабочая пятидневка и обычные рабочие часы, с которыми ты был согласен. Почему же ты не выходил на работу?» На что получила интересный ответ: «Ну, на предыдущей работе тоже говорили, что надо будет работать и ходить в офис, а я не ходил — и ничего».
То есть опыт бывает совершенно разный. Если вы не хотите застать пустой стол (или, в случае удаленки - неактивный аккаунт и зависшие таски), потому что ваш сотрудник ушел по своим делам, то хорошо бы про это прокоммуницировать на берегу.
Больничные
Допустим, мы договорились о часах и днях, а сотрудник все равно не вышел, но на этот раз — потому что заболел. С каждым может случиться. Это грустно, влияет на сроки, но бывает. Однако, ситуация может быть хуже, если ваш сотрудник заболел, но не знал, как и кому об этом сообщить, и поэтому просто вышел на работу.Конечно, если у вас важный релиз, то ответственный сотрудник, как правило, выйдет поработать даже заболев — чтобы точно никого не подвести и успеть проверить свою часть. Но на самом деле, это приводит к тому, что человек в плохом состоянии совершает больше ошибок, и, как следствие, это негативно влияет и на качество релиза, и на скорость выздоровления самого сотрудника.
Поэтому то, как отмечать больничный, мы рассказываем тоже на первом уровне нашего квеста. У нас это реализовано в интранете в достаточно несложной форме:
Отпуска
Допустим, работает у вас над проектом небольшая команда из 5 человек: аналитик, проджект, фронтенд и бэкенд-разработчики и QA. Активно работают, всё хорошо. Но когда до релиза остается 2 недели, фронтенд-разработчик внезапно говорит, что послезавтра он уходит в отпуск.Чтобы не сорвать релиз, вам надо срочно передать его задачи и знания другому разработчику. И хорошо, если у вас есть свобоный фронтендер. А если нет? Тогда его сначала надо найти и нанять. Скорее всего, у вас сдвинутся сроки деплоя, если не сорвутся все дедлайны вообще. Это один из примеров катастрофы. Чтобы минимизировать такие риски, мы решаем вопрос с отпусками как с больничными — аналогичной формой:
Важно, что у нас автоматически настроены нотификации в Slack для менеджеров, и они заранее получают уведомления, что у Пети, например, через месяц будет отпуск — есть время подготовиться и передать экспертизу.
Отлично, теперь все сотрудники ходят на работу, не болеют и не в отпуске. Остается решить вопрос о треках.
Треки
Продуктовым компаниям треки не так актуальны, как аутсорсерам, которые выставляют счета заказчику именно на их основе. Нет треков в конце месяца — можно считать, что весь месяц человек проработал бесплатно. Поэтому, в идеале, треки нужно вносить каждый день. И обычная реакция новых сотрудников на это выглядит примерно так:
Когда проходит первый шок, то сотрудник задается вопросом: «А как их вносить-то?», поскольку «работал работу на работе» обычно не подходит. Поэтому мы для новеньких описали, что такое хороший worklog (трек с описанием выполненной работы), дав конкретные примеры. Мы опираемся на то, что в идеале трек должен включать не больше 8 часов и быть подробно описан по сути:
И эти примеры с конкретикой, как показала практика, дают зачастую гораздо больше толковых треков, чем все теоретические описания. Наша команда разработки обычно вносит треки в Jira в задачи, над которыми они работали.
ОК, допустим, мы знаем, как и куда надо вносить в worklog. Но что делать, чтобы их реально все-таки вносили? Потому что кричать и топать ногами, конечно, не наш метод. Более того, этот метод никогда не работает и никому не помогает.
Для этого у нас есть восхитительные люди — аккаунт-менеджеры. Каждую пятницу они проверяют, кто внес треки и хвалят тех, кто молодец. А к тем, кто треки еще не внес, они ищут индивидуальный подход. С разрешения моих коллег покажу маленький кусочек такого подхода из переписки коллег:
Резюме
Отлично, первый уровень мы прошли! Подведем итоги, что мы сделали:- Дали доступ к общей базе знаний по компании;
- Договорились о рабочих днях и часах;
- Научили новеньких, как вносить больничные, отпуска и треки.
- Интранет/wiki;
- Нотификации в Slack (автоматические и ручные) — от грядущего отпуска работы до дня рождения сотрудника.
- Jira (для работы с задачами и для внесения треков)
Level 2. Вход на проект
Выходя на проект, тестировщик пока не знает, что от него ожидает команда, И может получиться так, что вы взяли классного специалиста, который отлично прошел собеседование, но вот проходит неделя, вторая, третья, а он работает плохо. Например, пишет странные и неактуальные баги, не понимая, как устроен функционал. Если у вас такое было, то, скорее всего, вы с этим сотрудником пропустили или недоработали онбординг.Онбординг
Для входа в проект у нас разработана целая система, где написано, о чем тестировщику надо узнать в первые 2-3 дня, сократив вход в проект с пары недель до 2-3 дней:
Общий документ по регламентам и процессам — QA-guide — у нас находится в wiki компании. Приведу его оглавление:
Итак, допустим, тестировщик прочитал весь QA-guide и разобрался со всеми его пунктами. Его следующим логичным вопросом будет: «А с кем я работать-то буду? Кто все эти люди?» И наступает черед знакомства с командой на проекте.
Кто все эти люди?
На проекте у вас может быть как небольшая группа людей, так и множество отделов. Естественно, знакомство QA мы начинаем с тех коллег, с которыми ему чаще всего взаимодействовать: это, в первую очередь, другие QA на проекте (при их наличии), а так же команда разработки и PM. В идеале, PM представляет нового сотрудника на общем созвоне с командой, а дальше идет индивидуальное общение и знакомство.А еще очень важно иметь здоровую коммуникацию между отделами. У меня был случай, много лет назад, когда ко мне пришла QA-лид из соседней команды и сказала: «Знаешь, что у нас отдел Security сейчас натворил? Они нашли критическую уязвимость на проде. Говорят, что прямо ужас-ужас то, что они нашли. И срочно сделали фикс, он уже на стейдже. Пришли к нам, попросили проверить фикс. Пока все идет нормально, да?» Мы говорим, что конечно, проверим, всё остальное отложим. Но в чем бага-то?! И получаем ответ: «Мы не можем вам рассказать, про что эта бага. Потому что она очень-очень секьюрная!»
В итоге у нас было два недовольных друг другом отдела, открытый конфликт и заблокированный релиз критичноего фикса на прод. Конечно, в итоге всех помирили, и фикс через несколько часов оказался на проде. Однако, если этого можно было избежать, договорившись заранее о регламенте проверки задач по безопасности, то это было бы в разы выгоднее и по времени, и по нервам сотрудников. Точно так же можно заранее наладить регламенты по взаимодействию с другими отделами.
Отлично, с командой мы познакомились, регламенты выяснили. Казалось бы, можно уже работать! Но у нас же еще есть заказчик.
Заказчик и договоренности
У тестировщиков, особенно начинающих, есть большой порыв пропустить коммуникацию с заказчиком, потому что зачастую считается, что с заказчиком договаривается только PM. Однако, на самом деле очень важно, чтобы QA на старте тоже проговорил основные детали разработки, ведь именно ему, в первую очередь, делать приемку задач и анализировать соответствия.Если на проекте несколько QA, то общаться с заказчиком будет QA-lead. А если QA один, и новенький, то идет общаться он, заодно и опыта набирается. Почему это необходимо? Потому что не любой PM ориентируется в важных для разработки деталях.
Приведу пример. Допустим, у вас стартует новый проект с новой командой. На старте PM узнал у заказчика, что проект надо будет проверять только в браузерах, и никаких мобилок и планшетов не будет. Когда QA уточнил, в каких браузерах проверять, PM ответил: «Ну, в самых популярных, наверное, как обычно: Chrome и Safari». И если в этот момент QA не насторожился и не стал перепроверять, то дальше может произойти грустная история.
Я знаю историю, когда прошла пара месяцев, пришел заказчик и сказал: «Ребята, у вас так много багов в IE11!» — «Да, в IE11 много багов, но мы его и не поддерживаем!» — «А я считаю, что надо поддерживать! Это же очевидно, что нам нужен IE11!» Получается, что один браузер они потеряли, и теперь все фиксы багов для этого самого IE11 будут идти за их счет.
Конечно, это очень печально. Поэтому у нас есть целый сет вопросов, по которым надо договариваться с заказчиком, начиная с документации и заканчивая географией команды:
А после того, как информация собрана, есть еще один крайне важный этап, которую делают не все, но который очень помогает при рабочих спорах, и это — фиксация договоренностей. Неважно, где вы это сделаете: это может быть email, Confluence, Google doc или любое другое место, удобное вам и заказчику. Важно, чтобы с обеих сторон было подтверждение, что работаем мы именно так, и все с этим согласны.
Так, в истории выше, проекту бы очень помогло, если бы они с заказчиком прописали на берегу, что проверка качества будет только в Chrome и Safari последних версий, и больше нигде. И заказчик либо вспомнил бы уже на этом этапе про IE11 (в 9 случаях из 10 так и происходит), либо согласился на эти два браузера, и команда бы не пострадала.
Итак, с заказчиком мы договорились, и наконец-то наступает момент, когда тестировщик может начать «работать работу» — то, ради чего он и устроился к нам.
Разделение задач и зон ответственности
Когда тестировщики начинают работать друг с другом, не исключена ситуация, когда на стендапе один тестировщик скажет, что потратил на задачу 4 часа, а второй очень удивится: «Хм… Я ее сделал еще вчера».
В этом случае ваши сотрудники начинают думать друг про друга плохо. Чтобы этого избежать и иметь мир среди QA, мы договариваемся о разделении задач и зон ответственности. Например, мы договариваемся, что QA назначает на себя задачу, которую он сейчас проверяет, чтобы было видно, кто за эту задачу в ответе, и заодно — в каком она статусе. Также может быть разделение ответственности по функционалу и сложности задач, если у вас большой проект: например, Вася проверяет функции А, B и С, а Петя — D и E.
Как разозлить разработчика
Однако нам важно сохранить мир не только среди своих QA, но и с другими отделами. Когда тестировщики начинают писать баги, то при должном умении это может стать почти гарантированным способом разозлить разработчиков. Например, можно следовать этим шагам:
Чтобы сохранить нервы и разработчиков, и PM — мы ввели общий регламент по форматам написания багов и тест-кейсов. И о, чудо! — количество перекрытых задач и доработок по ним заметно сократилось. Бонусом мы получаем довольных разработчиков, которые иногда пишут в личку: «Спасибо, что так понятно пишешь баги. Я такое встречаю редко».
Резюме
Итак, второй уровень мы прошли. Подведем итоги, что мы сделали:- Провели новичкам онбординг в проект;
- Договорились о взаимодействии с другими отделами;
- Согласовали, что и как тестируем, с заказчиком;
- Разделили задачи среди тестировщиков;
- Выбрали формат написания багов и тест-кейсов.
- Confluence/google docs/ email, mind maps, figma;
- Google sheets/Jira/интранет + Slack/zoom + Stand up;
- Jira/TestRail/Google sheets;
Level 3. Как тебе с нами?
После прохождения второго уровня тестировщик освоился и в компании, и на проекте. И примерно через месяц работы наступает третий уровень квеста. В этот момент ваш сотрудник задается вопросом: «А мне здесь вообще нравится или нет?»
One-to-one встречи
С новенькими очень полезно проводить регулярные One-to-one, пусть даже в сокращенном варианте. Очень важно понять — вашему тестировщику у вас хорошо или плохо? И почему? Ему нравится тестировать мобилки или api? Ему хочется движуху стартапа или тихую монотонную регрессию? Он лучше работает в большой или в маленькой команде? И если вы не взаимодействуете с вашим новым коллегой, то легко можно пропустить тот момент, когда окажется, что лично для него что-то пошло не так.
Например, у нас был сотрудник, который был отличным, толковым специалистом. И в первый месяц мы, к сожалению, взаимодействовали с ним только по функционалу («Даешь релиз новых фич! А остальная логика работает вот так-то»). И... он ушел от нас через полтора месяца, потому что оказалось, что он привык работать по отлаженным процессам, а у нас тогда как раз был стартап.
Тогда я поняла, что очень важно приходить к человеку и спрашивать: «Как у тебя дела? Что не получается? Чем помочь?» Вопросы простые, однако так вы показываете человеку, что он нужен и важен, что о нем думают, помогают, и что своими проблемами лучше делиться, потому что так их можно решить быстрее.
Welcome Day
Следующий вопрос, над котором новичок начинает задумываться: «Люди, которые нами руководят — они вообще кто? Они вообще какие?»Вдруг они выглядят как-то так?
Здесь очень важно сделать «развиртуализацию», чтобы ваши сотрудники не нафантазировали себе, что руководители страшные, непонятные и, может быть, могут укусить. Поэтому мы у себя проводим Welcome Day.
Это мероприятие, когда все пришедшие за месяц новенькие созваниваются с нашими топами, которые рассказывают, как и на каких ценностях была основана компания, какие сейчас есть проекты и куда мы планируем развиваться. А потом отвечают на все вопросы и знакомятся в неформальной обстановке.
Особенно это важно в распределенной команде с ребятами из разных городов (а сейчас и на удаленке), когда вы не можете просто встретиться на кухне и пообщаться за чаем-кофе.
База знаний
На этом же этапе, как правило, человек становится готов к работе с базой знаний. Однако, прежде всего, стоит понять для себя: «А база знаний вот конкретно нам, в нашем случае нужна или нет?», потому что если у вас немного людей в команде, динамично меняющийся стартап или короткий проект на 2-3 месяца, то в этом случае, скорее всего, создание базы знаний будет избыточным.А вот если у вас много сотрудников (100+), сам проект идет уже больше года, у вас много Legacy-кода, есть отделы маркетинга и технической поддержки, то, с высокой долей вероятности, база знаний — это то, что вам прямо показано.
И если база данных все-таки вам нужна, то как ее делать? В первую очередь надо определиться с целью — а она вам зачем? Какую цель вы закрываете? Может быть, вам нужен полный список актуальных девайсов во всех городах, учитывая, что у вас распределенная команда? Или вы хотите иметь базу с видео всех внутренних обучающих митапов? Цели у всех разные, и именно они лежат в основе хорошей базы.
Еще важно учесть то, что без всех предыдущих коммуникаций, о которых мы сегодня говорили, работа с базой знаний, к сожалению, не взлетает. Именно поэтому я говорю о базе знаний только сейчас. Однако, если у вас выполнены все предыдущие шаги, то настало время определиться: а где мы базу знаний будем вести? Чаще всего выбирают Confluence. Однако важно помнить, что под разные данных данных хорошо бы использовать предназначенные именно для них области хранения (макеты, например, в figma, а тест-кейсы — в TestRail).
Еще один важный момент: нам важно, чтобы база знаний не просто была, а чтобы ей пользовались. Как правило, работа с базой знаний «не взлетает» из-за двух причин: непонятно, как искать информацию и куда ее записывать.
Самое простое, чем здесь можно помочь: составьте структуру папок в Confluence (если вы решили делать базу знаний в нем) и проведите небольшой созвон на 10-15 минут со всей командой. Расскажите всем, какая папка у вас для чего, что и куда вы записываете, а также — где вашим коллегам можно создавать их документы. Соберите фидбек, удобно ли им это, и доработайте формат с его учетом. Волшебным образом это помогает команде начать действительно работать с вашей базой знаний, потому что она перестает быть непонятной.
А еще очень важно показать вашим сотрудникам, чем лично им может быть полезна база знаний? Им-то она зачем? Лучше всего показывать на примерах. В первую очередь, это может быть банальная экономия времени, чтобы не пересказывать новому сотруднику, зачем он пришел и что ему делать (так обычно и рождается гайд по онбордингу). Также это может быть быстрый доступ к актуальной информации — к тому же списку всех девайсов, например. А может быть польза самому же себе на будущее: «Вот сейчас напишу тест-кейсы, а потом по ним же сделаю автотесты, как я и хотел». И, конечно же, это может быть, в том числе, помощь другим. Очень ценно, когда Петя приходит к Васе и говорит: «Спасибо тебе большое, Вася, твой тест-кейс мне уже три раза пригодился, классно написан! Я кучу времени сэкономил».
Резюме
Итак, на третьем уровне мы сделали:- Регулярное проведение 1:1 (особенно с новичками);
- «Развиртуализацию» топов;
- Постепенное внедрение работы с базой знаний (при необходимости).
- Slack/Google meet;
- Zoom;
- Confluence, TestRail, google doc, onedrive, figma, intranet.
Заключение
Подводя итоги, вы можете подумать, что придется очень много коммуницировать. И будете правы. Однако это окупается сполна.
А еще популярный вопрос: а с чего начинать внедрение коммуникаций, если пока нет ничего? Начать можно с минимума. Например, если у вас компания расширяется, то можно сделать гайд для онбординга сотрудников. Затем, если у вас нет стендапов, попробуйте их провести в течение месяца. Команда привыкнет, и через месяц можно будет добавить, например, ревью.
А как это всё внедрять? Лучше всего — постепенно, а не как обычно: «Хочу все и сразу, немедленно!». Поэтому, чтобы не бросить во вторник начатую с понедельника новую жизнь, внедряйте изменения небольшими шагами.
Наш мозг так устроен, что к новым изменениям ему надо привыкать постепенно, поэтому наилучшие результаты получаются именно так. И, с таким планомерным введением коммуникаций, имея в голове общую картину уровней квеста, вы и сами не заметите, насколько сильно уже через полгода поменяется ваш QA-отдел.
Коммуникации, отсутствие которых приводит к катастрофам
Какие катастрофы бывают у нас в IT-мире? Самые популярные — это срывы сроков, сырые релизы и дублирование одной и той же работы. Я хочу рассказать страшные истории из своего опыта и показать на их...
habr.com