RFC / TODO List
Feb. 1st, 2012 09:02 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_rНачиная новый проект, каждый раз думаю, как сделать TODO лист более эффективным. Прочёл стопку книжек, пробовал много программ и способов, пару сам написал. Но счастья не нашёл. И вот вчера, обдумывая новый способ записи, понял, что проблема на идеологическом уровне.
Записывается общее название действия, а не его результат. Для
То есть, список надо делать более циничным и правдивым, чтобы все варианты не выглядели ошибкой, а являлись полноправными.
Возьму простой случай:
Сейчас пытаюсь классифицировать
Первоначальный вариант под катом. Список не причёсанный и не полный, так как писалось в отеле, одной ногой в двери на выход.
UPD Немного подедактировал список. Как ожидалось, особого ажиотажа вопрос не вызвал. Буду исправляться и писать ерунду.
Записывается общее название действия, а не его результат. Для
сделать то-тоесть единственный
правильныйответ
Done, хотя проблему могут решать и варианты
Stopped,
Delegated,
Frozen,
Rejected...
То есть, список надо делать более циничным и правдивым, чтобы все варианты не выглядели ошибкой, а являлись полноправными.
Возьму простой случай:
Продать Х. Это может быть
Убедить купить,
Оформить покупку,
Освободить место на складе способом самовывоза. И так далее.
Сейчас пытаюсь классифицировать
честныезадачи. Ищется минимальный набор типов, способный покрыть большую часть задач. Так что нужны предложения, замечания, мысли...
Первоначальный вариант под катом. Список не причёсанный и не полный, так как писалось в отеле, одной ногой в двери на выход.
- найти информацию
- показать результат (выполнить дурь начальника и отчитаться)
- создать видимость (процесса)
- передать работу
- сделать документ
- сложить информацию в одно место
- отчёт
- презентация
- бумажка для галочки (создаётся документ, который никому не нужен, но
участвует в процессе
)
- запрограммировать функцию / написать программу
- администрация софта (найти, скачать, установить, и т.п., короче сделать так, чтоб заработало)
- убедить (кого-то)
- проинформировать
- сообщить
- объяснить
- представить (Цель не передача информации, а создание чувства, что она правильная, каким бы бредом она не была. Пример - TED)
- уничтожить
- стереть (следы)
- выкинуть
- деинсталлировать
- очистить
- получить/раздобыть
- информацию
- софт
- материальный объект
- деньги (сюда входит постановка счёта, отсылка, проверка проводок, отсылка напоминаний и т.п.)
- выяснить (Напрячь интуицию. Догадаться об информации, которая не лежит на поверхности, или получить о ней слухи. Сюда входит всё возможное, исключая профессиональный промышленный шпионаж.)
- скрытые мотивы
- политическую расстановку
- перспективы
- скрытые планы
- скрытые факты
- найти ответственного
- создать пути коммуникации
- официальные пути обена информацией
- "кротовые норы" (эффективный в противоположность официальному путь обмена информацией
- подтверждённый обмен (путь доставки с подтверждением для прикрытия задницы и ответа на заяления
В первый раз слышу!
)
- саморазвитие
- выучить
- развить навык
- натренировать
- отрепетировать (подготовить сценарий с вариантами)
- создать эмоциональную связь
- получить сертификат
- официально зафиксировать (решение, отношения, протокол, договор)
- выбрать решение
- придумать
- запланировать
UPD Немного подедактировал список. Как ожидалось, особого ажиотажа вопрос не вызвал. Буду исправляться и писать ерунду.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-02-02 08:11 pm (UTC)- роли ...
Основная проблема - не всегда понятно, где роль, а где персона. Тем более, для задачи, в которой важна компактность записи.
- цели (тактика - задача, план, веха, проект; стратегия - процесс, направление, миссия)
Опять же, тонкое деление не однозначно даже для стратегии против тактики.
- ХЗ (нечто неопределенное в данный момент,
Это нельзя делать, классификация должна покрывать всё. Иначе вот это будет присвоено 90 процентам записей
- найти/выбрать
- создать/запустить
- уничтожить/завершить
- сделать
- передать
- повторить
Я не вижу различия между последними тремя. И я не уверен в формуле "уничтожить = завершить". Хотя, первое у меня было неучтено.
В данном ПО будет главное интерфейс, т.е. время на создание записи должно быть минимально и просто, чтобы можно было выработать привычку с минимальным раздражением.
Для правильного интерфейса нужна правильная информационная модель. Нельзя методом дизайна создать что-то удобное, если надо выбирать (не задумываясь) больше чем из семи и выбор не однозначен.
no subject
Date: 2012-02-03 06:09 am (UTC)На самом деле тут отношения есть, я просто не стал их акцентировать. Понятно, что у одной персоны может быть несколько ролей, равно как и, наоборот, одну роль могут играть несколько персон.
В данном случае, на мой взгляд, стоит придерживаться простого правила - если определен человек (например "показать результаты Алисе"), то это персона, если человек не определен и могут быть варианты - это роль ("показать результаты коллеге"). Понятное дело, что тогда задача может уточнятся (т.е. требовать исправления, что плохо, ибо время и переключение контекста), но, мне кажется, это делать необязательно. Все-таки между напоминалкой и педантичным списком задач для беспрекословного исполнения должна быть разница.
Ну, на этот счет можно условится жестко. Например, атомарная/рутинная/типовая задача/проект с протяженностью не более двух месяцев - это тактика, комплекс проектов или направлений исследований - стратегия. Для упрощения можно совсем отказаться от использования терминов "тактика" и "стратегия" - толку в них мало.
Это, увы, нужно, потому что почти всегда есть неопределенность. Разумеется, она имеет свойство уменьшаться (а данные по объекту уточнятся), но надо понимать, что ХЗ - это лишь связка, маячок, а контекст будет раскрываться в других словах.
Но что применение этой сущности должно быть ограничено - согласен. Например, по времени или по допустимым действиям.
Сделать - это да, повтор "создать", хотя предполагалось, что под сделать имеется ввиду некое относительно атомарное действие вне основных контекстов, например "сделать ТО".
Передать - это трансфер между сущностями. "Передать сущность:документ сущность:персона"
Повторить - операция над операциями (мы так до функций высших порядков договоримся :)), т.е. повторение уже существующей операции.
Там не равенства, а инварианты. Я просто поставил их рядом, потому как эти операции обычно завершают некий цикл.
А вот тут позвольте не согласится.
1. дизайн играет не последнюю роль (успех Эппл, например), в деле с TODO, когда альтернатив, мягко говоря, до пояса, наиболее критичным будут аспекты именно быстрого вовлечения, непринужденной работы и последующего привыкания. Скажем так, если пользователю не понравится лук или он будет тратить на внесение заметки более 30-60 секунд - на успех можно рассчитывать, только если доплачивать за использование.
2. как мы знаем, построить идеальную модель все равно не получится (с тем же успехом можно заняться моделированием всего, но это уже экстремизм). Да, мы можем покрыть большинство наших каждодневных задач, но это все равно будет достаточно неполная картина мира. Поэтому я и уточнил, что система должна быть расширяемой и каждый мог ее адаптировать под свой типовой набор действий/сущностей.
3. в моем списке не более 6 пунктов, хоть в сущностях, хоть в операциях. Да, сущности потом требуют уточнения (например, для персоны необходимо будет выбрать из потенциально объемной адресной книги), но это можно сделать в несколько шагов.
no subject
Date: 2012-02-03 09:20 pm (UTC)На самом деле тут отношения есть, я просто не стал их акцентировать. Понятно, что у одной персоны может быть несколько ролей, равно как и, наоборот, одну роль могут играть несколько персон.
Это только усложняет модель. И в большинстве случаев совершенно лишнее.
В данном случае, на мой взгляд, стоит придерживаться простого правила - если определен человек (например "показать результаты Алисе"), то это персона, если человек не определен и могут быть варианты - это роль ("показать результаты коллеге").
Второй вариант - это не постановка задачи, а постановка вопроса. Перед выполнением надо решить, что такое "коллега", что в большинстве случаев не тривиально. (Для того задача построения путей коммуникации и существует, чтоб определить действие однозначно и убрать муки выбора)
Это, увы, нужно, потому что почти всегда есть неопределенность. Разумеется, она имеет свойство уменьшаться (а данные по объекту уточнятся), но надо понимать, что ХЗ - это лишь связка, маячок, а контекст будет раскрываться в других словах.
При обнаружении не определённых в системе элементов, надо добавлять определение в систему, а не кормить её мусором. То есть задача "выполнить некую фигню" разбивается на две "определить какую именно фигню" (процесс постановки задачи/планирования) и "эту конкретную фигню выполнить" (выполнение задачи)
Но что применение этой сущности должно быть ограничено - согласен. Например, по времени или по допустимым действиям.
Ограничение возможно только одно "Нельзя". Любые "слабые" ограничения имеют тенденцию размываться.
1. дизайн играет не последнюю роль (успех Эппл, например)
Эппл тем и отличается, что использует для создания интерфейсов не программистские модели, а те, что в голове у пользователя. Начиная от рабочего стола и мусорной корзины.
как мы знаем, построить идеальную модель все равно не получится
Строимая модель - это не конечная версия, а зародыш. Что вырастет - зависит от полевых испытаний.
И классы должны быть легко определимыми, а не абстрактными базовыми.