Как стать автором
Обновить
292.75
Конференции Олега Бунина (Онтико)
Профессиональные конференции для IT-разработчиков

Управление договоренностями

Время на прочтение 19 мин
Количество просмотров 7.9K
Давайте поговорим про управление договоренностями. Почему это вдруг? Да потому что, мы на TeamLead Conf любим обсуждать боли и проблемы, но и не забываем про решения. Наверняка у всех бывают проблемы, связанные с договоренностями по работе.

«Договоренности не выполняются», — капитан Очевидность

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

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

Однако, в данном случае Стас Михальский утверждает, что проблема более, чем серьёзная. Под катом будем разбираться, к чему ведет то, что договоренность не выполняется, и как, в конце концов, сделать их нерушимыми.


О спикере: Стас Михальский занимается web-разработкой с 1998 года. Прошел путь от младшего Perl-программиста до директора по разработке Biglion. Участвовал в разработке нескольких десятков проектов с высокой посещаемостью и обеспечивал их поддержку.

Почему это проблема


Бизнес и руководство от наших команд и нас, как тимлидов, ждет результат. Выполнение задачи в срок может не привести к результату, но это отдельная история.

Работа и результат — разные вещи, но об этом поговорим в другой раз.

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

Казалось бы — все понятно: когда мы не выполняем действия, мы срываем договоренности.

Рассмотрим стандартные примеры. Соблюдение стандарта code style — это договоренность с конкретным разработчиком. Не вся команда одним голосом отвечает: «Да, мудрый Каа, мы будем соблюдать code style», но каждый говорит лично, что обещает его соблюдать. Запустить релиз в пятницу или в понедельник — это тоже договоренность. Что бы мы не делали, нас кто-то об этом попросил или мы сами решили, что это надо для чего-то, если от нас ждут результат, то это выполнение действия в рамках договоренности.

— Если мы сами решили, что от нас этого ждут — это договоренность?
— Да, договоренность с самим собой, но это частный случай.

Теперь самое интересное — на самом деле все наоборот: проваленная договоренность = невыполненное действие.

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

Я хочу донести до вас мысль, что разработчики, бэкендеры, фронтендеры, тестировщики, тимлиды, руководители разработки — это все некоторые функции и роли, в рамках которых мы что-то делаем. Но если посмотреть чуть выше, то вся наша работа — это заключение договоренностей и их выполнение. Это как UDP — в договоренность завернуто все остальное. Если мы не умеем правильно заключать договоренности, то мы можем быть отличными фронтендерами или бэкендерами, писать отличный код, но результата не будет.

Наоборот — если мы научимся создавать правильные договоренности, то:

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

Что делать?


«Сделать так, чтобы договоренности выполнялись»

Капитан Очевидность

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

Классическая модель, как этого можно достичь:

  1. Понять причины.
  2. Определить и предпринять действия по устранению этих причин и изменению результата.



Поговорим чуть более детально. Есть три действующих лица:

  1. Договоренность, с которой надо разобраться.
  2. Срыв, который случается с договоренностью.
  3. Причины, по которым происходит срыв.

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

Что такое договоренность?


Договоренность состоит из двух частей: обязательство и обещание. Разница между ними в том, что обязательство берется, обещание дается.

Обещание — это субпродукт, это сообщение кому-то о том, что я взял на себя обязательство. В принципе, его можно даже не давать, так как это просто уведомительное сообщение. А вот обязательство я сем беру на себя. Поэтому обязательство без обещания намного лучше, чем обещание без обязательства. С последним мы сталкиваемся довольно часто.

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

На самом деле все еще намного сложнее, потому что договоренности бывают разные по типу:

  • В рамках непосредственных обязанностей, например, писать комментарии в коде, закончить релиз к среде.
  • За рамками основной работы, например, следить за актуальностью информации в wiki, прочитать книгу, ходить на курсы.
  • Изменить поведение, например, начать приходить на работу к определенному часу, или вести учет времени, потраченного на задачу.

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

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

Классический пример, когда раньше было неважно приходить к 10 или к 12, потому что, если что, можно задержаться и доработать, а теперь нужно быть на рабочем месте не позже 11, потому что процессы и прочее. Если человек просто соглашается: «Да, хорошо, завтра приду в 11» — это не изменение поведения, а подвиг. Если же выясняется, что для этого нужно, может быть, жизнь перестроить — ложиться чуть раньше или не играть в Warcraft, то значит, человек сам должен измениться. Это сложно, и, главное, не поддается контролю, как какой-нибудь проект.

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

Срывы


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

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

Срывы тоже бывают разные.

Провал — это мой любимый, самый честный и самый безобидный вид срыва. Мы договорились, человек пообещал и не сделал — бывает. Это простой срыв, потому что с ним все понятно.

Есть более неприятные варианты, такие как формальное выполнение.

Формальное выполнение — это когда в пятницу вечером разработчик (под пивас для вдохновения) размазывает 40 часов рабочего времени по таскам, которые сделал за неделю. В действительности человек, который с вами заключил эту договоренность, в этот момент не получает ничего. Если логирование времени нужно не для того, чтобы всех прижать к ногтю, а для того, чтобы статистически понять, сколько времени занимают разные типы задач, какая средняя ошибка и т.д., то такое его выполнение гробят всю инициативу. Никакой статистики не будет, потому что данные берутся из головы. В результате договоренность не выполнена, хотя вроде бы что-то сделано, и всё хорошо.

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

Подмена чуть-чуть отличается от формального выполнения формой, но по сути это та же попытка нарушить договоренность. Просто вместо видимости выполненного задания, создается подмена. На примере логирования времени это звучит примерно так: «Чтобы записывать время каждой задачи, мне нужно 5 мин. В сумме это два часа в неделю. Да ну его. Я вот сделал задачу, которую не собирался, за 4 часа. Я же сделал больше, чем обещал, ни и что, что не залогировал время.

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

Повторюсь: невыполненная договоренность — это работа в минус, результат в минус.

Как выживать в мире неисполняемых договоренностей?

Можно просто напоминать: «Ты помнишь, что мы логируем часы?». Если речь идет об изменении поведения, то напоминание — хорошая схема. Самые хитрые вешают плакатики, поддерживающие модель поведения: «Залогировал время — спас бобра!». По факту же мы просто напоминаем, что была договоренность, вообще не проверяя ее статус в настоящий момент.

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

Можно проверять:

  • по результату;
  • по шагам;
  • по динамике.

Проверку по результату мы уже обсуждали. Вопрос в том, что делать, если результат неудовлетворительный, но к этому вернемся позже.

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

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

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

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

Причины срыва


Наверное, это неполный список, но здесь самые яркие примеры:

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

Часто за всеми отговорками скрывается король сорванных договоренностей — саботаж. Когда мы не хотим делать и не хотим признаваться, что не хотим делать, получается саботаж. Распиывание 40 часов в неделю по задачам методом научного тыка — это саботаж. Прийти на работу в 9 утра и час пить кофе — это саботаж. В его основе лежит нежелание делать, которое не было явно высказано.

На самом деле, есть более системные причины срыва. То, что мы проговорили, лежит на поверхности, а если копнуть вглубь, то причины всего три:

  1. Не учтен тип договоренности.
  2. Не согласован тип договоренности.
  3. Обещание без обязательств.

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

— Эгей, сделай так!
— ОК, сделаю! — и разбежались.

Так можно поступать, когда мы говорим о работе в работе, например, о написании модуля: «Быстро сделай задачку 28». Но так нельзя делать, когда речь идет о подготовке к выступлению на митапе, например. По-хорошему, чтобы подготовить выступление на митапе, нужно сесть, разобраться, объяснить, как это важно и т.д. Но зачастую мы все делаем в одном ритме: «Сделай так» или «Смотри, больше не опаздывай!» — и побежали.

Бывает, что мы договариваемся, находясь в разном понимании о типе договоренности. Классический пример — документирование кода. За последние время, возможно, все изменилось, но когда я с этим сталкивался, у нас с коллегами были постоянные дебаты о том, должен ли разработчик документировать код или нет. Я, как руководитель, считаю, что должен. Разработчик, считает, что код работает, и хорошо, учитывая нагрузки и постоянно меняющиеся приоритеты.

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

Самая популярная ситуация, как я уже говорил, — обещание без обязательств. Договоренность, которая породила обещание, но не породила обязательства, не будет выполнена по тем или иным причинам: упадет рояль, человек отвлечется, случится еще что-нибудь.

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

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

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

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

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

Резюмируя, сказанное о причинах срыва договоренности:

  • Обещание не является гарантией.
  • Контроль затруднен.
  • Провал выявляется по факту.

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

Капитан Очевидность

Другими словами:

  • As Is — сейчас система выглядит так: довольно хрупкие договоренности, которыми сложно управлять.
  • To Be — должно быть: нерушимые договоренности, управление которыми прозрачно и не трудоемко.

Для стандартной ситуации GAP-анализа «To Be» — это конечная цель, к которой мы стремимся, но не факт, что дойдем. Но стремиться надо.

Осталось разобраться, что такое прочная договоренность и как её управлять.

Прочная договоренность


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

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

Цена слова


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

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

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

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

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

Осталось только разобраться, что вообще способно вовлечь человека в такую кабалу обязательства, если его еще и нарушать нельзя.

Для этого существует несколько причин, но настоящая одна — это трудовой договор: «Я обещал вам это делать, потому что вы мне за это платите деньги».

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

Желание — это главная причина. Я долго пудрил вам мозги просто для того, чтобы донести простую мысль.

Человек сделает то, что хочет, и не будет делать того, чего не хочет.

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

Уздечка для бизона


Есть простое правило из книжки «Закон малинового варенья» Дж. Вайнберга, которое мне очень нравится — уздечка для бизона. Автор пишет, что у него был друг, который разводил бизонов. Это здоровые, слабоуправляемые животные. Даже ограды не сильно помогают, чтобы куда-то их не пустить. Когда Вайнберг спросил своего друга, как он справляется с бизонами, тот ответил, что у него есть уздечка, которая состоит из двух частей:

  1. Бизона можно отвести куда угодно, если он хочет туда идти.
  2. Бизона можно куда угодно не пустить, если он не хочет туда идти.

Несмотря на то, что это практически цитата из Тони Роббинса, в этом есть смысл. Вы — не нянька — не человек, который идет за спиной своего подчиненного и контролирует каждый его шаг. По-хорошему вы должны его отпустить и дождаться результата. У вас нет и не должно быть пульта управления, но он, скорее всего, у вас есть на каждого подчиненного. Этого быть не должно, человек должен все сделать сам. Для этого он должен хотеть.

Есть еще три вещи, которые важно добавить, чтобы «уздечка» была прочной:

  • Договоренность формализована.
  • Человек вовлечен.
  • Содержание проработано.

Формализация


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

Мы должны договориться, что договоренность никогда не меняется в одностороннем порядке. Смена приоритета, пришедший Вася не может быть причиной изменения договоренности в одностороннем порядке.

Сообщить об изменении нужно моментально, чтобы возможно было пересмотреть договоренность.

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

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

— Давай, ты будешь приходить вовремя!
— Давай.

Но можно и по-другому: «Слушай, мне надо, чтобы ты приходил вовремя. Давай на этой неделе прямо по часам я буду тебя ждать на рабочем месте с чашкой вкусного капучино в 10:55. Мы будем ежедневно отмечать на доске пришел ты вовремя, или нет».

Я буду ждать человека, который должен научиться не опаздывать, с кофе за 5 минут до начала работы — это не саботаж, а взятка, но это другое. Таким образом, у нас будет: план действий, контроль и критерии оценки.

Тогда обязательство — это важно — относится к прохождению по этому плану, а не к эфемерному изменению поведения.

Как вовлекать людей?


Это самый важный вопрос, в который все упирается: как вовлечь человека? У меня есть 4 вопроса, по которым я строю свою речь, когда мне нужно о чем-то договориться:

  1. Зачем это мне?
  2. Зачем это тебе?
  3. Что будет, если сделаешь?
  4. Что будет, если не сделаешь?

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

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

На самом деле я не очень уверен, что это сработает для любого человека любого уровня. Пока что я пользуюсь этим следующим образом. Когда я прошу человека что-то сделать, то объясняю, зачем это мне, зачем это ему и что будет, если сделать и не сделать.

Ответ на вопрос «Зачем это мне» в моем понимании придает смысл всей договоренности. Если я просто прошу человека логировать время — это одно. Если я объясняю, что хочу на основе этого попытаться понять, какой тип задач дает наибольшую ошибку в оценке — это совершенно другое.

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

Подводя итог, как работать с договоренностями:

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

В начале можно составить реестр договоренностей, вплоть до таблички в Excel, чтобы ничего забыть: кто, что, содержание, срок. Но это необязательно, сейчас табличку я уже не веду.

Что делать с нарушителями?


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

Сколько нужно ждать? Сколько дать шансов? Я верю в правило трех точек — оно меня ни разу не подводило: первый раз — случайность, второй — совпадение, третий — закономерность.

Важно, что после каждой «точки» нужно поговорить с человеком, объяснить важность, нарисовать перспективы в конце концов. И интервалы между «замерами» нужно делать значительные — все-таки речь идет об изменении поведения. Но если «третья точка» случилась, то вместо вопроса «Что с этим делать?» встает вопрос «Мириться с этим или нет?»

А это уже личный выбор каждого…

А вот выбор, идти на TeamLead Conf или нет, на мой взгляд, очевиден. Тем более уже и программа почти готова. Но вы можете выбрать Москву в феврале или Питер в сентябре, и подписаться на рассылку, чтобы не пропустить новые видео и статьи, открытие Call for Papers и ключевые даты.
Теги:
Хабы:
Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку
+41
Комментарии 0
Комментарии Комментировать

Публикации

Информация

Сайт
www.ontico.ru
Дата регистрации
Дата основания
Численность
31–50 человек
Местоположение
Россия