Эта статья от Fliggy front-end@jiudi (также называемого братским псом), который много лет занимается бизнесом и имеет большой опыт PM в проекте. для новых студентов Флигги, заимствование интерфейсной части Флигги Публичная учетная запись команды WeChat используется совместно со студентами, занимающимися фронтенд-разработкой. Я с нетерпением жду возможности внести свой вклад в процесс разработки и контроля проекта Али. Добро пожаловать в общение!

Анти-дисс гайд по Front-end PM

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

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

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

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

Но "определение" вообще абстрактно, что делать, когда оно конкретизируется в сцене реального шоппинг-гида, где может быть четкий ответ, хотя бы опыт?
Для того, чтобы не попасть в эти проблемы в будущем, исходя из своего предыдущего опыта и уроков в качестве front-end PM, исходя из существующих бизнес-проектов Али, я обобщил «Руководство по Front-end PM». являетесь небольшим партнером в других направлениях бизнеса, вы можете использовать свой собственный бизнес, а также чтение замены инструмента. Я надеюсь, что это руководство может помочь мне и другим студентам в будущей работе, и я надеюсь, что оно может вдохновить студентов в других областях бизнеса.Я приветствую критику и исправления.

нуждается в проверке

Подготовка перед обзором

Подготовка способностей

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

Заранее сообщайте о намерениях продукта PD (как правило, PD связывается с главным разработчиком перед запуском обзора)

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

работа после общения

Внимательно прочитайте PRD, у вас должно быть четкое представление о том, какие способности использует каждый модуль.
Бизнес-цели требований должны быть четкими и разумными.Если входные и выходные данные слишком малы, а цели неопределенны, следует передать обратную связь PD для повторной проверки.
Когда речь идет о областях, с которыми вы не знакомы, необходимо своевременно дополнять информацию
- Например: Эта страница активности должна использовать функцию seckill. Вы понимаете систему игрового процесса активности, соответствующую функции seckill?
- Например: на этот раз есть продукты, привлекающие инвестиции, вы понимаете процесс привлечения инвестиций, разницу между продуктами, привлекающими инвестиции, и обычными продуктами?
Он не охватывает потребности в сфере бизнеса, которую вы понимаете.Вы должны своевременно сообщить своему начальнику о сфере деятельности и границах, а затем дать отзыв PD.
Если изменение функции связано с разработчиком, который не ясен, пожалуйста, проконсультируйтесь вовремя, чтобы предотвратить утечку людей во время проверки.
Есть новые технологии и новые инструменты, чтобы бросить вызов, мы должны вовремя сделать технические резервы

Требуется приглашение на проверку

Приглашение на собрание по рассмотрению потребностей выдается PD, и PM должен проверить, что весь необходимый персонал охвачен и что необходимый персонал может присутствовать вовремя.
Если у PD нет группы гвоздей проекта, ему необходимо вытащить группу гвоздей, а PD отвечает за объяснение фона спроса и т. д. Адрес PRD запроса должен быть помещен в групповое объявление.
Если ПД не нужно сообщать заранее, если у вас есть какие-либо сомнения после внимательного прочтения ПРД, решите, нужно ли вам немедленно связаться с ПД в соответствии с влиянием на проект.
- Границы бизнеса, приоритеты ресурсов и т. д.Проблемы, напрямую влияющие на разработку проекта, необходимо немедленно связаться с ПД, требуется ПД для уточнения границ и координации ресурсов
- Некоторые модулиТехнически невыполнимо, текущие инструменты не могут быть реализованы, и другие вопросы могут быть обсуждены во время обзора.

рассмотрение

нужна обзорная встреча

Убедитесь, что весь необходимый персонал присутствует
Бизнес-цели требований должны быть четкими и обоснованными, поддающимися количественной оценке и отслеживанию.
- Например: Ключевым показателем в этом вопросе является кликабельность, необходимо знать, до какой степени кликабельность достигнет за определенный период времени, и насколько она увеличится по сравнению с каким периодом.
Основное внимание при проверке требований уделяется проверке рациональности требований при условии их одобрения соответствующими сторонами, вовлеченными в эти требования., нет необходимости обсуждать слишком много технических деталей, такие проблемы могут быть зафиксированы и определены в техническом обзоре
- Например: можно ли получить определенное поле продукта, если оно не является областью особого интереса в этом выпуске, его можно записать первым, потому что интерактивный черновик может быть только схематической диаграммой, которую можно подтверждено во время проверки пользовательского интерфейса и подтверждено во время технического рассмотрения.
Точка спроса должна быть полностью понятной и не может быть принята как должное. Все стороны должны определять план и подтвердить целесообразность плана
Если вам нужно использовать интерактивное рецензирование рукописи, вам нужно обратить внимание на проблемы взаимодействия с интерфейсом и отбросить их во время обзора требований, чтобы предотвратить замедление прогресса UED.
**Есть требования к модулям, подтвержденные после обсуждения, или специальные требования к модулям, которые необходимо зафиксировать **
- Например, требование обратного отсчета модуля seckill — это момент времени, когда операция заполняет обратный отсчет или интерфейс для чтения активности, какое содержимое модуль будет обновлять после окончания обратного отсчета и как поступать с исключением. Консенсус, сформированный после такого продукта, операции и технического общения, должен быть записан.
По пунктам, которые необходимо подтвердить после встречи, необходимо четко зафиксировать проблему, назначить человека и определить, когда она может быть подтверждена., После подтверждения будет обратная связь (ответ на обзор UI или в группу)
Определите сроки последующих обзоров пользовательского интерфейса, за исключением случаев, когда нет уверенности в наличии ресурсов.

После встречи по рассмотрению потребностей

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

Обзор пользовательского интерфейса

Подготовка перед обзором

Предварительный просмотр проекта дизайна

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

Приглашение на проверку пользовательского интерфейса

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

рассмотрение

Совещание по обзору пользовательского интерфейса

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

После совещания по обзору пользовательского интерфейса

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

технический обзор

Подготовка перед обзором

умственная подготовка

Ясно и четко указаны соответствующие стороны, которые должны присутствовать.
PM должен знать, на какой стороне вашего развития и бизнеса
- Например: на типичной странице продвижения, кто предоставляет пул продуктов (алгоритм или операция), кто дополняет поля продукта (значение на стороне сервера или результат расчета алгоритма) и каков метод доставки (запись конфигурации операции или персонализированный алгоритм) , каков метод производства (алгоритм или конфигурация операции), какие есть случаи для входа, и какие поля необходимы для каждого отображения входа
Были ли четко поняты требования и пользовательский интерфейс, и были ли учтены функциональные точки, которые должен сообщать каждый модуль
Были ли нерешенные проблемы, оставшиеся от ранних результатов, точно
Какие вопросы являются ключевыми, а какие являются промежуточными, необходимо различать основные и второстепенные вопросы.
- Общие функциональные точки являются вторичными, новые функциональные точки являются первичными.
- Простые модули вторичны, сложные модули первичны.
- Модуль, который является самодостаточным для одного разработчика, является вторым, а модуль, который реализуется несколькими сторонами, является основным модулем.
Основная цель технического ревью не планирование, а обмен информацией, определение технических решений, уточнение границ и способов сотрудничества разработчиков.

Приглашение на технический обзор

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

рассмотрение

Все разработчики, тестировщики и PD должны присутствовать, Если требуется сотрудничество по эксплуатации, также должны присутствовать студенты-операторы.
Проверка проводится помодульно с привязкой к визуальному проекту пользовательского интерфейса.
Кто предоставляет каждое поле каждого модуля и как его реализовать, следует четко сообщить
- Для некоторых спецполей необходимо прописать логику стоимости копирайтинга, кто и как это реализует, нужно четко помнить
Для функциональных точек, которые ранее не затрагивались, требуется техническое решение по копирайтингу
Для модулей, требующих многостороннего сотрудничества
- Необходимо, чтобы все стороны достигли консенсуса по техническому решению, чтобы обсудить конкретный процесс реализации, не может быть расплывчатых предположений.
  - Например: кто будет передавать данные проверяющей стороне, откуда берутся данные и как они будут передаваться проверяющей стороне, будь то уведомление о событии, sql или оффлайн таблица, каковы требования к реальному времени для этого данных, и каковы требования к стабильности
- Должно быть ясно, за что отвечает каждый разработчик, что он должен предоставить и кто выше и ниже по течению.
По пограничным вопросам, которые трудно решить всем сторонам, своевременно вызывать контролеров соответствующих сторон для подтверждения разделения границы.
После четкого сообщения плана каждого модуля согласовывается расписание
- Для общих требований серверная часть должна обеспечивать функциональную совместную отладку, а моменты времени, которые необходимо подтвердить, находятся в положительном порядке на временной шкале:
  - Время начала
  - Соглашение о внешнем и внутреннем протоколе передачи данных
  - Предоставление фоновых фиктивных данных
  - Предоставление реальных данных
  - Время совместной отладки внешнего и внутреннего интерфейса
  - Время тестирования
  - Время принятия
  - время онлайн
- Для общих требований к строительству временные точки, которые необходимо подтвердить, расположены в положительном порядке на временной шкале:
  - Время начала
  - Время полного модуля создания внешнего интерфейса
  - Время завершения создания товарного пула одноклассников операции
  - Событие завершения конфигурации платформы доставки данных Operation classmate
  - Время тестирования
  - Время принятия
  - время онлайн
- Серверная часть также зависит от изменений.Помимо необходимых моментов времени для общих требований, необходимо четко указать моменты времени, когда каждая зависимая сторона может предоставить данные или возможности, и должны соответствовать периоду разработки доверяющей стороны. .
После встречи должен быть четкий график разработки

Отслеживание хода проекта

Начало проекта

Требуется ли стартовая почта?

Кроме рутинной итерации всех проектов нужен Kickoff Mail

Содержание по почте Kickoff.

Основные элементы: предыстория проекта, цели проекта, ритм проекта, участники проекта, данные проекта.
Объем проекта и содержание разработки должны быть четко указаны, и последующий объем разработки должен быть основан на этом Изменения, не входящие в этот объем, должны рассматриваться как изменения спроса.
Получателями электронных писем являются все участники проекта, и они копируют основных заинтересованных лиц (PD, эксплуатация, UED, интерфейс, серверная часть, алгоритм, тестирование), супервайзеры + участники проекта из их собственных команд.Важные проекты необходимо копировать в каждая команда или BU, ответственная за продвижение этого вопроса.

Проект Еженедельно, Ежедневно

Требуется ли еженедельный или ежедневный отчет по проекту

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

Еженедельный и ежедневный контент

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

Риск и задержка

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

Уведомление об изменении и расширении требований

Изменения в неосновных требованиях к проекту: группа DingTalk хорошо известна и отмечена в PRD, и отражается в проекте еженедельно/ежедневно.
Изменения в основных требованиях проекта или любое расширение проекта: в дополнение к тому, что группа DingTalk известна и отмечена в PRD и отражена в еженедельном / ежедневном отчете по проекту, получатель стартового электронного письма должен быть уведомлен по электронной почте.

Спецификация испытаний

Вам нужна субтСА почта?

Для всех проектов требуется тестовая электронная почта

Обнаружение содержимого электронной почты

Основные элементы: функциональное завершение, завершенное самотестирование, тестовый пакет (при необходимости), автономный пакет (при необходимости), адрес страницы, QR-код, информация о проекте.
Если в середине есть изменение спроса, об этом нужно напомнить в тестовом электронном письме.
Если есть особые требования к тестовому контенту, это необходимо указать в тестовом письме.
При наличии особых требований к методу испытаний необходимо указать адрес документа метода испытаний в тестовом электронном письме.

выпускать

Предварительные требования к выпуску

должен пройти тест
Это должно быть принято деловой стороной

график выпуска

Релиз строго соответствует красной линии изменений, реализованной в то время, и должен быть в оттенках серого, отслеживаться и откатывать.
Выпущено в порядке зависимостей
- Как правило, доверяющая сторона публикует первой
- Если есть изменения, влияющие на онлайн, они будут выпущены после того, как будут несовместимы со старой версией.
После релиза необходимо организовать тестирование и бизнес-партии провести онлайн-приемку сразу
После прохождения тестирования и принятия бизнес-стороной релиз считается официально завершенным.
Приемка обнаружила онлайн-проблемы
- Независимость от пользователя и быстрое исправление: исправление и выпуск
- Пользователь не имеет восприятия, но не может исправить это быстро: нужно ли общаться с PD через ежедневные итерации
- Уведомление пользователя и быстрое исправление: откат и исправление
- Пользователи знают, но не могут исправить быстро: руководство см. в разделе «Риски и задержки».

Что делать после публикации

журнал проблем

Выработайте полезную привычку устранять неполадки и анализировать записи в Интернете.

Мониторинг и производительность

Обратите внимание на различные показатели стабильности платформы мониторинга
Обратите внимание на наличие обратной связи с общественным мнением
Соберите данные о производительности, если есть новая и старая версии, нужно сравнить изменения производительности до и после

бизнес-данные

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

Вам нужно электронное письмо с выпуском

Все проекты с Kickoff должны иметь Release

Публиковать содержимое электронной почты

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

Last but not least

Вышеизложенное представляет собой полное содержание «Руководства по борьбе с диссами в PM», а также микрокосм процесса разработки проекта на стороне Флигги. Если нет объяснений, пожалуйста, прокомментируйте и обменяйтесь, и добро пожаловать, чтобы указать не в том месте~

Флигги занимается набором интерфейсных специалистов. В настоящее время у нас много разработок в области бессерверных, микро-интерфейсных рабочих мест, конечного рендеринга, интерактивного маркетинга, найма, интеллектуальных технологий, технологий опыта и измерения данных. Мы приветствуем студентов, у которых есть способность приходить и внедрять технологии для создания бизнеса. Ценность, если вы хотите привлечь людей и одноклассников, вы можете напрямую указать направление. Добро пожаловать, чтобы подписаться на общедоступную учетную запись WeChat, чтобы связаться!

В этой статье используетсяmdniceнабор текста