Недоброе обязательство

Некоторое время назад, когда я начинал карьеру в Pivotal Labs, меня попросили закрепить проект. Якорь - это просто человек в проекте (почти всегда с самого начала), который держится за контекст, обеспечивает хорошее проведение необходимых встреч и помогает управлять клиентом. Это то, чем занимаются все консультанты, но я никогда раньше не ставил якорь.

Я был взволнован, потому что это была возможность улучшить свои навыки и узнать больше об iOS. Этот клиент хотел создать платформу iOS с очень небольшой командой (я, их инженер и менеджер по продукту).

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

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

Благодаря объединению их клиент-разработчик и я смогли признать некоторые трудности того, что мы пытались сделать. То, как он хотел работать, и его опасения были полностью несовместимы с TDD (тестовое проектирование) и общими гибкими методологиями. Хотя я мог объяснить ему это любезно, и он проявил ко мне доброту, общее настроение в проекте продолжало ухудшаться.

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

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

Эффект доброты

Доброта - основная ценность Pivotal. Это одно из самых действенных приемов поведения, которым мы можем научить.

Это суть манифеста обратной связи, в котором говорится, что обратная связь должна быть действенной, конкретной и доброй.

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

И, конечно же, снимает стресс!

Мы не всегда добрые

Проявлять доброту к клиентам может быть непросто. Как консультанты, мы привносим в работу свои личные страхи и неуверенность (синдром самозванца и т. Д.). Клиенты также привносят в свои обязательства свои собственные уникальные страхи. (например: что изменится после взаимодействия с Pivotal? Будет ли у меня еще работа? Может ли этот «проворный» фокус-покус сработать?)

Не забывать практиковать доброту тоже непросто, особенно если ваша команда очень талантлива и опытна. У каждого свое уникальное прошлое, но не у всех есть тот опыт, который есть у вас. Это может быть удивительно, когда вы сталкиваетесь с кем-то, кто не работал с вашей технологией (например, «Что вы имеете в виду, вы не знаете, что такое HTTP?»).

Мы забываем, что наша работа - не показывать, насколько мы умны, а просто заставлять других понимать, на что они способны.

Как это передается?

Есть несколько явных способов проявить доброту. Например:

  • Положительный язык тела
  • Смирение
  • Игра в пинг-понг

(Многие люди в Pivotal любят играть в пинг-понг. Это нормально быть плохим! Когда-то я был очень и очень плохим. На самом деле, я все еще играю, но об этом позже.)

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

  • Запрос обратной связи в конце дня
  • Поощрение застенчивых членов команды к игре в пинг-понг
  • Поддержка кого-то, когда он впервые проводит встречу
  • Признание, уважение и поощрение различных мнений:

«Я считаю, что XYZ - правильный подход, но я могу не согласиться со мной…»

«В последний раз, когда я видел это, проблема была в XYZ, но я могу ошибаться…

«Я хотел бы попробовать XYZ, но я готов сначала заняться ABC…»

Доброе Обручение

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

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

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

Я увидел (и не был удивлен), что все мы в некотором роде чувствовали себя уязвимыми, и мы начали больше обсуждать доброту и уязвимость как команду во время наших ежедневных встреч. Однажды, когда мы все качали головами из-за какой-то странной ошибки, я выразил собственное замешательство и то, что может быть трудно восприниматься как «эксперт», когда вы тоже все еще учитесь. Это сильно удивило клиента. По их мнению, я был экспертом, который знал все «лучшие практики Go». Я мягко напомнил им, что не существует серебряных пуль и что мы все должны стремиться принимать правильные решения, используя имеющуюся у нас информацию, и постоянно искать лучшие модели и решения. Это помогло им осознать, что им предстоит долгий путь, чтобы изучить дисциплину и искусство разработки программного обеспечения, а также научиться развивать и развивать собственное определение эффективного и хорошего Go.

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

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

Что здесь значил успех? Более счастливые и более вовлеченные команды, в которых люди были более уверены в себе и менее бессильны.

Последние мысли

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

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

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

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