Home

Автор: Воробьева Юлия

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

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

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

Итак

Методы, которые могут погубить продукт

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

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

Почему? А потому что вечером в пятницу, часам к 11, один бэкенд разработчик, назовем его Михаил, решил, что нет смысла писать тестерам и терять время. Он сделал MR и трое других разработчиков на удивление быстро дали апрув. Закрыв глаза на то, что релизить в пятницу вечером – плохая примета, Михаил ушел заниматься своими делами, а в понедельник обнаружил что его изменения повлияли на политику антифрода и 90% сотрудников было заблокировано. Система не была готова к такому повороту событий, и следующие три дня QA, менеджеры и саппорт разблокировали каждого в ручную. Было потрачено три дня на то, чтобы разобрать последствия, и еще почти две недели, чтобы окончательно исправить эту проблему.

А можно было просто дождаться понедельника и повесить задачу на QA, верно?)

P.S.: тогда мы с юмором отнеслись к случившемуся, потом всей командой скинулись и сделали нашему разработчику кастомную футболку с тематическим принтом, он с гордостью ее носил))

Следующий метод заруинить проект, не менее веселый – это…

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

Давайте приведу пример:

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

Руководство посмотрело на это и решило, что пора выходить на новый уровень, –покорять СНГ. В команду пришли новые люди. План простой: переиспользовать все наработки и запустить сразу две страны. Но оказалось что никто из прошлой команды не оставил после себя никаких документов, инструкций или полезных артефактов. Все обсуждалось в чатах, где и потерялось. В итоге план “туда-сюда миллионер” не удался, а переиспользовать удалось только идею, но не сами наработки.

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

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

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

• отсутствие SSO (логина через корпоративную учетку)

• слабые возможности по обеспечению безопасности

• невозможность централизованного поиска сотрудников по имени

Так и более тонкие, которые становятся заметны только с опытом:

• отсутствие поддержки внутренних ролей и тегов (команд, гильдий, лидов)

• невозможность задать единые стандарты наименования и организации чатов

• отсутствие глубоких интеграций с другими корпоративными сервисами

• слабая система прав доступа на создание и управление контентом

• неудобная работа с оргструктурой

• отсутствие из коробки набора полезных ботов и автоматизаций

Но, думаю, главный недостаток — невозможность эффективно доносить важную информацию до всей компании. В Telegram невозможно выстроить каналы массовой коммуникации так, чтобы они были одновременно централизованными, структурированными и не утопали в шуме. Универсальный чат на 100+ человек быстро становится бесполезным: уведомления сразу же отключают из-за флуда и хаоса. Результат — бесконечное размножение мелких групп, где каждый раз собирается новый состав и информация теряется. Какой выход? Только искать альтернативы привычному.

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

Игнорирование обратной связи.

Без диалога с клиентами растет риск потерять связь с их реальными потребностями. Представление вашей команды может сильно расходиться с тем, что ценят пользователи. Чем это грозит? Очень просто: трата ресурсов на ненужные функции, отрицание, гнев, торг, депрессия и, наконец, открытый документ со статистикой клиентских обращений, но может быть уже поздно.

Важно понимать, что с ростом популярности продукта вычленить полезную обратную связь станет гораздо тяжелее, если неправильно к ней относиться. Уже не получится дать простую коммуникацию с вопросом “Все ли вам нравится?” и вариантами ответов "Да" и "Нет". Аудитория шире, а значит качество аудитории ниже. Чтобы достучаться до всех сегментов, придется использовать более хитрые метрики, расширять штат техничекой поддержки, более тонко размечать данные по тематикам обращений и проблемам, возможно, прибегать к разметке с помощью искусственного интеллекта. На первых порах  это дороже и сложнее.

Например: большой проект, B2B или даже B2G, большие объемы, масса настроек сервиса в личном кабинете клиента. Сделано недостаточно интуитивно. Все, что клиент не понял, кажется ему багом, он идет и говорит вам об этом. А вы объясняете: это не баг, а фича! Объясняете снова и снова, но продукт от этого удобнее не становится. А теперь представьте, потенциальный клиент пообщался с действующим, узнал что фичи не делают по запросу и не стал подключаться, а после и действующий ушел к конкурентам, которые учли его потребности.

Так что не игнорируйте своих неравнодушных пользователей! Иначе продукт быстро станет не востребован. Как итог: работа в стол, открытое резюме на hh.

Человеческий фактор

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

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

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

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

И последний пункт, но не по значимости, а тем более не по моей симпатии:

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

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

Вывод

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

Давайте еще раз вспомним, что поможет нам убить хороший продукт.

• Не тестировать код
  Тестирование — это для слабаков! Настоящие разработчики пишут код и надеются на лучшее

• Публиковать релизы в пятницу вечером
  Никто не будет работать над исправлениями до понедельника, все хорошенько отдохнут! Суеверия для дураков

• Чрезмерная документация
  Напишите столько документации, чтобы пользователи не поняли, зачем они пришли к вашему продукту, а тестировщики забыли что вообще нужно проверить 
  Пусть они потратят часы на чтение вместо проверки!

• Использовать устаревшие технологии
  Зачем обновлять? Они работали когда-то, значит, будут работать и сейчас

• Игнорировать отзывы пользователей
  Зачем слушать тех, кто использует продукт? Это  ведь мы его сделали, значит знаем, что для них лучше

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

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

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

P.S. Шутки шутками, но помните, вечер пятницы дан нам не для релизов!

Обсудить в форуме