Мне потребовалось много довольно глубокой психологической работы, чтобы к этому прийти.<\/p>\n
Тем не менее, я извлек и более конкретный и практичный способ из своей многолетней работы над собственной продуктивностью.<\/p>\n
В посте для платных подписчиков на Бусти<\/a> я описал пошаговый алгоритм борьбы с прокрастинацией, который я выработал за это время.<\/p>\n Каждый прием почерпнут из каких-то научных исследований или экспериментов и опробован на практике — моей и моих заказчиков.<\/p>\n",
"date_published": "2023-05-23T14:16:22+00:00",
"date_modified": "2023-08-02T07:34:28+00:00",
"_date_published_rfc2822": "Tue, 23 May 2023 14:16:22 +0000",
"_rss_guid_is_permalink": "false",
"_rss_guid": "127",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "126",
"url": "https:\/\/blog.skalon.me\/2023\/05\/23\/11\/",
"title": "Главный принцип настройки систем управления — простота",
"content_html": " У меня есть простая аналогия для настройки процессов с точки зрения исполнителя.<\/p>\n Представьте себе продавца, который занимается холодным обзвоном. У него в CRMке специально для холодных обзвонов должен быть простейший интерфейс, состоящий из:<\/p>\n А теперь представьте, что продавцу каждый раз приходится искать следующий контакт для прозвона: фильтровать массу карточек в разных статусах, удерживать концентрацию, чтобы не отвлечься на более приятные задачи...<\/p>\n Как вы думаете, какова будет продуктивность по сравнению с первым сценарием?<\/p>\n Во всех интерфейсах систем, которые предназначены для работы с задачами, стремитесь к однозначности:<\/p>\n А у вас в таск-трекере порядок?<\/p>\n",
"date_published": "2023-05-23T13:57:25+00:00",
"date_modified": "2023-08-02T07:40:17+00:00",
"_date_published_rfc2822": "Tue, 23 May 2023 13:57:25 +0000",
"_rss_guid_is_permalink": "false",
"_rss_guid": "126",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "125",
"url": "https:\/\/blog.skalon.me\/all\/vozmozhnost-vpisatsya-v-komyuniti-i-prokachat-svoyu-menedzhersku\/",
"title": "Возможность вписаться в комьюнити и прокачать свою менеджерскую скилуху",
"content_html": " Друзья, всем привет.<\/p>\n Я решил завести Бусти<\/a>: платную подписку на дополнительные полезняшки от меня, которых нет в Телеге. Долго думал, чего бы такого ценного отгрузить платным подписчикам, сейчас расскажу, что надумал.<\/p>\n Расположил в порядке возрастания тиров (tier) — от начальных (наименьшая стоимость подписки) к продвинутым — максимальная стоимость подписки.<\/p>\n Первый тир<\/b><\/p>\n Возможно, кто-то возможно уже давно думает: «Блин, годный контент Вася постит. Надо его поддержать». Теперь у вас есть такая возможность. Дополнительно вы получите возможность задавать вопросы, на которые я буду отвечать в формате видео раз в месяц.<\/p>\n Второй тир<\/b><\/p>\n У меня есть контент, чертовски полезный для менеджеров, но чересчур задротский, чтобы публиковать его в канале. Скринкасты того, как я настраиваю системы на ноу-код инструментах, записи моих стримов на менеджерские темы (возможно — с гостями), записи мастермайндов на тему менеджмента, которые я буду проводить с членами сообщества, о котором вы можете прочитать в следующем тире. Планов громадье, стэй тюнд, как говорится.<\/p>\n Третий тир<\/b><\/p>\n Я решил создавать сообщество, которое будет реально полезно менеджерам. Учиться у лучших. Нетворкаться. Спрашивать совета в сложных ситуациях. Постить вакансии и объявления о поиске работы.<\/p>\n Для этого я создам (сюрприз, сюрприз!) закрытый телеграм-чат, доступ в которому будет бонусом третьего тира.<\/p>\n Чтобы это не превратилось в еще один дохлый чатик в вашей папке «Редко заглядываю», я буду:<\/p>\n Сейчас отличное время, чтобы вписаться в это сообщество: пока участников будет мало, я смогу уделять всем максимум внимания. Почти индивидуальная работа получается.<\/p>\n Четвертый тир<\/b><\/p>\n C донатерами четвертого уровня я готов раз в месяц созваниваться тет-а-тет для обсуждения вопросов, связанных с организацией исполнения, наведением порядка и дисциплины… в общем, по темам, в которых я экспертен. Часовая встреча, на которой вы задаете вопросы, я отвечаю или в режиме коучинга помогаю вам прийти к ответам.<\/p>\n Пятый тир<\/b><\/p>\n Я буду индивидуально сопровождать донатера в формате коучинга. Это значит, что:<\/p>\n В отличие от предыдущего тира, к этим встречам я готовлюсь: изучаю ваши материалы, записи совещаний и т. д. Также у вас есть возможность задавать мне вопросы между встречами.<\/p>\n Ссылка еще разок<\/a>.<\/p>\n",
"date_published": "2023-05-23T13:56:12+00:00",
"date_modified": "2023-05-23T13:56:05+00:00",
"_date_published_rfc2822": "Tue, 23 May 2023 13:56:12 +0000",
"_rss_guid_is_permalink": "false",
"_rss_guid": "125",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "124",
"url": "https:\/\/blog.skalon.me\/all\/mozhno-obizhatsya-mozhno-ispolzovat-kak-rabotat-s-hinsaytom-i-ch\/",
"title": "Можно обижаться, можно использовать — как работать с хинсайтом (и что это такое)",
"content_html": " Когда я презентую заказчику рекомендации по улучшению процессов, я часто слышу в ответ:<\/p>\n «А, ну это само собой разумеется» или «Да, да, ровно это я и собирался сделать». А порой даже: «Да-да, мы так и работаем»<\/p>\n При этом очевидно, результатов это «мы так и работаем» не приносит.<\/p>\n Например:<\/p>\n Рассказываю про «цикл регулярных совещаний<\/u>»<\/a> или совещание как драйвер процесса<\/a>. Заказчик говорит: «Да-да, понятно. У нас настроен регулярный менеджмент». При этом без вмешательства собственника ничего не едет, задачи теряются, все держится на нескольких ключевых сотрудниках.<\/p>\n Внедряю новую методологию управления проектами, заказчик говорит: «Ну да, мы ведь так и работали». При этом проекты буксуют, в ИТ-системе черт ногу сломит, кто за что отвечает — непонятно.<\/p>\n Предлагаю провести сессию ретроспективы<\/a>. Слышу: «Ой, я регулярно со своими менеджерами провожу сессии ретроспективы». Задаю пару уточняющих вопросов, выясняется, что под «ретроспективой» имеется в виду разбор полетов, который боятся и ненавидят все, но в который руководитель ввергает команду после особо неприятного факапа.<\/p>\n Сначала меня это задевало: воспринималось, как будто обесценивают мой труд. Я-то знаю, чего стоит эта простота. Но потом я понял, что это совершенно естественная ситуация, с которой просто надо уметь работать.<\/p>\n Это не со зла — обычное смещение восприятия<\/b><\/p>\n Причин несколько:<\/p>\n По форме — есть, по существу — издевательство<\/i> (перефразируя классика). Очевидно, что иметь документ с названием «календарный план» ≠ иметь план по проекту. Проводить ежедневное обсуждение задач с командой ≠ внедрить СКРАМ. Но чтобы понять, чем отличается каша из набросанных в случайном порядке задач от рабочего календарного плана, нужен опыт. Надо посмотреть какое-то количество календарных планов, а еще лучше — составить несколько собственноручно и провести сотню планерок по ним. У меня такой опыт есть, у заказчика — нет. Это нормально: потому меня и позвали.<\/p>\n Путаем «хотим делать» и «делаем»<\/i>. Иногда «время от времени собираемся, чтобы хаотично пообщаться по теме проекта» становится «регулярно проводим планерки». Это добросовестное заблуждение: термины зыбкие, и разница на первый взгляд тонкая, легко ее упустить, если не знать, что собой представляет сфокусированная планерка, и что «регулярно» это значит по графику, по четкой повестке и т. д.<\/p>\n Хинсайт<\/i>. То есть, ощущение «а, ну это же само собой разумеется», когда все стало известно. Действительно: почти все вещи в проектном управлении укладываются в здравый смысл. Это не квантовая физика. Проблема в том, что до того, как «все само собой уразумелось», в момент принятия решения, перед заказчиком еще несколько очевидных, но неправильных вариантов, каждый из которых «сам собой разумеется». И пока сам эту дорожку не прошел, хрен догадаешься, какой из вариантов рабочий. А вот когда правильный уже известен, создается ощущение, что он очевиден.<\/p>\n Полезно не обижаться и опираться на факты<\/b><\/p>\n Как же с этим работать?<\/p>\n Во-первых, если вы внедряете новые процессы в компании — полезно «сходить в гэмбу<\/u>»<\/a> (это всегда полезно), и посмотреть, что конкретно собой представляют планы проектов, что именно написано в регламентах и на что похожи регулярные планерки. Соберите факты, и потом уже на основе фактов объясняйте<\/a>, что и почему не работает.<\/p>\n Во-вторых, этот эффект можно использовать. Я обычно в такой ситуации говорю: «Да, совершенно верно. У вас все это было. Мы взяли все ваши практики, просто чуть-чуть причесали и структурировали<\/i>». И это радикально снижает организационное сопротивление: людям гораздо комфортнее принять свои собственные наработки, которые немного «довели до ума», чем абсолютно новую систему.<\/p>\n А я уж успею получить должную меру признания, когда новые процессы поедут, и станет понятно, насколько они отличаются.<\/p>\n Кстати, кто из прочитавших сказал себе: «Да это же само собой разумеется»?<\/p>\n",
"date_published": "2023-05-23T13:53:47+00:00",
"date_modified": "2023-05-23T13:53:21+00:00",
"_date_published_rfc2822": "Tue, 23 May 2023 13:53:47 +0000",
"_rss_guid_is_permalink": "false",
"_rss_guid": "124",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "123",
"url": "https:\/\/blog.skalon.me\/all\/universalny-algoritm-dvizheniya-vpered-zapilite-prostuyu-tablich\/",
"title": "Универсальный алгоритм движения вперед — запилите простую табличку и пользуйтесь",
"content_html": " Есть замечательный инструмент в проектном управлении, который в свое время перевернул мое представление о руководстве проектами. Он, с одной стороны, довольно тривиален, с другой — я не так часто вижу его применение.<\/p>\n Руководитель проекта упорно двигается к результату<\/b><\/p>\n Быть руководителем проекта (РП) — значит быть 100% нацеленным на результат. Помню, меня в свое время впечатлила фраза моего старшего товарища: «Я вцеплюсь в результат, как бульдог, и не отпущу хватку, пока не достигну его». С тех пор воспитываю в себе этот подход.<\/p>\n Но на практике постоянно возникают какие-то препятствия, о которые неопытные РП спотыкаются и буксуют. Особенно мешает, когда препятствует какая-то мутная, неясная фигня.<\/p>\n Всю мутную и неясную фигню надо прояснять и упорядочивать, только тогда вы сможете что-то с ней поделать.<\/p>\n Лучше всего все опрозрачнивать при помощи моих любимых табличек.<\/p>\n Реестр открытых вопросов — паркуем всю неясную фигню<\/b><\/p>\n Открытый вопрос — a.k.a. «issue», «проблема» — это какая-то (сюрприз!) проблема, которая непременно повлияет на проект, если ее не решить.<\/p>\n Важно, что это не задача:<\/p>\n Приведу пример: ваш тимлид положил заявление на стол. Это проблема. Если с ней что-то не сделать, работа команды будет парализована.<\/p>\n Как руководитель вы можете:<\/p>\n Все это — задачи, и они падают в бэклог команды.<\/p>\n Сам открытый вопрос «Иванов увольняется с такого-то числа» висит в реестре открытых вопросов, вы удерживаете на нем фокус, т. к. на каждой планерке рассматриваете открытые вопросы<\/p>\n Универсальный алгоритм движения вперед<\/b><\/p>\n Для меня работа с открытыми вопросами стала воплощением универсального алгоритма движения вперед.<\/p>\n На практике я реализую этот алгоритм, задавая вопросы:<\/p>\n Это практически система-ниппель: мы либо двигаемся вперед, либо нам что-то мешает, тогда мы решаем, что делать, чтобы это устранить, и снова двигаемся вперед.<\/p>\n Других вариантов нет, только вперед.<\/p>\n",
"date_published": "2023-05-23T13:46:43+00:00",
"date_modified": "2023-05-23T13:46:15+00:00",
"_date_published_rfc2822": "Tue, 23 May 2023 13:46:43 +0000",
"_rss_guid_is_permalink": "false",
"_rss_guid": "123",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "122",
"url": "https:\/\/blog.skalon.me\/all\/fokus-na-nekorrektnoy-metrike-privedet-k-pustoy-trate-resursov-n\/",
"title": "Фокус на некорректной метрике приведет к пустой трате ресурсов. Надо правильно понимать создаваемую ценность",
"content_html": " Как могли заметить внимательные читатели моего блога, я меломан, а хорошую музыку хочется слушать на хорошем звуке.<\/p>\n Долгое время я покупал одни наушники круче других, но быстро заметил, что прирост качества на рубль резко уменьшается: наушники за 80 долларов были примерно в два раза круче наушников за 40, но наушники за 350 долларов были круче наушников за 80 процентов на 25.<\/p>\n Где-то на этой отметке я остановился, потому что понял: чтобы выйти на качественно новый уровень, мне придется потратить деньги, которые я не готов отдать за наушники. Тем более, что мои Westone X30 — аудиофильские наушники со сменным проводом, — звучали хорошо.<\/p>\n Какую метрику максимизировать?<\/b><\/p>\n Качественный прорыв в области пользовательского опыта, — т. е. того, насколько я удовлетворен взаимодействием с продуктом — пришел неожиданно.<\/p>\n Во-первых, я сменил оригинальный провод на блутус провод. До того, как я это сделал, я не отдавал себе отчета в том, как хорошо без вьющихся по телу и запутывающихся проводов.<\/p>\n Во-вторых, я сделал кастомные амбюшуры: сдал слепок ушей, по которому мне отлили специальную резиновую вкладку. Это сделало ношение наушников в разы более комфортным, улучшило звукоизоляцию процентов на 40 и добавило процентов 30 баса.<\/p>\n Вместо максимизации метрики «качество звука» через улучшение технических спецификаций я радикально повысил свой уровень счастья от применения продукта, потратив дополнительно примерно 30% от его стоимости.<\/p>\n Вспоминается вечный спор между хэйтерами и фанатами эппл на тему того, насколько важна скорость процессора, количество мегапикселей и пр. технические метрики.<\/p>\n Нет, важна субъективная польза и кайф, который получает пользователь от продукта. Его не сведешь к тактовой частоте процессора.<\/p>\n Новый прорыв пользовательского опыта<\/b><\/p>\n Недавно блутус провод скончался, отслужив должное, и я решил, что это повод купить себе эппл эйр подс.<\/p>\n Это открыло для меня еще один уровень прироста пользовательского опыта:<\/p>\n Из минусов — менее комфортно сидят в ушах и батарейка не так долго держит. Правда, на фоне остальных улучшений это мелочи.<\/p>\n И потратил я на это меньше денег, чем на свой комплект из наушников, блутус провода и амбюшур.<\/p>\n Я часто привожу этот пример в качестве иллюстрации того, что надо выбирать правильную метрику для максимизации и правильно формулировать проблему<\/a>.<\/p>\n",
"date_published": "2023-05-23T13:44:20+00:00",
"date_modified": "2023-05-23T13:43:46+00:00",
"_date_published_rfc2822": "Tue, 23 May 2023 13:44:20 +0000",
"_rss_guid_is_permalink": "false",
"_rss_guid": "122",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "121",
"url": "https:\/\/blog.skalon.me\/all\/kak-udelyaya-odin-chas-v-mesyac-menedzher-mozhet-dvigat-ogromny\/",
"title": "Как, уделяя один час в месяц, менеджер может «двигать» огромный объем работы?",
"content_html": " Одна из типичных проблем, с которой ко мне обращаются — без участия шефа ничего не едет. Приходится закапываться в текучку, вместо того, чтобы заниматься задачами развития. В тяжелых случаях менеджер может потонуть рутине отдела из трех человек.<\/p>\n Как же управляют топ-менеджеры многотысячных корпораций? Ведь у них тоже 24 часа в сутки.<\/p>\n Проиллюстрирую на примере одного своего проекта.<\/p>\n Вместо брейнстормов — управленческое совещание<\/b><\/p>\n Я внедрял проектное управление для заказчика. Когда я пришел, большая часть совещаний в компании представляла собой мозговые штурмы, на которые люди приходили общаться: обсудить проблему, выяснить информацию, подумать.<\/p>\n Но чтобы контролировать большой портфель инициатив, такой режим не годился. Чтобы не утонуть в десятках совещаний, надо было успеть обсудить все самое важное по всему портфелю.<\/p>\n Когда я предложил сделать для этого одну встречу, у заказчика был шок: такое совещание будет идти часов шесть!<\/p>\n Я продолжал настаивать, что это возможно, если сделать совещание более концентрированным.<\/p>\n Я прописал процесс подготовки к совещанию:<\/p>\n На самом совещании мы вместо мозгового штурма предусмотрели краткий доклад о выявленных проблемах и предлагаемых контрмерах.<\/p>\n Зачем тогда вообще проводить совещание, если мы все обсудили?<\/b><\/p>\n Именно такой вопрос задавал заказчик, когда я выдвинул предложения.<\/p>\n Помните мой пост про то, что сотрудник должен приходить с проектами решений, а не с проблемами<\/a>? Здесь происходит примерно то же самое.<\/p>\n Вместо того, чтобы закатав рукава погружаться в обсуждение насущных вопросов, руководитель передает инициативу сотрудникам: «Думайте сами. Жду от вас проекты решений на утверждение».<\/p>\n При этом результаты инициативы сотрудников рассматриваются публично<\/i> и торжественно на общем собрании.<\/p>\n Если кто-то пришел неготовый — это видно.<\/p>\n Если на совещании возникают споры — руководитель говорит: «Так, ребят, вы не готовы, идите договаривайтесь».<\/p>\n Очень не хочется облажаться на таком совещании.<\/p>\n Признаться, мне было сложно на словах убедить заказчика, что это сработает. Благо, у меня был большой кредит доверия, и мы попробовали. Но уже после пары совещаний сила этого приема стала очевидна всем.<\/p>\n Вспоминаю аналогичный процесс подготовки к ежемесячному совещанию с Губернатором одного из регионов, который мы настраивали.<\/p>\n Подготовка занимала около полутора недель, в ходе которых директора департаментов анализировали ситуацию по проектам, вырабатывали меры реагирования на отклонения от планов и договаривались между собой, кому от кого что нужно, чтобы в торжественной обстановке под телекамерами доложить Губернатору.<\/p>\n Губернатор тратил на эти совещания один час в месяц. Но ради этого часа проделывался целый вагон работы.<\/p>\n Чтобы это заработало, надо соблюдать несколько условий<\/b><\/p>\n Четкие правила подготовки.<\/i> За какое время до начала направлять материалы, кому, какие обязательные согласования и т. п.<\/p>\n Правила эскалации.<\/i> Какие проблемы сотрудники решают сами, какие — выносят на совещание.<\/p>\n Требования к выносимым материалам.<\/i> Шаблоны управленческой отчетности, типовые слайды и пр.<\/p>\n Ответственный за качество процесса подготовки.<\/i> Например, проектный офис.<\/p>\n Ответственный за прозрачность.<\/i> Чтобы никакие детали не смягчили и не обошли в процессе «договаривания», часто нужна третья, независимая сторона, которая проверяет достоверность данных.<\/p>\n",
"date_published": "2023-05-23T13:40:59+00:00",
"date_modified": "2023-05-23T13:40:50+00:00",
"_date_published_rfc2822": "Tue, 23 May 2023 13:40:59 +0000",
"_rss_guid_is_permalink": "false",
"_rss_guid": "121",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "120",
"url": "https:\/\/blog.skalon.me\/all\/starayas-podkrepit-svoy-avtoritet-mozhno-ego-podorvat-izbegayte\/",
"title": "Стараясь подкрепить свой авторитет можно его подорвать. Избегайте этого приема",
"content_html": " Есть такой прием, когда надо заставить кого-то что-то сделать: сослаться на требования третьего, более авторитетного лица. Например: «Вася, тут Петр Семенович мне звонил вчера вечером. Ему прям приспичило получить вот такой-то результат. Можешь сделать <то-то>?»<\/p>\n Это очень типичный метод, и я хотел бы на его примере поговорить о том, где пролегают психологические «границы» менеджерской роли.<\/p>\n Пример, когда этот прием уместен<\/b><\/p>\n Мы с коллегой делали проект для гос.заказчика: сформировать портфель мероприятий по улучшению инвест. климата региона. Задача была — организовать большое количество гос.органов (региональных департаментов), чтобы они придумали мероприятия, а затем — реализовали их. При этом было важно, чтобы они делали все именно таким образом, как это придумали мы, без лишней самодеятельности.<\/p>\n Мы выступали от имени Департамента проектного управления — довольно новой сущности, которая еще не завоевала авторитет.<\/p>\n Мой шеф заходил с такой легендой:<\/p>\n Это, с одной стороны, создавало «горящую платформу» (еще один прикольный прием управления изменениями), с другой — превращало нас из каких-то не в меру инициативных ребят в спасителей положения, в котором все оказались.<\/p>\n Пример, когда валить на третью сторону неуместно<\/b><\/p>\n Был у меня руководитель — милейший человек, на первый взгляд. Интеллигентный, противник любых форм агрессии. По его собственному признанию — главное для него на работе, чтобы со всеми были хорошие отношения.<\/p>\n К сожалению, избегание конфликтов приводило к тому, что руководитель боялся давать мне обратную связь и даже ставить поручения. Я был достаточно автономным сотрудником и работал напрямую с кураторами своих проектов, поэтому мой руководитель мог неделями со мной не общаться.<\/p>\n Когда же все-таки ему приходилось мне поставить задачу, он неизменно прибегал к этой манере, дескать «меня шеф попросил, это все он, я-то что, я-то ничего».<\/p>\n Признаться, это бесило. Какого хрена? Ты — мой шеф, скажи прямо, что нужно.<\/p>\n Вместо этого у меня было ощущение, что меня пытаются переиграть в какие-то невидимые шахматы. Это создавало токсичную атмосферу пассивной агрессии, и было одним из важных факторов, повлиявших на мое решение об уходе из компании.<\/p>\n Что делать, если мне все-таки боязно ставить поручения?<\/b><\/p>\n Знаю по своему опыту, бывает. Как человеку, который не очень комфортно себя чувствовал в конфликте, первое время мне было тяжеловато ставить поручения. Постоянно было ощущение, что меня могут оспорить, и случится конфуз<\/i>. А что если человек не выполнит мое поручение? Вот неловко-то будет.<\/i><\/p>\n Поэтому я и сам прибегал к методу «я-то что, я-то ничего, это все он», чтобы как-то придать веса своим словам. Пока в один прекрасный момент не поймал себя на этом с удивлением: «Так, чувак, а что за дела? Ты ведь не носки свои просишь постирать».<\/p>\n Одно дело, когда я «стою рядом», и мне надо что-то от людей, которые скорее всего меня пошлют. Тут действительно можно добавить веса своим словам (это не единственный метод, замечу кстати).<\/p>\n Другое дело, когда я — руководитель. Ставить задачи — моя работа. Пытаться подкрепить свой авторитет ссылками на третьих лиц — дискредитация своей собственной роли.<\/p>\n На практике выяснилось, что сотрудники довольно редко челленджат меня. Когда это все-таки происходило, на помощь мне приходила моя конфликтная стратегия:<\/p>\n Это важный принцип, который помогает руководить людьми «сделывать дела» с минимальным уровнем агрессии и стресса, как с вашей, так и с их стороны (на самом деле, просто по жизни тоже очень хорошо помогает)<\/p>\n «Никто не мудак» подразумевает, что люди редко делают что-то со зла.<\/p>\n В основном, люди делают то, что делают, руководствуясь какими-то позитивными намерениями<\/b><\/p>\n Это означает, что если сотрудники делают что-то неприятное и неправильное, надо сначала разобраться, почему. Вероятнее всего, они не замотивированы, у них был какой-то негативный опыт, который вызвал такую реакцию.<\/p>\n Если на этом принципе строить взаимодействие, оно становится гораздо более комфортным и дружелюбным. Меньше стресса и «войнушки».<\/p>\n Если люди по умолчанию плохие, вам приходится либо пытаться их переделать (бесплодная трата сил), либо тратить невероятные усилия на контроль и страховки от мудаков, которые все хотят сломать.<\/p>\n Если мы вспоминаем, что никто не мудак, это позволяет искать решение проблемы вместе с человеком.<\/p>\n Примеры<\/b><\/p>\n Вы проводите ретроспективу<\/a>, обсуждаете проблемы процесса. Все работали на общие цели, но подвел неэффективный процесс. Никто не мудак, ребят, все хорошо, расслабились, вместе думаем над улучшением процесса.<\/p>\n Сотрудник что-то не делает. Вспоминаем: никто не мудак. Начинаем разбираться: почему нормальный человек, руководствующийся позитивными намерениями, ведет себя так неэффективно? А почему бы нам не пообщаться доверительно ван он ван<\/a>?<\/p>\n Партнер говорит, что не хочет идти вместе в новый проект, на который вы так рассчитывали. Хочется наорать на него. Вспоминаем: никто не мудак. Вероятно, у него есть какие-то ограничения, опасения. Включаем уважительное обсуждение: давай вместе подумаем, как нам решить задачу таким образом, чтобы прийти к наилучшему обоюдному результату с учетом имеющихся у нас ограничений<\/a>?<\/p>\n Важно: это не про кота Леопольда<\/b><\/p>\n Бывают люди, позитивные намерения которых направлены в сторону противоположную от ваших, и вам с ними не по пути. Бывают люди, которые очень стараются, но не тянут. Я вовсе не предлагаю вам со всеми христосоваться и во что бы то ни стало входить в положение. У каждого свои цели, бизнес есть бизнес.<\/p>\n Просто в следующий раз, перед тем, как принять какие-то решительные меры по борьбе с очередным мудаком, попробуйте задать себе вопрос: какие могут быть объективные и позитивные причины для его поведения?<\/p>\n",
"date_published": "2023-05-23T13:27:49+00:00",
"date_modified": "2023-05-23T13:27:45+00:00",
"_date_published_rfc2822": "Tue, 23 May 2023 13:27:49 +0000",
"_rss_guid_is_permalink": "false",
"_rss_guid": "119",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "118",
"url": "https:\/\/blog.skalon.me\/all\/snizit-stress-i-soprotivlenie-za-schet-izmeneniya-otnosheniya-pr\/",
"title": "Снизить стресс и сопротивление за счет изменения отношения — простой прием, используемый профессиональными консультантами",
"content_html": " Однажды я принимал участие в тренинге по прокачке социальных навыков, который подразумевал общение со случайными людьми на улицах. Тема общения могла быть в том числе довольно дурацкой или провокационной, и от общения надо было получить определенные результаты.<\/p>\n Тренинг проходил в небольшом городке, и когда 30 участников разбрелись по небольшому центру, была велика вероятность, что, подойдя к очередному человеку со своим дурацким запросом, я буду не первым, и меня встретят готовым отпором. Очень неприятная мысль, которая мне мешала приступить собственно к упражнению.<\/p>\n Я подошел к своему «куратору обучения» (один из команды организаторов, который давал обратную связь и поддержку в ходе полевых упражнений) и пожаловался на сложившуюся ситуацию. Его ответ я запомнил, и повторял с тех пор добрую сотню раз:<\/p>\n «Ну да, ты прав: задача усложнилась. Ну и что? Ты рассчитывал пройти этот уровень на easy, а оказался nightmare, но это все та же игра, просто сложнее»<\/p>\n Удивительно, но эта простая мысль переключила меня из режима «уу-у-у-у, все так плохо и несправедливо» в режим азартного поиска решения.<\/p>\n «Тест апельсинового сока» от Дж. Вайнберга<\/b><\/p>\n Есть отличная, очень афористичная книга про консалтинг от Джерри Вайнберга, в русском переводе называется «Закон малинового варенья». Она написана в формате притч\/баек, и чаще всего я вспоминаю одну, под называнием «Тест апельсинового сока».<\/p>\n Представьте, что вы — менеджер отеля, и к вам обратился заказчик со следующей просьбой.<\/p>\n Он хочет организовать ежегодный слет сотрудников своей компании на 700 человек.<\/p>\n По устоявшейся традиции они завтракают тостами, и ровно в 7:00 основатель произносит напутствие, под которое все 700 человек должны чокнуться большими бокалами свежевыжатого апельсинового сока.<\/p>\n Любой, кто представляет себе организацию мероприятий, понимает, что это весьма сложная логистическая задача: мало того, что надо организовать визит и размещение 700 человек, так еще и завтрак тостами, отжим 700 порций сока в такие сроки, чтобы он оставался свежевыжатым ровно к 7:00...<\/p>\n Звучит как кошмар для организатора.<\/p>\n В притче Вайнберга менеджеры отелей делятся на три категории:<\/p>\n Только третий вариант — подход настоящего профессионала.<\/p>\n Да, заказчик может счесть не целесообразным тратить на организацию ивента те деньги, которые с него запросят, но это уже совершенно другой вопрос, который он способен решить сам.<\/p>\n Сложно ≠ невозможно<\/b><\/p>\n Внедряя новый процесс, решая сложную задачу, я много раз наталкивался на сопротивление: «Это невозможно» — со стороны сотрудников.<\/p>\n По моим наблюдениям, находясь в ощущении «это невозможно» люди с большей вероятностью переходят в режим обороняющегося сопротивления: нет почвы для сотрудничества, нет обсуждения, только защита от опасной и вредной идеи.<\/p>\n Переключение в режим «это просто повышенный уровень сложности» сразу же дает пищу для брейнсторма, творчества, совместного решения.<\/p>\n Более того: когда вы решаете творческую задачу, стресса становится гораздо меньше, чем когда вы сопротивляетесь абсурдной и невозможной прихоти.<\/p>\n",
"date_published": "2023-05-23T13:23:18+00:00",
"date_modified": "2023-05-23T13:23:09+00:00",
"_date_published_rfc2822": "Tue, 23 May 2023 13:23:18 +0000",
"_rss_guid_is_permalink": "false",
"_rss_guid": "118",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "117",
"url": "https:\/\/blog.skalon.me\/all\/ne-poluchaetsya-vnedrit-privychku-neuzheli-ya-luzer\/",
"title": "Не получается внедрить привычку. Неужели я лузер?!",
"content_html": " Когда вы внедряете какую-то привычку или новый процесс, очень редко бывает так, что внедрение удается безупречно с первого раза.<\/p>\n Например, вы начали делать зарядку\/ходить в спортзал\/медитировать, и все шло прекрасно на протяжении двух недель\/месяцев. Но в один прекрасный день что-то вам помешало, и вы не сделали очередную зарядку. И вдруг из-за одного пропуска ваша привычка накрывается медным тазом: вы не можете себя заставить делать зарядку, и даже непонятно, как получалось в предыдущие два месяца.<\/p>\n Одна из ключевых причин отката в такой ситуации — чувство вины и разочарования, которое вы испытываете из-за срыва.<\/b><\/p>\n Вы думаете о зарядке и испытываете стыд, ругаете себя безвольной тряпкой за то, что не справились с задачей.<\/p>\n Вам и так трудно было себя заставить, а теперь у вас «в эмоциональной карте» соседствуют зарядка и чувство вины. И простое казалось бы действие обременено дополнительным отторжением: кому приятно, когда его называют тряпкой и ленивой задницей?<\/p>\n Этот стресс вызывает желание отвлечься<\/a>, компенсировать его чем-то приятным: заесть, посмотреть видосик и т. д.<\/p>\n Чтобы откат не превратился в окончательный отказ, помогает взглянуть на ситуацию с другой стороны.<\/b><\/p>\n Очень похожая история при внедрении организационных изменений.<\/b><\/p>\n При переходе на новый процесс, важна атмосфера принятия и поддержки для тех, кто добросовестно старается, но у него не получается. Сотрудники неправильно заполняют новые документы? Помочь, а не ругать. Сроки по новому процессу нарушаются? Все хорошо, мы этого ожидали. Давайте проанализируем, что произошло, и извлечем из этого уроки.<\/p>\n Резкая реакция должна быть только в отношении тех, кто злонамеренно саботирует внедрение. И то: сначала надо убедиться в злонамеренности и дать шанс исправиться<\/a>.<\/p>\n",
"date_published": "2023-05-23T13:21:47+00:00",
"date_modified": "2023-05-23T13:21:22+00:00",
"_date_published_rfc2822": "Tue, 23 May 2023 13:21:47 +0000",
"_rss_guid_is_permalink": "false",
"_rss_guid": "117",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "116",
"url": "https:\/\/blog.skalon.me\/all\/pochemu-ne-vsegda-polezno-pobezhdat-v-peregovorah\/",
"title": "Почему не всегда полезно побеждать в переговорах",
"content_html": " Есть такая технология, очень полезная для менеджеров и переговорщиков: «Управленческие поединки» (УП).<\/p>\n Вам с оппонентом дают кейс, роли в этом кейсе, и вы вступаете в поединок, чтобы достигнуть целей.<\/p>\n Например, спор двух партнеров по бизнесу. Один больше участвует в операционке, чем другой, и хочет за это большую долю прибыли. Второй считает иначе, потому что (...какие-то разумные аргументы). Вам достается роль одного из партнеров, и вы должны топить за свое. Затем меняетесь ролями.<\/p>\n Судьи оценивают переговоры с нескольких позиций: «Доверил бы я свою собственность такому человеку?», «Пошел бы я работать к такому человеку?» и «Направил бы я такого человека на переговоры?».<\/p>\n Почитать подробнее можно здесь<\/a>.<\/p>\n Крутая технология. Реально работает. Прокачанным в ней людям палец в рот не клади.<\/p>\n Однако я сталкивался и с ситуациями, когда владение УП человека подводило.<\/p>\n Всегда ли полезно побеждать в переговорах?<\/b><\/p>\n Представим себе ситуацию: вы — исполнитель по проекту, и пользуетесь технологиями УП, чтобы отбить замечания заказчика. На любые его аргументы вы отвечаете так ловко, что он разводит руками и соглашается: да, мол, крыть нечем. Вы отбили замечания, подписали акты и сэкономили свой бюджет.<\/p>\n Но — удивительно — заказчик почему-то не горит покупать у вас новый проект. Почему?<\/p>\n Есть не только «победил\/проиграл», но и «прав\/не прав»<\/b><\/p>\n Возможно, заказчик действительно напридумывал какой-то фигни, которая принесла бы ему ноль пользы. Но в обсуждении замечаний он ожидал от вас больше заботы. А натолкнулся на жесткий отпор, причем он еще и почувствовал, что его по щекам отхлестали.<\/p>\n На мой взгляд, умение побеждать в УП — это примерно как драться. Если вы — мастер спорта по джиу-джитсу, вы сможете отмудохать в лоскуты примерно любого оппонента, который встретился вам в жизни.<\/p>\n Однако героем вы станете только в том случае, если оппонент был преступником, угрожал вам или вашим близким. Если же вы наброситесь с кулаками и болевыми приемами на заказчика — преступник это вы.<\/p>\n Так и в переговорах: если вас хотят «притопить» на совещании в большой корпорации, где идет битва за ресурсы — надо уметь отбиться, причем желательно так, чтобы больше попыток не возникало.<\/p>\n Если же вы неправы «по понятиям» (например, не слышите заказчика), вы можете сколько угодно «побеждать» в переговорах, но это только приведет к разрушению отношений.<\/p>\n Конечно, можно сказать, что это неправильное применение технологии, раз оно приводит к таким результатам.<\/p>\n Но я хочу подчеркнуть, что есть более глубокий слой, про который легко забыть — правильно или не правильно «по понятиям».<\/p>\n Необходим прочный этический фундамент<\/b><\/p>\n Я уже излагал в блоге свою конфликтную стратегию.<\/p>\n Суть ее в том, чтобы вести переговоры с этически-безупречной позиции:<\/p>\n Эта позиция правильная «по понятиям», и она безопасна в применении. Простое следование ей закрывает 95% всех переговорных ситуаций в обычной среде: в командной работе редко возникают ситуации, когда надо драться (не говорю сейчас про токсичные корпорации).<\/p>\n Никоим образом не хочу попрать, или хоть как-то присоседиться к авторитету Владимира Тарасова, который изобрел технологию управленческих поединков, структурировал и превратил в дисциплину.<\/p>\n Книги Владимира Тарасова — бесконечный источник управленческой и житейской мудрости.<\/p>\n Опыт поединков поможет вам не только в оставшихся 5% жестких конфликтных ситуаций, но и просто быстрее соображать в конфликте.<\/p>\n Но каждый раз, собираясь восторжествовать над оппонентом, задайте себе вопрос, на какой стороне вы находитесь с точки зрения справедливости.<\/p>\n",
"date_published": "2023-05-23T13:15:55+00:00",
"date_modified": "2023-05-23T13:15:11+00:00",
"_date_published_rfc2822": "Tue, 23 May 2023 13:15:55 +0000",
"_rss_guid_is_permalink": "false",
"_rss_guid": "116",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "115",
"url": "https:\/\/blog.skalon.me\/all\/instrument-mentalnoy-gigieny-bez-kotorogo-vy-obrecheny-tratit-si\/",
"title": "Инструмент ментальной гигиены, без которого вы обречены тратить силы, время и деньги",
"content_html": " Большинство людей интуитивно неправильно формулируют проблемы.<\/p>\n На первый взгляд, это может показаться пустяком, но я уверен, что бизнес теряет невероятное количество денег и ресурсов, решая неправильно сформулированные проблемы. В проектном управлении я сталкиваюсь с этим сплошь и рядом.<\/p>\n Проблема ≠ отсутствие решения<\/b><\/p>\n Классическая ошибка — формулировать проблему через отсутствие решения.<\/p>\n Для примера возьмем проект внедрения системы контроля поручений (СКП) руководителя. В паспорте проекта неопытный менеджер может описать проблему так:<\/p>\n «Отсутствует система контроля поручений»<\/p>\n Не видите здесь ничего странного? Давайте позадаем дополнительные вопросы:<\/p>\n Все они остаются без ответа.<\/p>\n Теперь попробуем сформулировать иначе.<\/p>\n Вот тут уже понятно, что секретари не справляются, и потери большие.<\/p>\n В первом случае под проблему замаскировалось конкретное решение, а причины, по которым оно вообще потребовалось, были скрыты.<\/p>\n Во втором случае мы указали, что мы решаем, — то есть, конкретные проблемы, — чтобы предложить решение: систему контроля поручений.<\/p>\n Это не спор об определениях, а очень практичный вопрос<\/b><\/p>\n Кто-то может даже сказать: «А для меня именно отсутствие СКП проблема!»<\/p>\n На это можно ответить, что спор о том, что считать проблемой, не лингвистический, а прагматический.<\/p>\n В бизнес-обстоятельствах проблема — это что-то, что мешает достижению целей. Цель бизнеса — зарабатывать деньги сейчас и в будущем. С ней связаны все остальные цели — подразделения, проекта, сотрудника и т. д.<\/p>\n Из правильной формулировки проблемы должно быть понятно, желательно — без дополнительных пояснений, как она мешает достижению целей.<\/p>\n Вот два прагматичных следствия из правильной формулировки проблемы:<\/p>\n В нашем примере менеджер мог обнаружить, что проблемы-то собственно и нет. Например, у нас маленькая команда, все мотивированные как черти, и без всяких поручений просто рвут и мечут.<\/p>\n Какие есть альтернативные способы внедрения СКП? Только разные варианты СКП.<\/p>\n Посмотрев внимательно на правильные проблемы, мы можем найти и другие подходы. Например, предложить секретарям какую-то компенсацию испытываемых неудобств и обучить их более деликатно запрашивать статус с менеджеров. Это может оказаться сильно дешевле и принести другие полезные плоды.<\/p>\n Как формулировать проблемы правильно?<\/b><\/p>\n Помогает проверочный вопрос: «Чем это плохо?» Задавайте его, пока он не начнет звучать совсем уж по-идиотски. Чаще всего, это происходит, когда доходит до денег. Обычно понятно, чем плохо, если мы теряем 10 млн в месяц.<\/p>\n Тем не менее, рекомендую и в «идиотских» ситуациях себя преодолеть и спросить еще пару раз. Бывает, открываются новые бездны.<\/p>\n Я привел одну из наиболее типичных ошибок, но есть и другие. Например, когда проблема звучит как обвинение (мешает трезвому обсуждению), или когда это проблема уровня «у нас хреновые законы» (обычно не решаема в рамках компании, поэтому бесполезна) и т. д.<\/p>\n Чтобы лучше разобраться, почитайте про «критерии проверки логических построений» и «правила формулировки нежелательных явлений» в теории ограничений систем.<\/p>\n Там еще выше уровень методологической чистоты формулировок. По опыту, не всегда практично достигать именно этого уровня, но изучение принципов очень помогает ясности мышления.<\/p>\n",
"date_published": "2023-05-17T12:11:54+00:00",
"date_modified": "2023-05-17T12:11:40+00:00",
"_date_published_rfc2822": "Wed, 17 May 2023 12:11:54 +0000",
"_rss_guid_is_permalink": "false",
"_rss_guid": "115",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "114",
"url": "https:\/\/blog.skalon.me\/2023\/05\/17\/6\/",
"title": ".",
"content_html": " Последнее время часто встречаю полярные высказывания на тему того, сколько часов в сутки, как интенсивно и с какой самоотдачей нужно работать.<\/p>\n С одной стороны — голоса трудоголиков и достигаторов, которые цитируют известного бизнесмена: «Любой бизнес хорош, если ты работаешь 16 часов в день».<\/p>\n С другой — сторонники ворк-лайф баланса, раннего ухода на пенсию и т. п.<\/p>\n Как трудоголик в ремиссии, внесу свои пять копеек.<\/p>\n Работа — одна из основных сфер жизни<\/b><\/p>\n Работа сыграла в моей жизни характерообразующую роль<\/a>, помогла прокачать «душевные мускулы», раскрыть свой потенциал и приносить пользу миру.<\/p>\n Чиллить с пивком и смотреть сериалы днями напролет — очевидно не лучшая стратегия, если вы хотите добиться результатов, которые принесут свободу и удовлетворение.<\/p>\n Но при этом,<\/p>\n Трудоголизм — это обратная сторона прокрастинации<\/b><\/p>\n Топливо для трудоголизма, перфекционизма и прокрастинации — нездоровое отношение к работе и к самому себе:<\/p>\n «Мне уже 25, а миллионером я планировал стать в 21<\/a>»<\/p>\n «Я такой крутой, что не могу позволить себе сделать что-то не безупречно»<\/p>\n «Сейчас я как следует все спланирую, чтобы сделать безупречно с первого раза»<\/p>\n Обычно трудоголизм — плохая стратегия при забеге на дистанцию<\/a>. Можно потерять гораздо больше, чем заработать.<\/p>\n Если завалить себя важными и срочными текущими задачами, может не остаться «мыслетоплива», чтобы посмотреть на свою жизнь с отдаления. Одни из лучших осознаний приходили мне на вторую неделю отпуска.<\/p>\n Более того, работа хоть и важная сфера жизни, но не единственная. Если вдруг с ней что-то происходит, хорошо бы иметь на что опереться — друзья, семья, творчество и т. п.<\/p>\n Отказ от трудоголизма запускает цикл положительной обратной связи<\/b><\/p>\n Интересно, что в качестве одной из первых мер по борьбе с прокрастинацией специалисты предлагают запланировать отдых и другие нерабочие активности. Я проверил это на практике.<\/p>\n Последние годы я осознанно ограничиваю свой объем работы. Не работаю на выходных, стараюсь не работать больше 8 часов в день, не думать о работе в нерабочее время.<\/p>\n Это помогает радикально снизить проблему прокрастинации, и в отведенное время работать качественно и включенно. Мне по кайфу начинать рабочую неделю в понедельник, стартовать рабочий день вовремя и плотно работать по таймеру<\/a>.<\/p>\n И я по большей части доволен тем объемом дел, который я успеваю переделать. Иногда, конечно, подмывает поднажать, но вместо того, чтобы больше работать, я стараюсь иначе организовать процесс или выполнить в имеющееся время не все задачи, а наиболее ценные.<\/p>\n Время вне работы тоже можно провести по-разному. Когда я вкалывал по 60+ часов в неделю, у меня оставались силы только для того, чтобы потупить в компьютерную игру или ютубчик, а на выходных, когда они были, лежать пузом кверху.<\/p>\n Сейчас я не так вымотан, и в свободное от работы время могу заниматься чем-то более ценным и полезным: учиться музыке, слушать аудиокниги, заниматься спортом, писать.<\/p>\n Как выясняется, если начать с ограничения рабочего времени, не только возрастает качество жизни, но и результативность не особо снижается за счет того, что у меня больше сил на улучшение своих процессов.<\/p>\n Вместо «достигаторства» — тратить время осознанно<\/b><\/p>\n Чтобы унять достигаторский зуд («я еще не все достижения достиг, надо поднажать»), я сформулировал для себя принцип:<\/p>\n «Я трачу время осознанно»<\/p>\n Когда я работаю, я отдаю себе отчет, над чем я работаю и зачем. Какой результат это мне дает, как продвигает к целям.<\/p>\n Когда я отдыхаю, я тоже понимаю, на что трачу время. Слушаю много аудиокниг, гуляю и пр. Но иногда позволяю себе и залипнуть в фильм или даже сериальчик, потому что не каждая минутка обязана быть продуктивной и развивающей. Так как сериалы и фильмы я смотрю довольно редко, я выбираю максимально качественные, и мой «уровень кайфа в единицу времени» растет.<\/p>\n Это дает мне уверенность в том, что если я не работаю как проклятый, это не значит, что я не развиваюсь и не становлюсь лучшей версией себя. Наоборот, я становлюсь более разносторонним и сбалансированным.<\/p>\n",
"date_published": "2023-05-17T12:10:09+00:00",
"date_modified": "2023-05-17T12:10:00+00:00",
"_date_published_rfc2822": "Wed, 17 May 2023 12:10:09 +0000",
"_rss_guid_is_permalink": "false",
"_rss_guid": "114",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "113",
"url": "https:\/\/blog.skalon.me\/2023\/05\/17\/5\/",
"title": ".",
"content_html": " Кто хоть раз внедрял в компании таск-трекер или систему управления проектами с вероятностью 90% знает на практике, что значит «система не взлетела»:<\/p>\n Я знаю, я был там.<\/p>\n Теперь, внедряя такие штуки, я пользуюсь отличным показателем, который говорит, жива ли наша система управления:<\/p>\n Количество задач, по которым прогнозный срок находится в прошлом.<\/b><\/p>\n Давайте разберемся, что означает этот показатель?<\/p>\n Прогнозный срок<\/a> — это сообщение исполнителя руководителю. Ситуация, когда по активной задаче прогнозный срок находится в прошлом, возможна только в одном случае:<\/p>\n Исполнитель не обновил либо прогноз по срокам, либо статус задачи, т. е. забил на коммуникацию.<\/p>\n Почему это так важно?<\/b><\/p>\n Система управления нужна для того, чтобы облегчать принятие решений. Руководитель смотрит на задачи проекта и понимает, где отставание, какие проблемы, где ресурсов добавить и т. п.<\/p>\n А теперь давайте представим, что какой-то неизвестный процент задач в этой системе показывает ошибочную информацию.<\/p>\n Это бесповоротно подрывает доверие к системе.<\/i><\/p>\n Руководителю приходится переходить в ручной режим: звонить исполнителям, вместо того, чтобы пользоваться дашбордом. Держать все в голове. Вести заметки в своем собственном эксельчике.<\/p>\n Иными словами, система становится бесполезной.<\/p>\n Что делать?<\/b><\/p>\n Когда сотрудники нарушают сроки, не сделывают цели, заваливают проекты — я рекомендую проявлять максимум терпения и принятия (если конечно это не злостный игнор правил и нарушение договоренностей<\/a>). Обычно человек сам не рад<\/a>, что завалил проект.<\/p>\n Но я совершенно непреклонен в вопросах соблюдения правил и поддержания коммуникации. Потому что малейшая слабина в этом вопросе подрывает весь процесс, который ведет команду к успеху.<\/p>\n Поэтому когда я настраиваю дашборды для проведения планерок, я на самом верху размещаю красный виджет «Не обновленные задачи», и завожу правило: «Ребята, если на момент начала планерки здесь есть хоть одна задача, будем ругаться».<\/p>\n Приятные и важные следствия<\/b><\/p>\n Постоянный мониторинг этой простой и однозначной метрики приводит к тому, что люди вынуждены актуализировать статусы и сроки, подавать запросы о переносе срока... то есть, появляется та самая управляемость и прозрачность<\/a>, ради которой вы загнали всех в систему.<\/p>\n Да, конечно, первое время люди будут обновлять задачи, которые почти «протухли», и делать это только перед планеркой. Но обычно работа в системе постепенно входит в привычку, и, при должной настойчивости менеджера, команда начинает общаться через таск-трекер. А это уже позволяет реально контролировать процесс, радикально сократить время на планерки и т. п., о чем я уже много писал (например, здесь<\/a> и здесь<\/a>).<\/p>\n",
"date_published": "2023-05-17T12:02:58+00:00",
"date_modified": "2023-05-17T12:02:16+00:00",
"_date_published_rfc2822": "Wed, 17 May 2023 12:02:58 +0000",
"_rss_guid_is_permalink": "false",
"_rss_guid": "113",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "112",
"url": "https:\/\/blog.skalon.me\/2023\/05\/17\/4\/",
"title": ".",
"content_html": " Часто в околобизнесовых кругах можно слышать про проекты внедрения\/трансформации корпоративной культуры и\/или внедрения ценностей.<\/p>\n Звучит круто. Сотни сотрудников корпорации, объединенные в едином порыве строят значимый бизнес. При этом мотивированы они не зарплатой, а чувством принадлежности и смыслом, который дает им работа.<\/p>\n И примеры сильных корпоративных культур у всех на слуху.<\/p>\n Однако мне вспоминается фраза, которую сказал операционный директор одного очень большого и серьезного заказчика, для которого мы делали проект:<\/p>\n «Я считаю бесполезно внедрять корпоративную культуру саму по себе. Потому что корпоративная культура — это следствие того, что и как мы делаем»<\/b><\/p>\n К сожалению, некоторые руководители считают, что достаточно повесить на стене в офисе плакат: «Наша ценность — развитие!» — и народ вовлечется и не пойдет просить повышения зарплаты в следующий раз.<\/p>\n Есть отличный прием из практик по управлению изменениями.<\/p>\n Как в игре «Крокодил»: топ-руководитель не говорит об изменениях, а показывает конкретными действиями.<\/p>\n Например, у нас диджитализация? Пусть смотрит отчеты на айпаде, а не распечатанные на бумажке.<\/p>\n Внедряем ценность «Результатоориентированность»? Запустите внедрение ОКР.<\/p>\n",
"date_published": "2023-05-17T11:54:43+00:00",
"date_modified": "2023-05-17T11:54:29+00:00",
"_date_published_rfc2822": "Wed, 17 May 2023 11:54:43 +0000",
"_rss_guid_is_permalink": "false",
"_rss_guid": "112",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
},
{
"id": "111",
"url": "https:\/\/blog.skalon.me\/2023\/05\/17\/3\/",
"title": ".",
"content_html": " Часто слышу от менеджеров примерно следующие слова:<\/p>\n «Вася, сорри, что тебя динамлю, но руководство не выделяет мне ресурсы, поэтому...»<\/p>\n И дальше идет:<\/p>\n «...я не могу заниматься твоим проектом»,<\/p>\n «...у меня нет заместителя и я все завязал на себя»,<\/p>\n «...мы завалены делами и факапим задачи».<\/p>\n По этому поводу я могу только повторить слова моего старшего товарища и наставника:<\/p>\n «Один из основных скиллов менеджера — уметь выбить ресурсы»<\/b><\/p>\n Приведу пример как это можно сделать из своего опыта.<\/p>\n Член моей команды — директор департамента — был очень завален и злостно фачил задачки<\/a>. Когда мне надоело стоять у него над душой и я понял, что надо что-то системно менять, я пришел к нему со словами: «Дорогой Коля (имя изменено), я вижу, вы с ребятами завалены. Давай я помогу тебе правильно донести эту ситуацию до руководства. Для нашего проекта это большой риск, я не могу стоять в стороне».<\/p>\n После чего я сел с ним рядом на табуреточку и мы вместе заполнили таблицу: текущие проекты на подразделении, оценка трудозатрат с обоснованием, объем непроектных задач с примерами и категориями и т. п.<\/p>\n (См. скрин ниже)<\/p>\n В общем, я показал на данных, что объем обязательств, возложенных на подразделение, не реалистичен.<\/p>\n В нижней строке на скриншоте вы можете увидеть почти двукратное превышение доступного объема трудозатрат.<\/p>\n В результате мы согласовали бюджет на консультантов, которые сняли с подразделения часть задач по моим проектам.<\/p>\n Важно добавить.<\/p>\n Часто руководство режет ФОТ\/штат прямо требуя или косвенно подразумевая, что руководители должны оптимизировать процессы. Это не всегда реалистичные ожидания, т. к. из-за сокращения штата количество текучки на сотрудника увеличивается, что не располагает к тому, чтобы заниматься задачами оптимизации.<\/p>\n Тем не менее, неся руководству аналитику по доступному объему ресурсов, не забудьте указать, какие меры по оптимизации рабочего процесса вы уже приняли и какой был\/ожидается от них эффект.<\/p>\n",
"date_published": "2023-05-17T11:53:44+00:00",
"date_modified": "2023-05-17T11:53:35+00:00",
"image": "https:\/\/blog.skalon.me\/pictures\/2023-05-17-19.52.38.jpg",
"_date_published_rfc2822": "Wed, 17 May 2023 11:53:44 +0000",
"_rss_guid_is_permalink": "false",
"_rss_guid": "111",
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": [
"https:\/\/blog.skalon.me\/pictures\/2023-05-17-19.52.38.jpg"
]
}
},
{
"id": "110",
"url": "https:\/\/blog.skalon.me\/2023\/05\/17\/2\/",
"title": ".",
"content_html": " Сегодня делюсь отличным материалом, который я пересылал добрую сотню раз. Я отправлял его каждому начинающему руководителю проектов (и не только).<\/p>\n Что значит «сделать»?<\/a><\/p>\n Я прочитал этот коротенький пост в 2014-м году и меня как громом разразило. Это был один из первых материалов, который лег в основу моего сегодняшнего представления о командной работе.<\/p>\n Речь в нем идет о том, что такое ответственность и что такое настоящая результатоориентированность.<\/p>\n Автор — Николай Товеровский. Кстати мой коллега, руководитель проектов и тренер. У него вокруг принципа «сделывания» целая методология построена. Есть книга<\/a> и тренинг<\/a> по управлению проектами в Школе менеджеров Бюро Горбунова.<\/p>\n\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
![\"\"](\"https:\/\/blog.skalon.me\/pictures\/2023-05-17-19.52.38.jpg\")
\n<\/div>\n