Яндекс.Метрика

Песочница

Как написать статью, используя UX и GTD

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

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

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

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

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

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

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

  6. ^Z
Как-то примерно так, теперь

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


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

Откуда тут взялся UX? Сработал один из принципов дизайна “фокус на конкретной цели пользователя”. В качестве отправной точки был “инструмент” — довольно абстрактный подход GTD требующий некоторого опыта для эффективного применения. Поставив цель сделать статью, и задав таким образом определенный контекст, абстрактный совет оброс конкретикой и стал намного больше напоминать руководство к действию. Кроме того, пришло понимание что основная цель не написать статью, а именно опубликовать ее. Это позволило лучше расставить приоритеты.
  • Промежуточная цель #1: сформулировать основные мысли и написать законченный текст. Стараемся достичь цели в кратчайший срок, для чего ограничиваем, а при необходимости урезаем объем статьи.
  • Промежуточная цель #2: добиться хорошего качества. Эта цель вспомогательная — она не влияет на то получите вы результат или нет, зато она определяет насколько вам самим понравится ваша статья. Фокусируемся на ней когда первая цель уже достигнута и тратим на нее оставшееся время и энтузиазм.
  • Конечная цель: опубликовать статью или провести презентацию.
Также здесь хорошо просматривается влияние принципов гибкой (agile) разработки: получившийся рецепт “поддерживает” итеративную работу над статьей, ставит приоритет на сроки получения конечного результата даже в ущерб объему/функциональности и помогает принять решение что включить в “текущий релиз”, а что отложить на вторую версию/часть.

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

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