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

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

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

Особенные методы работы

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

1. «Забывание» рабочего расписания других локаций — представители заказчика упорно «забывали», что в других локациях другой часовой пояс, люди могут быть доступны только в определенный промежуток времени, и звонили в любое удобное для них время или просили подключить нужного человека на звонок.
2. Публичная «порка» – представители руководства со стороны заказчика на бизнес встречах отчитывали и критиковали докладчика по объективными причинам и нет.
3. Эскалация и поднимание паникии – представители заказчика эскалировали проблемы нашему руководству по поводу и без повода, преувеличивая их значение и создавая атмосферу паники.
4. 5и+ часовые звонки – представитель руководства заказчика создавал звонок, и не отпускал никого со звонка, пока проблема не будет решена.
5. Проблемное взаимодействие с командами заказчика — команды заказчика позволяли себе игнорировать митинги, отказывались делиться информацией, до последнего не признавали баги в продакшен системе и т.д.
6. Постоянное недовольство со стороны заказчика – представители руководства заказчика были все время не довольны, как бы успешно вы не работали, и благодарили за успешно и во время сданный функционал только представителей своей стороны.

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

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

«Забывание» рабочих часов других локаций

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

Как первый шаг, пришлось взять на себя «основной удар» — отучить их звонить напрямую членам команд, а обращаться к lead/scram-master/PM как ко входной точке для получения информации. Ни в коем случае не соглашаться присоединить кого-либо из команд на звонок вне рабочих часов, даже если этот вопрос займет 5 сек. Обычно 5 сек перерастают в 6 часов. Но это привело к тому, что lead/scram-master /PM не спали по ночам. Можно, конечно, сказать, что на то они и руководители, но им тоже спать надо, все-таки люди.

Как второй шаг, мы договорились, что бизнес-митинг (вечерний по нашему времени и утренний по времени заказчика) — этот митинг — веха, позже которой, коммуникация должна быть только через переписку. Конечно, какое-то время звонки продолжались, но тут надо проявить собственную стойкость для того, чтобы не поддаться и не поднять трубку в неурочное время. К сожалению, мы на проекте все-таки дали слабину, и звонки в 12 или 1 час ночи продолжались до конца проекта, но только lead/scram-master/PM. Право спасть спокойно командам мы отстояли.

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

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

Публичная «порка»

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



Если же представитель руководства заказчика все-таки не удовлетворен ответами, или ETA, или звезды не так сошлись, то «порка» обязательно состоится. Тут главное не уйти в эмоции. Мне помогало упражнение, когда я мысленно строила между нами кирпичную стенку, которая защищала меня от давления и негатива, и предельно вежливо отвечала: «Да, это наша ошибка/просчет, все поправим». Могу сказать, что подобный прием помог снизить и количество «порок», направленных лично в мою сторону.

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

Эскалация и поднимание паники

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

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

5и+ часовые звонки

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

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

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

В конце проекта я посчитала накладные расходы по формуле, что предлагает Алексей Баранцев в своей лекции «Метрики в тестировании. Практические советы», и показала заказчику. Значение Kпр было равно 0.75, ох как заказчика не порадовала эта информация, ему раньше никто не показывал такой метрики. Честно говоря, то я сомневаюсь, но одновременно и надеюсь, что это поможет ему в будущем сократить количество митингов и их время у этого конкретного заказчика.

Проблемное взаимодействие с командами заказчика

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

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

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

Постоянное недовольство со стороны заказчика

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

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

• Объём разработанной функциональности 80%
• Объём протестированной функциональности 60%
• Объём выпущенной в prod функциональности 40%
• Количество найденных багов (10) и закрытых багов (5)
• В сроки вкладываемся

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

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

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

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

Вывод

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

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