![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
- gtd,
- management,
- motivation,
- quality,
- ru
RFC / TODO List
Начиная новый проект, каждый раз думаю, как сделать TODO лист более эффективным. Прочёл стопку книжек, пробовал много программ и способов, пару сам написал. Но счастья не нашёл. И вот вчера, обдумывая новый способ записи, понял, что проблема на идеологическом уровне.
Записывается общее название действия, а не его результат. Для
То есть, список надо делать более циничным и правдивым, чтобы все варианты не выглядели ошибкой, а являлись полноправными.
Возьму простой случай:
Сейчас пытаюсь классифицировать
Первоначальный вариант под катом. Список не причёсанный и не полный, так как писалось в отеле, одной ногой в двери на выход.
UPD Немного подедактировал список. Как ожидалось, особого ажиотажа вопрос не вызвал. Буду исправляться и писать ерунду.
Записывается общее название действия, а не его результат. Для
сделать то-тоесть единственный
правильныйответ
Done, хотя проблему могут решать и варианты
Stopped,
Delegated,
Frozen,
Rejected...
То есть, список надо делать более циничным и правдивым, чтобы все варианты не выглядели ошибкой, а являлись полноправными.
Возьму простой случай:
Продать Х. Это может быть
Убедить купить,
Оформить покупку,
Освободить место на складе способом самовывоза. И так далее.
Сейчас пытаюсь классифицировать
честныезадачи. Ищется минимальный набор типов, способный покрыть большую часть задач. Так что нужны предложения, замечания, мысли...
Первоначальный вариант под катом. Список не причёсанный и не полный, так как писалось в отеле, одной ногой в двери на выход.
- найти информацию
- показать результат (выполнить дурь начальника и отчитаться)
- создать видимость (процесса)
- передать работу
- сделать документ
- сложить информацию в одно место
- отчёт
- презентация
- бумажка для галочки (создаётся документ, который никому не нужен, но
участвует в процессе
)
- запрограммировать функцию / написать программу
- администрация софта (найти, скачать, установить, и т.п., короче сделать так, чтоб заработало)
- убедить (кого-то)
- проинформировать
- сообщить
- объяснить
- представить (Цель не передача информации, а создание чувства, что она правильная, каким бы бредом она не была. Пример - TED)
- уничтожить
- стереть (следы)
- выкинуть
- деинсталлировать
- очистить
- получить/раздобыть
- информацию
- софт
- материальный объект
- деньги (сюда входит постановка счёта, отсылка, проверка проводок, отсылка напоминаний и т.п.)
- выяснить (Напрячь интуицию. Догадаться об информации, которая не лежит на поверхности, или получить о ней слухи. Сюда входит всё возможное, исключая профессиональный промышленный шпионаж.)
- скрытые мотивы
- политическую расстановку
- перспективы
- скрытые планы
- скрытые факты
- найти ответственного
- создать пути коммуникации
- официальные пути обена информацией
- "кротовые норы" (эффективный в противоположность официальному путь обмена информацией
- подтверждённый обмен (путь доставки с подтверждением для прикрытия задницы и ответа на заяления
В первый раз слышу!
)
- саморазвитие
- выучить
- развить навык
- натренировать
- отрепетировать (подготовить сценарий с вариантами)
- создать эмоциональную связь
- получить сертификат
- официально зафиксировать (решение, отношения, протокол, договор)
- выбрать решение
- придумать
- запланировать
UPD Немного подедактировал список. Как ожидалось, особого ажиотажа вопрос не вызвал. Буду исправляться и писать ерунду.
no subject
no subject
Это идеальное условие для идеального мира. В реальности нужно заниматься не только тем, чем хочется
no subject
Список целей, не умещающийся в голове, напрашивается на приоритезацию.
Как следствие - когда что-то записываешь, приоритет либо автоматически повышается и эта задача болтается в сознании, либо понижается, и тогда задача вылетает из головы.
no subject
Это хорошо для случая, когда надо делать пару знакомых задач. Если есть два десятка разных проектов, куча людей, разнородная информация и асинхронные прерывания, стоимость переключения контекста начинает играть существенную роль.
no subject
no subject
Ищется решение задачи для данных условий. Решение другой задачи может быть замечательным, но эта альтернатива не рассматривается.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Сущности:
- персоны (т.е. конкретные люди)
- роли (рабочие - начальник, подчиненный, коллега; деловые - потенциальный заказчик, заказчик, потенциальный исполнитель, исполнитель; квалификационные - специалист, консультант; общественные - знакомый, друг, родственник, близкий родственник)
- цели (тактика - задача, план, веха, проект; стратегия - процесс, направление, миссия)
- инструменты (материальные - программное обеспечение, аппаратное обеспечение, прибор, устройство; нематериальные - методика, документ, официальный документ, знание, консультация, отчет)
- ХЗ (нечто неопределенное в данный момент, например, что равновероятно может быть и консультацией, и софтом, и методикой)
- группы (комбинации вышеприведенного в виде - множества (без учета порядка), списка(с учетом порядка), иерархии, линейных связей).
У каждой из сущностей могут быть псевдонимы и инварианты. Например, компания = иерархия персон.
Далее, операции. Я не буду придумывать новых, просто обобщу исходный список:
- найти/выбрать
- создать/запустить
- уничтожить/завершить
- сделать
- передать
- повторить
Т.о. идеальное TODO - это что-то вроде приложение для смарта (с синхронизацией в облако, куда без этого) с голосовым распознаванием и выделением объектов и операций по словарю (словарь расширяем, а еще лучше - саморасширяем) + возможность ввести заметку при помощи скольжения пальцем по экрану (как стандартные элементы тут будут отстойными). Запись идет в список и после чего ей вешается еще одна характеристика - время (точка или диапазон), в рамках которого она будет актуальна. Предположу, что достаточно два состояния - "активно" и "завершено", а "заморожено" и "отложено" получается автоматически при помощи манипуляции с таймлайном.
В данном ПО будет главное интерфейс, т.е. время на создание записи должно быть минимально и просто, чтобы можно было выработать привычку с минимальным раздражением.
Как-то так.
no subject
(я чуть ниже и своего понаписал — у нас многие мысли перекликаются :)
no subject
Просто группа и иерархия - это композитные модификаторы, т.е. они объединяют набор сущностей без рассмотрения, что эти сущности из себя представляют. Можно, конечно, копнуть глубже, но в рамках данной задачи, кажется, это будет лишним.
no subject
- роли ...
Основная проблема - не всегда понятно, где роль, а где персона. Тем более, для задачи, в которой важна компактность записи.
- цели (тактика - задача, план, веха, проект; стратегия - процесс, направление, миссия)
Опять же, тонкое деление не однозначно даже для стратегии против тактики.
- ХЗ (нечто неопределенное в данный момент,
Это нельзя делать, классификация должна покрывать всё. Иначе вот это будет присвоено 90 процентам записей
- найти/выбрать
- создать/запустить
- уничтожить/завершить
- сделать
- передать
- повторить
Я не вижу различия между последними тремя. И я не уверен в формуле "уничтожить = завершить". Хотя, первое у меня было неучтено.
В данном ПО будет главное интерфейс, т.е. время на создание записи должно быть минимально и просто, чтобы можно было выработать привычку с минимальным раздражением.
Для правильного интерфейса нужна правильная информационная модель. Нельзя методом дизайна создать что-то удобное, если надо выбирать (не задумываясь) больше чем из семи и выбор не однозначен.
no subject
На самом деле тут отношения есть, я просто не стал их акцентировать. Понятно, что у одной персоны может быть несколько ролей, равно как и, наоборот, одну роль могут играть несколько персон.
В данном случае, на мой взгляд, стоит придерживаться простого правила - если определен человек (например "показать результаты Алисе"), то это персона, если человек не определен и могут быть варианты - это роль ("показать результаты коллеге"). Понятное дело, что тогда задача может уточнятся (т.е. требовать исправления, что плохо, ибо время и переключение контекста), но, мне кажется, это делать необязательно. Все-таки между напоминалкой и педантичным списком задач для беспрекословного исполнения должна быть разница.
Ну, на этот счет можно условится жестко. Например, атомарная/рутинная/типовая задача/проект с протяженностью не более двух месяцев - это тактика, комплекс проектов или направлений исследований - стратегия. Для упрощения можно совсем отказаться от использования терминов "тактика" и "стратегия" - толку в них мало.
Это, увы, нужно, потому что почти всегда есть неопределенность. Разумеется, она имеет свойство уменьшаться (а данные по объекту уточнятся), но надо понимать, что ХЗ - это лишь связка, маячок, а контекст будет раскрываться в других словах.
Но что применение этой сущности должно быть ограничено - согласен. Например, по времени или по допустимым действиям.
Сделать - это да, повтор "создать", хотя предполагалось, что под сделать имеется ввиду некое относительно атомарное действие вне основных контекстов, например "сделать ТО".
Передать - это трансфер между сущностями. "Передать сущность:документ сущность:персона"
Повторить - операция над операциями (мы так до функций высших порядков договоримся :)), т.е. повторение уже существующей операции.
Там не равенства, а инварианты. Я просто поставил их рядом, потому как эти операции обычно завершают некий цикл.
А вот тут позвольте не согласится.
1. дизайн играет не последнюю роль (успех Эппл, например), в деле с TODO, когда альтернатив, мягко говоря, до пояса, наиболее критичным будут аспекты именно быстрого вовлечения, непринужденной работы и последующего привыкания. Скажем так, если пользователю не понравится лук или он будет тратить на внесение заметки более 30-60 секунд - на успех можно рассчитывать, только если доплачивать за использование.
2. как мы знаем, построить идеальную модель все равно не получится (с тем же успехом можно заняться моделированием всего, но это уже экстремизм). Да, мы можем покрыть большинство наших каждодневных задач, но это все равно будет достаточно неполная картина мира. Поэтому я и уточнил, что система должна быть расширяемой и каждый мог ее адаптировать под свой типовой набор действий/сущностей.
3. в моем списке не более 6 пунктов, хоть в сущностях, хоть в операциях. Да, сущности потом требуют уточнения (например, для персоны необходимо будет выбрать из потенциально объемной адресной книги), но это можно сделать в несколько шагов.
no subject
На самом деле тут отношения есть, я просто не стал их акцентировать. Понятно, что у одной персоны может быть несколько ролей, равно как и, наоборот, одну роль могут играть несколько персон.
Это только усложняет модель. И в большинстве случаев совершенно лишнее.
В данном случае, на мой взгляд, стоит придерживаться простого правила - если определен человек (например "показать результаты Алисе"), то это персона, если человек не определен и могут быть варианты - это роль ("показать результаты коллеге").
Второй вариант - это не постановка задачи, а постановка вопроса. Перед выполнением надо решить, что такое "коллега", что в большинстве случаев не тривиально. (Для того задача построения путей коммуникации и существует, чтоб определить действие однозначно и убрать муки выбора)
Это, увы, нужно, потому что почти всегда есть неопределенность. Разумеется, она имеет свойство уменьшаться (а данные по объекту уточнятся), но надо понимать, что ХЗ - это лишь связка, маячок, а контекст будет раскрываться в других словах.
При обнаружении не определённых в системе элементов, надо добавлять определение в систему, а не кормить её мусором. То есть задача "выполнить некую фигню" разбивается на две "определить какую именно фигню" (процесс постановки задачи/планирования) и "эту конкретную фигню выполнить" (выполнение задачи)
Но что применение этой сущности должно быть ограничено - согласен. Например, по времени или по допустимым действиям.
Ограничение возможно только одно "Нельзя". Любые "слабые" ограничения имеют тенденцию размываться.
1. дизайн играет не последнюю роль (успех Эппл, например)
Эппл тем и отличается, что использует для создания интерфейсов не программистские модели, а те, что в голове у пользователя. Начиная от рабочего стола и мусорной корзины.
как мы знаем, построить идеальную модель все равно не получится
Строимая модель - это не конечная версия, а зародыш. Что вырастет - зависит от полевых испытаний.
И классы должны быть легко определимыми, а не абстрактными базовыми.
no subject
* из многих версий информации получить наиболее свежую
* выяснить наиболее компетентный источник информации
no subject
Это получение/добывание информации
Сохранение инфформации - это просто обязательная часть. Иначе выходит "получить и потерять"
Вскрыть конфликт интересов или мнений - это другое, но сформулировать надо как-нибудь покороче
из многих версий информации получить наиболее свежую
Это просто решение, какую информацию использовать для работы.
выяснить наиболее компетентный источник информации
Найти ответственного - это подходит.
Ещё сюда же - официально зафиксировать решение.
no subject
В самом верху под "материальной фиксацией" это и имелось в виду: письмом или иной утверждённой формой обозначить исходную опорную информацию в виде, который потом можно использовать как аргумент.
Вторая "грань" идеи: это ещё и юридические аспекты.
*************************************************************************
Ещё выкристаллизовалось:
* для больших проектов: как можно скорее выяснить иерархию заказывающей стороны, чётко обозначить контактных лиц, обговорить возможных заместителей ключевых источников заданий/информации в случае "очень надо, а человек в отпуске" (как-то сразу много в одном, можно назвать: "иерархически определить производственно социальную сеть" :)
* получить по возможности более чёткие ответы на вопросы: "Что конкретно нежелательно и нельзя?" и "Всё, что не запрещено, значит, можно?"
* свести количество посредников к минимуму
* выяснить, какое и какой свежести железо на стороне заказчика
* составить общий облик будущих пользователей
no subject
В принципе, это относится к политике и поиску ответственных. И, как показывает практика, никакая подготовка в таких случаях не работает. Время тратится по-любому.
Впрочем, можно взять в план под заголовком "создание путей коммуникации" с подтипом "создать кротовые норы" (под официальным планом коммуникации)
получить по возможности более чёткие ответы на вопросы: "Что конкретно нежелательно и нельзя?" и "Всё, что не запрещено, значит, можно?"
Это информация, скрытая информация или юридическая фиксация договорённостей. То есть три совершенно разных варианта для одного и того же названия.
свести количество посредников к минимуму
Это как?
Можно отнести к "создание путей коммуникации"
выяснить, какое и какой свежести железо на стороне заказчика
Это информация
составить общий облик будущих пользователей
Это тоже получение информации. Причём, достаточно частный случай
no subject
Чтобы было ясней, от чего отталкиваться.
О себе: я инженер-приводчик, с уклоном в PLC, но и системно-интеграционное тестирование знакомо. И прочее.
Исходя из собственного опыта именно прошу: границы б чуть яснее обозначить. :)
no subject
Это сложно. Грубо говоря, на первом этапе всё, что связано с выполнением проекта. В перспективе - всё, включая поддержание жизнедеятельности и досуг.
no subject
А если надо что-то для медитации, мне тут из бездны нашептывают что концепция кругов ада вполне подойдёт для описания ситуации. Там как раз список всех пороков которые воплощаются в гражданах корпораций, и мешают
творцампрограммистам.no subject
Задача запланировать и выполнить множество процессов в условиях асинхронных прерываний.
no subject
В науке с этим борятся ведя журнал исследований. Типа искал кусок документации, у кофейника агент сказал что один архитектор зажимает, набил морду архитектору, забрал док. В следующий раз будете знать что сразу надо бить морду архитектору.
После нескольких проектов у вас появится инвентория которую вы пытаетесь создать. Да и для мемуаров пригодится.
Помойму проще определить список скилзов которые приходится применять. Например презентации - тренировать сценическую речь перед зеркалом. Обаяние - освоить технику внутренней улыбки. Доверие - работать с эспандером чтоб рукопожатие было крепким...
no subject
В условиях асинхронных прерываний хорошо работают женщины, но никак не мужчины.
Это только так кажется. Такие условия для всех не эффективны. И разделение не по полу, а по психической организации.
В науке с этим борятся ведя журнал исследований. Типа искал кусок документации, у кофейника агент сказал что один архитектор зажимает, набил морду архитектору, забрал док. В следующий раз будете знать что сразу надо бить морду архитектору.
Почему "в науке"? Любая разумная деятельность подразумевает ведение логов.
Помойму проще определить список скилзов которые приходится применять.
О! Спасибо. Совсем забыл целый блок: выучить, развить навык, натренировать, отрепетировать (подготовить сценарий с вариантами), создать эмоциональную связь