>> БП может в себя включать кучу всего вне системного контура и у него другие задачи.
БП — да, а БП, подлежащий автоматизации, всегда мапится на функции системы.
И я бы все же разделяла понятия как в терминах у Вигерса (логическую модель данных он часто заменяет синонимом концептуальной) и общепринятых стандартов, например, UML (Class Diagram в UML или ERD у аналитиков так и называется концептуальной моделью предметной области в терминах сущностей (классов), их атрибутов и связей). Я понимаю что у вас концептуальная модель системы как бы, а не данных, но такого термина я не встречаю в обиходе.
>> У Вас есть какие-то еще примеры?
Тут я все же больше имела ввиду важные моменты на фазе инициации разработки: технологический стек реализации и иные нюансы, которые должны быть на входе у архитекторов при проектировании или создании тех. дизайна системы с учетом инфраструктур, кроссплатформенности, сред развертывания, интеграций, миграции данных, перспектив масштабирования и т.д.
То, что перечислили вы это уже более глубокие моменты последующего функционального анализа (технического, системного) и действительно не всегда могут быть в пакете итоговых артефактов для условно простых систем.
Возможно, я неверно поняла фразу «Потребность в некоторых документах возникает вариативно, в зависимости от особенностей проекта»:)
Концептуальная модель (точнее то, что вы ею называете; для меня понятие концептуальной модели все же ближе к понятию модели данных (логической модели) или концептуальной модели данных в терминах UML, а у вас модель БП верхнего уровня в нотации IDEF0; сущности описывают ERD и UML Class Diagram) и технологический стек — это немного о разном, как мне кажется. Тех. моменты решения, которые стоит учесть на этапе анализа, есть всегда, независимо от того, «простая система или сложная».
>> А вот UX/UI нет в бековских системах (а где есть фронт — макеты будут 99%), в простых системах архитектуру вполне заменяет концептуальная модель, как мне кажется.
Макеты да, а UX ;)
Но, это все придирки, повторюсь:) Статья очень структурна и полезна.
Хорошая статья:) Не соглашусь лишь с отнесением описания архитектурных решений в необязательные другие типы документов.
Тема обширна. Возможно, различия в восприятии терминологии, но важные тех. решения должны быть выявлены и обязательно зафиксированы на самом старте проекта, отражены в структуре требований (особенно, если у вас будут логические модели данных в виде ERD-диаграмм или диаграммы классов, например) и проектировании минимально-достаточного «дерева» требований. Или еще аргумент хотя бы с позиции потребностей бизнес-анализа: без арх. решений вы НФТ (производительность, отказоустойчивость, например) ну никак не напишите исчерпывающе.
UX/UI не так категорично, конечно, но я бы тоже отнесла в обязательные.
В том то и дело, что в НИОКР без детально проработанных требований (конструкторских решений, планов, чертежей) вы никогда не перейдете к последующим фазам:) Даже для производственного образца будет гора документации. Кратко говоря картинка с самокатом из тренингов по Agile никогда не будет иллюстрацией создания боинга или ПО для колл-центра скорой помощи.
Помимо предиктивного и гибкого ЖЦ, есть еще итеративные инкрементные (PMBOK версии 6).
Главная ошибка в
непонимании отличия
проектов с итеративной моделью жизненного цикла (с инкрементным наращиванием функционала продукта или без него), реализуемых по схеме фиксаций проектных характеристик и, чаще всего, ориентированных на управление фиксированными характеристиками проекта,
от
проектов с адаптивной (гибкой, Agile) моделью жизненного цикла (которая в свою очередь является разновидностью вышеназванной итеративной инкрементной модели жизненного цикла), ориентированных всегда на управление изменениями.
Разница в том, что в IID можно сформулировать требования (разработать чертеж боинга), сделать план на N итераций (не на весь проект как в предиктивном ЖЦ (waterfall)), а гибкие ЖЦ дают больше инструментов, когда этого сделать невозможно по причине неопределённости скоупа.
Еще пример с известным сервисом пассажироперевозок. Каков подход к управлению на старте его разработки (мой ответ: гибкий)? А сейчас (мой ответ: IID+Agile)? Почему? Подсказка: с позиции возможности определить функционал и в целом целесообразность вложений в такой продукт. Более того сейчас не требуется проверка гипотез в принципе о возможности существования такого сервиса, она скорее потребуется в отношении каких-то конкурентноспособных фич, если на текущий момент разработка такой реплики вообще целесообразна:) Но это покажет другой анализ. Здесь пример для ЖЦ.
И то, к чему я фактически вела.
В большом количестве случаев в рамках аутсорсинговых контрактов (например) или для ПО для собственных нужд (возможно банковского, например) когда возможно определить скоуп (нет исследований, проверки гипотез) оптимальным является выбор IID ЖЦ, а не гибкого, с предварительной фазой диагностики и фиксациями параметров проектного треугольника и в дальнейшем с процессами работы с планом и с изменениями и т.д. Это поможет снизить риски разрыва ожиданий. При этом ничто не мешает нам быть Agile в таких проектах в более широком смысле этого понятия.
Автор статьи и сам прекрасно понимает проблемы использования выбранного подхода. Я в таких случаях предлагаю «не натягивать сову на глобус», а посмотреть в сторону других инструментов и подходов.
>> К сожалению, чтобы разобрать там все проблемы потребуются не одна и не две вдумчивых сессии, явно не формат комментария.
Тем не менее вы «выставили свой диагноз» о проблемах с картиной мира Scrum. Это как врачебный по фотографии:)
Не помогли даже мои пояснения.
А логическая цепочка такова: проблема долгосрочных планирования и фиксации параметров (несовместимы не равно невозможны) — полезность и адекватность оценок, если они все же требуются — выбор правильного подхода к управлению проекта (в том числе и с учетом степени неопределенности скоупа проекта на старте и возможности ее уменьшить) и работа с разрывом ожиданий и изменениями. Разрыв ожиданий не равно неверные ожидания. Это термин работы с рисками и бизнес-анализа.
И:) могу подсказать вопрос, который поможет порыть глубже, для начала хотя бы в этом направлении: что предлагает нам Agile из инструментов долгосрочного планирования?
>> Просто в этом случае применение PMBOK может оказаться полезнее попытки нанятуть Agile методы. Тем более что нормальная предиктивка никак не отрицает замечательных вещей…
Кажется, вы не рассмотрели корову со всех сторон:) И в первоисточнике, кажется, было про слона:))
По моей фразе «после получения какой-то начальной картины по оценкам» разве верен ваш вывод о моей категоричности в утверждении невозможности получения оценок? Я писала не о невозможности, а о полезности, как раз-таки, этих оценок:) их применимости и рисков разрыва ожиданий.
И мне было бы интересно, что в моем комментарии вы считаете вольной интерпретацией скрам гайда?
Scrum и фиксированные оценки не совместимы более, чем на один запланированный спринт. Scrum базируется на эмпиризме. Эмпиризм там, где высокая степень неопределенности, обратная связь и опыт. Как можно оценить то, что неопределенно?:) Только отработав некоторый момент времени и получив Velocity мы можем делать всего лишь прогнозы. Оценка всего бэклога сомнительна в любой момент времени проекта. А если у вас после N спринтов по обратной связи стейкхолдеров по продукту поменяется половина фич (или сторей и т.д.)? Все техники оценки работают в рамках планирования одного спринта. Мне кажется, после получения какой-то начальной картины по оценкам (неважно каким образом полученными, если они нужны заказчику, все равно они будут далеки от реальности, скорее всего) необходимо грамотно отработать возражения клиента по моменту окончательности этих оценок, чтобы избежать разрыва ожиданий. Либо писать требования и делать оценку. Но это не всегда возможно и это уже не про Scrum (см. далее).
Иная ситуация: детально прописанные атомарные требования (глубже, чем фичи или стори в бэклоге) дают возможность получить оценку трудозатрат. Но тогда у вас скоуп является определенным, вы режете его на куски и реализуете по итерациям, управляя изменениями, которые могут быть, но не так часты, например. Это не Agile и не Scrum как его инструмент, это IID (итеративный инкрементный ЖЦ, разновидностью которого, и является адаптивный ЖЦ) и там множество своих инструментов и для оценки и для управления.
Позвольте высказать точку зрения человека из сферы ИТ и образования в ИТ. Возможно, кто-то в ней что-то найдет для себя, чему я буду несказанно рада.
Иллюзия “про деньги”.
Человек счастлив только в своей деятельности и в процессе получения результата и осознания его, принятии новых вызовов и поиска путей развития. Бывают исключения, но… Это закономерности не только биохимии мозга и выработки гормона дофамина, базовых инстинктов, но и эволюции: выживает сильнейший, выживает деятельностный, используй, совершенствуйся или потеряешь, а то и умрешь (концепт постоянного развития или open-endedness). Я не могу найти ни одного примера богатого наследника богатых родителей, который был бы счастлив в своей бездеятельности и неисчерпаемости финансов. С неограниченными финансами рушатся границы в доступном, но блага не безграничны, наступает момент, когда чего-то хочется, а все есть и больше нечего придумать. Поэтому богатые и мудрые родители главным благом видят необходимым НЕ передать наследство чаду, а дать образование, предполагающее не только наличие фундаментальных навыков и развивающее интеллект, но и оттачивание мастерства постоянного обучения и саморазвития (навыков собранности), умения личностного стратегирования и гибкости в построении образовательных траекторий саморазвития (stepping stones или “бесцельное фланирование”).
Иллюзия “про разбогатеть, став умнее”.
Компьютерные модели (https://arxiv.org/abs/1802.07068) показывают, что богатство дается волей случая, везением. Если человек развил интеллект и навыки, то он не упустит случая. Богатые – это удачливые люди. Они могут быть не самыми умными, но уж точно не глупые, раз не упустили шанс. Но более умному может не выпасть этот шанс. Варианта два: становиться искусным рациональным фланером и пробовать (что не гарантирует, но повысит шанс на успех) или принять факт, что развитие, ум и богатство, увы, не имеют прямолинейной связи и прикладывать усилия там, где действительно будет ожидаемый результат.
Иллюзия “про выгорание и профессию на всю жизнь”
Мы живем в интересное время перемен и экспоненциального роста технологий. Перемены наступают, но не успеют вступить в силу изменения, являющиеся следствием этих перемен, как уже наступают новые перемены. На фоне того, что бабушка работала от звонка до звонка у станка и была счастлива (нужно серьезно учитывать контекст условий послевоенной жизни и многие-многие детали социума), нежелание в 30 лет работать программистом звучит как бы дико. Но в свете современных обстоятельств большая странность для меня в том, что в человеке может пребывать уверенность о том, что профессия программиста с текущими навыками (даже если они на максимуме сейчас) или водителя с ним на всю жизнь. Тони Себа прогнозирует, что с 2025 года все новые автомобили будут электрическими, а компания NVIDIA в 2021 году анонсировала выпуск ПО для беспилотного вождения. Уже нашему поколению предстоит переучиться еще 3-4 раза. А наши дети, есть мнение, сменят профессию до 10-12 раз.
Вывод.
Хотеть изменить профессию, искать развития в Х лет — это нормально! Считать, что уже стар или это лишнее – нет. Выгорание – это не выгорание. Это точка роста.
Мои советы на старте.
1. Заняться поиском и личным стратегированием, развитием и совершенстованием мастерства собранности (умения учиться).
2. Почитать первоисточник (искать результаты трудов Анатолия Левенчука), выше обозначенных моментов в моей интерпретации, которые я глубоко разделяю.
А дальше, я полагаю, вы уже будете знать, что делать.
>>… т.е. для анализа данных.
верно, но это ведь не совсем про бизнес-анализ.
Но вы — автор, ваше право. Вопрос не в моем позволении же :) я просто посоветовала. Но тогда хорошо бы использовать один термин «аналитика» или «анализ», «бизнес-анализ», «анализ данных» и т.д. (для меня, например, это 4 совершенно по-разному объясняющиеся понятия) для одного понятия (предположив неточности перевода и т.д.), но одно понятие называть разными терминами, сильно отличающимися, — не очень.
В заключительной части у вас: «Правильный выбор инструмента для бизнес-аналитики...»
На Википедии все верно, у вас все же не совсем. Мое дополнение к определению выделено жирным шрифтом.
Business intelligence (сокращённо BI) — обозначение компьютерных методов и инструментов для организаций, обеспечивающих перевод транзакционной деловой информации в человекочитаемую форму (это аналитика и BI — это инструмент именно для этого), пригодную для бизнес-анализа (здесь много других инструментов и это уже не BI, а использование его результатов), а также средства (вот тут уже об анализе, но в статье они не раскрываются подробно) для массовой работы с такой обработанной информацией.
Устоявшиеся термины для двух различных областей: аналитика данных и бизнес-анализ.
Я поясню шире и другими словами.
BI — это, обобщенно говоря, совокупность инструментов для обеспечения аналитики данных, результаты которой (аналитики) используются для анализа (в том числе и для бизнес-анализа) и принятия решений (в том числе и для бизнеса). Вы пишите о первом (инструментах аналитики), которые помогают получать отчеты и т.д. Разумно, именно это обозначить в названии. А вот уже как используются эти отчеты и данные из них (построение бизнес-моделей, визуализация данных, установление критериев принятия решений для конкретных ситуаций бизнеса, анализ альтернатив, выводы, обоснование выводов) вы не раскрываете, только называете некоторые возможности инструментов в рамках их описания. После процесса аналитики (получения отчетности), начинается процесс анализа. Кстати, в выводах и кое-где в статье у вас указан верный термин.
И еще бизнес-анализ (область разработки требований к продуктам и системам) может существовать без аналитики данных, но не наоборот — аналитика всегда нужна для анализа.
У вас хорошая статья, но этот тонкий момент сделает ее лучше :)
Посмотрите также тут: ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%B0.
Из определения следует, что отчеты — это часть рассуждения (аналитика), которая помогает сделать анализ.
Здравствуйте! Поправьте в названии: статья про бизнез-аналитику данных, а не про бизнес-анализ. Между аналитикой и анализом все же существенная разница.
Cравнение Agile и DevOps в целом некорректно. Agile — это манифест и 12 принципов. DevOps — это Agile “tribe” или area of concern, которое адаптирует и реализует (по необходимости дополняет, но никогда не противоречит философии, поэтому и сравнивать-то нечего) идеи и ценности Agile через конкретные практики (Automated Build, Version Control, Continuous Integration, Continuous Deployment, например), позволяя следовать философии Agile в конкретных контекстах потребностей проекта и выбранного инструмента.
Гнать или не гнать — это надо еще понять (могут и не сознательно ведь). Мы вроде с разных позиций смотрим на ЭМ. Я ни разу не говорила о позиции начальника и дурака или позиции «я так вижу». Это вопрос нездоровых амбиций и всего чего угодно только НЕ здравого менеджмента.
Я говорю о том, что инвестор при любых сомнениях (или просто так) имеет право на аудит и стороннее мнение, имеет право на адекватную реакцию команды на его решение и лояльную проработку командой такого решения. Даже если попался ЭМ-«личинка», то «если доводы команды объективны, то инвестор их поймет». А вот при оправдании сомнений он имеет право на запуск изменений. К тому же, мне хорошо знаком изначальный посыл, указанный в статье (Твоя команда из тебя деньги вымогает. Да твое приложение можно было за 3 месяца выпустить за те же деньги. Давай я тебе покажу как надо! Я их выведу на чистую воду!). Не такой уж и уникальный, и не такой уж неоправданный. И примеров, когда «в этом есть доля правды», увы не мало. Даже не потому, что команда действует намеренно, а просто потому что ошибаться — это нормально.
Но это слишком общо, чтобы прийти к единому пониманию. Частные же случаи и конкретные контексты потянут на часы-дни дискуссий.
Эффективный менеджер в кавычках или без всегда будет злом для команды. Если команда работает хорошо, то он не нужен, если плохо – она, вероятнее, не будет заинтересована об этом узнать, а если знает и делает, то это вообще вопрос жизненных принципов и “места под солнцем”.
В частности же, хуже всего сочетание “эффективный” менеджер и неэффективная, скажем так, команда. Вот это абсолютное зло для инвестора. А в общем, все возможные вариации ситуации должны рассматриваться исключительно с позиции его (инвестора) интересов и не ограничиваться компетенцией одного специалиста – слишком много аспектов затрагивают такой аудит и улучшения (и технологические моменты, и процессные).
Но лично мне не понятно во всем этом только одно: почему постановка задачи и отношение к эффективному менеджменту формулируется через призму “хорошая команда по умолчанию”? Увы, в реальности так не всегда. И даже вопрос не в том, что команда неэффективная (имеет или нет некое намерение, чтобы быть таковой), она просто может этого не знать.
БП — да, а БП, подлежащий автоматизации, всегда мапится на функции системы.
И я бы все же разделяла понятия как в терминах у Вигерса (логическую модель данных он часто заменяет синонимом концептуальной) и общепринятых стандартов, например, UML (Class Diagram в UML или ERD у аналитиков так и называется концептуальной моделью предметной области в терминах сущностей (классов), их атрибутов и связей). Я понимаю что у вас концептуальная модель системы как бы, а не данных, но такого термина я не встречаю в обиходе.
>> У Вас есть какие-то еще примеры?
Тут я все же больше имела ввиду важные моменты на фазе инициации разработки: технологический стек реализации и иные нюансы, которые должны быть на входе у архитекторов при проектировании или создании тех. дизайна системы с учетом инфраструктур, кроссплатформенности, сред развертывания, интеграций, миграции данных, перспектив масштабирования и т.д.
То, что перечислили вы это уже более глубокие моменты последующего функционального анализа (технического, системного) и действительно не всегда могут быть в пакете итоговых артефактов для условно простых систем.
Концептуальная модель (точнее то, что вы ею называете; для меня понятие концептуальной модели все же ближе к понятию модели данных (логической модели) или концептуальной модели данных в терминах UML, а у вас модель БП верхнего уровня в нотации IDEF0; сущности описывают ERD и UML Class Diagram) и технологический стек — это немного о разном, как мне кажется. Тех. моменты решения, которые стоит учесть на этапе анализа, есть всегда, независимо от того, «простая система или сложная».
>> А вот UX/UI нет в бековских системах (а где есть фронт — макеты будут 99%), в простых системах архитектуру вполне заменяет концептуальная модель, как мне кажется.
Макеты да, а UX ;)
Но, это все придирки, повторюсь:) Статья очень структурна и полезна.
Тема обширна. Возможно, различия в восприятии терминологии, но важные тех. решения должны быть выявлены и обязательно зафиксированы на самом старте проекта, отражены в структуре требований (особенно, если у вас будут логические модели данных в виде ERD-диаграмм или диаграммы классов, например) и проектировании минимально-достаточного «дерева» требований. Или еще аргумент хотя бы с позиции потребностей бизнес-анализа: без арх. решений вы НФТ (производительность, отказоустойчивость, например) ну никак не напишите исчерпывающе.
UX/UI не так категорично, конечно, но я бы тоже отнесла в обязательные.
Помимо предиктивного и гибкого ЖЦ, есть еще итеративные инкрементные (PMBOK версии 6).
Главная ошибка в
непонимании отличия
проектов с итеративной моделью жизненного цикла (с инкрементным наращиванием функционала продукта или без него), реализуемых по схеме фиксаций проектных характеристик и, чаще всего, ориентированных на управление фиксированными характеристиками проекта,
от
проектов с адаптивной (гибкой, Agile) моделью жизненного цикла (которая в свою очередь является разновидностью вышеназванной итеративной инкрементной модели жизненного цикла), ориентированных всегда на управление изменениями.
Разница в том, что в IID можно сформулировать требования (разработать чертеж боинга), сделать план на N итераций (не на весь проект как в предиктивном ЖЦ (waterfall)), а гибкие ЖЦ дают больше инструментов, когда этого сделать невозможно по причине неопределённости скоупа.
Еще пример с известным сервисом пассажироперевозок. Каков подход к управлению на старте его разработки (мой ответ: гибкий)? А сейчас (мой ответ: IID+Agile)? Почему? Подсказка: с позиции возможности определить функционал и в целом целесообразность вложений в такой продукт. Более того сейчас не требуется проверка гипотез в принципе о возможности существования такого сервиса, она скорее потребуется в отношении каких-то конкурентноспособных фич, если на текущий момент разработка такой реплики вообще целесообразна:) Но это покажет другой анализ. Здесь пример для ЖЦ.
В большом количестве случаев в рамках аутсорсинговых контрактов (например) или для ПО для собственных нужд (возможно банковского, например) когда возможно определить скоуп (нет исследований, проверки гипотез) оптимальным является выбор IID ЖЦ, а не гибкого, с предварительной фазой диагностики и фиксациями параметров проектного треугольника и в дальнейшем с процессами работы с планом и с изменениями и т.д. Это поможет снизить риски разрыва ожиданий. При этом ничто не мешает нам быть Agile в таких проектах в более широком смысле этого понятия.
Автор статьи и сам прекрасно понимает проблемы использования выбранного подхода. Я в таких случаях предлагаю «не натягивать сову на глобус», а посмотреть в сторону других инструментов и подходов.
Тем не менее вы «выставили свой диагноз» о проблемах с картиной мира Scrum. Это как врачебный по фотографии:)
Не помогли даже мои пояснения.
А логическая цепочка такова: проблема долгосрочных планирования и фиксации параметров (несовместимы не равно невозможны) — полезность и адекватность оценок, если они все же требуются — выбор правильного подхода к управлению проекта (в том числе и с учетом степени неопределенности скоупа проекта на старте и возможности ее уменьшить) и работа с разрывом ожиданий и изменениями. Разрыв ожиданий не равно неверные ожидания. Это термин работы с рисками и бизнес-анализа.
И:) могу подсказать вопрос, который поможет порыть глубже, для начала хотя бы в этом направлении: что предлагает нам Agile из инструментов долгосрочного планирования?
Т.е. PMBOK это предиктивка по-вашему? :)
По моей фразе «после получения какой-то начальной картины по оценкам» разве верен ваш вывод о моей категоричности в утверждении невозможности получения оценок? Я писала не о невозможности, а о полезности, как раз-таки, этих оценок:) их применимости и рисков разрыва ожиданий.
И мне было бы интересно, что в моем комментарии вы считаете вольной интерпретацией скрам гайда?
Иная ситуация: детально прописанные атомарные требования (глубже, чем фичи или стори в бэклоге) дают возможность получить оценку трудозатрат. Но тогда у вас скоуп является определенным, вы режете его на куски и реализуете по итерациям, управляя изменениями, которые могут быть, но не так часты, например. Это не Agile и не Scrum как его инструмент, это IID (итеративный инкрементный ЖЦ, разновидностью которого, и является адаптивный ЖЦ) и там множество своих инструментов и для оценки и для управления.
Иллюзия “про деньги”.
Человек счастлив только в своей деятельности и в процессе получения результата и осознания его, принятии новых вызовов и поиска путей развития. Бывают исключения, но… Это закономерности не только биохимии мозга и выработки гормона дофамина, базовых инстинктов, но и эволюции: выживает сильнейший, выживает деятельностный, используй, совершенствуйся или потеряешь, а то и умрешь (концепт постоянного развития или open-endedness). Я не могу найти ни одного примера богатого наследника богатых родителей, который был бы счастлив в своей бездеятельности и неисчерпаемости финансов. С неограниченными финансами рушатся границы в доступном, но блага не безграничны, наступает момент, когда чего-то хочется, а все есть и больше нечего придумать. Поэтому богатые и мудрые родители главным благом видят необходимым НЕ передать наследство чаду, а дать образование, предполагающее не только наличие фундаментальных навыков и развивающее интеллект, но и оттачивание мастерства постоянного обучения и саморазвития (навыков собранности), умения личностного стратегирования и гибкости в построении образовательных траекторий саморазвития (stepping stones или “бесцельное фланирование”).
Иллюзия “про разбогатеть, став умнее”.
Компьютерные модели (https://arxiv.org/abs/1802.07068) показывают, что богатство дается волей случая, везением. Если человек развил интеллект и навыки, то он не упустит случая. Богатые – это удачливые люди. Они могут быть не самыми умными, но уж точно не глупые, раз не упустили шанс. Но более умному может не выпасть этот шанс. Варианта два: становиться искусным рациональным фланером и пробовать (что не гарантирует, но повысит шанс на успех) или принять факт, что развитие, ум и богатство, увы, не имеют прямолинейной связи и прикладывать усилия там, где действительно будет ожидаемый результат.
Иллюзия “про выгорание и профессию на всю жизнь”
Мы живем в интересное время перемен и экспоненциального роста технологий. Перемены наступают, но не успеют вступить в силу изменения, являющиеся следствием этих перемен, как уже наступают новые перемены. На фоне того, что бабушка работала от звонка до звонка у станка и была счастлива (нужно серьезно учитывать контекст условий послевоенной жизни и многие-многие детали социума), нежелание в 30 лет работать программистом звучит как бы дико. Но в свете современных обстоятельств большая странность для меня в том, что в человеке может пребывать уверенность о том, что профессия программиста с текущими навыками (даже если они на максимуме сейчас) или водителя с ним на всю жизнь. Тони Себа прогнозирует, что с 2025 года все новые автомобили будут электрическими, а компания NVIDIA в 2021 году анонсировала выпуск ПО для беспилотного вождения. Уже нашему поколению предстоит переучиться еще 3-4 раза. А наши дети, есть мнение, сменят профессию до 10-12 раз.
Вывод.
Хотеть изменить профессию, искать развития в Х лет — это нормально! Считать, что уже стар или это лишнее – нет. Выгорание – это не выгорание. Это точка роста.
Мои советы на старте.
1. Заняться поиском и личным стратегированием, развитием и совершенстованием мастерства собранности (умения учиться).
2. Почитать первоисточник (искать результаты трудов Анатолия Левенчука), выше обозначенных моментов в моей интерпретации, которые я глубоко разделяю.
А дальше, я полагаю, вы уже будете знать, что делать.
верно, но это ведь не совсем про бизнес-анализ.
Но вы — автор, ваше право. Вопрос не в моем позволении же :) я просто посоветовала. Но тогда хорошо бы использовать один термин «аналитика» или «анализ», «бизнес-анализ», «анализ данных» и т.д. (для меня, например, это 4 совершенно по-разному объясняющиеся понятия) для одного понятия (предположив неточности перевода и т.д.), но одно понятие называть разными терминами, сильно отличающимися, — не очень.
В заключительной части у вас: «Правильный выбор инструмента для бизнес-аналитики...»
Business intelligence (сокращённо BI) — обозначение компьютерных методов и инструментов для организаций, обеспечивающих перевод транзакционной деловой информации в человекочитаемую форму (это аналитика и BI — это инструмент именно для этого), пригодную для бизнес-анализа (здесь много других инструментов и это уже не BI, а использование его результатов), а также средства (вот тут уже об анализе, но в статье они не раскрываются подробно) для массовой работы с такой обработанной информацией.
Устоявшиеся термины для двух различных областей: аналитика данных и бизнес-анализ.
Я поясню шире и другими словами.
BI — это, обобщенно говоря, совокупность инструментов для обеспечения аналитики данных, результаты которой (аналитики) используются для анализа (в том числе и для бизнес-анализа) и принятия решений (в том числе и для бизнеса). Вы пишите о первом (инструментах аналитики), которые помогают получать отчеты и т.д. Разумно, именно это обозначить в названии. А вот уже как используются эти отчеты и данные из них (построение бизнес-моделей, визуализация данных, установление критериев принятия решений для конкретных ситуаций бизнеса, анализ альтернатив, выводы, обоснование выводов) вы не раскрываете, только называете некоторые возможности инструментов в рамках их описания. После процесса аналитики (получения отчетности), начинается процесс анализа. Кстати, в выводах и кое-где в статье у вас указан верный термин.
И еще бизнес-анализ (область разработки требований к продуктам и системам) может существовать без аналитики данных, но не наоборот — аналитика всегда нужна для анализа.
У вас хорошая статья, но этот тонкий момент сделает ее лучше :)
Посмотрите также тут: ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%B0.
Из определения следует, что отчеты — это часть рассуждения (аналитика), которая помогает сделать анализ.
Здравствуйте! Поправьте в названии: статья про бизнез-аналитику данных, а не про бизнес-анализ. Между аналитикой и анализом все же существенная разница.
Я говорю о том, что инвестор при любых сомнениях (или просто так) имеет право на аудит и стороннее мнение, имеет право на адекватную реакцию команды на его решение и лояльную проработку командой такого решения. Даже если попался ЭМ-«личинка», то «если доводы команды объективны, то инвестор их поймет». А вот при оправдании сомнений он имеет право на запуск изменений. К тому же, мне хорошо знаком изначальный посыл, указанный в статье (Твоя команда из тебя деньги вымогает. Да твое приложение можно было за 3 месяца выпустить за те же деньги. Давай я тебе покажу как надо! Я их выведу на чистую воду!). Не такой уж и уникальный, и не такой уж неоправданный. И примеров, когда «в этом есть доля правды», увы не мало. Даже не потому, что команда действует намеренно, а просто потому что ошибаться — это нормально.
Но это слишком общо, чтобы прийти к единому пониманию. Частные же случаи и конкретные контексты потянут на часы-дни дискуссий.
В частности же, хуже всего сочетание “эффективный” менеджер и неэффективная, скажем так, команда. Вот это абсолютное зло для инвестора. А в общем, все возможные вариации ситуации должны рассматриваться исключительно с позиции его (инвестора) интересов и не ограничиваться компетенцией одного специалиста – слишком много аспектов затрагивают такой аудит и улучшения (и технологические моменты, и процессные).
Но лично мне не понятно во всем этом только одно: почему постановка задачи и отношение к эффективному менеджменту формулируется через призму “хорошая команда по умолчанию”? Увы, в реальности так не всегда. И даже вопрос не в том, что команда неэффективная (имеет или нет некое намерение, чтобы быть таковой), она просто может этого не знать.