Добрый день,

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

Перевод статьи Джеффри Джеймса «The 8 Stupidest Management Fads of All Time»

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

Недавно дошли руки до превращения записи моего доклада на AgileKitchen в полноценный слайдкаст.

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

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

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

Теперь хочу подробно разобрать пример построения контрольной карты Шухарта на основе реальных данных. В качестве реальных данных я взял историческую информацию о завершенных личных задачах. Эта информация у меня есть благодаря адаптации под себя модели личной эффективности Дэвида Аллена Getting Things (про это у меня тоже есть старый слайдкаст в трех частях: Часть 1, Часть 2, Часть 3 + Excel-табличка с макросами для анализа задач из Outlook ).

Постановка задачи выглядит так. У меня имеется распределение среднего числа завершенных задач в зависимости от дня недели (ниже на графике) и нужно ответить на вопрос: «есть ли что-то особенное в понедельниках или это всего лишь погрешность системы?»



Ответим на этот вопрос при помощи контрольной карты Шухарта – основного инструмента статистического управления процессами.

Практически каждый разработчик задается вопросами, как ему следует развивать свои навыки и какое направление роста выбрать: вертикальное — то есть, стать управленцем, либо горизонтальное — фулстек. Многолетняя работа над одним продуктом, вопреки мифам, становится не ограничением, а полезной возможностью. В этой статье мы делимся опытом нашего backend разработчика Алексея, который посвятил 6 лет сертификациям и прошел за это время путь до архитектора.