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