Кодирует ли вас стресс?
Это тяжелое и утомительное испытание для многих разработчиков. Многие из них чувствуют, что ничего не делают на работе. Есть длинный список проблем, которые они должны решить, и никогда не хватает времени, чтобы все сделать.
Решите одну проблему, и две другие займут ее место.
Они уже перегружены. Так что они делают? Они работают усерднее. Они добавляют больше работы к своей уже полной тарелке. Они переключают свое внимание на тактику грубой силы, делая все возможное, чтобы получить результаты.
Вы знаете, как это заканчивается. Не работает
Их личная жизнь страдает, поскольку они сокрушены под тяжестью их огромной рабочей нагрузки.
Проблема не в их рабочей нагрузке
Это их инструменты.
Есть специальный инструмент, который делает вещи психологически невыносимыми для многих разработчиков. Что-то так просто, это сразу же сбрасывается со счетов или игнорируется.
Почти сразу же вы услышите возражения.
- «Это не так уж плохо».
- «Я использую это, и я просто в порядке».
- «Я использую этот инструмент каждый день. Это только проблема в начале ».
Некоторые разработчики совершенно фанатично относятся к этому инструменту.
- «Мне абсолютно нужен этот инструмент».
- «Я никак не могу функционировать без этого».
- «Проекты без этого не успешны».
К настоящему времени вы, вероятно, на булавках и иголках. Какой инструмент вредит разработчикам? О чем он говорит?
Я говорю о…
Списки дел.
Ваш список дел является либо отдельным продуктом, либо функцией выбранного вами инструмента управления проектами. Это то, что мы используем для управления нашей личной и профессиональной жизнью, и обычно это не обязательно …
Что является проблемой.
Списки дел полезны … сначала. Вы можете получить общее представление о работе, которая должна быть сделана. Вы знаете, что делать и когда это делать. Это держит всех на ходу и на одной странице.
Отлично, верно?
Не очень хорошая сторона списков дел
Списки дел имеют много недостатков. Что еще хуже, урон от этих недостатков постепенно увеличивается со временем. Он медленно и незаметно закрадывается.
Ущерб настолько мал, что большинство разработчиков упускают его.
Повреждение? Какой урон?
- Вечная вина. Ты чувствуешь себя виноватым, потому что ты не все делаешь. Вы задерживаете это или не делаете это достаточно быстро. Когда вы закончите, это завершенное задание является постоянным напоминанием о том, что вы не сделали это правильно.
- Производительность заблуждения. Вы проверяете что-то в своем списке дел и не можете не чувствовать себя хорошо. Такое ощущение, что вы что-то делаете, как будто вы делаете успехи — кроме случаев, когда вы этого не делаете.
- Психологическая нагрузка. Есть угнетающий секрет о списках дел. Они никогда не заканчиваются. Завершите один список, и другой займет его место. Снова и снова, день за днем, день за днем.
- Смещенные приоритеты. Ваши приоритеты сосредоточены на правильных задачах, или вы просто крутите колеса, работая над задачами, которые в конечном итоге не имеют значения? Как вы можете сказать?
- Обусловлено неудачей. Не секрет, что вы перегружены работой. Список того, что вы должны делать, не перестает расти. Что это обучает разработчиков делать? Игнорируйте их список дел.
- Дезорганизован и неэффективен. Списки дел приложений имеют ограничения, которые снижают производительность. Например, большинство приложений для ведения дел не позволяют устанавливать групповые задачи, когда группа людей работает вместе над одной задачей. Кроме того, существует тот факт, что списки дел не различают задачи, которые можно выполнить за три минуты, и задачи, которые занимают три дня.
И это еще не все.
В начале, новые разработчики обычно безразличны или увлечены делами. Разработчики, которые подверглись насилию, считают иначе.
Часто они тушатся с разочарованием.
«Это не работает, но мой босс заставляет меня использовать его». Это обескураживающая часть работы, которую допускают опытные разработчики.
Что означает, что эти задачи наносят вред всем остальным
Если вы разработчик, борющийся с этими проблемами, вы не так продуктивны, как следовало бы.
И это не твоя вина.
Независимо от того, кто несет ответственность, эти ошибки наносят ущерб разработчикам, командам, с которыми они работают, их руководителям и даже их клиентам.
Значит ли это, что вы не должны использовать списки дел? Что, в лучшем случае, это пустая трата вашего времени и ресурсов? Точно нет. Списки дел могут быть полезным инструментом.
Если они используются правильно.
Но что это значит? Это означает, что списки дел должны использоваться в качестве инструмента поддержки команды, направления развития и продвижения проекта к конечной цели.
Списки дел служат команде, а не наоборот.
Эти списки становятся вредными, когда это переключается. Как только команды начнут выполнять свои задачи, неизбежно последуют неэффективность и борьба.
Хорошо, так что разработчики должны использовать вместо этого?
То, что вы используете, зависит от вашей свободы
Если вы фрилансер или работаете в небольшом агентстве, у вас есть влияние или контроль, которые вам нужны, чтобы пробовать новые вещи.
Вот несколько стратегий, которые вы можете предложить или, по крайней мере, попытаться бороться со злоупотреблением делами.
Крошечные привычки
Я заметил общую проблему с разработчиками; они создают список дел с одинаковыми повторяющимися задачами, независимо от проекта. Это задачи, которые они знают, как делать, и это то, что они делают неоднократно, например, по маслу.
Что если вместо этого вы создали привычку?
Б. Дж. Фогг, директор убедительной технологической лаборатории в Стэнфорде, открыл простой способ создания привычек .
Сделай шаги ребенка. Маленькие крошечные, простые в использовании шаги ребенка, которые создают новые привычки.
Допустим, вы хотели создать новую привычку: чистить зубы каждый день.
Большинство людей усложняют ситуацию. Они полагаются на грубую силу, чтобы создать привычку. Они проводят время за покупками зубочистки. Они создают ночные таблицы и контрольные списки, когда подойдет простая привычка.
Доктор Фогг рекомендует обратное.
- Сделать крохотный крошечный , скажем … зубной нитью. Это достаточно мал, если это легко и быстро сделать.
- Найдите место в вашем существующем распорядке дня, где эта новая крошечная привычка могла бы соответствовать, после твердой привычки, например, обедать. Например, зубная нить по дизайну приходит после еды.
- Тренируйте это. Сосредоточьтесь на том, чтобы делать эту привычку после вашей якорной привычки каждый день. Сначала вам понадобятся напоминания, но вскоре вы заметите, что они становятся автоматическими.
Я использовал общий пример, но это может относиться практически ко всему. Более того, есть определенные вещи, которые вы обычно делаете в рамках цикла разработки.
- Предварительное планирование и планирование задач
- Реализация задач
- Тестирование и анализ
- Отладка и улучшение производительности.
Видишь, о чем я? У каждого проекта есть рутина, а это значит, что вы можете строить привычки вокруг них.
Планирование и ограничение задач
«О, ты закончил свою работу рано? Большой! Вот еще один длинный список того, что вам нужно сделать ». Ваш мозг знает, что вознаграждение за ваш тяжелый труд будет… более тяжелым. Итак, зачем?
Это оказывает демотивирующее влияние на вашу команду.
И худшая часть? Это поощряет всех вытаскивать вещи, чтобы доить свое время. Он обучает вашу команду тратить больше времени на выполнение меньшего .
Вот что мы сделали вместо этого.
Мы потратили больше времени на планирование наших проектов. Фактически, 60 процентов нашего времени было потрачено на планирование проекта. Думать о том, как все будет работать, устанавливать ожидания клиентов и собирать ресурсы вместе.
В начале это было безумно.
«Кто проводит такое планирование времени? Agile лучше, нам просто нужно войти туда и что-то построить. Нам нужно быстро повторить ».
Мы проигнорировали наши возражения, решив, что попробуем составить расписание, и немного ограничим наши задачи, чтобы посмотреть, как это работает для нас. Вот что мы нашли.
- Изменения упали на 96 процентов (по сравнению с предыдущим годом).
- Ошибки, правки, исправления — любые надобности уменьшены более чем вдвое.
- 80 процентов наших проектов запущены вовремя и в рамках бюджета.
- Наши клиенты были намного счастливее.
Все потому, что мы запланировали и ограничили наши задачи.
Но что это значит?
Мы планировали свои проекты в начале, выбирая для работы над определенным набором задач или задач каждую неделю.
Если в нашем процессе предварительного планирования есть восемь этапов, а это занимает две недели, мы потратим первые две недели на предварительное планирование. Это наш фокус — мы установили границу вокруг этих двух недель.
- Нет изменений
- Не меняя объем работ
- Нет добавления в последнюю минуту
- Нет связанных задач
Это заняло больше дисциплины, чем мы ожидали. Но вот что мы нашли.
- Разработчики сделали лучшую работу. У каждого разработчика было определенное количество заданий на неделю. Не было бесконечного списка дел, поэтому наша команда осталась свежей. У нас было больше времени, поэтому мы написали лучший код и обнаружили больше ошибок, выполнив больше работы за меньшее время.
- Они нашли проблемы быстрее. Когда вы перегружены списком задач, ваш фокус меняется. Вы стремитесь сосредоточиться на том, чтобы выбивать как можно больше задач, когда вы должны сосредоточиться на правильном решении проблем. Удивительно, что вы ловите, когда у вас есть время посмотреть.
- Клиенты были более стабильными. Мы заранее сказали клиентам, что мы не будем менять наши задачи или варианты от недели к неделе, если они не будут абсолютно необходимы. Это заставило клиентов тщательно обдумать изменения, которые они хотели. Запросы в последнюю минуту в стиле «Мне нужна эта новая функция к завтрашнему дню» иссякли в одночасье.
- Ползучий прицел было легко избежать. С запланированными или замороженными задачами мы смогли минимизировать проскальзывание области, только внося коррективы для потребностей.
Преимущества были огромны.
Но эти стратегии хорошо сработали для нас, потому что у нас был контроль. Мы были небольшим агентством, и у нас была автономия, в которой мы нуждались, чтобы проверить это.
Но что, если вы этого не сделаете?
Вы закончили, если у вас нет контроля
Правильно?
Это ожидание. Если вы работаете на работе, и у вас нет контроля над ситуацией, вам просто придется смириться с этим.
Но это не правда.
Если вы работаете в месте, где люди готовы слушать, поговорите со своими коллегами.
Сделайте свое дело и попросите обратную связь. Но что, если это не безопасно? Вам понадобятся еще несколько вариантов.
Ограничение задач
Это так же, как и раньше. Но вместо того, чтобы ограничивать задачи в проекте, вы накладываете ограничения на задачи, над которыми вы будете работать в течение определенного периода времени.
- Выберите таймфрейм. Если вы пользуетесь микроуправлением на регулярной основе, вам понадобится более короткий срок. Если у вас больше автономии, у вас есть более длительный период работы, например, от недели до месяца. Ограничьте задачи, которые вставляются в ваш таймфрейм. Например, если вас принуждают к вашей неделе, вы откладываете существующее задание.
- Выберите ваши задачи. Вы будете хотеть выбрать правильную смесь задач. Важные задачи продвигают проект вперед, делают вашего босса счастливым, но занимают больше времени. Средние и низкие значения дают вам быстрые победы и много импульса, но не так привлекательны.
- Разобраться с сопротивлением. Управляющий босс может захотеть диктовать, над чем вы работаете и когда. Привязать их к этому , заставить их разделить ответственность за успех проекта. Сделайте это правильно, и вы получите властного босса, чтобы отступить.
Использование напоминаний, чтобы игнорировать задачи
Исследования показывают, что мы работаем лучше всего, когда концентрируем свое внимание на одной вещи за раз. Это означает, что многозадачность является худшим. Но именно это и побуждает нас делать.
Сосредоточьте свое внимание на всех вещах, над которыми вам придется работать позже.
Таким образом, вы создаете полезные напоминания. Здесь проблема. Большинство из нас пользуется этой возможностью, чтобы загрузить себя. Мы берем все задачи и вешаем их на шею, создавая толпу напоминаний.
Не делай этого.
Вместо этого создайте одно напоминание за раз. Если вы собираетесь начать работать с A, создайте напоминание для B. Если вы начинаете B, создайте напоминание для C.
Создайте одно напоминание для следующей вещи в вашем списке .
Это требует дисциплины, но ваше здравомыслие поблагодарит вас.
Когда вы закончите, вернитесь к списку дел и вычеркните его. Создайте напоминание, затем продолжайте.
Зачем беспокоиться?
Потому что страх, стресс и беспокойство убивают вашу работу . Агрессивное ограничение вашего списка дел сводит ваш уровень стресса к минимуму.
Хотите сделать свою лучшую работу? Это не обязательно.
Ваш босс будет настаивать на контроле. Ваши коллеги будут добиваться контроля. Некоторые из ваших коллег позаботятся о команде, но давайте будем честными, большинство не будет. Большинство ваших коллег будут искать возможности уменьшить свою рабочую нагрузку, даже если это означает увеличение вашей.
Защитите свое эмоциональное и психологическое здоровье, и ваши лучшие дни еще впереди.
Игнорировать это и страдать.
Списки дел только больно, если вы позволите им
Это легко сказать — если вы контролируете ситуацию. Когда у вас есть автономия, контроль или влияние, можно легко сбрасывать со счетов чужие проблемы.
Но это не реальность для большинства разработчиков.
Разработчики испытывают стресс, переутомление, насилие. Это общая проблема .
Который сразу создает страх. Этот страх обычно проявляется так:
«Когда вам дают больше работы, вы наклоняетесь и говорите: « Спасибо, сэр, можно мне еще » .
Или тебя заменит … через минуту в Нью-Йорке.
Если вы ничем не примечательный разработчик, это правда. И почему бы не быть?
Но если ты хорош в том, что делаешь — услужливый, поддерживающий, звездный — проиграть тебе будет больно. Все звезды имеют возможность устанавливать границы и ограничения в своей работе. Ты слишком ценен, чтобы терять.
Вы не можете работать без дел …
… И тебе не нужно этого делать. Но стать рабом своего списка дел — это не ответ. Ваш список дел должен работать для вас, для команды, а не против вас, как для многих разработчиков.
To-Dos не должен быть стрессом
Списки дел делают кодирование напряженным и утомительным испытанием для разработчиков. Большинство разработчиков перегружены работой. Работать усерднее, тонуть в делах.
Это не обязательно должен быть ты.
Ваша личная и профессиональная жизнь может стать прекрасным опытом без стресса. Вы не должны быть сокрушены под весом огромного списка.
Вы контролируете
Забери свой список дел. Боритесь за свое время, боритесь за свою эмоциональную и психологическую свободу. Дайте себе инструменты, которые вам нужны, и вы обнаружите, что ваши лучшие дни впереди.
Не требуется дробления.