Как подружиться с заказчиком и не рассориться между собой: шесть историй с одного большого проекта
Я руковожу проектами уже восемь лет, и за это время успел познакомиться с разными командами и заказчиками. О работе с одним из клиентов я и решил рассказать: проект был долгим, историй накопилось много. Эта статья не сборник рекомендаций, в ней только личный опыт. Но думаю, что вопросы, ответы на которые нам пришлось искать, рано или поздно станут на пути большинства PM. Можно ли установить тесный контакт с людьми, сидящими на расстоянии 3000 км? Как не стать бутылочным горлышком, замкнув на себе большинство важных вопросов? Кому и когда рассказывать о проблемах? Наконец, в какой ресторан вести гостей из Лондона, Мюнхена или Копенгагена? Задуматься о том, как функционирует большой проект, полезно всем, кто работает в распределенных командах. Надеюсь, записанные мной истории наведут вас на интересные мысли.
Этот проект был самым ярким за 14 лет моей работы в DataArt и, думаю, одним из самых запоминающихся за всю историю нашей тревел-практики. За три года работы команда пережила взлеты и падения, успела во всей красе ощутить на себе модель Такмана, пережить «болезни» взрывного роста с двух до 75 человек и изобрести собственные модели на замену Agile-подходам, которые не сработали. После всех трудностей в проекте сложился коллектив, способный сворачивать горы, причем в сроки, которые раньше казались мне совершенно нереальными.
Иллюстрация Алины Самолюк
По понятным причинам заказчика я не называю, но о характере его бизнеса немного рассказать могу. Это инновационный стартап, решивший поколебать привычные паттерны взаимодействия отеля и постояльца. Планшет с их приложением заменяет ресепшен и службу консьержа, позволяет заказать ужин, купить сувениры, составить маршрут прогулки или отрегулировать температуру и освещение в номере.
С заказчиком нам, можно сказать, повезло. Как и в большинстве стартапов, его коллектив состоял из харизматичного основателя, команды продавцов, дизайнеров и двух программистов. Цель компании была определена четко — выйти в своей области на первое место в мире (надо сказать, когда мы начинали, услугами их сервиса уже пользовался десяток отелей в Лондоне, но сейчас в списке клиентов сотни гостиниц от Америки до Азии). Главным по взаимодействию с нашей командой стал живущий в Лондоне немец, который был по совместительству модным диджеем. Назовем его Кристиан. Опыта работы с удаленными командами, тем более в проектах такого уровня, у него было не очень много. Но надо признать, что проект во многом держался как раз на его кипучей энергии и энтузиазме и конечному успеху Кристиан здорово способствовал.
На этом я перейду непосредственно к историям. Я не стал располагать их в хронологическом порядке и почти не добавлял к ним нравоучений. Но, надеюсь, кое-какие выводы из них можно сделать и так.
Плюшевая обезьяна
Все, кому приходилось управлять командой, рано или поздно сталкиваются с проблемой тайм-менеджмента. Ты существуешь в режиме постоянной нехватки времени, и это становится частью твоей жизни. Каждый день менеджер возвращается домой (даже после 10 или 11 часов на работе) с чувством, что все равно ничего не успел, оставив в офисе сотню нерешенных задач. Их рассчитывает завершить завтра. Но на следующий день количество задач удваивается. Быстро в такой ситуации оказались и мы.
Книг и статей про тайм-менеджмент тонны, однако один коллега посоветовал начать с классики и прислал ссылку на статью Who’s Got the Monkey, написанную в далеком 1974 году. И я как начинающий РМ, и Кристиан очень быстро прониклись идеей контроля за «обезьянами», которых команды и менеджеры пересаживают друг на друга вместе с проблемами. Слово monkey вошло в наш ежедневный обиход, иногда мы использовали его по сто раз на дню. При этом одной фразой вроде I got this monkey или Now this developer feeds the monkey можно было описать целый комплекс принятых мер. Надо признать, объем микроменеджмента в нашей с ним работе сократился, а времени на приоритетные задачи стало больше. Да и команде стало с нами проще и понятнее работать.
Полгода спустя, когда Кристиан вместе с продакт-оунером приехали к нам в гости, они первым делом торжественно вручили мне плюшевую обезьяну со словами «Now you finally got the real monkey». Этот трофей был знаком признательности за то, что мы не только выполняем работу, но и делимся знаниями, помогаем конкретным людям на стороне клиента. Когда учишься вместе с заказчиком, это не только решает конкретные проблемы проекта, но и отлично укрепляет ваши отношения.
Видео о команде, строчка кода толщиной в волос и космический репозиторий
На второй год сотрудничества нам предложили приехать в Лондон на двухдневный воркшоп, который задумало руководство компании. Мы вместе с сотрудниками заказчика должны были провести два дня в изоляции, в отеле далеко от Лондона. И это был не просто тимбилдинг: за это время все должны были разобраться, что именно делают другие отделы и команды и каков вклад каждого в развитие проектов. На первый взгляд затея может показаться странной, ведь на тот момент компания существовала уже около четырех лет — по идее все должны были прекрасно знать друг друга и понимать распределение задач. Но на самом деле все было иначе. Продавцы понятия не имели, чем заняты разработчики, дизайнеры не представляли, какие проблемы бывают у аккаунт-менеджеров (они их называли РМ).
Руководителю каждого отдела дали два задания: подготовить презентацию о своих задачах и команде, а также сделать интерактивный воркшоп, который бы на практике объяснил другим, чем отдел занимается и какие проблемы решает.
Кристиан сразу пришел к нам. Уже после небольшого совещания мы осознали, что с наскока сделать все красиво не получится, к задаче нужно подойти творчески. Начались недели так называемых мозговых штурмов.
Какие проблемы мы хотели решить:
- Показать всю команду. Кроме немногих, кто приезжал к нам в гости, никто ни разу (за два года!) не видел наших разработчиков и QA.
- Показать объем работ, который мы проделали. На стороне заказчика его тоже почти никто не представлял.
- Ответить на вечные вопросы продавцов и менеджеров на стороне заказчика: «Что вообще может делать команда в 60 человек, если я не вижу почти никаких изменений в продукте?», «Где новые фичи, которых я жду целый год?!»
- Сделать воркшоп интересным и понятным для людей, далеких от программирования. При этом объяснить, из каких частей состоят наши продукты и как взаимодействуют друг с другом.
Надо заметить, что семь лет назад наш отдел маркетинга был еще совсем не таким, как сейчас, поэтому нам приходилось рассчитывать на собственные силы. Мы хорошо умели писать код и тестировать продукты, а вот вся эта красота и презентации — это было не про нас.
Идея первая: показать объем работы. Как объяснить, что простая страничка в клиентском приложении — это тысячи строчек кода, что за ее созданием стоят огромные усилия многих ребят, причем не только разработчиков? Словами можно, но будет ли это достаточно убедительно? Мы решили продемонстрировать это на примере, сравнив что-то очень маленькое и что-то очень большое, желательно хорошо знакомое аудитории. Образы искали долго, в итоге посчитали количество строк в клиентском приложении. И вставили в презентацию слайд, где показали, что будь строчка нашего кода толщиной в человеческий волос, собранные вместе они составили бы конструкцию высотой более 135 м. То есть наше приложение оказалось бы выше одного известного объекта в центре Лондона.
Из зала во время презентации раздавались возгласы типа «ого, в таком маленьком приложении — так много!»
Однако мы решили, что только этого недостаточно — как-то несолидно. Надо показать работу в динамике, дать понять, что же поменялось, когда DataArt и заказчик начали работать вместе как одна команда. Картинки приложения до и после? Опять количество строчек? Увеличение производительности и большая стабильность? Наверное, но все-таки не то.
Но ведь не мы первые рассказываем продавцам и маркетингу, что такое работа программистов. В конце концов наткнулись на замечательную программу, позволяющую визуализировать репозиторий — то, как он менялся во времени. Попробовали и сразу поняли: да, это оно!
Наше видео мы не можем показать из соображений конфиденциальности, но это демо может дать общее представление о том, как выглядит визуализация, сделанная с помощью Gource
Во время презентации было интересно следить за реакцией зала. Должен сказать, это было нечто.
Идея вторая: познакомить с командой. Окей, первую проблему решили. Но как быть с командой? Просто вставить в презентацию фотографии коллег? Нет, не наш метод. Сначала решили поснимать наш офис на телефон: сделать видео, где ребята работают за компами. Однако быстро поняли, что в плане видео мы совсем не тянем — не было у нас таких людей, а на коленке красиво сделать вряд ли получится. Приняли волевое решение нанять профессионала, который знает свое дело. В день съемок пришлось оторвать большую часть команды от работы для создания оживших фото (привет Гарри Поттеру!) с имитацией митингов и всяких обычных дел. Оказалось, что реальность выглядит гораздо более правдоподобной, если ее все-таки сыграть. Но и результат был гораздо круче наших изначальных ожиданий.
Вот так, иногда от клиента приходят запросы не только на создание продуктов, что мы умеем хорошо, но и на вообще никак не связанные с разработкой вещи, требующие нестандартного подхода. И я горжусь, что работал в команде, которой любые задачи были по плечу.
Заказчики в рамочках
За все время проекта мы старались уделять психологическому и коммуникационному аспектам повышенное внимание. Пытались показать тех, кто составляет команду, объяснить, какие роли они выполняют, в чем сильные стороны каждого.
Во многих проектах как происходит? Заказчик в основном общается с РМ, DМ и парой ключевых людей. Тех же, кто выполняет основную работу по созданию и тестированию продукта, никто никогда не видит. Нельзя сказать, что это однозначно плохо. Но и хорошей такую ситуацию точно не назовешь. Просто если все коммуникации завязать на менеджеров, со временем они оказываются так называемым бутылочным горлышком, отчего становится хуже всем: команда не получает необходимой информации, заказчик начинает ассоциировать весь большой коллектив с лицами всего лишь пары человек. Для больших проектов это может вылиться в серьезные проблемы с коммуникациями, исказить восприятие команды, да и компании, которую она представляет, в целом.
Мы старались показать команду не в виде списка в Excel, а как-то более наглядно. Ниже — один из примеров. В табличке видно, кто за какой продукт отвечает, к кому обращаться с конкретным вопросом.
Однако таблички и вообще любые онлайн-документы не решали главную проблему — те люди на стороне заказчика, которые этих документов не видят, не имеют никакого представления о тех, кто для них работает в DataArt.
Наша АМ-команда обсуждала, как сделать коллег «олицетворенными» для заказчика. Хотелось, чтобы на вопрос сейлза на другой стороне «кто пишет мой продукт?» мы могли ответить «парень на третьей фотке сверху с непроизносимым для англичан именем Вячеслав. Это вот он сделал так, чтобы шторы в номерах гостиниц нормально открывались через приложение».
Для нас это может казаться мелочью. Ну зачем тратить время и силы? Но для англичан важен фактор личного общения. И уж как минимум они всегда хотят точно понимать, кто отвечает за то или иное направление. Если их самих спросить, кто может помочь с определенной проблемой, они не скажут идти к РМ или руководителю маркетинга, а назовут конкретное имя.
Но что в итоге — фотографии в рамочках? Нет, что-то не то. Простой набор портретов выглядит как-то блекло. И мы решили дополнить их описанием, как в RPG. Попросили наших дизайнеров сделать макет.
Идея всем сразу понравилась. Хотя, надо признать, выбить из коллег вразумительные био и наборы скиллов оказалось той еще задачей.
Начали мы с двух рамочек от нас, вывешенных в Лондоне, и двух рамочек с портретами партнеров со стороны заказчика в нашем офисе (правда, на последних были люди, которых у нас все и так прекрасно знали).
Однако мы не стали останавливаться на достигнутом и старались по мере роста команды каждый раз печатать новые рамки и передавать заказчику. Единственная проблема заключалась в полном отсутствии свободного пространства у них в офисе. Но мы нашли то, что было. Вот как это выглядело поначалу.
Процесс остановили, когда команда выросла более чем в два раза и рамочки просто физически стало некуда вешать.
Интересно, это в итоге оказалось совсем не пустой затеей. Нас действительно стали воспринимать как команду индивидуальностей, а не N девелоперов и X QA.
Как-то во время командировки ко мне подошел один из сейлзов и попросил передать Александру слова благодарности: «Приложение, что он сделал, просто шикарное». Я говорю — какому Александру? Он — справа вверху, который эксперт по iOS.
Круглосуточный телемост, или Большой Брат не пройдет!
А вот этот рассказ о том, что лучшее — враг хорошего. Выше было несколько примеров, как много сил и внимания мы уделяли тому, чтобы заказчик нас считал не только сервис-провайдером, которого наняли выполнить определенную работу, а полноправным партнером, чувствовал, что мы — одна команда, работающая над единой целью. Надо признать, что усилия не были напрасными. Однажды клиент даже пришел к нам с предложением настроить телемост, чтобы сотрудники могли круглосуточно видеть офисы друг друга. Можно, мол, будет помахать друг другу ручкой время от времени, и это позволит сблизить два коллектива. Фотки команды заказчика мы все видели, но вживую, хотя бы по видеосвязи, общались немногие.
Идея отличная, по крайней мере так нашей АМ-команде показалось вначале. На митинге я рассказал об этом остальным коллегам, занятым в проекте. Предложил всем вместе, ну или большинству из нас, занять один большой квадрат на этаже, благо пространство позволяло.
Реакция, однако, была несколько неожиданной. Многие сразу начали скандировать, что категорически против сидеть под наблюдением (даже если монитор будет не видно). Другие соглашались, что да, инициатива вроде логичная, но сами при этом не хотели попадать в поле зрения камеры. Никакие доводы и убеждения не помогали.
В итоге провели анонимное голосование, где выяснилось, что половина против, вторая нейтральна, но все-таки будет не очень счастлива, если телемост заработает. Наверное, только двое человек идею поддержали. Победила демократия, команда нашла основания для отказа и избежала, как оказалось, дополнительного, пусть и небольшого, стресса (в больших проектах его и так всегда хватает).
Перед заказчиком извинились, сказали, что команда не хотела бы. На той стороне к нашему решению отнеслись с уважением.
Хотели как лучше, а потеряли всех дизайнеров
На протяжении всего времени совместной работы заказчик уделял огромное внимание внешнему виду своих продуктов. Дизайн всегда должен быть на высочайшем уровне, ведь речь шла о сотрудничестве с
У команды разработчиков быстро возникла проблема — как работать с дизайнами, которые, по сути, — перекрашенные картинки в Photoshop, без указания цветов, шрифтов и прочего, необходимого при создании UI. Мы постарались быстро взять в команду своего дизайнера, права которого, правда, были сильно ограничены. Заказчик не признавал никаких доводов и не хотел допускать к проектированию дизайнов человека со стороны, несмотря на всю глубину нашей дружбы и взаимного доверия. Поэтому нашему коллеге не оставалось ничего, кроме как транслировать картинки в формат, необходимый для фронтенд-разработчиков.
Проблема усугублялась тем, что сроки сдачи были классические («на вчера»), а дизайнеры заказчика поставляли все в последний момент. Долго думали, что с этим делать. Решили, что наш дизайнер будет периодически подсказывать коллегам на другой стороне, проводить сессии обучения новым инструментам и прочим хитростям работы.
Инициатива очень понравилась заказчику. Дизайнеры на его стороне взялись за обучение с неистовым энтузиазмом. Жизнь начала налаживаться. И у нас дизайны в разумные сроки в нужных форматах, и заказчик доволен.
Однако месяца три спустя ждем мы очередных дизайнов, начинаем волноваться, сроки поджимают. Спрашиваем Кристиана, где они. А он говорит, что, мол, все трое дизайнеров у них в один день уволились, нашли себе позиции с более солидной оплатой. Ведь они научились многому и на рынке труда теперь выглядят совсем не джуниорами.
Понятно, что трагедии из этого не вышло, через какое-то время заказчик нанял новых дизайнеров (нам дизайн тогда так и не доверили). Однако с практикой обучения мы решили малость притормозить.
Эта история заставила нас задуматься об анализе и планировании. И я как раз узнал про квадрат Декарта и первый раз попробовал применять его на практике. Самый сложный из четырех вопросов — что плохого произойдет, если мы сделаем что-то позитивное?
Гепард
Большинство коллективов, которые работают вместе достаточно долго, постепенно начинают пополнять лексикон новыми фразами, придавая привычным словам и выражениям совсем не те значения, что обозначены в словарях. В команде появляются традиции и ритуалы, иногда уже никто не может объяснить новичкам, почему и с каких пор так повелось. У нас таких фраз было много, надо признать.
Как часто бывает со стартапами, мы работали в условиях жуткой нехватки времени, которая усугублялась хаосом, отсутствием разумного планирования, конфликтами стейкхолдеров и дедлайнами, которые диктовали нам сейлзы. В таких условиях отсутствие документации и хоть какой-то базы знаний быстро создает информационный голод. Чтобы его восполнить, команда находит того, кто «знает все». Постепенно к такому человеку начинают ходить все, даже не задумываясь, что у него может не быть ответа на их вопросы.
В этом проекте таким человеком стал я, потому что был одним из двух разработчиков, начинавших его. А может, потому что больше всех общался с заказчиком. Или по каким-то другим причинам.
Иногда ситуация доходила до абсурда: позади моего рабочего места выстраивалась живая очередь из тех, кто хотел меня о чем-то спросить. С так называемыми быстрыми вопросами, не требующими обсуждения, а значит и отдельно запланированного митинга. Большинство вопросов, конечно, были по делу, и я на них всегда отвечал, даже если приходилось отрываться от чего-то срочного. Но некоторые заставляли задуматься: я что — всемирная энциклопедия, где можно узнать «какое млекопитающее самое крупное» (полосатый кит) или «какое млекопитающее самое быстрое?» (гепард).
В общем, как-то со временем ответы на вопросы не по адресу сократились до слова «гепард», чтобы не тратить много времени. Ребята понимали: это означает, что готового ответа у меня нет и лучше поискать человека в команде, который сталкивался с конкретной проблемой.
Я совсем не горжусь таким подходом и в последующих проектах уделял огромное внимание созданию и наполнению Confluence, старался, чтобы ключевые хранители информации тратили время на создание статей, диаграмм и прочих артефактов, которые помогут команде в дальнейшем. И да, «гепард» я после этого проекта не употреблял, хотя это слово можно иногда услышать от бывших членов команды в значении «пожалуйста, не приставай ко мне с такими вопросами».
Национальная кухня как способ (не)приятно удивить заказчика
Практически в каждом проекте мы стараемся приглашать заказчика в гости, чем-то удивить, обязательно помочь с размещением, транспортом и бытовыми мелочами. Конечно, совместный поход в ресторан после работы — неотъемлемая часть такой программы.
В тот раз из Лондона к нам прибыли двое: датчанка, скажем, Эмма и уже знакомый вам Кристиан, родившийся в Баварии. Теперь, прожив несколько лет в Великобритании, я понял, какое внимание здесь уделяют здоровому питанию. Наверняка сейчас я бы заранее уточнил и предпочтения, и ограничения, даже об аллергических реакциях спросить не постеснялся бы. Тогда же я знал только одно — гостям из Индии не стоит предлагать говяжий стейк. На том мои познания заканчивались.
В общем, на закуску мы заказали на всех жареную корюшку, сало с чесноком, чесночные жареные хлебушки и свиные ушки. Не знаю, как вам, а мне все это безумно нравилось и не казалось чем-то криминально нездоровым. Смотрим на Эмму и Кристиана: «Это вообще что? Уши? Нет, спасибо. Жир (так мы перевели сало)?! Вы жир прямо с жиром едите, вы сумасшедшие?»
Закуски мы доели сами, но и борщ с пельменями оказались мимо! «Вы зачем капустный салат варите? И почему эти равиоли такие странные?» Закончилось все двумя салатами «Цезарь».
Вечер столкновение культур и кулинарных привычек нам не испортили, но на заметку возможность таких поворотов я бы взял. Хотя год спустя, когда к нам снова приехали заказчики, мы повели их в ресторан кавказской кухни — всем очень понравилось. Поэтому мне кажется, все-таки стоит удивлять клиентов, знакомить с чем-то новым и не бояться возможного непонимания. Компромисс всегда найдется, зато поездку ваши гости запомнят.
Поделись проблемою своей (с менеджером)
У вас в проекте никогда не было ситуации, когда разработчик или DevOps говорят PM, что завтра все будет, но проходит день, другой, иногда неделя, а на все вопросы продолжает звучать «завтра»? При этом люди работают много и вроде бы интенсивно, что-то явно делают, но проблема не решается?
Такое возникает часто, но мне почему-то особенно запомнился один случай.
Заказчик практически с первых дней выразил желание, чтобы деплой с тестовых окружений в продакшн происходил нажатием одной кнопки, был быстрым и контролируемым. Над выполнением этой задачи мы без остановки работали не меньше двух лет. В команду добавили двух DevOps.
У нас инфраструктура прода (environment, на котором крутится и работает основной продукт, который используют конечные пользователи) была на AWS и распределена между
Собственно, в один момент мы всей командой стремились попасть в дедлайн, жесткий и даже жестокий, без возможности переноса, так как он был привязан к очередной выставке Travel & Hospitality. Разработчики все сделали, QA протестировали, дело за малым — выкатить на прод. Но вот что-то не выходит каменный цветок. День проходит, другой, и я начинаю нервничать, и заказчик.
Подхожу к ребятам, спрашиваю: «Как же так, у вас вроде кнопку нажал, и все задеплоилось? Раньше ведь работало, почему теперь не так?» Мне отвечали, что все под контролем, мол, сейчас тут немного подпилим — и все взлетит. Не взлетало.
В итоге чисто случайно пересеклись в курилке, я попытался навести мосты, зайти с другого угла и понять, в чем же проблема. Оказалось, все проще простого. Production instance была сконфигурирована под множество взаимосвязанных серверов, а вот на тестовом environment все крутилось на одном. Отсюда и возникали проблемы: деплой на тестовый сервер кардинально отличался от деплоя на прод. И ребята пытались на лету переконфигурировать всю процедуру, по сути, с нуля.
Я у них спрашиваю, чего молчали? Давайте у заказчика попросим сделать зеркальное отражение (чтобы тестовые сервера в точности повторяли прод). Мне в ответ: нет, заказчик же экономит, мы лучше продолжим, и скоро все проблемы победим.
Пришлось немного подготовиться в плане математики и посчитать, есть там экономия или наоборот. Простые вычисления показали, что дешевле заказчику будет потратиться на дополнительные мощности AWS, чем платить DevOps за все часы, что они тратят каждый месяц.
Доводы были услышаны, математика сыграла свою роль. На следующий день нам разрешили докупить все необходимое на AWS. И в своих последующих проектах я всегда пытался донести до команды: не молчите, не пытайтесь самостоятельно побороть проблему, если видите, что долго не можете продвинуться. Всегда можно найти альтернативное решение, о котором вы, возможно, не догадывались. Иногда клиент даже может отказаться от фичи, если справиться с ней оказалось слишком уж сложно. Нужно только внятно объяснить, в чем проблема.
Вывод
Надеюсь, какие-то из этих историй показались вам хоть немного интересными, раз уж вы дочитали до этой строчки. В проекте у нас были и головокружительные взлеты — нашу команду чуть ли не на руках носили, и трудности, которые казались непреодолимыми. Но мы продолжали работу, методично улучшая процесс взаимодействия, укрепляя отношения и не скрывая проблем. Наш проект можно было бы охарактеризовать множеством слов, вот только «скучный» или «однообразный» там точно не будет. И я с удовольствием передаю пламенный привет всей команде, вместе с которой над ним трудился!
