Давайте поговорим про управление договоренностями. Почему это вдруг? Да потому что, мы на TeamLead Conf любим обсуждать боли и проблемы, но и не забываем про решения. Наверняка у всех бывают проблемы, связанные с договоренностями по работе.
«Договоренности не выполняются», — капитан Очевидность
Боль с ними, в первую очередь, в том, что договоренности не выполняются — это знают все, даже наш друг капитан Очевидность, который будет помогать нам в этой статье.
Много что идет не так, как хотелось бы. Казалось бы, в чем проблема? Ну и что, город стоит, люди приезжают, любят его. Например, не всегда бывают солнечные дни в Питере. Не всегда то, что происходит не так, как мы хотим, является по-настоящему серьезной проблемой.
Под катом будем разбираться, к чему ведет то, что договоренность не выполняется, и как, в конце концов, сделать их нерушимыми. Однако, в данном случае Стас Михальский утверждает, что проблема более, чем серьёзная.
О спикере: Стас Михальский занимается web-разработкой с 1998 года. Прошел путь от младшего Perl-программиста до директора по разработке Biglion. Участвовал в разработке нескольких десятков проектов с высокой посещаемостью и обеспечивал их поддержку.
Почему это проблема
Бизнес и руководство от наших команд и нас, как тимлидов, ждет результат. Выполнение задачи в срок может не привести к результату, но это отдельная история.
Работа и результат — разные вещи, но об этом поговорим в другой раз.
Результат является следствием работы — выполнения задач, проектов, подпроектов. Возможны разные деления, но так или иначе работа состоит из некоторых действий, каждое из которых на самом деле является следствием договоренности.
Казалось бы — все понятно: когда мы не выполняем действия, мы срываем договоренности.
Соблюдение стандарта code style — это договоренность с конкретным разработчиком. Рассмотрим стандартные примеры. Запустить релиз в пятницу или в понедельник — это тоже договоренность. Не вся команда одним голосом отвечает: «Да, мудрый Каа, мы будем соблюдать code style», но каждый говорит лично, что обещает его соблюдать. Что бы мы не делали, нас кто-то об этом попросил или мы сами решили, что это надо для чего-то, если от нас ждут результат, то это выполнение действия в рамках договоренности.
— Если мы сами решили, что от нас этого ждут — это договоренность?
— Да, договоренность с самим собой, но это частный случай.
Теперь самое интересное — на самом деле все наоборот: проваленная договоренность = невыполненное действие.
То есть не договоренность сорвана, если действие не выполнено, а невыполненное действие является следствием проваленной договоренности. Мы не сделали, потому что договорились не так, либо не очень хотели, либо что-то еще. В центре находится проблема именно с договоренностью. Таким образом мы получаем картину, в которой проваленная договоренность приводит к невыполненному действию, что, естественно, влияет на качество работы, и в итоге к отсутствию результата.
Но если посмотреть чуть выше, то вся наша работа — это заключение договоренностей и их выполнение. Я хочу донести до вас мысль, что разработчики, бэкендеры, фронтендеры, тестировщики, тимлиды, руководители разработки — это все некоторые функции и роли, в рамках которых мы что-то делаем. Если мы не умеем правильно заключать договоренности, то мы можем быть отличными фронтендерами или бэкендерами, писать отличный код, но результата не будет. Это как UDP — в договоренность завернуто все остальное.
Наоборот — если мы научимся создавать правильные договоренности, то:
- сэкономим кучу времени;
- значительно снизим оверхед на все контроли, разборки и т.д.;
- сможем заниматься по-настоящему своей работой.
Что делать?
«Сделать так, чтобы договоренности выполнялись»
Капитан Очевидность
Это понятно всем, даже капитану Очевидности, нужно всего-навсего сделать так, чтобы договоренности выполнялись, и не нужно делать так, чтобы они не выполнялись.
Классическая модель, как этого можно достичь:
- Понять причины.
- Определить и предпринять действия по устранению этих причин и изменению результата.
Есть три действующих лица: Поговорим чуть более детально.
- Договоренность, с которой надо разобраться.
- Срыв, который случается с договоренностью.
- Причины, по которым происходит срыв.
Если на все это посмотреть со всех сторон, то, наверное, можно понять, в чем проблема и как улучшить ситуацию. Я надеюсь, с тем, что ситуация требует вмешательства, все согласны.
Что такое договоренность?
Договоренность состоит из двух частей: обязательство и обещание. Разница между ними в том, что обязательство берется, обещание дается.
В принципе, его можно даже не давать, так как это просто уведомительное сообщение. Обещание — это субпродукт, это сообщение кому-то о том, что я взял на себя обязательство. Поэтому обязательство без обещания намного лучше, чем обещание без обязательства. А вот обязательство я сем беру на себя. С последним мы сталкиваемся довольно часто.
Не всегда мы принимаем решение осознанно и реально понимаем, чем нам грозит данное обещание. Честно говоря, мне кажется, что вся проблема в том, что далеко не все (и мы тоже) и не всегда, когда заключаем договоренности, думаем про обязательства. Мы просто киваем: «Да, да», уходим, а обязательство с собой не забираем — и это большая проблема.
На самом деле все еще намного сложнее, потому что договоренности бывают разные по типу:
- В рамках непосредственных обязанностей, например, писать комментарии в коде, закончить релиз к среде.
- За рамками основной работы, например, следить за актуальностью информации в wiki, прочитать книгу, ходить на курсы.
- Изменить поведение, например, начать приходить на работу к определенному часу, или вести учет времени, потраченного на задачу.
Это совершенно разные договоренности, человек к ним относится по-разному, и с ними совершенно по-разному нужно работать.
Если человек умеет учиться — это совсем другое, чем если он просто за 10 лет научился быстро и без ошибок кодить. Как правило, за рамки основной работы выходят вопросы, которые в некотором смысле важнее, как мне кажется, чем текущий уровень кодирования у разработчика, потому что через них он может трансформироваться. Но бывает еще веселее, когда речь идет об изменении поведения. Иногда договориться с разработчиком, чтобы он прочел книжку, бывает намного сложнее, чем потребовать от него документирования кода.
Если человек просто соглашается: «Да, хорошо, завтра приду в 11» — это не изменение поведения, а подвиг. Классический пример, когда раньше было неважно приходить к 10 или к 12, потому что, если что, можно задержаться и доработать, а теперь нужно быть на рабочем месте не позже 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 и ключевые даты.
