Пользователь
0,0
рейтинг
7 апреля 2014 в 08:57

Управление → Почему сотрудники делают глупые ошибки и что с этим делать.Часть 1

Как-то один из персонажей популярного сериала заявил «Все врут!». И это отчасти правда. И что уж 100% правда, что все лажают. Каждый может вспомнить, когда наши сотрудники не выполнили взятые на себя обязательства, сорвали сроки, что-то сделали — но совсем не то, а иногда лучше бы вообще не проявляли инициативу. К сожалению, лажают не только сотрудники, но и руководители. Самое печальное в этом то, что работают далеко не дураки, но бывают такие глупые epic fail, что и говорить не хочется.



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

Часть 1. Предыстория «Как кто-то играл в шахматы, а кто-то в шашки».


У меня шел очередной ИТ проект, плюс обычная работа (стандартная матричная структура управления).

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

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

Первой моей реакцией было: «Ну бывает. К ошибкам нужно относится терпимее, это собственно и есть — накопление опыта и зрелости». Я гордился своим взвешенным подходом — настоящий матерый управленец.

Я разговаривал с каждым сотрудником по факту каждого косяка, спрашивал у него: «Чему ты теперь научился?». А после разговора трепал по плечу: «Ну ничего, бывает. Важно, что ты понял, что сделал неправильно. В следующий раз такого уже не будет.».

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

К середине проекта я уже был очень теоретически подкованный парень в области управления проектами (прошел несколько курсов и получил PMP). Нужен научный подход! Это была моя вторая попытка что-то сделать.

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

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



Это лишь привело к тому что мой телефон раскалялся от звонков типа: «У нас кончились метизы, где нам их взять?», «У нас тут ошибка выскочила, но не критическая можно работать дальше. Нужно звонить разработчикам?». Никто не хотел сделать ни одного лишнего шага без согласования.

Потом была попытка №3. Я решил пересмотреть должностные инструкции, описать основные бизнес процессы, учесть в деталях все нюансы. Итог закономерен — я утонул в деталях.

Окончательно меня добил рассказ Элберта Хаббарда «Послание к генералу Гарсия». Небольшой рассказ буквально несколько страниц. Далее будет спойлер… настоятельно рекомендую прочитать рассказ самостоятельно.

В двух словах содержание
Идет война. Нужно передать послание лидеру повстанцев. Где он находится – никто не знает. Как его найти – тоже непонятно. Вызывали простого парня по имени Роуэн и вручили ему письмо, назвав только конечного адресата – генерала Гарсия. Роуэн взял письмо, запечатал его в мешочек на груди и исчез в джунглях. Через три недели он доставил письмо генералу Гарсия. Как он это сделал и через что прошел, чтобы доставить письмо Гарсия — загадка. Но он это сделал, не задавая лишних вопросов, не прося лишних ресурсов, не жалуясь ни на что — просто взял и сделал.

Я перебрал у себя в голове весь свой персонал… никто бы из них не смог доставить письмо. Не было такого человека, которому можно просто сказать конечный результат, и он бы добился его.

Я не помню, когда у меня появилась идея: нужно сформулировать правила игры. То есть нужно задать начальные координаты наших отношений руководитель – подчиненный. Что-то такое, на что можно было опираться, когда нужно принять решение или выполнить задачу в условиях недостаточной информации.

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

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

Итоговым вариантом нашей совместной работы стали два документа:
  1. «Принципы Менеджмента»
  2. «Фирменные стандарты»


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

Во втором документе описываются общие стандарты поведения и принятия решений в условиях недостаточной информации – лекарство от неопределенности. В аннотации к данному документу написан следующий текст:

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

Здесь будет приведены только «Принципы Менеджмента», т.к. объем статьи и так стал большим. Фирменные стандарты я опишу в следующей статье, если будет интерес.

Часть 2. Принципы Менеджмента


Отступление:
  1. Часть из нижеизложенных принципов я честно скопировал, часть написана моими сотрудниками, часть написана мной. Я не помню, откуда они появлялись. Если вы обнаружили свои мысли, сообщите я поставлю внизу ссылки.
  2. У нас использовалась на тот момент специализированная ИТ система для управления проектами и задачами, я заменил ее название на XXX


Принцип 1: Прозрачность.


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

Данная прозрачность достигается путем использования специализированной системы XXX

Принцип 2: Все в одном месте


Все коммуникации по рабочим вопросам должны идти только через XXX. Результаты встречи, телефонного разговора, Lync общения и аськи ответственное лицо должно внести все достигнутые договоренности в XXX.

Кто является таким ответственным лицом? Если явно несказанно, то тот, кто дает поручения.
Вывод 1: В случае, если задача не была поставлена в XXX ее можно не выполнять. Последствий за это не будет. (За исключением экстренных ситуаций и аварий)
Вывод 2: Если задача не отмечена как выполненная в XXX, она считается не выполненной.

Принцип 3. Полученное задание должно быть проанализировано перед началом работы


Получив задание исполнитель должен его проанализировать. Целью анализа является оценка достаточности собственных ресурсов, а именно:
  • Понимание – оценка ясности самого задания, как по целям, так и по способам исполнения. Кроме того, необходимо учесть другие параметры сроки, требования по качеству, приоритетность.
  • Квалификация – оценка собственных знаний и навыков, необходимых для выполнения задания с учетом требуемых параметров
  • Информации – оценка ее полноты для выполнения задания с учетом требуемых параметров
  • Времени — оценка возможности выполнения задания в требуемые сроки с учетом остальных обязательств по ранее полученным заданиям, рутинным обязанностям.
  • Полномочия – оценка достаточности полномочий для выполнения задания (сравнение имеющихся полномочий и тех, которые вручены вместе с заданием)


Принцип 4. Полученное задание должно быть выполнено на 100%


Работа делится на две части: выполненная с учетом всех обязательств и условий в задании, и не выполненная. Другими словами, либо результат есть, либо его нет.

Принцип 5. О препятствиях к 100% выполнению задания необходимо немедленно сообщать руководителю и всем заинтересованным лицам


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

Принцип 6. Предложение по решению проблемы предпочтительнее чем информация по ее возникновению


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

Принцип 7. Расширенное толкование полученного задания не допускается


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

Принцип 8. Несогласие с параметрами задания или регламентами исполнения не может служить поводом для их игнорирования


Если вы не согласны с параметрами полученного задания, то вы можете их обсудить
  1. При анализе полученного задания
  2. При возникновении ситуации, когда невозможно закончить работу на 100%


Принцип 9. Факты и аргументация предпочтительнее мнения


Мнение сотрудника очень важно, но лучше если оно подкреплено кроме эмоций еще и фактами.

Принцип 10. Ваше задание – это только ваше задание.


За выполнение полученного задания полностью отвечает исполнитель. Если в процессе выполнения задания ему потребуется какая-либо помощь, информация, взаимодействие с другими людьми – это не снимает с него ответственность за вовремя законченное задание.

Принцип 11. Системная работа по проектам в системе XXX


У каждого проекта обязательно есть:
  • Название – кратко суть проекта или его результат
  • Суть проекта. О чем проект? Краткое описание: о чем проект, что должно быть в результате.
  • Контрагент. Для какой организации будет выполняться проект. Если такого контрагента нет, его необходимо добавить
  • Автор проекта, он же ответственный за результаты выполнения проекта.
  • Статус проекта. Если по данному проекту есть активные задачи, которые нужно выполнить, то проект считается активным. (Активными считаются задачи, где-либо есть сроки либо их нужно выполнить до последнего числа текущего месяца)
  • Срок окончания проекта
  • Аудитор проекта – руководитель ответственного лица за результаты проекта.
  • Исполнители проекта. Они могут быть добавлены позже, при назначении задач.


Принцип 12. Правильное планирование работ по проекту


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

Весь проект разбивается на задачи. Задача — это объем работы, который выполняется либо одним человеком, либо в
течение 1 рабочего дня.

Название задачи обязательно начинается с глагола: «Сделать, отправить, получить, спланировать, выполнить, и.т.д.»
У каждой задачи есть:
  • Постановщик задачи.
  • Исполнитель задачи, их может быть несколько.
  • Краткое описание что должно быть сделано.
  • Срок окончания задачи

Дополнительно может использоваться:
  • Файлы
  • Чек листы
  • Напоминание/Повтор задачи
  • Аналитика
  • Заметки / другие источники информации


Принцип 13. Постановка экстренных задач и поручений


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

Если выполнение задачи требует больше времени, она обязательно фиксируется в системе XXX. Если это не сказано явно, ответственным за регистрацию в системе является тот, кто поставил задачу.

В следующей статье я расскажу о наших «Фирменных стандартах» и к чему это все привело.

Продолжение здесь

UPD: Поправил автора рассказа «Послание к генералу Гарсия». Саентологи затуманили мой мозг. Действительно автором данного рассказа является Элберт Хаббард. Спасибо за внимательность хабражителю vfrolov
Сергей Тетерин @ded_Sergei
карма
18,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Управление

Комментарии (52)

  • +1
    Если не секрет, сколько человек у вас в команде?
    • +1
      На тот момент, когда были написаны данные документы в команде проекта было 25 сотрудников. В самой компании было 110.
      • +4
        А сейчас, видимо, уже меньше? Достаточно резкий документ, а как же творчество?
        • +1
          Принципы в статье можно разделить на 2 части: ответственное отношение сотрудника к работе (пп. 3-10) и правила использования ХХХ (пп. 1, 2, 11-13).

          При соотношении 25 чел. в команде на одного менеджера без ХХХ никуда, менеджер не может помнить кто и что делает. Если работы в проекте достаточно сильно связаны, то так же без активного использования ХХХ вообще никак. Скорее всего, проект классический водопадный (фиксированы сроки, функционал, качество и стоимость) и даже реализуется без внутреннего agile, поэтому требование к полноте задач (п.12) и отсутствие правил про релизы/итерации. Тут есть что развивать, но при достаточном допуске по стоимости и времени можно и так успешно завершать проекты.

          По принципам формулировки грубоваты. Но по сути хорошо, если сотрудник будет до последнего скрывать проблемы по задаче (п.5)? Или приходить к руководителю только с эмоциями, без предварительного самостоятельного анализа из-за чего они (п.9)? Или втихаря сделать не то, что просили (интерпретировав как понравилось) (п.8)? Это не имеет никакого отношения к ограничению творчества (как писали в комментариях ниже). Фактически, пункты 3-10 можно переформулировать как «оперативно обсуждайте проблемы вместо молчания». Адекватное поведение взрослого человека, который не хочет подставить своего руководителя.
        • 0
          Творчество это хорошо. Можно проявлять творчество в подходах по решению задач, и.т.д.
          На тот момент мы активно занимались системной интеграцией и быстро росли. В силу различных причин, не из за документа, сейчас приоритетным направлением осталась разработка ПО. Сейчас в компании чуть меньше 40 сотрудников.
      • +4
        А как давно это было?
        Каков результат введения этих двух документов, и не рано ли его оценивать и уж тем более публиковать в качестве серебряной пули?
        Фразы «об одном из подходов, который в моем случае сработал. По итогу количество косяков и взаимных конфликтов руководитель-подчиненный стало значительно меньше.» маловато…
        • +1
          Было примерно 2 года назад. Я не в коем случае не рекомендую использовать это как silver bullet. Это опыт конкретной команды в конкретных условиях. О результатах я попробую остановится подробнее во второй части. Надеюсь завтра опубликую.
  • +2
    Кто является таким ответственным лицом? Если не явно несказанно, то тот, кто дает поручения.

    Вот не совсем согласен. Опыт показывает, что лучше назначать ответственным лицом как раз-таки исполнителя. То есть иными словами: «получил задачу — запиши». Тем самым мы решаем проблему превратного понимания задачи исполнителем. Пусть пишет, как понял он, а вы потом уже поймете — правильно он понял или нет. И дополните, если что.
    • +1
      Имеется ввиду, что если пришло письмо «Надо сделать такую-то ХХХ в такой-то срок» на группу из 6 человек, то ответственным является тот, кто послал такое письмо без указания конкретного исполнителя. Наверное.
      • +1
        Ответственной не должна быть группа людей. Это плохо соотносится со SMART потому что тогда непонятно, как обеспечить единообразие понимание группы. Ну и вообще чревато перекладыванием ответственности с одной головы на другую.
    • 0
      Согласен. Всегда лучше оставить за исполнителем письменное занесение задачи. Убиваем двух зайцев: проверка у исполнителя понимания поставленной задачи и занесение собственноручно задачи лучше мотивирует к ее исполнению.
      • +2
        Есть еще и третий вариант. Если ставить всем задачи письменно, то ни на что другое времени уже не останется.
        • 0
          Возможно вы правы. Все очень сильно зависит от проекта и команды. Конкретно на том проекте я чертовски устал от «пацанских договоренностей». Кто то с кем то когда то договорился… а как сдавать работы, то нечего такого не было.
  • +4
    Вы мне напоминаете неопытного программиста, который, вместо того, что бы взять и написать, мечется между технологиями, и меняет архитектуру после каждой прочитанной статьи.
  • +3
    Автор, спасибо за пост, я в такой же ситуации =), только со значительно меньшим коллективом :D
    с нетерпением жду продолжения
  • +1
    Статья про ошибки сотрудников с текстом
    Ну нечего, бывает
    выглядит достаточно странно…
  • +2
    Не раскрыт вопрос, как сотруднику быть с объективно идиотскими заданиями при таких принципах, такие задачи бывают в любой области, вот классический пример.
    Задача:
    Необходимо нарисовать 7 перпендикулярных красных линий
    Дополнение:
    Три линии необходимо нарисовать зеленым цветом, а две прозрачным.

    Распишите пожалуйста как тут быть, если пункты 1-3 можно выполнить без усилий, то далее при текущей авторитарной манере управления мы получаем не выполненное задание, сниженную мотивацию, сорванный проект и виноватыми всех, кроме руководителя который поставил эту задачу и который уверен что: «Принцип 7. Расширенное толкование полученного задания не допускается»; И что: «Несогласие с параметрами задания или регламентами исполнения не может служить поводом для их игнорирования», а также с " Принцип 10. Ваше задание – это только ваше задание."
    Меня всю статью не покидало ощущение, что она писалась маркетологом, который далее захочет впарить программу ХХХ, а все пункты отношения к реальной жизни и проектам не имеют, поправьте если я ошибаюсь.
    • +1
      Все верно. Конечно вы не поймете если читаете по диагонали и вырываете мысли из контекста.

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

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

      Что качается принципа 10, то что же в нем плохого? Если человеку делегировали задачу, то человек отвечает за ее выполнение или делегирует другому (если у него есть на то полномочия), но даже в этом случае это не снимает с него ответственности. Иначе я, получив задачу от нашего гена, просто передам ее работникам и в случае неудачи буду пожимать плечами и валить всю вину на них. Так работа не пойдет.

      • +1
        Еще раз я про ситуацию, задачу обсудили одни а скинули ее на другого работника, с формулировкой: «Вы же профессионал, сделайте.»
        Естественно возможна ситуация, когда неразрешимая проблема появляется после начала работ, но в этом случае эту проблему так же нужно анализировать, а значит и вносить изменения в задачу, и это работа руководителя.

        Но при этом, закреплена только ответственность работника и его время, но не время принятия решений руководителем и ответственность руководителя, однобоко не правда ли?

        По 10 пункту, кроме делегирования задачи необходимо обеспечить исполнителя необходимым инструментом и данными, а то: «Если в процессе выполнения задания ему потребуется какая-либо помощь, информация, взаимодействие с другими людьми – это не снимает с него ответственность за вовремя законченное задание. », напоминает: «Я тебе задачу дал а ты совокупляйся с ней как хочешь, но чтоб к обеду было сделано»

        Еще раз подчеркну, авторитарный тип управления и прочие KPI инструменты хороши для «конвеерных» работ, но абсолютно не подходят для задач, где есть хоть малейший элемент творчества, а программы и отчеты убивают всякое желание делать дело, а заставляют лишь писать бесполезные писульки, чтоб соответствовать системе ХХХ и набрать в ней бонусы.
        • 0
          Можно добавить принцип обсуждать задачу вместе с исполнителем. Мы обычно так и делаем у себя. Здесь проблема обычно в другом — руководитель уверен, что он знает как решить задачу, хотя его решение иногда бывают неверными, а вдолбить это в голову руководителя очень сложно.

          Можно так же добавить основной принцип менеджмента — можно делегировать обязанности, но не ответственности.

          По поводу 10 пункта согласен, очень уж жесткая формулировка, не учитывающая изменение сроков и требований.
      • +1
        Подписываюсь к RicoX.

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

        То есть, получив задачку, исполнитель срочно должен бросить все текущие дела (несмотря на пп. 4, 7 и 10) и въедливо изучить все материалы по задаче, с диким стрессом из-за боязни что-нибудь важное пропустить, что потом придётся в соответствии с п. 7 ползать по ковру?

        А если после фазы анализа анализировавший уйдёт на больничный, а задачку кинут непричастному?
        • 0
          Занят — Не принимай задачу в работу. Тут нужно сделать отступление, что адаптировалась под конкретную информационную систему.
  • +3
    Давно хочу сделать то же у себя в отделе. Если вы, автор, не против, использую ваш документ, по результатам сообщу.
    • +1
      Без проблем. Делитесь опытом потом.
  • +1
    До создания этих двух документов у вас были прописаны должностные обязанности сотрудников?
    • +1
      Конечно. И должностные инструкции и положение об отделах.
      На мой взгляд иногда не хватает изложить на бумаге какие то очевидные вещи, которые вроде бы всем понятны.
      К примеру: прежде чем брать задачу подумай как ты ее будешь делать, если взялся то сообщи заранее если не успеваешь к сроку, и.т.д.
  • +19
    В вас живет натуральный микро-менеджер.
    Вы хотите всё и вся подчинить правилам и схемам, но при этом ждете от сотрудников инициативы и самостоятельности.
    Так не бывает.

    А штрафы — это вообще, конечно, лол.

    Использовать ХХХ для каждого чиха — это тоже менеджмент головного мозга. В итоге сотрудники полдня ковыряются с софтом, вместо того, чтобы работать свою работу.

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

    Есть всего три вещи, соблюдение которых уже даст половину успеха.
    1. Прозрачность процессов
    2. Открытость управленцев
    3. Просчет рисков

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

    • +3
      Использование тех или иных инструментов зависит от размера проекта, объема и разнообразие задач, а также количества втянутых в него подрядчиков, субподрядчиков, представителей генподрядчика, поставщиков, представителей заказчика, ревизионных комиссий банка, который ссуды дает Заказчику и генподрядчику, представителей шеф монтажных организаций, представителей проектного института, и.т.д.
      И с ними так или иначе нужно взаимодействовать.
      (Это далеко не все участники с которыми мне так или иначе общаться).

      По поводу микроменеджера… может быть… хотя минимальный объем задачи, который должен быть занесен в систему это 8 часов. Если меньше делай без системы… фиксируй по факту.

      Проблема в том, что задач много. Людям свойственно забывать. Забыл отправить поставщику письмо с просьбой предоставить документы на совместимость оборудования (казалось бы задача на 5 минут — отправить емайл, потом получить, распечатать и приложить в документам) выливается в срыв сдачи объекта т.к. комиссия не принимает.

      • +3
        В таком случае, просто стоит подарить человеку блокнот с надписью «мешочек для мозгов». Чтобы записывал туда все дела на день, если сам додуматься до подобного не может.

        И у меня сложилось ощущение, что вы там один менеджер на всю команду. Один управленец на 25 человек — многовато. Самое время выделять тимлидов и общаться с ними, а не пытаться уследить за каждым.

  • +2
    Распишу свое мнение по постановке задач, откровенное вредительство и саботаж исключим, считаем что все сотрудники нейтральны или довольны а также в состоянии выполнить задачу. Итак я лично встречал 3 типа сотрудников:
    1) Задачу нужно ставить «по алгоритму». Пример:
    Вот тебе молоток, гвоздь, вон там на стене есть крестик, необходимо забить молотком гвоздь в этот крестик на 10см., держать гвоздь шляпкой к себе, вот видеоурок и инструкция по забиванию гвоздей молотком для правши и т.д. Ставим срок сами, сами проверяем результат.
    2) Задачу необходимо ставить «по результату». Пример:
    Вон там висит сейф, над ним нужно повесить вот эту картину, выбор гвоздя, молотка или шурупа и отвертки и т.д. оставляем за исполнителем, ставим контрольный срок исполнения и вид отчета, отчет делает исполнитель.
    3) Постановка задачи «по проблеме». Пример:
    У нас есть сейф, необходимо чтоб он не бросался в глаза посетителям. Все остальное оставляем на выбор исполнителя, будь то картина, зеркало, шкаф или другие средства маскировки а также необходимые инструменты, определяем бюджет и срок, но срок должен быть расплавчатый, например к конце недели и назначен исполнителем (если нас срок и предложенный вариант решения устраивает — утверждаем бютжет). Отчитывается исполнитель сам в указанный им же срок, в остальные этапы руководитель не стоит за спиной и не мешает советами.

    И так главное не перепутать кому как ставить задачу, если руководитель перепутал, то тут сразу вылезают авралы, недовольство, сорванные сроки и проекты, при этом все исполнители могут быть отличными специалистами и искренне хотеть сделать все в лучшем виде. Мне кажется подход описанный в статье рассматривает только первый тип постановки задач, но забывает про 2 других.
    • +1
      Согласен на все 100%, если выполняются несколько условий:
      1. Команда работает уже вместе продолжительное время
      2. Все знают кто как работает и у кого какие требования к выполнению/делегированию задач.

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

      Есть даже теоретические модели под это, к примеру ситуативная модель руководства Херси и Бланшара.
      image

      Стиль S1 требует, чтобы руководитель сочетал большую степень ориентированности на задачу и малую — на человеческие отноше­ния. Этот стиль называется «давать указания»;

      Второй стиль S2 — «продавать» — подразумевает, что стиль руководителя в равной и в высокой степени ориентирован и на задачу, и на отношения. В этой ситуации подчиненные хотят принять ответственность, но не могут, так как обладают средним уровнем зрелости (М2).Таким образом, руководитель выби­рает поведение, ориентированное на задачу, чтобы давать конкретные инструкции подчиненным относительно того, что и как надо делать.

      Третий стиль S3 характеризуется умеренно высокой степенью зрелости (МЗ). В этой ситуации подчиненные могут, но не хотят отвечать за выполнение задания. Для руководителя, сочетающего низкую степень ориентированности на задачу и высокую степень — на человеческие отношения, самым подходящим будет стиль, основанный на участии подчиненных в принятии решений, потому что подчинен­ные знают, что и как надо выполнять, и им не требуется конкретных указаний

      Четвертый стиль S4 характеризуется высокой степенью зрелости (М4). В этой ситуации подчиненные и могут, и хотят нести ответственность. Здесь более всего подходит стиль делегирования, а поведение руководителя может сочетать низкую степень ориентированности на задачу и на человеческие отношения.
      • +1
        В S4 на диаграмме ошибка s/высокая — на задачу/низкая — на задачу/g
        Ушел знакомиться с трудами Херси и Бланшара, не знал про них.
  • +1
    Важный момент: ХХХ должна уметь отображать время постановки задачи, иначе может быть такой диалог:
    — почему задачу не выполнил?
    — ее нет в ХХХ?
    — как это нет? вот она…
  • 0
    С удовольствием прочитал статью, но в сухом остатке весь смысл: «важно использовать систему управления проектами». Да, бюрократии и «разборок с софтом» с ней становится больше, но тут, как и в любом деле, главное не доводить до крайности.
  • 0
    А если не секрет что за XXX (в личку?)
    • 0
      Ответил в личку.
      • 0
        Я знаю два проекта, которые умерли по одной причине — в них ХХХ оказался софт под названием JIRA, убогость которого вызвала дикую демотивацию в команде. Если у вас прямо всё-всё-всё через эту систему, проверьте сами и спросите всех, не мешает ли она.
  • +10
    Интересно провести хронометраж деятельности сотрудников. Я понимаю, что в больших проектах просто необходим контроль за выполнением этапов, но вот как на счет «текучки»? В этом комментарии habrahabr.ru/post/218435/#comment_7472353 приводится пример с письмом — задачей на 5 минут. Но с учетом работы системы ХХХ это уже будет далеко не 5 минут. А сколько подобных задач на протяжении дня? Конечно, если у работника не сверх-узкая специализация.
    Как по мне, то подобный способ работы больше напоминает ситуацию, когда руководителя подчиненные уже «достали» и он решил «закрутить гайки», перекрыв все лазейки и возможные отмазки. Если подчиненный на этапе оценки задания что-то не учел, то потом это его проблемы. Из своего опыта знаю, что если задача (как здесь уже было сказано продолжительностью от 8 часов) достаточно крупная, то проанализировать ее — это уже сделать достаточно большую часть работы. Продолжу пример с сейфом. Практически, работник должен прикинуть, чем лучше закрыть сейф — зеркалом, картиной или какой-то полочкой. Сколько стоит зеркало необходимого размера, картина, полка. Если картина, то что лучше: заказать печать на холсте или купить готовую репродукцию («Эй, народ. Делаю опрос: что лучше… Ок, заказываем печать. Фотографию с корпоратива печатаем? Нет? А что тогда?...» <продолжаются прения>). От выбора что вешаем переходим к выбору на что вешаем и чем вешаем. То есть, когда будет список вариантов на утверждение (или самостоятельное решение), то будет готова львиная часть работы. Предположим, что некто Сидоров заканчивает свое текущее задание завтра в 15:00 (согласно системе ХХХ). Начальник дает задание Сидорову начать проект по скрытию сейфа завтра в 15:30. Ведь на тот момент он уже будет свободен. Что имеем? Сидоров вместо своего текущего задания тратит время на анализ нового приключения, выполняя его процентов на 60-70. А потом сидит ночью, чтобы наверстать упущенное. Ладно, он таки справился.Задание принял и с 15:30 прнялся за сейф. А вот тут самое интересное. Купили зеркало/картину/полочку. Пригласили слесаря просверлить дырку для крепления. И тут слесарь говорит: «Знаете, тут ни сверлить, ни гвозди забивать нельзя — проходят кабели охранной системы...» Ой! К директору бы пойти… Вот только «проблемы индейцев шерифа не волнуют»… Сейф должен был быть закрыт, по заданию принято закрыть зеркалом/картиной/полкой. Sik! А насчет проводов — вы же задание приняли, вот и разгребайтесь сами.
    Работая в одной компании на должности руководителя среднего звена как-то получил в начальники одного товарища, который был ярым приверженцем чекитов, тасков и шедулеров. Высочайшее начальство сначала очень ценило новаторский подход. Хватило на 2 месяца.
  • +1
    90% косяков везде, где я ни работал, случалось по вот этому небольшому количеству причин:
    1. Гиперконформизм, доверие мнению толпы — сотрудник использует метод/принцип/подход, о котором многие из его окружения хорошо отзываются, спотыкается на нем, но продолжает колоться, «ибо миллионы мух не могут ошибаться».
    2. Нежелание осознавать границы своей компетентности — думают, что раз они чего-то не знают, то этого нет — как итог, решают только понятую ими часть задачи и оспаривают остальное ближе к концу работ. Спрашиваешь, разве нельзя было уточнить непонятные моменты при получении задачи — отвечают, что тогда было всё понятно, такие дела.
    • +2
      >> разве нельзя было уточнить непонятные моменты при получении задачи

      Да, нельзя. Потому что уточнить заранее все моменты задачи — это значит решить ее. Вспомните, сколько времени вы отводите подчиненым на оценку задачи, секунд 30? Хороший пример приведен в комментарии выше про сейф, картину и провода.
      • 0
        Вы не поняли мой комментарий и отвечаете каким-то своим мыслям.
  • +1
    Собственно почти все ваши принципы взяты из семинара «Центрирующие парадигмы» Александра Фридмана.
    Возможно он их тоже откуда-то взял ранее, суть не в этом.

    Творческим людям работать по такой системе невозможно, говорю на собственном опыте, пропадает любая мотивация, когда тебя считают роботом, а не человеком. По мне так важен человеческий подход прежде всего, а эти парадигмы настраивают человека на негатив. Возможно они и хороши для низкоквалифицированного персонала, но не для ITшников, я был очень недоволен работая по «Фридману» и считаю это время самым ужасным в моей практике.
    • +1
      Винтиками и шпунтиками руководить проще. Это же механизм. А чтобы сделать механизм, нужно убить в человеке что-то уникальное, загадку личности. Нет никаких допущений, есть формулы и графики. Эриха Фрома всем менеджерам отчасти не хватает www.youtube.com/watch?v=JEp9O1ZLJNQ ))
      Для бизнеса это хорошо по большей части, но для человека как вы описали — это убийство личности и право на уникальность и гениальность. Но… все таки это люди в команде были, а не сам Сэр Фридаман. Если они не видят в вас личность и загадку, воспринимать их как людей согласен, очень сложно.)
    • 0
      Гм… не участвовал / не видел данного семинара. Стоящая вещь? Но да вы правы… часть заметок действительно взята у Фридмана, Гагина, Дена Кеннади.
      К сожалению, не всегда нужно творчество. Иногда нужно просто сделать большой кусок рутинной работы по ГОСТ/ТУ и.т.д. Мне тоже претит когда людей называют human resource и относятся к ним так же и гораздо ближе тот подход, который описан в «Маверик» Рикардо Семплера.
  • +3
    Не повезло тем, кто у вас работает. Управление проектом это очень хорошо, но выдвигание задач в ультимативной форме, а потом какие-то наказания за не решения. Ну, это знаете, ни за какие деньги в подобную контору лучше не устраиваться. А то придётся надувать шарики в виде котов.
    • 0
      Здесь есть тонкая грань между порядком и хаосом. Собственно данный документ не спустился в ультимативной форме от диктатора компании… его обсуждали, критиковали и правили. Никто не мешает внести в него изменения. Есть здравые мысли почему бы их не вписать. На мой взгляд это лучше, чем неуправляемый хаос и постоянные залеты и разборы с Заказчиком.

      Кстати здравая мысль при трудоустройстве интересоваться «а как у вас отслеживается выполнение задач по проекту и вообще сами проекты. Расскажите пожалуйста».
  • 0
    Что изменилось после введения этих принципов и стандартов? Сколько прошло времени?
  • +1
    Мы уже 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 человека)
    Не забываем оставить личный контакт с каждым человеком. Ведь не все вопросы можно решить через других, есть человеческий фактор

    И самое главное. Если есть проблема — мы ее решаем
    Если Есть не очень хорошее решение, а других решений нет — используем его. Не стоим на месте.
  • 0
    Рекомендую прочитать «Догнать Зайца».
  • +1
    В вашем кратком пересказе «Послание к генералу Гарсия» вы упустили один, на мой взгляд, ключевой момент. А именно кто поручил Роуэну доставить письмо.
    Если бы это был не президент США, а мелкий клерк, то и результат был бы скорее всего иным.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.