«Зачем я буду писать статью или, тем более, статьи? Мне и так хватает «писанины». Для кого их писать? Куда писать? Будут ли их читать? Сколько времени у меня это займет? Справлюсь ли я?..»
Меня тоже раньше мучали эти вопросы. И некоторые мучают до сих пор. А с некоторыми, я считаю, я успешно справился. И решил написать статью о том, как это можете сделать и вы.
Введение
Начало статьи содержит общую информацию о написании статей по бизнес-анализу. Читайте только тезисы, идущие сразу после подзаголовков, если ограничены во времени. Вторая часть содержит информацию о ресурсе, который поможет вам избежать типовых ошибок писателей. Третья часть содержит описание полезности корпоративного ресурса компании, на котором можно публиковать статьи о реализованных проектах.
Для кого и зачем писать?
Условно предлагаю выделить 2 целевых группы читателей:
- Заказчики:
Цель написания статей: реклама, увеличение продаж и поиск клиентов.
- Коллеги:
Цель написания статей: поделиться опытом или заявить о себе.
Так вот статьи стоит писать с учетом потребностей аудитории. В связи с наличием этих двух целевых групп читаталей, статьи также можно разбить на два типа:
- Первый тип статей предназначен для формирования заинтересованности (потенциального) заказчика и описания решения проблем. Это скорее популярные статьи, чем профессиональные. Заказчик, увидев в статье описание решения своей проблемы, должен захотеть обратиться к Вам за помощью.
- Второй тип уже рассчитан на профессиональных аналитиков. Данный тип читателей ориентирован на получение новой информации с целью улучшения своих навыков и процессов в своей деятельности. Это обеспечиваться за счет ознакомления с новыми инструментами, практиками, методологиями и т.д.
Где публиковать свои статьи?
Давайте условно разделим ресурсы, на которых вы можете публиковать написанные статьи, на внешние и внутренние:
- Внешние ресурсы:
- Личный блог + лента новостей http://www.uml2.ru
- http://analyst.by/
- Журнал по аналитике http://www.ritba.ru/.
- Внутренние ресурсы:
- Корпоративная wiki (база знаний компании).
- Проектные wiki и базы знаний по доменам, проектам или департаментам.
Внешние ресурсы ориентированы на большее число читателей. Из ограничений: конфиденциальность проектов, и поэтому не каждую статью вы можете опубликовать на таком ресурсе. Небольшие открытия советую писать в блоге, а более популярные и масштабные на analyst.by.
Примером такого открытия может быть опыт использования кратких обозначений при протоколировании совещания или найденные ресурсы для тренировки к сдаче CBAP.
Внутренние ресурсы, как правило, полноценно используются крупными компаниями. Есть проектные wiki и базы знаний, в которых вы можете описывать свои полезные открытия, инструменты и методы.
Более масштабный характер будут носить статьи на ресурсе, который доступен всем сотрудникам компании, а не только коллегам по проекту или департаменту. Такой ресурс обычно содержит статьи без оглядки на конфиденциальность, а также ссылки на любые внутренние и внешние ресурсы, решения, инструменты и команду.
О чем писать?
- Про наработанные практики и лайфхаки.
- Про методологии\подходы\нотации и т.п. о чем уже написано в книгах (плюсы и минусы).
- Про инструменты.
- Про книги, конференции, встречи и ресурсы по бизнес-анализу (обзор).
- Перевод англоязычных статей.
- Интервью.
- Про навыки, про место аналитика и анализ в целом (бизнес\системная), про рынок и т.п.
- Про предметную область.
- Про реализованные проекты.
Как писать?
Лично я, когда пишу, придерживаюсь определенного плана. Именно им я бы и хотел с вами поделиться:
- Определить цель статьи – почему вашу статью будет интересно читать?
- Выбрать аудиторию читателей. Это влияет на выбор ресурса для публикации статьи.
- Проработать структуру. На выходе у вас должно получится что-то похожее на оглавление книги с краткими тезисами.
- Поискать источники информации для статьи.
- Собственно написать саму статью.
- Оформить статью: рисунки, подзаголовки, выделение тезисов.
- Написать выводы и придумать финальную версию заголовка. Важно, чтобы заголовок заинтересовывал и соответствовал смыслу статьи. Не рекомендую использовать слишком кричащие заголовки, потому что они воспринимаются читателями как «дешевая» реклама.
- Перечитать и убрать лишнее. «Семь раз отмерь, один раз отрежь» (нар. мудрость). Повторить через несколько дней.
- Отдать на ревью эксперту. Опциональный пункт: если есть эксперт, то попросите его прочитать вашу статью и дать рецензию. Это будет полезно и вам, и вашей статье.
Советы от писателей
О чем писать знаете только вы сами. А вот по слогу статьи я рекомендую ресурс: https://glvrd.ru/.
Пример анализа написанного текста смотрите на рисунке ниже.
Ресурс автоматически оценивает текст и выделяет те фразы, которые стоит переформулировать. Механизм «умный» и дорабатывается по мере появления новых методик контроля. Справа вы можете увидеть описание причины и ссылку на статью, в которой рассказывается почему нельзя так писать.
Вы можете подписаться на бесплатную рассылку от Главреда и получать 1 раз в неделю по письму с описанием типичных ошибок писателей. Или вы можете читать статьи прямо на сайте.
Корпоративные базы знаний о проектах
На стадии завершения проекта есть полезная составляющая – это ретроспектива проекта. Ретроспектива позволяет понять, насколько правильно реализовывался проект и какие выработаны «best practices», сформировать перечень ошибок и «выстреливших» рисков, которые требуется учитывать и избегать в будущем.
Можно выбрать для описания проекта и процесса его реализации отдельные документы (описание проекта, уроки опыта по PMBOK и др.) или оформить информацию о реализации проекта в виде статей, которые можно разместить в корпоративной wiki-системе. Wiki-система выбрана мною из-за простоты и удобства использования.
Корпоративная wiki, содержащая статьи о завершенных проектах, решает следующие задачи:
- Накопление и фиксация описания технологических решений.
- Описание способов решения проблем, возникших на проектах.
- Фиксация ретроспектив проектов.
- Поддержка информированности всех сотрудников о выполняемых проектах в компании независимо от домена и специализации. При таком подходе не требуется отвлекать коллег от работы, чтобы узнать подробности реализованного проекта, чтобы повторно использовать решения.
- Описание всех стадий реализации конкретных проектов и взгляд команды на проект (формирование картины проекта). Это позволяет начинающим сотрудникам увидеть на примере: стадии проекта, способы управления проектом, способы коммуникаций с заказчиком, понять какие типы документов требуются на конкретном проекте и от чего это зависит.
- Сохранение информации не в головах сотрудников, а на надежном общедоступном ресурсе.
Расскажу про наш корпоративный опыт
Корпоративная wiki-система у нас развернута на ресурсе сообщества аналитиков (платформа MS SharePoint 2013). Любой аналитик добровольно (не принудительно) пишет статью в сообществе о проекте. Статья пишется в свободной форме и удобным языком для автора, чтобы не вызывать дискомфорт и отторжение от написания подобных статей. Статьи содержат описание проблем, с которыми сталкивался аналитик, и интересные технологические решения. Также статьи содержат краткое описание инфраструктуры проекта, чтобы даже через 5 лет быстро можно было найти, где хранятся требования и документы, исходники системы и учетные данные для демонстрационных стендов. Т.е. статья содержит ту полезную информацию о проекте, которую можно узнать у команды проекта при личном общении.
Пример структуры проектной статьи ниже:
- Заказчик
Гос. заказчик или коммерческий, численность пользователей системы.
- Платформа и технологии
- Описание решения
Описание разработанной системы со скриншотами, включая подробности реализации и обоснование принятых технологических решений.
- Описание деятельности и инструментов аналитика
Описание задач, которые стояли перед аналитиком на каждом этапе проекта, и их решения. Также рекомендую указывать, что нового вы применили на проекте, и что получили в результате. Обязательно указывайте инструменты, которые вы использовали, сопровождая ссылками на дистрибутивы, статьи и видео, в которых описан опыт практического применения и перечень предоставляемых инструментом функций.
- Виды документов
Указание нотаций\языков моделирования, которые использовались при описании требований в документации, перечень видов документов, стандартов, шаблонов и ссылок на написанную документацию.
- Ретроспектива (выводы).
Указывайте ошибки, которые совершены, и лайфхаки, которые вам помогли в работе.
- Аналитики проекта
Послесловие
Надеюсь, что моя статья побудит кого-то из вас завести блог, написать статью на ресурсе analyst.by или сформировать корпоративную/проектную wiki-систему, где обмениваться проектным опытом с коллегами.
Я буду рад узнать про ваш опыт решения тех же задач, которые я решаю с помощью публикаций на внутренних и внешних ресурсах. Мне интересно узнать про ваш опыт публикаций. Есть ли у вас корпоративные базы знаний, и если да, то для каких целей вы их используете? Если вы ещё не пишете статьи на внешних ресурсах, то что вам мешает?
—
