Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 342 сообщений
Cообщения с меткой

управление временем - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Un-FuckUp-able Development Protocol (UDP)

Четверг, 04 Августа 2016 г. 17:40 (ссылка)

Недавно после очередного Team Building’a получил от одного Коллеги-Графомана письмо-притчу про большую кнопку «сделать всё хорошо». Он и раньше баловался изобретением велосипедов, но, в этот раз конструкция показалась мне очень удачной. Кому интересно — прошу-приглашаю под кат. С его разрешения дословно:



В эту сиесту на веранде практически никто не курил, потому, что все ушли на очередной двухдневный SCRUM тренинг. Джонни устало окинул взглядом присутствующих: Дёму и Варю. Они тоже не были в восторге от происходящего, было слишком жарко и душно, лето в Долине было в самом разгаре, и казалось, что на улице даже жарче чем в Task Tracker’е.








Дела были не ахти, все трое это знали. Они все в решении своих задач зависели от людей, которые ушли учиться как надо организовывать процесс разработки. Реальная работа, которую надо было сделать ещё вчера, сегодня переносилась на тот незримый момент в будущем, когда остальные “бойцы” вернутся с фронта борьбы за ликвидацию безграмотности.



— А хотите, ребята, я Вам сказкочку расскажу, про программистский Рай? — спросил Джонни, стряхивая пепел после очередной затяжки.



Варя и Дёма уныло кивнули, но постарались улыбнуться. Тогда Джонни достал из кармана трубку, и, пояснив, что это будет Long Run Story, стал неторопливо погружаться в клубы Balkan Delight (сорт табака).



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



Инициализация BIOS выдала слушателям сведения об оборудовании:





Ну и прочий IO и периферия, типа “сторонних” тестировщиков, верстальщиков и дизайнеров, с которой все были согласны. Все так же согласились, что дисплей это SCRUM доска, а операционная система это Linux, то есть движение Open Source конкретно и прорывные инновации IT сферы в частности.



Менеджмент, безусловно, отнесли к прикладному софту — Task Tracker’у и Cron. Электроснабжение, по понятным причинам, заменили на понятие Cash Flow от Заказчиков и Клиентов. Ведь компьютеру не важно откуда придёт энергия, важно просто делать расчёты, поэтому данность наличия энергии и источник её возникновения тоже никем не оспаривался. Корпус, в их случае, конечно же был кастомный, с водяным охлаждением (бассейн и сауна), разлоченным генератором тактовой частоты (любые ништяки, от кальяна и пива на веранде, куда не запрещалось брать ноутбук, до спортзала в подвале их особняка). ИБП в виде угарнейших корпоративных вечеринок и прочих значительных поблажек в presence time schedule так же, конечно, обозначился как неотъемлемый и очень нужный девайс.



Пропустив остальные несущественные моменты описания Джонни подвёл итог:



— Итак, мы имеем 50+ человек, которые уже пару лет дышат той или иной методологией разработки, но при этом всё равно у нас регулярно происходит какой-нибудь FuckUp. Мы начали с самоорганизованного хаоса, тогда нас было 10. Потом нас стало 20, и 30, и 40 и у нас был “Водопад” (модель разработки). И, когда всё завертелось не так, как мы привыкли, мы стали делать SCRUM. И, вроде бы, всё у нас отлично, стабильная ЗП, отличный менеджмент, довольные пользователи регулярно заносят копеечку, но все же видят проблемы? — подитожил Джонни.



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



Все знали, что каждый из разработчиков регулярно получает не только премии, но и “по шапке” за факапы. Что тестировщики “не тестируют”, а джуны не джунят. Верстальщикам то не хватало “еды”, так как дизайнеры были перегружены микроменеджментом, то их заваливало так, что уже разработчики были вынуждены их ждать. Про саппорт — этих бравых ребят — могучих викингов во главе с самим Тором можно было с удовольствием писать лишь панигирики да некрологи. А первой ассоциацией к менеджменту у всех единогласно был утренний будильник, всегда звенящий не вовремя. Пожалуй, не будем продолжать, Вы и сами все всё про всё это знаете, оно везде так, не только в IT.



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



Все так же понимали, что ни Скрам, ни Водопад, и ничто в этой вселенной не отменит здравый смысл. Что если происходит пожар на продакшене — его надо тушить. Что если что-то упустили и надо срочно — то будет прерывание и выпадение из контекста, это естественно. Что нельзя отказаться от необоснованного общения с менеджментом, и никакой SCRUM не спасёт от внезапно возникшей “чудо-идеи”. Что технический долг никуда не денется, и задач сопровождения будет всё больше и больше, до тех пор пока число пользователей будет расти. А именно обеспечение этого роста и есть ключевая задача, не менее важная чем разработка новых продуктовых фич. И что ни скрам, ни канбан, ничто не спасёт от всего этого бардака, так как система не может быть замкнутой, она дышит, она — живой организм.



— Таким образом, мы все хотим расти, развиваться, писать код, но, чтобы всё это было так же интересно как и сейчас, нам нужен какой-нибудь новый “paradise”?



Все кивнули. Джонни снова раскурил уже давно погасшую трубку.



“Мы владеем коммандой, которую нужно Ре-Инжинирить!”



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



— Все же помнят разницу между TCP и UDP? — Джонни пояснил, что это метафорично в контексте сказки, и все согласились, что UDP лучше подходит для стриминга, но не гарантирует доставку.



Потом всем стало ясно, что менеджмент хочет, чтобы мы совместили в себе и UDP и TCP, то есть гарантировали доставку для высокой скорости поставки новых фич.



— У нас есть коллектив разработчиков, который, так уж сложилось, поделился на комманды. Во главе каждой комманды стоит Team Lead, и почти всегда это кто-то из наших Senior Developer’ов. Над нами есть CEO и CTO. Так же у нас здесь все остальные непонятные люди, которые постоянно прерывают процесс и вносят свои коррективы. И, вот, вроде бы все разработчики вроде бы постоянно заняты разработкой, но кто-то всё время простаивает или перегружен и/или попутно занят решением какого-нибудь из типов прерываний: от руководства, от саппорта, от технического долга. То есть, мы постоянно имеем дело с каким нибудь FuckUp, кторый происходит потому, что просто всё так сложилось. У нас вроде бы есть процесс, но он не решает проблему того, что когда Ты хочешь писать код — ты не можешь, а когда можешь, то уже не хочешь, так как устал, пока не мог, и вообще решал другие “важные” задачи. Кто на митинг пошёл, кто за чаем, и вот так вот плов всё никак не сварится до нужной кондиции.



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



— Я предлагаю объединить комманды по другому. Во главе комманды не может стоять Team Lead. То есть, всё будет как и раньше, только управлять коммандой будет не Senior Developer, а кто-нибудь более-менее грамотный из Middle или даже перспективных Jun’ов.



Это как-это?



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



Например, у нас есть Pool высококвалифицированных и самых компетентных специалистов, давайте так обзозначим Senior Developer’ов. Далее у нас есть менее компетентные, которые очень хотят “расти” и стать более компетентными. Но им постоянно не хватает ни времени “старших” братьев, ни уважения менеджмента, ни, тем более, понимания процессов.



Конечно, здравым смыслом пренебрегать не стоит, Senior — он на то и Senior, что может сам поднять упавший сервер, когда и в каком бы состоянии Ты его не разбуди. Но только руководить разработкой он не должен. Он должен разрабатывать, принимать решения и ответственность за их реализацию. А вот управлять процессом должен Middle или опытный Jun, просто потому, что они смогут:


  • — всё увидеть сами

  • — захотят задать правильные вопросы

  • — осознают, что им ещё расти и расти, но они уже могут что-то сами

  • — натаскаются, в конце концов

  • — опылятся и т.п. и т.д.





И тогда, через год у нас будет не 8 Сеньоров, а минимум в два раза больше. Мы же уже два года не меняем перспективы. Нанимаем вроде бы отличных сеньоров, а джуны в мидлов почти не растут, да и мидлы почти не растут в сеньоров.



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



— Представь, Дёма, что Ты смог бы работать, именно Работать, а не просто сидеть в скайпе ежечасно отрываясь на кодец, не по 20+, а по 30-40+ часов в неделю? Ты же и так работаешь по 60+ часов только из-за того, что постоянно кто-нибудь врзывает Тебе мозг, а работа стоит, а сделать её надо, ты же ответственный!



Конечно, Дёма не мог не согласиться, он уже две недели жену и дочь видел только спящими. Он очень хотел как-нибудь всё же уйти домой вовремя.



— Представь, Вася, что Ты бы был начальником у Дёмы? У Тебя же бы все дела спорились, Может и Анита из аккаунтов, наконец бы Тебя заметила? А там, глядишь, Ты бы увидел код Дёмы из-за спины, и понял бы, что в нём нет никакой “магии”.



Конечно у Васи загорелись глаза. Он и представить себе не мог это в самых радужных снах, руководить отделом! Уж он то знал точно, как всё устроить, если бы у него только были ещё и такие подчинённые как Дёма, он бы давно всё порешал.



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



Варя просияла, так как она поняла, в чём проблема. В основном она работала с Аристархом, тем ещё Хипстером: “коммандиром” FrontEnd комманды. Личность он был весьма импозантная, и код у него был великолепен. Проблема была толкьо в том, что ему некогда было его писать, и большая часть задач решалась его подчинёнными, и у него даже не всегда было время на Code Review. Так как он был чуть ли не единственный человек, который понимал процесс создания красивостей “в комплексе”, то порой даже и отдел продаж контактировал с ним напрямую, минуя всю технологическую цепочку. Это был единственный человек в комманде, который мог понять дизайнера сразу, не переспрашивая, и не уточная. Конечно, вся его комманда на него молилась, но Варя страдала. Она понимала, что половина его подчинённых ждут когда же он обратит внимание на ею, Варей, найденные баги.



Конечно же, этой ночью никто из-них уже не мог сомкнуть глаз, несмотря на усталость.

Утром они встретились на веранде и определили желаемые новые субординации и составы команд.



К вечеру был готов “меморандум”, который они тайком приклеили на SCRUM доску.

В меморандуме было лишь следующее:



Un-FuckUp-able Development Protocol (UDP)




  • Team Lead !== Team Manager

  • Team Manager == Middle Developer

  • Senior Developer == Code Leader (GOD of Code)





И QR код на “по-быстрому” подготовленный документ, излагающий основные принципы вчерашней PR компании идей Джона.



***



Do You like my Story, man?



Конечно, у них было всё, и метрики производительности, и Grade’ы, и SMART и всё такое остальное важное-преважное, что мы все так сильно любим. Но все же мы понимаем, что хотим, не так ли?



Sincerely Yours John…
Original source: habrahabr.ru.

https://habrahabr.ru/post/307134/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Разработка личной системы управления

Среда, 27 Июля 2016 г. 15:46 (ссылка)

Мотивация



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



Если интересно, что с этим может поделать отдельный человек — добро пожаловать под кат.



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



Итак, что может сделать отдельный customer, чтобы усложнить задачу по формированию собственного предсказуемого поведения? Для меня ответ заключается в следующей фразе — чтобы научиться чем-то управлять, необходимо научиться это измерять.



Но что может измерять человек сам у себя и как это анализировать? Решение придумано довольно давно — это ведение личного дневника (своя/моя little data) и последующий анализ зафиксированных событий.



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



Итак, какими свойствами может обладать идеальный дневник:


  • Заведение данных и их быстрая (в пределе, автоматическая) классификация, по разным видам объектов, таких как, мысли, задачи, напоминания, контакты, сон, заметки и т.д. Ведение связей между объектами;

  • Загрузка данных из внешних источников (соц.сетей, банковских счетов, трекеров физ.активности);

  • Автоматическое построение аналитики, по разным срезам информации;

  • Выдача подсказок по текущим действиям (задача с высоким приоритетом, дни рождения и т.д. и т.п.);

  • Возможность настройки алгоритмов, по индивидуальной обработке объектов;

  • Система должна предоставлять выбор, какая информация доступна для публикация во внешнюю сеть, а какая остается персональной (реализация должна обеспечивать честность в этом отношении), данные во внешней сети также классифицируются и раскладываются на составляющие;

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



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









Задача



Изначально я ставил перед собой следующие цели:


  1. Создание любых видов объектов без разработки;

  2. Вывод одинаковых объектов на отдельной странице с отображением в табличном виде, а также с возможностью перехода к отдельному объекту и отображения\ведения в виде карточки;

  3. Возможность установления связей между объектами;

  4. Настройка статусов и категорий для объектов;

  5. Ведение аналитики\напоминалок\прогнозирования.



Результаты



Получилось:


  • Создание новых объектов;

  • Создание статусных схем, привязываемых к любым видам объектов;

  • Есть возможность создавать ссылки между объектами, ссылки отображаются в отдельной вкладке. По сути ссылки решают задачу наследования и являются связями между любыми объектами;

  • Гиперссылки на объекты — возможно задавать прямую ссылку на объект;

  • Для задач есть возможность создания отдельных папок для удобства обработки.



Проблемы:


  • Нет аналитики;

  • Нет каскадного удаления дочерних объектов;

  • Нет возможности поиска объектов;

  • Нет возможности на одной странице обрабатывать несколько объектов;

  • Сложность создания новых видов объектов (описание объекта занимает порядка получаса, даже у меня как автора)

  • Более менее понятная архитектура превратилась в набор хаков



Решение



Disclaimer! Автор не является профессиональным программистом и специалистом в области разработки на python\js, а всего лишь любителем, поэтому идеи по правильной организации архитектуры и используемым технологиям приветствуются и я буду очень благодарен за данные советы.



Код на github



Используемый инструментарий



Backend:


  • Python 3.2.5 — Серверная часть

  • SQLite 3.5.1 — База данных



Frontend:


  • Bootstrap 3.3.6 — Отображение данных

  • JQuery 2.2.0 — Логика

  • TinyMCE 4.3.2 — Редактор текста. Дополнительно использовался плагин syntaxhighlighter, для форматирования кода.

  • Datatables 1.10.10 — Отображение данных в табличной форме.



Архитектура решения



image



Общее описание архитектуры




  1. На Python написан сервис, который крутится на localhost и выполняет обработку запросов от html-страниц.

  2. Объекты представляют собой html-страницы с определенной разметкой, в которой указываются названия полей, соответствуют полям в базе данных (не используется никаких ORM решений, обработка осуществляется своим велосипедом)

  3. Общение с сервером происходит через json-сообщения.

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

  5. Есть встроенные объекты, это статусы и отношения, остальные объекты описываются отдельно (см. ниже)



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



Frontend:


  • Main.js — Точка входа для обработки событий frontend. Производится инициализация начальных данных, обработка событий с html-страницы, вызов других объектов для работы.

  • datatype.js — Внутреннее преобразования данных в необходимый формат для обработки в зависимости от сценария.

  • card.js — Обработка карточки объекта, отображение данных карточки для редактирования, просмотра, связей, сохранение данных.

  • main_view.js — Управление отображением карточки\таблицы на странице

  • myajax.js — Обертка для ajax-запроса

  • mydatatables.js — Обертка для работы с datatables.net.

  • mytinymce.js — Обертка для работы с TinyMCE

  • %ObjectName% — Параметры, по каждому виду объекта.

  • all_relations.js — Все возможные виды объектов, доступных при отображении отношений.

  • object_state.js — Класс для обработки вида объекта

  • rel.js — Обработка отношений между объектами.

  • requester.js — Преобразование данных в формат для передачи на сервер.

  • settings.js — Константы.



Backend:


  1. server.py — Обработка запросов.

  2. json2sql.py — Преобразование json-запроса с frontend в sql-запрос для БД

  3. dbserver.py — Выполнение sql-запроса.

  4. settings.py — Параметры.

  5. object2db.py — Параметры видов объекта на сервере.

  6. actionfile.py — Создание директорий для задач.





Схема базы данных:


  • %object_name% — Отдельная таблица для каждого создаваемого объекта.

  • sys_status — Возможные статусы, сгруппированные по статусным схемам.

  • Sys_rel2obj_items — Данные по связям между объектами

  • Sys_rel_object2object — Настройка соответствия отношений между объектами

  • object_type — Описание типов

  • Sys_rel — Описание отношений





Примеры JSON-сообщений:


  • Получить статусы по объекту — {“object”: “status”, “action”:”select”, “items”:[{“id”:1,”msg”:{“fields”: [{“column”:”id”, “op”:”>=”, “value”:”0''}]}}]}

  • Получить отношения по объекту — {“object”: “rel_items”, “action”:”select”, “items”:[{“id”:1,”msg”:{“fields”: [{“column”:”obj1_type”, “op”:”=”, “value”:”project”},{“column”:”id1'', “op”:”=”, “value”:”22''}]}}]}

  • Получить возможные отношения объектов — {“object”: “sys_rel_object2object”, “action”:”select”, “items”:[{“id”:1,”msg”:{“fields”: [{“column”:”id”, “op”:”>=”, “value”:”0''}]}}]}

  • Получить все объекты — {“object”: “project”, “action”:”select”, “items”:[{“id”:1,”msg”:{“fields”: [{“column”:”id”, “op”:”>=”, “value”:”0''}]}}]}

  • Создать объект — {“object”:”project”, “action”:”insert”, “items”:[{“id”:0,”msg”:{“fields”:{ “title”:”123'',”note”:”123” }}}]}

  • Изменить объект — {“object”:”project”,”action”:”update”,”items”:[{“id”:0, “msg”:{“fields_set”:{“title”:”1234'',”note”:”123”}, “fields_where”:{“id”:”22''}}}]}





Где:


  • Object – тип объекта (например, проект, задача и т.д.)

  • Action – тип действия (создание, удаление, измение, удаление, получить)

  • Items – в рамках одного сообщения, можно запрашивать несколько элементов, например, делать несколько insert.

  • Msg – сообщение в рамках одного пакета

  • Fields – поля по данному объекту





Некоторые из созданных объектов:


  • Project– ведение проектов.

  • Task– ведение задач

  • Question– ведение вопросов

  • Think– ведение мыслей, идей и т.д.

  • Timing– контроль времени ()

  • Contact– ведение контактов

  • Diary– ведение личного дневника

  • Snippet– snippet



Алгоритм создания нового объекта




  1. Создать таблицу в БД

  2. Создать файл %object_name%.html

  3. Создать файл %object_name%.js

  4. Описать объект в файле object2db.py

  5. При необходимости добавления статуса заполнить данные в таблицах (sys_status)

  6. При необходимости создания новых отношений заполнить данные в таблицах(sys_rel_object2object)



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



Планы на будущее для версии 2.0



Идеал – работа с любыми объектами в рамках одного окна, минимум действий с помощью мышки. Максимум перевести на описание в командной строке.



Идеи:




  • Редактор объектов. — Создание объектов, без необходимости ручного создания html-страниц, наличия отдельного js-файла для объекта и отдельной настройке на python.

  • Создание статусов.

  • Создание\настройка отношений.

  • Отображение на одной странице множества объектов. — В настоящий момент архитектура построена таким образом, что на одной странице возможно отображение только одного вида объекта (не считая ссылок на другие объекты).

  • Командная строка — Командная строка для сокращения кол-ва действий для выполнения операций.

  • Например, находясь на объекте «Проект» в командной строке набирается «Задача» и происходит автоматическое создание объекта «Задача» со ссылкой на данный проект. Т.к. в настоящий момент нужно перейти на вкладку

  • Шифрование. — Добавить шифрование БД.

  • Аналитика — Возможность базовой аналитики по объектам, с отображением кол-ва по статусам, важности и т.д.

  • Добавление объекта сроки(даты) — Отдельный объект, который можно добавлять в любой объект с возможностью добавления стоков

  • Активности — Возможность отработки определенных действий

  • Проверка на дублирования — При создании инстанции объекта проверка на дублирование

  • Обязательность полей — Определение полей, обязательных для заполнения.



Заключение



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



Данной системой пользуюсь, порядка 3 месяцев, попутно исправляя ошибки, полёт ± ровный.



Спасибо за уделённое время.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306540/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Школа_славянской_магии (Автор -Бася_Ведающая)

Правило двадцати минут

Воскресенье, 03 Июля 2016 г. 08:18 (ссылка)






За 20 минут можно вытерпеть любое действие, которые вы совсем не хотите делать. Это хороший способ начать что-то делать, бороться с ленью и повысить свою мотивацию.





 





Кто занимается спортом 20 минут в день, тому не стоит беспокоиться о своем здоровье.



Кто уделяет 20 минут в день уборке своего дома, тому не стоит переживать о беспорядке.



Кто выделяет 20 минут в день на улучшение концентрации, тому не стоит беспокоиться о творческом кризисе.



Кто находит 20 минут в день, чтобы выслушать о делах своего мужа или жены, не стоит беспокоиться о проблемах в отношениях.



Кто выделяет 20 минут в день на слушание себя и ведения личных записей, тому не стоит беспокоиться о недостатке идей.



Кто 20 минут в день работает над созданием источников дохода, тому не нужно переживать о собственном финансовом благополучии.



Кто выделяет 20 минут на отдых, не следует опасаться переутомления и усталости.



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

Метки:   Комментарии (1)КомментироватьВ цитатник или сообщество
Воз-дух

"Продолжение темы: Управление временем или астрология успеха...

Четверг, 09 Июня 2016 г. 19:36 (ссылка)

Это цитата сообщения galkapogonina Оригинальное сообщение

Продолжение темы: Управление временем или астрология успеха - pavel_sviridov Лекция вторая.

pavel_sviridov - http://pavel-sviridov.livejournal.com/
Первую часть семинара по астрологии успеха - Первую лекцию Управление временем или астрология успеха - 1 смотрите по этой ссылке.




Лекция вторая. Часть 1.
Управление временем или астрология успеха - 4
Jun. 7th, 2016

Читать далее...
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Всеслава_Ветер

Используем время эффективно. Разговоры

Понедельник, 28 Марта 2016 г. 23:01 (ссылка)


Как долго вы говорите ни о чем? Как часто вы тратите время на пустые разговоры?



Ответы на эти вопросы помогут вам существенно переосмыслить необходимость длинных разговоров ни о чем.



Почему следует опасаться пустых разговоров?



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



Признаки пустой болтовни:



- занимает много времени;



- может длиться часами;



- забирает энергию, опустошает;



- отнимает желание действовать.



После пустой болтовни вы вряд ли будете рваться покорять высоты или активно действовать. Дело в том, что необходимый потенциал уже высвободился и не может принести результата. По этой же причине не нужно обсуждать планы, важный день со всеми подряд. И ваши дальнейшие действия после результатов. Это бессмысленно и не эффективно.



 



Пустая болтовня с соседями и знакомыми



Болтовня с соседями и знакомыми может быть знаком вежливости, внимания, формальностью, а может быть и пустой болтовней, серьезно отнимающей наше время.



Во всем нужна мера. Разумеется, невозможно оградить себя от разговоров вовсе, но их объем можно существенно уменьшить.



 



Используйте речь как дар, а не как проклятье!



 



Пустые телефонные разговоры



Замечали ли вы, что всякий раз выходя из дома или транспорта, ваша рука тянется к телефону? Безусловно, этот разговор важный...



Хотя и без половины этих машинальных звонков легко можно обойтись.



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



 



Ваша энергия там, где ваше внимание!



 



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



 



Как избежать разговоров ни о чем?



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



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



 



- определитесь со временем;



- следите за ходом беседы не включайтесь в разговоры ни о чем и переливания из пустого в порожнее;



- тратьте минутки затишья на совершенствование себя.



 



Существует мнение, будто чрезмерная болтливость свидетельствует о боязни одиночества.



 



Помните несколько правил:



1.Больше всего энергии тратиться при обсуждении людей. Не осуждайте и не обсуждайте людей.



2. Не пытайтесь никого переубедить. У каждого свой ум и свой путь.



3. Учитесь быть наедине с собой.



 



Управляйте своим временем сами, или оно будет управлять вами!


Комментарии (0)КомментироватьВ цитатник или сообщество
Совет1

Техника «помидор» или Как работать максимально эффективно

Воскресенье, 06 Марта 2016 г. 22:40 (ссылка)

Техника «помидор» является довольно распространенной техникой для улучшения своей работоспособности. Благодаря ей, рабочий процесс будет куда эффективней. Как работает этот метод управления временем?..Далее

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Совет1

Как узнать куда мы тратим свое время

Вторник, 01 Марта 2016 г. 05:48 (ссылка)

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

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Maxim_Manakov

ТАЙМ МЕНЕДЖМЕНТ ДЛЯ ДЕТЕЙ

Понедельник, 29 Февраля 2016 г. 05:25 (ссылка)


https://www.youtube.com/watch?v=wVqh7iOIoaY



5783185_TAIM_MENEDJMENT_DLYa_DETEI (700x393, 162Kb)

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Совет1

Техника «помидор», или Как работать максимально эффективно

Вторник, 22 Декабря 2015 г. 16:31 (ссылка)

Техника «помидор» является довольно распространенной техникой для улучшения своей работоспособности. Благодаря ей, рабочий процесс будет куда эффективней. Как работает этот метод управления временем?..Далее

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
life__is__great

Осознанный выходной

Воскресенье, 09 Ноября 2015 г. 00:35 (ссылка)


За 3 года интенсивного впахивания,  только сейчас, поняла, что у меня нет выходных. 3 года без выходных!! Вы подумаете: "что за бред?" Но некоторые из вас точно такие же. Сейчас все по полочкам разложим!



За эти 3 года у меня были календарные выходные. Я даже могла себе спокойно поехать в путешествие на месяц, или на отдых на недельки 2. Но это были не выходные. Даже будучи на календарных выходных, я дотягивала хвосты по работе дома. Получалось, что на этих выходных я работала было больше, чем в будний. А когда ехала на море на пару недель, я оставалась на связи 24\7. Мне каждый день кто-то звонил, я давала задания, контролировала процессы, что-то решала, даже будучи на море.  Да, это по-своему круто и комфортно, лежать на пляже с коктейлем и работать(отдыхать???). В итоге получалась ни отдых и ни работы на 100%. Как-то ни то и ни сё. Даже я если ничего не делала, я мыслями думала, как помочь процессу.



Только сейчас, когда времени не хватает даже на себя, решила остановится, абстрагироваться и посмотреть на все с другого ракурса. Мне нужно отдохнуть мозгами. Чтоб на работе думать о работе и быть включенной на все 100%, на отдыхе думать о отдыхе и не думать о чем-либо. Даже я дошла до такого, что во время секса я думаю о работе\отдыхеscare.  Это не нормально!! Я так с ума сойду.



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



И вы знаете, я столкнулась с тем, что во-первых: у меня ломка, мне нужно что-то делать, во-вторых: мне делать нечего!!! Аж страшно. Маникюр\педикюр сделала, в ванной аж 1.5 часа провалялась, 3 фильма посмотрела... На телефоне уже 15 пропущенных, я игнорю. Мне нужно научится отдыхать. Я забыла как это. Я не хочу бухать, тогда у меня следующий день из жизни просто выпадает, а я дорожу каждой секундой своего осознанного времени. Тусить на дискотеках мне нравилось... раньше... Сейчас там куча иностранцев, которые пытаются снять меня всяческими способами. В тренажерке уже сегодня была... Рисовать сейчас не хочется, книжку читать не хочется... В кино сходить?? эм.. да ну... Блин, и что делать в осознанный выходной??? Если свои хобби монетизировала и теперь это уже не только удовольствие но и работа. Состояние фрустарации.



Когда ходила на йогу, мне нравился процесс медитации, где мы минут 20 находились наедине сам с собой и свои телом и включалась в этот процесс на 100%. После йоги (медитаций), у меня как-то ритм жизни был другой... Работа работалась, и во время секса думала о удовольствие и партнере(рах).



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



Теперь, по воскресеньям, у меня осознанный выходной, на котором я не знаю что буду делать, но это будет приносить мне массу удовольствия и это будет не работаpardon. Планирую ввести в список ежедневных ритуалов медитацию. Чтоб это было как чистить зубы - само собою разумеющийся процесс.



А я сейчас пошла приготовлю чего-то вкусненького, еще одну масочку на лицо, еще пару пабликов сюда и еще немного ничего не поделаю перед сномangel.

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<управление временем - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda