Проекты подразумевают совместную работу. Это значит, что задачи и сроки их завершения у одного члена команды могут значительно влиять на время выполнения у других коллег. Это как эффект домино, где негативные последствия приведут к неконтролируемому расширению масштаба проекта.
Однако вся суть в том, что сроки выполнения соблюдаются редко независимо от того, связано это с работой или повседневной жизнью. По своей природе люди склоны несерьезно относиться ко всему далекому, предполагая, что времени еще достаточно. Как правило, они ошибаются.
Какой здесь психологический подтекст?
Как было сказано выше, такое поведение характерно многим людям в силу своей природы. Психологи выделяют много причин. Приведу некоторые из них.
Мотивация
Доводилось ли вам сдавать экзамен, подготавливаясь к нему всего за ночь? Если да, то вы должны помнить свое волнение. Чем ближе дата важного события, дедлайна проекта или задачи, чем ближе вы к ней приближаетесь, тем больше волнения и нервозности вы ощущаете. В английском языке есть даже специальный термин — Goal Looms Larger Effect.
И вот как психологи описывают его суть: мотивация завершить задачу увеличивается, когда уменьшается количество времени до нее. Чем ближе вы приближаетесь к успеху, тем больше усилия вы вкладываете в его достижение. Другими словами, как только вы приближаетесь к цели (задаче, дедлайну), тем больше вы думаете об этом. И вот это повышенное внимание помогает извлекать выгоду.
Давление
С точки зрения психологии можно объяснить и другие моменты. К примеру, есть категория людей, полагающих, что под давлением они лучше работают. Однако это бессмысленно, поскольку тяжело прилагать максимум усилий в условиях ограниченного количества времени. Отсюда следует, что эти люди совсем не работают без дедлайнов. А если же они поставлены, они все равно стараются растянуть сроки.
Ошибки планирования
А ведь есть еще такое понятие, как ошибка планирования – тенденция неправильно определять время на выполнения любой задачи. На это есть несколько причин.
Мы не учитываем опыт предыдущего планирования. Большинство студентов, будь они даже на последнем курсе, с затруднением оценят период времени на написание курсовой. И это несмотря на то, что до этого как минимум раз в год они ее писали.
Мы не допускаем варианты, что что-то может пойти не так. Планы в нашем представлении всегда идут по наилучшему сценарию. Мы отводим на завершение задачи столько времени, сколько нужно согласно такому ходу событий. Но редко случается, чтобы все шло, как запланировано.
И наконец, мы не учитываем все этапы выполнения задачи и время на выполнение каждого из них. Если студенту необходимо написать курсовую, как правило, он не учитывает время, которое стоит провести в библиотеке или в общении с преподавателем для получения информации. Ему кажется, что все время будет потрачено исключительно на написание. Все остальное он не учитывает.
Но не буду углубляться в дальнейшие нюансы психологии человека, а расскажу, как побудить сотрудников и членов команды уважительно относиться и, главное, соблюдать сроки выполнения задач и проекта в целом.
1. Ставьте только реальные дедлайны
Как часто вы сталкивались с ситуацией, когда на одну и ту же задачу вам ставят несколько финальных сроков? Когда приближается первый дедлайн, становится понятно, что он ненастоящий. Руководитель или менеджер проекта использовал его для манипулирования командой с примерно такими мыслями: если не соблюдаются сроки первого (ненастоящего) дедлайна, то следующий (настоящий) точно будет соблюден. Не самый удачный пример управления, даже если вы гуру и знаете стили руководства в менеджменте.
Как подсознательно повлиять на команду?
Разбейте большие задачи на задачи поменьше с меньшим временным отрезком. Создавайте и назначайте задачи, которые требуют день или два. Члены команды поймут, что они идут непрерывным потоком, и четко обозначенные дедлайны не сложно соблюдать.
2. Позволяйте команде ставить дедлайны
Участники проекта (спонсоры, клиенты, т.д.) зачастую не имеют даже малейшего представления о том, как в нем протекают все процессы. Они не знают, как все работает и как все организованно. Такие лица назначают финальные даты, но исполнители сразу понимают, что их сложно соблюсти.
Как подсознательно повлиять на команду?
Включите в эти процессы команду. Позвольте им оценивать реальные сроки на выполнение задач. Такой шаг охарактеризует вас как находчивого менеджера.
Во-первых, создается атмосфера командной работы. Чем больше вовлеченность в командную работу, тем ответственнее работает участник проекта.
Во-вторых, члены команды устанавливают дедлайны, основанные на реальном понимании предстоящей работы и необходимого для ее выполнения количества времени. Более того, если команды сама устанавливает сроки, им не на что будет жаловаться. Ведь именно они все оценили и просчитали.
3. Объясняйте
Объяснять крайне важно. Недостаточно сказать, когда дедлайн. Обязательно еще уточните, почему это важно. По крайней мере, вы вызовите ответную реакцию.
Будьте точным настолько, насколько этого требует ситуация. Не нужно говорить следующее.
— Все ошибки в проекте должны быть исправлены к следующему понедельнику к 18:00.
Гораздо лучше объяснить важность.
— Все ошибки в проекте должны быть исправлены к следующему понедельнику к 18:00. Это важно, потому что во вторник у нас новый спринт, основанный на всех исправлениях.
Как подсознательно повлиять на команду?
Следуйте такой модели всегда. Ведь именно она дает полное представление о дедлайнах. Понимание – это ключ, помогающий с большей ответственностью и серьезностью относиться к срокам.
4. Делайте акцент на негативных последствиях несоблюденных сроков
Вопрос психологии. Если сроки не соблюдаются, придайте значение негативным последствиям, которые повлияют на весь проект и команду. Страх и все, что с ним связанно, в большей степени влияют на людей, чем что-то положительное и приятное. А еще страх хорошо мотивирует.
Вернемся к примеру выше. Чтобы придать значение негативным результатам, добавим еще одно предложение.
— Все ошибки в проекте должны быть исправлены к следующему понедельнику к 18:00. Это важно, потому что во вторник у нас новый спринт, основанный на всех исправлениях. Если мы не начнем его, спонсоры сократят расходы, и это напрямую повлияет на нашу заработную плату.
Как подсознательно повлиять на команду?
Применяйте эту тактику, но будьте осторожны: слишком частые угрозы могут подорвать моральное состояние. Делайте акцент на негативных последствиях, но не угрожайте вашей команде.
5. Используйте систему напоминаний
Конечно, не стоит ежедневно напоминать о дедлайнах, говоря о них, как попугай, при каждом случае. Но и не следует занимать противоположную позицию, сказав о них раз и забыв.
Попробуйте изобрести свою систему напоминаний или же использовать уже зарекомендовавшую себя. Главное, чтобы она работала.
Как подсознательно повлиять на команду?
Есть очень эффективное решение. Вместо постоянных напоминаний о том, когда задача должна быть выполнена, попробуйте вовлечь членов команды в дискуссию, спросив, когда же дедлайн к той или иной задаче. Если коллега сам ответит на ваш вопрос, значит, он не забудет о сроках.
6. Используйте эффективное ПО
Даже очень опытные менеджеры не всегда вовремя завершают проекты. Хорошим решением будет начать использовать эффективный и надежный инструмент. Конечно, чтобы найти подходящий, может потребоваться много времени. Но это того стоит.
На самом деле, рынок предлагает множество всевозможных инструментов, отличающихся функционалом, рабочими принципами, интерфейсом и т.д. Поэтому в них легко можно затеряться.
Как улучшить командную работу и соблюдать дедлайны?
Выберете инструмент, который уже зарекомендовал себя. К примеру, он может быть основан на методе Канбан. Это наглядная система в виде карточек, показывающая, у кого какие задачи, когда их необходимо завершить и т.д.
Вот как это выглядит на примере популярного сервиса Trello.
В IT-сфере часто используют спринты. Здесь хорошо зарекомендовал себя инструмент JIRA. Менеджер легко создает задачи, назначает ответственных и для каждого спринта ставит дедлайн.
А вот как выглядит проект на примере онлайн диаграммы Ганта GanttPRO. Все задачи здесь визуализированы, видны сроки их выполнения и прогресс.
Впрочем, здесь можно найти подходящий для вас сервис для управления проектами.
Суммируем
В любом проекте важно соблюдать сроки. Но сделать это не всегда легко, особенно если в проекте много задач и участников. Для повышения эффективности попробуйте подсознательно влиять на команду:
- Ставьте только реальные дедлайны;
- Позволяйте команде ставить сроки;
- Объясняйте;
- Делайте акцент на негативных последствиях;
- Используйте систему напоминаний;
- Используйте эффективное ПО.
Комментарии (33)
Drag13
21.07.2017 10:46+1Просто страх это то что идет от руководителя ( и то чем он может гораздо проще управлять) а вот положительные эмоции зависят от него в гораздо меньшей степени. Поэтому страх — проще. Об этом еще г-н Макиавелли писал. Правда все забывают о том, что в отличии от тех времен, сотрудник может просто поменять работу.
kristoft
21.07.2017 11:27+3В разработке ПО по большей степени применяются все методы, описанные здесь. И всё равно все сроки летят к чертям =)
Если честно, читая заголовок, думал здесь будет что-то действительно неизвестное и действенное
Raftko
21.07.2017 11:27+2При прочтении статьи тоже мысленно не согласился с автором про страх. Если я действительно на работе часто(или даже периодически) буду бояться чего-то, я эту работу 100% сменю. Любые вычеты на меня действуют исключительно деморализующие и я объясню почему. Работая в командах, мы психологически склонны винить кого угодно и до последнего защищать себя. Игроки командных игр (например DotA или же футболл во дворе) думаю отлично это знают. И получается, что виновата «команда дебилов», а наказали и вас тоже. Отсюда чувство несправедливости и уход. В общем, перед тем как применять метод последствий, тщательно изучите свою команду. На автора это сработает в плюс, а на меня точно в минус.
Aleksei_Mikhailov
21.07.2017 11:41+3Станислав, в моём восприятии откликается основная цель вашей статьи — приоритет на дедлайне, особенно то, что вы выбрали основной стратегией помочь коллегам понять пользу соблюдения сроков! Особенно универсальными, а от этого полезными более широко, мне показались пункты об Объяснении и Эффективных инструментах. Объяснение, потому что точно зная пользу, которую вы доведёте до коллеги, он точнее поймёт и выполнит задачу. А правильно подобранный инструмент позволит избежать ограничений, навязанных атавизмами другого неподходящего инструмента.
Я бы хотел выделить, то, с чего нужно начать строить приоритет и важность, на мой взгляд, и очень жаль, что мысль спряталась в середине статьи:
«Следуйте такой модели всегда. Ведь именно она дает полное представление о дедлайнах. Понимание – это ключ, помогающий с большей ответственностью и серьезностью относиться к срокам».
Если вы понимаете особую ценность дедлайна, нужно вписать это в конституцию своей компании или команды!
Тогда все остальные пункты станут второстепенными и не придётся влиять на восприятие коллег уже в начатом проекте, иначе каждое изменение будет стоит титанических усилий. И наоборот, принципы, с которыми согласились при старте работы, даже раньше старта отдельных проектом, ставшие базовыми принципами — будут легко применяться в проектах.
Я не полностью понял основные пункты советов: Ставьте только реальные дедлайны и Позволяйте команде ставить сроки. Неуниверсально, так как часто дедлайн ставит заказчик, которому нужно успеть к старту второй стадии его проекта. Я понимаю, что опыт аналогичных проектов нужно учесть на стадии составления плана работ, где как раз появятся понимание дедлайна.
Но в итоге, из трёх основных измерений — срок, бюджет, функциональность — придётся чем-то пожертвовать, ведь за даже в быту за город на отдых не выехать без изменения в сроке поездки, бюджете или количестве посмотренных достопримечательностей :-), что говорить более сложных проектах в компаниях, где каждый раз получается, не так:
а так:
картинки я взял со страницы принципов работы Бюро Горбунова
stannislav
21.07.2017 11:57Дельно. Особенно на примере поездки за город. Сроки всегда и везде меняются и будут меняться — это истина)
Объясню по поводу пунктов, которые вы не поняли. В принципе, по поводу реальных сроков все написано в статье, добавить нечего. А вот второй пункт — конечно, это не универсально, как и многие советы а-ля «сделайте это, и вы будете счастливы», или «ешьте это, и проживете до 100 лет». Но если ситуация позволяет подключить команду, то можно пробовать. По крайней мере объяснение с точки зрения психологии у этого пункта есть. А сработает или нет — все зависит от ситуацииAleksei_Mikhailov
21.07.2017 12:45Спасибо, что пояснили!
Сроки всегда и везде меняются и будут меняться — это истина)
Когда речь о принципах работы и их описании, я склонен внедрять и применять только безусловно универсальные решения. Как лекарства в медицине вводят только после высочайшего процента воздействия на определенные участки организма. Иначе плацебо было бы и то эффективнее.
Так и в принципах соблюдения дедлайнов в работе. Простой пример: в мастерской печати на тканях нужно изготовить плакат к 8 мая, потому что 9 мая заказчик понесёт плакат в руках на демонстрации в центре города. Принципиально похожих примеров и в масштабных проектах — масса, а значит возможность сдвига сроков не могу считать истиной.
Другое дело, что если, в крайнем случае, придётся резать по живому и чем то жертвовать, то функциональностью, а не дедлайном. Например, не нанимать шрифтовика, а сделать на плакате надпись готовым шрифтом или, к примеру, использовать более простой метод нанесения краски на ткань.
Собственно, идея приоритетов на дедлайне полностью перекликается с вашими идеями в статье.
Принципы менять нельзя. То «да», то «нет» при регламентировании — не выход. Согласны?
WizardryIB
21.07.2017 12:02+1И ни слова про управление рисками…
stannislav
21.07.2017 12:07Не совсем понимаю, почему именно в ЭТОЙ статье должно быть про управление рисками?
Aleksei_Mikhailov
21.07.2017 12:16Риски, крутая и важная тема. Правда очень обширная. А какую часть темы о рисках вы бы осветили в статье о побуждении сотрудников соблюдать сроки?
WizardryIB
21.07.2017 12:41Например, введение подобного правила:
При возникновении отклонения следует незамедлительное извещение инициатору запроса.
Отсюда вытекает, что при возникновении отклонения необходимо предотвратить задержку принятия корректирующих действий руководителем проекта.
Или такого:
Знание о невыполнимости задачи в срок не освобождает сотрудника от ответственности за ее выполнение.
Требование для сотрудника — предотвратить задержку принятия корректирующих действий руководителем при постановке первоначальной задачи.
Требование для руководителя – при непонимании сотрудником поставленной задачи требуется минимизировать время для корректировки декомпозиции выполнения или для постановки новой цели.stannislav
21.07.2017 12:48+1Извините, но не могу не написать. В вашем же посыле даже после прочтение несколько раз ничего не понятно
WizardryIB
21.07.2017 12:50Речь идет о применении ограничений при управлении командой. Что именно не понятно? Готов пояснить…
stannislav
21.07.2017 12:53Вы формулируете предложения таким образом, что они сложны для восприятия. Чем больше подряд идущих существительных в родительном падеже, тем сложнее это воспринимается
WizardryIB
21.07.2017 12:57Возможно получилось излишне формализовано. Я не Лев Толстой.) Попробую по другому…
В бытность проекта по запуску первого лунохода на Луну подразделения под управлением Королева С.П. решали вопрос о составе почвы на спутнике Земли. Из-за возникших споров проект никак не мог стартовать. Одни были убеждены в том, что почва на Луне состоит из космической пыли и поэтому необходима соответствующая конструкция и форма колес. Другие настаивали на каменистости спутника и убеждали всех в альтернативном решении вопроса.
В один из дней, когда все пришли на работу, на стене компании был прибит лист со следующей формулировкой: «Луну считать твердой. (с) Королев С.П.»
Споры были прекращены и проект успешно стартовал, завершившись запуском лунохода. Как потом выяснилось, почва и правда была каменистой, но главный вывод в том, что при принятии парадигмы удалось сдвинуть проект с мертвой точки.
Это пример использования парадигм управления — правил, утвержденных руководителем и принятых к обязательному исполнению подчиненными.
Aleksei_Mikhailov
21.07.2017 12:56+1Игорь, согласен, описание в правилах, как действовать, в случае сбоя принесёт пользу команде. Да и в сущности управления рисками нужно, чтобы минимизировать ущерб при сбоях. Но сначала нужно наладить и описать принципы работы без сбоев, систему. А как побудить сотрудников её соблюдать? Мне показалось, что свой взгляд на это и описал автор.
WizardryIB
21.07.2017 13:01+1Соблюдать систему всегда легче на основе установленных правил. Достаточно лишь их определить и согласовать со всеми участниками процесса.
Aleksei_Mikhailov
21.07.2017 13:13Точно. Поэтому я описал выше, что нужно соблюдение сроков сделать основным принципом команды. Корректировать по факту, внутри проекта будет менее эффективно.
WizardryIB
21.07.2017 13:07В описание системы необходимо заложить и правила по соблюдению правил. Всё просто. Вы же программисты!
WizardryIB
21.07.2017 12:07Из интересных и полезных продуктов, рекомендую посмотреть в сторону 3SL Cradle.
Symphel
21.07.2017 12:25+2«Как подсознательно побудить сотрудников соблюдать дедлайны проекта» -> «Как побудить сотрудников подсознательно соблюдать дедлайны проекта»
«Как подсознательно повлиять на команду?» -> Как повлиять на подсознание членов команды?"
А то у вас какой-то самогипноз получается.
mad_nazgul
21.07.2017 12:29+7Настоящим
самураямпрограммистам дедлайн не страшен.
Т.к. они уже представили, что дедлайн наступил и прошел.
Поэтому работают одинаково, как до дедлайна, так и после.
<:o)alexZzZzZzZ
21.07.2017 14:32+2Большинство дедлайнов на самом деле ни на что не влияют. Обычно в этих случаях еще и изменение задачи в процессе идет без изменения сроков. Единственно важный дедлайн, это когда ты можешь отказаться от части функциональности (и с этим никто не спорит, потому что понимает, что реально важно) и успеть в срок.
mad_nazgul
21.07.2017 14:43Это применимо для любого «дедлайна» важного или не важного.
Т.е. будет сделано, то что будет сделано.
По мне любой дедлайн — это мощный демотиватор для команды.
Причем не важно успели или не успели.
Если не успели, то понятно.
А если успели, то после делайна обычно «расслабляются».
Но после дедлайна работа не должна прекращаться.
Вот и живут от дедлайна, до дедлайна.
sbnur
21.07.2017 18:00+2Дедлайн имеет смысл, когда он действительно дед
Обычно точное выполнение дедлайнов возможно при выполнении стандартной работы — типа колки дров (есть топор, есть дрова, есть место куда дрова складывать)
Реализация нового продукта таит столько неизвестностей, что дедлайн не выполняется, как правило.
Здесь главное не срок, а стабильное движение к реализации, то есть работа должна проводится по принципу Петра Леонидовича Капицы — Сегодня мы стали немного умнее
lpwaterhouse
21.07.2017 21:23+1Любой дедлайн ненастоящий. Продукт не возьмется внезапно из ниоткуда, а потому дедлайн имеет свойство сдвигаться до готовности некоторого core-функционала. Поэтому любая привязка ко времени малоэффективна по сути своей.
Grammidin
22.07.2017 08:43+3Страх действует только первые пару дедлайнов. Потом привыкаешь и к штрафам, и к истеричным звонкам менеджеров, и к призывам «поднажать». Человек не может каждый месяц жить в стрессе. Он либо привыкает и это становится рутиной, либо меняет работу.
SerjkFrog
27.07.2017 12:04Не понимаю таких, кто эффективно работает только под давлением. Такое мышление мне не просто понятно.
m03r
Если мне не изменяет память, то в целом негативная мотивация работает хуже позитивной. Ваше бескомпромиссное высказывание на этот счёт заставляет сомневаться и в действенности остальных пунктов.
stannislav
Ну почему же вы так категорично? Там все написано, что не стоит с этим усердствовать, а использовать такой подход в меру. И это психологический момент, не мной придуманный, а выясненный и утверждаемый психологами.
Не согласиться с ними я не могу, по себе сужу, что страх может значительно мотивировать
m03r
… мотивировать искать другую работу.
stannislav
И это в том числе)
TerraV
Это же классика — Fear Driven Development и Hope Driven Development.
Envek
Suffer Driven Development — единственная работающая методология :-)