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

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

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

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

Введение

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

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

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

  • Заказчики:

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

  • Коллеги:

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

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

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

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

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

  • Внешние ресурсы:
    • Личный блог + лента новостей http://www.uml2.ru/
    • Журнал по аналитике http://www.ritba.ru/.
    • Корпоративная 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-систему, где обмениваться проектным опытом с коллегами.

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