company_banner

Как китайские стратагемы помогают в работе

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

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



    Алексей Золотых (zolotyh) — тимлид в Infobip. Алексей использует в своей работе правила ведения войны древнего Китая. Из статьи на основе его доклада на Saint TeamLead 2019, вы узнаете, как стратагемы помогают в жизни тимлида: как помириться с разработчиком внутри команды, как завоевать авторитет среди коллег, как отстоять свое мнение, зачем жертвовать сливой, ругать акацию, прикидываться безумным и бить по траве.



    Стратагемы

    Стратагема — это просчитанная последовательность действий, направленная на решение конкретной задачи.
    Это правила, стратегические ходы и тактические приемы для достижения разных целей. Стратагемы использовалась в военных действиях. В основном, о них рассказывается в книгах «Тридцать шесть стратагем» и «Искусство войны», которые приписывают Сунь-цзы. Этот китайский стратег и мыслитель жил примерно за 500 лет до нашей эры. Но понятие «стратагема» живет в культуре Китая уже 3 000 лет, поэтому можно считать, что автор трактатов — весь китайский народ.

    Но возникает вопрос — мы же тимлиды, причем здесь война? Мы не воюем, ни с кем не деремся и не захватываем, зачем нам стратагемы?

    Система сдержек и противовесов


    В книге Рея Далио «Принципы» есть важная мысль: любая компания или команда это система сдержек и противовесов. Компания — это замороженные конфликты и конфронтации.

    Объясню на примере. В компании «Абстракт» работает два отдела: тестировщиков (QA) и разработчиков. Цель разработчиков — как можно быстрее добраться до продакшн и выпустить продукт к сроку, потому что у них на это KPI. У тестировщиков другие приоритеты: им важно найти как можно больше багов, потому что у них KPI на качество. Два абстрактных отдела в абстрактной компании постоянно вступают друг с другом в абстрактные конфликты и конфронтации.

    Похожая ситуация между HR и владельцами компаний. Упрощенно, цель HR — нанять как можно больше людей. Но для этого придется раздуть бюджет, потому что нынче люди в IT дорогие. Владельцы компаний хотят нанять людей подешевле. Опять конфликт и противостояние.

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

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

    Полководец медлит, потому что разглядывает победу




    Нужно готовиться к каждому митингу. Кажется, здесь появляется Капитан Очевидность, но нет, подождите…

    «Выигрывает вовсе не тот, кто умеет играть по всем правилам. Выигрывает тот, кто умеет отказаться в нужный момент от всех правил, навязать игре свои правила, неизвестные противнику, а когда понадобится — отказаться и от них». Это объяснение стратагемы из одной книги о них. Если применить к IT, то здесь говорится, что тот, кто устанавливает правила в начале митинга в нем и побеждает.

    В 2017 году я выступал на конференции. Одна из целей моего выступления была «продать» аудитории язык Dart. Это довольно странный ЯП, не мейнстримный, но я его очень люблю. Понятно, что публика на конференции к нему не готова, поэтому я придумал «военную хитрость».

    Я позвал на сцену «жюри» из трех человек, чтобы они озвучивали определенные характеристики JavaScript, TypeScript и Dart и сравнили эти три языка. Но я сам задал формат соревнования и сам придумал правила. Как ведущий и главный на сцене, я говорил:
    — По моим оценкам в TypeScript типизация на 5 баллов из 10, в JavaScript ее вообще нет, а в Dart на 10 из 10.

    Кто, кроме Чака Норриса, все равно выберет TypeScript при таких доводах? Это не логично, никто не хочет быть «не как все». Поэтому у жюри просто не было возможности выбрать победителя иначе, чем в том формате, который я задал. Предсказуемо в этом «сражении» победил Dart, потому что я подготовился.

    В покое ожидать утомленного врага




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

    «Давайте все перепишем на...»


    Как у тимлида, у меня есть относительная свобода в выборе технологий, поэтому ко мне часто приходят мои сокомандники (я не употребляю слово «подчиненные», считаю, что это неправильно). Обычно они говорят что-то такое:
    — Давай выкинем TypeScript и перепишем все на Flow!

    Или:
    — Есть классная штука — GraphQL. Ты про нее делал доклад и за нее агитируешь. Давай внедрим!

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

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

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

    Так я убиваю двух зайцев:

    • не затыкаю человека и не слышу потом на каждом митинге о GraphQL, как он решит все наши проблемы и прочее;
    • если человек все-таки доведет проект до конца, то станет хорошим тимлидом в будущем, а у нас появится что-то новое и крутое.

    «Мне лень писать, давай голосом»


    Этот лайфхак мне подсказал хороший друг. Представьте, что вам приходит pull request и нужно провести ревью, найти какие-то ошибки. Вы понимаете, что в этом pull request корень зла сидит глубоко: разработчик абсолютно не понимает, что он делает, поэтому все пишет неправильно, и вы об этом сообщаете. Разработчик не согласен (ожидаемо), приходит к вам и говорит: «Слушай, мне лень писать, давай обсудим так».

    Не соглашайтесь на это! Если к вам приходят поговорить, то «поговорить» — это бесплатно. Можно говорить час, и вам это ничего не стоит. У нас вся переписка ведется на английском языке, а когда приходится отвечать, то иногда быстрее переделать, чем лезть в Google Translate. Споров становится меньше: человек уже утомлен, ему не интересно бороться.

    Пожертвовать сливой, чтобы спасти персик




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

    Scrum головного мозга


    В Infobip есть два условных мнения: одни говорят, что Scrum и Agile — это круто, а другие предлагают писать больше кода и меньше болтать. На совещаниях вторая позиция выражается в том, что человек берет с собой ноутбук и утыкается в него — от него ничего не добьешься.

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

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

    Указывая на тутовое дерево, ругать акацию




    У Григория Бакунова есть хороший доклад, в котором он высказал мысль, что любой разработчик находится в творческом процессе свойственном детям от 5 до 7. По его словам, любому разработчику от 5 до 7 лет (условно), и с ним нужно разговаривать как с ребенком.

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

    Как это применить на разработчиках? Раньше, когда хотел дать кому-то фидбэк, то говорил это напрямую:
    — Олег, ты здесь и здесь не прав. Чтобы завтра все было лучше, делай так и так.

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

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

    Прикидываться безумным, сохраняя рассудок


    Прикидываться дураком мой любимый лайфхак. Принцип простой: если у вас есть технический вопрос, спросите. Не знаю как вы, но я не самый умный человек в команде и прекрасно это осознаю.
    Задавать вопросы — это нормально.
    В одной из моих предыдущих компаний работал человек на достаточно высоком посту VP of engineering (CTO). Он все время повторял:
    — Я в ваших технических штуках не понимаю, объясните русским языком.

    Или:
    — Это приведет к запутыванию кода. А чем это нам грозит? Почему? Как?

    У CTO таких как я еще 30 человек. Единственный способ понимать, что происходит — расспрашивать снова и снова.

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

    Если вам кажется, что так вы потеряете свой «авторитет» и «профессиональное лицо», то вспомните Ричарда Фейнмана. Это лауреат Нобелевской премии, соавтор теории квантовой электродинамики, один из разработчиков атомной бомбы, художник и взломщик сейфов. В 60-х Фейнман вел свои лекции в Caltech, которые позже выпустили в виде трех томов «Фейнмановских лекций по физике». До сих пор это одно из самых понятных и популярных объяснений физических явлений от механики до квантовой физики.

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

    Заманить на крышу и убрать лестницу



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

    — Стоп! Что нужно, чтобы понять сроки?
    — Это, это и то.
    — Тогда проведем митинг 1 октября. Давайте к этому времени поймем, успеваем мы или нет.
    — Но как же? Может ураган начаться, не прийти автобус, кто-то заболеет – как мы это все учтем?
    — Ага, и Годзилла нападет… Давайте упростим задачу: решим, что мы ничего не найдем, а если найдем, то просто об этом скажем руководству. Но к 1 октября это должно быть сделано.


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

    Если хочешь что-нибудь поймать, сначала отпусти




    Дайте возможность сохранить лицо


    Я пришел тимлидом в уже сложившуюся команду. Естественно, первое, что я решил сделать — это «продать» свой авторитет.

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

    Все эти результаты я выложил своему «сопернику» в надежде, что он осознает свою ошибку, и все уляжется. Но все вышло иначе. Мой оппонент понял, что теряет авторитет. Теперь его не интересует продукт и все равно, кто прав, а кто нет — важно сохранить лицо. После этого каждое мое решение встречало резкий отпор. Разработчик не думал о проекте, он думал о том, как показать, что он умнее. Все закончилось болезненным переводом человека в другую команду (увольнением). Я был прав, но не дал человеку сохранить лицо. До сих пор жалею об этом.
    Дайте противнику возможность выйти из ситуации достойно.
    Даже если вы полностью правы — оппонент должен сохранить свое достоинство. Если вы наступите на мозоль, то приобретете врага.

    Сайт как помидор


    Еще один забавный пример услышал в лекции Людвига Быстроновского, арт-директора студии Лебедева. Представьте дизайнера, который предлагает сделать сайт как помидор. Непонятно, как это будет выглядеть, а главное зачем? Но дизайнеру нравится и он продвигает свою «идею» только потому, что он ее придумал.

    С такими идеями, конечно, соглашаться не стоит. Возвращайте человека на землю:
    — Я понимаю, что ты отличный дизайнер, но эта идея — не ты, она сейчас не работает.

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

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

    Бить по траве, чтобы вспугнуть змею


    Когда вы получаете большой долгосрочный проект, я советую реализовывать MVP: минимальный проект со всеми фишками, проблемами, багами, который помогает адекватно оценивать сроки. Если простой MVP строить условные 2 недели, то понятно, что произойдет дальше.

    Это хороший совет и он работает везде. Сейчас я противник иного подхода, уже на этом набил себе мозоль. Пусть лучше разработчик сделает MVP и что-то конкретное по коду, чем будет работать над большим проектом как-то иначе.

    Бегство — лучшая стратагема



    Уйти от конфликта — не проигрыш.
    Как говорил Сунь-цзы, есть три варианта.

    • Пойти на компромисс. Это половинчатое решение: и выигрыш и проигрыш.
    • Признать поражение.
    • Уйти. Но это не проигрыш, а шанс вернуться и исправить.

    Не лезьте в конфликт! Лучше не воевать, а жить мирно.
    «Сто раз сразиться и сто раз победить — это не лучшее из лучшего. Лучшее из лучшего — покорить чужую армию, не сражаясь».

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

    Старайтесь меньше конфликтовать и не позволяйте собой манипулировать.

    На этой позитивной ноте, напоминаю, что заявку на доклад на следующую конференцию для тимлидов можно подать до конца недели, то есть 22 декабря. А еще через неделю мы волевым усилием из сотни (подозреваю, что к тому времени будет еще больше) заявок выберем спикеров февральской TeamLead Conf, чтобы вы перестали сомневаться в необходимости приобрести билет на конференцию.
    • +21
    • 4.7k
    • 5
    Конференции Олега Бунина (Онтико)
    251.30
    Конференции Олега Бунина
    Share post

    Comments 5

      +3

      Из всего следует важный принцип — введи всех в заблуждение, сам заблудиться всегда успеешь

        +2
        Война — это путь обмана.

        Сунь-цзы (который считается одним из авторов 36 стратагем)
          +1

          А как в итоге правильно разрулить ситуацию из "Дайте возможность сохранить лицо"?

            0
            Для начала просто думать над происходящем в этом ключе. Дальше смотреть по ситуации. Стратегически нужно отвязать человека от его идеи. То есть показать, что от того, что идея хорошая или плохая человек не становится лучше или хуже. Может перекликается с «Пожертвовать сливой, чтобы спасти персик». Например уступить в части конфликта, но зато не отступить в принципиальном. Последний тезис конечно субъективен. У вас все может быть сложнее
            +1
            Кто-то уже пошутил про 5-7 лет условно?)

            Only users with full accounts can post comments. Log in, please.