Думаю, многие согласятся с тем, что основная проблема большинства личных GTD/To-Do-сервисов — это их неудобство. В погоне за максимальным функционалом, который бы устраивал всех, разработчики навешивают множество функций. Но, начиная с определенного момента, каждая новая функция приводит не к упрощению работы, а к усложнению, так как потери времени на действия начинают превышать выгоду от использования сервисов.
Примерно год назад я перепробовал несколько сервисов, после чего остановился на Workflowy. Еще спустя три месяца я почти отказался от Workflowy и подумывал вернуться к бумажной записи. Причина была банальной: понимая, что этот сервис с точки зрения реализации ближе всего к простой бумажной записи, я не мог организовать систему таким образом, чтобы не возникала проблема усложнения. И тут я столкнулся с тем, с чем сталкивались, наверное, многие начинающие: невероятно сложно найти описание адекватного опыта использования сервисов. Именно опыта; success stories с деталями.
Проблеме отсутствия «историй опыта» и посвящен пост под хабракатом. Если получу инвайт, в следующем посте опишу опыт использования Workflowy, почему хотел уйти, и к чему сейчас пришел.
Представьте, что купили швейцарский нож и не знаете как им пользоваться. Вам с его помощью нужно периодически открывать консервы, резать хлеб, открывать бутылки с ситро и отбиваться от диких ежей. Предположим, что задачи не такие линейные, возможны различные варианты по своему удобству, нельзя их решить простым перебором, а также не существует единственно верного решения для каждой из задач. Вот такая аналогия с новичком, приступающим к освоению GTD и задающимся основным вопросом: «Как именно с помощью этого чуда-инструмента решить мои задачи и самоорганизоваться?»
Казалось бы, помощь повсюду: и разработчики, и пользователи готовы ее оказать. Досадно, что в большинстве случаев их усилия не направлены на новичков.
О чем обычно пишет разработчик ножей:
О чем обычно пишут пользователи:
Решает ли это вопросы новичка? Не решает. Даже, если он будет знать, как открывается нож, он еще не поймет как резать хлеб. А пока поймет, его несколько раз покусают дикие ежи. Гораздо более информативными будут 5 историй пользователей, описывающих их подходы к резанию хлеба. Пусть 3 из 5 историй будут кривыми, четвертая будет про разделочные доски, а пятый способ не понравится самому пользователю. Ознакомление с этим опытом в любом случае сокращает временные затраты на освоение. А разработчики получают уникальный инструмент мониторинга, как используются придуманные ими функции.
Я ни в коем случае не против хэлпа, который сейчас создают пользователи и разработчики. Наоборот, он в большинстве своем полезен; но, к сожалению, его зачастую просто недостаточно, чтобы освоиться в GTD.
Еще один для меня важный тезис. Я верю, что подобные описания опыта в сети есть. Но вместе с тем они тонут в выдаче первых страниц поисковиков, заполненных «обычными» статьями разработчиков и пользователей. Наверное, нет лучшего решения, чем централизованно собирать подобные истории непосредственно на сайте разработчика.
P.S. В тексте GTD используется как обозначение класса программ. Это не совсем корректно, но, по моему мнению, соответствует распространенной практике.
P.P.S. Я всегда ратую за то, чтобы не разжевывать, а давать, как говорил Жванецкий, экстракт. Кому нужно, тот придет домой и разбавит (сам поищет дополнительную информацию). В посте речь не о том, что необходимо писать подробные инструкции. Наоборот, нормально человеку достаточно указать только направление и ограничиться основными принципами.
Примерно год назад я перепробовал несколько сервисов, после чего остановился на Workflowy. Еще спустя три месяца я почти отказался от Workflowy и подумывал вернуться к бумажной записи. Причина была банальной: понимая, что этот сервис с точки зрения реализации ближе всего к простой бумажной записи, я не мог организовать систему таким образом, чтобы не возникала проблема усложнения. И тут я столкнулся с тем, с чем сталкивались, наверное, многие начинающие: невероятно сложно найти описание адекватного опыта использования сервисов. Именно опыта; success stories с деталями.
Проблеме отсутствия «историй опыта» и посвящен пост под хабракатом. Если получу инвайт, в следующем посте опишу опыт использования Workflowy, почему хотел уйти, и к чему сейчас пришел.
Представьте, что купили швейцарский нож и не знаете как им пользоваться. Вам с его помощью нужно периодически открывать консервы, резать хлеб, открывать бутылки с ситро и отбиваться от диких ежей. Предположим, что задачи не такие линейные, возможны различные варианты по своему удобству, нельзя их решить простым перебором, а также не существует единственно верного решения для каждой из задач. Вот такая аналогия с новичком, приступающим к освоению GTD и задающимся основным вопросом: «Как именно с помощью этого чуда-инструмента решить мои задачи и самоорганизоваться?»
Казалось бы, помощь повсюду: и разработчики, и пользователи готовы ее оказать. Досадно, что в большинстве случаев их усилия не направлены на новичков.
О чем обычно пишет разработчик ножей:
- «Ура! Мы выпускаем новую модель ножа. Он в два раза лучше прежней модели, а также мы устранили баг с открытием второго по длине лезвия.»
- «Мы добавили в корпус вилку. Как ее достать смотрите в видео.»
О чем обычно пишут пользователи:
- «Есть семь разных ножей, вот их описание и скриншоты». Чуть лучше: «Я попробовал семь ножей. У пятого ножа корпус синий, а шестой не открывается в дождливую погоду». Еще лучше: «Второй нож отлично себя показал при открытии ситро. Мне это важнее всего, поэтому я остановился на нем.»
- «С тех пор, как я купил этот нож, я два раза продвинулся на работе. Я люблю вас, разработчики!»
- «Нож Первого ножевого завода прекрасно интегрируется в рюкзак от Первого рюкзачного завода»
Решает ли это вопросы новичка? Не решает. Даже, если он будет знать, как открывается нож, он еще не поймет как резать хлеб. А пока поймет, его несколько раз покусают дикие ежи. Гораздо более информативными будут 5 историй пользователей, описывающих их подходы к резанию хлеба. Пусть 3 из 5 историй будут кривыми, четвертая будет про разделочные доски, а пятый способ не понравится самому пользователю. Ознакомление с этим опытом в любом случае сокращает временные затраты на освоение. А разработчики получают уникальный инструмент мониторинга, как используются придуманные ими функции.
Я ни в коем случае не против хэлпа, который сейчас создают пользователи и разработчики. Наоборот, он в большинстве своем полезен; но, к сожалению, его зачастую просто недостаточно, чтобы освоиться в GTD.
Еще один для меня важный тезис. Я верю, что подобные описания опыта в сети есть. Но вместе с тем они тонут в выдаче первых страниц поисковиков, заполненных «обычными» статьями разработчиков и пользователей. Наверное, нет лучшего решения, чем централизованно собирать подобные истории непосредственно на сайте разработчика.
P.S. В тексте GTD используется как обозначение класса программ. Это не совсем корректно, но, по моему мнению, соответствует распространенной практике.
P.P.S. Я всегда ратую за то, чтобы не разжевывать, а давать, как говорил Жванецкий, экстракт. Кому нужно, тот придет домой и разбавит (сам поищет дополнительную информацию). В посте речь не о том, что необходимо писать подробные инструкции. Наоборот, нормально человеку достаточно указать только направление и ограничиться основными принципами.
