Category: философия

Cartmendum

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

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


FB Twitter VK LinkedIn YouTube

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


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


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

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

Cartmendum

Э. Деминг, операциональные определения и история на anekdot.ru

Недавно наткнулся на anekdot.ru на историю, которая прекрасно подчеркивает то, что Деминг называет "операциональными определениями".

Операциональное определение - краегольный камень всей производственной философии Деминга. Это переход от субъективных описаний свойств предметов и процессов к описанию на языке "испытаний и выборок".

В "Выходе из кризиса" явно не хватало какого-то практического и жизненного примера наподобие этого.
Cartmendum

Полномасштабная ретроспектива проекта. Пока еще недорого...

Упырь-Привет
Последнее время у меня происходит интересный сдвиг парадигмы. Если раньше я думал, что буду наносить основную пользу при помощи методов оценки проектов и теории ограничений, то сейчас на практике вижу, что очень многим командам не хватает вещей куда более простых – общения друг с другом. Честного, откровенного общения, на важные темы. Особенно на такие темы, которые достаточно важны, что бы их обязательно обсудить, но весьма сложны, тяжелы и неоднозначны, чтобы это делать прямо сейчас... Поэтому обсуждение можно отложить на недельку… Раз пятьдесят…

Именно поэтому мы с Димой Лазаревым начали совместно проводить ретроспективы проектов в том виде, в котором они описаны у Норма Керта: 2-3 полных дня вне офиса с полным погружением. Мы успели заметить, что даже в командах стартапов, где практически все заражены одной идеей и сидят в одной комнате, находится огромное количество недосказанного. А также нового, интересного и важного, о чем многие не знают. Узнав это новое, интересное и важное у команды появляется общая и целостная картинка того, что происходило с ними на текущем проекте. В результате ребята начинают совсем иначе смотреть друг на друга, ну и извлекают для себя массу уроков, которые помогают сократить им время выполнения следующих проектов.

Сейчас мы готовим к изданию книгу Норма Керта, а до момента выхода книги мы решили продавать проведение ретроспектив за очень недорого, если заказчик соглашается все делать по правилам: проводить мероприятие загородом и минимум 2 дня, а также не против того, что с нами будет фотограф и по результатам (с одобрения заказчика и с требуемой степенью анонимизации) мы готовим описание кейса в наше портфолио.

Наш сайт, посвященный ретроспективам: http://retrospectives.ru/

С удовольствием ответим на вопросы в комментариях или лично.

P.S. Если вы думаете, что на ретроспективе нечего обсуждать два дня, тогда я бы советовал планировать все три...
Cartmendum

Про уплотнение времени

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

Скажем, если раньше мне нужно было съездить в Питер - это было целой историей:
- Извини, я сегодня не могу, я на этой неделе еду в Питер.

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

Сейчас уже все иначе. Например, если тренировка заканчивается за 50 минут до отправления поезда, то это не повод ее отменить. Это повод лишь сократить время на растяжку и заминку...
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-а в моем понимании отпишусь позже
 

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