<?xml version="1.0" encoding="utf-8"?> 
<rss version="2.0"
  xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
  xmlns:atom="http://www.w3.org/2005/Atom">

<channel>

<title>Скалон о менеджменте: заметки с тегом внедрение</title>
<link>https://blog.skalon.me/tags/vnedrenie/</link>
<description>Блог о менеджменте, способствующем раскрытию человеческого потенциала</description>
<author>Василий Скалон</author>
<language>ru</language>
<generator>E2 (v3572; Aegea)</generator>

<itunes:owner>
<itunes:name>Василий Скалон</itunes:name>
<itunes:email></itunes:email>
</itunes:owner>
<itunes:subtitle>Блог о менеджменте, способствующем раскрытию человеческого потенциала</itunes:subtitle>
<itunes:image href="" />
<itunes:explicit></itunes:explicit>

<item>
<title>Можно обижаться, можно использовать — как работать с хинсайтом (и что это такое)</title>
<guid isPermaLink="false">124</guid>
<link>https://blog.skalon.me/all/mozhno-obizhatsya-mozhno-ispolzovat-kak-rabotat-s-hinsaytom-i-ch/</link>
<pubDate>Tue, 23 May 2023 13:53:47 +0000</pubDate>
<author>Василий Скалон</author>
<comments>https://blog.skalon.me/all/mozhno-obizhatsya-mozhno-ispolzovat-kak-rabotat-s-hinsaytom-i-ch/</comments>
<description>
&lt;p&gt;Когда я презентую заказчику рекомендации по улучшению процессов, я часто слышу в ответ:&lt;/p&gt;
&lt;p&gt;«А, ну это само собой разумеется» или «Да, да, ровно это я и собирался сделать». А порой даже: «Да-да, мы так и работаем»&lt;/p&gt;
&lt;p&gt;При этом очевидно, результатов это «мы так и работаем» не приносит.&lt;/p&gt;
&lt;p&gt;Например:&lt;/p&gt;
&lt;p&gt;Рассказываю про &lt;a href="https://blog.skalon.me/all/esli-vy-chuvstvuete-chto-v-vashih-proektah-nedopustimo-mnogo-hao/" class="nu"&gt;«&lt;u&gt;цикл регулярных совещаний&lt;/u&gt;»&lt;/a&gt; или &lt;a href="https://blog.skalon.me/all/kak-udelyaya-odin-chas-v-mesyac-menedzher-mozhet-dvigat-ogromny/"&gt;совещание как драйвер процесса&lt;/a&gt;. Заказчик говорит: «Да-да, понятно. У нас настроен регулярный менеджмент». При этом без вмешательства собственника ничего не едет, задачи теряются, все держится на нескольких ключевых сотрудниках.&lt;/p&gt;
&lt;p&gt;Внедряю новую методологию управления проектами, заказчик говорит: «Ну да, мы ведь так и работали». При этом проекты буксуют, в ИТ-системе черт ногу сломит, кто за что отвечает — непонятно.&lt;/p&gt;
&lt;p&gt;Предлагаю провести &lt;a href="https://blog.skalon.me/all/sessiya-retrospektivy-sposob-vovlech-komandu-i-uluchshit-process/"&gt;сессию ретроспективы&lt;/a&gt;. Слышу: «Ой, я регулярно со своими менеджерами провожу сессии ретроспективы». Задаю пару уточняющих вопросов, выясняется, что под «ретроспективой» имеется в виду разбор полетов, который боятся и ненавидят все, но в который руководитель ввергает команду после особо неприятного факапа.&lt;/p&gt;
&lt;p&gt;Сначала меня это задевало: воспринималось, как будто обесценивают мой труд. Я-то знаю, чего стоит эта простота. Но потом я понял, что это совершенно естественная ситуация, с которой просто надо уметь работать.&lt;/p&gt;
&lt;p&gt;&lt;b&gt;Это не со зла — обычное смещение восприятия&lt;/b&gt;&lt;/p&gt;
&lt;p&gt;Причин несколько:&lt;/p&gt;
&lt;p&gt;&lt;i&gt;По форме — есть, по существу — издевательство&lt;/i&gt; (перефразируя классика). Очевидно, что иметь документ с названием «календарный план» ≠ иметь план по проекту. Проводить ежедневное обсуждение задач с командой ≠ внедрить СКРАМ. Но чтобы понять, чем отличается каша из набросанных в случайном порядке задач от рабочего календарного плана, нужен опыт. Надо посмотреть какое-то количество календарных планов, а еще лучше — составить несколько собственноручно и провести сотню планерок по ним. У меня такой опыт есть, у заказчика — нет. Это нормально: потому меня и позвали.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Путаем «хотим делать» и «делаем»&lt;/i&gt;. Иногда «время от времени собираемся, чтобы хаотично пообщаться по теме проекта» становится «регулярно проводим планерки». Это добросовестное заблуждение: термины зыбкие, и разница на первый взгляд тонкая, легко ее упустить, если не знать, что собой представляет сфокусированная планерка, и что «регулярно» это значит по графику, по четкой повестке и т. д.&lt;/p&gt;
&lt;p&gt;&lt;i&gt;Хинсайт&lt;/i&gt;. То есть, ощущение «а, ну это же само собой разумеется», когда все стало известно. Действительно: почти все вещи в проектном управлении укладываются в здравый смысл. Это не квантовая физика. Проблема в том, что до того, как «все само собой уразумелось», в момент принятия решения, перед заказчиком еще несколько очевидных, но неправильных вариантов, каждый из которых «сам собой разумеется». И пока сам эту дорожку не прошел, хрен догадаешься, какой из вариантов рабочий. А вот когда правильный уже известен, создается ощущение, что он очевиден.&lt;/p&gt;
&lt;p&gt;&lt;b&gt;Полезно не обижаться и опираться на факты&lt;/b&gt;&lt;/p&gt;
&lt;p&gt;Как же с этим работать?&lt;/p&gt;
&lt;p&gt;Во-первых, если вы внедряете новые процессы в компании — полезно &lt;a href="https://blog.skalon.me/2023/05/10/8/" class="nu"&gt;«&lt;u&gt;сходить в гэмбу&lt;/u&gt;»&lt;/a&gt; (это всегда полезно), и посмотреть, что конкретно собой представляют планы проектов, что именно написано в регламентах и на что похожи регулярные планерки. Соберите факты, и потом уже &lt;a href="https://blog.skalon.me/2023/05/10/2/"&gt;на основе фактов объясняйте&lt;/a&gt;, что и почему не работает.&lt;/p&gt;
&lt;p&gt;Во-вторых, этот эффект можно использовать. Я обычно в такой ситуации говорю: «Да, совершенно верно. У вас все это было. Мы взяли все ваши практики, &lt;i&gt;просто чуть-чуть причесали и структурировали&lt;/i&gt;». И это радикально снижает организационное сопротивление: людям гораздо комфортнее принять свои собственные наработки, которые немного «довели до ума», чем абсолютно новую систему.&lt;/p&gt;
&lt;p&gt;А я уж успею получить должную меру признания, когда новые процессы поедут, и станет понятно, насколько они отличаются.&lt;/p&gt;
&lt;p&gt;Кстати, кто из прочитавших сказал себе: «Да это же само собой разумеется»?&lt;/p&gt;
</description>
</item>


</channel>
</rss>