analyst.by

Белорусское сообщество бизнес и системных аналитиков

Как бизнес-аналитику написать статью (или несколько)

«Зачем я буду писать статью или, тем более, статьи? Мне и так хватает «писанины». Для кого их писать? Куда писать? Будут ли их читать? Сколько времени у меня это займет? Справлюсь ли я?..»

Меня тоже раньше мучали эти вопросы. И некоторые мучают до сих пор. А с некоторыми, я считаю, я успешно справился. И решил написать статью о том, как это можете сделать и вы.

Введение

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

 

Для кого и зачем писать?

Условно предлагаю выделить 2 целевых группы читателей:

  • Заказчики:

Цель написания статей: реклама, увеличение продаж и поиск клиентов.

  • Коллеги:

Цель написания статей: поделиться опытом или заявить о себе.

Так вот статьи стоит писать с учетом потребностей аудитории. В связи с наличием этих двух целевых групп читаталей, статьи также можно разбить на два типа:

  1. Первый тип статей предназначен для формирования заинтересованности (потенциального) заказчика и описания решения проблем. Это скорее популярные статьи, чем профессиональные. Заказчик, увидев в статье описание решения своей проблемы, должен захотеть обратиться к Вам за помощью.
  2. Второй тип уже рассчитан на профессиональных аналитиков. Данный тип читателей ориентирован на получение новой информации с целью улучшения своих навыков и процессов в своей деятельности. Это обеспечиваться за счет ознакомления с новыми инструментами, практиками, методологиями и т.д.

 

Где публиковать свои статьи?

Давайте условно разделим ресурсы, на которых вы можете публиковать написанные статьи, на внешние и внутренние:

  • Внешние ресурсы:
  • Внутренние ресурсы:
    • Корпоративная wiki (база знаний компании).
    • Проектные wiki и базы знаний по доменам, проектам или департаментам.

Внешние ресурсы ориентированы на большее число читателей. Из ограничений: конфиденциальность проектов, и поэтому не каждую статью вы можете опубликовать на таком ресурсе. Небольшие открытия советую писать в блоге, а более популярные и масштабные на analyst.by.

Примером такого открытия может быть опыт использования кратких обозначений при протоколировании совещания или найденные ресурсы для тренировки к сдаче CBAP.

Внутренние ресурсы, как правило, полноценно используются крупными компаниями. Есть проектные wiki и базы знаний, в которых вы можете описывать свои полезные открытия, инструменты и методы.

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

 

О чем писать?

  • Про наработанные практики и лайфхаки.
  • Про методологии\подходы\нотации и т.п. о чем уже написано в книгах (плюсы и минусы).
  • Про инструменты.
  • Про книги, конференции, встречи и ресурсы по бизнес-анализу (обзор).
  • Перевод англоязычных статей.
  • Интервью.
  • Про навыки, про место аналитика и анализ в целом (бизнес\системная), про рынок и т.п.
  • Про предметную область.
  • Про реализованные проекты.

 

Как писать?

Лично я, когда пишу, придерживаюсь определенного плана. Именно им я бы и хотел с вами поделиться:

  1. Определить цель статьи – почему вашу статью будет интересно читать?
  2. Выбрать аудиторию читателей. Это влияет на выбор ресурса для публикации статьи.
  3. Проработать структуру. На выходе у вас должно получится что-то похожее на оглавление книги с краткими тезисами.
  4. Поискать источники информации для статьи.
  5. Собственно написать саму статью.
  6. Оформить статью: рисунки, подзаголовки, выделение тезисов.
  7. Написать выводы и придумать финальную версию заголовка. Важно, чтобы заголовок заинтересовывал и соответствовал смыслу статьи. Не рекомендую использовать слишком кричащие заголовки, потому что они воспринимаются читателями как «дешевая» реклама.
  8. Перечитать и убрать лишнее. «Семь раз отмерь, один раз отрежь» (нар. мудрость). Повторить через несколько дней.
  9. Отдать на ревью эксперту. Опциональный пункт: если есть эксперт, то попросите его прочитать вашу статью и дать рецензию. Это будет полезно и вам, и вашей статье.

 

Советы от писателей

О чем писать знаете только вы сами. А вот по слогу статьи я рекомендую ресурс: https://glvrd.ru/.

Пример анализа написанного текста смотрите на рисунке ниже.

 

Ресурс автоматически оценивает текст и выделяет те фразы, которые стоит переформулировать. Механизм «умный» и дорабатывается по мере появления новых методик контроля. Справа вы можете увидеть описание причины и ссылку на статью, в которой рассказывается почему нельзя так писать.

Вы можете подписаться на бесплатную рассылку от Главреда и получать 1 раз в неделю по письму с описанием типичных ошибок писателей. Или вы можете читать статьи прямо на сайте.

 

Корпоративные базы знаний о проектах

На стадии завершения проекта есть полезная составляющая – это ретроспектива проекта. Ретроспектива позволяет понять, насколько правильно реализовывался проект и какие выработаны «best practices», сформировать перечень ошибок и «выстреливших» рисков, которые требуется учитывать и избегать в будущем.

Можно выбрать для описания проекта и процесса его реализации отдельные документы (описание проекта, уроки опыта по PMBOK и др.) или оформить информацию о реализации проекта в виде статей, которые можно разместить в корпоративной wiki-системе. Wiki-система выбрана мною из-за простоты и удобства использования.

Корпоративная wiki, содержащая статьи о завершенных проектах, решает следующие задачи:

  • Накопление и фиксация описания технологических решений.
  • Описание способов решения проблем, возникших на проектах.
  • Фиксация ретроспектив проектов.
  • Поддержка информированности всех сотрудников о выполняемых проектах в компании независимо от домена и специализации. При таком подходе не требуется отвлекать коллег от работы, чтобы узнать подробности реализованного проекта, чтобы повторно использовать решения.
  • Описание всех стадий реализации конкретных проектов и взгляд команды на проект (формирование картины проекта). Это позволяет начинающим сотрудникам увидеть на примере: стадии проекта, способы управления проектом, способы коммуникаций с заказчиком, понять какие типы документов требуются на конкретном проекте и от чего это зависит.
  • Сохранение информации не в головах сотрудников, а на надежном общедоступном ресурсе.

 

Расскажу про наш корпоративный опыт

Корпоративная wiki-система у нас развернута на ресурсе сообщества аналитиков (платформа MS SharePoint 2013). Любой аналитик добровольно (не принудительно) пишет статью в сообществе о проекте. Статья пишется в свободной форме и удобным языком для автора, чтобы не вызывать дискомфорт и отторжение от написания подобных статей. Статьи содержат описание проблем, с которыми сталкивался аналитик, и интересные технологические решения. Также статьи содержат краткое описание инфраструктуры проекта, чтобы даже через 5 лет быстро можно было найти, где хранятся требования и документы, исходники системы и учетные данные для демонстрационных стендов. Т.е. статья содержит ту полезную информацию о проекте, которую можно узнать у команды проекта при личном общении.

Пример структуры проектной статьи ниже:

  • Заказчик

Гос. заказчик или коммерческий, численность пользователей системы.

  • Платформа и технологии
  • Описание решения

Описание разработанной системы со скриншотами, включая подробности реализации и обоснование принятых технологических решений.

  • Описание деятельности и инструментов аналитика

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

  • Виды документов

Указание нотаций\языков моделирования, которые использовались при описании требований в документации, перечень видов документов, стандартов, шаблонов и ссылок на написанную документацию.

  • Ретроспектива (выводы).

Указывайте ошибки, которые совершены, и лайфхаки, которые вам помогли в работе.

  • Аналитики проекта

 

Послесловие

Надеюсь, что моя статья побудит кого-то из вас завести блог, написать статью на ресурсе analyst.by или сформировать корпоративную/проектную wiki-систему, где обмениваться проектным опытом с коллегами.

Я буду рад узнать про ваш опыт решения тех же задач, которые я решаю с помощью публикаций на внутренних и внешних ресурсах. Мне интересно узнать про ваш опыт публикаций. Есть ли у вас корпоративные базы знаний, и если да, то для каких целей вы их используете? Если вы ещё не пишете статьи на внешних ресурсах, то что вам мешает?

 

Олег Денисов

 

 


01 Ноября, 2016


Добавить комментарий
Также Вы можете войти используя: Facebook Google