Бизнес план и системный анализ
Приветствую! Меня зовут Сергей, и я — бизнес/системный аналитик. В IT отрасли работаю около 8 лет, начиная с сопровождения, перетекающего в тестирование, и продолжая аналитикой: как бизнес, так и системной. Отдельно бизнес и отдельно системным аналитиком я ещё не работал.
В ходе своей профессиональной деятельности в целом, включая практику и личные собеседования, и в частности собеседований с потенциальными кандидатами я постепенно пришел к пониманию того, каких навыков рынок ждёт от Аналитика. Свежих статей на эту тематику Хабр не видел давно, поэтому я решил подготовить материал самостоятельно.
Для кого, на мой взгляд, будет полезна статья:
- Начинающим бизнес / системным аналитикам;
- Аналитикам, желающим и дальше прокачивать свои проф. навыки;
- Возможно, менеджерам по подбору персонала.
Сразу скажу, что пункты ниже — это моё субъективное видение специализации аналитика, сформировавшееся в процессе практики. Если в вашей компании запущен полноценный scrum с product owner, сидящем в метре от вас, с выделенными для команды дизайнером и архитектором, что-то из перечисленного может оказаться невостребованным.
Тем не менее, все эти навыки как минимум не окажутся лишними и сделают из аналитика еще более компетентного в своих вопросах специалиста. Разумеется, надо понимать, что я перечислил не все умения и способности аналитика (те же нотации, бизнес-скиллы, sql и так далее).
Бизнес аналитика
- Устраняйте двусмысленные требования на самых ранних этапах
Разговаривая с бизнес-заказчиком, нужно отдавать себя отчет в том, что его язык может существенно отличаться от вашего. Бизнес-требование может быть озвучено таким образом, что у нескольких участников процесса согласования требований возникает различное понимание, что это требование означает. Порождается двусмысленность, которая очень дорого обходится команде на поздних этапах разработки.
Проблема оказывается наиболее острой при наличии нескольких бизнес-заказчиков, каждый из которых выдвигает свои требования. Например, при интеграции двух систем, по каждой из которых есть свой представитель от бизнеса.
Кейс из практики: месяц разработки был потрачен на функционал переноса списка активностей из объекта №1 в объект №2. На этапе приемочного тестирования обнаружилось, что заказчик ожидал совершенно иной функционал — копирование, а не перенос активностей. В процессе переделывания функционала и детализации двусмысленности IT-команда, во-первых, договорилась с заказчиком о MVP, а, во-вторых, о необходимости работы с корнем бизнес-проблемы. Было выдвинуто предположение, что сам функционал копирования требуется только лишь по причине недостаточно качественно реализованного функционала подгрузки шаблонов активностей.
- Не бойтесь уточнять у заказчика о целях требования
По работе встречался с кейсами, когда постановка на разработку была описана без фиксации бизнес-цели: в чем конкретно эта доработка поможет бизнесу? Какую боль эта доработка снимет с бизнеса?
Зачастую такие доработки без цели приводили к неприятным последствиям уже на этапе тестирования, когда и разработчик, и тестировщик не понимали, зачем мы спроектировали этот функционал. Хуже того, разработчик и тестировщик не получали ответы от аналитика, а если и получали, что чаще всего придуманные самим аналитиком: цели, который аналитик сформировал самостоятельно.
Записывайте цели вместе с заказчиком, чтобы абсолютно все участники процесса в любой момент времени понимали, зачем они выполняют свою работу.
- Требуйте у заказчика своего присутствия на бизнес-встречах
На практике сталкивался с разными заказчиками, некоторые из которых не сразу были готовы приглашать аналитика на свои оффлайн-встречи. С этим аналитик также должен будет поработать: договориться и показать результат от слаженной совместной работы.
Во время очной встречи руководителя подразделения с подчиненным, где мы — аналитик и UX-дизайнер — сидели «в фоне», выявился целый ряд требований, который не проявлялся в течение целого года работы команды. Мы обращали внимание на все детали: ручные записи руководителя и сотрудника, на стикеры, на пометки в windows-блокноте, на действия внутри системы. По итогу такой встречи бэклог был существенно дополнен, а мы приступили к глубокой переделке реализованного в системе функционала.
- Старайтесь достигать соглашения и не формировать отписки
Многие аналитики, и я в том числе, в процессе формирования требований, сталкиваясь с жёстким дедлайном, пользовались следующим приёмом: писали участникам процесса письмо со сроком, до которого на письмо нужно ответить и согласовать требования / дать комментарии. В противном случае требования будут автоматически признаны согласованными.
Как показала практика, ничего хорошего в таком подходе нет. Понятно, что, работая на стороне вендора и имея на руках договор, приходится прибегать к такого рода приёмам, но всё же старайтесь избегать молчаливого согласия, попытайтесь понять, почему участники не хотят давать вам ответ именно сейчас, и решите проблему как можно быстрее.
Лучше письменно задокументируйте тот факт, что ответ не был получен от таких-то лиц и вы видите в этом следующие риски для проекта. Однако процесс работы не может стоять на месте, поэтому вы вынуждены продолжить свою аналитическую деятельность, при этом ранее определенные риски должны быть понятны всем участникам процесса.
В процессе проработки интеграции двух систем мы столкнулись с формированием требований со стороны директора, покрывающих действия пользователей в двух системах, но отсутствием явного согласования этих самых требований от непосредственного руководителя подразделения, сотрудники которого являлись пользователями системы.
Как выяснилось позже, руководитель подразделения совершенно не понимал, к чему все эти доработки и каким образом они помогут оптимизировать процессы в его зоне ответственности.
Часто участники процесса согласования просто боятся поставить свою подпись, так как не до конца понимают те или иные участки обновленного бизнес-процесса. Ваша задача как бизнес-аналитика — устранить это непонимание.
- Ознакомьте разработчиков с предметной областью
Потратьте несколько часов, но верхнеуровнево расскажите своим разработчикам о заказчике, о текущих бизнес-процессах, о боли и планах на развитие. Как правило, хорошо замотивированные разработчики не просто отлично выполняют свою работу, понимая, для кого они пишут код, но и вносят свой ценный вклад: предлагают оптимизацию, обходные решения, охотнее задают уточняющие вопросы.
При необходимости (и отсутствия scrum) привлеките заказчика к такой встрече. Как правило, представители Бизнеса охотно соглашаются на такого рода инициативы.
- Научите заказчика отвечать на вопрос «Что?», а не формулировать требования в формате «Как»
Заказчик не должен формулировать бизнес / пользовательское требование с позиции «Как»: нам нужна кнопка на этом экране, чтобы сформировать отчёт; нам нужна ссылка на внешнюю систему в этом разделе; и так далее.
На этапе первичного анализа процесса, до непосредственно проектирования, заказчик не должен предлагать решение.
Вместо этого научите заказчика формулировать проблему, свою «боль»: нам необходимо на еженедельной основе формировать отчет, который вручную дополняется сотрудником и высылается на руководство; в процессе работы с клиентом нам требуется анализировать дополнительную информацию, а так как в CRM-системе она отсутствует, нам приходится открывать новую вкладку в браузере и выполнять вход в смежную систему.
Узнав боль заказчика, вы, как специалист, сможете предложить варианты оптимизации процесса и его автоматизации. Например, автоматически высылать сформированный отчет на почту сотрудника, избавить сотрудника от ручной работы с отчетом в принципе, автоматическую загрузку данных из смежной системы в CRM, и так далее.
Во многих случаях этот подход столкнется с реальностью: со сроками и приоритетами. Но вы, во всяком случае, честно попытались.
- Обязательно разделите пользователей на классы
Принимая требования от пользователя системы, в обязательном порядке учитывайте его роль в бизнес-процессе. В практике часто встречаются случаи, когда руководитель подразделения формирует требования для функционала, с которым будет работать обычный сотрудник.
Разделите пользователей системы на роли, а функционал, затачиваемый под одну роль, не «размазывайте» под другую роль.
Как-то раз в рамках Системы мы реализовали отображение списка сделок с клиентами.
Предполагалось, что со списком будут работать как руководители, так и обыкновенные сотрудники. К сожалению, нам не удалось добиться от заказчика понимания необходимости разделить UI-ную часть доработки на два списка / экрана: один список — для руководителя с целью анализа и контроля, второй список — для сотрудника с целью осуществления операционной деятельности.
В итоге получился некий монстр, который впоследствии пришлось дорабатывать и дорабатывать.
Применяйте бэст-практики из UX: проработайте персонажей — модели пользователей. Убедите заказчика в необходимости разделять требования для каждого из персонажей.
- Активно применяйте аналитический мозговой штурм
Можно в тандеме со вторым аналитиком, можно в тандеме с UX-дизайнером. В процессе штурма примерьте две роли: один человек сначала генерирует множество идей, посильных и не очень, второй — критикует эти идеи, декомпозирует их, записывает, продумывает; затем поменяйтесь ролями и сделайте ту же работу.
Как показывает практика, такой подход позволит значительно ускорить процесс составления функциональных требований и повысить их качество. Но есть сложность в том, что оба специалиста должны быть в контексте задачи.
- Если застряли в Waterfall, не отчаивайтесь и двигайтесь в сторону Scrum
В одной из компаний буквально за год нашей команде удалось перевести процесс внедрения доработок от устоявшегося на уровне управляющих менеджеров Waterfall к некоторой разновидности Scrum. Да, назад тянули «чёткие» сроки по сильно размазанному бэклогу, которые заказчик постоянно требовал с IT-команды, при этом риторика была постепенно смягчена через двухнедельные релизы, MVP-решения и быстрый отклик на изменения.
- Ни в коем случае не демонизируйте заказчика
Да, заказчики бывают всякие. Есть и такие, которые буквально бесят. Тем не менее, бизнес-аналитик должен решать этот вопрос или самостоятельно, или с привлечением менеджера и ни в коем случае не выносить «ссору из избы» — на команду.
Команда должна быть хорошо мотивирована на работу, и роль бизнес-аналитика в процессе формирования мотивации — одна из ключевых.
- Не перебивайте
Серьезно. Когда в процессе общения с заказчиком я слышу от своего коллеги-аналитика нелепые словесные вставки, когда коллега-аналитик перебивает заказчика, не дослушивая его до конца, мне хочется отправить его на курсы по ведению переговоров или элементарной этике.
Старайтесь и слушать собеседника, и слышать его.
- Избавьтесь от слов-паразитов
Старайтесь избегать слов-паразитов и поменьше «мычать» в разговорах. Поначалу это тяжело, но, поверьте, заказчику вдвойне тяжелее слушать такого аналитика, который не может выразить свою мысль четко и ясно. Словами-паразитами может страдать разработчик, дизайнер, тестировщик, но не бизнес-аналитик, связывающий IT-команду с Бизнесом.
Рекомендуемая литература:
— Карл Вигерс «Разработка требований к программному обеспечению».
— Максим Ильяхов «Пиши, Сокращай: как Создавать Сильный текст».
Системная аналитика
- При постановке задачи на front и back старайтесь описывать sequence диаграммы
Или, по-русски, диаграммы последовательности. Диаграммы окажутся полезными даже не с точки зрения разработки, но с точки зрения верификации собственных требований. Очень часто при описании потока сообщений я выявлял «дыры» в собственном процессе. Например, неактуальный API.
Для быстрого «рисования» sequence диаграмм используйте плагин PlantUML для Confluence. Мне показалось, что быстрее набирать код, нежели ручками корректировать расположение блоков и стрелок. Но у каждого в этой части свой опыт и свои предпочтения.
- Освойте Swagger Editor
С точки зрения анализа Swagger Editor позволит вам закрывать ваши же дыры в требованиях. Где-то упустили атрибут, где-то забыли создать задачу в JIRA для доработки базы данных. Не пытайтесь зазубрить синтаксис Сваггера, а создайте шаблоны под разные типы API (справочники, фильтры и так далее), чтобы упростить себе жизнь в будущем.
- Активно используйте инструмент разработчика в целевом браузере, чтобы анализировать запросы клиента и ответы от сервера
Во-первых, в процессе первичной приемки вы сможете проверить API, который сами же описали. Иногда некоторую часть доработки оказывается быстрее проверить по исходящим запросам, нежели по UI, чтобы на раннем этапе понять корень проблемы.
Вам, как аналитику, потребуется гораздо меньше времени, чтобы проверить реализацию от разработчика: исходящие данные, входящие данные, результат в UI.
Во-вторых, вы сможете убедиться в правильной последовательности вызовов. Ведь вы сами описали её в рамках sequence диаграммы.
Этот подход позволил нашей команде выводить достаточно хитрые доработки в пром в рамках спринтов без задержек.
Рекомендуемая литература:
— Марейн Хавербеке «Выразительный JavaScript». Главы про JSON, Интернет, HTML, http / https, методы и другие.
— В. Олифер, Н. Олифер «Компьютерные сети. Принципы, технологии, протоколы». Главы про сетевые службы и сервисы, сетевые приложения, базовые технологии безопасности, аутентификацию и другие.
В дополнение
- Погрузитесь в UX
Возможно, вам даже понравится и вы захотите развиваться в сторону UX-аналитики. В любом случае, изучение соответствующей литературы и инструментов проектирования пойдет на пользу как минимум с точки зрения поиска общего языка с UX-дизайнером из вашей команды.
Зачастую те требования, которые вы, как аналитик, детализируете и распишите, будут впоследствии корректироваться со стороны дизайнера. Ведь не вы один, по сути, проектируете пользовательский опыт.
Чтобы быть на одной волне, попрактикуйтесь в UX-анализе. Например, в свободное от работы время в Sketch или Figma, время от времени показывая результат вашему дизайнеру. Такой опыт аналитики никогда не будет лишним.
Рекомендуемая литература:
— Дон Норман «Дизайн привычных вещей».
— Алан Купер «Психбольница в руках пациентов».
— Алан Купер «Интерфейс. Основы проектирования взаимодействия».
— Робин Уильямс «Дизайн. Книга для недизайнеров».
***
Спасибо за прочтение статьи! Буду благодарен, во-первых, за обратную связь. Во-вторых, за рекомендации по литературе, источникам, за бэстпрактисы, личный опыт и рекомендации.
Системный бизнес-анализ — это инструмент аудита, который позволяет выявить проблемы и запросы бизнес-проекта, а также разработать пути преодоления возникающих трудностей.
“В любой области бизнеса, если рассматривать её внимательно, существуют проблемы, которые можно решить с помощью систематизации. Вопрос только в том, хочет ли видеть их владелец. Если у него есть серьёзная цель — привести свою компанию на какой-то глобальный уровень, — то он будет искать и исправлять эти проблемы”.
Д. Тараненко, выпускник программы «Business Booster»
К бизнес-аналитикам обращаются как молодые, неопытные предприниматели, так и владельцы компаний, которые достигли качественно нового уровня развития и ощутили потребность во внедрении иной политики, инструментов, организационной системы, нежели те, что до применялись до сих пор.
Что представляет собой теория системного бизнес-анализа
Как научное направление бизнес анализ нацелен на изучение требований компании на текущем этапе развития, после определения которых становится возможным выстроить схему необходимых изменений, внедрив которые организация сможет выполнить свои стратегические цели.
Изменения могут касаться любой сферы деятельности предприятия: внутренней, внешней или кадровой политики, структурной организации, стратегии и тактики.
Практика системного бизнес-анализа включает следующие направления.
- Аудит организации. Это направление изучает потребности бизнеса, «узкие места», определяет перспективные точки роста, а затем разрабатывает механизмы решения выявленных проблем. В результате компания получает: общую, но объективную картину положения дел; инструменты для выполнения конкретных задач, которые раньше реализовывались интуитивно; план реинжиниринга, повышающий эффективность существующих или заново сформированных бизнес-процессов.
- Планирование и управление потребностями. Данное направление создаёт в компании процесс планирования запросов, определяя их приоритетность.
- Сбор требований от заинтересованных лиц с помощью различных техник: изучение документов или интерфейсов, интервьюирование, опросы, наблюдения, моделирования.
- Анализ требований подразумевает описание собранных запросов (или формулировку, если собственник затрудняется с детализацией запроса), с декомпозицией, достаточной для реализации на практике.
- Коммуникация потребностей. Этот раздел использует методики объединения заинтересованных лиц вокруг сформулированного плана: все понимают, что, зачем, как делается, кто отвечает за каждый участок или этап.
- Оценка и контроль решений. Системный подход в бизнесе немыслим без мониторинга и корректировки действий. Бизнес-аналитик постоянно взаимодействует с владельцем: консультирует, отслеживает процесс внедрения новых технологий управления, участвует в разработке технической документации и стандартов.
Функции бизнес-аналитиков
Наука бизнес-анализа затрагивает слишком широкий круг проблем, чтобы один человек мог качественно вникнуть в каждую область деятельности бизнеса, поэтому как представители многих научных отраслей бизнес-аналитики предпочитают специализироваться на одном из секторов.
Стратег
В условиях современного рынка стратегические задачи приобретают первостепенное значение. Бизнес-аналитик, занимающийся стратегией, выполняет различные функции:
- анализирует тенденции рыночной ниши;
- выполняет стратегический анализ внутренней и внешней среды, необходимый для качественного стратегического планирования;
- оценивает проекты и направления деятельности компании на предмет финансовой целесообразности;
- просчитывает стратегические альтернативы;
- предлагает инновационные методы и инструменты.
Архитектор (аналитик бизнес-процессов)
Порой чтобы устранить проблемы, выявленные бизнес-аналитиком, компании нужно провести существенные изменения. На этом этапе на помощь руководству приходит специалист, который владеет навыками модернизации (усовершенствования) бизнес-процессов. Системный подход в реорганизации бизнес-процессов позволяет обеспечить целостное видение, синхронизировать все аспекты деятельности организации, направить их на достижение разработанных стратегических целей.
Потребность в бизнес-архитекторах растёт день ото дня, поскольку всё больше собственников понимают, как много зависит от архитектурного фундамента компании и системного анализа бизнес-процессов.
Системный аналитик
Чем отличаются бизнес-аналитик и системный аналитик? Специалисты шутят, что первый имеет 80% знаний по бизнесу и 20% по технологиям, а второй — наоборот. В какой-то степени так оно и есть: бизнес-аналитик формулирует потребности бизнеса, а системный аналитик реализует удовлетворение этих потребностей с помощью IT-технологий.
Инфотехнологии важны, но дороги даже для крупных компаний, поэтому помощь специалиста в подборе действительно эффективных инструментов автоматизации бизнеса существенно экономит затраты предприятия на реорганизацию.
Цели команды аналитиков
Общей целью аналитики является максимальное упрощение работы компании и повышение её эффективности (мы знаем, что эффективность определяется не суммой заработанных денег, а соотношением вложенных усилий и уровнем полученного результата).
Эта глобальная цель достигается через решение промежуточных задач.
- Уменьшение затрат (в том числе, за счёт рационального бизнес-планирования) при соблюдении сроков закрытия проектов. Известно, что любое дополнительное время, затраченное на разработку и внедрение проекта, обходится дороже, чем оплата работ в запланированные сроки: в игру вступают дополнительные расходы, потерянные выгоды, сокращения расходов, не осуществлённые вовремя. Задача аналитика — гарантировать, что несмотря на непредвиденные обстоятельства, приоритетные задачи будут выполнены в срок.
- Составление протокола требований. Внедряемые системные бизнес-технологии призваны максимально удовлетворять потребности пользователей. Поэтому задействованный аналитик должен иметь документацию с полным описанием требований, под которые он разрабатывает проект оснащения компании новыми инструментами.
- Повышение эффективности проектов. Эффективность достигается двумя основными способами: опережение графика внедрения (по крайней мере, обеспечение отсутствия простоев) и профилактика переделок уже внедрённых звеньев. В результате предприятие получает выгоду в виде высвобождающихся ресурсов и не затрачивает человеко-часы на дополнительную работу.
Системный подход к реорганизации бизнеса
Как сделать бизнес системным? В первую очередь, следует понимать, чем системный бизнес отличается от бизнеса традиционного, «интуитивного»:
- традиционный владелец ориентируется на конечные показатели сотрудников и видов деятельности: (сколько вложено, сколько продано и т. д.), это правильный метод, но поверхностный, он не даёт ответов на многие вопросы, не выявляет ошибки, до тех пор, пока они не вырастут до размеров катастрофы; «интуитивный» бизнес допускает только точечное вмешательство, которое можно сравнить с наложением «заплаток» на слабые места;
- системный бизнес сосредоточен на правильном течении процессов, и это позволяет получать прибыль почти автоматически: при правильно выстроенном контроле любые ошибки выявляются в зародыше и притом немедленно.
Правила системного подхода к бизнес-процессам
Здоровый, развивающийся бизнес, имеющий стратегические цели, должен опираться на три основополагающих правила.
- Внедрение новшеств. Реалии современного рынка таковы, что без инноваций компания быстро потеряет свою конкурентоспособность.
- Количественная оценка внедрённых инноваций — понимание уровня инновационной активности и потенциала во многом определяет характер управленческих решений.
- Порядок в бизнес-процессах. Поскольку системный подход понимает предприятие как совокупность взаимосвязанных процессов, руководитель должен помнить, что неполадки в одном процессе могут нарушать другие виды деятельности и влиять на конечный результат.
Принципы системного подхода к бизнесу
Построение системного бизнеса во многом зависит от соблюдения экономических принципов.
- Собственник должен инициировать эффективные действия, а не реализовывать их, смешивая функции владельца и исполнительного директора.
- Создание описание эффективных действий должно сопровождаться их внедрением на постоянной основе (шаблоны, скрипты, прочие регламенты).
- Применение «рычагов» помогает получить лучшие результаты с меньшими затратами: проводить не одиночные испытания от резюме до подписания контракта, а запустить рекрутинговую автоворонку, чтобы к этапу личного интервью оставались только самые перспективные кандидаты; не приглашать клиентов в офис для обстоятельной презентации, а устроить конференцию и т. п.
- Соблюдение порядка действий гарантирует порядок: выполнена фундаментальная работа — нужно её проанализировать, закрепить результат и только затем приступать к работе над деталями. Как пример: нет смысла оснащать свои офисы по последнему слову техники, пока у вас не отлажена надёжная система поставки сырья на производство.
- Фокусировка на критике клиентов: системный бизнес всегда нацелен на удовлетворение потребностей клиента; таким образом, жалобы и замечания служат прекрасным индикатором системных недочётов.
Построение системного бизнеса
Организационная структура состоит из взаимодействия технических, экономических, социально-психологических, административных явлений и элементов.
Системное проектирование бизнеса основано на понимании, что любая организация создаётся для выполнения конкретных задач, следовательно, она должна обладать определёнными функциями, ресурсами, технологиями, носителями или пользователями которых являются наполняющие организацию элементы.
Построение новых или оптимизация уже функционирующих структур основывается на балансе компонентов, так называемой «триаде системного подхода».
- Цели и показатели: первые оправдывают существование предприятия, вторые характеризуют эффективность деятельности, направленной на достижение целей.
- Система деятельности, состоящая из структур, процессов, задач, должна постоянно оцениваться на предмет соответствия поставленным целям.
- Распределение ответственности за достижение запланированных целей должно проводиться согласно установленным в организации принципам, а также сопровождаться наделением соответствующими полномочиями (другими словами, нельзя спрашивать с сотрудника, который не наделён правом отдавать распоряжения, в императивном порядке организовывать мероприятия).
Системный процесс синтеза оргструктуры подразумевает, что данная последовательность выполняется несколько раз, на каждом шаге отдаляясь от центрального руководящего звена к периферийным узлам управления, приобретая всё большую детализацию, пока не превратится в конкретные скрипты, правила, инструкции.
Заключение
Как ни парадоксально, большинство экономических школ России не дают практически никаких полезных навыков: у нас учат экономистов, а не предпринимателей.
“Тренинги и семинары на которых я был до программы Высоцкого, безусловно, давали определённые знания, практическую информацию. Но как её структурировать, как применять для повышения эффективности бизнеса — этому нигде не обучают”.
Д. Тараненко, владелец компании «Сток Опт»
Конечно, рынок полон предложениями консалтинговых компаний, разрабатывающих и внедряющих системные бизнес-решения, однако зачастую это происходит как бы без участия собственника. Инструменты внедряются, процессы отлаживаются, но причинно-следственная связь от руководителя ускользает. А ведь, как мы убедились, развитие бизнеса — это спираль, значит, через какое-то время возникнет потребность снова реорганизовывать бизнес.
Поэтому разумно отдавать предпочтение программам, нацеленным одновременно на преобразование компании и на обучение её собственника.