Давайте поговорим про управление договоренностями. Почему это вдруг? Да потому что, мы на TeamLead Conf любим обсуждать боли и проблемы, но и не забываем про решения. Наверняка у всех бывают проблемы, связанные с договоренностями по работе.
«Договоренности не выполняются», — капитан Очевидность
Боль с ними, в первую очередь, в том, что договоренности не выполняются — это знают все, даже наш друг капитан Очевидность, который будет помогать нам в этой статье.
Казалось бы, в чем проблема? Много что идет не так, как хотелось бы. Например, не всегда бывают солнечные дни в Питере. Ну и что, город стоит, люди приезжают, любят его. Не всегда то, что происходит не так, как мы хотим, является по-настоящему серьезной проблемой.
Однако, в данном случае Стас Михальский утверждает, что проблема более, чем серьёзная. Под катом будем разбираться, к чему ведет то, что договоренность не выполняется, и как, в конце концов, сделать их нерушимыми.
О спикере: Стас Михальский занимается web-разработкой с 1998 года. Прошел путь от младшего Perl-программиста до директора по разработке Biglion. Участвовал в разработке нескольких десятков проектов с высокой посещаемостью и обеспечивал их поддержку.
Почему это проблема
Бизнес и руководство от наших команд и нас, как тимлидов, ждет результат. Выполнение задачи в срок может не привести к результату, но это отдельная история.
Работа и результат — разные вещи, но об этом поговорим в другой раз.
Результат является следствием работы — выполнения задач, проектов, подпроектов. Возможны разные деления, но так или иначе работа состоит из некоторых действий, каждое из которых на самом деле является следствием договоренности.
Казалось бы — все понятно: когда мы не выполняем действия, мы срываем договоренности.
Рассмотрим стандартные примеры. Соблюдение стандарта code style — это договоренность с конкретным разработчиком. Не вся команда одним голосом отвечает: «Да, мудрый Каа, мы будем соблюдать code style», но каждый говорит лично, что обещает его соблюдать. Запустить релиз в пятницу или в понедельник — это тоже договоренность. Что бы мы не делали, нас кто-то об этом попросил или мы сами решили, что это надо для чего-то, если от нас ждут результат, то это выполнение действия в рамках договоренности.
— Если мы сами решили, что от нас этого ждут — это договоренность?
— Да, договоренность с самим собой, но это частный случай.
Теперь самое интересное — на самом деле все наоборот: проваленная договоренность = невыполненное действие.
То есть не договоренность сорвана, если действие не выполнено, а невыполненное действие является следствием проваленной договоренности. Мы не сделали, потому что договорились не так, либо не очень хотели, либо что-то еще. В центре находится проблема именно с договоренностью. Таким образом мы получаем картину, в которой проваленная договоренность приводит к невыполненному действию, что, естественно, влияет на качество работы, и в итоге к отсутствию результата.
Я хочу донести до вас мысль, что разработчики, бэкендеры, фронтендеры, тестировщики, тимлиды, руководители разработки — это все некоторые функции и роли, в рамках которых мы что-то делаем. Но если посмотреть чуть выше, то вся наша работа — это заключение договоренностей и их выполнение. Это как UDP — в договоренность завернуто все остальное. Если мы не умеем правильно заключать договоренности, то мы можем быть отличными фронтендерами или бэкендерами, писать отличный код, но результата не будет.
Наоборот — если мы научимся создавать правильные договоренности, то:
- сэкономим кучу времени;
- значительно снизим оверхед на все контроли, разборки и т.д.;
- сможем заниматься по-настоящему своей работой.
Что делать?
«Сделать так, чтобы договоренности выполнялись»
Капитан Очевидность
Это понятно всем, даже капитану Очевидности, нужно всего-навсего сделать так, чтобы договоренности выполнялись, и не нужно делать так, чтобы они не выполнялись.
Классическая модель, как этого можно достичь:
- Понять причины.
- Определить и предпринять действия по устранению этих причин и изменению результата.
Поговорим чуть более детально. Есть три действующих лица:
- Договоренность, с которой надо разобраться.
- Срыв, который случается с договоренностью.
- Причины, по которым происходит срыв.
Если на все это посмотреть со всех сторон, то, наверное, можно понять, в чем проблема и как улучшить ситуацию. Я надеюсь, с тем, что ситуация требует вмешательства, все согласны.
Что такое договоренность?
Договоренность состоит из двух частей: обязательство и обещание. Разница между ними в том, что обязательство берется, обещание дается.
Обещание — это субпродукт, это сообщение кому-то о том, что я взял на себя обязательство. В принципе, его можно даже не давать, так как это просто уведомительное сообщение. А вот обязательство я сем беру на себя. Поэтому обязательство без обещания намного лучше, чем обещание без обязательства. С последним мы сталкиваемся довольно часто.
Честно говоря, мне кажется, что вся проблема в том, что далеко не все (и мы тоже) и не всегда, когда заключаем договоренности, думаем про обязательства. Не всегда мы принимаем решение осознанно и реально понимаем, чем нам грозит данное обещание. Мы просто киваем: «Да, да», уходим, а обязательство с собой не забираем — и это большая проблема.
На самом деле все еще намного сложнее, потому что договоренности бывают разные по типу:
- В рамках непосредственных обязанностей, например, писать комментарии в коде, закончить релиз к среде.
- За рамками основной работы, например, следить за актуальностью информации в wiki, прочитать книгу, ходить на курсы.
- Изменить поведение, например, начать приходить на работу к определенному часу, или вести учет времени, потраченного на задачу.
Это совершенно разные договоренности, человек к ним относится по-разному, и с ними совершенно по-разному нужно работать.
Как правило, за рамки основной работы выходят вопросы, которые в некотором смысле важнее, как мне кажется, чем текущий уровень кодирования у разработчика, потому что через них он может трансформироваться. Если человек умеет учиться — это совсем другое, чем если он просто за 10 лет научился быстро и без ошибок кодить. Иногда договориться с разработчиком, чтобы он прочел книжку, бывает намного сложнее, чем потребовать от него документирования кода. Но бывает еще веселее, когда речь идет об изменении поведения.
Классический пример, когда раньше было неважно приходить к 10 или к 12, потому что, если что, можно задержаться и доработать, а теперь нужно быть на рабочем месте не позже 11, потому что процессы и прочее. Если человек просто соглашается: «Да, хорошо, завтра приду в 11» — это не изменение поведения, а подвиг. Если же выясняется, что для этого нужно, может быть, жизнь перестроить — ложиться чуть раньше или не играть в Warcraft, то значит, человек сам должен измениться. Это сложно, и, главное, не поддается контролю, как какой-нибудь проект.
Поэтому очень важно понимать, о какой договоренности идет речь. От того, какой тип договоренности мы пытаемся заключить, зависит степень проработки.
Срывы
Мало того, что договоренности срываются, они срываются, во-первых, неожиданно, во-вторых, на финише — потому что так веселее. Хотя это неожиданно, как правило, и находится в предсказуемой точке. Я всегда знаю, когда сорвется договоренность.
Мы сейчас работаем в командах, век одиночек и гаражных компьютеров ушел. У нас есть команда, процессы, и каждая договоренность, в цепочке. Если она рушится, то рушится всё. Если человек просто не прочитал книжку, то, в принципе, у вас ничего не испортится и не сломается, но через год ваша команда вдруг не будет лучше, чем сейчас. По мне, это фейл куда больший, чем два часа отказа всех систем.
Срывы тоже бывают разные.
Провал — это мой любимый, самый честный и самый безобидный вид срыва. Мы договорились, человек пообещал и не сделал — бывает. Это простой срыв, потому что с ним все понятно.
Есть более неприятные варианты, такие как формальное выполнение.
Формальное выполнение — это когда в пятницу вечером разработчик (под пивас для вдохновения) размазывает 40 часов рабочего времени по таскам, которые сделал за неделю. В действительности человек, который с вами заключил эту договоренность, в этот момент не получает ничего. Если логирование времени нужно не для того, чтобы всех прижать к ногтю, а для того, чтобы статистически понять, сколько времени занимают разные типы задач, какая средняя ошибка и т.д., то такое его выполнение гробят всю инициативу. Никакой статистики не будет, потому что данные берутся из головы. В результате договоренность не выполнена, хотя вроде бы что-то сделано, и всё хорошо.
Проблема в том, что мы не всегда регистрируем формальное выполнение, как сорванную договоренность. Особенно, если сами не очень заинтересованы. Например, я — тимлид, мне сверху директор сказал: «Часы записывайте, а то всех накажу!». Я пришел к команде и транслирую, что надо записывать часы, иначе всех накажут. В итоге часы как-то записаны, я доволен — мне есть что показать директору. Я сам участвую в этом саботаже, и для меня важно формальное выполнение. Для поставщика задачи оно неприемлемо.
Подмена чуть-чуть отличается от формального выполнения формой, но по сути это та же попытка нарушить договоренность. Просто вместо видимости выполненного задания, создается подмена. На примере логирования времени это звучит примерно так: «Чтобы записывать время каждой задачи, мне нужно 5 мин. В сумме это два часа в неделю. Да ну его. Я вот сделал задачу, которую не собирался, за 4 часа. Я же сделал больше, чем обещал, ни и что, что не залогировал время.
Это попытка отдать вам что-то, чтобы вы отстали с проверкой, но на самом деле это тоже срыв. Проблема в том, что, как правило, у нас есть куча других дел, незалогированное время — это вроде не самое страшное. Мы сами попустительствуем.
Повторюсь: невыполненная договоренность — это работа в минус, результат в минус.
Как выживать в мире неисполняемых договоренностей?
Можно просто напоминать: «Ты помнишь, что мы логируем часы?». Если речь идет об изменении поведения, то напоминание — хорошая схема. Самые хитрые вешают плакатики, поддерживающие модель поведения: «Залогировал время — спас бобра!». По факту же мы просто напоминаем, что была договоренность, вообще не проверяя ее статус в настоящий момент.
Можно быть чуть более настойчивым и спрашивать, как выполняется договоренность, сделал ли человек уже что-нибудь. Это отличается от напоминания тем, что вынуждает дать какой-то членораздельный ответ. Но так вы ставите человека перед выбором: врать или не врать. Ответ, кстати, не для всех очевиден. В некотором смысле вы подталкиваете человека к плохому. Спрашивать — это латентный вид контроля — вроде бы спросили, но не проверили. Человек соврал, но мы оставляем это на его совести.
Можно проверять:
- по результату;
- по шагам;
- по динамике.
Проверку по результату мы уже обсуждали. Вопрос в том, что делать, если результат неудовлетворительный, но к этому вернемся позже.
По шагам и по динамике можно проверить выполнение договоренности в работе и вне работы. Например, мы уговорили человека на заполнение базы знаний, наметили с ним план и идем по этому плану — это еще куда ни шло. Но что делать с изменением поведения? Человек либо логирует время, либо не логирует; либо приходит вовремя, либо нет. Отследить эту трансформацию по шагам и динамике — сегодня опоздал на полчаса, завтра на 25 минут, послезавтра на 20 — это же смешно.
Самая большая проблема проверки в том, что это не всегда возможно. Учитывая, что договоренности заключаются все время и со многими людьми, это еще и очень трудозатратно.
Модель менеджмента, в которой практически все время руководителя уходит на контроль исполнения задач, существует, но плохо работает в IT. Да и прошлый век это. Я надеюсь, что такой подход к управлению однажды умрет, как последний динозавр.
Вместо того, чтобы контролировать, давайте лучше разберемся, почему на самом деле происходит срыв — почему человек, который дал нам обещание, его не выполнил.
Причины срыва
Наверное, это неполный список, но здесь самые яркие примеры:
- Необдуманное согласие. Человек соглашается, потому что отказывать неловко: вы его руководитель или просто уважаемый человек, либо он искренне хочет вам помочь, вы ему нравитесь, либо он вообще не любит отказывать.
- Ошибка в оценке. Человек может подумать, согласиться, но ошибиться в оценке. Тогда он придет и скажет: «Да, я обещал, но работы оказалось в два раза больше, чем я предполагал».
- Смена приоритетов: «Я почти закончил, но потом пришел Вася, у него проблема еще более важная, поэтому извини».
- Нехватка ресурса — просто не хватило времени.
- Непредвиденные обстоятельства — сверху упал рояль.
- Саботаж.
Часто за всеми отговорками скрывается король сорванных договоренностей — саботаж. Когда мы не хотим делать и не хотим признаваться, что не хотим делать, получается саботаж. Распиывание 40 часов в неделю по задачам методом научного тыка — это саботаж. Прийти на работу в 9 утра и час пить кофе — это саботаж. В его основе лежит нежелание делать, которое не было явно высказано.
На самом деле, есть более системные причины срыва. То, что мы проговорили, лежит на поверхности, а если копнуть вглубь, то причины всего три:
- Не учтен тип договоренности.
- Не согласован тип договоренности.
- Обещание без обязательств.
Причем первый и второй пункт могут присутствовать оба сразу. Когда мы заключаем договоренность, мы не думаем про то, о чем мы договариваемся. Часто это звучит так:
— Эгей, сделай так!
— ОК, сделаю! — и разбежались.
Так можно поступать, когда мы говорим о работе в работе, например, о написании модуля: «Быстро сделай задачку 28». Но так нельзя делать, когда речь идет о подготовке к выступлению на митапе, например. По-хорошему, чтобы подготовить выступление на митапе, нужно сесть, разобраться, объяснить, как это важно и т.д. Но зачастую мы все делаем в одном ритме: «Сделай так» или «Смотри, больше не опаздывай!» — и побежали.
Бывает, что мы договариваемся, находясь в разном понимании о типе договоренности. Классический пример — документирование кода. За последние время, возможно, все изменилось, но когда я с этим сталкивался, у нас с коллегами были постоянные дебаты о том, должен ли разработчик документировать код или нет. Я, как руководитель, считаю, что должен. Разработчик, считает, что код работает, и хорошо, учитывая нагрузки и постоянно меняющиеся приоритеты.
Конфликт понимания типа договоренности не всегда вскрывается. Мы часто считаем, что эту договорённость не надо никак разъяснять, подкреплять, потому что и так все понятно: просто возьми и сделай. Подчиненный считает, что от него хотят сверху то, чего он делать не хочет. И тогда начинается саботаж.
Самая популярная ситуация, как я уже говорил, — обещание без обязательств. Договоренность, которая породила обещание, но не породила обязательства, не будет выполнена по тем или иным причинам: упадет рояль, человек отвлечется, случится еще что-нибудь.
На самом деле в условиях сложности систем, интенсивности изменений: когда все второпях пишем код, быстро выкатываем, переделываем, — другими словами, в условиях энтропии всегда может случиться что-то, что помешает выполнить договоренность. Конечно, можно контролировать каждый шаг, впрягаться в каждый кейс каждого своего подчиненного, пытаться ему помочь прийти к выполнению нашей договоренности. Но тогда не хватит времени ни на что больше, кроме как своими силами тащить все на себе.
Единственный шанс на то, что договоренность будет выполнена в том, что человек захочет ее выполнить.
Если у меня есть желание выполнить договоренность, я разберусь со всеми вылетающими проблемами: с падающими роялями, с тем, что я ошибся в оценке и т.д.
Это похоже на идеологию Scrum, точно также до конца неизвестна сложность задачи. Мы делаем некоторое предположение с погрешностью на предыдущий опыт, оцениваем, а дальше просто делаем все, чтобы закрыть спринт. Мы признаем, что да, будет сложно, что мы могли где-то ошибиться в оценке, что система может нас удивить, но мы просто будем делать так, чтобы решить задачу.
С договоренностью должно происходить то же самое, что и со спринтами в Scrum. Человек, который взял на себя обязательство что-то сделать, просто должен сделать это. Все просто!
Резюмируя, сказанное о причинах срыва договоренности:
- Обещание не является гарантией.
- Контроль затруднен.
- Провал выявляется по факту.
Понятно, что нужно делать: просто создавать прочные договоренности, которыми легко управлять, и поехать наконец-таки на Багамы.
Капитан Очевидность
Другими словами:
- As Is — сейчас система выглядит так: довольно хрупкие договоренности, которыми сложно управлять.
- To Be — должно быть: нерушимые договоренности, управление которыми прозрачно и не трудоемко.
Для стандартной ситуации GAP-анализа «To Be» — это конечная цель, к которой мы стремимся, но не факт, что дойдем. Но стремиться надо.
Осталось разобраться, что такое прочная договоренность и как её управлять.
Прочная договоренность
Прочная договоренность — это настоящие обязательства, которые заключены с обязательным человеком. Это очень важно. Мы говорили про обязательства, как про некоторый пакет, который надо передать, а теперь мы поговорим чуть-чуть про носителя этого пакета.
Договоренности, заключенные с необязательным человеком ведут к несоответствиям. Если представить работу в виде потока договоренностей, которые рассылаются в разные стороны пакетами, то, когда вы пытаетесь заключать договоренность с необязательным человеком, будьте готовы к тому, что с вероятность 50% вы потеряете время. Поэтому первое, с чего надо начать, это повышать цену слова.
Цена слова
Каждый ваш коллега в идеале должен понимать, что обслуживание обязательств — это его основная работа. Это суть его работы. Написанный код, выкаченный релиз — это производные от выполненных обязательств. Поэтому я стараюсь разговаривать с людьми именно об обязательствах и о том, что проблема не в том, что код не написан или результата нет. Это следствие и большая боль. Но суть проблемы в том, что, взяв на себя обязательство, мы не нашли способа его выполнить.
Если вы никогда об этом с людьми не говорили, то это, в общем и целом, не так очевидно. Подозреваю, что для того, чтобы об этом поговорить, может быть, нужно сначала пробежать лесенку из начала доклада «результат — работа — действие — договоренность» и обратно. Но людям нужно донести мысль про ядерность договоренности и обязательства, про то, что договоренность — это обязательство, а обязательство, если оно взято, практически нерушимо.
Самое смешное, что если у вас получится это донести, будьте готовы к снижению количества договоренностей. Вам будут намного реже что-либо обещать. Вы старались, чтобы договоренности работали, а в итоге вместо 10 обещаний у вас останется только 3. Правда, хорошая новость — они практически нерушимые.
Повышая вероятность выполнения каждого обязательства, мы снижаем их количество.
Это естественно, потому что люди могут не справляться и по объективным причинам — все сделать невозможно. Снижение количества обязательств — это нормально, но зато они будут действительно крепкими.
Осталось только разобраться, что вообще способно вовлечь человека в такую кабалу обязательства, если его еще и нарушать нельзя.
Для этого существует несколько причин, но настоящая одна — это трудовой договор: «Я обещал вам это делать, потому что вы мне за это платите деньги».
Возможность — это обязательное условие, но не гарантия. Если человек не может выполнить обязательство, он его не выполнит — совершенно очевидно. Это критерий, за которым надо следить.
Желание — это главная причина. Я долго пудрил вам просто для того, чтобы донести простую мысль.
Человек сделает то, что хочет, и не будет делать того, чего не хочет.
Наша задача, если мы хотим по-настоящему создавать прочные договоренности — вовлечь человека в выполнение каждой из них.
Уздечка для бизона
Есть простое правило из книжки «Закон малинового варенья» Дж. Вайнберга, которое мне очень нравится — уздечка для бизона. Автор пишет, что у него был друг, который разводил бизонов. Это здоровые, слабоуправляемые животные. Даже ограды не сильно помогают, чтобы куда-то их не пустить. Когда Вайнберг спросил своего друга, как он справляется с бизонами, тот ответил, что у него есть уздечка, которая состоит из двух частей:
- Бизона можно отвести куда угодно, если он хочет туда идти.
- Бизона можно куда угодно не пустить, если он не хочет туда идти.
Несмотря на то, что это практически цитата из Тони Роббинса, в этом есть смысл. Вы — не нянька — не человек, который идет за спиной своего подчиненного и контролирует каждый его шаг. По-хорошему вы должны его отпустить и дождаться результата. У вас нет и не должно быть пульта управления, но он, скорее всего, у вас есть на каждого подчиненного. Этого быть не должно, человек должен все сделать сам. Для этого он должен хотеть.
Есть еще три вещи, которые важно добавить, чтобы «уздечка» была прочной:
- Договоренность формализована.
- Человек вовлечен.
- Содержание проработано.
Формализация
Формализация — это протокол, по которому мы договариваемся и который нужно настроить один раз, убедиться, что работает, и просто проверять, что от него не отходят.
Мы должны договориться, что договоренность никогда не меняется в одностороннем порядке. Смена приоритета, пришедший Вася не может быть причиной изменения договоренности в одностороннем порядке.
Сообщить об изменении нужно моментально, чтобы возможно было пересмотреть договоренность.
С возможностью пересмотра связан тонкий момент. Я считаю, что договоренности можно пересматривать, хотя это может оказаться лазейкой: человек взял обязательство, а потом говорит, что не справляется и просит перенести срок. На самом деле человек вовлеченный не будет использовать эту лазейку, но, с другой стороны, у него будет свобода действия и понимание, что он не загнан в угол. Человеку нужна гибкость, потому что единственный шанс выполнить обязательство — это в момент, когда возникает какая-то проблема, найти правильное решение. Исполнение обязательств в нестабильном мире — это всегда лавирование.
Конечно, у обязательства должно быть содержание и срок выполнения. Содержание — это ожидаемый, «осязаемый» результат. Например, в случае изменения поведения — это проработанный процесс. По-хорошему договоренность на изменение поведения должна заключаться не на смену поведения, а на прохождение некоторого процесса его изменения. Это может выглядеть так:
— Давай, ты будешь приходить вовремя!
— Давай.
Но можно и по-другому: «Слушай, мне надо, чтобы ты приходил вовремя. Давай на этой неделе прямо по часам я буду тебя ждать на рабочем месте с чашкой вкусного капучино в 10:55. Мы будем ежедневно отмечать на доске пришел ты вовремя, или нет».
Я буду ждать человека, который должен научиться не опаздывать, с кофе за 5 минут до начала работы — это не саботаж, а взятка, но это другое. Таким образом, у нас будет: план действий, контроль и критерии оценки.
Тогда обязательство — это важно — относится к прохождению по этому плану, а не к эфемерному изменению поведения.
Как вовлекать людей?
Это самый важный вопрос, в который все упирается: как вовлечь человека? У меня есть 4 вопроса, по которым я строю свою речь, когда мне нужно о чем-то договориться:
- Зачем это мне?
- Зачем это тебе?
- Что будет, если сделаешь?
- Что будет, если не сделаешь?
Вопросы могут идти в разной последовательности. Как правило, я по ним пробегаюсь заранее. Главное, что в рамках своего выступления перед человеком я готов ответить на все четыре из них.
Перед конференцией в рамках тематического коучинга Александр Зиза мне подставил подножку и сказал: «Знаешь, по-хорошему не тебе нужно отвечать на эти вопросы людям, они должны сами себе на них ответить, а ты просто придумай, как это поспособствовать!» Звучит, как тема следующего доклада, я пока не придумал, как это сделать.
На самом деле я не очень уверен, что это сработает для любого человека любого уровня. Пока что я пользуюсь этим следующим образом. Когда я прошу человека что-то сделать, то объясняю, зачем это мне, зачем это ему и что будет, если сделать и не сделать.
Ответ на вопрос «Зачем это мне» в моем понимании придает смысл всей договоренности. Если я просто прошу человека логировать время — это одно. Если я объясняю, что хочу на основе этого попытаться понять, какой тип задач дает наибольшую ошибку в оценке — это совершенно другое.
Ответ на вопрос «Зачем это тебе» вообще иногда перестраивает всю договоренность, потому что это должно быть зачем-то нужно человеку, с которым мы договариваемся. Если он не понимает, зачем это ему, то бизон никуда не пойдет — уздечка не работает. Иногда мне приходится переформулировать задачу так, чтобы она была тоже выгодна человеку. Это можно представить как манипуляцию или продажу, но на самом деле это просто повод задуматься о том, как сделать договоренность обоюдовыгодной.
Подводя итог, как работать с договоренностями:
- Вовлекаем исполнителя.
- Прорабатываем с ним содержание.
- При каждой возможности доносим, что суть работы на самом деле относится к выполнению обязательств, и ядерное качество для сотрудника — это обязательность, то есть умение обслуживать обязательства.
- Культивируем «цену слова» на всех углах. Пусть лучше обязательств будет меньше, но они будут прочными.
В начале можно составить реестр договоренностей, вплоть до таблички в Excel, чтобы ничего забыть: кто, что, содержание, срок. Но это необязательно, сейчас табличку я уже не веду.
Что делать с нарушителями?
Важно помнить, что срыв договоренности является просто следствием, а нарушение заключается в том, что человек не пересмотрел свое отношение к обязательствам и их значимости. А это значит что он не смог измениться, пока…
Сколько нужно ждать? Сколько дать шансов? Я верю в правило трех точек — оно меня ни разу не подводило: первый раз — случайность, второй — совпадение, третий — закономерность.
Важно, что после каждой «точки» нужно поговорить с человеком, объяснить важность, нарисовать перспективы в конце концов. И интервалы между «замерами» нужно делать значительные — все-таки речь идет об изменении поведения. Но если «третья точка» случилась, то вместо вопроса «Что с этим делать?» встает вопрос «Мириться с этим или нет?»
А это уже личный выбор каждого…
А вот выбор, идти на TeamLead Conf или нет, на мой взгляд, очевиден. Тем более уже и программа почти готова. Но вы можете выбрать Москву в феврале или Питер в сентябре, и подписаться на рассылку, чтобы не пропустить новые видео и статьи, открытие Call for Papers и ключевые даты.
Автор: romas1982
