Как стать автором
Обновить

Комментарии 17

такое чувство, что во всех этих «школах менеджмента» преподают именно заголовки как незыблемые правила.
Похоже на то. При чём, есть стойкое ощущение, что авторы «материала» для этих школ «пороху не нюхали» и даже понятия не имеют, почему за правила вроде: "Совершенно не имеет значения насколько грешен менеджер: пока он приносит прибыль, достигает поставленных целей, успешно развивает бизнес или просто в хороших отношениях с нужными людьми, все грехи его будут прощены" — кто-то из таких менеджеров потом «внезапно» остаётся инвалидом или т.п. (уж простите меня за цинизм, но жизнь иногда и много циничней). Есть грани, которые нужно чётко понимать и которые на пути к своему успеху переходить нельзя (если не готов мириться с их последствиями).
Ой, да история стара как мир, не умеешь — учи.
Разумеется, всегда есть исключения, и преподов «нюхавших пороху» найти можно.
Однако у меня буквально под носом есть пример — чел преподает непосредственно менеджмент в одном немелком гос.вузе, после его окончания пошел работать по сути коммивояжером, за полгода ничего особо не заработал и с треском вылетел. Вернулся в вуз, написал кандидатскую и поучает всех, включая меня, «как надо» имея статус вузовского преподавателя. И вот вопрос — нужны ли мне его советы, если он теоретик, а я практик?
Да и вообще, если капитан идущего полным ходом на айсберг корабля просто застынет в оцепенении от ужаса, не отдавая никаких команд, то, вполне вероятно, что корабль через какое-то время пойдет ко дну.


Забавно, что вы привели именно этот пример.
Ведь именно в случае с Титаником последовательность менеджерских (капитанских) факапов (поддержание высокой скорости в неподходящих условиях в угоду собственнику, отсутствие бинокля у вахтенного), и последняя судорожная попытка «выправить ситуацию» в итоге и привели к гибели лайнера. А ведь именно в этой ситуации нужно было, просто врезаться в лоб и сохранить корабль. То есть именно менеджер его и погубил.
Впадение в грех №2 в комментарии этом вижу я…
Перекладывать вину, безусловно, плохо. Но к Титанику я, вот честное слово, никакого отношения не имею. :-)
Я к тому, что это задним числом понятно что «нужно было, просто врезаться в лоб и сохранить корабль». А к трагедии, как обычно, привёл не один какой-то косяк, а серия, в целом не очень вероятных, причин. И переборки, и шлюпки и много чего ещё.

Вот так и знал, что подумают про Титаник! И думал о том, что кто-то скажет про лобовое столкновение, мол, не надо было поворачивать. Но все равно использовал эту метафору. И вот почему: во-первых, кроме Титаника от айсбергов затонул не один десяток кораблей, а во-вторых, исследователи говорят, что Титаник реально мог уйти от столкновения (что в сравнении со смятым носом в несколько передних отсеков и немалыми, кстати, жертвами, было бы намного лучше лобового столкновения), если бы решение о повороте было принято оперативнее, что было возможно с учётом реального времени обнаружения айсберга http://titanicsociety.ru/30_seconds_lost/ уверен, что вам будет интересно почитать.

Узнаю себя, когда немного тимлидил.
Причем я сам чувствовал, что делаю что-то не то и не так, а как правильно — не понимал. То есть от этих "грехов" еще и никакого удовольствия.
Поэтому больше и не менеджерю. Вреда больше чем пользы.

Для большинства пунктов безгрешной жизни менеджера нужно кое-что такое, что почти всегда есть у программиста и далеко не всегда есть у остальных. Это кое-что — способность к систематизации сущностей. Для программиста она, как правило, совершенно естественна потому что вшита в мозги на уровне железа. В итоге, когда программист начинает общаться с человеком без такой способности, то программист перестаёт понимать что происходит и начинает считать своего собеседника хамом, лентяем или непроходимым тупицей. А это не так. Если осознавать это обстоятельство и не ожидать от людей невозможного, то становится проще работать.
но S (specific) и, как правило, T (time bound) – это как Отче Наш


нет, оно так не работает. Вы пробовали senior программистам или другим высококвалифицированным инженерам расписывать детально задачу? (т.е. как раз S — specific) на первый раз они молча стерпят, на второй — пошлют со словами, «я сам лучше знаю, как это делать». И ещё обидится.

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

А реализация этого протокола будет разной, в зависимости от ситуации. Традиционно рассматривают две ситуации, высококвалифицироанных сотрудников и низкоквалифицированных. Низкоквалифицированному действительно нужно всё разжевать по пунктам SMART. А вот высококвалифицированным нужно рассказать R — зачем вообще это нужно и пусть он сам расскажет, что конкретно он сделает, когда, в каком виде и что ему для этого нужно.
SMART — это вообще не про задачи. Это про цели. А то, о чём вы пишете, это микро-менеджмент в чистом виде.
SMART применим как к целям (глобальным), так и к задачам
Как вы представляете себе, например, параметр М для задачи?

Цели — это «Что?» и «Для чего?», а задачи — это «Как?» Единственный смысл задачи без цели — потратить ресурсы.
про параметр M для задачи процитирую лучшую статью про SMART, которую я когда-либо видел. Погуглите, будет полезно

Примеры внесения измеримости в задачи:

«Работы должны быть выполнены в соответствии с техническим регламентом»;

«Презентация должна быть представлена в формате Power Point»;

«Уклон дороги должен составлять 6 %, а строительные работы — выполняться с учетом требований техники безопасности»;

«В качестве образца используй прошлогоднюю презентацию»;

«В стандартную форму отчета внеси дополнительный столбец для выделения непредвиденных расходов»;

«Напиши объяснительную записку в свободной форме»;

«Производительность оборудования к концу квартала должна достигнуть 80 %».


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

Это вообще не цель и не задача. Это ограничение. Ну или поясните как именно вы собираетесь измерять «степень соответствия регламенту при выполнении работы»

«Презентация должна быть представлена в формате Power Point»

Это не цель и даже не задача (потому что в нём ничего не говорится о том для чего и/или как это должно быть выполнено). Это требование (нефункциональное).

«Уклон дороги должен составлять 6 %, а строительные работы — выполняться с учетом требований техники безопасности»

Это тоже требования (см. выше). Если уклон будет 2%% это лучше чем если он будет 12%%? В какую сторону должны быть направлены усилия тех, кто будет этот уклон формировать?

«В качестве образца используй прошлогоднюю презентацию»

Это вообще не несёт никакой смысловой нагрузки.

«В стандартную форму отчета внеси дополнительный столбец для выделения непредвиденных расходов»

Это более-менее похоже на цель, но она категорически не SMART (в том числе в части М — если столбцов будет внесено не один, а семь можно ли сказать что результаты превзошли ожидания?)

«Напиши объяснительную записку в свободной форме»

Опять мимо. Здесь вообще ничего измерить нельзя!

«Производительность оборудования к концу квартала должна достигнуть 80 %»

Под конец вам (или автору статьи) почти удалось. Почти, потому что не указано 80% от чего. От производительности на начало квартала? От максимальной производительности по итогам прошлого года? От проектной производительности?

В общем, судя по всему, все статьи про SMART которые вы видели были, мягко говоря, не очень… Так что погуглить, в данной ситуации, лучше вам!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации