Данные - как продукт или про будущее аналитики. 

 

Чаще всего работа с данными это что-то, что происходит внутри организации, поэтому теряется одна из основополагающих компонент “продуктовости” - определение ценности для клиента через продажу, а еще лучше через вторичную продажу. 

 

На настоящем “рынке” требуется (надеюсь, не задеть глубоко погруженных в тему упрощением): 

1. осознавать и создавать ценность
2. привлекать клиентов
3. а для этого анализировать целевую аудиторию, проводить интервьюирование
4. анализировать цены и условия конкурентов 
5. создавать маркетенговые стратегии (включающие многоходовые прогревы, создание бренда, сети рекомендаций)
6. собирать реальную обратную связь с целью усовршенстования продукта 
7. заботиться о последующих продажах и в целом лояльности к бренду
8. исследовать новые фичи, втч из “голубого океана” (т. е. те о которых клиент может и не догадываться) -  так называемый cust dev 
9. считать pnl 

 

Это все про продуктовое мышление и клиентоцентричность. Профит рыночной экономики именно в том, что она позволяет за счет конкуренции создавать наиболее качественные и доступные продукты. 

 

Давайте подумаем. Как обычно выглядит заказ данных внутри организации?

В зависимости от зрелости дата платформы, наличие core команды инженеров и в целом компетенции у сотрудников в написание кода цепочка получения ценности может быть чуть разной. 

 

Если обобщить, то всего четыре варианта: 

1. клиент описывает свой дата заказ и ждет выполнения
2. клиент описывает свой дата заказ, получает частичную раелизацию, и что-то доделывает на инструментах платформы или в ас Excel
3. клиент описывает свой дата заказ, ему предоставляют инструменты, он делает все “сам”
4. клиент описывает свой дата заказ и его находят в доступе в дата платформе (скорее редкость)

 

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

 

 

Про 4 пункт хочется сказать отдельно. Действительно, чаще всего в DWH есть детальный(единая модель для нескольких источников) или базовый (сохраненная историчность по отдельным источникам и какими то универсальными ключами) слой данных. Более того, например, у teradata есть FSLDM  которая по сути не только описывает корректно масштабируемое решение, но и подсказывает компании ее бизнес сущности. Но очень часто все эти даты объекты (особенно если это что-то сильно нормализованное) требуют значительных трансформаций для получения ценности. 

 

Переходя на уровень организации - можно увидеть, что даже выполняя запросы от разных клиентов (разные проекты) производитель становится носителем понимания ценности данных всей компании. Качественно работающий дата каталог https://inoursky.com/helenlovedata/datamanagementsystem , и сами датааналитики как суперхабы организации могут знать ответы на те вопросы, до которых бизнес аналитки в целом не могут дойти. 

 

В моем понимание, данные как продукт это когда 

1. Фокусы мониторинга смещаются с слежения за тем как данные грузятся, на то как они потребляются (в тч числе в количественных метриках - сколько запросов к дата сету/просмотров итд). Скорее всего потребляемых -  значительно меньше чем тех, что грузятся)) 
2. Данные обязательно имеют качественные метаданные, отражающие сущность продукта.(Естественно, это же как маркеры товара на прилавке!)
3. Продукт менеджер погружается глубже в клиентский опыт, потребность и собственно сам бизнес и используя свою экспертизу в области данных и доступных данных - предлагает клиенту как и какие витрины ему нужны. 
4. Продукт менеджер думает про стратегию развития данных в контексте увеличения их потребления разными клиентами, в контексте сокращения стоимости производства - в общем, чтоб PnL был хорош! 
5. Наиболее типичной ситуацией “заказа” становится: клиент описывает свой дата заказ, его находят (передают в доступ) в дата платформе. 

 

Когда в прошлом году завела свой профиль на linked in - мне хотелось именно так описать то, зачем ко мне нужно обращаться. Но вообще, это настоящий вызов сделать дата платформу адаптивной для быстрого созданий на ней ценности(чаще всего скорость критический фактор развития всяких “очень полезных песочниц”), и культуры вовлеченности дата команд в общий бизнес результат. 

Мне кажется первым шагом на этом пути может стать оценка/осознание(а может и проверка гипотезы) ценности того или иного атрибута для аналитики в момент появления его в процессинговой системе. 

 

Надеюсь пройти его вместе с какой нибудь компанией! Helen love data. 

 

Согласитесь, первое, что приходит в голову, когда вы слышите Data lineage это визуализация диаграмм потоков данных. Это могут быть и pipeline как в informatica ipc или, я например, видела кастомную визуализацию в виде графа. Очень интересно, но ничего не понятно. 

Обладаю намерением рассказать, что визуализация важна, но вторична. 

 

План заметки: 

• Применение lineage
• Подводные камни внедрения 
• Причем тут коты

 

Итак, lineage - это “родословная”, а точнее метаинформация о связях между объектами  (source/target) внутри вашего DWH и шире (это важно).

 

 

 

Применение 

 

1 Анализ влияния (Impact) 

 

1.1 Мониторинг загрузок

Допустим, упал поток загрузки. На какие расчеты это влияет? Требуется остановить какие-то процессы, которые идут после?

Спорный момент тут заключается в том, что наличие lineage это лишь малая часть метаданных, которая нужна для того, чтобы в действительности оценить влияние и отреагировать на ситуацию. Рекомендую статью на эту тему: https://medium.com/airbnb-engineering/visualizing-data-timeliness-at-airbnb-ee638fdf4710

 

Если без картинок, то можно сделать следующее:  

• Autorecovery на различных этапах pipeline
• Заведение проблем в тикет систему
• Отправка уведомлений о влияние 
• Подготовка сводного ежедневного статуса(в формате светофор - без диаграмм) по влиянию на критичные процессы бизнес аналитиков

 

1.2 Анализ проблем с качеством данных 

Раскапываем проблему в target таблице, через предыдущие этапы трансформаций.

 

Если без картинок:  В этом случае картинки могут быть очень хороши. Потому что открывая 5 подзапрос, в 3 view ты реально забываешь с чего начал. А если это все есть на картинке и как-то условно “кликабельно”. Это актуально если мы говорим о каких то новых/нетипичных ошибках, или если проблемами с данными занимаются совсем не те люди, которые этот код писали. Потому что в иных случаях - вот эта базовая логика связи объектов лежит в голове у аналитика или инженера. 

 

• Просто имея список связанных объектов - можно пробежаться  и поискать как выглядела интересующая строка записи в предыдущих своих реинкарнациях на более ранних стадиях загрузки - а лучше начать с самой ранней и источника. 
• Если речь идет о промежуточных расчетах, так же можно count-ами рассчитать с какого момента идет значительное отклонение от ожиданий. 

 

1.3 Реинжиниринг витрин, а точнее этап блиц анализа и оценки сложности.

 

Представим есть stg схема с больше чем 1000 атрибутами, а в итоговой витрине около 300 атрибутов. Нужно воспроизвести финальную витрину на другой бд. 

Например, вы можете вообще не знать из каких источников загружены 1000 атрибутов. Определение источников и типов подключения - в данном случае базовая потребность. 

Получив lineage можно разделить данные на бизнес домены, оценить по кол-ву связей сложность логики. 

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

Но для непосредственного создания новых алгоритмов в моем понимании все равно нужно смотреть код и/или какую-то техническую документацию.

 

Если без картинок:  

Лично мне как аналитику табличный вид удобнее всего на свете, но это субъективно. В таблице при помощи фильтров и CTRL F найти все таблицы, где ключ клиента - FK, или, например, все таблицы, где есть историчность, в них есть минимум одно поле с датой без технического названия. 

 

2.Тепловые карты и удаление данных

 

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

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

 

 Наоборот информацию о наиболее используемых объектах  можно использовать для ранжирования выборки в дате каталоге.   

 

3. Безопасность (GDPR и прочее)

 

Во всех системах есть персональные данные или чувствительные данные - csv коды от карточек, например, нужно(а часто и по законодательству положено) понимать куда они утекают и как контролируется доступ к этим данным. 

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

 

4. Инструмент документирования

 

Data lineage - сам по себе ценность, потому что это какой-то иной (кроме кода) способ фиксации информации о логике загрузок.  DWH - клуб любителей сохранять данные. А Data governance  - клуб любителей сохранять метаданные. Информация о связанности объектов данных имеет огромный, думаю нам еще не вполне понятный, потенциал: как, например, обучение искусственного интеллекта писать запросы отвечающие типовым запросом бизнес аналитиков на базе профилирования данных источника. 

 

Подводные камни внедрения 

 

1. Отсутствие инструментов автоматизированного сбора Data lineage

 

Если для РСУБД довольно много всяких приятных движков по парсингу кода, то например когда код пишется на Scala. Вся логика сходится к тому, что чтобы было что раскладывать в lineage нужны стандарты разработки и методы мета описания объектов. 

Если Data lineage документируется вручную - много рисков, что он не соответствует реальности и устаревает. 

 

2. Логика загрузки на разных инструментах

Допустим  что-то написано на sap data services и там все красиво и понятно, а вот этот кусок загрузки ба бац и на микро сервисах от разных команд и как следствие необходимость собирать и систематизировать метаинформацию или вручную или с помощью дополнительных сервисов. 

 

3. Нет процессов и инструментов обеспечивающих актуализацию метаинформации

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

 

4. Нет возможности контролировать фронтальные объекты 

Это как раз то самое “шире” из определения Data lineage, которое я сформулировала выше. Если есть дашборды в отдельной системе, куда данные поставляются большими витринами или, например, песочницы с бесконтрольными возможностями подгрузки через jdbc, но в именно там решают значимые для бизнеса вопросы, приходим к тому, что видим цепочку, но без самого нужного флага - “вот это на самом деле важно”. 

 

5. Недостаточно других метаданных

Про это уже упоминала выше, кроме lineage нужно решить базовые вопросы управления: 

• определение перечня дата объектов и ответственных за них
• релизные политики и практики включающие актуализацию метаданных
• sla с потребителями 
• бизнес актуальность данных 

 

 

Каких котов спасаем? 

 

lineage очень популярная фича, ее продали и не раз на тех самых слайдах с короткими формулировками. Вот, например, 31 голос она получила  (где 32 самая популярная фича)  в результатах опроса после 5 дневного тренинга  по governance культуре https://t.me/datanature/192 обыграв, например, статус качества данных объектов.

 

И действительно, дело хорошее, но все точно так же, нужно понять какую конкретно нишу (“котов”) будет закрывать она в данном конкретном случае, насколько это реально. (моя заметка на тему важности формулировок в бэклоге: https://t.me/helenlovedata/76) 

 

 

Предложу следующих “котов”, в которых мне кажется максимально целесообразным использовать Lineage.

1. Небольшие группы команд, которые разрабатывают на едином технологическом стеке,  выстроены процессы devopsa и управления дата объектами, формализованы требования критичности от бизнес аналитиков. 

 

2. Как помощь в переработке большого количества кода - например, переехать в  другое хранилище при смене технологического стека и сделать новое dwh “лучше”, а pipeline прямее. 

 

3. Если у вас очень большая текучка кадров (шутка, или нет ;)) - т е действительно если людям регулярно приходится разбираться в чужом коде - будь то вопросы качества данных, или восстановления загрузок. 

 

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

 

 

 

 

 

Информационная безопасность(далее ИБ) начинается с чтения законодательства и заканчивается выбором сетевого кабеля, не являюсь экспертом ни в одной из этих областей, но могу сказать о том, что зачастую соприкосновения data people и ИБ довольно болезненная тема. 

Во-первых,главный принцип безопасности “используйте необходимый минимум в работе ”,а ключевая задача DWH наоборот “сохранить все, что только можно сохранить”(и использовать потом). Т.е. data people изначально находятся  на радаре. 

Во-вторых, вопреки бесконечным тренингам по кибербезопасности не всем очевидна именно их роль и зона ответственности. Например, менеджерами data продуктов чаще всего становится люди из аналитики, разработки, бизнеса и фокус на безопасность(если это жестко не контролируется) наводится уже после появления определенных проблем. 

 

Поговорим о том, как data people могут занять проактивную позицию и наиболее эффективно наладить взаимодействие. 

 

Публикация будет состоять из 3х блоков: 

1. Источники формирования требований ИБ и почему иногда они могут быть избыточными? 
2. Разбор популярных вопросов ИБ, к тем у кого есть доступ к данным
3. Как найти ключ к сердцу безопасника?(кратко)

Источники формирования требований ИБ и почему иногда они могут быть избыточными? 

В основе любого консенсуса, лежит желание понять позицию оппонента, поэтому предлагаю начать с источников требований.  При поиске разъяснений мне понравилась классификация предложенная dama book, так как она отражает не только ограничивающие, но и “разрешающие” потребности. Итак, 4 блока: 

1. Нормативно правовое регулирование (например, формы строгость по срокам предоставления определенных данных)
2. Законные интересы бизнеса (например, kpi руководства или патентную документацию)
3. Интересы сторон ( например, в россии это несколько федеральных законов в том числе:  N 152-ФЗ О персональных данных , 323-ФЗ (ред. от 26.03.2022) "Об основах охраны здоровья граждан в Российской Федерации")
4. Необходимые потребности бизнеса в доступе к данным

Изучив картинку, становится понятным, что гипотеза, что ИБ просто придумывают правила - не верна, а задача формирование политики ИБ не тривиальна. 

Готовых решений для каждого конкретного бизнеса нет - так как нужно учитывать  не только законодательство(часто и локальное и международное), еще и отраслевую специфику(банки, например, PCI DSS) и специфику описанную в договоре с клиентом. А, представим, что типов таких договоров сотни, а если еще и подрядчики?  Которым всегда требуется передача данных. 

 

Приведу пример зафиксированных в законодательстве требований. В законе о защите персональных данных  N 152-ФЗ  в статье 5. "Принципы обработки персональных данных" можно найти такие строки: 

 

Интересно, во многих ли договорах написано, что на основании данных будут тестироваться маркетинговые гипотезы? Знаю что в гугл точно написано аж на 32 страницы.  

При определенной интерпретации и излишней тревожности и безграничной власти сотрудников ИБ, прочитав N 152-ФЗ,  можно в целом поставить крест на аналитике использующей в своей основе персональные данные, которые все еще являются бизнес ключами и той самой изюминкой любого dwh. Конечно, в действительно, не все так страшно, потому что, например, за недавний масштабный грубый слив данных Яндекс еды наказание составило всего  60000 тыс рублей.

 

Откуда берётся избыточность в требованиях?

Кроме понятно всем желания перестраховаться, как, еще один сложный момент. Это многообразие технологических решений. Сложно удерживать невозмутимое лицо, когда смотришь схемки с логотипами новых баз/инструментов, не говоря о уже о огромном количестве рукописных фреймворков. Предполагаю, что они все как то категоризируется и использует типовые методы логирования, движки аутентификации - но все-таки формирование конкретных технических ограничений, оценка применимости, разумности в том или ином случае, а также анализ непосредственной реализации, серьезная интеллектуальная задача требующая минимум на 50% свободному от run задач. Есть ли у сотрудников ИБ приоритет и время на это?

 

Суть этой части статьи в том, что нужно проникнутся к “безопасникам” глубоким уважением.

 

Разбор популярных вопросов ИБ, к тем у кого есть доступ к данным

 

Что за данные лежат на этой флешке(условно, в пересылаемом письме) и зачем вы выносите эти данные за пределы компании?  

 

Ответ - не нужно ничего выносить, если вы предварительно не согласовали это действие с руководством с определенной целью. Это действительно, полностью ваша ответственность. 

Какой бы круто не была защищена система, человеческий фактор остается. Слышала истории, когда трудоголики системно без злого умысла уносили необезличенные дата-сеты, чтобы доделать отчетность на домашнем устройстве - тем самым сливая информацию в сеть. 

 

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

 

Т.е, как минимум уберите идентификаторы(всегда для локальных задач можно заменить на промежуточные sequence) и не забудьте поменять название самого файла, особенно если изначально оно было “зарплаты руководства”.

 

Зачем вы используете персональные идентификаторы и/или другую чувствительную информацию? (вообще и/или при разработке дата-продукта)

 

Начать стоит с того, что минимизировать объем таких данных. 

Если взять за новое правило задавать себе этот вопрос в момент начала анализа источника  - вы можете очень сильно упростить себе жизнь.  Видя подозрительные поля уточнять у заказчика, точно ли это будет использоваться и можете ли вы вместе придумать смысловую логически верную альтернативу.  Если говорить про биг дату, часто для проверки некоторых гипотез и построения рекомендательных моделей достаточно статистического массива. Также при опромышливание дата продуктов ключи безусловно можно заменить на хэши. Правда важно не забывать про проверки качества и наличие в данных бизнес ключей для объединения с другими массивами.

 

Для тех данных, что останутся: 

• Нарисуйте модель данных это позволит намного проще и объяснить, и самим понять почему вам критичны именно эти атрибуты.
• В некоторых БД есть большие преимущества по базовым возможностям разграничения прав доступа, стоит изучить этот вопрос отдельно. Где-то можно создать view, и навязать на них умные ролевые модели,  а где то в движок БД вшита даже построковая фильтрация результата - используйте это по максимуму, просто пряча чувствительные данные на нижние уровни. Ну а если у вас hadoop.. то подходите к вопросу более творчески;) Например, если у вас есть информация о заболеваниях клиента, детальная с диагнозом - это критично, вы можете вынести в доступную “для широкого круга пользователей” некий недискредитирующий флаг “требует особого отношения”, а в скрытой таблице витрины оставить мед тайну. 
• Проверьте в документации/и/или политиках/законодательстве сами, что данные могут использовать для тех целей, для которых вы хотите - это например, должно быть в политике конфиденциальности или договорах с клиентом. Подготовьте почву для общения, но не торопитесь выкладывать ее пока не спросят.
• Привлеките бизнес заказчиков, которые объяснят экономический эффект от использования данных, а иногда может и будут готовы взять на себя некоторые риски. 
• Опасный совет, но считаю его правильным. Зафиксируйте договоренности с бизнес владельцем данных, тем самым продемонстрировав сотрудникам ИБ свою этичность (по хорошему они должны согласовывать распространение производных данных, но это уже data governance).Под бизнес владельцем я понимаю, того кто формирует ценность данных на входе в ваш продукт(например, собирает и создает клиентскую базу),также он часто является ключевым потерпевшим в случае утечки информации. 

Откуда на этой среде данные?

 

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

 

Тема обезличивания красной нитью проходит по статье, и резонно возникает вопрос, так давайте все обезличим и будем работать?  Мне бы очень хотелось сказать, что при помощи обезличенных данных можно полноценно проводить аналитику, например, на среде разработки(и возможно все еще впереди), но суть проблемы довольно глубоко - она в том, что источники данных - автоматизированные системы, открытые данные и прочее - живые существа, в которых меняется не только профиль данных, но часто и структура, а для процесса интеллектуального обезличивания необходимо время и качественно описанная модель источника, не говоря уже о времени требуемом на процесс релизного вывода кода  - за счет этого образуется слепая зона и реальная разница в данных, вызывающая ошибки при выводе продуктов в пром. В общем, приходится ИБ доверять D-people, чтобы бизнес делался.

 

Пожалуй, остальные вопросы, которые приходят в голову уже лежат в плоскости проектирования архитектуры решения или относятся к data opsу.

Например, у кого будет пароль на обновление и изменение кода? Какие методы шифрования данных применяются? как устроена аутентификация?каким образом организована доставка кода на промышленную среду?есть ли бэкапирование, куда делают бэкап? как организован доступ к данным? каким образом устроено логирование пользователей? 

Кроме этого требования периодически меняются, и естественно лучше стараться решать вопросы “малой кровью” и просто обыграть ту архитектуру, что есть. 

У нас был такой случай, когда представителю ИБ категорически не нравился приемник наших данных с формулировкой как раз про отсутствие логирования, но каким то сказочным путем его удовлетворило как sas клиент логирует  пользовательские обращения к готовому дата продукту.(т е нас спас не наш, а конечный пользователь). 

 

Как найти ключ к сердцу безопасника в вашем случае?

1. Понимайте, когда за вами придут(шутка). Осознайте какие принимаемые именно вами или вашей командой решения влияют на ИБ. Обращайте на это внимание в работе. 
2. Общайтесь с ИБ на этапе проектирования решения. Совет не нов, ибо в waterfall все так и делали. В общем, на этапе проектирования или создания первых прототипов, найдите конкретного специалиста ИБ, у которого потребуется получать согласование,  обсудите ожидания и подводные камни. Даже если вы придете к каким то непреодолимым сложностям, то не придется начинать сначала, да и просто человеческие отношения уже будут налажены. Если у вас в организации есть официальный процесс - отлично, если нет - создайте его на своем уровне. 
3. Делайте описания доступными, с картинками. Всегда помните - ИБ проще запретить, особенно запретить, то что непонятно. Поэтому в ваших интересах максимально просто и с правильным фокусом подготовить материалы. Далеко не каждый ( в силу скиллов, свободного времени, личных причин) сотрудник ИБ готов выполнять роль не только полицейского, но и конструктора/инженера/проектировщика безопасного решения.
4. Медитируйте. Безопасность выполняет свою работу. Это то что как мантру про себя повторяла на сложных многочасовых встречах. Так и задумано, они проверяют, как охранники на концерте. Помните, возможно именно они помогут найти вам сумочку, если вас ограбят. Будьте доброжелательны и спокойны, но и конструктивно не давайте себя в обиду. 

 

успехов нам всем, друзья, в это непростое время, когда под угрозой не только информационная безопасность,  ILOVEDATA

 

 

В последнее время у меня создается четкое ощущение, что людей пугает 

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

 

Если смысл всей статьи донести в одной фразе, то  “ТЗ - это диалог, который нужно записать”.

Я бы разделила статью на три блока:

1. почему в диалоге важны оба участника, и как роль каждого зависит от конкретной ситуации (5 вариантов)?
2. что такое записать диалог? как выстроить работу в каналах коммуникаций, чтобы использовать это как ТЗ? Что делать если у вас нет структуры ТЗ?
3. всегда ли ТЗ - это процесс?

Потом совсем чуть-чуть расскажу про данные. И завершу тем, почему ТЗ не стоит бояться с позиции конкретных участников, а не проекта в целом.

 

В диалоге важны оба участника. Ключевая мысль в том, что ответственность лежит на плечах не только того кому требуется выполнение заказа  -  но и на плечах исполнителя. В большинстве случаев диалог ведут люди, которые имеют разные компетенции( исключение субподряд). Роль исполнителя в том, что именно он знает какие правильные вопросы, раскрывающие профессиональные аспекты задачи необходимо проговорить, они могут быть абсолютно недоступны клиенту ( в том числе в силу отсутствия не только технических навыков, но и опыта). Не нужно злиться на клиента - “а что сразу то не сказал” - подумайте о том “ а что сразу не спросили”.  Важное значение имеет и сама форма диалога( про это чуть ниже ). Формат так же лучше задать исполнителю, ведь делать (“обрабатывать вводные”) ему. 

 

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

Советую изначально понять с кем вы имеете дело. Личная встреча обычно многое ставит на свои места - если вы общаетесь через посредника “на котором все держится” , “напроситесь” хотя бы тихо послушать.

Попробую рассказать с позиции исполнителя про варианты развития событий.

 

Заказчики знают что хотят, и как это сделать. 

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

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

 

Заказчики знают чего хотят, но не знают как это сделать, а исполнитель знает. 

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

Конечно, если вопрос контракта еще нерешенный - не стоит открывать все карты. 

 

Заказчики знают чего хотят, но не знают как это сделать, и исполнитель тоже НЕ знает.

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

 

Заказчики не знают чего хотят, но слышали как сделал кто-то еще и делать нужно без вариантов - политика партии. 

Звучит не очень, но бывает, что заказчику не страшно потерять время/деньги, для него это r&d задача и важен процесс - движение вперед, важно пробовать. 

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

 

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

 

ТЗ - Нужно записать. Не поверите но существует достаточно большая разница между талмудом на 60 страниц (например, гост на по проектированию АС) и аудиозаписью в ватсап. 

 

Как я говорила ранее в зависимости от ситуации, разрабатывать детальные требования на ранних стадиях проекта иногда не требуется, но ТЗ должно быть задокументировано. 

Мы живем в очень быстрое время, процессы ускоряются, доступные технологии - делают нас все более поверхностными в части любого текстового общения. Знаете как часто мужчины шлют смайлик “огонь” - вместо того чтобы написать, “ты красивая”, хотя нельзя быть уверенными, что правильная расшифровка фразы не “гори в огне, ведьма”.Так же и в вопросах передачи друг другу задач. Например, если говорить о ролях клиент-исполнитель, люди переносят свой быстрый опыт заказа уже готовых изделий, в котором достаточно 2х сообщений в мессенджерах или одного клика на сайте. Для таких продуктов, вероятно скорость действительно ключевой показатель успешности бизнеса. Но, когда речь продукт на основе данных, или выборе целого платформенное решение - это все-таки не коробочная история. 

 

В ТЗ, практически как в CAP теореме можно обеспечить только два из трех пунктов:  

• неистовая скорость в подготовке ТЗ
• индивидуальность настроек в решение
• отсутствие глобальной переработки продукта на более позднем этапе ЖЦ

Как запустить процесс написания  ТЗ?

Ответ очень простой - коммуницируйте правильно с самого старта проекта!  

Вся информация, которая получаться со встреч и различного рода других коммуникаций - уже часть технического задания.

Бич нашего времени в качестве этих самых коммуникаций. 

 

Какие есть каналы и как выстраивать работу в них:    

1. Мессенджеры, в них текст не привязан к “теме” и конкретному проекту, часто отправлен в нескольких сообщениях и не “осмыслен”( сама периодически грешу таким). Просите важные тезисы дублировать в почту (они же уже все равно написаны) или делайте это сами, не стесняйтесь менять заголовки на осмысленные, просите коллег  вести диалог  в одной ветке, сохраняя тем самым историю переписки. 
2. Аудиозаписи - это вообще проклятие, думаю, тут не нужно пояснять - что человек не должен писать конспект по вашей 3х минутной речи. И более того он не может к ней вернутся в любой момент. 
3. Звонки - хорошее, просто отличное средство для коммуникации. Но так же обязательно подтверждать письмом в официальном канале, иначе : 
   • вас найдут когнитивные ошибки восприятия разными людьми разных аспектов (исполнитель по хорошему должен “пересказать своими словами” то что сказал заказчик)
   • различия в восприятие времени и понятия “скоро”
   • банально - кто нибудь потом не вспомнит и это не вопрос доверия, а того, что все мы довольно многозадачные
   • текст обратит на себя внимание и позволит что-то уточнить, ведь его можно перечитать 3-5 раз
   • если большая команда - вас ждет меньше испорченного телефона 
   • текст упрощает процесс делегирования

 

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

 

В общем, с ТЗ в целом имеет смысл работать как с любым документом - сначала создаете структуру и наполняйте ее. Откуда взять структуру: 

• Заведите шаблон вопросов по типовым проектам -  если он у вас есть,  главное не забывать обогащать острыми моментами каждого нового проекта. Как мы проговорили ранее, часто заказчик не знает ответов - но даже фиксация того - что этот вопрос не был учтен на ранней стадии - даст вам возможность запросить доп время и деньги - если что-то пойдет не так. Так же это поможет в целом осознать ситуацию и  уровень зрелости и вовлеченности заказчика в проект(возвращаемся к 5 вариантам) . Еще лучше если в вашем шаблоне будут не только вопросы, но и варианты ответа - ограничивая выбор,  имеете возможность обосновать вариант который наиболее важен вам в реализации.  
• Возьмите за основу старый/похожий проект, даже если у вас такого не было - поспрашивайте у коллег. 
• Если у вас совсем нет опыта, то попробуйте "приготовить рецепт до конца" - т е постарайтесь визуализировать себе процесс реализации поэтапно в проджект плане,  обсуждая с техническими специалистами детали каждого этапа, по ходу у вас начнут возникать вопросы.

Тз это диалог, диалог это процесс. 

Нужно понимать, что какой бы не была ваша методика ведения проекта/задачи, waterfall или agile, диалог не пройдёт за одну итерацию и будет продолжаться на всех этапах жизненного цикла. 

Agile в свою очередь -  это не разработка без требований - это разработка в которой требования могут законно меняться. 

Все хотят agile, но часто люди в самих командах психологически не готовы к тому, чтобы после

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

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

Можете погуглить в интернете множество статей на тему управления требованиями, это целая полка в проектном менеджменте со специализированными инструментами. (мне понравилась первая часть статьи https://habr.com/ru/company/ds/blog/534580/). 

 

В общем, это целое искусство, перечислю несколько тезисов из моего опыта: 

• Цените возможность задавать вопросы, но не давайте им ходить по кругу, только в случае неуспешности ранее принятых решений. 
• Если вам нужно что-то “уточнить” используйте только четкие, утвердительные формулировки, желательно как в игре - да/нет - а не абстрактные филосовские вопросы. 
• Задавайте “открытые” вопросы - только в случае если вам не критичен ответ, а так лучше опять же предлагайте варианты из вашей практики, заранее прикидывая дальнейшие ходы по этим вариантам.  
• Даже после того, как ТЗ написано (и например, согласовано в официальном договоре, если это внешний клиент) не забывайте фиксировать дальнейшие требования на каких то опять же wiki страницах или в единой ветке письма. 
• Еще интересный аспект - это оперативное реагирование на критические “уточнения”, нужно обязательно донести до всех участников команды, необходимость не только записывать, но и акцентировать на них внимание руководства. Кажется, это очевидно, но увы я сталкивалась с таким - что то нужно делать не по ТЗ выяснили давно и даже начали делать, а риски и сроки не оценили. 

Что там по данным? 

ТЗ на создание Платформы/Хранилища, в общем какой-то комплексной системы обеспечивающей решение сразу ряда задач. Тут можно смело гуглить стандарты проектирования АС и далее по моим инструкциям - выделять главное.  Не берусь советовать больше, потому что во первых - я не архитектор, а во вторых это нужно еще 5 страниц написать. 

ТЗ на витрину(data set - который будет использоваться в постоянных целях и возможно несколькими потребителями) - на эту тему написала целую статью и задала много всяких интересных и важных вопросов, которые можно использовать под структуру ТЗ. http://inoursky.com/helenlovedata/pochemu-vitrina-dannyh-eto-ne-odna-tablitsa 

И еще не забудьте спросить про критерии приемки: 

• чтобы понять какие показатели - ключевые показатели 
• должны ли ваши данные с чем то сходиться или сходиться между собой

ТЗ на отчет ( разовое или многоразовая выгрузка готовых расчетов)

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

 

Почему не стоит боятся ТЗ не с точки зрения проекта, а с точки зрения каждого конкретного участника?

• в действительности это довольно творческий момент для всех участников процесса - а любить творчество нынче в моде 
• вопросы озвученные в ТЗ все равно придется решать, просто выбора будет меньше, участники возможно будут воспринимать это как “проблемы” /”исправление ошибок” -  грустить и  уставать  - снижайте уровень стресса
• записывание информации - позволяет осознать и структурировать, декомпозировать задачу, это полезный soft/да и hard скилл( и главная причина - почему я веду этот блог)

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

 

Повторюсь, чтобы все это имело смысл не забывайте, что необходимо выстроить систему работы таким образом чтобы не только писать, но и читать ТЗ . Оно должно быть на виду и общим рабочим инструментом. 

 

Всем спасибо, i love data

 

ссылка на канал с аудиозаписью статьи

 

Каким сайтом каждый из нас(вне зависимости от отношения к интернету, возраста, пола, религии ) практически вне зависимости ни от чего пользуется парочку раз в день?

Поисковиком, все мы ищем информацию. 

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

Если бы вы спросили меня про продукт моей мечты, я бы ответила вам ссылкой на эту статью. 

 

Статья будет состоять из 5 блоков. 

Создание системы управления метаданными в компании: 

1. Почему это важно(цель)?
2. Что это такое?(не забудьте открыть таблицу в конце статьи) 
3. С чего начать?
4. Как “продать” это руководству?
5. В чем для меня успех?

Почему это важно?

 

Несколько месяцев назад устроила опрос про темы о которых интересно почитать и получила несколько вопросов, которые сливаются воедино с волнующей меня много лет темой создания системы управления метаданными в компании. 

Вот эти вопросы: 

Как не допустить превращения хранилища данных в DATASWAMP(болотце данных)?

Что считаешь залогом успеха внедрения бизнес глоссария? 

 

Википедия научила меня, что «мета-» означает «о себе». А на Украине главный поисковик не так давно назывался Мета. Это к тому, что качественный поиск не только у меня ассоциируется с системы сбора мета информации. 

 

Данные это актив с большими к нему ожиданиям, data driven быть не столько модно, сколько практически необходимо. Если 10 лет назад хранилища себе могли позволить только корпорации, то сейчас всё open source и cloud. И в тоже время какими бы замечательными не были технологичные технологии, данные ничего не стоят без людей, которые вкладывают в них свой опыт и знания и заставляют их работать на компанию. 

 

Цель создания системы управления метаданными  - переиспользование (интероперабельность, а где то и согласованность с непротиворечивостью) того, что люди уже вложили в данные, повышение независимости данных от людей, структурирование работы, а также упрощение обслуживания данных различными сервисными подразделениями ну и как следствие быстрая навигация и поиск по знаниям, как в настоящем гугле, только для профессионалов, так называемых D-people.

 

Что это такое система управления метаданными? 

 

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

Например, активный клиент - совершивший покупку не более чем 3 мес назад. 

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

 

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

Методология - это сложно, любимая holywar тема определения единой версии правды ключевых терминов и классификаций у различных бизнес подразделений итд. Крутые бизнес аналитики редкость и обычно они максимально заняты бизнесом и на роль айти специалистов ложится в том числе проработка расчетов, выверка и итеративное согласование алгоритмов, а айти специалисты в свою очередь зачастую не сильны(и не хотят, что важнее)  формулировать алгоритмы с использованием профессиональной(например, финансовой) терминологии. Вот и выходит, что не так просто найти тех, кто этот глоссарий качественно и оптимально по скорости создаст. 

 

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

 

Абсолютно убеждена, что вся нужная метаинформация уже рождается в ЖЦ работы с данными,  просто за счет отсутствия адекватных стандартов работы и сложности распространения методологии управления данными - это информация вовремя не структурируется, не оформляется, и не сохраняется в едином и удобном для поиска формате. 

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

Про какие метаданные идет речь:

 

ТУТ НУЖНО ПРОЧИТАТЬ ТАБЛИЦУ, если вы с телефона - скачайте PDF, если с ноутбука - откройте в конце статьи

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

 

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

Вот отличная статья от яндекса https://habr.com/ru/company/yandex/blog/557060/ - почему зоопарк бывает не только историческим наследием, но и обдуманным стратегическим шагом. Правда, как я понимаю, ребята как раз имеют некий единый управляющий механизм. В любом случае создание среды интеграции логов, структурирование идентификаторов потоков и общие справочники упростят lineage анализ, хоть и не сделают его 100% прозрачным. 

 

Кроме встраивания системы сбора информации, стоить продумать использование поискового движка, не изобретая велосипед, а используя существующие (например, elasticsearch - как же руки чешутся с ним поработать).  Плюс добавила бы возможность интеллектуальной настройки поиска при помощи того же самого sql подобного языка, такое есть во многих инструментах, например,  jira.

 

Помимо обычного googleit в этой системе за счет большого объема разносторонней метаинформации о различных объектах управления данными будет активно использоваться переход по ссылкам, как в википедий, назвала бы это неким системным поиском. Нужно стараться избегать количество фриформатных метаданных, там где можно создать несложную категоризацию ( до 10 пунктов) или новый объект справочник. 

 

Инструмент должен быть гибок в доработке и умение интегрироваться с гигантами case средств и lineage движков. Дело в том что большинство удобных и продуманных функций уже сделано в других инструментах(powerdesigner, confluence итд)  и на это потрачено не один год опыта. В действительности я, конечно, систем не проектировала(только dwh), но по моему вполне возможно продумать api, позволяющие быстро “заливать” различные метаданные в единую визуализацию. 

 

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

 

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

 

С чего начать?

Ответ на этот вопрос сильно зависит от стадии ЖЦ, уровня автоматизации, размера компании, и также вашей в ней роли.

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

 

Разберитесь, кто конкретно те люди, которые знают алгоритмы сбора ключевых данных, в каких системах сейчас они работают и есть ли уже какая либо документация (и как она выглядит).

Если не выходит, поймите какие данные максимально используемые в компании, поищите резонансные проблемные кейсы. Проблемы поднятые до уровня руководства, например, мы тут ошиблись в расчетах и потеряли млн. Ну а дальше кто с ними работает и возвращаемся к первому совету. 

Не забывайте думать про масштабирование системы и убедится, что “путь” критичных данных можно назвать “типичным”. Проблемы здесь обычно обусловлены историческим наследием, отсутствием единых процессов и подходов к управлению ими. Ну и еще раз, продумывайте автоматизированные процесс актуализации - сразу. Неактуальная метаинформация - это боль. Хотя это лучше чем вообще никакой информации.  

 

Как “продать” это руководству?

 

Планирую однажды ответить - позовите меня! 

В интернете много статей от  крупнейших компаний говорящих о необходимости построения таких систем, например, от Ростелеком https://habr.com/ru/company/rostelecom/blog/495934/ и чуть более короткая от Убер https://eng.uber.com/databook/. 

 

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

Будьте экономны и покажите это. Тратить дополнительное время(оно же деньги) но создание и работу с такой системой придется, но важно быть “экологичным” и внедрять изменения внимательно вслушиваясь в то о чем говорят команды разработки, сопровождения и бизнес пользователи.  Бывают проекты, где не то что документацией заниматься времени нет - вообще думаешь как бы успеть рассчитать данные в срок, сейчас одно из направлений моей работы именно такое. Но цена отсутсвия документации -  косяки в различном понимание алгоритмов с заказчиком, интерпретации ТЗ и прочих мелочах, которые в итоге только накручивают время на пересчет данных. Это сложно доказать это тем, кто не был “в полях” много раз и им пока везло, у кого ключевые люди не увольнялись внезапно, в конце концов, но мой опыт такой (ваша бабушка Лена)) . 

 

В чем для меня успех ?

А вот тут вступает в дело вопрос моего другого коллеги “ как не превратить хранилище данных в болото?” 

Ответ - внедрить систему управления метаинформаций и над ней инструменты и алгоритмы,  которые позволили бы в автоматизированным виде, регулярно расчищать болото. Например, мониторить нагрузку на использование тех или иных данных - часто это называется тепловыми картами.  Это трудозатратно с точки зрения ресурсов, выделяемых на дополнительного логирование, но без этого не актуальные для потребителей расчеты, 

 

Так же успех в том:

что у руководства есть быстрые дашборды, которые показывает чем наполнены хранилища и желательно в бизнес терминологии 

что нет потребности ежегодно увеличивать “железо” в разы, только если ваша компания не увеличивается в эти же разы

что молодым аналитики могут не за месяц (а хотя бы за 2-3 дня) найти нужные им данные

 

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

Описание таблицы с типовыми метаданными (стадия жизненного цикла, объект управления и описания, сами метаданные, как использовать)

Почему витрина это не одна таблица? 

Меня до глубины души поразил случай, когда давеча товарищ из дата сферы(лично не знакомы, судя по контексту - не бизнес точно), настойчиво в официальной переписке требовал от меня объяснений, чего это я ему тут описания 30+ таблиц скинула и посмела назвать это одной витриной! Как же меня бомбило, вы бы видели. Эту статью я написала для него!:) 

 

В последние годы за счет кратного увеличения объема информации и людей которые с ней работают  - наблюдаю  сильное обесценивание системного подхода к работе с данным, если кратко - “ загрузим, а потом разберемся”. Этап анализа делается на бегу  и зачастую интегрирован в процесс производства(увеличиваем кол-во релизов, делаем задачу кусочками) этого требует необходимости быстро выдавать результат. Есть свои плюсы (mvp) и минусы(бардак). Также тенденция во многом связана с тем, что сотрудники 21-26 лет, как сказал мой хороший друг - “дети Hadoop” в целом не работали с реляционными базами данных.

 

 

Итак, разберемся 

• Что такое витрина? Почему это нетривиальный вопрос даже для профи?
• Системные подходы к проектированию данных в Хранилищах
• Почему нарисованные модели данных спасут мир? 
• Есть ли золотая середина между скоростью разработки и структурированным подходом проектированию?

Что такое Витрина данных?

Базово, витрина  - это логическое объединение набора таблиц(сущностей) с колонками(атрибутами) и связями между ними, которое отвечает на запрос бизнес задачи(задач) или покрывает определенную предметную область(продажи, hr).  

 

В реальности это 20% ответа, особенно когда дело касается не производства(собрать эти таблички), а, например, сопровождения, развития, распространения и попыток структурирования багажа знаний компании. Конфигурации и скоупы таблиц, объединяемых в витрины интерпретируются довольно индивидуально. Это зависит от очень неожиданных вещей, например от  организационной структуры компании. Бывает, что департамент в компании говорит, что все таблицы которые он использует  - это их одна большая витрина, хотя данные могут быть несогласованны и даже не связаны между собой. А бывает, что каждый уважающий себя аналитик делает свою таблицу и называет ее отдельной витриной. 

В маленьких компаниях сильно проще - обычно там есть 1-2 core data команды, которые могут договориться по поводу того, что такое витрина.

 

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

 

Рубрика очевидное и невероятное.

Очевидное - обычно у команд нет проблем в понимание важности этих вопросов. 

• Сколько бизнес задач будут решать над витриной, будут ли ей пользоваться заказчики разных функциональных направлений?
• Какой предполагается объем данных (инишиал и инкремент)?
• Проверены ли бизнес гипотезы на ручных выгрузках(прототипирование)? чтобы не забыть маленькую но очень гордую таблицу
• Как результат расчета соотносится с уже существующими витринами, должен ли он с чем то сходиться ?
• Есть ли подобные витрины в вашей организации? крайне полезно посмотреть там алгоритмы связей 
• Какие требования к скорости расчета и стабильности поставки данных? Какие зависимости по поставке данных с источника?
• Какие у вас платформенные ограничения(железо то купили уже)?

 

Невероятное - часто забывают в процессе принятия решений 

• Как быстро потребуется( и потребуется ли) добавлять новые сущности и атрибуты ? 
• Какая предполагается типология запросов от пользователей, и какой у них технический уровень?
• Какая команда будет развивать и сопровождать?Это может влиять не только  на стандарты разработки, но и на сложность модели данных. 
• Каким образом, как часто и где вы будете организовывать доступ к витрине? Нужна ли поставка данных в другие системы и в каком режиме? (обычно это называется solution архитектура) 
• Какие будут уровни конфиденциальности?( для них могут потребоваться дополнительные слои view)

 

Если вы осознали большую часть ответ на вопросы, запускайте проектирование. 

 

 

Системные подходы к проектированию данных в Хранилища

Модель данных бывает концептуальная, логическая, физическая))) Ладно ладно, я не буду погружаться в такую замечательную теорию, хотя безусловно она и есть база. Меня научили проектированию данных в институте - это был один из любимейших предметов, хотя над книжкой Диго Светланы Михайловны “Основы баз данных”  - я засыпала почти так же хорошо, как над высшей математикой. 

 

И все таки никуда не деться без обращения к классикам проектирования хранилищ данных Инмону, Кимбаллу, и прости господи Линстедту. Кто не слышал про таких, но хочется разобраться, нужно прочитать если не книжки, то статьи.  Оставлю ссылку на неплохую статью( не со всем согласна, но все таки)https://moluch.ru/archive/310/70003/

 

Если кратко сформулировать сугубо мое мнение к этим подходам, получиться следующее: 

Инмон

3НФ - максимальная нормализация и единая интерпретация данных для всей компании. Для больших организаций - считаю утопичной идей, бизнес растет быстрее чем вы можете закрыть организационные аспекты работы над такой моделью. Для некоторых витрин, когда, например заказчик очень плохо понимает, что хочет - вы сами разбираетесь как правильно интерпретировать данные с источника, нормализуете (например,  в некоторых системах даже сущность клиента может быть раскидана по 10кам разных таблиц)- тем самым создаете себе отличный плацдарм для будущих более осмысленных требований заказчика. 

 

Кимбалл

Звездочка, Снежинка - максимальная ориентированность на конкретную бизнес задачу,  таблицы фактов со справочниками  вокруг. Если задача действительно локальная и не предполагается использовать витрину для других функций бизнеса это самый простой и быстрый вариант. Но учтите, что просто так добавить атрибуты в таблицы фактов у вас врятли получится. Придется делать initial перезагрузки больших таблиц - что иногда крайне проблемно. Ну и главное, будете готовы к отсутствию целостности и непротиворечивости относительно других витрин в компании. 

 

Линстедт

Data Vault - гибрид предыдущих двух подходов с HUB, SATELLITE. lINK и расширенным осознанием необходимости хранения технической истории.

Это все таки больше про базу хранилища, чем про конкретную витрину, но я фанат Data Vault, поэтому расскажу. Если запросы бизнеса часто меняются и требуются новые разрезы данных - масштабировать во все стороны модель  разработанную по данному подходу - одно удовольствие. 

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

 

 “DS подход” (мое название))

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

 

И новинка сезона - скоростные витрины - как таковое это не методология проектирования, но тут все строится вокруг самой быстрой части данных - потока событий, а остальные таблицы в целом добавляются максимально близко к подходу Кимбалла. 

 

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

 

Будет отдельная статья, где покажу пример создания модели в разных методологиях на основание одной входной информации, а пока картинка модели данных в 3НФ из интернета (Power designer - one love): 

 

Взята с сайта: https://studbooks.net/2018370/informatika/razrabotka_fizicheskoy_modeli_dannyh

Почему нарисованные модели данных спасут мир?

 

Только то что сразу бросается в лицо:

1. “Прочитать” такую модель можно за 5 минут. Я видела огромные модели по + 100 объектов, но это все равно проще чем смотреть эти 100 таблиц в словаре в базе и пытаться понять, что вообще к чему. 

2. Кардинальность связи видна моментально - она всегда играет огромную роль.

3. Модель дисциплинирует с точки зрения Name Convention (правил наименования объектов) - потому что видно ;) 

4. Анализировать глобальные проблемы и перекосы в данных можно на уровне отлова ошибок(когда всем больно) и на уровне логики модели (когда всем видно).  

5. Объяснить бизнес заказчику суть, решить в какой задачи можно использовать, и какие фрагменты нужно распространять обязательно вместе - 100% удобнее имея модель. 

6. Ну и главное! Когда ты смотришь на список из N-ого количества витрин и думаешь, что проще сделать свою заново, чем разобраться есть ли то что тебе нужно в этих витринах -, максимально ценный ресурс, человек который может нормально - русским языком объяснить, что, где и как. Обычно это системный аналитик, и эти люди никогда не сидят без дела.Они решают новые бизнес задачи и очень не любят каждому рассказывать, что там в этой таблице и как ее объединить с другой. Нельзя делать этих людей узким горлышком. 

 

 

Есть ли золотая середина между скоростью разработки и структурированным подходом проектированию?

 

Простой ответ - НЕТ.

От дата людей сейчас действительно требуют очень большой скорости, потому что данные это самый быстро развивающийся актив бизнеса, дающий качественное преимущество. Если он сам качественный :)

 

Пару предложений как эту золотую середину нащупывать

1. Идеальный вариант это автоматизация процессов проектирования и разработки. Модель рисуется и описывается в case средствах, оттуда генерируется код структур физических таблиц и документация по описанию. Код накатывается на среды - все везде совпадает - счастье есть. Правда это не особо работает для hadoop (обожаю, сарказм ;) )
2. Если требования бизнеса растут быстрее чем есть возможность грамотно осмысливать и описывать модель - бейте таблицы на базовые - которые будет переиспользоваться всеми и какие то специфические справочники или агрегаты - для локальных заказчиков и их осмысливайте, проектируете и описывайте с меньшем приоритетом.
3. Если даже на описание базы не хватает ресурсов. Проговаривайте ключевые бизнес драйверы в витрине, т.е. на какие показатели будут смотреть в первую очередь и начинайте с этих блоков данных(кажется простой совет, но ему не так просто следовать, это же нужно заказчику устроить допрос с лампочкой и на 5 раз он сам осознает и  сознается)
4. Если с ресурсом совсем совсем плохо, придумайте простые инструменты - идеально то что можно расшарить на всех участников команды сразу (супер простой пример - таблицы в google docs), чтобы как минимум фиксировать описания таблиц и атрибутов, ключей связей (PK,FK) в связке со схемами БД и физическим наименованиями таблиц. 

успехов нам всем, друзья, ILOVEDATA

Навыки системного аналитика ( аудио и текст тезисами на канале в телеграме ) 

 

Эта публикация для тех 

• кому интересно понять, чем же занимается системный аналитик (на моем опыте) 
• кто возможно ищет себя на стыке технологий и бизнеса (твердая 4 по математике и 5 по литературе) 
• тем кто уже развивает себя в профессиях близких к анализу данных
• кто работает с подбором команды в области data проектов

Для начало кратко про меня - считаю себя именно системным аналитиком ( 6 лет опыта), и только потом идут те роли, которым сейчас посвящаю большую часть своего рабочего времени и развития. Навыки, которые опишу ниже на самом деле помогают в любом деле, но критичны и хорошо развиваются на этой роли.

С точки зрения подбора персонала мой стаж не так велик, пару лет, и около 30-40 собеседований. Далеко не все разы я попадала в точку. Но фокус в сторону найма хочу сделать именно потому, что никогда осознанно не погружалась и действую интуитивно. Полезно составить портрет системного аналитика, которого с удовольствием взяла бы в команду.

 

Мне было сложно остановится, чтобы не описывать идеального солдата и не уходить в банальности типа “ответственность”, поэтому навыков будет всего 7.

 

Перейдем к терминологии - ключевая роль системного аналитика - это мостик между бизнесом и разработчиками. Или по простому “переводчик”. Сейчас идет тренд на то чтобы сам бизнес образовывать в сферу ИТ, но все же - человек который знает многое о финансовом планирование или разбирается в маркетинге, продажах - не обязан знать, что такое data vault. Проекты бывают очень разные, но такие вот переводчики нужны практически везде, иногда они параллельно выполняют функции младшего разработчика, специалиста по визуализации отчетности, хозяина документации проекта,тестировщика и даже прости господи agile коуча. Иногда вообще ведут небольшие активности end  to end так как имеют довольно универсальный профиль ( и jar ничик написать и методологию roi изучить)

 

И наконец переходим к самим навыкам. Разбивать на группы soft и hard skills мне не захотелось. Они будут расположены в порядке применения к жизненному циклу типичной задачи системного аналитика.

1. Growth mindset  - психология роста
2. Умение изучать документацию и гуглить
3. Холодные обзвоны
4. Умение задавать вопросы, слушать и  домысливать за бизнес
5. Знание подходов к моделированию данных
6. Знание языков запросов sql python и пр
7. Отсутствие брезгливости к разной работе

 

 

1. Growth mindset  - психология роста.

Или если просто - отсутствия страха “не знать” и внутренняя готовность узнавать. 

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

Другая сторона -  желание разобраться в процессе подготовки продукта от начала до конца. Зачастую важны миллион деталей: инструмент на котором ведется разработка, особенности ведения документации на стороне источника, список релизов системы, всё что угодно. 

Знать все это по умолчанию  - технически невозможно. Поэтому нужно быть открытым к своему незнанию и не испытывать смущения, сомнений и терзаний.

 

Как развивать Этот навык сидит глубоко внутри. Нужно сбивать свое эго и значимость - всегда напоминать себе - что вы в процессе познания и это абсолютно нормально, даже хорошо. Не спорить ( ох как мне это сложно иногда дается) - принимать факт того, что очень много людей опытнее. Будьте открыты.  Пару лет назад я прочитала книгу, которая в целом сильно повлияла на мое мировосприятие в этой области - называется “Гибкое сознание” Кэрол Дуэк есть еще ролик на Ted Talks. Почитайте или посмотрите обязательно.

Как проверить Спросить что действительно интересно человеку и что он делал, чтобы продвинуться в этой области, пытался ли он как то реализовываться на этом поприще в  прошлых проектах - заодно проверите уровень инициативности.

По ходу встречи в целом люди с Growth mindset будут проще признавать, что они чего-то не знают. У них не будет цели пустить пыль в глаза.

 

2.  Умение изучать документацию и гуглить. 

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

Читать документацию нужно уметь в 2х режимах 

по диагонали, когда вам прислали документ и сказали, что там “всё есть”  лучше быстро просмотреть и сразу вернуть вопросы - если информации недостаточно

глубоко,  когда нужно проработать методологию и даже возможно обратиться к дополнительными открытым источникам ( например , консультант плюс)

Ну и любимая шутка с моим наставником это про то, что я на первом собеседование сказала - “что не знаю”, но могу погуглить. Только вот это совсем не шутка. До сих пор встречаю очень много людей, которые ленятся использовать всемирную сеть для своих вопросов и задают у вас что-то типа “как закрыть задачу в jira” . В каких то ролевых моделях это вполне допустимо - например когда идет речь о времени руководителя - но системный аналитик точно должен уметь сам ответить на этот вопрос.

 

Как проверить  Абсолютно на каждом собеседовании я задаю вопрос про эфемерную задачку - без точной постановки и спрашиваю путь решения проблемы в таких условиях недостаточности. Если в ответе нет вариантов - поискать документацию и погуглить - грущу. И задаю наводящие вопросы.

Как развивать  Этому как раз учат в университете, в целом это академический навык. А потом уже опыт, усидчивость, а иногда помогает страх общаться с людьми. Но в любом случае очень часто ответы на вопросы лежат чуть чуть глубже чем на поверхности и задача системного аналитика без привлечения дополнительных ресурсов со стороны коллег в них разобраться.

Конечно, все хорошо в меру и сидеть над документацией вечность - непозволительная роскошь, поэтому переходим к следующему навыку. 

 

3. Холодные обзвоны(внезапно).

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

Best practice - узнайте какую роль занимает человек, с какого ракурса обычно смотрит на интересующую вас тему. Придумайте заранее как кратко представиться - чтобы было понятно “откуда вы” и  емко  рассказать суть проблемы/вопроса и изложить как он может вам помочь. Нужно быть терпеливым и не быть навязчивым. Сильно напрягает, когда людям которым нужен Ваш совет начинают названивать каждые 2 час. Уважение, терпение и некоторая бойкость. Это грань начинает чувствоваться со временем - особенно когда общаешься с руководством.

 

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

Как развивать Практика и проведение презентаций перед незнакомыми людьми или наоборот можете своим друзьям попробовать рассказывать про работу - собирая обратную связь - что понятно, что нет. 

 

4.Умение задавать вопросы, слушать и домысливать за бизнес.

После того как у вас стабильный контакт с нужным вам человеком - требуется понять язык на котором требуется осуществлять перевод. Для этого нужно задавать разные вопросы и понять уровень компетенций и погруженности человека. Для начала анализа - вопросы могут быть даже слегка философские - а как лучше, а как бы сделали вы, а покажите процесс. Записывайте - чтобы не уточнять второй раз - берегите чужое, а главное свое время. 

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

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

 

Как проверить Попросить предложить 3 решения какой нибудь бизнесовой задачи с данными и посмотреть как человек обработает ситуацию.

Как развивать Быть инициативным, не бояться нечетких задач - видеть и искать в них свое развитие и творчество.

 

5. Знание подходов к моделированию данных. Мне тут на днях человек со схожей на мою должность написал - что витрина это всегда одна таблица. Думала кину в него пару тройку книжек. Теорию нужно знать. И что такое 3НФ и что такое снежинка, звездочка - если нет время на книжки - почитайте статьи - на хабре их десятки.

Кажется на 3 курсе у нас был предмет Базы данных - он шел по субботам по 4  часа в середине дня ( самое время поучиться)  и к нему прилагалась довольно нудная книжка написанная нашим же преподавателем -  Базы данных. Проектирование и создание.  Диго С.М. Вы не представляете сколько раз я засыпала над ней. Правда не смотря на это Базы данных был один из моих любимых предметов. Так вот сколько раз потом смотрела на все эти таблицы в хранилищах в попытках выстроить взаимосвязи - настроить правильно ключи и фильтры в своих запросах, сколько документов пыталась разложить в таблицы и прочее. И научная база - сильно помогала.

Если бы я провела аналогию с чем то бытовым, то например, представим супермаркеты, в которых есть разделы -  бакалея, овощи, фрукты, сыры - и как нам просто искать продукты внутри этих категорий. А вот без азов моделирования,  сразу представляйте себе магазин в котором нет такого разделения и товары просто стоят как хотят,  сколько времени вам потребуется чтобы найти что-то в таком магазине.

И вот этой базы в моем понимание не хватает большинству молодых и  хайповых data scientistов. Я уже не говорю, что именно модель хранилища - критически отражается на скорости расчета и общей производительности системы.

 

Как оценить Идеально если человек не пугается при словах power designer,  erwin, hub и reverse engineering. В целом это уже экспертная часть собеседования - так что зовите старшего системного аналитика. 

Как развивать Читать книжки и пробовать применять в своих задачах. Это история про опыт и научную базу одновременно.

 

6. Знание языков запросов sql, python, можно каких то языков объектно ориентированного программирования.

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

 

Как оценить Ну тут все понятно - на задачах. Но дам совет - любой вопрос про технический навык я начинаю с фразы - оцените свое знание от 1 до 5 и потом уже свожу с моим ощущениями. 

Если вы почитали перед собеседованием список операторов в гугле или пользовались этим 5 лет назад - не притворяйтесь, что знаете язык - человек который знает поймет ваш уровень после первого вопроса. Возвращаясь к 1 скиллу - научиться можно всему, но нужно быть готовым учиться и честным.

Как развивать Мне повезло - я всему  училась на практическом опыте - но курсов в интернете просто огромное количество - бесплатных в том числе.

 

7. Отсутствие брезгливости к разной работе.

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

Меня просто бомбит слышать что то типа - это что мне 2 эксель нужно сверять. На самом деле - у аналитика всегда есть путь - автоматизации процесса и в этом его развитие. Но иногда нужно быстро, ручками и очень муторно -  вы не волнуйтесь это пойдет вам в копилочку понимания и процессов и опыта и доверия от вашего руководства. И иногда механическая работа тоже нужна - переключить мозги в другой режим. Короче, хотите быть эффективным системным аналитиком выкиньте корону “истинного предназначения”.

 

Как проверить Спросить как человек будет решать задачу 

Как развивать Тут нужна глубокая работа с восприятиям себя. Я не равен своей работы. И опять же возвращаемся к 1 скиллу - психология роста - опыт нужен разный и он может стать внезапно полезным.

 

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

 

Хочется еще пару слов сказать про найм.

По паре встреч действительно сложно понять на сколько вы сработаетесь в долгосрочной перспективе - хоть и  внутренняя интуиция конечно - есть. Рекомендации - это очень ценный актив - наш ит мир очень мал и я с 50% вероятностью найду своего друга, который знает про ваши реальные навыки работы. Будьте честны. Искать работу через знакомых - абсолютно нормально и даже очень хорошо. 

Если вы идете без рекомендаций - потратьте время на свое резюме. 

Когда ваш опыт 2-3  года это нормально что вы пишите всё,  где вы пригодились и по максимуму перечисляйте свои скиллы, которые были приобретены еще в университете.

Но когда ты смотришь человека у которого опыт работы 9 лет - и резюме на 5 страниц, для меня этого говорит о том, что человек до сих пор не понимает, что у руководства скорее всего нет времени читать 5 страниц или боится показаться недостаточно значимым, написав о своем опыте чуть скромнее ( влияет на 1 навык). В общем мой совет 1 топс 2 страницы и подстройте под ту должность по которой собеседование, указывайте именно релевантный опыт. А еще попытайтесь для себя сформулировать - что вас привлекает в этом работодателе - прям от души, это всегда плюс! 

 

успехов нам всем, друзья, ILOVEDATA

 

P.S.

Вообще на тему развития своих навыков абсолютно всем советую прочитать про 4 С. Одно из представлений концепции на странице по ссылке. https://www.aeseducation.com/blog/four-cs-21st-century-skills

4 С :

1. Critical thinking
2. Creativity
3. Collaboration
4. Communication

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

 

P.P.S

Кому хочется более четких классификаций и уровня зрелости навыков ( целых 7), более глубокой проработки прикладного подхода, крайне рекомендую   Framework for the Information Age SFIA https://www.sfia-online.org/en/framework/sfia-7/a-to-z-skills-collection

Этому подходу уже более 20 лет. 

Для системного аналитика оттуда я бы выделила: 

• information-analysis
• data-visualisation
• database-repository-design
• research
• systems-design
• user-research

Любой процесс генерирует поток информации, попробую рассказать, как понять какие данные могут принести ценность.
В моем понимание, два подхода:

1. когда сформулирована конкретная проблема, зона роста или цель и есть желание достичь её при помощи данных
2. когда есть какие-то данные и очень хочется их использовать

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

 

Итак, подход первый. Или без хорошего ТЗ, результат ХЗ.

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

Нужно найти того, кто работает непосредственно с процессом, который требует отладки и устроить ему допрос по следующим 6 пунктам:

1. Какие этапы существуют в текущем процессе? (визуализируйте, квадратики на листочке бумаги – отличный вариант)
2. Что\кто является главным объектом? (любимый пример, тех кто занимается данными это – клиент)
3. Какая информация на входе и выходе на каждом этапа процесса? (дорисуйте стрелочки между квадратиками из п.1)
4. К какой информации приходится прибегать в критичных ситуациях? (например, гуглить упоминание инн в судебных делах)
5. Какая дополнительная информация получается если объект проходит по процессу много раз? т.е. какие статистические показатели формируются "сами по себе"?  (например, если клиент приходит каждый месяц, в его действиях есть система и вы можете под неё подстроится)
6. Какая информация доступна об объекте из других источников? (возможно схожие процессы в вашей компании так же работают с этим объектом но по другим вопросам)

Расскажу на нестандартном примере компании Мегафон, которая совместно с Лиза Алерт поставила перед собой цель упростить процесс поиска пропавших людей. Пройдемся по моим вопросам:

1.Какие этапы существуют в текущем процессе?

Человек пропал\Кто-то сообщил о его исчезновение\Начались поиски на местности, рассылка листовок, посты в соц сетях\ (ну и как одна из веток)\ Кто-то узнал сообщил о его местоположение\ Человека нашли.

2.Что\кто является главным объектом? Личность пропавшего, т.е. идентификация, в данном случае, например, номер телефона, фотография.
3.Какая информация на входе и выходе на каждом этапа процесса?

Последнее известное место расположение человека, время пропажи. Всё описывать долго (но я уверена, там масса инсайтов).

4.К какой информации приходится прибегать в критичных ситуациях?

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

5.Какая дополнительная информация получается если объект проходит по процессу много раз?

Надеюсь, люди не пропадают несколько раз. Но в целом в самом процессе формируется много статистики, самые частые места по пропаже людей. (Возможно в них можно установить камеры слежения, системы для зарядок телефона или какие-то «красные кнопки»)

6.Какая информация доступна об объекте из других источников?

Например, соц сети того, кого ищут( по номеру телфона), проверить в последних постах друзей упоминание\фотографии с ним. Проконтактировать лично со всеми, включить их в процесс поиска.

В итоге, при взгляде на процесс через данные возникает много интересных идей. Конечно, вопрос реализации с точки зрения правомерности и стоимости может быть крайне сложным. Но вот появившийся «Мегафон-поиск» вполне реален: сервис анализирует данные и формирует список людей, которые могли бы находиться рядом с человеком в момент пропажи и рассылает им сообщения с фотографией и приметами. Скорость распространения и openrate* при персональной коммуникации увеличивается и повышается вероятность, что нужный человек будет подключен к поиску.

*процент открытых писем

 

Почитать подробнее по Мегафон - поиск можно по ссылке 

Второй подход. Хорошие новости в том, что даже если у вас нет конкретной цели, сами данные могут вас вдохновить.  

Для этого нужно:

• 1 шаг Оценить и структурировать ваш актив данных.
• 2 шаг Изучить в глобальной сети интернет как работают с данными более крупные компании вашей сфере.

Со вторым шагом понятно, а по первому шагу, поняла, что нужно написать отдельную статью. 

В паре слов, оценить - это составить полный перечень того, какие документы вы используете в работе сейчас, какую отчетность готовите для органов контроля ( ЦБ, ФНС), какую информацию регулярно мониторите в сети.

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

 

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

 

Что делать дальше, если хотите начать более плотно работать с данными? 

 

Возможно, вопрос моего знакомого был как раз в сторону, что делать дальше, вкладывать ли деньги в оцифровку бизнеса и привлечения дополнительных источников информации? Вариантов реализации много и есть просто копеечные, поэтому мой ответ - вкладывать!  Для оценки стоимости и выбора решения, первое что нужно сделать - понять масштаб. Т.е. сколько новых данных приходит вам ежедневно? Если это 10 клиентов в день - не нужно смотреть в сторону хранилища, хватит даже самой банальной базы acess из пакета microsoft :). Например, уже одна корректная и своевременная обработка и системная загрузка данных в единое место, может ускорить формирования отчетности. 

 

успехов нам всем, друзья, ILOVEDATA

 

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

 

(1) Данные. Если просто мы с командой  работаем с данными, обрабатываем, поставляем, объедением и разъединяем, фильтруем, суммируем, валидируем и прочие удовольствия. Ассоциации с АС Excel в вашей голове не случайны, это наш прямой конкурент :)

(2) Объем. Excel имеет ограничение по скорости обработки на больших объемах данных, типам хранимой информации, вариантам и простоте выполнения преобразований. Место в хранилищах меряют не в гигабайтах, а в тысячах гигабайт. Традиционно, производители хранилищ, поставляют аппаратную часть - "железо", вместе с программный обеспечением, которое позволяет оптимально на этих вычислительных мощностях распределять объемы и осуществлять расчеты. В последние пять лет идет тренд на использование облачных сервисов и открытого кода. Каждый из нас теперь может развернуть себе кластер Hadoop, за несколько баксов. Иногда в светской беседе о работе помогает перечислить названия вендоров, например, oracle, teradata. Но в целом живем на рынке универсальных солдат, готовых разрабатывать на любом ПО,  адаптироваться под особенности и ограничения различных DWH. Вернемся к контенту. 

 

(3) Удобство для аналитических задач и историчность. Практически любое хранение подразумевает предварительное структурирование, комплектацию, отсеивание с какой то целью. Представьте обычный склад - там логисты продумывают как им расположить товары, какие маркеры расставить, какой ассортимент более ходовой и пойдет на отправку вначале. Порядка 50 лет назад, на стадии зарождения, ключевая идея хранилища, была в том, чтобы на берегу договориться, как положить данные так - чтобы их удобно было извлекать для решения десятков различных аналитических задач, т.е. с ориентацией не на то как данные появляются, на то на какие вопросы отвечают. В отличие от реальных продуктов, срок годности данных дольше, поэтому столпы хранилища - это правила историчности и обеспечение неизменности с течением времени. В эру неструктурированной информации (поведение на сайтах, видео, аудио)  изначальная задумка хранилищ приобретает другой оттенок. Сейчас уже абсолютно не зазорно сначала загрузить, а потом осмыслить. Это связано с тем, что сама по себе информация становится сложнее и оценить её полезность и применимость можно только объединив с другими данными и попробовав в бою.

  Итак, у меня наконец есть, ответ на вопрос кем же я работаю? Координирую команду и процессы (5) в проектах по обработке и интеграцией большого объема(2) данных(1) из различных систем компании(4) в единую область с целью извлечениям из данных пользы для аналитических задач(3).

 

успехов нам всем, друзья, ILOVEDATA

 

dwh - data warehouse

Всем привет, меня зовут Елена, и с 2012 года я работаю с области DWH. Чуть меньше месяца назад задумалась о том, что хочется структурировать багаж знаний и сохранить его не только в виде пунктов резюме, но и виде материалов, которые могут помочь коллегам по цеху и\или молодому поколению.

 

Постараюсь писать профессионально, но с юмором и душой. Это волнительно! Ведь я не знаю, какая у меня целевая аудитория и списка тем на ближайшие 2 года тоже нет. Но есть вдохновляющая любимая работа. 

 

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

 

Планирую вести канал в telegram и возможно чуть более структурированно дублировать информацию здесь. 

 

успехов нам всем, друзья, ILOVEDATA