GTD / [Из песочницы] Как написать статью, используя UX и GTD

Сразу оговорюсь: это просто статья о том как написать статью. С какого боку тут всякие сокращения будет понятно чуть позднее.

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

Бывает это так: вроде и в теме разобрался, и с формулировкой мыслей проблем нет, и самих мыслей предостаточно. Набрасываешь примерный план, делаешь список тем которые хочется обсудить, копаешься в интернете, пишешь десяток абзацев текста. В процессе созревают новые идеи — добавляешь их в план. Назавтра пишешь еще несколько абзацев, расширяешь и уточняешь план и понимаешь что это начинает напоминать небольшую книгу. 2-3 таких итерации и энтузиазм несколько утихает, оставляя после себя кучу найденных ссылок, дюжину-другую абзацев покрывающих треть от планируемых тем и ощущение незаконченности работы.

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

В качестве лирического отступления скажу, что в последнее время я особенно интересовался дизайном взаимодействия с пользователем “UX ^[1]” и доведением дел до завершения “GTD ^[2]”. И то и другое — крутой замес из принципов, идей, методологии и своей философии.

Вот что получилось после переваривания этой проблемы с точек зрения UX и GTD.

Рецепт гибкого написания статей

1. Планирование: общие планы не работают.
   
   • Разбейте будущую статью на конкретные пункты и отдельные мысли с прицелом в 1-3 параграфа на каждый.
   • Отранжируйте пункты, выберите 3-7 наиболее важных и интересных в список “основные”. Это будет “ядро” статьи которое вы напишете сегодня.
   • Остальные занесите в список “на будущее”.
2. Написание: начните с простого.
   
   • Кратко и доступно сформулируйте мысли из “основного” списка.
   • Не гонитесь за совершенством. Сначала сделайте ядро статьи. Отвлекаться на доведение формулировок до идеала можно будет когда вся статья перед глазами.
   • Если мысль разрастается, например требует пояснения, — посмотрите можно ли отложить пояснение на потом или без него статья потеряет смысл. Во втором случае никуда не денешься — расширяйте тему, но переместите что-нибудь из конца “основного” в список “на будущее”.
   • Не давайте статье распухать. Если тема тянет все новые идеи, мысли и пояснения — выделяйте ее в отдельную статью.
3. Что дальше?
   
   • А собственно все. Темы из основного списка раскрыты, ядро готово.
     Даже если к этому моменту запал прошел или вас отвлекли другие дела, то статья уже есть — вы старались не зря. Но если у вас как и у большинства хороших программистов периодически просыпается зуд к оптимизации, то можно и пополировать.
4. Улучшение
   
   • Посмотрите на последовательность предложений и порядок параграфов. Легко ли прослеживается основная мысль статьи? Нет ли необходимости пояснить отдельные моменты?
   • Отдавайте предпочтение простому языку. Если вы использовали слово “инфинитезимальный” (Стоп! Дочитайте абзац до конца), то вашему читателю может понадобиться отвлечься чтобы найти его значение. Отвлечься с риском затеряться в интернете и забыть про вашу статью. (Все, если хотите, можете гуглить “инфинитезимальный”, но там нет ничего интересного, честно).
   • Избегайте сложных предложений и больших параграфов. Разбейте или упростите длинные предложения.
   • Проверьте стиль изложения
     
     • на ровность: резкий переход от доверительного стиля к академически сухому может легко сбить читателя с мысли.
     • на насыщенность: много воды и посторонних рассуждений плохо сочетаются с бешеным ритмом наших дней.
     • на живость: образность и юмор не повредят даже техническому тексту. Главное — не пересолить.
   • Протестируйте статью на знакомых. Если кто-то уснул в процессе чтения — это тревожный знак.
   • Эти рекомендации, конечно, далеко не полный рецепт успеха, но они позволят держать статью в хорошей форме. Если вам самим статья нравится ну или вы заметили что час запланированный на полировку уже давно прошел и за окном светает — самое время публиковать. Ваша настоящая цель не написать статью, а поделиться ею с читателями.
5. Продолжение
   
   • Что делать если материала и энтузиазма еще много? Посмотрите на реакцию читателей, выделите наиболее важные и интересные мысли из списка “на будущее” в “основной” и переходите к следующей итерации — пишите вторую часть.
   • Помните, что планы и идеи могут поменяться вместе с изменением ваших интересов и оценкой статьи аудиторией.

6. ^Z

Как-то примерно так, теперь

Вернемся к GTD и UX

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

Откуда тут взялся UX? Сработал один из принципов дизайна “фокус на конкретной цели пользователя”. В качестве отправной точки был “инструмент” — довольно абстрактный подход GTD требующий некоторого опыта для эффективного применения. Поставив цель сделать статью, и задав таким образом определенный контекст, абстрактный совет оброс конкретикой и стал намного больше напоминать руководство к действию. Кроме того, пришло понимание что основная цель не написать статью, а именно опубликовать ее. Это позволило лучше расставить приоритеты.

• Промежуточная цель #1: сформулировать основные мысли и написать законченный текст. Стараемся достичь цели в кратчайший срок, для чего ограничиваем, а при необходимости урезаем объем статьи.
• Промежуточная цель #2: добиться хорошего качества. Эта цель вспомогательная — она не влияет на то получите вы результат или нет, зато она определяет насколько вам самим понравится ваша статья. Фокусируемся на ней когда первая цель уже достигнута и тратим на нее оставшееся время и энтузиазм.
• Конечная цель: опубликовать статью или провести презентацию.

Также здесь хорошо просматривается влияние принципов гибкой (agile) разработки: получившийся рецепт “поддерживает” итеративную работу над статьей, ставит приоритет на сроки получения конечного результата даже в ущерб объему/функциональности и помогает принять решение что включить в “текущий релиз”, а что отложить на вторую версию/часть.

Собственно, помимо желания поделиться работающим для меня рецептом написания статей и презентаций, была еще и цель #2 — показать, что технологии организации работы над программами срабатывают и в применении к “несофтверным” вещам.

Вам судить, насколько это удалось.

Автор: DeeKey