Книга «Искусство управления IT -проектами» (The Art of Project Management ) — первая из опубликованных книг Скотта Беркуна (немного про автора).

Книга

Содержание

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

Отдельную главу Скотт посвятил «инструкции по чтению» книги, подробно описав, в какой ее части, о чем будет рассказано, да еще и с комментариями относительно того кому какую главу будет интереснее и полезнее всего прочитать.

Каждая глава содержит подробное описание действий, которые должен, с точки зрения Скотта, предпринимать менеджер проекта, а также всевозможные практические советы и примеры из собственной практики. Наибольшая полезность этой книги лежит именно в области практических советов.

Книга пестрит очень полезными ссылками на внешние информационные источники по тем темам, которые автор не имел возможности раскрыть непосредственно на страницах. 

Стиль изложения

Нельзя с полной определенностью сказать, в чем причина – в плохом переводе, либо же в собственном стиле автора, но книга кажется «сухой» и написана скучновато. (Тут важно понимать, что моим идеалом «литературности» подобных книг, для меня являются книги ДеМарко, а далеко не каждому удается так писать).

Для кого эта книга

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

Мое личное впечатление – Скотт пытался составить максимально исчерпывающее руководство по управлению IT -проектами для начинающих менеджеров, впихнув в формат небольшой книги все этапы разработки ПО, с которыми он сталкивался. (При этом, увы, пострадала полнота изложения, иногда это весьма сильно видно).

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

Лирическое отступление: Лично мне кажется, что такие книги вообще бессмысленно читать, не имея хоть какого-то опыта соответствующей деятельности. Они проходят через такого читателя не оставляя в нем никаких новых знаний или мыслей.

Резюме

Книга целиком «списана» с личного опыта автора. Это, с одной стороны – хорошо, поскольку постоянно приводятся реальные примеры из периода его работы в Microsoft, с другой стороны – не очень, поскольку иногда складывается впечатление, что анализом чужого опыта Скотт не занимался (то ли не хотел или не считал нужным, то ли просто было некогда).

Нельзя назвать эту книгу шедевром (содержание совсем соответствует "яркому" названию), но крепким середнячком – вполне (даже с претензиями на «лидера», учитывая в целом небольшое количество хороших подобных книг).

Могу ее смело рекомендовать как начинающим руководителям проектов (даже совсем «зеленым», в качестве «руководства»), так и опытным (что бы еще раз задуматься о многих злободневных вопросах).

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

По 5ти-бальной шкале книгу можно оценить следующим образом:

• За содержание: 4
• За стиль и качество изложения: 3+

В очередном параграфе выводится нетривиальная мораль – "сообщение всегда должно учитывать условия его получения". А то, что об этом пишут уже лет 20 в каждой книжке по менеджменту или управлению коммуникациями – это ничего.

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

Подробнее про это можно почитать, например, вот тут

• Don’t Give The Client What She Thinks The User Wants
• You Do Not Know What Your User Wants
• Only Users Know What Users Want

А по этому адресу можно найти статью ракрывающую перечисленные принципы:  (Aral Balkan, User Interface Design Principles for Web Applications)

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

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

Как менеджер может демотивировать свой персонал? Начинайте загибать пальцы:
 

1. Сюрпризы во время очередной оценки персонала

   Большинство менеджеров убеждены в том, что периодические оценки персонала повышают эффективность.

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

2. «Микроменеджмент»

   Большинство работников хотят некоторой «автономности» в своей работе. Микроменеджмент – требование исполнения задачи в четком соответствии с тем, как этого хочет менеджер, вплоть до самых мелочей – это лишает людей этой свободы.

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

   Худший вариант «микроменеджмента»– требовать от персонала выполнения задач в точном соответствии с требованиями менеджера, без объяснения для чего выполняются эти задачи, какой смысл заложен в выполняемые действия.

3. Требовать одного, но поощрять другое

   Один из моих первых менеджеров объявил, что стабильность продукта – наш основной приоритет во время внесения изменений в ПО, которое мы тогда разрабатывали.

   Но скоро я заметил, что те работники, которых хвалили и продвигали по службе, вовсе не относились к тем, кто методично тестирует свой код. Поощрялись те разработчики, которые оставались за полночь, находили и фиксили критические баги (чаще всего – баги которые они сами и сделали). Ребята похитрее начинали сами добавлять баги, что бы заполучить хотя бы немного внимания.

4. Нереалистичные дедлайны

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

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

5. Запрос на оценку сроков с последующим ее игнорированием

   Менеджер приходит и просит команду разработчиков прикинуть, сколько времени займет выполнение поставленной задачи. Объявленная оценка менеджеру не нравится и он, со словами «Да мой младший брат спрограммирует это быстрее!», урезает ее вдвое. «Зачем он тратил наше время» – удивятся разработчики.

   Команда получает «тройной удар»: нереалистичный срок сдачи, недоверие к их профессиональной оценке и менеджера который устроил им публичный «разнос».

   Они не будут мотивированы на достижение «жестких» сроков сдачи, установленных менеджером. Они будут мотивированы доказать, что установленный менеджером срок был нереалистичным.

6. Выборочные поощрения

   Менеджеру не нужно поощрять всех одинаково. Менеджеру нужно поощрять всех справедливо.

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

7. Пустой трёп

   Бесконечно продолжается эпопея с использованием подхода к решению проблем при помощи «воодушевляющих» (как принято считать) фраз, типа: «Давайте сделаем это! Единственный путь – это победа! Мыслите нестандартно!».

   Конечно, наверняка есть ситуации, когда это работает, но когда менеджер начинает говорить подобные фразы, это сигнал о том, что: а) менеджер не понимает, что происходит б) менеджер не знает, что делать что бы решить проблему. И, внимание – бонус, разработчики, которые поверят в эти призывы, не перестанут сталкиваться с проблемами, они просто перестанут говорить о них менеджеру.

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

8. Люди – это расходный материал

   Когда снижение затрат означает сокращение персонала, получаемый персоналом сигнал говорит о том, что в данной компании люди – это не тот актив, в который будут вкладывать. Люди – это «расходы зарплату».

9. Некоторые люди более ценны, чем другие

   Предполагается, что ранжирование по рейтингам и разрядам – это способ повысить производительность и мотивацию персонала.

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

   Люди из «серединки» будут продолжать оставаться в этом «неудобном» положении. Демотивированное большинство.

10. Персонал не надежен

    Однажды я работал в компании, в которой 2 сотрудника из департамента численностью в 800 человек нарушили правила компании по возмещению затрат на такси. После того как это «происшествие» раскрылось, наш Вице-президент выпустила приказ, о том, что все чеки на возмещение затрат стоимостью более $5 требуют его личного утверждения.

    Таким образом она продемонстрировала сотрудникам, что с ее точки зрения никто в этой компании не заслуживает доверия.

11. Сотрудники не способны принимать хорошие решения

    Большое количество подписей, согласований и утверждений не только замедляют работу и расстраивает людей. Это говорит им о том, что компания не считает, что ее сотрудники могут самостоятельно принимать разумные решения.

Вопрос к читателю: Основываясь только на данных диаграммы – определите уровень грамотности опрошенных.

Educate Your Stakeholders!

As much as it hurts to admit it, most of the important decisions of website development are not made by design professionals. They’re made by the business owners and middle managers who hire us. After all, it is they who hold the purse strings, so it’s only fair that they set the online priorities.

http://www.alistapart.com/articles/educatingstakeholders

Это к слову об управлении ожиданиями заинтересованных лиц и раннем информировании.

1. С одной стороны "юзабельность" предполагается как некоторый универсальный параметр, расчитанный на человека в принципе, исключающий субъективный взгляд конкретного разработчика продукта на то, как должен выглядеть интерфейс (все мы сталкивались с интерфейсами, разработанными программистами). Задача юзабилиста – подняться над слоем "разработки" и сделать процесс взаимодействия с продуктом наиболее комфортным для той группы (групп) пользователей, для которой он разрабатывается, в лице "усредненного пользователя группы".В реальности же "нормальным" является наблюдение суперпарадокса, когда т.н. юзабилист создает дизайн интерфейса основываясь исключительно на своем представлении об удобстве (при этом он конечно же помнит и не забывает упоминать о "user driven" и пр.). В результате мы имеем: а) отсутствие каких либо проверяемых критериев оценки удобства интерфейса б) непредсказуемый результат (рулетка, в зависимости от того кем был юзабилист в "прошлой жизни").
2. Противоположная сторона п.1 – это позабытый пользователь. Ударившись, видимо, в усреднение группы, юзабилист получает параметры расчитанные на сферического пользователя в вакууме. В таких случаях мы получаем вещи подобные нашим школьным стульям. Вроде бы и угол сидения подобран идеальный, и высота, и плакат специальный со школьником в нужной позе нарисован, но пользоваться все равно невозможно.
3. Другая вещь, которая также вызывает искреннее недоумение, это сверхфункциональность. Когда для решения простых задач применяются слишком сложные решения – использующие максимальный набор доступных технических средств, к месту и не к месту, просто потому что "это прикольно". В этой же категории "странных вещей" находится необъяснимая нелюбовь некоторых проектировщиков интерфейсов объяснять (имеются в виду хэлпы и пр.) как и что работает. "То что очевидно мне – очевидно каждому".
4. И наконец, мой ночной кошмар, это – инновационные интерфейсы. Не то, что бы я имел что-то против инновационности и вообще каких-то изобретений. Но когда читаешь обсуждение типа "а давайте мы вот такую тут штуковину забубеним" и смотришь на макет "штуковины", то, ей богу, волосы дыбом. Опять про пользователя забыли и юзабилисты коллективно экстазируют на суперинтерфейс. А вот мне удобно то, к чему я привык, а не то, что считается удобным соответствующим специалистом.

К чему все это. Хочется что бы всегда разработчики (будь то юзабилисты или кто еще) помнили:

1. Пользователь – это живой человек, а не воображаемый куб.
2. Пользователь делает и думает совсем по-другому.
3. Пользователю не очевидно.
4. Пользователь любит когда привычно.

Жизнь внутри пузыря Неформальное руководство менеджера по выживанию в инвестируемом проекте Тем, кто вблизи наблюдал чудовищный рост популярности Интернета в 1998–1999 годах, может показаться, что в 2005–2006 годах история того интернет-пузыря повторяется ещё раз. После падения доткомов и безнадёжной инвестиционной зимы 2001–2003 годов, когда большинство скороспелых интернет-проектов разорились, и ушибленные Интернетом инвесторы поклялись никогда больше не инвестировать в Мнтернет, бешеный рост этого странного бизнеса вдруг начался снова. Дальше

• Скачать PDF (3,85Mb)