Сложности работы с заказчиками или позитивный эффект формализма

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

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

По этому я предлагаю другой ответ на этот вопрос.
Мой ответ базируется на подходе разделения компаний по уровню зрелости, что я привела в статье «Что такое архитектурная модель зрелости компании?»

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

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

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

1. Сложности с управлением временем
2. Сложности при налаживании коммуникации с заказчиком
3. Сложности эскалаций или паника на проекте
4. Сложности on-line общения
5. Сложности взаимодействий с командами заказчика
6. Сложности в получении обратной связи

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

Стратегии для работы со сложностями

Управление временем

Представители заказчика хотят получать ответы на свои вопросы в свое рабочее время, чтобы ее получить они обращаются к тем, кто ей владеет. Но, если владелец информации находитесь в другом часовом поясе, это может означать обращение в нерабочие часы, например в 12 часов ночи. Если подобное обращение происходит в письменно в виде, то тут есть возможность ответить позже. Хотя сообщения в мессенджеры в 12 часов ночи, тоже не очень приятны. Но, что делать, если представители заказчика звонят в это позднее время? Скидывать? А если что-то случилось? А если звонят не руководителям, а любому члену команды на прямую, что бы быстрее было?
Что бы не возникали такие ситуации можно сделать ряд превентивных шагов

Первый шаг, согласовать с заказчиком входную точку для получения информации. Это значит, что необходимо проговорить с заказчиком и записать в отдельном документе роли, которые есть на проекте и ответственны за предоставление ему информации, а так же лично представить людей, выполняющие эти роли.
Например, руководитель разработки у нас Алексей Платковский, а руководитель тестирования Юлия Атласова — они входная точка по предоставлению соответствующей информации.
Вроде бы формализм, но эффект этого формализма – это осведомленность заказчика о конкретных людях, кому можно писать или звонить, и как следствие не надо выяснять сперва, кто может ответить на вопросы, или звонить/писать все команде. Согласитесь, что это весьма удобно, и добавляет благожелательности в общение. Вроде бы очевидно, но очень часто этот очевидный шаг забывается.


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

Но эти два шага направлены на удовлетворения нашего удобства, а как же удобство заказчика? — спросите вы. Для этого как раз и существуют третий и четвертый шаги.

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

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

Сложности коммуникации

У вас было такое, что вы рассказываете свой статус и свои проблемы и блокеры, а на вас смотрят непонимающим взглядом. Или вот пример:
Я. — Мы провели тестирование, нашли 8 багов, 4 из них критичные, и мы ждем установки обновлённой версии, что бы их перепроверить.
М. — Эээ, не понял, так работает или не работает?

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

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



И читается она так:
у нас есть проблема в несоответствии данных по расчету скорости в виджетах на prod системе и UAT системе, мы знаем причину проблемы, ее исправление будет нам стоить 1 день работы 1 разработчика, после исправления необходима переустановка и повторная проверка — это так же займет 1 день и нужен 1 тестировщик. Итого суммарно на эту проблему надо 2 дня и 2 человека. Через 2 дня мы можем установить исправленную и проверенную версию приложения для проверки пользователей со стороны заказчика.
Согласитесь, что этот вариант звучит понятно даже не для менеджеров!

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

Эскалация или паника на проекте

Иногда случаются непредвиденные ситуации, кто-то кого-то не понял, и на проекте случается паника. Самое интересное, что паники возникают стихийно и обычно на пустом месте. Почему?
Как правило это кто-то кого-то недопонял или не нашел информацию в документации. Так бывает, мы все люди. И если уровень зрелости компании низкий, то чаще всего при появлении паники идет прямое обращение к вашему руководству или к руководству вашего руководства. Тут главное придерживаться совета из мультика «Карлсон»: Спокойствие, только, спокойствие. А далее не спасовать самому, прояснить проблему детально и предложить пути решения с оценками времени своему руководителю, т.к. он уже был во вовлечен, то от него ожидают подобной информации. Затем уже проблема будет обсуждаться представителями заказчика. Обычно все вопросы решаются за таким обсуждением достаточно быстро. Но паника могла бы и не возникнуть при соблюдении определенного уровня формализма, если бы информация была в документации.
И вот реальный пример подобной паники: была переработана оригинальная система, которая проходилась по всем данных из хранилища, и на основании этих данных делала расчеты на последующие 3 года. Переработанная система работала 6 часов, кто-то со стороны менеджмента решил, что это очень продолжительное время и систему надо ускорить. Началась паника и эскалация, архитекторы и разработчики показывали, что ускорение технически невозможно (и так выжали все, что могли), а менеджеры настаивали – это очень долго. А дело было в том, что затерялась информация о том, что оригинальная система работала 3 суток (кто-то кого-то недопонял или не нашел информацию в документации). Информацию то нашли, панику то погасили, но осадочек то остался.

on-line общение

Сложность on-line общения — это время. Обратили внимание, что при работе из дома время on-line встреч удлинилось. Но порой на проектах изначально время митингов занимает большую часть рабочего дня. А когда же работать?!
С этой сложностью можно побороться при помощи формализма. Если на проекте есть возможность списывать время митингов в отдельную задачу, то надо списывать, и потом показать заказчику, что митинги в день в течение недели занимали по 5 часов. Только 3 часа осталось на работу соответственно рабочие задачи не могут быть решены к поставленному сроку. Это скорее всего это поможет сократить количество митингов и их время.

Если же подобной задачи нет, то можно подсчитать накладные расходы по формуле, что предлагает Николай Юденко в своей лекции «Метрики в тестировании. Практические советы», и показать заказчику. Например, если значение Kпр равно 0.75, то это скорее всего не порадует заказчика.

Есть еще один вариант — это использование on-line калькулятора стоимости митингов. Ведь время — это деньги, чем дольше митинг тем дороже он стоит, и это можно показать!

Взаимодействие с командами заказчика

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

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

Вот тут проявляется в полной мере позитивный эффект формализма:

1. Оформляем баг в bug tracking системе
2. Отсылаем письмо со ссылкой на баг команде заказчика
3. Ставим в копию своих менеджеров и руководство заказчика
4. Согласовываем необходимость митинга по обсуждению бага и время, которое всех устроит
5. Если митинг не состоялся, письменно повторно запрашиваем еще один

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

Обратная связь

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

• Компания заказчика 0, 1 или 2 уровня архитектурой модели, когда есть проблемы с процессами в самой компании, а любое внешнее воздействие — это дополнительная нагрузка на эти процессы, тут сложно ожидать обратной связи, скорее всего она поступит позже, когда процессы установятся.
• У компании заказчика негативный предыдущий опыт работы с it outsource, в таком случае, недоверие надо преодолеть, и после уже можно ожидать обратной связи.
• Ожидания заказчика не были достаточно проработаны и не совпадают с результатами работы, но обратной связи нет и мы не можем об этому узнать, что бы исправить или проработать, вот тут работа для очень опытного менеджера помочь разобраться в этой ситуации получить обратную связь, какой бы они не была.

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

Позитивный эффект формализма

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

Вывод

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

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

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