Все мы умные задним умом , и ,конечно, мудрость тех или иных книжек чувствуется только после того как несколько раз выхватишь пиздюлей именно таким образом, который в книжке описан. Такое вот выхватывание побуждает тебя к прочтению большего числа книг, дабы снизить интенсивность выхватывания, но - сюрприз, сюрприз - ты все равно будешь отхватывать.
Но так как ты не один, и вокруг тебя иногда (а лучше всегда) есть молодое подрастающее поколение специалистов, то вот именно их ты можешь уберечь от типовых сортов пиздюлей. Если дашь вовремя прочитать нужную книжку и проверишь что они не только ее прочитали , но и начали что-то по ней делать.
P3.express - это сублимат практик по управлению проектами, который лучше использовать, чем не использовать, особенно тем кто менеджит проект в первый раз.
Отдельно не могу не подчеркнуть что на свои 45 страниц текста - мудрости там намного больше и подача намного лучше чем в pmbok.
Для того чтобы объяснять людям понятными словами что происходит когда вы будете им вводить в организации Engineering Ladder.
Как человек, который видел внедрение engineering ladders в нескольких организациях и в паре организаций внедрял это сам, я читал вот эту статью про офигительные приключения Netflix и периодически у меня сводило лицо.
Ситуация внутри Netflix не является какой-то особенной - она типична. Фундаментальной основой проблематики внедрения карьерных лестниц внутри организаций является человеческая же природа. В природе нет никаких карьерных лестниц (что не означает что нет иерархии), но и коллективов сходных с размерами современных IT организаций тоже нет. Тут конечно можно вспомнить про стаи саранчи, но сложность и разнообразность поведения качественно иные.
Когда у тебя есть плоская структура где каждый каждому брат и вообще Senior Software Engineer - это очень хорошо вкатывается в голову человека за счет биологии.
И именно с этим моментом конфликтует внедрение карьерных лестниц - вам нужно четко понимать что вы придете в плоский неструктурированный коллектив и скажете что кто-то теперь выше, а кто-то ниже на этой самой лестнице.
Этот момент неизбежен, к нему нужно готовится, и несмотря даже на самую тщательную подготовку вы можете выхватить нежелательных последствий.
Второй момент которому достаточно часто уделяется мало внимания на старте - это процесс перехода по карьерной лестнице. Его также придется разработать и внедрить, и объяснить всем. Лучше даже показать на примере пару тройки растущих людей. Самый частый вопрос- "а судьи кто ?" - кто конкретно принимает решение о том переходит человек на ступеньку выше или нет ?
Третье - размер. На примере Netflix - 2000 инженеров - это уже очень поздно. Даже если у вас есть аналитическая оценка того сколько человек могут встать и выйти из организации и пусть она условно 5% - то простая арифметика говорит что 5% от 2000 и 5% от 500 человек - это разный уровень потерь. И внедрение карьерной лестнице - это стратегический вопрос, тесно связанный с ростом организации.
Честно ожидания от книги не оправдались чуть более, чем полностью. Основополагающий принцип Грэма о покупке акций компаний которые недооценены - это конечно хорошо, но ... И тут вот списком из трех пунктов не отделаться. Дело в том что реальность, описанная Грэмом - еще более старая, чем реальность описанная Линчем, которого я тоже критиковал. Обе из тех реальностей - они реальности настоящих работников Wall Street, для которых копание в отчетности компаний - суть и базис ежедневной работы. С моментов написания книг мир изменился - инвестирование уже не есть удел среднего класса, банковские депозиты сходят на нет, фондовые рынки глобальны и что более важно - на них приходят обычные люди, которые не склонны заниматься фундаментальным анализом и именно поэтому махрово цветут фонды (ETF). И это цветение если не суть завтрашнего фондового рынка, то точно серьезная угроза сегодняшнему его состоянию - частное мнение на этот счет можно почитать тут.
Книжка точно избыточна по объему, хотя хорошо переведена и структурирована.
Долго мучал и наконец домучал. 256 страниц А4, с тонной воды, где есть концентрированного смысла на 1 пост в бложике (читай 5-6 листов).
Квантифицирование результатов, характеризующее достижение цели - это конечно хорошо, ибо выносит из дискуссии конфликт субъективных "все сделал" и "чот кажется не сделал", однако к описанной в книге (да и не только в книге) системе есть несколько претензий: 1. в один голос все адепты OKR говорят двухнедельных интеграциях на стыке кварталов по подведению итогов и постановке новых - выглядит жирновато. Если раз в квартал нужно две недели на постановку целей и подведение итогов, то на годовой OKR видимо потребуется со всеми ритуалами и выравниванием целей - месяц.
2. инструментарий. Это все можно вести в одном excel-файле, но кажется что если перевалить за сотню OKR (будь то подразделения или люди) при 3-5 О (целях) по 3-5 KR на каждую - вы замучаетесь листать тот excel. Первое что приходит в голову - довольной умный гибрид MindMap в смеси с excel.
3. кому все это надо/подходит. Пересмотр и постановка (возможно новых) целей каждые три месяца подходят компаниям , для которых в рамках этих 3 месяцев могут произойти значимые изменения окружающей среды на которые необходимо среагировать. С точки зрения рядового сотрудника/инженера - что обычное планирование (Management by Objectives) что OKR - все одно.
Еще одна мысль:если вы Гугл и нанимаете ну очень умных людей, которых не знаете/не умеет/не можете контролироать и пусть они себе там делают что хотят лишь бы бизнес делали а все фреймворки изобретаемые в процессе - ну это ок, уже заложено в стоимость и не повлияет на прибыль - да, кажется что OKR - это может быть способ сохранять этим умным людям продуктовый фокус. Но тоже только "может быть " потому что в performance review результаты OKR (по утверждениям) не используются.
У меня до сих пор остается подозрение что "вы не любите кошек, потому что вы просто не умеете их готовить" и если хотя бы раз увидеть как это все происходит в живую на стыке кварталов то может быть и можно будет понять в чем изюминка. Пока все равно не понял.
Оценка книги: 4/10 , ниже есть три видео которые успешно заменяют книгу.
Заметки на полях
История OKR
Фредерик Уинслоу Тейлор -
Хоторнский эффект - дело не в свете и не изменениях, а в том что к работникам проявили интерес.
Питер Друкер , Практика менеджмента - три каменщика (зарабатываю на жизнь, становлюсь лучшим в профессии, строю храм). Качать профессию - не самоцель, нужен фокус на бизнес.
Management by Objectives (Друкер)
Каждому менеджеру, начиная с «большого босса» и заканчивая начальником цеха, бригадиром и офис-менеджером, нужны четко сформулированные цели. Эти цели должны объяснять, какие результаты необходимо обеспечивать вверенному ему подразделению, а также указывать, какой вклад обязан внести менеджер и его подразделение, чтобы помочь другим структурным единицам компании выполнить поставленные перед ними цели. Наконец, они должны указывать, на какой вклад со стороны других подразделений может рассчитывать этот руководитель, чтобы достичь поставленных перед ним целей. Иными словами, с самого начала акцент в целях делается на коллективной работе и коллективных результатах.
Цели по Друкеру могут быть краткосрочными и долгосрочными, количественными и качественными.
Проблемы с MBO - насаждение сверху вниз и длительный период планирования.
Эндрю Гроув, Intel - куда я хочу попасть (Цель, O) и как я буду оценивать свое продвижения (мера результата, key result). Горизонт планирования до 3 месяцев.
Джон Дорр (фонд Kleiner Perkins) - занес OKR из Intel в Google.
Что такое OKR
OKR — это структура критического мышления и постоянная дисциплина, направленная на то, чтобы сотрудники работали вместе, сосредоточив свои усилия на внесении ощутимого вклада в развитие компании.
Структура критического мышления.
Постоянная дисциплина.
Убедитесь, что сотрудники работают вместе.
Сосредоточение усилий.
Вносите ощутимый вклад.
Цель (Objective) — это краткое изложение главной качественной цели, при- званной продвигать организацию в желаемом направлении. По сути, это вопрос «Что мы хотим сделать?». Правильно сформулированная цель имеет временное ограничение (квартал) и должна вдохновлять вашу команду и отражать ее коллективное видение.
Ключевой результат — это количественное выражение для измерения достижения цели. Если цель сводится к вопросу «Что мы хотим сделать?», то ключевой результат — «Как мы узнаем, что достигли цели?».
Самое трудное при постановке ключевых результатов — найти баланс: ключевые результаты должны быть достаточно сложными, чтобы вы получали интеллектуальное удовольствие от их достижения, но не сверхсложными, поскольку кажущаяся невыполнимость может деморализовать команду.
Ключевой результат может быть базового уровня (первый раз формулируем что хотим поэтому не понимаем где база и полученное будем считать за нее), позитивной метрикой (повысить на 20%), негативной метрикой (сократить на 20%), метрикой пороговых значений (между 20% и 30%) и вехой (запустили фичу в 3 странах-0.7, в 2-х - 0.5, в 1-ой - 0.3).
5 мифов реализации стратегии :
Реализация — это согласованность. Каскадирование целей сверху вниз создает функциональные колодцы, которые действуют в собственных интересах.
Реализация означает следование плану . Пока не столкнутся с реальностью. Нужно реагировать на изменение среды, а не следовать плану.
Коммуникация — это понимание. коммуникация доходит не до всех и не одинаково.
Культура результативности стимулирует реализацию. Бешеная результативность приводит к локлаьным перекосам.
Реализация OKR должна осуществляться сверху вниз. Ровно наоборот.
Нельзя сказать что прочтение этой книги намного лучше чем прочтение оригинального документа, но скорее нагрузит вас контекстом для оригинального документа.
В культуре Netflix нет ничего прям особенного - это просто управление без хуйни - вы убираете все ненужное, что может сковывать свободу действий людей в инновационной компании работающей на развлекательном рынке. Так можно сделать еще много где, но много где так сделать нельзя - и об этом в книге тоже говорят прямым текстом. Так же, всем адептам культуры Freedom & Responsibility настоятельно рекомендую обратить внимание на целую массу мест в книге где чаще всего Рид говорит о том что "не все везде и всегда, а кое-что иногда и местами" - адаптация некоторых практик внутри самой организации неравномерна (и это приходится подстегивать) и есть резервные механизмы управления (из опыта предыдущего управления), которые всегда можно включить.
Пожалуй самыми ценными для среднестатистического менеджера в ИТ (классический читатель этой книги) на мой взгляд будут две мысли: 1. уберите посредственностей/мудаков из команды - это как раз тот самый случай когда 2+2 будет давать даже не 5 , а 6.
2. Контролировать умных людей все равно нужно, но дав им достаточное информационное поле для принятия решений и возложив на них ответственность - делать это можно сильно реже и/или выборочно.
Книга хорошо структурирована и качественно переведена.
Я читал эту книгу очень долго и причин тому две : 1. очень мелкий шрифт - я думаю это сделано специально. ибо если ее издать с нормальным размером шрифта, то она превратиться в 800 страничный фолиант и хер ее продашь.
2. отвратительный язык изложения и постоянные качели в нем - то читаешь и приятно-интересно, то блевать хочется.
Эта книга объяснит вам некоторые элементы теории игр, некоторые моменты про стратегию вообще и в частности, но не объяснит ничего из этого вглубь (гораздо лучше, хоть и менее красочно с этим справится Алексей Савватеев на YouTube), зато покажет вам кучу экономических примеров того как стратегия и игры воплощаются в жизни.
Если хочется прикоснуться к теории игр и стратегиям. но не хочется в математику - рекомендую, во всех остальных случаях - нет.
Как я уже писал в своем опусе о GTD вообще я пользовался MaxDone и пришло время его менять. Чтиво ниже - оно про мой конкретный переезд с MaxDone на Todoist, события ему предшествовавшие и выводы по ходу.
Часть первая - щелчок.
В дампе данных из MaxDone я выяснил, что первая завершенная задача осела в его закромах аж в ноябре 2014 года. Что же заставило меня с него мигрировать? Причины на самом деле три, хотя их можно сократить до двух: 1. 29 июня 2020 сервис прилег и так как я лично знаком с людьми, которые его начинали делать я просто пошел в личку и его приподняли.
В этот момент собственно говоря сознание и дало трещину - с одной стороны ты не видишь своих задач и мозг думает что их нет, но спустя 15 минут, когда допамин с серотонином успокоились приходит отрезвление и осознание того что они на самом деле есть.
2. Листая ленту Twitter я увидел вот такое вот и щелчок сфинктера произошел второй раз.
Перейдя по ссылке я узнал новых деталей на тему того что проект не будет поддерживаться дальше и что ситуаиця описанная в п.1 может повторится с более печальным исходом.
3. Перед новым годом я разжился Samsung Galaxy S20 с 11 версией Android на котором виджет Maxdone отказался работать и показывать актуальные таски от слова совсем, но это скорее было уже последней каплей, нежели причиной.
Тут можно сразу отложить первые два вывода: 1. если в системе task-менеджмента нет возможности экспорта тасков или на худой конец API, чтобы этот экспорт сделать самому, то вы оказываетесь в ситуации классического vendor lock-in и вам будет плохо.
2. бэкапы. Тут много всего можно написать, но первое - они должны быть, и второе - в них нужно хотя бы разок посмотреть , что там отклаывается, и третье - лучше чтобы они это делали в какую-то независимую площадку.
В качестве независимой площадки для бэкапов сделанных задач я выбрал Google Docs и настроил туда отгрузку через Integromat - хотел сначала telegram, но не все так просто как хотелось бы.
Часть вторая - выбор новой системы.
Собственно, поиски новой системы начались несколько раньше - после первого и второго прецедентов я стал смотреть на то что есть на рынке. Что входил в рассмотрение 1. Microsoft Todo (ex. Wunderlist) - попробовал , интерфейс и возможности показались дико примитивными/неспециализированными. Видео от Дорофеева тут.
2. Todoist - слышал отличные отзывы от друга, решил смотреть.
3. SingularityApp - еще один проект который пиарит Максим Дорофеев (как и MaxDone). Видео от Дорофеева тут. Показалось аналогом todoist, c минорными изменениями UI и всякими ненужными мне pomodoro-фичами.
Основным бичом всех инструментов после MaxDone стали ... выполненные задачи. В отличии от MaxDone который просто отображает их все одной портянкой, Todoist и Singularity предполагают более неудобный принцип работы. В Todoist вы найдете все, но в журнале активности, а в Singularity - в архиве.
Надо сказать что эти отличия всегда будут вкусовщиной и тут следующий вывод:
при выборе инструмента нужно учитывать свои личные предпочтения.
Еще один момент, который меня сначала триггерил, а потом даже понравилось - в todoist найти задачу вне проекта - сложно, а если она в проекте - то легко. Это дает более сильно выраженный проектный фокус, что кажется даже хорошо.
Третий момент который мне нравится в Todoist сейчас - это то что ты можешь посмотреть свои задачи на произвольный день в календаре - то есть когда ты перекидываешь задачи с понедельника на четверг, потом наступает четверг и ты понимаешь что у тебя их на четверг уже 25 и все надо именно сейчас (в четверг) - ну это довольно неприятный "ой", который эта вот фича может предотвратить.
Часть третья - миграция
Тут все будет довольно скучно и по-менеджерски. Вместо того чтобы писать красивые скрипты миграции и долго дебажиться, я просто экспортировал все незавершенные задачи в CSV , переделал их в другой CSV и импортировал в Todoist. Нюанс - у Todoist нет глобального импорта задач, есть только попроектный, поэтому я разрезал задачи на "сегодня", "неделю" и "может-быть когда-нибудь потом" на три разных проекта с этими самыми названиями и потом уже растаскивал их по проектам в соответствии со спецификой Todoist. Кстати проект "может быть, когда-нибудь потом" до сих пор не растащил до конца))).
Что еще нужно сказать про текущую систему в сравнении с предыдущей? Проекты в MaxDone снабжены статусом (in progress, planning, completed, canceled, paused) и сроками, но оба эти аттрибута чуть менее чем полностью нефункциональны там и более носят статус заметок на полях, нежели чего-то рабочего - если сроки проекта уже прошли MaxDone не начнет орать дурниной, равно как и todoist, но у него этих аттрибутов и нет.
Из приятных мелочей - простецкая аналитика количества выполненных задач в todoist - я знаю что в среднем у меня 12 выполненных задач в день и можно его настроить на эту цифру , чтобы когда червь сомнения начнет тебя грызть изнутри - можно было посмотреть на счетчик и успокоится (Конечно, задачи все надо записывать, но это везде так).
Выполненные задачи из MaxDone я выгрузил как справочную информацию, спасибо заметке на форуме у Максима Дорофеева и тему что у MaxDone нет лимитов и все свои 14000+ тасков я смог выгрузить одним куском json-а, но опять же - парсить его я не очень собираюсь, больше лежит как бэкап для справочной информации, за которой я скорее сначала пойду в пока еще работающий MaxDone нежели в json у себя на компе но мысль о том чтобы сделать из этого на каком-нибудь bootstrap статическую страничку набитую данными с фильтрацией и поиском или отложить в табличном виде в Google Docs у меня есть.
MaxDone спасибо, с ним было хорошо, при том довольно долгое время. Про todoist напишем когда-нибудь потом, когда придется съезжать с него.
Основной залог спокойного переезда - малое количество задач (у меня было чуть больше 300 и кажется что многие в системе управления задачами лежать не должны).
Вот уже много лет у меня в бэклоге лежит задачка-желание написать говно-пост про идеи и креативность. Почему лежит и не делается ? Потому что в какой-то момент в прошлом я посмотрел видео Скотта Беркуна и понял, что мне еще рано рассуждать на эту тему, можно еще людей послушать.
Видео вот
Тем не менее, Скотт был менеджером проектов в Microsoft, и увидев что его книга переведена на русский я не мог пройти мимо.
Книга структурирована на 3 части , 16 глав. Автор прямым текстом в начале говорит, что главы можно читать независимо друг от друга, но это не так - в тексте есть куча отсылок на другие главы, при том чаще дальше по содержанию книги чем назад.
На 560 страниц довольно много воды, абстрактных примеров и слоганов Тони Роббинса.
Про "практику проектного менеджмента" - вообще в книге не нашел.
Скотт занимался в Microsoft разработкой Internet Explorer и я готов поверить что в MS для проектов уровня Internet Explorer есть такой документ (оформленный как документ) как продуктовое видение, есть маркетинговая стратегия и даже строятся WBS (work breakdown structure). Проблема в том, что в российском ландшафте управления проектами вы этих артефактов с высокой долей вероятности не увидите, а если и увидите то не факт что качественные.
Более того - мне кажется половина практик описанных Скоттом из той эпохи когда софтверные проекты делались годами, agile был в новинку - вторая половина 90-х и начало 2000-ых. С тех пор много чего поменялось.
В книге есть полезные приемы, но и тут вопрос - если вы реально управляете проектом по разработке софта и не знаете как проводить встречи, писать письма, трекать прогресс - то может быть вам и будет полезно, но страшно за ваш проект. Одним из плюсов все-таки является большая библиография источников автора - я себе оттуда пару книг записал.
Трудно даже сказать сколько лет эта книга пылилась у меня в списке на прочтение (да, моя антибиблиотека очень велика).
"Если долго мучаться, что-нибудь получится" - гласит народная мудрость.
Если вы много и системно занимаетесь чем-то, то у вас внутри вырабатывается система. Если вы занимаетесь этим своим чем-то ну очень успешно, то выработанную вами систему можно попробовать продавать отдельно, даже отдельно от результатов ее функционирования.
Например Уильям Детмер много упарывался по теории ограничений Голдратта и потому выродил из себя книгу по инструментам теории ограничений, прочитав которую вы узнаете что на самом деле есть 7 нотаций, следуя которым если вы будете правильно описывать свои проблемы, то можете найти что-то интересное, чего не замечали ранее.
Примерно тоже самое и с теорией решений изобретательских задач - если долго анализировать патентный фонд , то можно начать находить схожие закономерности в изобретениях различного рода. В этих закономерностях можно углядеть некоторые принципы, может быть даже описать законы. Вопрос лишь в том - будет ли жить дальше твоя система, отдельно от тебя отца-основателя или нет? В случае с Дэвидом Алленом и его GTD - можно сказать , что да. В случае с ТРИЗ - наверное нет. И причиной тому всего лишь историческая случайность. Описанная в книге теория весьма интересна, к тому же подкреплена кучей ссылок на патенты и авторские свидетельства. Однако в мире она почему-то не прижилась. Точнее прижилась ограниченно, исключительно в области материального производства (хотя и это уже неплохо).
Если бы исследования патентного фонда, составлявшие основу ТРИЗ проводились с государственным масштабом и за государственный счет может быть удалось бы нечто больше и долгоиграющее, в том числе для ИТ.
Книга скорее представляет собой высокоуровневый обзор + шпаргалку по основным моментам ТРИЗ. Назвать ее совершенно бесполезной конечно нельзя - автор таки набрел на понятие психологической инерции, которая мешает изобретательству, и некоторые техники ее устранения. Даже разработал пошаговый алгоритм решения изобретательской задачи (хотя на самом деле нет), который вводит понятия мини(макси)-задачи, оперативной зоны и оперативного времени, которые полезны и сейчас. Но вот ощущения большой единой системы, которую можно было бы сейчас применить к ИТ у меня содержимое теории не оставило.
Заметок на полях не будет (они у меня есть , но выглядят крайне сумбурно), ибо книга структурирована отвратительно (да. в СССР не умели "продавать").
Оценка: 5/10. Тот же самый Харари "почешет" ваш мозг лучше.
Если вы до этого никогда не читали и не видели в живую выступдения Александра Орлова и Славы Панкратова, то выйдете и зайдите в профессию снова идите в гугл, там много.
Мне очень нравится вот такой вот формат - небольшая книжка за небольшие деньги, которая написана простым языком (привет, Нассим Талеб!) и хорошо раскладывает одну тему. Я хочу чтобы таких книг было больше.
Книга рассказывает как коммуницировать не надо, а как надо в ежедневном , санитарно-гигиеническом контексте. И если представить себе, что все и каждый на работе коммуницировали бы прям по этой книжке , то Кафка и Оруэлл бы довольно ухмыльнулись, но нет.
Нет, потому что IT представляет из себя жукто перегретую отрасль, где даже мудаки не соблюдающие эти вот санитарно-гигиенические нормы будут получать офферы и заполнять офисы. И если мудаки - это апофеоз, то кроме них есть еще и полумудаки или просто люди с проблемами в коммуникации, с которыми вам придется взайимодействовать. Так вот методы описанные в книжке подходят для всех.
Это типа как мыть руки.
Автору желаю еще таких. небольших и полезных книг.
Оценка : 8.5 / 10
P.S. ну и про "Черную книгу менеджера" я тоже не могу не напомнить - она полна простых и удивительно хороших коммуникаций :).
Заметки из книги
Коммуникации - это зачастую переговоры,а они бывают позиционные(нам важна наша позиция) и партнерские (нам важны взаимоотношения с партнером).
В позиционных переговорах часто используются манипуляции для того, чтобы вызвать у собеседника эмоции.
Типы манипуляций:
Роль агрессор, тип эмоции - страх
Роль жертва, тип эмоции - чувство вины
Спаситель, эмоция : халява = лень + жадность (ничего не надо делать, а денег и возможностей еще дадим).
Тяжелые манипуляции - приемы направленные на разрушение картины мира человека («у хороших мам дети не болеют»)
Картина мира человека состоит из слоев:
Я как личность. Удар в уровень «я-не я»
Самоидентификация («почему специалисту такого уровня я должен такие вещи объяснять» )
Ценности («порядочные люди себя так не ведут» )
Социальные установки («мы ж не либералы какие-то» )
Опыт (« кто ж ездит на форде» )
Фантазии и иллюзии («форды покупают только люди с нетрадиционной ориентацией» )
Работа с критикой
Если человек кричит - значит он думает что его не слышат.
В ответ на письмо с критикой - прийти лично или позвонить (близкие коммуникации, потому что «по телевизору я не страшен» )
Ходить и орать одновременно трудно - выгулять его за кофе.
Начать за ним записывать.
Пусть нарисует схему проблемы.
5 вопросов для прояснения критики:
Что случилось ?
В чем это выражается?
Чем это плохо?
Чего хочется? Как нам это решить ?
Как вы поймете что это решение работает? (Если собеседник предлагает нечеткое решение)
Принципы конструктива
Своевременность - ретроспективно все всегда ясно и мы все умные
(не решаем проблемы в прошлом)
Решаем все проблемы,а не одну.
Адресность - проблему нужно решать с тем, с кем ее можно решить, а не мусолить в курилке со всеми.
Факты и данные
Намерение решить проблему, а не человека.
Ни один реальный подвиг не должен остаться «непроданным».
В чем проблема ? Влияет ли это на работу? Как влияет? Если не решать - что будет ?
Чего хотим долбится обсуждением?
Почему человек себя так ведет?
Факты и аргументы для себя и для оппонента
ПРоблема (озвучить, послушать что думает другая сторона, придти к согласию)
Не боятся вставать на паузу
Если факты кончились. - выйти из разговора
Решение (рассмотреть предложенные варианты, зафиксировать договоренности)
Предлагать решение самому можно только «наверх» - менеджеру или клиенту
Пусть оппонент предлагает решение сам
Проверка решения на устойчивостьм ( «а что если нагрузка вырастет в три раза?» )
Контроль (дата для обсуждения прогресса, проверяем достигнута ли цель, проверить что прогресс работает для обеих сторон)
Если решение выполняется- то сказать спасибо
Если нет - повод спросить «как же так, мы ж договорились»
Подбор аргументов «хотелки»-«аргументы»
Сферический сотрудник в вакууме хочет:
Интересных задач
Не работать над скучными задачами
Быть авторитетом для остальных
Роста зарплаты
Стать руководителем
Человек меняет свою модель поведения, когда понимает что она противоречит его целям.
Доность аргументы нужно через вопросы (как ты думаешь смогу ли я рекомендовать тебя к повышению?) , потому что тот кто задает вопросы управляет коммуникацией.
Типы контроля:
итоговый - исполнитель уже неоднократно подобного рода задачи и есть доверие.
предварительный - человек вроде бы выполнял подобного рода задачи
Периодический - стендапы, еженедельные планерки
Поэтапный - раз в N времени
выборочный - в случайное время в случайном месте, потому что иначе не можем.
Люди привыкают к тому как контролируют их работу, как следствие. - смена модели контроля - тяжеловато.
Работа «вверх»
Мотивы/проблемы руководителя -> Действия руководителя -> твои проблемы
Нужно собрать весь контекст, чтобы хотя бы приблитзительно понимать мотивы/проблемы руководителя, которые привели к вашим проблемам.
Матрица 2*2 «доверие»- «прозрачность»
Падает доверие - увеличивайте прозрачность.
Предлагай «наверх» веер решений.
Вопросник для рабора кейсов
Есть ли проблема?
Влияет ли это на работу?
Если не решать что будет не так ?
Какова ваша цель?
Допустим , человек продолжает , а его результаты растут в разы - так норм?
Человек всегда так себя вел или нет?
С какого момента это началось?
Что могло послужить причиной изменения поведения?
Человек понимает чего вы от него хотите ?
Он это умеет делать?
У него есть физическая возможность это делать ?
Как эта ситуация может выглядеть с точки зрения человека?
Чего человек может добиваться своим поведением?
Чего вообще человек хочет?
Какие аргументы покажут ему что его текущее поведение не соответствует его целям?
Когда конструктивная конфронтация не работает?
Стороны накопили эмоциональный багаж
Карта реальности другой стороны нам не известна, а наша-то правильная ?
