-
Система обзора является важным средством управления продуктами через Интернет. Система обзора охватывает все аспекты управления продуктами, такие как стратегическое планирование, дизайн продукта, внедрение технологий, эксплуатация продукта и маркетинг продукта. Можно сказать, что эффективная система отзывов является важным показателем возможностей компании по управлению продукцией. Кратко перечислим некоторые ценности системы отзывов:
Система проверки может помочь заинтересованным сторонам достичь последовательного понимания целей создания продукта;
С помощью системы проверки можно проверить качество планов планирования продукции, планов спроса на продукцию, технических планов, планов эксплуатации, планов маркетинга и т. д. для улучшения качества продукции;
С помощью системы проверки можно проверить ключевые моменты и точки риска в процессе планирования и изготовления продукта, чтобы снизить риски реализации проекта.
Система оценки может эффективно улучшить возможности участников;
Проверьте план с помощью системы проверки, чтобы убедиться, что дух архитектуры системного продукта и проектирования архитектуры последовательно реализован.
Хотя проверка продукта настолько важна, кажется, что ни одна система проверки не является эффективной. Все жалуются на многочисленные недостатки системы проверки. Совещание по проверке превратилось либо в формальность, либо в ПК между основными лагерями. Что касается системы проверки, она описана в различных книгах и методологиях по разработке программного обеспечения. Здесь основное внимание уделяется не обсуждению общих принципов системы проверки (например, проверки продукта). Главное здесь - обсуждение процесса работы платформы. - на основе продукта. Как проверить через систему отзывов.
1. Проекты этапа строительства VS.
Для интернет-продуктов (продуктовых платформ), использующих концепцию продуктовой платформы, таких как платежные платформы и открытые платформы, управление проектами продуктов в период строительства сталкивается с другими проблемами, чем управление проектами продуктов в период эксплуатации.
Причина особого внимания к этим продуктовым платформам заключается в том, что для многих интернет-продуктов основной логикой является интерфейс веб-сайта, поэтому обзор этих веб-сайтов относительно прост и требует только подхода, основанного на прототипах. Но для этих платформенных продуктов это не просто работа по разработке веб-страниц. Самая сложная логика этих систем обычно заключается в внутренних бизнес-правилах и бизнес-логике, и их невозможно четко объяснить с помощью прототипа.
1). Характеристики проекта в период строительства.
Цикл проекта относительно длинный, например, более 1 месяца.
Ресурсы проекта относительно обильны, и ими можно управлять как отдельной проектной командой.
Управление проектами может использовать традиционные методы управления проектами или методы гибкого управления проектами.
Предпроектной подготовки относительно достаточно, например, относительно полные документы на продукцию, полные прототипы, полные планы проекта, семинары по созданию проектов/семинары по спросу и т. д., исследование рынка/анализ продукции конкурентов и т. д.
Проект относительно независим и менее ограничен другими проектами.
2) Характеристики проекта в период эксплуатации
Цикл короткий, большая часть из которых составляет менее 2 недель.
Ресурсы ограничены, и членам проектной группы, возможно, придется одновременно поддерживать другие продукты.
По мере расширения бизнеса компании людей, знакомых с продуктами и технической архитектурой, всегда не хватает. Эти люди обычно отвечают за некоторые ключевые новые проекты и должны помогать новичкам ознакомиться с системой в работе.
В управлении проектами обычно используются гибкие методы управления проектами, такие как Scrum и XP, или даже сокращенная гибкая разработка.
Подготовка проекта недостаточна, и сделать это после достаточной подготовки невозможно.
Проект нуждается в оптимизации и реконструкции на основе существующих продуктов и не может повлиять на существующую систему. Для работающих продуктов архитектура продукта и архитектура системы теряют контроль и деформируются в ходе постепенной модификации. Должен быть механизм контроля этих факторов.
Здесь мы сосредоточимся на методах проверки продукта и технической проверки в период эксплуатации.
2. Принципы проверки продукции в период эксплуатации
Независимо от того, насколько срочен проект, необходимо провести обзор продукта и технический анализ.
Отзывы должны быть гибкими
Формат обзора не имеет значения, обзор! = Встреча, форма рассмотрения может быть формальным или неофициальным рассмотрением. Суть проверки в том, что должны быть люди, знакомые с системой и способные проверить план.
Целью обзора является не поиск оптимального решения, а наиболее разумного решения в рамках ограничений существующих ресурсов.
Идеальной системы проверки не существует. Ключевым моментом является постоянная оптимизация системы проверки на практике и создание системы проверки и последующих мер, соответствующих ситуации вашей компании.
3. Методы проверки продукции в период эксплуатации.
Для проверки продукта в период эксплуатации не существует справочного плана передовой практики. Каждая компания имеет свои собственные реалистичные условия ведения бизнеса, и разные бизнес-модели имеют разные методы проверки. Можно сказать, что эффективный анализ продуктов в период эксплуатации — это искусство баланса, которое должно сбалансировать требования стандартизации управления, гибкости и реальности бизнеса. Но в целом суть метода проверки продукта в период эксплуатации одна и та же: постоянное улучшение, основанное на сотрудничестве команды.
Система проверки в период эксплуатации должна поддерживаться процессом разработки продукта в течение периода эксплуатации. Следует сформулировать упрощенный процесс разработки продукта в период эксплуатации (по сравнению с процессом разработки продукта в период строительства) для сбора и выявления проблем в системе проверки из других звеньев процесса, чтобы обеспечить непрерывную оптимизацию системы проверки продукции. Например, благодаря обратной связи от тестирования качества, эксплуатации, продаж, маркетинга и других связей проекты с неудачными системами проверки обнаруживаются и включаются в библиотеку дел для постоянной оптимизации процесса НИОКР и системы проверки.
Установите жесткие стандарты, которые необходимо пересматривать, и доведите их до количественной формы контрольного списка (просто первый критерий)
Например, если время разработки составляет более 1 недели или менее 1 недели, но включает в себя ключевые бизнес-модули, их необходимо пересмотреть. Причина, по которой применяется универсальный метод определения периода строительства и воздействия вместо использования взаимодействующего персонала для оценки необходимости проверки, заключается главным образом в том, чтобы избежать слишком большого количества человеческих факторов, из-за которых система проверки становится простой формальностью.
Если срок менее 1 недели и не предполагает изменений ключевых бизнес-моделей, ответственное лицо вынесет собственное решение.
Проверка должна включать участие заинтересованных сторон и не может просто позволить персоналу, производящему продукт, и техническому персоналу проводить оценку самостоятельно. Например: в составе продуктовых решений должен быть технический персонал, операционный персонал, финансовый персонал и т. д. В технических решениях должен быть персонал по продуктам, архитекторы, бизнес-эксперты и т. д.; Заинтересованные стороны, участвующие в проверке, имеют право откатить план и переделать его. Конечно, это затрагивает еще одну более важную тему: командное сотрудничество. Если команда не может установить доверительные отношения, какой бы совершенной ни была система, она превратится в ПК.
Рецензенту не нужно проводить всестороннюю проверку, он лишь просматривает план по ключевым моментам требований, ключевым бизнес-правилам и точкам риска, чтобы гарантировать эффективность проверки. Результаты проверки необходимо зафиксировать в соответствующей процессуальной форме.
Создайте библиотеку кейсов для проверки, регулярно (ежемесячно) просматривайте библиотеку кейсов для проверки и постоянно оптимизируйте систему проверки. Краткое изложение рассматриваемого дела должно быть сосредоточено на вопросе, а не на человеке. Не возлагайте на рецензента полную ответственность за результаты.
Функционирование системы не зависит от того, насколько идеально она определена изначально. Ключ заключается в том, можно ли постоянно оптимизировать систему. Непрерывная оптимизация/постоянное совершенствование/постоянное улучшение — один из хорошо известных и эффективных основных секретов различных методов управления, но его также сложнее всего реализовать, особенно по сравнению с модными словечками в области управления, упоминание о непрерывном совершенствовании слишком неоригинально и скучно. . Оно настолько велико, что мы все надеемся на «серебряную пулю» для решения различных проблем, с которыми мы сталкиваемся.
Источник статьи: Стань монахом, как раньше, и стань Буддой. При перепечатке указывайте ссылку на источник.