1. Инициирование и планирование проекта
   1. Проекты в общем: Инициирование и планирование проекта
      1. Сбор и анализ информации об исходном положении проекта
         1. Анализ исходной ситуации должен проводится еще до начала проекта, но и в ходе инициирования и планирования проекта сбор и анализ информации продолжается
            1. данные о рынке, потребностях, технологиях, партнерах и конкурентах, ограничениях проекта, включая доступность ресурсов, и др.
         2. Понять
            1. насколько проект реально востребован и реализуем
         3. Инструменты и компетенции
            1. сбор и анализ данных
            2. анализ заинтересованных сторон
            3. дизайн мышление
      2. Определение (уточнение) целей и показателей успеха проекта
         1. Цель - образ желаемого будущего
            1. Цель проекта должна определять, те положительные изменения, ради которых делается проект
            2. Для обеспечения мониторинга достижения целей формулируются показатели успеха проекта, за которые несут ответственность руководитель проекта и члены команды
            3. Цели проекта отражают интересы ключевых заинтересованных сторон проекта и в первую очередь заказчика, но руководитель проекта (РП) должен цели принять и при необходимости уточнить.
         2. Инструменты и комтенции
            1. дерево целей
            2. SMART
      3. Разработка возможных способов достижения целей
         1. Часто цели проекта могут быть достигнуты разными способами или с применением разных решений
            1. приобретение готовых продуктов (активов), усиление существующих или создание нового продукта (актива) своими силами и т.п.
         2. Прежде чем переходить к детальному планированию, необходимо проанализировать альтернативные варианты решений
         3. Инструменты и комтенции
            1. дизайн мышление
            2. системная инженерия
      4. Определение выгод и возможных рисков каждого способа достижения целей
         1. Необходимо оценить альтернативные способы достижения целей
            1. оценка преимуществ и возможных негативных последствий каждого каждого способа (решения)
         2. Инструменты и компетенции
            1. анализ альтернатив
            2. системный анализ
            3. SWOT
            4. взаимодействие с заинтересованными сторонами
            5. привлечение экспертов
      5. Выбор основного способа достижения целей- проектного решения
         1. Инструменты и компетенции
            1. разработка и утверждение основных решений (концетциы проекта)
      6. Определение функциональных областей и видов работ, необходимых для реализации проекта
         1. Понимание решения (продукта проекта и его составных частей) позволяет определить масштаб и основные виды работ, которые надо будет планировать и реализовывать
            1. Позволяет оценить сложность проекта, области неопределенности и рисков, требования к опыту и компетентности команды проекта и привлекаемых экспертов
         2. Инструменты и компетенции
            1. иерархическая структура продукта проекта
            2. иерархическая структура работ проекта
            3. модель компетенний проекта
      7. Определение стратегии реализации проекта (ЖЦ, подходы к реализации, приоритеты и последовательность получения основных результатов)
         1. Стратегия реализации проекта - это укрупненный план, определяющий основные этапы, точки контроля и принятия решений по проекту
            1. Стратегия реализации проекта учитывает, как содержание проекта, так и условия реализации проекта (наличие ресурсов, факторы окружения проекта, наличие приоритеты и поддержки или сопротивления изменениям)
         2. Инструменты и компетенции
            1. жц проекта
            2. процессы управления проектом
            3. план по контрольным точкам
      8. Определение требований к составу и компетентности участников команды управления проектом
         1. уточнить полномочия и ответственность ключевых участников участников команды управления проектом
            1. формирование команды управления
         2. Инструменты и компетенции
            1. роли в команде проекта
            2. отвестственность и полномочия
            3. организационная структура проекта
            4. матрица отвественности
      9. Формирование и утверждение организационной структуры управления проектом, основных требований к управлению и реализации проекта
         1. фиксируются ранее принятые решения о целях и содержании проекта, а также принципы реализации и управления проектом
            1. Формируется и утверждается команда управления проектом, распределение ответственности и полномочий
         2. Инструменты и компетенции
            1. Устав (паспорт) проекта
      10. Детализации состава работ проекта, разработка общего и детальных календарных планов
          1. Инструменты и компетенции
             1. иерархическая структура работ проекта
             2. календарный план
          2. Кто участвует
             1. РП
             2. ключевые коллеги команды управления
             3. ответственные исполнители
             4. эксперты
      11. Определение потребностей в ресурсах ( включая бюджет, мощности, поставки и тд) по работам проекта и по проекту в целом
          1. Когда план проекта детализирован до отдельных задач (работ), можно провести ощенку потребности каждой отдельной работы (задачи, пакета работ) в ресурсах
             1. Оценка трудоемкости и потребностей проекта в ресурсах гораздо точнее, если привязаны к конкретным работам и выполнены с участием специалистов
          2. Инструменты и компетенции
             1. оценка потребности работ в ресурсах
             2. смета
             3. бюджет
             4. план обеспеченыя проекта ресурсами
      12. Разработка плана реагирования на риски. Доработка плана реализации проекта с учетом рисков
          1. План управления рискамия является частью сводного плана проекта, а такие элементы плана, как календарный план, бюджет, план привлечения ресурсов необходимо доработать с учетом плана утравления рисками
          2. Инструменты и компетенции
             1. выявление и анализ рисков
             2. план управления рисками
   2. МЛ
      1. Шаги
         1. Выбрать удобный и подходящий инструмент в качестве
         2. Создать репозиторий документов и сделать его доступным для команды
            1. Версионирование
            2. Docs-as-code
         3. Создать реестр рисков
            1. аналог
            2. LeanDS (Questions)
            3. Риск-Вопрос для изучения- действие по устранению
         4. Создать организационную модель клиента
            1. карта стейкхолдеров
            2. орг единицы
            3. ЛПУ
            4. ключевые лица (бюджетирование, визирование, IT-безопасность и тд
            5. бизнес-приоритеты
            6. кто клиент, а кто заказчик
            7. карта бизнес-процессов
            8. понимание того, как сейчас работает заказчик- увеличивает шансы на успех
            9. адаптация бизнес-процессов. Что необходимо?
            10. Своевременность проекта. (Не опережаем ли мы события? Не действуем ли слишком поздно?).
            11. Организация проекта. (Как будет реализовываться проект? Кто участники рабочей группы? Как мы будем их мотивировать?).
            12. Необходимость и достаточность. (Можно обойтись наименьшими усилиями? Бизнес-процесс – это не просто, не дешево и не быстро).
            13. Техническое задание. (Как правильно оформить ТЗ для оптимизации комплекса критичных бизнес-процессов через карту целей).
            14. основные поинты
            15. как и кем и когда будет финансироваться проект
            16. PandL
            17. какая организационная структура у компании-клиента
            18. зачем клиенту этот проект
            19. - какая IT-архитектура есть у клиента
         5. Проанализировать архитектуру системы клиента и функциональные/нефункциональные ограничения
            1. Функциональные
            2. что будет делать система, какая её функция, какую задачу будет решать, какие требования по метрикам?
            3. Нефункциональные
            4. скорость работы (throughput и latency), стоимость функционирования (железо и поддержка)
            5. Системные требования
            6. какая инфраструктура нужна, с какими системами нужно интегрироваться
         6. Получить пример данных
            1. отразить характеристики: статистические, нефункциональные (размер, скорость, история) и системные (где лежат данные)
            2. Анализ данных
            3. мало
            4. грязные
            5. сложно получаемые
            6. Понять возможность реализации фич
         7. Задокументировать требования по безопасности и приватности
            1. этический аудит проекта - кого он затронет, какие есть потенциальные негативные последствия
            2. юридические аспекты
         8. Разработать высокоуровневую архитектуру решения
            1. согласовать ее со стейкхолдерами
            2. получить ответы на вопросы:
            3. DEV: есть ли достаточно ресурсов на дев-среду, доступны ли в ней данные, какие мы будем использовать инструменты для разработки
            4. Prod: основные компоненты системы, как деплоить систему, как предоставлять досуп к компонентам
         9. Сформировать общее понимание бизнес-проблемы, свалидированное клиентом и командой проекта
            1. Питч
         10. Осуществить проверку (dilligence) проекта
             1. будут ли доступны стейкхолдеры и данные?
             2. Кто из членов команды доступен, какие у них компетенции?
             3. Найти ответы на вопросы
             4. Техническая осуществимость проекта - есть ли данные, инфраструктура, решалась ли уже проблема кем-то ещё
             5. Понятный бизнес-кейс и поддерживающие его стейкхолдеры
             6. Коммерческая осуществимость - есть ли ресурсы на проект?
         11. Оценить работы по проекту с учётом доступной команды, масштаба работы и рисков
             1. Разбиваем проект на эпики, примерно прикидываем затраты
             2. Чем сложнее проект, тем неточнее оценка
             3. Оцениваем основные инфраструктурные затраты - трейн-машины, хранение данных, инференс
         12. Создать план дизайна команды
             1. эксперты по домену, дата-инженеры, ML-инженеры, дата-саентисты, бэкэндеры и фронтендеры, девопсы, UX-инженеры, QA, деливери-менеджеры, РО
             2. зависит от спецификаи проекта и заказчика
         13. Провести ревью-встречу по всей проделанной работе
         14. Удостовериться, что подготовлены все нужные документы
      2. Артефакты
         1. репозиторий документов
         2. реестр рисков
         3. гипотеза проекта
         4. отчёт по dilligence
         5. высокоуровневый план проекта
         6. оценка времени и ресурсов
         7. документация (NDA и т.д.)
2. Начало проекта. Старт Работ
   1. МЛ
      1. Шаги
         1. Создать, обсудить и финализировать состав команды и необходимые ресурсы
         2. Договориться о совместной процедуре работы
            1. синки, лучшие практики, общие инструменты, каналы коммуникации, документация
            2. Области инструментов
            3. Репозиторий документов (Confluence, Notion, Teams)
            4. Тикетная система (Jira, GitLab, Azure DevOps)
            5. Система контроля версий - GitHub, Bitbucket
            6. Документы - Google Docs, Office 365
            7. Диаграммы - Visio, UML, Lucidchart
            8. Менеджмент билдов - Jenkins, Gradle
            9. Управление зависимостями - Conda, poetry
            10. Тестирование - pytest
         3. Создать и выложить инфраструктурный план
            1. Как получить доступы к данным, какие есть GPU-сервера и тд
         4. Провести более тщательное исследование данных (data story)
            1. Мотивация и контекст - зачем собирают именно эти данные
            2. Механизм - как собирают, какие данные не попадают в выборку
            3. История (lineage) - можно ли отследить весь путь данных до текущего состояния
            4. События - что происходило с данными, были ли какие-то резкие изменения в процедуре сбора
         5. Провести ревью данных и этики
            1. Создать план по приватности, безопасности и работе с данными
            2. Можно ли использовать данные для целей проекта?
            3. Все ли данные собраны в одной юрисдикции?
            4. Нужно ли исключить какие-то данные из анализа?
            5. Требуются ли какие-то дополнительные процедуры типа анонимизации или differential privacy?
            6. Кто из команды должен иметь доступ к данным?
         6. Создать роадмап проекта
      2. Артефакты
         1. описание данных
         2. список таблиц и других источников данных
         3. описание проблем с данными
         4. описание текущих сценариев использования данных
         5. план по созданию документации
         6. роадмап проекта
         7. план коммуникации (как и где общаемся с клиентом и друг с другом)
         8. план IT-инфраструктуры
         9. дизайн команды
         10. project heartbeat - список встреч команды и обязательных участников этих встреч от клиента и от нас
3. Начинаем работу. Спринт1
   1. МЛ
      1. Шаги
         1. Провести полноценное исследование данных, оценить все источники данных, их полноту, качество, актуальность
            1. Провести дата-тесты для оценки метрик качества данных и разметки
            2. Создать отчёт по данным (data survey)
            3. Этапы
            4. data story
            5. data survey
            6. Могут ли все элементы, описанные в data story, быть обнаружены в системе клиента?
            7. Есть ли доступ, как мы его можем получить?
            8. Каков примерный объём данных?
            9. Какие самые старые и самые новые данные?
            10. Какие базовые статистики
            11. макс, мин, медиана, количество нулей и пропусков
            12. Какие типы данных есть
            13. численные, категориальные, неструктурированные (картинки, текст, звук)
            14. Какие проблемы выявлены в данных
            15. EDA
         2. Разработать описание бизнес-применения проекта
            1. Создать бэклог user stories
            2. Провалидировать бизнес-применение и user stories с клиентами
            3. Определить требования к качеству работы ML-модели
            4. Создать UX-дизайн
            5. а подробнее
            6. Концепт - основная идея, зачем он нужен
            7. Список стейкхолдеров
            8. Приоритеты бизнеса - привлечение клиентов, рост выручки, попуск конкурентов, социальная ответственность
            9. Impact statement - как проект будет приносить ценность, на какие показатели влиять
            10. Дата-ресурсы - какие данные доступы для обучения и в продакшне, как они будут поступать в систему
            11. Концепт модели - что будем тренить
            12. Функциональные и нефункциональные требования
            13. Как и кем модель будет использоваться - дашборд, автономная работа и т.д.
         3. Агрегировать данные в единую картину
            1. Создать дата-пайплайны
            2. выбрать инструмент (Airflow) и настроить доступы
            3. Написать дата-тесты
            4. проверка на дубликаты, качество входных/выходных и тд
            5. Подвязываемся к источникам данных (сырые данные в CSV, Kafka, объектное хранилище и т.д.)
         4. Создать репозиторий моделей
            1. Определить и записать все артефакты, которые будут использоваться в ML-пайплайнах
         5. Запланировать и провести EDA
         6. Перепроверить этические риски в свете новой информации
         7. Обучить бейзлайны моделей
            1. понять
            2. все ли ок и идем дальше
            3. переопределение целей
            4. стоп
      2. Артефакты
         1. Доступ к обучающим и валидационным данным
         2. Data Survey
         3. Дата-пайплайны
         4. Дата-тесты
         5. Репозиторий моделей и других артефактов
         6. EDA
         7. Бейзлайн-модель
         8. Этическая оценка
4. Работа с моделями. Оценка насколько модель хороша
   1. Модель хороша, если
      1. создана
         1. на основе прозрачной и надёжной дата-инфраструктуры
         2. для решения понятной проблемы и действительно решает её
         3. с учётом этических аспектов
      2. Высокое качество фиче-инжиниринга
      3. Осмысленный дизайн самой модели
      4. Оценена по разным аспектам и с помощью разных метрик
      5. Процесс выбора модели прозрачен и используется понятный процесс моделирования
      6. Хорошо задокументирована
   2. ML
      1. Шаги
         1. Создать план фиче-инжиниринга, провести ревью с командой
            1. Имплементировать пайплайн фиче-инжиниринга
            2. Задизайнить аугментации
         2. Создать и задокументировать дизайн модели. Декомпозировать дизайн на задачи
            1. Факторы, влияющие на дизайн
            2. Метрики
            3. Прозрачность и интерпретируемость
            4. Скорость работы
            5. Стоимость
            6. Приватность данных
            7. Робастность
            8. Время на разработку
            9. Тип данных и особенности домена
            10. Модель может состоять из нескольких компонентов
            11. Несколько несвязанных моделей для разных аупутов
            12. Цепь из моделей (например, классификатор документов, а затем разные OCR-модели для разных типов документов)
         3. Утвердить процесс моделирования
            1. Выбрать эксперимент-трекер. Выбрать репозиторий моделей. Отвергнуть очевидно плохие модели
            2. Признаки плохих моделей
            3. Неконсистентный перфоманс и сильная чувствительность к небольшим изменениям входных данных
            4. Слишком хороший неожиданный перфоманс
            5. Небольшое изменение гиперпараметров ведёт к сильному росту метрик
         4. Имплементировать тестовую среду
            1. Создаём среду для оффлайн-тестирования, по возможности максимально приближенную к реальной работе - получаем доступ к данным, настраиваем дата-пайплайн, запускаем модель, считаем метрики
         5. Разработать метрик-тесты для моделей
            1. Решаем, как будем проводить онлайн-тесты - field trial (деплой на небольшую группу пользователей), A/B-тестирование, multi-armed bandits
         6. Протестировать нефункциональные требования
            1. Финальные latency/throughput, цена, требования по ресурсам
         7. Утвердить алгоритм выбора лучшей модели на основе валидационных и тестовых данных
            1. Учесть нефункциональные требования и другие качественные показатели
            2. Количественные тесты
            3. Сравниваем по какой-нибудь единой метрике
            4. Сравниваем по набору метрик (multi-objective optimization)
            5. Качественные тесты
            6. Безопасность модели
            7. Справедливость модели
            8. Интерпретируемость модели
         8. Написать model delivery отчёт
         9. Задокументировать процедуру выбора модели
         10. Отревьюить и обсудить с клиентом выбор модели
      2. Артефакты
         1. Пайплайн фиче-инжиниринга
         2. Дизайн модели
         3. Ряд обученных моделей
         4. Результаты экспериментов, метрики
         5. Список обнаруженных проблем
         6. Тестовая среда
         7. Алгоритм выбора лучшей модели
         8. Тестовые данные из онлайн-среды
         9. Документация по процессу выбора модели
5. В Продакшен!
   1. МЛ
      1. Шаги
         1. Определить тип деплоя
            1. Типы деплоя
            2. Assistive - люди смотрят на результаты работы модели, например, в дашборде
            3. Delegative - делают предикт, который используется напрямую, но под контролем человека
            4. Autonomous - автономные системы, работающие без человека
         2. Определить функциональные и нефункциональные эффекты системы
            1. Стоимость
            2. Эффект на экологию
            3. Скорость и пропускная способность
            4. Поддержка очерёдности запросов
            5. Поведение в случае ошибки
            6. Надёжность
         3. Выстроить продакшн дата-пайплайны
            1. Data lake (HDFS, S3) + процессор (Hadoop, Databricks)
            2. Data warehouse (BigQuery, Redshift)
            3. RDMBS-сервер (Oracle, Postgres)
            4. NoSQL (Mongo, Cassandra)
            5. Memory store (Redis, Memcached)
         4. Создать систему инференса
            1. Выбираем inference server
            2. In a database - BigQuery ML, Redshift ML
            3. Application server - Nginx, Flask
            4. Spark-like - Apache Spark, Databricks
            5. Kubernetes/Kubeflow
            6. Serverless - Lambda, Azure Function
         5. Определить необходимые компоненты интерфейса системы
            1. Принципы UI-дизайна ML-систем
            2. Должно быть понятно, что система может и не может делать
            3. Показывать только информацию, которая релевантна текущему контексту пользователя
            4. Должно быть легко отключить систему при необходимости
            5. Если система неуверенна в своём ответе, надо собрать больше информации от пользователя или временно отключиться
            6. Система должно плавно адаптироваться и обновляться. У пользователей есть свои ожидания
            7. Здорово собирать детальный фидбек о работе системы от пользователей
            8. У пользователя должны быть способы мониторить и контролировать работу системы
            9. Нужно заранее оповещать пользователя об изменениях в системе
         6. Выбрать соответствующий подход к разработке интерфейса, который позволит удовлетворить требованиям пользователей
         7. Создать системы логирования, мониторинга и алертинга
         8. Определить процесс управления и передачи модели
         9. Написать документацию по поддержке модели
            1. Run book - документ для HD первой и второй линии, который содержит информацию о всех возможных ошибках, и о том, что нужно делать в каждом случае
            2. Технический обзор - брифинг для новых инженеров, чтоб максимально быстро понять суть системы и заонбордиться
            3. Troubleshooting guide - более подробный гайд по всем возможным проблемам с системой
         10. Создать предрелизный план тестирования
             1. Юнит-тесты
             2. Системные тесты
             3. Интеграционные тесты
             4. Acceptance-тесты
             5. Финальные этические проверки
         11. Провести релиз в продакшн
             1. Создать пострелизный план тестирования
         12. Поблагодарить команду
6. Постпродакшен: Промышленная эксплуатация
   1. Шаги
      1. Определить основные источники ML-техдолга
         1. Проверять перфоманс модели ее актуальность и необходимость модели
         2. Определить примерную скорость устаревания модели и по необходимости процедуру переобучения
      2. Определить общий software-техдолг системы
      3. Провести пост-ревью, вынести уроки из проекта
      4. Определить новые практики для будущих ML-проектов
         1. Чему научились, какие новые практики попробовали, какие хотим попробовать в будущем
      5. Определить новые технологии для изучения
      6. Написать кейс-стади о проекте и поделиться
   2. Закрытие проекта
      1. распределение и выдача поощрений за работу
         1. передача результатов в эксплуатацию
         2. закрытие договорных отношений
         3. подведение итогов
         4. архивирование информации
         5. принятие решения об успешности проекта
            1. поощрение за работу
            2. мостик к эффективной работе на новых проектах
      2. Инструменты и компетенции
         1. процедура закрытия проекта
         2. анализ извлеченных уроков
         3. мотивация
         4. управление знаниями
7. Источники и интересные ссылки
   1. https://xmind.app/m/8khxdU/
      1. ML-продукты. Разбираем основы
   2. https://xmind.app/m/QtNa2r/
      1. Описываем задачу/гипотезу/метрику для ML проекта
   3. https://docs.google.com/spreadsheets/d/13G4J61pqoyz46k8VG5omFqIOoGCkvHuTyVCWtqwllJE/edit#gid=26284490
      1. задание по проекту (МБА)
   4. https://celsus.notion.site/celsus/Managing-ML-Projects-0893e33a047e4c5e9afa36cee6a4403f
      1. Конспект книги Managing ML Projects
   5. https://xmind.app/m/N8DuAK/
      1. Some notes about Mitosheet. An easy way to create visualizations
   6. https://xmind.app/m/aTyzbU/
      1. Some notes about Exploratory Data Analysis (Python and Pandas)
   7. Catalog of requirements for AI products
      1. https://github.com/ttzt/catalog_of_requirements_for_ai_products
8. Проекты в общем. Организация управления проектом
   1. Поиск квалифицированных исполнителей для выполнения работ проекта
      1. На основании плана проекта ( с учетом полномочий, выделенного бюджета) РП и команда управления подбирают конкретных исполнителей и поставщиков
      2. Инструменты и компетенции
         1. определение требования
         2. оценка квалификации исполнителей
   2. Определение индивидуальных задач и условий мотивации, приемлемых для конкретного исполнителя
      1. для каждого исполнителя определяются задачи в соотвествии с планом проекта
         1. исполнители принимают активное участие
         2. если внешние поставщики/подрядчики
            1. определяются требования и проводится отбор в соотвествии с утвержденными процедурами
      2. Инструменты и компетенции
         1. процедуры оценки и отбора исполнителей
   3. Формальное назначение исполнителей с определением полномочий
      1. После определение и распределения задач: необходимо дать исполнителям формальные полномочия
         1. если внешние подрядчики и исполнители
            1. заключение договоров и определение договорных обязательств
      2. Инструменты и компетенции
         1. внутренняя нормативно регламентная документация
         2. договоры
9. Проекты в общем: Координация и контроль проекта
   1. Координация деятельности исполнителей
      1. Инструменты и компетенции
         1. план коммуникаций проекта
   2. Измерение прогресса в исполнении проекта и отклонений от плана
      1. контроль за выполнением индивидуальных задач
      2. сбор отчетности и оценка состояния работ
         1. в соотвествии с приницпами регламента
      3. Инструменты и компетенции
         1. сбор и анализ отчетности по проекту
         2. критерии оценки эффективности реализации проекта
   3. Анализ и оценка индивидуальной деятельности в соответствии и индивидуальными задачами и планами
      1. аналогично
         1. по определенному плану
      2. Инструменты и компетенции
         1. сбор и анализ отчетности по проекту
         2. критерии оценки эффективности исполнителей
         3. мотивация
   4. Осуществление корректировки плана проекта (принятие решений по измерениям, пересмотрт плана проекта)
      1. по результатам анализа
      2. Инструменты и компетенции
         1. процедуры управления изменениями
         2. актуализация планов
      3. нужна ли корректировка