#easy

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

При этом на создание такой атмосферы влияют 4 фактора:
1) Люди
2) Процессы
3) Структура
4) Единые взгляды и ценности

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

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

P.S. Кстати, в названии "Идеальный руководитель" есть ирония. Так как сам Ицхак потом приводит веские аргументы, что идеальных руководителей не существует.

#easy

Итак, 1-й фактор эффективности (эффективность = взаимное доверие и уважение) - это Люди.

Но прежде чем рассказывать о hard-skills и soft-skills, которыми должны обладать конкретные специалисты по данным, я хочу рассказать о позициях, которые могут встречаться в data-team. Я выделяю такие основные позиции:

Web-аналитик - один из тех людей, кто занимается первичным сбором данных. Под первичным сбором данных я подразумеваю сбор данных на уровне источников, т.е. это не построение ETL-процессов и data-пайплайнов. Главная задача web-аналитика - собрать данные о поведении пользователей на сайте и в мобильном приложении в системы web/app аналитики, такие как Google Analytics, Яндекс Метрика, Firebase Analytics, AppsFlyer и др. Они собирают данные о том, с каких источников трафика приходят пользователи на сайт или в мобильное приложение, какие страницы они посещают, на какие кнопки нажимают, какие товары покупают в интернет-магазине и т.д. Часто web-аналитики выступают в роли продуктовых аналитиков - они анализируют данные в системах web/app аналитики, строят гипотезы по улучшению эффективности сайта или приложения как продукта, делают A/B-тесты.

Data Engineer (инженер данных) - человек, который отвечает за построение надёжных и масштабируемых ETL-процессов и data-пайплайнов. Его главная задача - извлечь данные из источников, преобразовать данные в пригодный для анализа и data science вид и загрузить их в хранилище данных (Data Warehouse) или озеро данных (Data Lake).

BI Engineer (BI-разработчик) - человек, который отвечает за проектирование и создание отчётности в BI-инструменте (Power BI, Tableau и т.д.). Его главная задача - сделать так, чтобы бизнес-пользователям было удобно пользоваться отчётами и дашбордами, они могли находить инсайты в данных и принимать решения. BI-разработчики более высокого уровня могут не ограничиваться только проектированием и созданием BI-решений. Они также анализируют уже созданные отчёты, находят инсайты, строят гипотезы и предоставляют рекомендации бизнесу.

Data Analyst (аналитик данных) - человек, который анализирует данные (часто, уже подготовленные инженерами данных). Его главная задача - находить инсайты и предоставлять рекомендации бизнесу. В отличие от BI-разработчика он использует более продвинутые методы и инструменты анализа, такие как SQL, Python или R. Аналитики данных более высокого уровня применяют знания статистики и строят простые модели для Machine Learning. Часто Data-аналитики выступают в роли продуктовых аналитиков.

Product Analyst (продуктовый аналитик) - человек, основная задача которого - находить инсайты в данных, строить гипотезы и предоставлять рекомендации по улучшению продукта. Под продуктом подразумевается IT-продукт, т.е. сайт, мобильное приложение, web-приложение и т.д. Продуктовые аналитики используют в своём арсенале инструменты web/app аналитики, SQL, Python/R и сервисы для A/B тестирования (например, Google Optimize).

Data Scientist - человек, который строит модели Machine Learning, Deep Learning и занимается предиктивной аналитикой. Главная его задача - находить закономерности в данных благодаря построенным ML/DL моделям и помогать бизнесу находить скрытые точки роста.

Очень часто один человек может исполнять несколько ролей. Всё зависит от типа компании, её размера, орг. структуры и конкретного проекта. Я, например, выполняю задачи web-аналитика, инженера данных и BI-разработчика)

P.S. Думаю, пост будет очень полезен новичкам, кто ещё не определился с выбором профессии. Возможно, в этих описаниях вы найдёте своё призвание:)

#easy

Вот видео с выступления Алексея Натёкина. Видео довольно старое, но не потерявшее актуальности. Думаю, многие опытные ребята его видели. Здесь Алексей как раз рассказывает про разницу между инженерами данных, аналитиками данных и Data Scientists.

P.S. На сегодня всё. Надеюсь, было полезно. А я пошёл хардкодить на Python.

Спасибо моему хорошему другу @sasha_borysenko за классный логотип!

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

Короче, я считаю, получилось круто! Саня, спасибо!:)

Как вам новый логотип?

#easy

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

Сегодня поговорим о soft-skills, личных качествах, которыми, на мой взгляд, должен обладать каждый специалист вне зависимости от его позиции.

Вот мои ТОП-5 качеств:

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

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

3) Умение работать в команде. Компания - это единый организм, её подразделения - внутренние органы, а люди, которые в ней работают - клетки. Если на уровне клеток процессы функционируют неправильно, это отражается на работе внутренних органов. Из-за этого страдает весь организм. Думаю, аллегория понятна.

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

5) Любознательность (горящие глаза). Это то, что позволяет вам расти и расти быстро, потому что вы постоянно узнаёте что-то новое, прокачиваете свои навыки, стремитесь применять best practices. Любой руководитель будет ценить таких работников и поощрять.


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

Сейчас технологии развиваются по спирали. Постоянно появляются какие-то новые продукты, инновации и всё очень быстро меняется. То, что вы изучаете сейчас, может быть неактуально через 5 лет и именно личные качества помогут быстро адаптироваться к изменившейся ситуации. И эти soft-skills будут актуальны долгое время.

P.S. Это только моё субъективное мнение. Вы можете быть не согласны и аргументировать свою точку зрения)Помним про критическое мышление

#easy

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

Вот Amazon Leadership Principles. Советую прочитать и узнать, на что обращают внимание флагманы IT-индустрии.

P.S. Завтра сделаю обзор hard-скиллов

#easy

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

Итак, я на самом деле выделяю 2 общих обязательных навыка, которые не зависят от конкретной роли в команде. Это:

1) Знание SQL. Сейчас практически все специалисты по данным, вне зависимости от занимаемой позиции, используют SQL в своей работе. SQL используется во всех или почти во всех задачах: трансформации внутри хранилища данных мы делаем на SQL, запросы в Data Lake мы пишем на SQL, для подготовки отчётности BI-разработчики используют SQL. Даже когда мы извлекаем данные из OLTP и хотим их загрузить в DWH мы можем использовать SQL (например, с помощью Python-библиотеки SQL Alchemy). Может возникнуть логичный вопрос: на каком уровне его нужно знать? Отвечу так: на уровне решения бизнес-задач. Т.е. не когда мы просто решаем задачки в "песочнице", а когда мы можем эти знания применить для решения конкретного бизнес-кейса. Если говорить за синтаксис языка, то для базового уровня нужно знать: DDL, простейший синтаксис (SELECT, FROM, WHERE, ORDER BY, LIMIT, OFFSET), объединение таблиц (JOIN), группировку (GROUP BY) и агрегатные функции, подзапросы (EXISTS, IN, SELECT FROM SELECT, CTE), простые функции для работы с числами, строками и датами. Если знаете, как использовать регулярные выражения при работе со строками и применяете оконные функции, то круто!

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


Теперь в разрезе отдельных позиций:

Web-аналитик:
Базовые навыки:
1) Навыки работы с Google Analytics (Universal Analytics и Google Analytics 4): настройка аккаунта/ресурса/представления, настройка целей и фильтров, настройка простой и расширенной электронной торговли, применение фильтров и сегментов в отчётах
2) Навыки работы с Яндекс Метрикой (для российского рынка): практически тоже самое, что и в Google Analytics
3) Навыки работы с Google Tag Manager: настройка и создание переменных, триггеров, тегов, настройка передачи событий в системы аналитики и рекламные сервисы, понимание принципа работы dataLayer (уровня данных), настройка электронной торговли, междоменного отслеживания
4) Навыки работы с сервисами мобильной аналитики (Firebase Analytics, AppsFlyer, Amplitude, Adjust и др.)
5) Навыки работы с сервисами визуализации данных (Google Data Studio, Power BI/Tableau)

Продвинутые навыки:
5) Навыки работы с Google Optimize
4) Знание SQL
5) Навыки работы с Google BigQuery / Clickhouse в качестве аналитического хранилища данных
6) Знание Python/R (как плюс)

Data Engineer:
1) Понимание принципов SQL и NoSQL баз данных
2) Знание SQL: DDL и DML (INSERT, SELECT и т.д.)
3) Навыки работы хотя бы с одним ETL-инструментом: Pentaho Data Integration, Matillion ETL, Fivetran, Amazon Glue, Azure Data Factory, Google Cloud Dataflow
4) Базовые знания системного и сетевого администрирования: знание командной строки (Bash/PowerShell), умение самостоятельно запустить виртуальную машину в облаке, понимание архитектуры "клиент-сервер", знание основных протоколов верхнего уровня (HTTP/HTTPS, FTP/FTPS, SFTP)
5) Знание скриптового языка программирования (Python/Java/Scala). Python наиболее популярный язык за счёт его простоты синтаксиса. Здесь, как и с SQL, язык нужно знать на уровне решения бизнес-задач. Т.е. если вы умеете самостоятельно писать ETL-скрипты, это говорит о достаточном уровне владения.
6) Навыки работы с фреймворками для оркестрации data-пайплайнов (Airflow/Luigi)
7) Умение работать с Big Data продуктами (Hadoop, Spark): если вы работаете с on-premise решениями, нужно знать как настроить и развернуть Hadoop/Spark и уметь использовать их для ETL. Если вы работаете с облачными технологиями, то провайдеры предоставляют serverless-решения для Hadoop и Spark. Например, вы можете в несколько кликов запустить Amazon EMR, Cloud Dataproc или Databricks и сразу писать там PySpark. Для облачных сервисов Hadoop и Spark нужно понимать на уровне концепций.
8) Навыки построения DWH и Data Lake
9) Понимание моделей данных (dimensional modelling, 3NF, data vault)
10) Навыки работы с сервисами для стриминга данных (Kafka, Amazon Kinesis, Google Cloud Pub/Sub и т.д.)
11) Знание принципов облачных вычислений и опыт работы хотя бы с одним облачным провайдером (AWS/GCP/Azure)
12) Знания DevOps, DataOps, MLOps (для самых-самых хардкорных)

P.S. Продолжение завтра

Судя по комментариям, вчерашние посты выглядят немного устрашающими, мол "как это всё возможно выучить?"

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

Я намеренно не выделял навыки по грейдам, так как требуемый набор скиллов сильно зависит от уровня компании, её технической культуры (какой стек технологий используется) и конкретных проектов. В одной компании вы со своим набором навыков можете быть senior, а другая компания оценит ваши навыки на strong-junior.

Поэтому, не пугайтесь, двигайтесь небольшими шагами, но регулярно развивайтесь.

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

#easy

Всем привет. Продолжаю писать про hard-skills, которыми должны обладать специалисты по данным. В прошлых постах я описал навыки для специалистов вне зависимости от позиции, для web-аналитика и инженера данных. Сегодня я опишу навыки для BI-разработчика, аналитика данных, продуктового аналитика и data scientist.

Итак,

BI Engineer:
1) Углублённые знания хотя бы одного BI-инструмента (как правило, Power BI, Tableau)
2) Базовые знания баз данных
3) Знание SQL
4) Навыки установки и администрирования BI-сервера: Power BI Report Server, Tableau Server или др.
5) Понимание параметров и показателей предметной области (маркетинг, продажи, финансы и т.д.)
6) Навыки анализа данных (сегментирование, контекст)

Data Analyst:
1) Знание предметной области. Если вы не понимаете основные концепции предмета вашего анализа, вы просто не сможете строить разумные гипотезы и предоставлять рекомендации бизнесу. Т.е. если вы работаете аналитиком данных в маркетинге, вы должны понимать базовые концепции маркетинга: что есть рынок продавцов и рынок покупателей, есть различные каналы привлечения трафика на сайт, есть такие метрики, как CPC, CPA, CPL, AOV, CAC, ROAS, LTV и т.д.
2) Знания Excel/Google Spreadsheets. Многие думают, что Excel - прошлый век, и кричат что-то типа "Вы что, Excel используете, вы серьёзно???" Но скажу по своему опыту: обычный Excel меня не раз спасал, когда мне нужно было быстро сделать какой-то ad-hoc отчёт или нужно было собрать статистику с разных аккаунтов Google Analytics, при этом применяя различные фильтры. Я понимал, что на автоматизацию может уйти больше времени, чем я просто вручную внесу цифры в таблички и построю базовые графики. Так что, не нужно категорично относиться только потому, что у него нет модных слов "databricks", "data platform" и т.д. Я во многих вакансиях встречал Excel как обязательное требование для всех аналитиков.
2) SQL - преимущественно DML
3) Python или R. Про R знаю плохо. Если собираетесь использовать Python, то нужно знать базовый синтаксис, уметь работать с различными типами файлов (CSV, Excel, JSON, XML), уметь подключаться к базе данных и импортировать данные себе в среду, владеть библиотеками Pandas и Numpy, владеть библиотеками для визуализации данных (Matplotlib, Plotly, Seaborn)
4) Знание статистики: описательные статистики, математическая статистика, тестирование гипотез, регрессия
5) Базовые знания Machine Learning: feature engineering, линейная и логистическая регрессия, k-means, matrix factorization, ARMA, ARIMA (для продвинутых специалистов)

Product Analyst:
1) Понимать основные метрики продукта: ARPU, ARPC, Retention Rate, Churn Rate, LTV и т.д.
2) Владеть основными фреймворками для продуктовой аналитики: когортный анализ, RFM-анализ и др.
3) Иметь навыки работы с Google Analytics и Google Tag Manager
4) Иметь навыки работы с сервисами аналитики для мобильных приложений: Flurry, Mixpanel и др.
5) Уметь проводить А/Б-тестирования и владеть инструментами для их проведения (Google Optimize, Arise и др.)
6) Знание SQL
7) Python или R
8) Знание статистики - преимущественно тестирование гипотез (p-value и всё такое)

Data Scientist:
1) Знание баз данных и SQL
2) Знание Python (базовый синтаксис, библиотеки Pandas, Numpy, Matplotlib, Plotly)
3) Знание основ Linux
4) Знание алгоритмов и структур данных
5) Углублённые знания статистики
6) Знания линейной алгебры
7) Знание основных алгоритмов машинного обучения (линейная и логистическая регрессия, k-means, matrix factorization, дерево решений, нейронные сети)
8) Знание Deep Learning

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

Вот мы и разобрали по полочкам первый фактор эффективности работы компании в целом и data-команды в частности - Люди

Мы разобрали, какие есть роли в data-team и какими soft-навыками и hard-навыками должны обладать эти специалисты, чтобы эффективно работать с данными.

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


Как вам такой последовательный формат постов?

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

Вчерашняя презентация для студентов.

#easy

Начинаем нашу серию постов о втором факторе эффективности работы data-team и организации в целом - о процессах.

И сегодня я хочу разобрать "пирамиду потребностей Data Science".

Главная идея этого концепта позаимствована из пирамиды потребностей человека, которую разработал известный психолог Абрахам Маслоу. Пирамида Маслоу состоит из нескольких уровней иерархии:

1) Физиологические потребности: потребность в пище, воде, тепле и отдыхе
2) Потребность в безопасности
3) Потребность в принадлежности к обществу и в любви: романтические отношения, дружеские отношения
4) Потребность в уважении и почтении
5) Потребность в развитии потенциала и потребность в творчестве

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

Теперь давайте переложим эту идею на работу с данными. Здесь есть 6 уровней иерархии:

1) Collect - сбор данных на уровне источников. Например, сбор данных о поведении пользователей на сайте или в мобильном приложении в системы web/app аналитики, поддержка транзакционной базы данных, которая обслуживает back-end интернет-магазина и в которую записываются данные об оформленных заказах на сайте. Это также учёт лидов и сделок в CRM-системе и т.д. За этот уровень у нас отвечают веб-аналитики, back-end разработчики, администраторы баз данных и люди, которые отвечают за администрирование CRM-системы. Это первый и самый базовый уровень иерархии, так как если вы будете собирать данные на уровне источников некорректно и не в полном объёме, то в последующих ETL, анализе и data science просто нет смысла. Вы будете принимать неверные решения, а качество моделей будет очень низким.
2) Move/Store - построение ETL, data-пайплайнов, DWH/Data Lake. Когда у нас налажен сбор данных на уровне источников и данные собираются в полном объёме, мы можем переходить к построению хранилища данных или озера данных и выстраивать data-пайплайны и ETL-процессы. Здесь к работе подключаются инженеры данных. Это 2-й уровень иерархии, который отвечает за надёжные и масштабируемые потоки данных и безопасное хранение данных. Без этого вы так же можете получать данные несвоевременно и не в полном объёме, из-за чего дальнейшая аналитика и принятие решений лишены смысла.
3) Explore/Transform - очистка данных и их подготовка к дальнейшему анализу. Когда мы удовлетворили потребность в надёжных потоках данных и их безопасном хранении, мы приступаем к их подготовке для анализа. Эту задачу могут выполнять аналитики данных и инженеры данных. Здесь мы работаем с пропущенными значениями, с типами данных, чтобы потом эту информацию можно было агрегировать и анализировать. Без этого уровня процесс анализа будет сложным и непродуктивным.
4) Aggregate/Label - объединение данных, расчёт нужных метрик, построение BI, сегментация, feature engineering и обучение данных. Когда мы очистили и подготовили данные, мы можем приступать к непосредственному процессу анализа и построению BI-решений. Здесь мы ещё не накручиваем сложные ML/DL/AI алгоритмы. Наша задача - найти инсайты в исторических данных и подготовить данные для построения Data Science моделей. Без этого уровня невозможно построить качественную модель и выводить её в production.
5) Learn/Optimize - A/B тестирование, эксперименты, построение простых ML-моделей, оптимизация моделей. Так что, можно, наконец, строить космолёт? Если вы хотите просто построить модель оттока клиентов - то можно начинать делать простые алгоритмы (например, модель классификации). Если вы хотите сделать рекомендательную систему товаров на сайте, то прежде чем строить модель и выводить её в prod, нужно убедиться, что показываются действительно подходящие товары. Для этого мы, опираясь на обученные данные, делаем A/B тесты на сайте и убеждаемся, что товары действительно нужны людям, и они их покупают. На этом этапе мы также дополняем данные новыми фичами для повышения качества моделей. И уже после этого используем алгоритм и выводим в продакшн.
6) AI и Deep Learning. И, наконец, если мы убедились, что ML работает для нашего бизнеса и приносит деньги, мы можем разрабатывать более сложные алгоритмы и запихнуть нитро в нашу бизнес-машину:)

Я описал, как должен быть выстроен процесс работы с данными. Но не нужно впадать в крайность и, например, доводить инфраструктуру до идеала, вместо того, чтобы анализировать данные и принимать решения на достаточно рабочем прототипе. Здесь полезно применять Agile-подход, главной задачей которого является ускорение разработки продукта. Т.е. нам сначала нужно масштабировать систему вертикально и создать MVP (minimal viable product), потому что пока вы будете доводить до идеала инфраструктуру, конкуренты будут принимать решения и занимать прочную позицию на рынке.
После того, как вы создали MVP, вы можете масштабировать его горизонтально, т.е. латать слабые места в системе и добавлять новые фичи в ваше решение.

#easy

Всем привет.

Продолжаем нашу серию постов о процессах. Я хочу рассказать про философии и методологии ведения проектов. Думаю, многие слышали такие слова как Agile, Waterfall, Scrum и Kanban. А для некоторых это не просто слова, и они с этим сталкиваются ежедневно на своей работе. Вот про это и поговорим.

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

Сегодня начнём с Agile и Waterfall.

Agile (гибкий) - философия ведения проектов, которая была разработана 17 разработчиками ПО. Её главная задача - ускорение разработки программного обеспечения.

Главные принципы Agile:
- удовлетворение потребностей клиентов за счёт быстрой и непрерывной поставки программного обеспечения;
- гибкость в меняющихся требованиях даже на поздних стадиях разработки, постоянное получение фидбека от конечных пользователей продукта и заинтересованных лиц;
- акцент на живом общении внутри команды и экспертизе каждого из её членов. Больше акцент на людях, а не жёстко регламентированных процессах;
- доверие к команде разработки и обеспечение свободы действия;
- итеративный подход к разработке - внедрение новых фич происходит циклами. Для итераций используется понятие "спринт".

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

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

Как происходит процесс разработки при использовании Agile-подхода:
Во-первых, у нас есть несколько ролей:
1) Product Owner (владелец продукта) - это человек, который не обладает глубокими техническими знаниями, но обладает общим видением продукта: для чего мы его делаем и каким он должен быть.
2) Stakeholders (заинтересованные лица) - все те, кто будет пользоваться этим продуктом или как-то в нём заинтересованы.
3) Development Team (команда разработки) - непосредственно те, кто будут технически реализовывать разработку и поставку продукта.

Во-вторых, у нас есть несколько последовательных этапов в каждой итерации (спринте):
1) Requirements - здесь заинтересованные лица предлагают свои идеи по продукту и его улучшению, а владелец продукта помогает сконвертировать эти идеи в готовые требования. Этот этап характеризуется большим количеством митингов и обсуждений.
2) Plan - на этом этапе требования разбиваются на более мелкие части работы (фичи). Для этих фич выставляется приоритетность и пополняется backlog.
3) Design - здесь, как понятно из названия, мы подготавливаем дизайн решения и разрабатываем стратегию тестирования.
4) Develop - непосредственный процесс создания и улучшения продукта.
5) Testing - этап тестирования, на котором проверяется, удовлетворяет ли продукт потребностям пользователей, есть ли баги и т.д.
6) Deployment - этап развёртывания решения в production.
После всех этапов цикл повторяется снова.

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


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

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

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

Недостатки Waterfall:
- высокая чувствительность к изменениям. В отличие от Agile, если, например, на этапе тестирования обнаружится, что какую-то фичу не учли ещё на этапе сбора требований, возвращение к первому этапу может повлечь большие финансовые потери;
- заказчик увидит рабочий продукт только на конечных стадиях разработки. Т.е., в отличие от Agile, где мы можем быстро собрать MVP (minimal viable product) и предоставить его заказчику для использования, при Waterfall заказчику придётся ждать последних стадий разработки. К тому времени, продукт может потерять актуальность и так и не принесёт ценности;
- требует чётко определённых требований от заказчика и других заинтересованных лиц. Если эти люди не смогут заранее определить чёткие требования к продукту, то есть высокий риск, что всю разработку придётся начинать заново.

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

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


Ок, много теории. Приведу пару примеров, когда мы можем использовать Agile, а когда Waterfall при работе с данными.

Давайте представим, что мы, например, специализируемся на построении end-to-end BI-решений для маркетинга. В частности, для интернет-магазинов (e-commerce). Мы заранее можем определить, какие данные и в каких срезах хочет видеть заказчик в будущих дашбордах, так как потенциальный набор отчётов для e-commerce не такой большой. +мы не раз строили такое решение для других клиентов. В этом случае нам отлично подойдёт Waterfall.

Теперь давайте представим, что мы вместе с командой разработки работаем над созданием продукта на базе Machine Learning. Мы не можем заранее определить все фичи, которые в нём будут, понимание будет происходить уже в процессе разработки. В таком случае нам лучше использовать Agile-методологию.

Также есть гибридные модели, такие как Agifall или WAgile. Мы в Promodo, например, при разработке end-to-end решений используем методологию близкую к Agifall. Так как мы специализируемся на решениях для маркетинга и у нас уже есть готовые кейсы по созданию таких решений, за основу взята методология Waterfall. Но для ускорения разработки мы можем частично переходить к следующим этапам, не завершив полностью предыдущий. Такое происходит, например, когда мы понимаем, что в одном источнике данные уже корректно собираются, и мы можем уже загружать эти данные в DWH.

P.S. Следующий пост будет посвящён популярным Agile-фреймворкам - SCRUM и Kanban.

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