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

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

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

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

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

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

There’s a certain breed of clients that lives in the past: web 1.0 clients in a web 2.0 world. They can be a nightmare to work for, and they often end up commissioning horrendous sites that pollute our precious internet. It might seem easy to just pretend they don’t exist, or, worse still, to do as they ask, but—brace yourself—these clients are the stepping stones to enlightenment. It can be frustrating to work for clients who force us to justify our strongly held beliefs, but, budget permitting, it may still be worthwhile.

Статья целиком: http://www.alistapart.com/articles/difficultclients

Когда я слы�?у о техническом задании на разработку веб-сайта, я внутренне улыбаюсь – еще один продукт, устарев�?ий уже в момент выхода. Это первая проблема всех технических заданий – предположение, что вне�?няя среда не меняется.

Мысль тоже устаревает в момент ее выхода, и что? ТЗ – это документ позволяеющий задать рамки проекта и впоследствии удержать его в этих рамках. ТЗ описывает за что заказчик платит вам деньги. В процессе разработки рамки могут изменяться, а изменения фиксироваться как дополнения к ТЗ и оплачиваться заказчиком (это ведь дополнительные работы). Без такого документа, фиксирующего хотя бы начальное состояние и договоренности, а также связанные с ними параметры проекта, изменения отследить невозможно.

Вторая проблема хоро�?о известна и отражена в древней мудрости: чтобы задать правильный вопрос, надо знать половину ответа. В ситуации, когда каждый новый сайт вы разрабатываете с использованием только что появив�?ихся технологий (новые модули, новая версия собственного движка, новая версия базы данных), – фактически вы каждый раз многое делаете заново. Это значительно осложняет процесс разработки, потому что вы не знаете, как будете это разрабатывать.

ТЗ редко включает в себя подробней�?ую спецификацию будущего модуля. Почти всегда достаточно описать остановиться на уровне функциональных возможностей в клиентской части и в части бэк-офиса. Как это будет реализовываться на практике – прикладная задача. В ТЗ это писать не нужно.

Третья проблема классическая – заказчик не всегда точно знает, чего он хочет. �? когда подходит срок сдачи проекта, вы слы�?ите, что вот здесь хоро�?о бы подправить, вот здесь изменить, а вот здесь добавить. Частично эту проблему ре�?ает моделирование конечного продукта, но, повторюсь, ли�?ь частично.

Это называется "работа с требованиями заказчика", читаем и запоминаем. � абота с требованиями заказчика действительно неприятный процесс и требует морального напряжения, но такова уж на�?а тяжелая доля. Почему-то никого не удивляет, что добавление в ма�?ину электростеклоподъемника стоит денег. Почему это должно удивлять в случае с сайтом? Тут нам очень поможет ТЗ, которое как раз описывает пожелания заказчика на старте проекта и содержит его (закачика) согласие, в виде подписи и печати. Фиксируйте пожелания заказчика, оценивайте их. Согласуйте описание пожеланий и оценку с клиентом. Если стоимость доработки невысока и не выводит проект за рамки бюджета – вы можете это сделать, как "подарок" заказчику, в противном случае – нужна соответствующая компенсация ва�?их _дополнительных_ работ. (кстати, PMP не рекомендует вносить "бесплатные" доработки и называет это Gold Plating) Далее в статье перечисляются очень слабо-применимые, при коммерческой разработке сайтов, методики, типа XP, подход притянут за у�?и. Почему, я подробнее напи�?у несколько позже. Продолжим:

�? все же нам нужно чем-то заменить отсутствие формального технического задания, – ведь мы должны сделать то, что требуется заказчику.

�?менно в Техническом Задании изложено то, чего хочет Заказчик. Отсутствие технического задания позволит Заказчику _бесконечно_ требовать доработок, а проект этот никогда не завер�?иться. Хотя где-то я видел и такой подход, когда проект превращался в процесс. Напоминаю, что это мой взгляд на проблему, в контексте _коммерческой_ разработки. Описанный автором подход тоже может работать, но я хотел бы увидеть также и описание бизнес-модели компании, которая бы обеспечивала гарантированную безубыточную деятельность при таком подходе. Это может быть работа по схеме Time-and-material, но найдите мне российского клиента который согласится на такую схему…