Category: искусство

Category was added automatically. Read all entries about "искусство".

Cartmendum

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

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


FB Twitter VK LinkedIn YouTube

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


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


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

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

Cartmendum

Об упорядоченной прокрастинации

Получил я недавно от одного очень хорошего человека ответ на свое письмо спустя 9 месяцев… Ничего критичного от этого ответа не зависело, это было просто легкое общение.

Тем не менее, как прокрастинатолога меня очень заинтересовал данный феномен. Ведь не каждый же день ты получаешь ответы на вопросы, заданные 3 квартала назад. Мне стало интересно, как так получилось? Это задача так долго болталась в списке задач или просто письмо где-то завалялось и тут на него случайно глаз упал. На это хороший человек мне ответил:

да, я в воскресенье прокрастинировал весь день заполнение инвойса (до позднего вечера), всем чем мог :)) : перепроектировал свою систему планирования и рутин, допереносил наконец-то все задачи из максдона в тудуист, и вот там в залежах и была она, как-то сошлось по-быстрому её выполнить, настроение было подходящее ))

После чего сразу вспомнилась книга Джон Перри "Искусство прокрастинации":


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

Кстати, я сейчас пишу этот пост тоже вместо того, чтобы заняться тем, что мой рациональный тип считает очень-очень важным… А если вообще посмотреть на мою прошлую жизнь… То я вообще стал прокрастинатологом во многом из-за того, что прокрастинировал основную работу…

Если у вас сейчас есть очень важная задача, которой вам нужно срочно заняться, лучше посмотрите вот это мое видео на YouTube :)
Cartmendum

Видео-инструкция для Excel-шаблона Enhanced Burn-Down Chart-а (и адаптивной оценки проектов)

Про то, что такое Enhanced Burn-Down Chart и чем он лучше Backlog Burn-Down я писал еще много лет назад тут. Так же в свое время я выложил в общий доступ Excel-ку, для рисования этого забавного графика, снабженную статистической моделью для прогнозирования даты завершения проекта.

Скачать ее можно тут.

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

Теперь стало понятнее?

Cartmendum

Списочек бесплатных тулов для рисования мыслесхем (Mind Maps)

Из комментариев к этому посту по-тихонечку сформировался небольшой списочек бесплатных тулов для рисования мыслесхем. Если у вас есть, что добавить к этому списку - добавляйте, человечество будет вам благодарно:
  1. FreeMind - простоват, но бесплатен и кросс-платформенен. Нельзя вставлять в узлы картинки, как это можно делать во FreePlane.
  2. FreePlane - на мой неопытный взгляд, один в один MindManager, только бесплатный. И еще он под линуксом без вайна работает.
  3. MindMeister - крутой и платный интернет-сервис для редактирования и хранения мыслесхем. Есть приложение под iPhone и Android. В бесплатном варианте можно сохранить только 3 мыслесхемы. В платном варианте появляется множество различных ништяков. В корпоративных планах есть даже возможность совместной работы над одной и той же мыслесхемой.
  4. xMind - Спасибо _darvin-у  за наводку. Тоже кросс-платформенный тул с открытым кодом.
  5. Mind42 - бесплатный онлайн тул. Позволяет делится мыслесхемами. Под мобильные платформы проги не нашел, но и искал плохо. brinlig, спасибо за ссылку.
  6. CMAP - Набор клиент-серверных тулов для рисования диаграмм. Клиентская часть бесплатна для всех, серверная бесплатна только для школьников (K-12). Сам не пробовал, но [info]igatopoison-у нравится
  7. SimpleMind+ - умеренно платный тул для всего яблочного
Cartmendum

Д. О'Коннор, И. Макдермотт: Искусство системного мышления.


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

Основная мысль - практически все, что нас окружает являтся системой, и каким бы сложным и разнообразным это "практически все" не являлось, рассматривая все как систему, можно найти очень много общего между тем, что на первый взгляд ничем общим не обладает. Для анализа этого "практически всего" привычная формальная логика может оказаться неприменимой из-за наличия обратных связей и сдвигах во времени и/или пространстве следствия, от вызвавшей ее прчины. Для этого и было выдумано системное мышление.

Книга написана для совершенно неподготовленного читателя, поэтому многие вещи иллюстрировались на мой взгляд избыточным числом примеров. Да и вообще книга слабовата...

Авторы претендовали на универсальность излагаемого подхода, давая примеры из различных областей: бизнеса, семейной жизни, личных финансов, систем общего пользования. Однако предисловаие к русскому изданию, написанное Рубаником Ю.Т. (основателем и главным смотрителем за http://www.deming.ru) явно указывает на происхождение этой науки.

После прочетния этой книги зачесались руки прочесть Питера Сенге "Пятая дисциплина"...
Cartmendum

Шаблон Enhanced Burn-Down Chart

Если честно, то я уже не помню кому и сколько раз обещал выложить шаблончик для рисования Enhanced Burn-Down Chart-ов... Сегодня решил взять и сделать.

Шаблон лежит тут: www.slideshare.net/Cartmendum/project-burndown-template

Упоминание про шаблон было в этой презентахе.

Теперь вы тоже сможете считать по своим проектам вот такие картинки:


Эта картинка обозначает следующее:
  1. Синяя полоска -объем работы на заданную итерацию
  2. Черные линии - линейное приближение делания и добавление работы
  3. Фиолетовая полоска - вероятность итерации стать последней (то есть, в эту итерацию будет доделано все, что есть, с учетом втока)
  4. Зеленая линия - вероятность завершить проект до заданной итерации включительно
Пользоваться шаблончиком просто (я надеюсь). Править нужно только первый лист под названием "Backlog". Для каждой задачки указывается в какую итерацию она появилась (если в самом начале, то ставим 0), в какую итерацию она была сделана и ее оценка.

Sprint Burn-Down шаблон не рисует, его задача показывать макро-картину.

Фидбек и вопросы категорически приветствуются.

P.S. В основе стат модели лежит нормальное распределение втока и вытока задач. Это предположении в большинстве случаев не верно, но статистика вообще лженаука...
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

О покупке ненужного (продолжение)

В продолжение о покупке вещей или о вопросах, ответы на которые при чуть более внимательном рассмотрении просто не нужны.

Не буду вдаваться в детали и рассказывать про то как, когда и с каким из моих заказчиков это произошло, но ситуация выглядела следующим образом. Перед началом относительно большого проекта (2 года и более 20 человек) был составлен до безобразия детализированный план. Наш кусочек работы представлялся на диаграмме Гантта набором из более чем 500 прямоугольничков.

План был откровенно плохой. (Основные признаки плохого плана будут рассмотрены позже в отдельном посте)

В плане можно было выделить группы задач, например, портирование баг-фиксов из старого выпуска. Каждая группа состояла из множества мелких задач: «портирование баг-фикса 1», «портирование баг-фикса 2», и так далее до числа порядка 40. Что самое страшное, в плане для каждой задачи «портирование баг-фикса N» были проставлены даты начала и даты конца. Нет, это даже не самое страшное, самое страшное случилось, когда этот план попал в руки человеку, ответственному за отслеживанием Percent Complete. Он, не особо задумываясь, решил, что ему нужно следить за каждой из множества этих задчек. Как результат на регулярной основе этот человек требовал от меня информацию по каждой задаче следующего содержания:
1.    Начата ли задача?
2.    Если не начата, то когда начнется?
3.    Если начата, или планируемая дата начала откладывается, то где будет планируемая дата завершения?
4.    Какой ресурс отвечает за эту задачу? (к сожалению, за год работы со мной они так и не уяснили разницы между ресурсом и человеком)
5.    Какой Percent Complete по этой задаче?

По замыслу художника, эта информация потом попадала в огромный файл в формате MS Project, откуда получалась ОДНА ЕДИНСТВЕННАЯ цифра – общий процент завершения проекта, что и рапортовалось начальству.

Как можно руководителю сэкономить свои усилия, отвечая на эти вопросы? Есть несколько вариантов:
1.    Называть случайные цифры,
2.    Долго думать, делая вид, что идет процесс планирования и все равно называть случайные цифры,
3.    Распределить маленькие задачи внутри команды и просить ответственных думать и называть какие-то цифры (которые все равно не будут коррелировать с реальностью и будут случайными)

Любой из этих путей ошибочен. Можно долго думать над более правильным способом точного определения даты начала и даты конца задачи, можно долго спорить, как считать процент завершения отдельной задачи, если она еще не завершена полностью. Все это имеет лишь один гарантированный результат – потеря времени, и делать этого не стоит. Нужно откатиться назад – к целям. Если цель всех Project Management Meeting-ов это получение информации достаточной для определения мифического процента завершения, то решать нужно именно эту задачу.

Естественно, любой здравомыслящий человек прекрасно понимает, что для получения заветной цифры не нужно «покупать» такое количество информации. Если объединить всю массу маленьких и слабо связанных друг с другом задач в одну, то проблема вычисления процента завершения сводится к простому делению числа завершенных задач, на их общее число (умноженных на коэффициент, который в этой науке обычно равен 100). Если следовать этой модели, то для определения заветного числа нужно «покупать» лишь одну цифру – число задач, завершенных на 100% (что является более точным показателем, ибо когда говорят, что «баг устранен на 53%», то это невольно вызывает ехидную улыбку. Если не вызывает – это сигнал к работе над собой)

Все это кажется простым до идиотизма. Я думал, а стоит ли вообще посвящать этому отдельный пост. Но, столкнувшись с маниакальным желанием руководителя программы на стороне заказчика (между прочим, компании из Fortune 500) знать кто конкретно и когда точно начнет работу над каждым кубиком диаграммы Гантта, понял что наверное стоит. Тем более основная задача не рассказать, как отслеживать процент завершения, а показать, что ненужные вещи покупают не только женщины...

Будет не лень - будут еще примеры.