вторник, 26 апреля 2011 г.

Обзор Искусства Управления IT-проектами (Making Things Happen) Скотта Беркуна.


Во время прочтения этой книги выработал для себя новый критерий качества чтива: через 5-10 минут продолжения\начала чтения судорожно ищешь карандашь, чтоб подчеркнуть полезную и интересную мысль, а карандашь превращается в закладку, чтобы потом долго его не искать =)

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


И да книжка не про ажайл\лин, а просто про управление проектами =)

Автор не обещает решений всех ваших проблем, или какой-то серебрянной пули, а всего лишь рассказывает о тех практиках подходах к управлению и принятиюрешений к котороым он пришел за время своей работы в Микрософт.
И, черт возьми, неудивительно, что Микрософт доминирует на десктопном рынке с такими управленцами =)

Все написано простым и понятным языком с необходимым минимумом теории и максимальным количество практики и подходов. И включает наверно самое важный пункт, который следует развивать пму:  главу "Как не раздражать людей на работе, в ходе электронной переписки, на совещаниях" =)

Удивительным образом во время чтения замечаешь, что несмотря на то, что описываемые события 90-х годов и во многих повествованиях проскальзывает явная ватерфольщина =), но все актуальные идеи лидерства, постоянного улучшения, ориентации на бизнес и команду и тонна других вещей удивительно актуальны и сродни текущим гибким течениям.
А во время чтения, того как делать НЕ НАДО, и в описании мест совершения самых частых ошибок с удивлением обнаруживаешь свой прошлый опыт работы(и возникает такой Ага-эффект) =)

Еще в книге присутствует 5-ок-другой опросников и чеклистов, чтобы проверять себя на разных стадиях работ и в различных ситуациях, во время чтения мне захотелось все их перенести в электронный вид и пользоваться ими при случаи(даже нашел подходящую онлайн тулзу - checkvist, жаль оффлайн клиента под кпк\андройд нет).


Маленький перечень, того, что особо хотелось отметить и не забыть потом во время чтения:

Цели и концепция проекта:

1)Наиболее распостранненные просчеты в определении конечной цели проекта:
 - мы будем делать то же , что и в прошлый раз
 - мы будем делать, то чем принебрегли в прошлый раз
 - мы будем делать то же самое, что и наш конкурент
 - мы будем делать, то что отвечает модным тенденциям (сделаем веб-два(три)-нольно и стартап !)
 - если мы сделаем этот продукт, он обязательно найдет своего покупателя

2) При формулировке цели можно воспользоваться таким приемом - отнеситесь к ней максимально придирчиво и задатьяс вопросом, не провалиться проект, если его цель будет достигнута в точном соответствии с его формулировкой. Затем нужно подумать, а нельзя ли более точно сформулироваться цель, нет ли какой-нибудь дополнительной, уточняющей информации.

3) Если вы не в состоянии найти какое-нибудть визуальное представленеи того, что изменится в этом мире под влиянием проекта, стоит задуматься не направлен ли этот проект на создание бесполезных вещей. или достаточно ли он понятен, чтобы быть успешно притворенным в жизнь.
3.1) Что концепция всегда была на видном месте, несколько ключевых целей проекта должны быть оформлены в виде плакатов, расположенных в наиболее людных местах (визуальный менеджмент в стиле Лин !)

Выбор Идеи:
 - Какую именно проблему мы пытаемся решить ? (При возникновении споров о том, что и как делать.)

Информированность: 
 - По возможности старайтесь избегать информации из 2-х, 3-х и 4-х рук. Во время разговора часто вскрываются детали и нюансы по тем или иным причинам не попавшие в отчет или презентацию.
 - Люди ценятся выше информации. Человек пишущий отчет, изучил 1000 разных веещй и узнал массу полезной информации, которую невозможно втиснуть целиком в этот отчет, но который он с радоситью поделиться с теми, кто проявит достаточное любопытство.
 - Хорошие решения могут давать плохие результыта.

Общение: 
 - Базовая модель общения:
- Передача
- Получение
- Усвоение
- Согласие
- Превращение в полезые действия
Не факт, что ваше сообщение не остановилось на уровне передачи или получения ! То, что вы что-то сказали\написали ничего не говорит о его усвоении, или о том. что с вашим сообщением согласны.

Почему люди раздражаются: 
 - Не считайте меня идиотом.
 - Доверяйте мне.
 - Не тратьте мое время попусту.
 - Не распоряжайтесь мной без должного уважения.
 - Не заставляйте меня слушать или читать всякие глупости.

Формула хорошего процесса:
Полная стоимость процесса:

  • время на выработку замысла процесса(DT),
  • время на его освоение командой(LT)
  • фактическое время выполнения работы при применении процесса, помноженное на частоту его применения (ATxN)

= DT + LT + (AT x N)
Суммарная выгода процесса:

  • стоимость провалов, которые процесс позволяет избежать(FC),
  • помноженную на показатель вероятности возникновения провалов(FP) без внедрения процесса в пределах определенных временных единиц
  • и помноженное на количество таких единиц в проекте (T). 

 =   (FC x FP) x T
А ценность процесса равна:  ((FC x FP) x T) - (DT + LT + (AT x N))

Итого:
Не зря она занимает свое место а бест-селлерах О`рейли и для всех кто интересуется разработкой ПО должна находитсья в разделе must have & must read.
Думаю перечитаю ее еще не раз через месяц-другой, чтобы освежить в памяти и найти какие-то новые моменты .

суббота, 9 апреля 2011 г.

Комментарии по книжке Деминга "Выход из Кризиса"


Решил написать обзор очередной книги, пара недель прошла, как прочитал, но с переездами в москву, поисками квартиры и прочим геммороем было не до того)
Отрабатываю долг перед собой)
Это наверно последняя из запланированных книжек из серии agile/lean/etc на ближайшие пару-тройку месяцев.
И она оказалось самой талмудистой =)

Читал и осозновал я соответственно "Выход из крисиза. Новая парадигма управления людьми системами и процессами" Эдвардса Деминга.

Об авторе и книге:
Товарищ Деминг можно сказать является родителем agile & lean подходов по той простой причине, что это он ездил распостранять свои идеи японцам, когда в америке продвинуть их не слишком удалось. И потом уже рекурсивно на волне подъема японской промышленности эти идеи вернулись в америку и добрались в том числе и до разработки ПО.

Автор достаточно скромен и честно признается в свой книге, что на самом деле он не автор всех этих идей, а развивал идеи и мысли Шухарта, и цикл Деминга должен быть не циклом Деминга, а циклом Шухарта =)

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

Книга опять же большая(~300-400 страниц) и потому с наскока не береться, потому лучше конспектируйте ее походу иначе есть вероятность после 2-3х дневного возврщанения к чтению забыть о чем же шла речь.
Одним из самых интересных моментов, книги являеться, то что она написана во первых тем, кто создавал эту теорию, а так же она написана уже ПОСЛЕ того, как теория подтвердилась на практике.
И, благодаря этому, у автора была возможность уточнить и отполировать теорию нового менеджмента и производства во время ее внедрения.

Вобщем можно вольно перефразировать Друкера и сказать "Деминг - это Тейлор сегодня".
Пришел, проанализировал производство и победил, т.е. переубедил(еще переубеждает) весь мир, как надо производить товары\продукцию\услуги.

Что запомнилось:

1) В кратце книгу можно пересказать, как "Стремитесь к максимальному качеству, и вот как это сделать".
Только под качеством надо понимать не только отсутствие ошибок, переделок и лишней работы, но и производство именно того, что нужно потребителю (хинт: делайте прототипы, и тестируйте их в реальных условиях), ведь в конце концов какая разница что предмет не ломается, если он не делает того, что надо или делает это не так.
А уже повышение качества приведет,
к снижению себестоимости(меньше переделок, брака, ошибок)
-> больше производительность
-> предлагаете лучшее качество по тойже или более низкой цене
-> захватываете рынок
-> ПРОФИТ!
-> повторять до бесконечности.

2) Для этого Деминг предлагает 14 пунктов менеджмента (почти теже, что описаны в Дао Тойота +/- пункт-другой, так что опущу сами прочитаете).
И называет "смертельные болезни менеджмента", т.е. то как делать не надо, например : "аттестация и ранжирование персонала" или "нацеленость на сиюмитный результат".
Кстати в книжке встречается, довольно много эдаких вопросников или чеклистов и если есть вопросы а стиле "что я(мы) делаем не так", то можно поробовать пробежаться через вопросник и станет понятно в какую сторону надо копать)

3) Кроме таких философско-менеджментско-общечеловеческих советов Деминг так же расписывает, как понять встали ли вы на путь улучшения: т.е. улучшаете процесс (и всю систему) - исправляете "общие" причины (вариабельности\ошибок), например отсутствие единой системы документации. Или постоянно фиксите "особые" причины (т.е. следствия системных ошибок, или единичные случаи), например некомпетентность отдельного человека (и это скорее следствие системной ошибки системы отбора персонала), либо завышенная сложность, или запутанность определенной процедуры.

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

4) Кроме того, контроль качества не должен быть бездумным, тюею стремиться к идеальному процессу на каждом этапе, если проверка + исправление потенциальной ошибки на этапе А, добавляет 10$ (5 - проверка, 5 - исправление) к себестоимости товара(надо кстати не забывать, что проверка качества тоже стоит денег), а проверка и исправление на этапе Б(этап А входит в него как одна из деталей) стоит 1000$ (10$ проверка + 990$ исправление), то если вероятность ошибки на этапе А - 0.000000001, а вероятность ошибки на этапе Б - 0.00001, то проверяя на этапе А мы добавляем к себестоимости каждого продукта стоимость его проверки на этом этапе, а на этапе Б проверять скорее всего все равно придеться т.к. стоимость нахождения дефекта пользователем обычно гораздо выше проверки и починки у производителя.

Стоит ли почитать:
Книжку можно почитать ВМЕСТО Дао Тайота, чтобы понять все идеи `японского` менеджмента, кроме того более научный стиль изложения создает неявное ощущение верности всех этих идей. Если вы уже знакомы с идеями lean, то стоит читать только отдельные главы + смотреть главы по вариабельность и типы ошибок.