Комментарии 33
Страх и все, что с ним связанно, в большей степени влияют на людей, чем что-то положительное и приятное. А еще страх хорошо мотивирует
Если мне не изменяет память, то в целом негативная мотивация работает хуже позитивной. Ваше бескомпромиссное высказывание на этот счёт заставляет сомневаться и в действенности остальных пунктов.
Ну почему же вы так категорично? Там все написано, что не стоит с этим усердствовать, а использовать такой подход в меру. И это психологический момент, не мной придуманный, а выясненный и утверждаемый психологами.
Не согласиться с ними я не могу, по себе сужу, что страх может значительно мотивировать
Не согласиться с ними я не могу, по себе сужу, что страх может значительно мотивировать
НЛО прилетело и опубликовало эту надпись здесь
В разработке ПО по большей степени применяются все методы, описанные здесь. И всё равно все сроки летят к чертям =)
Если честно, читая заголовок, думал здесь будет что-то действительно неизвестное и действенное
Если честно, читая заголовок, думал здесь будет что-то действительно неизвестное и действенное
При прочтении статьи тоже мысленно не согласился с автором про страх. Если я действительно на работе часто(или даже периодически) буду бояться чего-то, я эту работу 100% сменю. Любые вычеты на меня действуют исключительно деморализующие и я объясню почему. Работая в командах, мы психологически склонны винить кого угодно и до последнего защищать себя. Игроки командных игр (например DotA или же футболл во дворе) думаю отлично это знают. И получается, что виновата «команда дебилов», а наказали и вас тоже. Отсюда чувство несправедливости и уход. В общем, перед тем как применять метод последствий, тщательно изучите свою команду. На автора это сработает в плюс, а на меня точно в минус.
Станислав, в моём восприятии откликается основная цель вашей статьи — приоритет на дедлайне, особенно то, что вы выбрали основной стратегией помочь коллегам понять пользу соблюдения сроков! Особенно универсальными, а от этого полезными более широко, мне показались пункты об Объяснении и Эффективных инструментах. Объяснение, потому что точно зная пользу, которую вы доведёте до коллеги, он точнее поймёт и выполнит задачу. А правильно подобранный инструмент позволит избежать ограничений, навязанных атавизмами другого неподходящего инструмента.
Я бы хотел выделить, то, с чего нужно начать строить приоритет и важность, на мой взгляд, и очень жаль, что мысль спряталась в середине статьи:
«Следуйте такой модели всегда. Ведь именно она дает полное представление о дедлайнах. Понимание – это ключ, помогающий с большей ответственностью и серьезностью относиться к срокам».
Если вы понимаете особую ценность дедлайна, нужно вписать это в конституцию своей компании или команды!
Тогда все остальные пункты станут второстепенными и не придётся влиять на восприятие коллег уже в начатом проекте, иначе каждое изменение будет стоит титанических усилий. И наоборот, принципы, с которыми согласились при старте работы, даже раньше старта отдельных проектом, ставшие базовыми принципами — будут легко применяться в проектах.
Я не полностью понял основные пункты советов: Ставьте только реальные дедлайны и Позволяйте команде ставить сроки. Неуниверсально, так как часто дедлайн ставит заказчик, которому нужно успеть к старту второй стадии его проекта. Я понимаю, что опыт аналогичных проектов нужно учесть на стадии составления плана работ, где как раз появятся понимание дедлайна.
Но в итоге, из трёх основных измерений — срок, бюджет, функциональность — придётся чем-то пожертвовать, ведь за даже в быту за город на отдых не выехать без изменения в сроке поездки, бюджете или количестве посмотренных достопримечательностей :-), что говорить более сложных проектах в компаниях, где каждый раз получается, не так:
а так:
картинки я взял со страницы принципов работы Бюро Горбунова
Я бы хотел выделить, то, с чего нужно начать строить приоритет и важность, на мой взгляд, и очень жаль, что мысль спряталась в середине статьи:
«Следуйте такой модели всегда. Ведь именно она дает полное представление о дедлайнах. Понимание – это ключ, помогающий с большей ответственностью и серьезностью относиться к срокам».
Если вы понимаете особую ценность дедлайна, нужно вписать это в конституцию своей компании или команды!
Тогда все остальные пункты станут второстепенными и не придётся влиять на восприятие коллег уже в начатом проекте, иначе каждое изменение будет стоит титанических усилий. И наоборот, принципы, с которыми согласились при старте работы, даже раньше старта отдельных проектом, ставшие базовыми принципами — будут легко применяться в проектах.
Я не полностью понял основные пункты советов: Ставьте только реальные дедлайны и Позволяйте команде ставить сроки. Неуниверсально, так как часто дедлайн ставит заказчик, которому нужно успеть к старту второй стадии его проекта. Я понимаю, что опыт аналогичных проектов нужно учесть на стадии составления плана работ, где как раз появятся понимание дедлайна.
Но в итоге, из трёх основных измерений — срок, бюджет, функциональность — придётся чем-то пожертвовать, ведь за даже в быту за город на отдых не выехать без изменения в сроке поездки, бюджете или количестве посмотренных достопримечательностей :-), что говорить более сложных проектах в компаниях, где каждый раз получается, не так:
а так:
картинки я взял со страницы принципов работы Бюро Горбунова
Дельно. Особенно на примере поездки за город. Сроки всегда и везде меняются и будут меняться — это истина)
Объясню по поводу пунктов, которые вы не поняли. В принципе, по поводу реальных сроков все написано в статье, добавить нечего. А вот второй пункт — конечно, это не универсально, как и многие советы а-ля «сделайте это, и вы будете счастливы», или «ешьте это, и проживете до 100 лет». Но если ситуация позволяет подключить команду, то можно пробовать. По крайней мере объяснение с точки зрения психологии у этого пункта есть. А сработает или нет — все зависит от ситуации
Объясню по поводу пунктов, которые вы не поняли. В принципе, по поводу реальных сроков все написано в статье, добавить нечего. А вот второй пункт — конечно, это не универсально, как и многие советы а-ля «сделайте это, и вы будете счастливы», или «ешьте это, и проживете до 100 лет». Но если ситуация позволяет подключить команду, то можно пробовать. По крайней мере объяснение с точки зрения психологии у этого пункта есть. А сработает или нет — все зависит от ситуации
Спасибо, что пояснили!
Когда речь о принципах работы и их описании, я склонен внедрять и применять только безусловно универсальные решения. Как лекарства в медицине вводят только после высочайшего процента воздействия на определенные участки организма. Иначе плацебо было бы и то эффективнее.
Так и в принципах соблюдения дедлайнов в работе. Простой пример: в мастерской печати на тканях нужно изготовить плакат к 8 мая, потому что 9 мая заказчик понесёт плакат в руках на демонстрации в центре города. Принципиально похожих примеров и в масштабных проектах — масса, а значит возможность сдвига сроков не могу считать истиной.
Другое дело, что если, в крайнем случае, придётся резать по живому и чем то жертвовать, то функциональностью, а не дедлайном. Например, не нанимать шрифтовика, а сделать на плакате надпись готовым шрифтом или, к примеру, использовать более простой метод нанесения краски на ткань.
Собственно, идея приоритетов на дедлайне полностью перекликается с вашими идеями в статье.
Принципы менять нельзя. То «да», то «нет» при регламентировании — не выход. Согласны?
Сроки всегда и везде меняются и будут меняться — это истина)
Когда речь о принципах работы и их описании, я склонен внедрять и применять только безусловно универсальные решения. Как лекарства в медицине вводят только после высочайшего процента воздействия на определенные участки организма. Иначе плацебо было бы и то эффективнее.
Так и в принципах соблюдения дедлайнов в работе. Простой пример: в мастерской печати на тканях нужно изготовить плакат к 8 мая, потому что 9 мая заказчик понесёт плакат в руках на демонстрации в центре города. Принципиально похожих примеров и в масштабных проектах — масса, а значит возможность сдвига сроков не могу считать истиной.
Другое дело, что если, в крайнем случае, придётся резать по живому и чем то жертвовать, то функциональностью, а не дедлайном. Например, не нанимать шрифтовика, а сделать на плакате надпись готовым шрифтом или, к примеру, использовать более простой метод нанесения краски на ткань.
Собственно, идея приоритетов на дедлайне полностью перекликается с вашими идеями в статье.
Принципы менять нельзя. То «да», то «нет» при регламентировании — не выход. Согласны?
И ни слова про управление рисками…
Не совсем понимаю, почему именно в ЭТОЙ статье должно быть про управление рисками?
Риски, крутая и важная тема. Правда очень обширная. А какую часть темы о рисках вы бы осветили в статье о побуждении сотрудников соблюдать сроки?
Например, введение подобного правила:
При возникновении отклонения следует незамедлительное извещение инициатору запроса.
Отсюда вытекает, что при возникновении отклонения необходимо предотвратить задержку принятия корректирующих действий руководителем проекта.
Или такого:
Знание о невыполнимости задачи в срок не освобождает сотрудника от ответственности за ее выполнение.
Требование для сотрудника — предотвратить задержку принятия корректирующих действий руководителем при постановке первоначальной задачи.
Требование для руководителя – при непонимании сотрудником поставленной задачи требуется минимизировать время для корректировки декомпозиции выполнения или для постановки новой цели.
При возникновении отклонения следует незамедлительное извещение инициатору запроса.
Отсюда вытекает, что при возникновении отклонения необходимо предотвратить задержку принятия корректирующих действий руководителем проекта.
Или такого:
Знание о невыполнимости задачи в срок не освобождает сотрудника от ответственности за ее выполнение.
Требование для сотрудника — предотвратить задержку принятия корректирующих действий руководителем при постановке первоначальной задачи.
Требование для руководителя – при непонимании сотрудником поставленной задачи требуется минимизировать время для корректировки декомпозиции выполнения или для постановки новой цели.
Извините, но не могу не написать. В вашем же посыле даже после прочтение несколько раз ничего не понятно
Речь идет о применении ограничений при управлении командой. Что именно не понятно? Готов пояснить…
Вы формулируете предложения таким образом, что они сложны для восприятия. Чем больше подряд идущих существительных в родительном падеже, тем сложнее это воспринимается
Возможно получилось излишне формализовано. Я не Лев Толстой.) Попробую по другому…
В бытность проекта по запуску первого лунохода на Луну подразделения под управлением Королева С.П. решали вопрос о составе почвы на спутнике Земли. Из-за возникших споров проект никак не мог стартовать. Одни были убеждены в том, что почва на Луне состоит из космической пыли и поэтому необходима соответствующая конструкция и форма колес. Другие настаивали на каменистости спутника и убеждали всех в альтернативном решении вопроса.
В один из дней, когда все пришли на работу, на стене компании был прибит лист со следующей формулировкой: «Луну считать твердой. (с) Королев С.П.»
Споры были прекращены и проект успешно стартовал, завершившись запуском лунохода. Как потом выяснилось, почва и правда была каменистой, но главный вывод в том, что при принятии парадигмы удалось сдвинуть проект с мертвой точки.
Это пример использования парадигм управления — правил, утвержденных руководителем и принятых к обязательному исполнению подчиненными.
В бытность проекта по запуску первого лунохода на Луну подразделения под управлением Королева С.П. решали вопрос о составе почвы на спутнике Земли. Из-за возникших споров проект никак не мог стартовать. Одни были убеждены в том, что почва на Луне состоит из космической пыли и поэтому необходима соответствующая конструкция и форма колес. Другие настаивали на каменистости спутника и убеждали всех в альтернативном решении вопроса.
В один из дней, когда все пришли на работу, на стене компании был прибит лист со следующей формулировкой: «Луну считать твердой. (с) Королев С.П.»
Споры были прекращены и проект успешно стартовал, завершившись запуском лунохода. Как потом выяснилось, почва и правда была каменистой, но главный вывод в том, что при принятии парадигмы удалось сдвинуть проект с мертвой точки.
Это пример использования парадигм управления — правил, утвержденных руководителем и принятых к обязательному исполнению подчиненными.
Игорь, согласен, описание в правилах, как действовать, в случае сбоя принесёт пользу команде. Да и в сущности управления рисками нужно, чтобы минимизировать ущерб при сбоях. Но сначала нужно наладить и описать принципы работы без сбоев, систему. А как побудить сотрудников её соблюдать? Мне показалось, что свой взгляд на это и описал автор.
Соблюдать систему всегда легче на основе установленных правил. Достаточно лишь их определить и согласовать со всеми участниками процесса.
Точно. Поэтому я описал выше, что нужно соблюдение сроков сделать основным принципом команды. Корректировать по факту, внутри проекта будет менее эффективно.
В описание системы необходимо заложить и правила по соблюдению правил. Всё просто. Вы же программисты!
Из интересных и полезных продуктов, рекомендую посмотреть в сторону 3SL Cradle.
«Как подсознательно побудить сотрудников соблюдать дедлайны проекта» -> «Как побудить сотрудников подсознательно соблюдать дедлайны проекта»
«Как подсознательно повлиять на команду?» -> Как повлиять на подсознание членов команды?"
А то у вас какой-то самогипноз получается.
«Как подсознательно повлиять на команду?» -> Как повлиять на подсознание членов команды?"
А то у вас какой-то самогипноз получается.
Настоящим самураям программистам дедлайн не страшен.
Т.к. они уже представили, что дедлайн наступил и прошел.
Поэтому работают одинаково, как до дедлайна, так и после.
<:o)
Т.к. они уже представили, что дедлайн наступил и прошел.
Поэтому работают одинаково, как до дедлайна, так и после.
<:o)
Большинство дедлайнов на самом деле ни на что не влияют. Обычно в этих случаях еще и изменение задачи в процессе идет без изменения сроков. Единственно важный дедлайн, это когда ты можешь отказаться от части функциональности (и с этим никто не спорит, потому что понимает, что реально важно) и успеть в срок.
Это применимо для любого «дедлайна» важного или не важного.
Т.е. будет сделано, то что будет сделано.
По мне любой дедлайн — это мощный демотиватор для команды.
Причем не важно успели или не успели.
Если не успели, то понятно.
А если успели, то после делайна обычно «расслабляются».
Но после дедлайна работа не должна прекращаться.
Вот и живут от дедлайна, до дедлайна.
Т.е. будет сделано, то что будет сделано.
По мне любой дедлайн — это мощный демотиватор для команды.
Причем не важно успели или не успели.
Если не успели, то понятно.
А если успели, то после делайна обычно «расслабляются».
Но после дедлайна работа не должна прекращаться.
Вот и живут от дедлайна, до дедлайна.
Дедлайн имеет смысл, когда он действительно дед
Обычно точное выполнение дедлайнов возможно при выполнении стандартной работы — типа колки дров (есть топор, есть дрова, есть место куда дрова складывать)
Реализация нового продукта таит столько неизвестностей, что дедлайн не выполняется, как правило.
Здесь главное не срок, а стабильное движение к реализации, то есть работа должна проводится по принципу Петра Леонидовича Капицы — Сегодня мы стали немного умнее
Любой дедлайн ненастоящий. Продукт не возьмется внезапно из ниоткуда, а потому дедлайн имеет свойство сдвигаться до готовности некоторого core-функционала. Поэтому любая привязка ко времени малоэффективна по сути своей.
Страх действует только первые пару дедлайнов. Потом привыкаешь и к штрафам, и к истеричным звонкам менеджеров, и к призывам «поднажать». Человек не может каждый месяц жить в стрессе. Он либо привыкает и это становится рутиной, либо меняет работу.
Не понимаю таких, кто эффективно работает только под давлением. Такое мышление мне не просто понятно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как подсознательно побудить сотрудников соблюдать дедлайны проекта