Тайм-менеджмент третьего поколения
Выступление Рори Вадена на TEDx, сокращенное в три раза.
1. Делай сейчас то, что освободит время в будущем.
2. Научись целенаправленно откладывать дела.
Выступление Рори Вадена на TEDx, сокращенное в три раза.
1. Делай сейчас то, что освободит время в будущем.
2. Научись целенаправленно откладывать дела.
Попробуйте прямо сейчас
1. Закройте мессенджеры.
2. Отключите уведомления от соцсетей, кроме самых важных.
3. Выпейте воды.
4. Выключите, что у вас там играет на соседней вкладке.
5. Поставьте плюс, сохраните пост в закладки, закройте и идите заниматься тревожащим делом.
6. Вернитесь сюда позже.
Что сделать, чтобы полегчало
Очевидно, что вы продолжаете читать. Ну и ладно.
Список выше — временная пилюля. Можно применять её каждый день для небольших продвижений вперёд в том, что у вас там горит — диплом, домашка, задачи по работе или что-то ещё. Лейку от душа, допустим, забыли прикрутить.
Дело в том, что быстрые варианты и помогают краткосрочно — сложно долго сидеть без мессенджеров и соцсетей. Директ отвлекает, вконтактик и фейсбучек манят, тикток стоит несмотренный. А если вокруг дети, семья, ужин и холодильник потёк, то я вам вообще не завидую.
А жена — нет
Лень учиться — чаще всего симптом более важной проблемы. Похожие симптомы — лень работать, лень заниматься домашними делами, лень готовить завтраки. Поиск проблемы — тема для другой, длинной статьи с кучей источников. В таких ситуациях люди быстро сдаются. Примите это и не пытайтесь себя пересиливать. Попробуйте другой путь.
Чтобы стало хорошо, нужна система, в которой отвлечение не будет таким болезненным, а дела будут делаться легче. К счастью, всё уже давно придумали — осталось подстроить систему под себя и начать регулярно ей пользоваться.
Книжки-пилюли
Во всех хороших книжках написано, что нет рецепта продуктивности, который подходит каждому — потому что все разные, у всех разные начальные условия и цели. Это нормально.
Я прочитал эти две недавно, поэтому по горячим следам рекомендую. Ссылок не оставляю (только на бесплатный фрагмент на сайте издателя), если загорится — найдите сами в поисковике.
Максим Дорофеев, «Джедайские техники»
Книга про выработку привычек, полезные инструменты для разгрузки памяти и ежедневные практики, которые помогают больше и чаще думать. После неё вы будете с любовью относиться к спискам задач, делить мир на цели, проекты и встречи, а ещё разберёте наконец почту, чтобы снизилась тревожность.
Книга написана простым языком, без зауми, и большую часть рецептов можно сразу взять и применить. Горячо рекомендую. В списке ссылок внизу статьи — фрагмент одной из глав с сайта издателя.
Максим Дорофеев, «Путь джедая»
Два Максима Дорофеева в одной подборке — не случайно. «Путь джедая» — книга про постепенное повышение осознанности, улучшение жизни и внедрение в жизнь пяти уровней джедайской мудрости.
На сайте издателя есть бесплатная глава — она про второй уровень, на котором, кажется, почти все мы и находимся. Можно прочитать и примерить на себя.
Привычки (это долго)
О том, что привычки не вырабатываются за 21 день, знает каждый, кто пытался, но не получилось.
Считать, что жизненный пейзаж меняется только по причине автомобиля — значит не догонять фишку. Он меняется потому, что ты каждый день двигаешься вперед, и неважно на чем.
Для выработки привычек есть разные трекеры — например, HWYD. Туда заносятся разные вещи, которые хочется делать регулярно, например, «планка» или «диплом». В конце дня нужно посмотреть на список и поставить галочки там, где было что-то сделано.
Привычка сама себя не воспитает
Сначала будет тяжело, но тут как и со всем — нужно сначала просто последить и попробовать хотя бы иногда заносить дела. А потом появится привычка отслеживать привычки и жизнь станет чуть легче.
Начинание дня с ритуалов
Ритуалы создают предсказуемость. Предсказуемость — это хорошо. Она помогает понять, что делать дальше. Когда понятно, что делать на шаг вперёд, следующие шаги уже не такие страшные.
Ритуалы могут быть разные, например:
1. Проснуться.
2. Взвеситься.
3. Выпить воды.
4. Сделать завтрак.
5. Спуститься за булочкой.
Или
1. Проснуться.
2. Прочитать 15 страниц книжки.
3. Сделать зарядку.
4. Съесть кашу, приготовленную с вечера.
Или
1. Написать 10 страниц диплома.
2. Проснуться.
Планирование от обратного
Мы не представляем, сколько у нас есть времени на учёбу. Сделайте упражнение: распланируйте неделю — прямо возьмите гугл-календарь и добавляйте туда всё, что придёт в голову.
Идея в том, чтобы не писать о том, что нужно сделать. Сначала напишите всё, кроме этого — когда вы будете спать, завтракать, пойдёте в магазин и поедете на работу. Туда же — все встречи, которые запланированы на неделю.
Всё, что осталось — ваше время на учёбу/работу/диплом или что вам там лень делать.
Моя неделя. Всё белое — время на учёбу. Так себе, конечно, расписание.
Ещё советики
Чеклисты
Для любой, даже долгой задачи, можно придумать чеклист — список действий, которые нужно последовательно выполнить.
Если я учусь программировать — шаги для достижения комфортной зарплаты или определенного профессионального уровня.
Если играю в сквош — что нужно знать, чтобы поучаствовать в своих первых соревнованиях и не проиграть всухую первый матч.
Если я ищу работу — как составить резюме, чтобы меня не послали нафиг после первых пяти слов.
Если я лежу на диване — как сделать так, чтобы лежать на диване было не больно (или как встать с него).
Разрешите себе не делать
Потому что иногда можно не делать некоторые вещи, чтобы снизить уровень тревожности. Если не можете не делать — хотя бы запишите всё, что тревожит, в список, и разгрузите голову.
Сделайте, чтобы не вспоминать
Некоторые вещи постоянно возвращаются в голову, тревожат и отвлекают — их нужно сделать, просто чтобы больше никогда не вспоминать. Про это хорошо написано у Людвига Быстроновского — там про то, как выживать без стремления к цели, и как всё-таки улучшить ситуацию.
Мотивирующие подкасты
Одному из читателей блога помог подкаст «Будет сделано». От того же автора есть одноименная книга — в ней компиляция опыта, который автор получил при производстве подкаста.
Контроль со стороны
Найдите наставника, ментора или личную машину контроля. А ещё можно запустить тимвьюер и знать, что за твоей работой наблюдают.
Есть ещё сервисы для контроля времени, которые мотивируют не пропускать задачи. Например, Toggle считает время, потраченное на задачи, и сразу видно, где вы поленились, а где поработали на славу.
Статьи и подкасты для внеклассного чтения и слушанья:
8 шагов, чтобы зарабатывать 100 тысяч в месяц
Подкаст «Будет сделано»
Если ничего не помогло
Конечно, если ничего не помогло, всегда есть Шайа Лабаф.
Ладно, вы держитесь, а я побежал бы, но мне лень.
На работе иногда публикуют новости о компании и всякие смехуёчки. Недавно было вот что:)
Давно хотел я написать о том, как можно применить методологию SCRUM не в Dev, а в Ops команде.
Сама методология довольно неплохо (но для тех кто первый раз пытается погрузиться, возможно это описание будет выглядеть перегруженным) описана на Вики https://ru.m.wikipedia.org/wiki/SCRUM. Для тех кто не хочет читать, или предпочитает более легкую и наглядную демонстрацию, я предлагаю посмотреть вот такой короткий ролик на Ютубе:
Вот ещё небольшая юмористическая зарисовка на тему скрам из сериала «Кремниевая долина»:
— «Ну scrum, так скрам» скажете вы. — » Зачем нам это, это же девелоперские фишки, код там писать, тестить. Это нам не поможет, мыж сервера поднимаем, сетку настраиваем, юзеры вечно что то хотят.» Не применимо это короче — а вот и нет!!! Очень даже применимо. Ибо это организация работы над проектом и задачами. Просто для OPS команды (сисадмины, сетевики и пр), его надо немного доработать.
После доработки он становится вполне применим и позволяет делать следующие вещи:
1. приводить в порядок список ваших проектов и долгоиграющих задач ( ведь у вас на это появляются силы и возможности)2. спокойно поставить задачи и двигаться к намеченным целям всем сотрудникам отдела / членам команды3. регулярно пересматривать ваш список задач и проектов, выявлять не актуальные и тем самым не держать за спиной груз бесполезных задач4. гибко и быстро реагировать на поступающие запросы
и многое другое что дает SCRUM
Сейчас я расскажу о нашем опыте. Мы не переизбирали эту методологию. И в первую очередь, вам нужно познакомиться с ней, с ее идеями, с ее артефактами и тп. Иначе все сказанное ниже будет казаться для вас если не ахинеей то как минимум слабо связанным с тз идей текстом.
Далее я привожу список наших доработок или “патчей”, чтобы scrum мог работать для Ops команд:
1. Заведите backlog (хранилище задач) под все ваши задачи, проекты, тикеты и ТД. Это обязательное требование Scrum в принципе, но для OPS команд это означает — заведите единое хранилище. То есть не должно быть такого что заявки от пользователей Вам приходят в хелпдеск / тикет систему, указания от руководства (не IT отдел) не покидают Ваш телефон или почту и хранятся только там, а все внутренние задачи и проекты записаны только в блокноты сотрудников. У вас должно быть централизованное унифицированное хранилище “истины”. Увидел кто-то что была найдена уязвимость в ядре и вышло обновление — поставь сам задачу на отдел — “протестить и обновить сервера” (это кстати не очень хорошая формулировка, но об этом чуть позже), вместо того, чтобы пометить в блокноте и забыть на месяц. Или того хуже — сказать коллегам за кофе, чтобы они “угукнули” и забыли все вместе- коллективно и навсегда.
2. Начинаем использовать спринты. Берем максимально короткий для SCRUM интервал — 1 рабочая неделя. В начале недели, в понедельник с утра — собираем команду на 1 час, планируем спринт. То есть берем готовый к работе бэклог, набираем из него задач на неделю, что-то распределим, что-то оставляем в свободном виде (тот кто освободился- подхватил), а вечером пятницы, незадолго до конца рабочего дня, тоже собираемся на час и смотрим что получилось. Ведем разбор полетов- что успели, а что нет. Почему, как в следующий раз не допустить, какие были проблемы и ошибки, чему научились. Это все кстати лучше фиксировать.
3. Помимо планирования спринтов в начале недели и разбора полетов в конце, проводите ежеутренние “стендапы” (летучки) всей командой. 15-20 минут с утра, у маркерной доски, в строго определенное время и стоя! Строго определенное время нужно для приучения всех к дисциплине, 15-20 минут — этого хватает чтобы каждый рассказал чем занимался вчера, чего достиг, что планирует сейчас, что было интересного и в чем ему нужна помощь коллег. Эдакая синхронизация команды. А стоя — так по нашему опыту не возникает желания растягивать это надолго, естественным образом пресекаются долгие дискуссии и холивары. Каждый по очереди пишет на доске напротив своего имени что будет делать сегодня, зачеркивает/стирает что делал вчера и делает другие пометки. Да, это необычно для скрам, тк там должна быть только скрам доска со стикерами или их аналогом ( у нас она заменена веб приложением), но скрам доска нужна для поддержания сквозного скрам процесса, спринта и тд а это чисто утренний синк команды.
4. Разбейте все ваши проекты и долгоиграющие задачи на подзадачи, которые могут быть выполнены за 1-3 дня. Не больше. Если задача тяготеет к 5 дням работы, она рискует быть не выполненной за спринт (отвлеклись и оп), а значит ее надо разбить на подзадачи. Более того, выше я приводил пример как человек заводит внутреннюю задачу “протестить и обновить сервера” — это плохая задача. Хорошая задача формулируется так, что для ее выполнения не надо думать “что надо сделать и с чего начать” — не тратятся мозговые ресурсы. Она должна быть сформулирована так, чтобы вы могли за нее взяться даже если Вас разбудят в 3 ночи. Например — “развернуть тестовый сервер на виртуальной машине с текущей версией ядра, потом обновить его до версии с патчем, протестировать (напишите как — например развернуть копию рабочей базы данных и прогнать пару тестов на производительность), а потом пачками по Х штук обновить сервера 1,2,3,4 и тд в продакшене ( список серверов и порядок обновления)”.
5. Начните оценивать задачи которые вы ставите сами себе или которые ставят вам с точки зрения — «сколько человеко часов на это уйдет». Это будут наши story points или очки задач. Во первых, это поможет вам с предыдущим пунктом, а во вторых приучит к оценке и планированию. Не бойтесь брать небольшой запас и не бойтесь ошибаться, со временем вы и ваша команда научитесь это делать это четко и точно.
6. Посчитайте число участников вашей команды. Их не должно быть больше 10. для таких команд скрам не работает. Если вас меньше, скажем 7-8, вычтите 1 (потом увидите зачем) и получившееся число умножьте на число человеко часов вашей рабочей недели ( например у нас стандартная 5-ти дневка, мы работаем 8 часов из которых час на обед и прочие надобности — покурить, туалет и ТП). Итого 5*7= 35 часов. на 7 человек (8-1) имеем 245 свободных поинтов. Теперь на этот размер можно набирать задач из бэклога, только так чтобы 1 задача не превышала за раз 3 поинтов как вы поняли.
Итак, у нас есть хранилище куда попадают все задачи которые мы должны сделать, задачи перевариваются — разбиваются если надо и оцениваются, у нас есть своя оценка поинтов (именно описанная выше оценка лучше всего подходит для ОПС команд) и есть понимание сколько всего очков у нас в запасе на спринт. Пока все более менее стандартно, ничего нового.
Помните вы вычитали одного члена команды ( кстати он может быть и не один но это надо подбирать на практике, мы справляемся с одним)? Это дежурный инженер или on-call. Его время не учитывается в работе, оценке, исполнении спринта — его задача быть буфером между командой и задачами «срочно, сломалось, надо было вчера сделать».
Все входящие задачи, помимо оценки времени должны разделятся по одному принципу — “это задача или инцидент?”. Как это сделать:
- Если чего то не было и это хотят (новый принтер в бухгалтерию ) — это задача. - Если вам надо развернуть новую серверную ферму под кластер виртуализации — этот проект который надо разбить на задачи. - А вот если что то работало и потом сломалось, например: в офисе пропал интернет, почтовый сервер все пихает в спам, 1С не грузится, у пользователя не включается компьютер, сайт отдает 503 — это инцидент.
Дежурный инженер должен принять их на вход и обработать. Например оценит что это срочно и важно и ринуться грудью на амбразуру, прикрывая товарищей от отвлекающей рутины. Или поняв что это нечто, требующее долгой работы отдела (тот же пресловутый кластер виртуализации рассыпался и теперь надо в несколько пар рук заниматься им полное время) — собирает всю информацию, составляет диагноз, нарезает первые задачи с чего начать и, уведомив руководство, первым кидается тушить пожар. А уже IT менеджер / старший админ / начальник отдела оценивает масштаб происшествия и принимает решение кого и как прислать на подмогу.
Так же, дежурный инженер должен заниматься ежедневными рутинными задачами — «разгребать» их, снимая эту нагрузку с команды — отключения учетных записей, проверки бекапов, наблюдение за мониторингом и тп.
Таким образом нейтрализуется ежедневный отвлекающий фактор, создающий прерывания и приносящий “рабочий шум”. Команда же может спокойно планировать задачи и выполнять их.
На этом все! Применение этих простых “патчей” позволит Вам использовать SCRUM методологию в Вашей Ops команде!
П.С. Тэг "мое", тк перенесено сюда из статьи моего блога: https://kazarin.online/index.php/2019/06/06/how-to-patch-scr...
Это, блин, бесполезно. Опять пытался правильно рассчитать и распределить время, в итоге время распределило меня. Можно бесконечно гадать, сколько уйдет на задачи, по итогу все равно сделаешь только самые приоритетные, да и то, если повезёт, сделаешь их полностью как задумывал.
Эй ребят, как вы это делаете? Я ещё могу понять, если занимаешься долго в одной сфере, но что если твоя задача - все время делать что-то новое? Какая-нибудь хитрая послойная разработка?
Походу надо просто привыкнуть к постоянному ощущению недоработанности, а в качестве мотиватора использовать не желание сделать всё, как задумал, а просто не тормозить. И ставить большие цели, даже понимая, что достигнуть их нереально. Ведь чем дальше стремишься, тем быстрее движешься.
Всем привет, сегодня я хотел бы поделиться тем, как я реализовал управление временем на Unity 3D. Думаю многие играли в Price of Percia: The sands of time. Мне показалось, что в этой игре не раскрыли весь потенциал, данной задумки. Что ж давайте подумаем, как можно это реализовать. В unity есть такая вещь, как Time. Вы можете его посмотреть настройки в Time Manager во вкладке Edit/ProjectSettings/Time
Как мы видим, здесь есть настройки Fixed Timestep - этот параметр определяет то, через какое время будет вызываться функция FixedUpdate. В этой функции выполняется обработка физики RigidBody и тому подобное. Maximum Allowed Time - Отвечает за независимый от частоты кадров отсчет времени, здесь он нам не понадобится. Time Scale - это скорость, с которой течет время, так установив этот параметр на 0 вы остановите движение времени в игре, а установив на значение больше или меньше 1 ускорите или замедлите время соответственно. Очень хорошо может применяться для создания SlowMotion или же для паузы в игре, заметим, что параметр Time Scale не может быть меньше 0, это значит, что мы не можем использовать его для наших целей, то есть можем, но не так просто.
Что же с теорией разобрались теперь давайте подумаем как нам реализовать обратную перемотку. На ум сразу же приходит идея записать позиции и поворот всех нужных нам объектов и присваивать их при нажатии на кнопку. Так и поступим.
Создадим C# скрипт и назовем его Time_. Создадим массив GameObject и назовем его Objects, создадим также двумерный массив типа Vector3 и еще один двумерный массив типа Quaternion, назовем их Positions и Rotations соответственно.
Создадим сразу переменную Index типа integer, для того чтобы ориентироваться в массиве. Ведь когда мы будем записывать позиции и поворот, мы должны сохранить это в следующем элементе. Так же создадим переменную Scale типа int, которая будет регулировать размер массивов, а следовательно и длину записи, установим ей значение 1000.
В Старте инициализируем переменные.
Objects мы будем искать все объекты на сцене по тегу "Time", давайте настроим этот тег.
Objects = GameObject.FindObjectsWithTag("Time"), далее инициализируем Positions и Rotations, устанавливая первый размер Objects.Length, а второй Scale.
Получим что-то вроде этого.
Давайте сразу пропишем в Update вычисления, если Index больше Scale, то обнуляем Index и записываем все по новой. Это будет значить, что мы возвращаем только последние несколько секунд времени, количество которых зависит от Scale. Тоже самое, только наоборот, делаем и с нулем, таким образом ограничивая Index (0,Scale).
В начале мы не просто так затронули функцию FixedUpdate, она вызывается через определенное кол-во кадров, в зависимости от TimeScale, и в ней обрабатывается физика.
Нам нет смысла обновлять позиции каждый кадр, если они не меняются. Следовательно прописываем функцию FixedUpdate() и в ней уже пишем цикл for от 0 до Objects.Length, с переменной і и в этом цикле Positions и Rotations[i,Index] присваиваем текущие позиции и повороты. после цикла в функции прибавляем к Index 1.
Теперь осталось только присвоить эти значения к текущим позиции и повороту, для этого в Update прописываем условие If(Input.GetKey(KeyKode.R)) и в нем значение TimeScale устанавливаем на 0, так мы защищаем себя от воздействия физики на объекты и перестаем записывать позиции еще раз. Теперь используя функцию Lerp присваиваем позиции и поворот нашему трансформу.
Теперь осталось просто запускать время, когда отпустим клавишу R, для этого все в том же Update пишем if(Input.GetKeyUp(KeyKode.R)) и в этом условии устанавливаем значение TimeScale на 1
Что ж, вот мы и написали небольшой код, для управления временем, он оказался довольно простым и наглядно показывает, как обновляется физика и как работает Lerp, так же практическое применение двумерных массивов в Unity. При настройке не забудьте добавить RigidBody на ваши кубики и установить тег.
а какие сверхспособности ты бы хотел получить?