Как поставить задачу программисту 1с

Обновлено: 07.01.2025

Одна из основных проблем в ИТ проектах — взаимопонимание двух миров: бизнеса и разработки. Одни хотят быстро и красиво, другие хотят получить исчерпывающее описание хотелки. Переговоры занимают много времени, но еще больше — исправление ошибок. Как эффективно выстроить процесс, рассказывает зам технического директора музыкального сервиса «Звук» Кирилл Ларин.

заместитель технического директора музыкального сервиса «Звук» Кирилл Ларин Ольга Соркина

Так как разработка (+тестирование) — самое дорогое звено в создании ИТ-решения, то необходимо экономить время разработчика любым способом.

Если задача поступает в разработку с неполным описанием, то есть в ней нет всех Use cases и Corner cases, то разработчик тратит массу времени на выяснение нюансов. Или не хочет вступать в полемику и делает все, опираясь на свою картину мира, по принципу “художник так видит”.

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

Одно из решений — выработка стандарта описания задач. Лучше больше продумывать их до реализации, чем додумывать в процессе исполнения. Здесь необходимо найти баланс между заказчиком и разработкой.

Основа баланса — смещение большей части работы на постановщика/представителя бизнеса. Чем лучше он проработает фичу, тем вернее будет результат на выходе.

Однако часто бизнес не знает, что требуется разработчику, чтобы сделать задачу верно и в срок. Как найти общий язык?

Сквозь слёзы и пот мы в Звуке сформировали стандарт, который позволяет получить 90% информации, необходимой для решения любой it-задачи.

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

Для этого заказчику необходимо описать следующие аспекты задачи:

Требование
Проблема, которую надо решить
Продуктовые требования
Технологические требования
User stories
Use cases
Corner cases

Рассмотрим подробно каждый аспект.

Для точного определения, что требуется сделать в постановке задачи используется принцип SMART:

Specifiс. Задача должна быть конкретной. Куда мы пойдем, чего мы хотим достичь?
Measurable. В чем должен измеряться результат и какой результат будет для нас хорошим
Attainable. Достижимые цели. Здесь мы проверяем, находятся ли наши цели в реальных пределах
Relevant. Все задачи должны относиться к бизнесу и должны вести к цели проекта
Time-bound. Обязательное ограничение во времени. Большие задачи надо стараться разбить на более мелкие

Какую проблему заказчик пытается решить?

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

Какие технологические требования и ограничения предъявляет заказчик к функционалу?

Какая функциональность ожидается?

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

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

Текст самой US должен объяснять роль/действия пользователя в системе, его потребность и выгоду, которые пользователь получит после того как история случится.

Как, <роль>, я <что-то хочу получить>, <с такой-то целью>.

Есть одна Роль
Есть одно действие
Есть одна ценность/влияние

US можно оценить по критериям INVEST:

Independent. Меньше зависимостей — легче планировать
Negotiable. Детали появляются в ходе обсуждений команды разработки и заказчика
Valuable. Измеримая история — какие метрики изменились
Estimable. Большая или расплывчатая история — невозможно точно оценить трудозатраты
Small. Небольшая история разрабатывается в рамках недели
Testable. Простой критерий готовности

Важно помнить, что:

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

Какой сценарий необходимо пройти, чтобы достичь цель?

Что UC включают в себя:

Кто пользуется системой
Что пользователь хочет сделать
Какая у пользователя цель
Шаги к достижению цели
Как система реагирует на действия пользователя

Что UC не включают в себя:

Реализацию на специфическом языке (терминология и т.п.)
Информацию про интерфейсы

В зависимости от глубины и сложности того, что вы хотите или должны достичь, UC описывают комбинацию следующих элементов:

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

Для написания UC используются следующие шаги:

Определить кто будет пользоваться системой.
Выбрать одного пользователя.
Определить, что этот пользователь будет делать с системой. Каждое действие станет UC.
Для каждого UC определить курс событий, когда этот пользователь использует систему.
Опишите основной курс в описании для UC. Опишите его с точки зрения того, что делает пользователь и что система делает в ответ, о чем пользователь должен знать.
Когда базовый курс описан, рассмотрите альтернативные курсы и добавьте их, чтобы «расширить» UC.
Ищите общие черты среди UC. Объедините их как UC одного курса.
Повторить шаги с 2 по 7 для всех пользователей.

Для того чтобы избежать непредвиденных сценариев в работе фичи, необходимо описать все возможные CC. По сути, CC отвечает на вопрос А что будет, если . СС должны покрывать большинство вариантов и указывать на причины возникновения вариантов.

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

Для этого целесообразно использовать таблицу, в которой на пересечении факторов будет описан результат/сценарий.

С теорией всё понятно, но как дело обстоит на практике? Разберем упрощенное описание задачи на примере сохранения настроек приложения.

Сохранять настройки приложения

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

Продуктовые требования

Использовать распространенный UX для реализации решения

Технологические требования

Сохранять настройки приложения на серверной стороне в связке с данными пользователя

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

— Пользователь открывает приложение.

— Пользователь входит в учетную запись в приложении.

— Пользователь устанавливает настройки приложения.

— Система сохраняет настройки.

— Пользователь выходит из учетной записи в приложении.

— Пользователь входит в учетную запись в приложении (+ на другом устройстве).

— Система передает сохраненные настройки в приложение.

— Приложение отображает сохраненные настройки пользователя.

Corner case

Обеспечить обратную совместимость со старыми клиентами.

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

Второе. Показать пример, поставить некоторое количество задач для начала по стандарту, показать заказчикам, как это надо делать, как оно работает.

Третье. При внедрении обязательно собрать обратную связь по стандарту. Ответить на все вопросы, внести корректировки. Тогда будет коллективный труд, порог вхождения ниже.

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

Пятое. Закрепить нововведения фактами в виде цифр — сравните с периодом до внедрения. Производительность увеличилась на столько-то, количество ошибок упало на столько-то.

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

В «Звуке» после внедрения стандарта скорость и качество работы увеличилось в 2 раза. Мы получили положительные отзывы от всех участников команды и решили основную проблему.

Скажите, вы когда-нибудь слышали фразу: «Дайте нам ТЗ» от ваших 1С-разработчиков?

А теперь скажите, насколько сильно она вас раздражала? Готовы ли вы были к тому, чтобы выделить личное время на изучение незнакомой вам среды, будь то 1С или что-то другое? Желаете ли вы добровольно описать функциональные, нефункциональные, системные и прочие требования, а также атрибуты качества и другие рабочие параметры, чтобы преподнести желаемый вами результат «на блюдечке» вашему подрядчику?

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

Не было ли у вас желания послать такого подрядчика к чертям?

Не опускались ли у вас руки от безысходности ситуации – ведь, чтобы сделать ТЗ нужно владеть терминологией разрабатываемой системы и, как минимум, представлять себе возможности, которые предлагает эта система при масштабировании? Располагаете ли вы такой информацией?

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

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

Конечно, я надеюсь, что такие подрядчики скоро вымрут как класс, ведь после них клиенты теряют вообще какую-либо мотивацию что-то менять в своих учетных системах.

Сегодня же я хочу дать совет. Особенно он будет актуален малому бизнесу, у которого нет времени разбираться во множестве технической информации вокруг ИТ-систем, в том числе 1С.

И вот мой совет:

Гоните в шею тех подрядчиков, кто просит у вас ТЗ. Если у вас оно есть – хорошо, но вы вовсе не обязаны заниматься работой технических специалистов.

Время ТЗ истекло. Совсем.

В современных динамично-меняющихся условиях бизнеса пока вы (или кто-то за вас) будет писать ТЗ, желаемая вами идея уже потеряет актуальность, а команда ваших единомышленников – мотивацию к ее реализации.

Именно поэтому я подготовил для вас чек-лист о том, как работать с подрядчиками максимально эффективно:

Позвоните подрядчику и обратите внимание на то, как быстро на том конце снимают трубку. Если ее не снимают – исключите такого подрядчика из вашей жизни – он будет также работать.
Попросите специалиста проконсультировать вас по вашей проблеме. Расскажите ему о ситуациях, которые вызывают неудобства при управлении бизнес-процессами, опишите, при каких обстоятельствах возникают проблемы. Послушайте ответ.
Обратите внимание на то, сколько времени готов уделить вам специалист по телефону. Если вам ответил продажник – попросите к телефону именно специалиста по 1С. Если он просит ТЗ – вы знаете, что делать
Задает ли вам специалист вопросы по существу или пытается всеми силами узнать ваш е-мэйл и распрощаться?
Спросите, решали ли в компании такую же или похожую задачу. Если решали, то есть ли рекомендации.
Договоритесь о времени, в течение которого вам будет сделано коммерческое предложение. Обратите внимание будет ли оно готово вовремя или нет.

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

Ну, во-первых, надо признаться, что вы можете не представлять себе в полной мере, что вы хотите. И это нормально, особенно, если ваш опыт автоматизации пока невелик. Если ваш подрядчик тоже это понимает, то он обязательно подскажет вам возможные пути автоматизации по вашему описанию проблемы, а не будет требовать от вас ТЗ.

Чаще всего путей решения будет несколько. Задумайтесь, если получите только один.

Чтобы ваше общение было более эффективным подготовьте ответы на наиболее часто встречаемые вопросы:

Какая у вас платформа? Платформа – это то, на чем будет строиться ваша учетная система. Набор механизмов для решения прикладных задач бизнеса. Чаще всего ответом на этот вопрос будет «8.2» или «8.3», если речь идет об 1С. Если вы не знаете, какая у вас платформа или какую платформу следует приобрести – пусть вам расскажет об этом сам подрядчик – не стесняйтесь просить его об этом.

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

Сколько пользователей будет работать в вашей системе? Хороший вопрос, который обязательно должен задать грамотный специалист. Ответ на него поможет подрядчику подобрать оптимальную инфраструктуру для вашего проекта. При ответе на этот вопрос следует закладывать в число пользователей не только текущих, но и тех, кто будет подключен к системе в течение года. Так вы сможете сэкономить на приобретаемых лицензиях.

Кто будет пользоваться системой? Так разработчик хочет выяснить роли, на которые ему будет необходимо ориентировать учетную среду. Такими ролями может быть «Менеджер», «Бухгалтер», «Директор», «Кадровик» и другие лица. Обычно за ролью кроется определенный функционал, который будет доступен или недоступен в зависимости от своего назначения. Подумайте и озвучьте подрядчику все роли, которые будут фигурировать в системе. Это не сложно, т.к. обычно состав ролей совпадает с функциональными обязанностями персонала в организации.

Зачем это нужно? Профессионал всегда спросит «зачем» даже, если вам кажется, что ответ на этот вопрос очевиден. Не удивляйтесь этому. Просто проясните ваши цели. Лучше, если этот вопрос будет задан, а ответ на него будет определен, чем выяснить в конце проекта, что полученный результат не совпадает с ожидаемым из-за разных ценностных фильтров участников проекта.

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

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

Много вопросов – это хорошо. А вот их отсутствие должно вас насторожить!

Эффективную систему учета на предположениях не построить. Любые гипотезы должны быть проверены.

Первый день на новой работе – сплошной стресс. В том числе потому что иногда сложно представить чем именно ты будешь заниматься в течении рабочего дня.

Программист 1С стажер

Что входит в обязанности программиста стажера 1С?

консультация пользователей «как сделать это в 1С»
добавить в существующий документ или справочник новые реквизиты
изменить существующий отчет когда выйдет новая версия
настроить распределенную базу (УРИБ, УРБД).

Как стать программистом 1С, стажером

Купить или скачать платформу 1С:Предприятие 8.1 и одну из типовых конфигураций, с которой предстоит работать.

Виды конфигураций: торговля (Управление торговлей), бухгалтерия (Бухгалтерия) или зарплата (Зарплата и управление персоналом).

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

Что должен знать программист 1С стажер

как пользоваться конфигуратором
как добавить реквизит, как изменить стандартный отчет
как настроить в типовой конфигурации УРИБ и другие доп. возможности
установка и обновление 1С

А что должен уметь опытный программист 1С?

Что входит в обязанности опытного программиста 1С?

нужно внедрить 1С с нуля – компания только переходит на 1С
большие доработки типовой конфигурации – например добавить несколько документов и сделать по ним отчет
нетиповая или сильно переделанная конфигурация – в этом случае с ней придется разбираться «на лету», в таких случаях что и где находится в конфигурации может не знать никто
требуются значительные знания прикладной (предметной) области – например нужно действительно сильно знать бухгалтерию, МСФО и прочее.

Как стать программистом 1С

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

После чего добавить все это и посмотреть что получится.

Что должен знать опытный программист 1С?

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

Как стать экспертом 1С?

В первую очередь он имеет большой опыт работы (более 3х лет). Во вторую очередь он способен составить самостоятельно ТЗ, хотя бы и не на бухгалтерскую тему. И наконец ему известно, что в 1С кроме мейнстримовых возможностей есть большое количество других механизмов.

Тайм-менеджмент для программистов: стандартный сценарий

Тайм-менеджмент – наука об организации своего времени и увеличении производительности его использования. Имея представление о принципах работы этой технологии, вы значительно продвинетесь в достижении своих целей и научитесь отсекать ненужные направления в своей жизни, которые только ведут в тупик. Давайте поговорим о том, как программист 1С может использовать эти принципы в работе и обучении.

Как определиться с целью? Целеполагание.

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

Для определения цели (целей) требуется сначала подумать, каким вы видите себя в будущем. Далее необходимо осознать, какими путями можно прийти к этому будущему. Путей может быть несколько, нужно выбрать самый предпочтительный. Выбрав путь – вы поставите перед собой цель.

Допустим, вы программист 1С, который делает только первые шаги в этой сфере. Но вам хочется работать на постоянной основе. Какие есть пути достижения этой цели? Можно устроиться на работу в одну из компаний-франчайзи 1С, можно работать удалённо (фриланс), а можно оказывать частные услуги, подав объявление в газету. Необходимо выбрать наиболее реализуемый вариант, который зависит от конкретного человека. Если вы только начинающий программист, то искать постоянную работу в 1С-сфере лучше через фриланс-биржи. Если вы живёте в большом городе, где сложно устроиться на работу по специальности, возможно, стоит попробовать работу «по объявлению». И так далее. Это и есть целеполагание.

Составление общего (стратегического) плана.

Затем наступает черёд стратегического планирования. Это долгосрочный план, в котором должны быть учтены все направления вашей деятельности, которые помогут добиться поставленной цели. Допустим, вы ещё не программист 1С, а только планируете освоить эту профессию. Это ваша цель. Чтобы её добиться, нужно: читать специальную литературу (печатную и на интернет ресурсах), посещать курсы, проходить веб-семинары и так далее. Но важно не просто заниматься всеми этими направлениями вперемешку и без осознания того, что вы делаете. Необходимо чёткое понимание выполняемых действий и осознание того, к чему они ведут. В этом и есть суть стратегического планирования.

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

Пример правильного стратегического планирования.

Для обучения специальности будущий программист 1С должен разработать примерно такой план:

Изучение основ внутреннего языка программирования 1С;
Выполнение продвинутых упражнений на знание внутреннего языка программирования 1С;
Изучение языка запросов 1С;
Выполнение продвинутых упражнений на знание языка запросов в 1С;
Создание отчётов и обработок для системы 1С:Предприятие;
Доработка существующих конфигураций.

Это и есть те самые «ступеньки», которые образуют лестницу стратегического плана.

Тайм-менеджмент помогает оптимизировать ваши временные затраты. Способствует концентрации именно на том, что важно в данный момент времени, и отметанию тех дел и стадий обучения, которые сейчас вам не пригодятся. Если перепрыгивать «через ступеньку»:

Вы не поймёте материал в правильной его интерпретации;
В голове возникнет путаница;
Вас это замедлит на стадии обучения текущему предмету.

Составление детального плана на день.

Этот принцип важен и при ежедневном обучении, и при выполнении стратегического плана в целом. Так, каждый этап стратегического плана может быть разбит на подпункты. Допустим, первый этап обучения «Изучение основ внутреннего языка программирования 1С». Обучаться можно по книгам, по интернет ресурсам и прочему. Хотя важно, чтобы имелся один постулативный элемент, «настольная книга», а уже в дополнение к ней изучались остальные источники.

Детальный план в ежедневном планировании.

Это незабвенный принцип «Целого слона можно съесть по кусочкам». Допустим, у вас есть задача: обновить нетиповую конфигурацию 1С. План может быть следующим:

Создание резервной копии обновляемой базы данных;
Остановка регламентных и фоновых заданий;
Подготовка каталогов с конфигурациями;
Обновление неизмененных в рабочей базе объектов;
Обновление частично изменённых в рабочей базе объектов;
Обновление частично изменённых в новой типовой конфигурации объектов;
Обновление полностью изменённых в новой типовой конфигурации объектов;
Обновление прочих объектов учёта;
Загрузка изменённой конфигурации в рабочую базу данных.

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

Принцип Парето.

Он звучит так: «20% усилий формируют 80% результата, а 80% усилий формируют 20% результата». Данный принцип применим к любым сферам деятельности человека. Вы опытный программист 1С? Подумайте, какие дела занимают у вас много времени, а результата практически не приносят, и наоборот? Отбросьте первую категорию дел, и занимайтесь второй. Допустим, вы работаете в компании-франчайзи и параллельно подрабатываете на фриланс-бирже. Очень часто удалённая работа при существенных на неё временных затратах приносит очень мало прибыли. Так может, лучше сосредоточиться на основной работе и стремиться получить более высокую квалификацию именно там? А возможно, у вас более двух источников дохода. Тогда сосредоточиться нужно на основных.

Инструменты тайм-менеджмента.

Опытный программист 1С знает, что подчас ему ставятся объёмные задачи, выполнить которые необходимо с максимальной скоростью. Когда список дел широк, непросто всё удержать в голове. Для самоконтроля существуют специальные инструменты:

Самый простой из них – электронный или бумажный органайзер, куда можно записывать все дела;
To-Do – компьютерная программа для ведения заметок;
Таймер – для лимитирования времени и оценки того, насколько увеличилась продуктивность по отношению к затраченному времени;
Macro Recorder или MouseRobot – программы для записи типовых действий пользователя (макросов) и последующего их воспроизведения.

Подобных инструментов много. У каждого свои принципы работы, но цель одна – оптимизация вашего времени.

Составление инструкций (скриптов).

Скрипты необходимы для выделения повторяющихся блоков и делегирования своих полномочий другим людям. Цель подобных скриптов – максимально упростить вашу работу, а возможно в дальнейшем – и вовсе превратить её в пассивный источник дохода, где вы будете лишь координировать действия других.

Тайм-менеджмент – основа успеха любого богатого человека. Вы не найдёте ни одного главу крупной компании, у которого не было бы блокнота (или альтернативы) для пометки важных дел. А вспомните картину: начальник идёт по коридору, а рядом его помощник (или секретарша) рассказывает ему о делах, которые ему требуется сегодня выполнить. И это вовсе не завышенное эго, а всё та же оптимизация времени, но в более глобальном масштабе. Обучаясь основам тайм-менеджмента, вы как минимум становитесь на путь этих успешных людей.

Читайте также: