Комментарии 52
Если не секрет, сколько человек у вас в команде?
На тот момент, когда были написаны данные документы в команде проекта было 25 сотрудников. В самой компании было 110.
А сейчас, видимо, уже меньше? Достаточно резкий документ, а как же творчество?
Принципы в статье можно разделить на 2 части: ответственное отношение сотрудника к работе (пп. 3-10) и правила использования ХХХ (пп. 1, 2, 11-13).
При соотношении 25 чел. в команде на одного менеджера без ХХХ никуда, менеджер не может помнить кто и что делает. Если работы в проекте достаточно сильно связаны, то так же без активного использования ХХХ вообще никак. Скорее всего, проект классический водопадный (фиксированы сроки, функционал, качество и стоимость) и даже реализуется без внутреннего agile, поэтому требование к полноте задач (п.12) и отсутствие правил про релизы/итерации. Тут есть что развивать, но при достаточном допуске по стоимости и времени можно и так успешно завершать проекты.
По принципам формулировки грубоваты. Но по сути хорошо, если сотрудник будет до последнего скрывать проблемы по задаче (п.5)? Или приходить к руководителю только с эмоциями, без предварительного самостоятельного анализа из-за чего они (п.9)? Или втихаря сделать не то, что просили (интерпретировав как понравилось) (п.8)? Это не имеет никакого отношения к ограничению творчества (как писали в комментариях ниже). Фактически, пункты 3-10 можно переформулировать как «оперативно обсуждайте проблемы вместо молчания». Адекватное поведение взрослого человека, который не хочет подставить своего руководителя.
При соотношении 25 чел. в команде на одного менеджера без ХХХ никуда, менеджер не может помнить кто и что делает. Если работы в проекте достаточно сильно связаны, то так же без активного использования ХХХ вообще никак. Скорее всего, проект классический водопадный (фиксированы сроки, функционал, качество и стоимость) и даже реализуется без внутреннего agile, поэтому требование к полноте задач (п.12) и отсутствие правил про релизы/итерации. Тут есть что развивать, но при достаточном допуске по стоимости и времени можно и так успешно завершать проекты.
По принципам формулировки грубоваты. Но по сути хорошо, если сотрудник будет до последнего скрывать проблемы по задаче (п.5)? Или приходить к руководителю только с эмоциями, без предварительного самостоятельного анализа из-за чего они (п.9)? Или втихаря сделать не то, что просили (интерпретировав как понравилось) (п.8)? Это не имеет никакого отношения к ограничению творчества (как писали в комментариях ниже). Фактически, пункты 3-10 можно переформулировать как «оперативно обсуждайте проблемы вместо молчания». Адекватное поведение взрослого человека, который не хочет подставить своего руководителя.
Творчество это хорошо. Можно проявлять творчество в подходах по решению задач, и.т.д.
На тот момент мы активно занимались системной интеграцией и быстро росли. В силу различных причин, не из за документа, сейчас приоритетным направлением осталась разработка ПО. Сейчас в компании чуть меньше 40 сотрудников.
На тот момент мы активно занимались системной интеграцией и быстро росли. В силу различных причин, не из за документа, сейчас приоритетным направлением осталась разработка ПО. Сейчас в компании чуть меньше 40 сотрудников.
А как давно это было?
Каков результат введения этих двух документов, и не рано ли его оценивать и уж тем более публиковать в качестве серебряной пули?
Фразы «об одном из подходов, который в моем случае сработал. По итогу количество косяков и взаимных конфликтов руководитель-подчиненный стало значительно меньше.» маловато…
Каков результат введения этих двух документов, и не рано ли его оценивать и уж тем более публиковать в качестве серебряной пули?
Фразы «об одном из подходов, который в моем случае сработал. По итогу количество косяков и взаимных конфликтов руководитель-подчиненный стало значительно меньше.» маловато…
Кто является таким ответственным лицом? Если не явно несказанно, то тот, кто дает поручения.
Вот не совсем согласен. Опыт показывает, что лучше назначать ответственным лицом как раз-таки исполнителя. То есть иными словами: «получил задачу — запиши». Тем самым мы решаем проблему превратного понимания задачи исполнителем. Пусть пишет, как понял он, а вы потом уже поймете — правильно он понял или нет. И дополните, если что.
НЛО прилетело и опубликовало эту надпись здесь
Согласен. Всегда лучше оставить за исполнителем письменное занесение задачи. Убиваем двух зайцев: проверка у исполнителя понимания поставленной задачи и занесение собственноручно задачи лучше мотивирует к ее исполнению.
Вы мне напоминаете неопытного программиста, который, вместо того, что бы взять и написать, мечется между технологиями, и меняет архитектуру после каждой прочитанной статьи.
Не совсем понял аналогию. Можно пояснить, если не трудно?
А мне кажется, эти мысли схожи с этой сегодняшней статьей Паралич анализа: вы знаете слишком много, чтобы просто писать код
Казалось бы, что все должно быть хорошо, ан нет: есть, увы, какие-то подводные камни.
Казалось бы, что все должно быть хорошо, ан нет: есть, увы, какие-то подводные камни.
Автор, спасибо за пост, я в такой же ситуации =), только со значительно меньшим коллективом :D
с нетерпением жду продолжения
с нетерпением жду продолжения
Статья про ошибки сотрудников с текстом
Ну нечего, бываетвыглядит достаточно странно…
Не раскрыт вопрос, как сотруднику быть с объективно идиотскими заданиями при таких принципах, такие задачи бывают в любой области, вот классический пример.
Задача:
Необходимо нарисовать 7 перпендикулярных красных линий
Дополнение:
Три линии необходимо нарисовать зеленым цветом, а две прозрачным.
Распишите пожалуйста как тут быть, если пункты 1-3 можно выполнить без усилий, то далее при текущей авторитарной манере управления мы получаем не выполненное задание, сниженную мотивацию, сорванный проект и виноватыми всех, кроме руководителя который поставил эту задачу и который уверен что: «Принцип 7. Расширенное толкование полученного задания не допускается»; И что: «Несогласие с параметрами задания или регламентами исполнения не может служить поводом для их игнорирования», а также с " Принцип 10. Ваше задание – это только ваше задание."
Меня всю статью не покидало ощущение, что она писалась маркетологом, который далее захочет впарить программу ХХХ, а все пункты отношения к реальной жизни и проектам не имеют, поправьте если я ошибаюсь.
Задача:
Необходимо нарисовать 7 перпендикулярных красных линий
Дополнение:
Три линии необходимо нарисовать зеленым цветом, а две прозрачным.
Распишите пожалуйста как тут быть, если пункты 1-3 можно выполнить без усилий, то далее при текущей авторитарной манере управления мы получаем не выполненное задание, сниженную мотивацию, сорванный проект и виноватыми всех, кроме руководителя который поставил эту задачу и который уверен что: «Принцип 7. Расширенное толкование полученного задания не допускается»; И что: «Несогласие с параметрами задания или регламентами исполнения не может служить поводом для их игнорирования», а также с " Принцип 10. Ваше задание – это только ваше задание."
Меня всю статью не покидало ощущение, что она писалась маркетологом, который далее захочет впарить программу ХХХ, а все пункты отношения к реальной жизни и проектам не имеют, поправьте если я ошибаюсь.
Все верно. Конечно вы не поймете если читаете по диагонали и вырываете мысли из контекста.
Что касается принципа 7, то там ясно сказано:
То есть все уточнения должны быть на этапе анализа, а не тогда, когда задача уже принята в работу. Если работник считает, что задачу нельзя выполнить, пусть говорит об этом до начала работ. Естественно возможна ситуация, когда неразрешимая проблема появляется после начала работ, но в этом случае эту проблему так же нужно анализировать, а значит и вносить изменения в задачу, и это работа руководителя.
Что качается принципа 10, то что же в нем плохого? Если человеку делегировали задачу, то человек отвечает за ее выполнение или делегирует другому (если у него есть на то полномочия), но даже в этом случае это не снимает с него ответственности. Иначе я, получив задачу от нашего гена, просто передам ее работникам и в случае неудачи буду пожимать плечами и валить всю вину на них. Так работа не пойдет.
Что касается принципа 7, то там ясно сказано:
Сроки, требования, условия выполнения задания необходимо обсуждать при анализе только что полученного задания. В процессе выполнения задания трактовать возникшие обстоятельствам в свою пользу не допускается.
То есть все уточнения должны быть на этапе анализа, а не тогда, когда задача уже принята в работу. Если работник считает, что задачу нельзя выполнить, пусть говорит об этом до начала работ. Естественно возможна ситуация, когда неразрешимая проблема появляется после начала работ, но в этом случае эту проблему так же нужно анализировать, а значит и вносить изменения в задачу, и это работа руководителя.
Что качается принципа 10, то что же в нем плохого? Если человеку делегировали задачу, то человек отвечает за ее выполнение или делегирует другому (если у него есть на то полномочия), но даже в этом случае это не снимает с него ответственности. Иначе я, получив задачу от нашего гена, просто передам ее работникам и в случае неудачи буду пожимать плечами и валить всю вину на них. Так работа не пойдет.
Еще раз я про ситуацию, задачу обсудили одни а скинули ее на другого работника, с формулировкой: «Вы же профессионал, сделайте.»
Но при этом, закреплена только ответственность работника и его время, но не время принятия решений руководителем и ответственность руководителя, однобоко не правда ли?
По 10 пункту, кроме делегирования задачи необходимо обеспечить исполнителя необходимым инструментом и данными, а то: «Если в процессе выполнения задания ему потребуется какая-либо помощь, информация, взаимодействие с другими людьми – это не снимает с него ответственность за вовремя законченное задание. », напоминает: «Я тебе задачу дал а ты совокупляйся с ней как хочешь, но чтоб к обеду было сделано»
Еще раз подчеркну, авторитарный тип управления и прочие KPI инструменты хороши для «конвеерных» работ, но абсолютно не подходят для задач, где есть хоть малейший элемент творчества, а программы и отчеты убивают всякое желание делать дело, а заставляют лишь писать бесполезные писульки, чтоб соответствовать системе ХХХ и набрать в ней бонусы.
Естественно возможна ситуация, когда неразрешимая проблема появляется после начала работ, но в этом случае эту проблему так же нужно анализировать, а значит и вносить изменения в задачу, и это работа руководителя.
Но при этом, закреплена только ответственность работника и его время, но не время принятия решений руководителем и ответственность руководителя, однобоко не правда ли?
По 10 пункту, кроме делегирования задачи необходимо обеспечить исполнителя необходимым инструментом и данными, а то: «Если в процессе выполнения задания ему потребуется какая-либо помощь, информация, взаимодействие с другими людьми – это не снимает с него ответственность за вовремя законченное задание. », напоминает: «Я тебе задачу дал а ты совокупляйся с ней как хочешь, но чтоб к обеду было сделано»
Еще раз подчеркну, авторитарный тип управления и прочие KPI инструменты хороши для «конвеерных» работ, но абсолютно не подходят для задач, где есть хоть малейший элемент творчества, а программы и отчеты убивают всякое желание делать дело, а заставляют лишь писать бесполезные писульки, чтоб соответствовать системе ХХХ и набрать в ней бонусы.
Можно добавить принцип обсуждать задачу вместе с исполнителем. Мы обычно так и делаем у себя. Здесь проблема обычно в другом — руководитель уверен, что он знает как решить задачу, хотя его решение иногда бывают неверными, а вдолбить это в голову руководителя очень сложно.
Можно так же добавить основной принцип менеджмента — можно делегировать обязанности, но не ответственности.
По поводу 10 пункта согласен, очень уж жесткая формулировка, не учитывающая изменение сроков и требований.
Можно так же добавить основной принцип менеджмента — можно делегировать обязанности, но не ответственности.
По поводу 10 пункта согласен, очень уж жесткая формулировка, не учитывающая изменение сроков и требований.
Подписываюсь к RicoX.
> То есть все уточнения должны быть на этапе анализа, а не тогда, когда задача уже принята в работу.
То есть, получив задачку, исполнитель срочно должен бросить все текущие дела (несмотря на пп. 4, 7 и 10) и въедливо изучить все материалы по задаче, с диким стрессом из-за боязни что-нибудь важное пропустить, что потом придётся в соответствии с п. 7 ползать по ковру?
А если после фазы анализа анализировавший уйдёт на больничный, а задачку кинут непричастному?
> То есть все уточнения должны быть на этапе анализа, а не тогда, когда задача уже принята в работу.
То есть, получив задачку, исполнитель срочно должен бросить все текущие дела (несмотря на пп. 4, 7 и 10) и въедливо изучить все материалы по задаче, с диким стрессом из-за боязни что-нибудь важное пропустить, что потом придётся в соответствии с п. 7 ползать по ковру?
А если после фазы анализа анализировавший уйдёт на больничный, а задачку кинут непричастному?
Давно хочу сделать то же у себя в отделе. Если вы, автор, не против, использую ваш документ, по результатам сообщу.
До создания этих двух документов у вас были прописаны должностные обязанности сотрудников?
В вас живет натуральный микро-менеджер.
Вы хотите всё и вся подчинить правилам и схемам, но при этом ждете от сотрудников инициативы и самостоятельности.
Так не бывает.
А штрафы — это вообще, конечно, лол.
Использовать ХХХ для каждого чиха — это тоже менеджмент головного мозга. В итоге сотрудники полдня ковыряются с софтом, вместо того, чтобы работать свою работу.
Почему-то многие выпускники всяких там МВА и прочих курсов забывают, что менеджмент — это, прежде всего, работа людей с людьми, а не бумажки, правила, штрафы, ХХХ, диаграмы, митинги и прочая лабуда. Так же как и фотошоп — это не дизайн, а IDE — не программирование.
Есть всего три вещи, соблюдение которых уже даст половину успеха.
1. Прозрачность процессов
2. Открытость управленцев
3. Просчет рисков
И для этого не надо рисовать накаких диаграм, нужно просто быть нормальным пацаном, решать возникающие вопросы, прикрывать и защищать команду и знать проект лучше всех.
Вы хотите всё и вся подчинить правилам и схемам, но при этом ждете от сотрудников инициативы и самостоятельности.
Так не бывает.
А штрафы — это вообще, конечно, лол.
Использовать ХХХ для каждого чиха — это тоже менеджмент головного мозга. В итоге сотрудники полдня ковыряются с софтом, вместо того, чтобы работать свою работу.
Почему-то многие выпускники всяких там МВА и прочих курсов забывают, что менеджмент — это, прежде всего, работа людей с людьми, а не бумажки, правила, штрафы, ХХХ, диаграмы, митинги и прочая лабуда. Так же как и фотошоп — это не дизайн, а IDE — не программирование.
Есть всего три вещи, соблюдение которых уже даст половину успеха.
1. Прозрачность процессов
2. Открытость управленцев
3. Просчет рисков
И для этого не надо рисовать накаких диаграм, нужно просто быть нормальным пацаном, решать возникающие вопросы, прикрывать и защищать команду и знать проект лучше всех.
Использование тех или иных инструментов зависит от размера проекта, объема и разнообразие задач, а также количества втянутых в него подрядчиков, субподрядчиков, представителей генподрядчика, поставщиков, представителей заказчика, ревизионных комиссий банка, который ссуды дает Заказчику и генподрядчику, представителей шеф монтажных организаций, представителей проектного института, и.т.д.
И с ними так или иначе нужно взаимодействовать.
(Это далеко не все участники с которыми мне так или иначе общаться).
По поводу микроменеджера… может быть… хотя минимальный объем задачи, который должен быть занесен в систему это 8 часов. Если меньше делай без системы… фиксируй по факту.
Проблема в том, что задач много. Людям свойственно забывать. Забыл отправить поставщику письмо с просьбой предоставить документы на совместимость оборудования (казалось бы задача на 5 минут — отправить емайл, потом получить, распечатать и приложить в документам) выливается в срыв сдачи объекта т.к. комиссия не принимает.
И с ними так или иначе нужно взаимодействовать.
(Это далеко не все участники с которыми мне так или иначе общаться).
По поводу микроменеджера… может быть… хотя минимальный объем задачи, который должен быть занесен в систему это 8 часов. Если меньше делай без системы… фиксируй по факту.
Проблема в том, что задач много. Людям свойственно забывать. Забыл отправить поставщику письмо с просьбой предоставить документы на совместимость оборудования (казалось бы задача на 5 минут — отправить емайл, потом получить, распечатать и приложить в документам) выливается в срыв сдачи объекта т.к. комиссия не принимает.
В таком случае, просто стоит подарить человеку блокнот с надписью «мешочек для мозгов». Чтобы записывал туда все дела на день, если сам додуматься до подобного не может.
И у меня сложилось ощущение, что вы там один менеджер на всю команду. Один управленец на 25 человек — многовато. Самое время выделять тимлидов и общаться с ними, а не пытаться уследить за каждым.
И у меня сложилось ощущение, что вы там один менеджер на всю команду. Один управленец на 25 человек — многовато. Самое время выделять тимлидов и общаться с ними, а не пытаться уследить за каждым.
Распишу свое мнение по постановке задач, откровенное вредительство и саботаж исключим, считаем что все сотрудники нейтральны или довольны а также в состоянии выполнить задачу. Итак я лично встречал 3 типа сотрудников:
1) Задачу нужно ставить «по алгоритму». Пример:
Вот тебе молоток, гвоздь, вон там на стене есть крестик, необходимо забить молотком гвоздь в этот крестик на 10см., держать гвоздь шляпкой к себе, вот видеоурок и инструкция по забиванию гвоздей молотком для правши и т.д. Ставим срок сами, сами проверяем результат.
2) Задачу необходимо ставить «по результату». Пример:
Вон там висит сейф, над ним нужно повесить вот эту картину, выбор гвоздя, молотка или шурупа и отвертки и т.д. оставляем за исполнителем, ставим контрольный срок исполнения и вид отчета, отчет делает исполнитель.
3) Постановка задачи «по проблеме». Пример:
У нас есть сейф, необходимо чтоб он не бросался в глаза посетителям. Все остальное оставляем на выбор исполнителя, будь то картина, зеркало, шкаф или другие средства маскировки а также необходимые инструменты, определяем бюджет и срок, но срок должен быть расплавчатый, например к конце недели и назначен исполнителем (если нас срок и предложенный вариант решения устраивает — утверждаем бютжет). Отчитывается исполнитель сам в указанный им же срок, в остальные этапы руководитель не стоит за спиной и не мешает советами.
И так главное не перепутать кому как ставить задачу, если руководитель перепутал, то тут сразу вылезают авралы, недовольство, сорванные сроки и проекты, при этом все исполнители могут быть отличными специалистами и искренне хотеть сделать все в лучшем виде. Мне кажется подход описанный в статье рассматривает только первый тип постановки задач, но забывает про 2 других.
1) Задачу нужно ставить «по алгоритму». Пример:
Вот тебе молоток, гвоздь, вон там на стене есть крестик, необходимо забить молотком гвоздь в этот крестик на 10см., держать гвоздь шляпкой к себе, вот видеоурок и инструкция по забиванию гвоздей молотком для правши и т.д. Ставим срок сами, сами проверяем результат.
2) Задачу необходимо ставить «по результату». Пример:
Вон там висит сейф, над ним нужно повесить вот эту картину, выбор гвоздя, молотка или шурупа и отвертки и т.д. оставляем за исполнителем, ставим контрольный срок исполнения и вид отчета, отчет делает исполнитель.
3) Постановка задачи «по проблеме». Пример:
У нас есть сейф, необходимо чтоб он не бросался в глаза посетителям. Все остальное оставляем на выбор исполнителя, будь то картина, зеркало, шкаф или другие средства маскировки а также необходимые инструменты, определяем бюджет и срок, но срок должен быть расплавчатый, например к конце недели и назначен исполнителем (если нас срок и предложенный вариант решения устраивает — утверждаем бютжет). Отчитывается исполнитель сам в указанный им же срок, в остальные этапы руководитель не стоит за спиной и не мешает советами.
И так главное не перепутать кому как ставить задачу, если руководитель перепутал, то тут сразу вылезают авралы, недовольство, сорванные сроки и проекты, при этом все исполнители могут быть отличными специалистами и искренне хотеть сделать все в лучшем виде. Мне кажется подход описанный в статье рассматривает только первый тип постановки задач, но забывает про 2 других.
Согласен на все 100%, если выполняются несколько условий:
1. Команда работает уже вместе продолжительное время
2. Все знают кто как работает и у кого какие требования к выполнению/делегированию задач.
В этом случае все, что написал уже вжилось в корпоративную культуру.В случае прихода новичка, ему приходится довольно сложно следовать неписанным правилам и зачастую нарушать табу.
Есть даже теоретические модели под это, к примеру ситуативная модель руководства Херси и Бланшара.
Стиль S1 требует, чтобы руководитель сочетал большую степень ориентированности на задачу и малую — на человеческие отношения. Этот стиль называется «давать указания»;
Второй стиль S2 — «продавать» — подразумевает, что стиль руководителя в равной и в высокой степени ориентирован и на задачу, и на отношения. В этой ситуации подчиненные хотят принять ответственность, но не могут, так как обладают средним уровнем зрелости (М2).Таким образом, руководитель выбирает поведение, ориентированное на задачу, чтобы давать конкретные инструкции подчиненным относительно того, что и как надо делать.
Третий стиль S3 характеризуется умеренно высокой степенью зрелости (МЗ). В этой ситуации подчиненные могут, но не хотят отвечать за выполнение задания. Для руководителя, сочетающего низкую степень ориентированности на задачу и высокую степень — на человеческие отношения, самым подходящим будет стиль, основанный на участии подчиненных в принятии решений, потому что подчиненные знают, что и как надо выполнять, и им не требуется конкретных указаний
Четвертый стиль S4 характеризуется высокой степенью зрелости (М4). В этой ситуации подчиненные и могут, и хотят нести ответственность. Здесь более всего подходит стиль делегирования, а поведение руководителя может сочетать низкую степень ориентированности на задачу и на человеческие отношения.
1. Команда работает уже вместе продолжительное время
2. Все знают кто как работает и у кого какие требования к выполнению/делегированию задач.
В этом случае все, что написал уже вжилось в корпоративную культуру.В случае прихода новичка, ему приходится довольно сложно следовать неписанным правилам и зачастую нарушать табу.
Есть даже теоретические модели под это, к примеру ситуативная модель руководства Херси и Бланшара.
Стиль S1 требует, чтобы руководитель сочетал большую степень ориентированности на задачу и малую — на человеческие отношения. Этот стиль называется «давать указания»;
Второй стиль S2 — «продавать» — подразумевает, что стиль руководителя в равной и в высокой степени ориентирован и на задачу, и на отношения. В этой ситуации подчиненные хотят принять ответственность, но не могут, так как обладают средним уровнем зрелости (М2).Таким образом, руководитель выбирает поведение, ориентированное на задачу, чтобы давать конкретные инструкции подчиненным относительно того, что и как надо делать.
Третий стиль S3 характеризуется умеренно высокой степенью зрелости (МЗ). В этой ситуации подчиненные могут, но не хотят отвечать за выполнение задания. Для руководителя, сочетающего низкую степень ориентированности на задачу и высокую степень — на человеческие отношения, самым подходящим будет стиль, основанный на участии подчиненных в принятии решений, потому что подчиненные знают, что и как надо выполнять, и им не требуется конкретных указаний
Четвертый стиль S4 характеризуется высокой степенью зрелости (М4). В этой ситуации подчиненные и могут, и хотят нести ответственность. Здесь более всего подходит стиль делегирования, а поведение руководителя может сочетать низкую степень ориентированности на задачу и на человеческие отношения.
Важный момент: ХХХ должна уметь отображать время постановки задачи, иначе может быть такой диалог:
— почему задачу не выполнил?
— ее нет в ХХХ?
— как это нет? вот она…
— почему задачу не выполнил?
— ее нет в ХХХ?
— как это нет? вот она…
С удовольствием прочитал статью, но в сухом остатке весь смысл: «важно использовать систему управления проектами». Да, бюрократии и «разборок с софтом» с ней становится больше, но тут, как и в любом деле, главное не доводить до крайности.
А если не секрет что за XXX (в личку?)
Интересно провести хронометраж деятельности сотрудников. Я понимаю, что в больших проектах просто необходим контроль за выполнением этапов, но вот как на счет «текучки»? В этом комментарии habrahabr.ru/post/218435/#comment_7472353 приводится пример с письмом — задачей на 5 минут. Но с учетом работы системы ХХХ это уже будет далеко не 5 минут. А сколько подобных задач на протяжении дня? Конечно, если у работника не сверх-узкая специализация.
Как по мне, то подобный способ работы больше напоминает ситуацию, когда руководителя подчиненные уже «достали» и он решил «закрутить гайки», перекрыв все лазейки и возможные отмазки. Если подчиненный на этапе оценки задания что-то не учел, то потом это его проблемы. Из своего опыта знаю, что если задача (как здесь уже было сказано продолжительностью от 8 часов) достаточно крупная, то проанализировать ее — это уже сделать достаточно большую часть работы. Продолжу пример с сейфом. Практически, работник должен прикинуть, чем лучше закрыть сейф — зеркалом, картиной или какой-то полочкой. Сколько стоит зеркало необходимого размера, картина, полка. Если картина, то что лучше: заказать печать на холсте или купить готовую репродукцию («Эй, народ. Делаю опрос: что лучше… Ок, заказываем печать. Фотографию с корпоратива печатаем? Нет? А что тогда?...» <продолжаются прения>). От выбора что вешаем переходим к выбору на что вешаем и чем вешаем. То есть, когда будет список вариантов на утверждение (или самостоятельное решение), то будет готова львиная часть работы. Предположим, что некто Сидоров заканчивает свое текущее задание завтра в 15:00 (согласно системе ХХХ). Начальник дает задание Сидорову начать проект по скрытию сейфа завтра в 15:30. Ведь на тот момент он уже будет свободен. Что имеем? Сидоров вместо своего текущего задания тратит время на анализ нового приключения, выполняя его процентов на 60-70. А потом сидит ночью, чтобы наверстать упущенное. Ладно, он таки справился.Задание принял и с 15:30 прнялся за сейф. А вот тут самое интересное. Купили зеркало/картину/полочку. Пригласили слесаря просверлить дырку для крепления. И тут слесарь говорит: «Знаете, тут ни сверлить, ни гвозди забивать нельзя — проходят кабели охранной системы...» Ой! К директору бы пойти… Вот только «проблемы индейцев шерифа не волнуют»… Сейф должен был быть закрыт, по заданию принято закрыть зеркалом/картиной/полкой. Sik! А насчет проводов — вы же задание приняли, вот и разгребайтесь сами.
Работая в одной компании на должности руководителя среднего звена как-то получил в начальники одного товарища, который был ярым приверженцем чекитов, тасков и шедулеров. Высочайшее начальство сначала очень ценило новаторский подход. Хватило на 2 месяца.
Как по мне, то подобный способ работы больше напоминает ситуацию, когда руководителя подчиненные уже «достали» и он решил «закрутить гайки», перекрыв все лазейки и возможные отмазки. Если подчиненный на этапе оценки задания что-то не учел, то потом это его проблемы. Из своего опыта знаю, что если задача (как здесь уже было сказано продолжительностью от 8 часов) достаточно крупная, то проанализировать ее — это уже сделать достаточно большую часть работы. Продолжу пример с сейфом. Практически, работник должен прикинуть, чем лучше закрыть сейф — зеркалом, картиной или какой-то полочкой. Сколько стоит зеркало необходимого размера, картина, полка. Если картина, то что лучше: заказать печать на холсте или купить готовую репродукцию («Эй, народ. Делаю опрос: что лучше… Ок, заказываем печать. Фотографию с корпоратива печатаем? Нет? А что тогда?...» <продолжаются прения>). От выбора что вешаем переходим к выбору на что вешаем и чем вешаем. То есть, когда будет список вариантов на утверждение (или самостоятельное решение), то будет готова львиная часть работы. Предположим, что некто Сидоров заканчивает свое текущее задание завтра в 15:00 (согласно системе ХХХ). Начальник дает задание Сидорову начать проект по скрытию сейфа завтра в 15:30. Ведь на тот момент он уже будет свободен. Что имеем? Сидоров вместо своего текущего задания тратит время на анализ нового приключения, выполняя его процентов на 60-70. А потом сидит ночью, чтобы наверстать упущенное. Ладно, он таки справился.Задание принял и с 15:30 прнялся за сейф. А вот тут самое интересное. Купили зеркало/картину/полочку. Пригласили слесаря просверлить дырку для крепления. И тут слесарь говорит: «Знаете, тут ни сверлить, ни гвозди забивать нельзя — проходят кабели охранной системы...» Ой! К директору бы пойти… Вот только «проблемы индейцев шерифа не волнуют»… Сейф должен был быть закрыт, по заданию принято закрыть зеркалом/картиной/полкой. Sik! А насчет проводов — вы же задание приняли, вот и разгребайтесь сами.
Работая в одной компании на должности руководителя среднего звена как-то получил в начальники одного товарища, который был ярым приверженцем чекитов, тасков и шедулеров. Высочайшее начальство сначала очень ценило новаторский подход. Хватило на 2 месяца.
90% косяков везде, где я ни работал, случалось по вот этому небольшому количеству причин:
1. Гиперконформизм, доверие мнению толпы — сотрудник использует метод/принцип/подход, о котором многие из его окружения хорошо отзываются, спотыкается на нем, но продолжает колоться, «ибо миллионы мух не могут ошибаться».
2. Нежелание осознавать границы своей компетентности — думают, что раз они чего-то не знают, то этого нет — как итог, решают только понятую ими часть задачи и оспаривают остальное ближе к концу работ. Спрашиваешь, разве нельзя было уточнить непонятные моменты при получении задачи — отвечают, что тогда было всё понятно, такие дела.
1. Гиперконформизм, доверие мнению толпы — сотрудник использует метод/принцип/подход, о котором многие из его окружения хорошо отзываются, спотыкается на нем, но продолжает колоться, «ибо миллионы мух не могут ошибаться».
2. Нежелание осознавать границы своей компетентности — думают, что раз они чего-то не знают, то этого нет — как итог, решают только понятую ими часть задачи и оспаривают остальное ближе к концу работ. Спрашиваешь, разве нельзя было уточнить непонятные моменты при получении задачи — отвечают, что тогда было всё понятно, такие дела.
>> разве нельзя было уточнить непонятные моменты при получении задачи
Да, нельзя. Потому что уточнить заранее все моменты задачи — это значит решить ее. Вспомните, сколько времени вы отводите подчиненым на оценку задачи, секунд 30? Хороший пример приведен в комментарии выше про сейф, картину и провода.
Да, нельзя. Потому что уточнить заранее все моменты задачи — это значит решить ее. Вспомните, сколько времени вы отводите подчиненым на оценку задачи, секунд 30? Хороший пример приведен в комментарии выше про сейф, картину и провода.
Собственно почти все ваши принципы взяты из семинара «Центрирующие парадигмы» Александра Фридмана.
Возможно он их тоже откуда-то взял ранее, суть не в этом.
Творческим людям работать по такой системе невозможно, говорю на собственном опыте, пропадает любая мотивация, когда тебя считают роботом, а не человеком. По мне так важен человеческий подход прежде всего, а эти парадигмы настраивают человека на негатив. Возможно они и хороши для низкоквалифицированного персонала, но не для ITшников, я был очень недоволен работая по «Фридману» и считаю это время самым ужасным в моей практике.
Возможно он их тоже откуда-то взял ранее, суть не в этом.
Творческим людям работать по такой системе невозможно, говорю на собственном опыте, пропадает любая мотивация, когда тебя считают роботом, а не человеком. По мне так важен человеческий подход прежде всего, а эти парадигмы настраивают человека на негатив. Возможно они и хороши для низкоквалифицированного персонала, но не для ITшников, я был очень недоволен работая по «Фридману» и считаю это время самым ужасным в моей практике.
Винтиками и шпунтиками руководить проще. Это же механизм. А чтобы сделать механизм, нужно убить в человеке что-то уникальное, загадку личности. Нет никаких допущений, есть формулы и графики. Эриха Фрома всем менеджерам отчасти не хватает www.youtube.com/watch?v=JEp9O1ZLJNQ ))
Для бизнеса это хорошо по большей части, но для человека как вы описали — это убийство личности и право на уникальность и гениальность. Но… все таки это люди в команде были, а не сам Сэр Фридаман. Если они не видят в вас личность и загадку, воспринимать их как людей согласен, очень сложно.)
Для бизнеса это хорошо по большей части, но для человека как вы описали — это убийство личности и право на уникальность и гениальность. Но… все таки это люди в команде были, а не сам Сэр Фридаман. Если они не видят в вас личность и загадку, воспринимать их как людей согласен, очень сложно.)
Гм… не участвовал / не видел данного семинара. Стоящая вещь? Но да вы правы… часть заметок действительно взята у Фридмана, Гагина, Дена Кеннади.
К сожалению, не всегда нужно творчество. Иногда нужно просто сделать большой кусок рутинной работы по ГОСТ/ТУ и.т.д. Мне тоже претит когда людей называют human resource и относятся к ним так же и гораздо ближе тот подход, который описан в «Маверик» Рикардо Семплера.
К сожалению, не всегда нужно творчество. Иногда нужно просто сделать большой кусок рутинной работы по ГОСТ/ТУ и.т.д. Мне тоже претит когда людей называют human resource и относятся к ним так же и гораздо ближе тот подход, который описан в «Маверик» Рикардо Семплера.
Не повезло тем, кто у вас работает. Управление проектом это очень хорошо, но выдвигание задач в ультимативной форме, а потом какие-то наказания за не решения. Ну, это знаете, ни за какие деньги в подобную контору лучше не устраиваться. А то придётся надувать шарики в виде котов.
Здесь есть тонкая грань между порядком и хаосом. Собственно данный документ не спустился в ультимативной форме от диктатора компании… его обсуждали, критиковали и правили. Никто не мешает внести в него изменения. Есть здравые мысли почему бы их не вписать. На мой взгляд это лучше, чем неуправляемый хаос и постоянные залеты и разборы с Заказчиком.
Кстати здравая мысль при трудоустройстве интересоваться «а как у вас отслеживается выполнение задач по проекту и вообще сами проекты. Расскажите пожалуйста».
Кстати здравая мысль при трудоустройстве интересоваться «а как у вас отслеживается выполнение задач по проекту и вообще сами проекты. Расскажите пожалуйста».
Что изменилось после введения этих принципов и стандартов? Сколько прошло времени?
Мы уже 10 лет пользуемся примерно такой системой, только она так строго не описана
1) Группа людей должна быть разделена подгруппы
2) подгруппа не должна превышать 9-10 человек
3) на 10 человек должно быть 2 специалиста 1 — полный техник до мозга и костей, 2 — писака/говорика
4) Если возникла проблема и мы не знаем как ее решить — немедленно сообщить о ней, если мы знаем как ее решить, решить и немедленно сообщит о решении, если сомневаемся, сообщить о проблеме и сообщить о возможных вариантах решения
5) для выполнения пункта 4 есть технарь и писака/говорика. Они помогут убрать эмоции и составить некий план
6) Техник и Писака — могут входить в группы, они просто ведущие группой
7) Кто старше — зависит от конкретного проекта, обычно это регулирует сам руководитель проекта, а техник и второй на одном уровне. Это рождает споры, а в спорах рождается истина, которую уже доносят до руководителя
8) Было еще одно звено. «Старший смены» — мифический персонаж, который умеет всё :) (он просто может понять когда нужно сообщить, а когда можно решить самому)
При такой схеме работы команда более чем в 45 человек работала как часы. (покрывала 3 или 4 разных направления, поддержка, разработка, настройка и т.д.) (2 техника, 2 писака/говорика, 2 старших смены)
Если кто-то проявил инициативу и ошибся — штрафовать не нужно
и не нужно не штрафовать.
Лучше сделать штраф, и спустя час-два премию с полным объяснением где он был не прав и где он был прав.
Еще лучше работает самоистязание, когда человек сам говорит что с ним сделать.
Руководитель проекта общается только с 5ю людьми. Только 5 человек ему что-то сообщают.
подГруппы «варятся» внутри себя. По подгруппе видно кто начинает «лажать». Можно принимать меры, распределять задачи.
Тут именно психология играет роль. Нельзя управлять больше чем 4-8 людьми. Так же как нельзя концентрироваться больше чем на 4-8 процессах.
В итоге получается некое дерево управления. Команда работала 24/7. Эту систему у меня сперли несколько организаций)
Схема: 1-2-(2-2)-(10-10-10-10)-5 (выходит 52 человека)
Не забываем оставить личный контакт с каждым человеком. Ведь не все вопросы можно решить через других, есть человеческий фактор
И самое главное. Если есть проблема — мы ее решаем
Если Есть не очень хорошее решение, а других решений нет — используем его. Не стоим на месте.
1) Группа людей должна быть разделена подгруппы
2) подгруппа не должна превышать 9-10 человек
3) на 10 человек должно быть 2 специалиста 1 — полный техник до мозга и костей, 2 — писака/говорика
4) Если возникла проблема и мы не знаем как ее решить — немедленно сообщить о ней, если мы знаем как ее решить, решить и немедленно сообщит о решении, если сомневаемся, сообщить о проблеме и сообщить о возможных вариантах решения
5) для выполнения пункта 4 есть технарь и писака/говорика. Они помогут убрать эмоции и составить некий план
6) Техник и Писака — могут входить в группы, они просто ведущие группой
7) Кто старше — зависит от конкретного проекта, обычно это регулирует сам руководитель проекта, а техник и второй на одном уровне. Это рождает споры, а в спорах рождается истина, которую уже доносят до руководителя
8) Было еще одно звено. «Старший смены» — мифический персонаж, который умеет всё :) (он просто может понять когда нужно сообщить, а когда можно решить самому)
При такой схеме работы команда более чем в 45 человек работала как часы. (покрывала 3 или 4 разных направления, поддержка, разработка, настройка и т.д.) (2 техника, 2 писака/говорика, 2 старших смены)
Если кто-то проявил инициативу и ошибся — штрафовать не нужно
и не нужно не штрафовать.
Лучше сделать штраф, и спустя час-два премию с полным объяснением где он был не прав и где он был прав.
Еще лучше работает самоистязание, когда человек сам говорит что с ним сделать.
Руководитель проекта общается только с 5ю людьми. Только 5 человек ему что-то сообщают.
подГруппы «варятся» внутри себя. По подгруппе видно кто начинает «лажать». Можно принимать меры, распределять задачи.
Тут именно психология играет роль. Нельзя управлять больше чем 4-8 людьми. Так же как нельзя концентрироваться больше чем на 4-8 процессах.
В итоге получается некое дерево управления. Команда работала 24/7. Эту систему у меня сперли несколько организаций)
Схема: 1-2-(2-2)-(10-10-10-10)-5 (выходит 52 человека)
Не забываем оставить личный контакт с каждым человеком. Ведь не все вопросы можно решить через других, есть человеческий фактор
И самое главное. Если есть проблема — мы ее решаем
Если Есть не очень хорошее решение, а других решений нет — используем его. Не стоим на месте.
Рекомендую прочитать «Догнать Зайца».
В вашем кратком пересказе «Послание к генералу Гарсия» вы упустили один, на мой взгляд, ключевой момент. А именно кто поручил Роуэну доставить письмо.
Если бы это был не президент США, а мелкий клерк, то и результат был бы скорее всего иным.
Если бы это был не президент США, а мелкий клерк, то и результат был бы скорее всего иным.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему сотрудники делают глупые ошибки и что с этим делать.Часть 1