Category: история

Category was added automatically. Read all entries about "история".

Cartmendum

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

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


FB Twitter VK LinkedIn YouTube

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


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


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

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

Cartmendum

Что писал Карл Густав Юнг о гаджетах в 1961

Опережающий рост качества, связанный с техническим прогрессом, с так называемыми«gadgets» (приспособлениями. — англ.), естественно, производит впечатление, но лишь вначале, позже, по прошествии времени, они уже выглядят сомнительными, во всяком случае купленными слишком дорогой ценой. Они не дают счастья или благоденствия, но в большинстве своем создают иллюзорное облегчение; как всякого рода сберегающие время мероприятия они на поверку до предела ускоряют темп жизни, оставляя нам все меньше и меньше времени. «Omnis fastinatio ex parte — diaboli est» — «Всякая спешка— от дьявола», как говорили древние.
Карл Густав Юнг
Воспоминания, сновидения, размышления
Cartmendum

Дэвид Андерсон: Канбан. Альтернативный путь в Agile

Не без помощи Германа Оскаровича и тому, что в Сбербанке теперь Agile на русском языке за последнее время издали огромное количество очень хороших книг, которые раньше были доступны лишь ИТ-шникам, работавшим на зарубежного заказчика (мало где еще читали профессиональную литературу на английском).
Вот одна из моих любимых цитат:


Большинство же команд, не имевших тщательных методов анализа и исторического опыта, не могли совладать с теми, кто подталкивал их брать на себя непонятные, а нередко и неосуществимые обязательства.
Я ее упер в свой тренинг по оценке проектов и работе с цифрами. Помню как 6 лет назад, когда я еще работал в "Лаборатории Касперского", мы ковырялись в клубке менеджерско-ИТшных проблем и пришли примерно к примерно такой-же корневой причине:

Только она была сформулирована несколько иначе: "наш нахер тонок и неубедителен". Имелось ввиду, что мы не могли достаточно жестко и опираясь на факты, отказать запросам, превышающим наш предел впихуемости, так как сами не понимали, где он...

Эхх... приятно вспомнить :)
Cartmendum

Дайджест форума mnogosdelal.ru за первую неделю

За первую неделю, а точнее за 4 дня, прошедших с момента создания форума, на нем начали довольно бодро обсуждаться весьма интересные темы, коих к настоящему моменту накопилось целых 13. Наиболее интересное на мой взгляд:

  1. Прокрастинируется еженедельный обзор... (что делать, если такая важная вещь, как обзор не проводится)

  2. Карта рабочего процесса в GTD (и ее апгрейды джедайскими техниками) (в чем тонкие отличия GTD Дэвида Аллена от того, что я называю джедайскими техниками)

  3. Помидорная тема (метод pomodoro и как им пользоваться)

  4. Список входящих на инкубацию (что это такое?)

  5. GTD + ТОС (буфер времени при планировании задач на день)

  6. Организация хранилища информации

  7. Майндмэпы vs Графы и Майндмэпы vs Списки


Понимаю, что для участия в обсуждениях там надо регистрироваться и регистрация через соцсети пока не впилена, но тем не менее, я вас приглашаю задать свой вопрос и/или поделиться своим мнением на уже заданные вопросы:
Cartmendum

Kano Survey: любопытный подход к приоритезации требований

В свое время dumtest навел меня на любопытную модель приоритезации требований к ПО. Эта модель была разработана Нориаки Кано в начале 80-х (судя по всему, еще до того момента, как Хиротака Такеучи и Икуджиро Нонака заявили о Scrum-е). Утверждается, что при помощи этого подхода можно выделить самые важные требования, максимизирующие функцию удовлетворенности пользователей.

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

По каждой пользовательской истории пользователю предлагается ответить на два вопроса:
  • Как вы относитесь к наличию данной функции?
  • Как вы относитесь к отсутствию данной функции?
На основании этих двух ответов, каждой пользовательской истории присваивается очко в одну из 6-ти категорий:
  1. Обязательная функция, без которых не возможно пользовательское счастье. (Must Haves)
  2. Линейные функции (Linear Features). Такие, что чем больше их есть, и чем изощеренее они реализованы, тем счастливее пользователь.
  3. Функции из разряда «приятные неожиданности» (Exciters)
  4. Функции, безразличные для пользователя и первые кандидаты на выкидывание (Indifferent)
  5. Заведомо бесполезные функции и даже вредительские функции (Reverse)
  6. Спорный функционал, или функционал, не понятый до конца заполняющим опросник пользователем (Questionable)
Далее уже смотрим ответы по всем респондентам и выясняем, какая пользовательская история в какой категории заработала больше очков.

На просторах интернета есть даже веб-сайт (сырой, но вполне юзабельный), позволяющий проводить подобные опросы: http://www.kanosurvey.com/ (халявный)

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

Лучший способ узнать подробнее что же такое Kano Survey – это поучаствовать в нем самому:


Попробуйте, результаты я потом опубликую.

Если интересны детали метода, то есть еще ссылки:
  1. http://itnaut.com/when_is_v1_feature_complete
  2. http://www.pragmaticmarketing.com/publications/magazine/4/3/0605ss#1264759290
  3. Книга Майка Кона "Agile Estimating and Planning" (в 11-й главе модель Кано рассмотрена достаточно подробно)
Cartmendum

Статистика для менеджера проекта (еще одна статья из PMMagazine)

С разрешения редакции PMMagazine делюсь с вами своей второй статьей из №2 (19) Июнь 2010

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

Здесь речь идет о причинах неопределенности, методах ее оценки на основе исторических данных команды, плюс предлагается маленький хинт для контрактов с фиксированной стоимостью в условиях неопределенности.

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

Менеджмент 20 веков назад

Цзы-гун спросил: "Что вы скажете, если кого-то любят все односельчане?". Учитель ответил: "Не годится". -"А что скажете, если кого-то ненавидят все односельчане?" - "И это не годится. Лучше, если его любят хорошие односельчане, а ненавидят злые".
Линь юй (13.24)