Category: кино

Cartmendum

Приклеенный пост: ссылки на все мои слайдкасты

Мои профили в соцсетях


FB Twitter VK LinkedIn YouTube

Краткое резюме есть здесь


А еще я написал книгу, и потом написал еще одну.


Если у вас есть вопрос, то его можно обсудить в форуме

Ссылки на все мои слайдкасты перехали сюда

Cartmendum

Про рекламу в интернете (бесплатный контент, банерорезки и paywall)

Ответ на очередной комментарий к моему опросу.

Комментарий:
Люто минусую рекомендации ставить блокировки рекламы. Дорофеев, ты что советуешь? Может ещё и софт воровать и фильмы? Реклама позволяет пользоваться интернетом бесплатно. Если все будут её блокировать, интернета в привычном виде скоро не станет, появится массовый paywall . Плохие виды рекламы, типа интерстишуал страниц блокируют сами современные браузеры.

Cartmendum

Одна из причин провала джедайских техник

Одна из довольно частых причин развала джедайских техник выглядит так: пока все хорошо (работы в меру и нет всяких завалов) техника работает. Но вот стресс-тест не выдерживает: как только наваливается куча задач (например, из-за аврала, после отпуска, болезни или командировки) система приходит в запустение и приводить ее в порядок уже не хочется ну или «очень хочется, но сейчас не время... потом…»

Рассмотрев несколько кейсов, я обнаружил интересную причину такого явления. Естественно, это и не «отсутствие мотивации» и не «особый склад характера» и, естественно, не настоящее «некогда». Корневая причина оказалась простой и неожиданной: два списка задач… Точнее, даже не два списка задач, а отсутствие личных задач в общем списке. Естественно, личные задачи в общем списке должны быть также сформулирован как настоящие задачи: четкие, мелкие, конкретные и понятные мозгу без дополнительных рассуждений (вы же помните, о том, как правильно формулировать задачи?).

Казалось бы, зачем взрослому состоявшемуся человеку иметь в своем рабочем списке задач еще и личные задачи?.. Смысл прост… Список задач помогает нам получить ответ на вопрос: «что нужно/можно сделать прямо сейчас?». Если мы не записываем в наш список задач личные задачи (или записываем их, но не достаточно четко или конкретно), то с хорошей вероятностью мы будем сравнивать мелкие оперативные задачи с чем-то крупным и мутным (потому как в голове у нас если оно и хранится, то именно в укрупненно-замутненном виде):

- Что же мне сделать прямо сейчас? Ответить на письмо начальнику или провести время с семьей?... Хм… 6 минут на ответ начальнику или много часов проводить время с семьей (я же хочу проводить с семьей много времени)? Хм… Хм… Ну 6 минутная задача не будет ждать много часов, сейчас быстренько делаю и …

И потом повторяется все тоже самое: провести время с семьей или заполнить еженедельный отчет. Провести время с семьей или перезвонить кому-то там еще… И как правило, мелкие задачки всегда будут побеждать крупное, общее и не конкретное. Чтобы такое перестало повторяться нужно соизмерять соизмеримое, но для этого еще нужно будет понять, какое первое непосредственное действие скрывается за «проводить время с семьей»? Например, купить билеты в кино, помочь сыну с рисунком, прибить полочку на кухне… В этом случае исход битвы за наш мозг между написанием отчета и покупкой билетов в кино уже не так очевиден. В какой-то момент мы можем подумать:

- Ответить на письмо 6 минут или 4 минуты купить в онлайне билеты?... Хм… Я уже хорошо потрудился, начальник до завтра потерпит, поэтому я могу уже спокойно покупать билеты в кино и двигать туда

А вот если в вашем списке задач есть только рабочее, то в какой-то момент вы заметите, что вы и делаете только работу… При этом, чем больше вы делаете работы, тем… тем больше вы делаете работы… То есть, если вы хорошо поработали, то вы в награду получаете еще больше работы… И так пока не затрахаетесь, и не перестанете хорошо работать. В итоге когда техника разваливается под каким-то мощным наплывом задач и потом перед вами встает вопрос, восстанавливать ее обратно или нет, по сути в отвечаете на простой вопрос: «стоит ли мне сейчас приложить дополнительные усилия и затрахаться для того, чтобы продолжить затрахиваться и дальше, пусть и более эффективным способом», на что подсознанка дает вам единственно правильный ответ: "в жопу все!", что ваше сознание интерпретирует как: "Не сейчас, потом..."
Cartmendum

Apollo-13: ITIL Simulation

Последнее время начал учить ITIL. Пока силами тренеров  что, кстати не очень впечатлило...

На прошлой неделе компания организовала нам выездную игру-симуляцию ITIL. Смысл игры - воспроизвести сценарий Apollo-13 (говорят, даже фильм про это есть, но я его не смотрел). История такая, в 1970 США запустили Apollo-13 и хотели высадится на луну, однако все у них пошло не так и им пришлось возвращаться. Ну и все вернулись.

Сама симуляция в основном была посвящена имитации сервис-деска. Весь псевдо-полет был разделен на 4 раунда, а каждый раунд на сколько-то псевдо-тактов по 2 минуты. В каждый такт ведущий, выполняющий роль команды, подбрасывал проблему, которую нужно было решить. Процесс выглядел так: проблема - это карточка с каким-то описанием. На "Земле" было 4 технических специалиста у каждого из которых был свой набор карточек с решениями, для каждой проблемы где-то у кого-то было решение и основной задачей было найти совпадающую карточку и вернуть ведущему. Ведущий потом отмечал сколько тактов прошло от момента возникновения проблемы, до момента ее решения. Забавно.

Видимо по замыслу художника ожидалось, что технические специалисты будут перебрасывать друг-другу карточки, пытаясь свалить проблему на кого-то еще. Сначала так и было, но с этим эффектом мы достаточно быстро поборолись, сменив Push систему на Pull. В исходной Push системе (которая вроде как и взята за основу в ITIL) сервис-деск тупо впихивал задачу нужному на его взгляд специалисту, при этом его совершенно не заботила загрузка этого специалиста. Как результат, в суматохе (а суматоха была, спасибо ведущему - он ее грамотно подогревал :) ) специалист тратил большую часть времени на переключения между карточками. Пришедшая на смену Pull система (лежащая в основе Lean) представляла собой плотно сдвинутые столы всех участников, аккуратно разложенные карточки-решения и пустое место, куда сервис-деск кидал новые проблемы, не думая кому конкретно ее передать. Тот, кто был свободен, хватал проблему и искал для нее карточку-решение. Если все были заняты, то карточки с проблемами мирно валялись себе и ожидали первого освободившегося. Как результат, в раунде с Pull системой среднее время разрешения проблемы сократилось в двое и при этом все проблемы нашли свое решение (в первом раунде было решено только 8 из 13). Вот она сила кросс-функциональности и отсутствия потерь на переключения между задачами!

Так же в игре симулировался процесс управления изменениями. По результатам проблемы пришедшей от наблюдающего за приборами, нужно было изменить курс. В игре изменить курс означало подготовить запрос на изменение, собрать с нужных участников нужные карточки-решения, надыбать аппрувы от нужных ролей, назначить серьезность и приоритет и сделать еще какие-то ритуалы. За изменение отвечал я и продолбал его. Продолбал потому как не догадался взять карточки-тесты от поставщика (типа решение не протестировано) и вписать в поля "Приоритет" и "Серьезность" нужные значения. Но ведущий взял запрос на изменение курса (ибо минимально необходимые карточки все же были собраны), но снял очки с команды. То же мне, поле приоритет пустое... Он как "космонавт" хотел жить или нет? Мог бы и не принимать изменение - стал бы еще одним спутником солнца...

В общем игрушка была достаточно веселой. Правильно было сделано, что между раундами проводились ретроспективы и можно было менять процесс (в результате чего и появилась Pull система). Единственный момент, который принес бы практическую пользу, но который организаторами был полностью проигнорирован (видимо, что бы не лишать ITIL-овских консультантов работы) - это сессия параллелей между ретроспективами в игре и своей реальной рабочей обстановкой. В игре улучшать процесс получалось и практически все понимали что нужно поменять, что бы следующий раунд отыграть еще лучше. Но как это поможет в нашей реальной работе? Можем ли мы что-то использовать из этого в своей реальной жизни? Что стоило бы попробовать в первую очередь, вернувшись в офис? Окончание игры было бы шикарным моментом для поиска ответов на эти вопросы, и я больше, чем уверен мы бы нашли что изменить в своих процессах. Без этого симуляция так и осталась несколькими часами балбесничания за счет конторы...


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

В этом блоге можно найти еще что-нибудь интересное
Cartmendum

Scrum Tailoring

Scrum Tailoring

Закончил работу над очередным фильмом.

История и персонажы вымышлены. Любое совпадение с рельностью является не более, чем случайностью.

Это безумно грустная история...  Правда же такого не бывает в жизни?


Cartmendum

The Rise and Fall of the Waterfall (trailer)

The Rise and Fall of the Waterfall

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

Смотрите, что получилось. Если понравится, у меня уже зреет идея сериала о жизни персонажей из програмной инженерии.

Трогательную мелодраму о жизни Уолкера и Уинстона Ройсов надеюсь завершить в ближайшее время.