Наша повседневная работа часто похожа на череду противостояний. Мы «воюем» с заказчиками и другими командами, с тестировщиками и коллегами, а отделы внутри компании соперничают друг с другом. Мы боремся за зарплату, принятие удобных технических решений, сроки и тысячи других вещей. В этой череде конфликтов тимлид — это лидер небольшой боевой единицы, команды. Он знает слабые и сильные стороны каждого «рядового», координирует и организует их работу, чтобы достичь целей с минимальными потерями.
Если смотреть на работу тимлида с этой точки зрения, то важно стратегическое планирование и позиционная работа внутри команды и за ее пределами. При этом не стоит забывать и о тактике. Неожиданно, но планировать стратегию и реагировать тактически помогает знание древнекитайских стратагем.
Алексей Золотых (zolotyh) — тимлид в Infobip. Алексей использует в своей работе правила ведения войны древнего Китая. Из статьи на основе его доклада на Saint TeamLead 2019, вы узнаете, как стратагемы помогают в жизни тимлида: как помириться с разработчиком внутри команды, как завоевать авторитет среди коллег, как отстоять свое мнение, зачем жертвовать сливой, ругать акацию, прикидываться безумным и бить по траве.
Но возникает вопрос — мы же тимлиды, причем здесь война? Мы не воюем, ни с кем не деремся и не захватываем, зачем нам стратагемы?
В книге Рея Далио «Принципы» есть важная мысль: любая компания или команда это система сдержек и противовесов. Компания — это замороженные конфликты и конфронтации.
Объясню на примере. В компании «Абстракт» работает два отдела: тестировщиков (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 для презентаций. Как ни странно, он проходит по средам, потому что в пятницу загружать коллег чем-то новым не очень хорошо.
Если человек ответственен, замотивирован и уверен, что прав, то, скорее всего, доведет проект до конца. Но если он просто хочет поговорить и поспорить, то даже смотреть в эту сторону не будет: придется с кем-то коммуницировать, искать, готовить презентацию, поработать дополнительно.
Так я убиваю двух зайцев:
Этот лайфхак мне подсказал хороший друг. Представьте, что вам приходит pull request и нужно провести ревью, найти какие-то ошибки. Вы понимаете, что в этом pull request корень зла сидит глубоко: разработчик абсолютно не понимает, что он делает, поэтому все пишет неправильно, и вы об этом сообщаете. Разработчик не согласен (ожидаемо), приходит к вам и говорит: «Слушай, мне лень писать, давай обсудим так».
Не соглашайтесь на это! Если к вам приходят поговорить, то «поговорить» — это бесплатно. Можно говорить час, и вам это ничего не стоит. У нас вся переписка ведется на английском языке, а когда приходится отвечать, то иногда быстрее переделать, чем лезть в Google Translate. Споров становится меньше: человек уже утомлен, ему не интересно бороться.
Бывают ситуации, когда можно отдать что-то небольшое взамен главного. Поэтому, перед началом переговоров важно понять, что для нас главное, а что второстепенное.
В Infobip есть два условных мнения: одни говорят, что Scrum и Agile — это круто, а другие предлагают писать больше кода и меньше болтать. На совещаниях вторая позиция выражается в том, что человек берет с собой ноутбук и утыкается в него — от него ничего не добьешься.
В этом случае мы общаемся с сотрудником:
— Давай поступим так: можешь вообще не приходить на Scrum-митинг, но обязан знать результаты. Но если все-таки пришел, убирай ноутбук и работай с нами.
Человек понимает, что если он пропустит встречу, то придется наверстывать, а его мнение никто не узнает. Я пожертвовал присутствием сотрудника, а это бьет по самолюбию и в итоге он все равно приходит. Проблема решена.
У Григория Бакунова есть хороший доклад, в котором он высказал мысль, что любой разработчик находится в творческом процессе свойственном детям от 5 до 7. По его словам, любому разработчику от 5 до 7 лет (условно), и с ним нужно разговаривать как с ребенком.
У меня есть сын, ему почти полтора года. Я читаю специализированные книги о воспитании и уходе за детьми. В одной из книг я узнал, как «обмануть» маленького человечка, чтобы он ел кашку: рассказать сказку о том, что есть желудок, и он чувствует себя плохо, когда ротик не дает ему кашку, и все это на примере какого-нибудь мальчика.
Как это применить на разработчиках? Раньше, когда хотел дать кому-то фидбэк, то говорил это напрямую:
— Олег, ты здесь и здесь не прав. Чтобы завтра все было лучше, делай так и так.
В большинстве случаев это подрывает самооценку: человек оправдывается и говорит, почему прав или почему не мог поступить иначе. Теперь я захожу с другой стороны:
— Представь, что ты тимлид и у тебя есть такая ситуация. Что будешь делать?
Я ставлю его на свое место и спрашиваю, что бы он сделал в этой ситуации. Самолюбие разработчика в порядке, а он вживается в роль тимлида и сам ищет пути решения проблемы.
Прикидываться дураком мой любимый лайфхак. Принцип простой: если у вас есть технический вопрос, спросите. Не знаю как вы, но я не самый умный человек в команде и прекрасно это осознаю.
— Я в ваших технических штуках не понимаю, объясните русским языком.
Или:
— Это приведет к запутыванию кода. А чем это нам грозит? Почему? Как?
У CTO таких как я еще 30 человек. Единственный способ понимать, что происходит — расспрашивать снова и снова.
Когда на ваш «глупый» вопрос человек отвечает простыми словами, то вы понимаете, где в его логике пробелы. В это время вы задаете уточняющие вопросы и находите, где что-то идет не так: недосказанность между аргументами, потенциальные проблемы, которые могут потом выстрелить. Поэтому не бойтесь задавать глупые вопросы.
Если вам кажется, что так вы потеряете свой «авторитет» и «профессиональное лицо», то вспомните Ричарда Фейнмана. Это лауреат Нобелевской премии, соавтор теории квантовой электродинамики, один из разработчиков атомной бомбы, художник и взломщик сейфов. В 60-х Фейнман вел свои лекции в Caltech, которые позже выпустили в виде трех томов «Фейнмановских лекций по физике». До сих пор это одно из самых понятных и популярных объяснений физических явлений от механики до квантовой физики.
По регалиям кажется, что это солидный и серьезный человек. Но все наоборот, он как раз не боялся выглядеть несуразно. Одна из особенностей Фейнмана — живой ум и самоирония. Он постоянно задавал глупые вопросы, не пытался выглядеть «несолидно» и стремился объяснять сложные вещи простыми словами. Одна из его цитат: «Если вы квантовый физик и не можете в двух словах объяснить пятилетнему ребенку чем вы занимаетесь, вы шарлатан».
Я столкнулся в команде с проблемой: есть большая фича, которая займет неопределенное количество времени. Меня постоянно спрашивают менеджеры, когда фича будет закончена, а разработчики не знают «когда», потому что не могут определить требования. В какой-то момент я сказал:
— Стоп! Что нужно, чтобы понять сроки?
— Это, это и то.
— Тогда проведем митинг 1 октября. Давайте к этому времени поймем, успеваем мы или нет.
— Но как же? Может ураган начаться, не прийти автобус, кто-то заболеет – как мы это все учтем?
— Ага, и Годзилла нападет… Давайте упростим задачу: решим, что мы ничего не найдем, а если найдем, то просто об этом скажем руководству. Но к 1 октября это должно быть сделано.
Самое важное, я спросил у каждого, согласен ли он с датой 1 октября. Если не согласен, то предлагал придумать другую дату, обосновать и сказать об этом наверх. Кратко стратагема описывается одной фразой.
Я пришел тимлидом в уже сложившуюся команду. Естественно, первое, что я решил сделать — это «продать» свой авторитет.
На одном из код-ревью я сильно поспорил с одним разработчиком об архитектуре. Я решил разобраться кто прав, а кто нет: спросил у всех лидеров индустрии объективное мнение о коде, о котором мы спорили. Все, у кого я интересовался оценкой, подтвердили, что я был прав.
Все эти результаты я выложил своему «сопернику» в надежде, что он осознает свою ошибку, и все уляжется. Но все вышло иначе. Мой оппонент понял, что теряет авторитет. Теперь его не интересует продукт и все равно, кто прав, а кто нет — важно сохранить лицо. После этого каждое мое решение встречало резкий отпор. Разработчик не думал о проекте, он думал о том, как показать, что он умнее. Все закончилось болезненным переводом человека в другую команду (увольнением). Я был прав, но не дал человеку сохранить лицо. До сих пор жалею об этом.
Еще один забавный пример услышал в лекции Людвига Быстроновского, арт-директора студии Лебедева. Представьте дизайнера, который предлагает сделать сайт как помидор. Непонятно, как это будет выглядеть, а главное зачем? Но дизайнеру нравится и он продвигает свою «идею» только потому, что он ее придумал.
С такими идеями, конечно, соглашаться не стоит. Возвращайте человека на землю:
— Я понимаю, что ты отличный дизайнер, но эта идея — не ты, она сейчас не работает.
Это тот же принцип сохранения лица, но в том случае, когда человек ассоциирует свое решение с собой. Это тоже нужно учитывать и с этим работать.
К сожалению, подобное бывает не только в творческой среде. Я встречал случаи, когда разработчики ассоциировали себя с GraphQL или с MongoDB, например. Старайтесь разделять идеи и человека, я на этом уже обжегся.
Когда вы получаете большой долгосрочный проект, я советую реализовывать MVP: минимальный проект со всеми фишками, проблемами, багами, который помогает адекватно оценивать сроки. Если простой MVP строить условные 2 недели, то понятно, что произойдет дальше.
Это хороший совет и он работает везде. Сейчас я противник иного подхода, уже на этом набил себе мозоль. Пусть лучше разработчик сделает MVP и что-то конкретное по коду, чем будет работать над большим проектом как-то иначе.
Не лезьте в конфликт! Лучше не воевать, а жить мирно.
Старайтесь меньше конфликтовать и не позволяйте собой манипулировать.
Если смотреть на работу тимлида с этой точки зрения, то важно стратегическое планирование и позиционная работа внутри команды и за ее пределами. При этом не стоит забывать и о тактике. Неожиданно, но планировать стратегию и реагировать тактически помогает знание древнекитайских стратагем.
Алексей Золотых (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, чтобы вы перестали сомневаться в необходимости приобрести билет на конференцию.
