精华内容
下载资源
问答
  • 陪学网(www.pexue.com)专注于产品管理类课程的开发和制作,志在为产品经理、交互设计、平面设计、需求人员分享最新、最好的产品类课程。

    产品需求文档是产品人员非常核心的基本功!是协调研发、测试、UED、业务非常重要的重要工具。但是,往往很多新入行的PM与互联网领域的PM,产出的文档往往不尽人意,主要体现在:

    缺乏逻辑,语言啰嗦不精练;

    通俗的用词过多,整体显的不专业;

    无法将字段的数据结构、逻辑关系清晰的表达出来;

    缺乏开发思维;

    而出现这种原因在于:

    新人入职,没有经过严谨的文档撰写、流程设计训练;

    大多数的PM非研发出身,对前后台的业务逻辑、数据结构了解不清晰;

    分工细,版本迭代迅速,对功能点理解不够透彻;

    二、业务描述

    任何的业务或需求,都有业务提出方,业务提出是相关的业务部门或产品经理自身。

    业务来源的本质,便是希望通过这个业务解决那些实际的问题,达到提升某些转化率或某些目的;业务描述清晰的表达出来即可,不需要多复杂,但常规包括:

    业务背景

    产品功能概述

    产品前景分析

    产品功能整体流程

    产品逻辑关系

    面向对象

    应用对象

    名词解释

    参考文档

    上述的这些层面,以通用版的角度,将产品的价值传递给研发方与业务方,实现之间有效的衔接。

    为什么,我们需要进行业务、功能、概述这些偏宏观不实际的描述呢?这样不是很麻烦,且浪费时间?

    我们要知道,每新增或删除一个功能,狭义来看也没啥大不了。但站在宏观的角度去看,功能研发是需要耗资企业运营成本。如果处理不完善,浪费运营成本同时,甚至影响整个用户体验与开发规则。

    身为产品人员在未传达产品的业务价值前提条件下,便强势驱动研发人员进入开发阶段,这是错误的!我要是研发,我也会拍死这位PM。那么业务描述的本质便很清晰了,便将业务价值,传递给团队成员。

    而且现在很多企业,内部的项目流程是不完善的,产品经理往往需要兼备着项目经理的职责,推动着项目实现研发上线。在这种情况下,如果业务价值描述不清晰,功能在开发与上线后出现问题,这个锅注定是要背的。

    BTW,这些我就不都说了,自己工作中慢慢积累!

    下面,我对组成业务描述的组成元素进行描述:

    业务背景描述:

    这里,你必须将业务提出方描写出来,并且细致到业务方为什么将这个需求提出来!为什么?一方面,你要告诉研发人员,你为什么设计这个产品或功能,这个需求从来源到设计是有原因的。另一方面,拉上相关业务部门,你至少不是一个人在战斗。

    产品功能描述:

    对当前功能进行概述,所设计的产品或功能的功能模块,新增、完善、优化那些产品功能;

    产品前景描述:

    本产品或功能,希望对那些转化率指标或实现那些目的;

    产品的整体流程:

    Visio、Axure

    简单的需求将主业务流与逻辑关系流表达出来便可以;但涉及复杂的业务,便将产品或功能涉及的主要流程绘制出来;而流程目的,主要是清晰的将前后台的逻辑关系与数据结构表达出来;一方面方便开发理解业务与数据流,另一方面也方便产品人员梳理自身需求的业务逻辑;利于后续与研发进行沟通。

    具体的流程数量,根据业务的复杂程度决定,一般只需要将核心的流程绘制出来便可;

    前台:主要是交互、数据流程;

    后台:主要是业务逻辑判断、数据流;

    前后台的流程凑在一起,能清晰的看到前后台的模块之间,是如何进行耦合的,数据储存、提取、处理、分析。

    功能框架:

    框架图的意义在于,能让查看或了解业务的人,全方位的了解功能之间的功能点的逻辑关系。同时,一份优秀的框架图,能让PM站在全局的基本面上,对个人所负责的产品进行全局的规划,对前后台的功能进行把握,达到支撑平台业务。

    产品架构:对前后台的各个系统与管理模块的逻辑关系,一般是对业务极其熟悉的业务构架师与资深的产品总监搭建,里面涉及每个接口如何进行对接耦合。

    功能架构:所负责的产品或功能的前后台功能的逻辑关系,简单点的就是一个产品或功能的前后台,大一点就是一个系统涉及的功能点之间的耦合。

    功能框架:功能点所涉及的逻辑关系。

    功能结构:功能点所涉及的逻辑关系。

    而“架构、框架、结构”区分在于,所负责的业务究竟有多大。但不论如何,它们的表现的原理是一致的。将分解的功能点,之间是如何联系的功能结构关系清晰、简练的表达即可。

    关于架构,包含“功能分解、面向用户”就够用了。若再深入,可将分为:“应用对象、BI分析(BI需求也写上去)、系统集成….”。后续可根据BI数据,对产品进行版本迭代与优化。

    面向对象

    表达产品或功能主要是为那类用户服务的。将面向用户是谁,拥有哪些权限清晰的表达出来即可,对个人进行功能设计也有很大的帮助。

    应用对象

    本功能需要在那些应用端或版本进行上线,清晰的描绘出来,方便后续进行业务交接。

    名词解释

    将本次文档涉及一些奇葩的明词进行解释,这点很重要!有些PM喜欢将一些非常简单的内容包装成非常牛逼,让人看起来很难懂,而事实上也就做哪些一件简单事,但是看的人会很痛苦:看PRD时会想:“这玩意,究竟想表达什么。

    参考文档

    将所做的本次功能,所参考的那些文档,附属上来;目的的在于,方便后续的业务方、研发方进行查看。

    三、功能描述

    功能描述能否描写清晰,描写清晰,开发找茬都不怕了。如何才能完整的对功能点进行描述呢?围绕三个点“功能是谁?功能来自哪里?功能要到哪里去?

    同时,功能需求主要分为核心功能、其它功能。不论是核心功能还是其它功能,都可以由以下元素构成:

    功能名称

    面向用户

    用例图

    前置条件

    后置条件

    功能简述

    详情描述

    而具体的功能描述内容,则根据业务(功能点)的复杂程度,进行筛选描写。可以全写,也可以不全写。但务必记住:不论何种方式,目的在于将业务价值完整、清晰、有条理的传递给查看文档的参与角色。

    功能名称(我是谁)

    本功能在系统里的命名。

    面向用户

    本功能的使用对象。(在前台,功能的参与者是少数的;但后台与企业级应用里,功能的参与者是多个的)

    用例图

    表达功能在表现层的逻辑图;可以是传统意义上的用例图,或者是简化版的原型图、流程图;

    前置条件(我来自哪里)

    使用该功能的前提、逻辑关系说明;公司大了后,每个开发都只写个人所负责的业务,所以一定要将每个模块来源都清清楚楚的表达出来,方便开发之间的衔接。

    后置条件(我要到那里去)

    使用该功能后,对业务、数据功能,产生的影响与结果;

    功能简述

    描写本功能需要实现的商业价值或目的;

    详情描述

    将功能“我怎么来,我怎么去”清清楚楚的表达出来。变成计算机逻辑便是,页面布局、操作逻辑进行详细的说明。常规而言:

    前台:主要是字段、交互逻辑组成;

    后台:主要是判断逻辑、列表表单、查询条件、交互逻辑组成;

    四、其它功能

    其它功能目的在于,功能描述针对于本次产品功能的核心业务,而其它功能针对于触发或需要其它功能变动的业务。功能描述清晰的让开发了解核心,而其它功能便让开发清晰的了解非核心。

    其他接口

    对其它系统产生“字段、业务流程”进行说明;本次产品或业务,对前后台那些非主流程模块产生影响;

    系统风险评估

    当前设计的功能存在哪些缺陷、注意事项与后期的功能拓展如何解决这些问题;

    其它需求

    对一些非核心的功能点进行详情描述。如:一些需过滤的关键字、新增某个栏目字段。

    五、综述

    通过上述内容,能以通用版的形式,清晰的将所负责产品与功能表达出来,而业务描述、功能描述、其它功能等是产品需求分析文档重要的组成部份,将产品需求较为全面、有效的描述出来。

    同时,能训练PM逻辑思维,提升文字表达能力、业务理解能力,从整体上让PM在需求管理上,明显更加专业,所负责功能的逻辑关系、数据流的来与去都能很好的把控。

    完善的产品需求文档,不但利于PM对所承接的功能进行有效的管控,将业务逻辑梳理清晰,对分解的功能点,进行协调测试、研发、设计、运营同时开展工作。

    更多产品经理、需求分析文档,交互设计资讯请登录陪学网(www.pexue.com)了解详细。

    陪学网(http://www.pexue.com)专注于产品管理类课程的开发和制作,志在为产品经理、交互设计、平面设计、需求人员分享最新、最好的产品类课程。

    展开全文
  • 产品需求文档是产品人员非常核心的基本功!是协调研发、测试、UED、业务非常重要的重要工具。但是,往往很多新入行的PM与互联网领域的PM,产出的文档往往不尽人意,主要体现在: 缺乏逻辑,语言啰嗦精练; ...

    一、简述

    产品需求文档是产品人员非常核心的基本功!是协调研发、测试、UED、业务非常重要的重要工具。但是,往往很多新入行的PM与互联网领域的PM,产出的文档往往不尽人意,主要体现在:

    • 缺乏逻辑,语言啰嗦不精练;
    • 通俗的用词过多,整体显的不专业;
    • 无法将字段的数据结构、逻辑关系清晰的表达出来;
    • 缺乏开发思维;

    而出现这种原因在于:

    • 新人入职,没有经过严谨的文档撰写、流程设计训练;
    • 大多数的PM非研发出身,对前后台的业务逻辑、数据结构了解不清晰;
    • 分工细,版本迭代迅速,对功能点理解不够透彻;

    完善的产品需求文档,不但利于PM对所承接的功能进行有效的管控,将业务逻辑梳理清晰,对分解的功能点,进行协调测试、研发、设计、运营同时开展工作;

    20160605154019

    模块化的功能点(倒爷当年做的一个功能)

    虽然,不同的公司拥有不同的产品需求文档模板!但,不论模板格式如何,文档的本质在于:“有效的将功能清晰的表达出来,并且能支撑后续的业务交接与版本迭代参考,对上与下进行价值传递。"并且,随着平台业务的发展,归档、仓储起来的业务文档,便是极其有价值的知识库,里面汇总了各个时期里PM、研发、测试、项目经理、设计….对业务是如何进行思考,对文档研究的本身,侧面也反应了企业是如何将战略进行细节落实。

    而,“业务描述、功能描述、其它需求”是组成产品需求文档非常重要的模块;本篇章,将以通用版的角度,对这些模块行介绍;

    二、业务描述

    任何的业务或需求,都有业务提出方,业务提出是相关的业务部门或产品经理自身。

    业务来源的本质,便是希望通过这个业务解决那些实际的问题,达到提升某些转化率或某些目的;业务描述清晰的表达出来即可,不需要多复杂,但常规包括:

    • 业务背景
    • 产品功能概述
    • 产品前景分析
    • 产品功能整体流程
    • 产品逻辑关系
    • 面向对象
    • 应用对象
    • 名词解释
    • 参考文档

    上述的这些层面,以通用版的角度,将产品的价值传递给研发方与业务方,实现之间有效的衔接。

    为什么,我们需要进行业务、功能、概述这些偏宏观不实际的描述呢?这样不是很麻烦,且浪费时间?

    我们要知道,每新增或删除一个功能,狭义来看也没啥大不了。但站在宏观的角度去看,功能研发是需要耗资企业运营成本。如果处理不完善,浪费运营成本同时,甚至影响整个用户体验与开发规则。

    身为产品人员在未传达产品的业务价值前提条件下,便强势驱动研发人员进入开发阶段,这是错误的!我要是研发,我也会拍死这位PM。那么业务描述的本质便很清晰了,便将业务价值,传递给团队成员。

    另一方面,非常多的企业,内部的项目流程是不完善的,且并非每一位研发人员都是善类。产品经理往往需要兼备着项目经理的职责,推动着项目实现研发上线。在这种情况下,如果业务价值描述不清晰,功能在开发与上线后出现问题,这个锅注定是要背的。

    BTW,这些我就不都说了,自己工作中慢慢积累!

    下面,我对组成业务描述的组成元素进行描述:

    业务背景描述:

    这里,你必须将业务提出方描写出来,并且细致到业务方为什么将这个需求提出来!为什么?一方面,你要告诉研发人员,你为什么设计这个产品或功能,这个需求从来源到设计是有原因的。另一方面,拉上相关业务部门,你至少不是一个人在战斗。

    产品功能描述:

    对当前功能进行概述,所设计的产品或功能的功能模块,新增、完善、优化那些产品功能;

    产品前景描述:

    本产品或功能,希望对那些转化率指标或实现那些目的;

    产品的整体流程:

    Visio、Axure(Axure画的流程图好丑)。

    通过而言,简单的需求将主业务流与逻辑关系流表达出来便可以;但涉及复杂的业务,便将产品或功能涉及的主要流程绘制出来;而流程目的,主要是清晰的将前后台的逻辑关系与数据结构表达出来;一方面方便开发理解业务与数据流,另一方面也方便产品人员梳理自身需求的业务逻辑;利于后续与研发进行沟通。

    具体的流程数量,根据业务的复杂程度决定,一般只需要将核心的流程绘制出来便可;

    • 前台:主要是交互、数据流程;
    • 后台:主要是业务逻辑判断、数据流;

    前后台的流程凑在一起,能清晰的看到前后台的模块之间,是如何进行耦合的,数据储存、提取、处理、分析。

    功能框架:

    Mindjet Minmanager、Xmind画的框架图好丑。

    框架图的意义在于,能让查看或了解业务的人,全方位的了解功能之间的功能点的逻辑关系。同时,一份优秀的框架图,能让PM站在全局的基本面上,对个人所负责的产品进行全局的规划,对前后台的功能进行把握,达到支撑平台业务。

    • 产品架构:对前后台的各个系统与管理模块的逻辑关系,一般是对业务极其熟悉的业务构架师与资深的产品总监搭建,里面涉及每个接口如何进行对接耦合。
    • 功能架构:所负责的产品或功能的前后台功能的逻辑关系,简单点的就是一个产品或功能的前后台,大一点就是一个系统涉及的功能点之间的耦合。
    • 功能框架:功能点所涉及的逻辑关系。
    • 功能结构:功能点所涉及的逻辑关系。

    而“架构、框架、结构”区分在于,所负责的业务究竟有多大。但不论如何,它们的表现的原理是一致的。将分解的功能点,之间是如何联系的功能结构关系清晰、简练的表达即可。

    关于架构,包含“功能分解、面向用户”就够用了。若再深入,可将分为:“应用对象、BI分析(BI需求也写上去)、系统集成….”。后续可根据BI数据,对产品进行版本迭代与优化。

    面向对象

    表达产品或功能主要是为那类用户服务的。将面向用户是谁,拥有哪些权限清晰的表达出来即可,对个人进行功能设计也有很大的帮助。

    应用对象

    本功能需要在那些应用端或版本进行上线,清晰的描绘出来,方便后续进行业务交接。

    名词解释

    将本次文档涉及一些奇葩的明词进行解释,这点很重要!有些PM喜欢将一些非常简单的内容包装成非常牛逼,让人看起来很难懂,而事实上也就做哪些一件简单事,但是看的人会很痛苦:看PRD时会想:“这玩意,究竟想表达什么。

    参考文档

    将所做的本次功能,所参考的那些文档,附属上来;目的的在于,方便后续的业务方、研发方进行查看。

    三、功能描述

    功能描述能否描写清晰,描写清晰,开发找茬都不怕了。如何才能完整的对功能点进行描述呢?围绕三个点“功能是谁?功能来自哪里?功能要到哪里去?

    同时,功能需求主要分为核心功能、其它功能。不论是核心功能还是其它功能,都可以由以下元素构成:

    • 功能名称
    • 面向用户
    • 用例图(Axure、mocking(适合移动端进行敏捷性开发))
    • 前置条件
    • 后置条件
    • 功能简述
    • 详情描述

    而具体的功能描述内容,则根据业务(功能点)的复杂程度,进行筛选描写。可以全写,也可以不全写。但务必记住:不论何种方式,目的在于将业务价值完整、清晰、有条理的传递给查看文档的参与角色。

    功能名称(我是谁)

    本功能在系统里的命名。

    面向用户

    本功能的使用对象。(在前台,功能的参与者是少数的;但后台与企业级应用里,功能的参与者是多个的)

    用例图

    表达功能在表现层的逻辑图;可以是传统意义上的用例图,或者是简化版的原型图、流程图;

    前置条件(我来自哪里)

    使用该功能的前提、逻辑关系说明;公司大了后,每个开发都只写个人所负责的业务,所以一定要将每个模块来源都清清楚楚的表达出来,方便开发之间的衔接。

    后置条件(我要到那里去)

    使用该功能后,对业务、数据功能,产生的影响与结果;

    功能简述

    描写本功能需要实现的商业价值或目的;

    详情描述

    将功能”我怎么来,我怎么去“清清楚楚的表达出来。变成计算机逻辑便是,页面布局、操作逻辑进行详细的说明。常规而言:

    • 前台:主要是字段、交互逻辑组成;
    • 后台:主要是判断逻辑、列表表单、查询条件、交互逻辑组成;

    四、其它功能

    其它功能目的在于,功能描述针对于本次产品功能的核心业务,而其它功能针对于触发或需要其它功能变动的业务。功能描述清晰的让开发了解核心,而其它功能便让开发清晰的了解非核心。

    而其它功能,主要由以下内容组成

    其他接口

    对其它系统产生“字段、业务流程”进行说明;本次产品或业务,对前后台那些非主流程模块产生影响;

    系统风险评估

    当前设计的功能存在哪些缺陷、注意事项与后期的功能拓展如何解决这些问题;

    其它需求

    对一些非核心的功能点进行详情描述。如:一些需过滤的关键字、新增某个栏目字段。

    五、综述

    通过上述内容,能以通用版的形式,清晰的将所负责产品与功能表达出来,而业务描述、功能描述、其它功能。是产品需求文档重要的组成部份,将产品需求较为全面、有效的描述出来。

    同时,能训练PM逻辑思维,提升文字表达能力、业务理解能力,从整体上让PM在需求管理上,明显更加专业,所负责功能的逻辑关系、数据流的来与去都能很好的把控。

    六、附语

    不论是什么格式,倒爷坚持一个观点,适合团队才是好的模板。当前很多的公司在进行MVP迭代的时候会使用Axure+内容描述的形式。虽然,这种形式,是很难将逻辑关系表达清晰,同时会有非常多的思维漏洞。在进行文档归档时,也很难对根据关键字进行检索。但,确实挺适合进行MVP迭代,出现问题修改起来也方便,这种方式比较适合项目流程完善的企业平台使用。

    而在敏捷性开发汇总,倒爷习惯流程图+功能框架(功能点)+Axure(原型图绘制),从核心的业务流开始,逐渐迭代至功能完善,这个过程也将文档补齐。

    但有些公司会在EXCEL里进行需求文档撰写,进行版本管理(这个也不错)。

    但,作为新人,需要记住:你能写复杂的东西,简单的东西也能能写;但当然一开始只写简单的东西,那你一辈子只能做简单的东西。

    大道至简,简难而繁易;经历过复杂的训练与要求,才能简化再简化。

    展开全文
  • 其实每一个产品经理的内心深处,都有着一颗文艺青年的心灵,也正是拥有了这样一颗感受丰富、体验细腻的产品之心,才使得我们能够对产品设计的细节有着更为透彻和深入的理解。

    经历了漫长的产品设计流程,我们终于来到了最后一个环节,也就是根据之前梳理的产品流程来进行产品的界面设计了。

    产品经理其实都知道,在这样一个看重颜值的时代,一个赏心悦目的网站(或者移动APP)是多么重要。每一个产品经理,也都希望自己创造的产品是与众不同的,在茫茫的互联网产品海洋里,能够闪射出耀眼的光芒,就好比每个人都希望自己是人群中独一无二的那一个。嗯,这么说来,其实每一个产品经理的内心深处,都有着一颗文艺青年的心灵,也正是拥有了这样一颗感受丰富、体验细腻的产品之心,才使得我们能够对产品设计的细节有着更为透彻和深入的理解。

    在大公司内部,通常来说不需要产品经理去进行具体的界面交互设计,多数是由产品团队与UED团队合作进行产品原型的设计,出具的交付物是产品原型和页面交互图,而产品经理则需要产出市场需求文档(MRD文档)和产品需求文档(PRD文档)。但是在绝大多数创业公司团队里面,则没有配置那么豪华的产品设计、交互设计团队,常见的搭配往往是一个产品经理加上一个UI设计师,所以一般都是产品经理自己身兼交互设计的工作职责,输出交互设计稿,也就是产品原型。

    什么是产品原型

    说的简单一点,产品原型是设计方案的表达,是产品经理、交互设计师的重要产出物之一,也是项目团队的其它成员(尤其是设计师、开发人员)的重要参考和评估的依据。

    结合我们前面了解的知识,产品界面原型其实就是页面级别的信息架构、文案设计、及页面和页面之间的交互流程,它是产品功能与内容的示意图。

    直接上几个原型图,可能会更加清晰明了,如下图:
    原型设计稿

    产品设计原型按照精细程度来分,可分为低保真产品原型和高保真产品原型、设计成品。

    低保真产品原型

    所谓低保真原型,其实是对产品较简单的模拟,它只是简单的表述了下产品的外部特征和基本功能构架,很多时候都是用简单的设计工具迅速制作出来,用来表示最初的设计概念和思路。

    比如用纸和笔进行的手绘,用画图软件做出的简单线框图,都算是低保真产品原型。

    这样的原型图有几个好处:
    1. 可以快速产出:有时候一个需求的开发周期很短,低保真原型可以快速满足研发同事的时间要求;
    2. 修改成本低:一个产品策划很可能会被修改很多次,低保真的原型修改起来很方便。当然,低保真原型也会有几个问题,比如交互细节不清楚,整体界面粗糙容易造成误解等。

    通常来说,一般只有时间比较紧迫,需求也比较简单的时候,我们才会去产出低保真产品原型。

    高保真产品原型

    高保真产品原型,则是高功能性、高互动性的原型设计,是忠实展示产品功能、界面元素、功能流程的一种表现手段。原型图中无论是功能模块的大小,还是文案设计甚至是所用的图标、图例、交互动作,都使用真实素材,或者说和最终UI设计师的产出非常接近,就算是高保真产品原型了。

    高保真的好处:
    1. 便于梳理产品细节:制作高保真原型的过程中可以让产品经理提前发现产品潜藏的各种问题,提前处理风险;
    2. 更容易让其他成员了解产品设计:有时候简单的线框图无法让别人想象出你要做的事情,也不清楚你要放的是哪几个字段,具体的文案是什么,而高保真原型就可以。

    相对而言,劣势就是制作周期比较漫长,涉及到产品流程的修改,那基本上原型就得回炉重造一遍。

    对于刚入门的产品经理,我的建议是如果有时间的话,还是尽可能多的画高保真原型。因为在一开始产品设计经验不多的情况下,通过设计一些高保真原型,对梳理自己的产品思维、了解产品设计是很有帮助的。对于已经入门很久的同学来说,则看需求的复杂程度和时间安排,比如产品的关键页面是必然要用高保真原型去设计和梳理的,至于要不要亲自上阵,则可以结合设计资源及团队实力来进行安排。

    设计成品

    设计成品在这里,你也可以理解为是视觉设计师产出的UI设计稿,也就是设计师对你的产品原型进行美化之后得出的作品。设计师会运用一定的设计规范,来将你的原型变成可以让前端开发进行代码实现的作品。

    在设计成品出来的那一刻,产品经理需要做的就是和设计师进行PK就好了,无论是产品主题色的选择,还是页面布局,甚至是交互按钮和控件,都是你们需要讨论的话题。

    放上一张图来比较下三种原型的区别:

    三种原型比较

    原型设计工具

    工欲善其事,必先利其器。好的原型设计工具,总是能大大提高我们的产出效率。产品经理在日常的工作中,其实也应该多多体验一些互联网工具产品,一方面可以让自己的产品感提升,另一方面,也可以通过体验产品来了解工具属性,从而更好地将工具利用起来。这里给大家介绍几款产品设计常用的原型设计工具:

    1、Axure RP ,推荐指数✦✦✦✦✦
    Axure官网

    Axure RP是一个专业的快速原型设计工具。Axure(发音:Ack-sure),代表美国Axure公司;RP则是Rapid Prototyping(快速原型)的缩写。Axure是产品经理的必备工具,其他的不多说了,去看看招聘网站上关于PM的招聘信息,基本所有职位描述里,都包含了这么一句“熟练使用Axure”,所以这款工具的重要性你懂的。

    2、墨刀,推荐指数✦✦✦✦
    墨刀

    墨刀也是一款原型设计软件,虽然可能功能没有那么完整,相对来说对于一般使用也是足够的,目前分为网页版和客户端,网页版可以直接使用,客户端其实也是网页版的功能,一般来说会下载客户端,使用过程中需要联网。

    墨刀相对来说有这么几个优势:1、简单、易上手;2、支持团队多人协作;3、控件什么的都是现成的;4、可以直接在手机上进行预览;

    当然缺点也很明显:1、依赖网络,网络不稳定或者服务器不稳定的时候则没法使用,这点有点让人崩溃,比如说原型设计到一半突然断网了,则没有保存;2、很多交互功能不够强大,还不能像axure那样实现复杂的交互和跳转;

    3、Visio,推荐指数 ✦✦✦
    很多老牌的产品策划人员、产品经理都使用过它来设计产品原型,算是线框图专业户,比较灵活,Office使用习惯接受程度较高。另一个好处是支持各种平台尺寸设计。有些产品设计团队从原先的Axure 调整至 Visio ,是因为Visio 可以更便捷地输出标准大小的PDF文档,方便在同事之间交流。

    在学习伊始,很多刚刚入门的产品新人比较热衷于上网找课程学习Axure等原型工具的使用,乐此不疲;他们都希望通过精通工具的使用能力,来提高自己的职场竞争力。然而这并不是重点,工具只是用来承载和描绘我们思想和内容的一个画笔,所以没有必要把太多的时间消耗在掌握工具的使用技巧上,产品设计的主题、内容、规划才是真正需要用心去考量和思索的。这就好比武侠小说里的故事一样,没有深厚的内功心法,即使拥有好的武器,也发挥不了太大的作用。

    设计原型时需要注意的事项

    通过上面的介绍,其实我们已经了解了,一个好的产品原型可以让其他人迅速理解我们想要做什么事情,减少团队的沟通成本,并确保接下来要推进的事情没有什么误会。

    产品经理在将原型图画好之后,往往会特别欣喜,恨不得立马就让全体团队成员看到自己的设计成果。但是,这时候的原型图通常是不完整的,很多场景、因素缺少考虑,小到一个按钮的位置,字段展示、大到功能的流程设计、逻辑设计,都缺乏系统地思考和完善。如果你就轻易把这么一份不完整的原型交付给技术,不但技术会喷你,搞不好用户也来喷你,甚至Boss也来喷你。所以,打磨好产品原型,尽量考虑各种场景、因素,设计原型时尽量细化分析,让所有人从原型就能看到你的态度,是一件非常重要的事情。

    总体来说,原型设计需要表达清楚这么几个地方:

    1、界面元素

    什么是界面元素,比如文字,下拉框,按钮,图标、图片等等这些都属于界面元素。我们在运用原型设计工具(如axure、墨刀、visio等)设计产品原型的时候,需要明确界面上的元素是什么,如何展现,鼠标移动或者手势滑动、点击上去是怎样的效果。

    2、数据逻辑

    这一点往往也是非常多创业团队和新手产品经理容易忽视的。比如一个直播列表界面,上面有三个tab,分别是关注直播、热门直播、最新直播,那么最新直播是基于怎样的数据逻辑获取的,你就需要在你的原型设计上进行说明了。当然,最新直播的数据获取逻辑是比较简单的,也许你不和研发人员说明清楚,他们也能知道是按时间倒序排列;但如果碰到稍微复杂一点的数据逻辑呢,就比如刚刚说的关注直播的数据获取,是获取关注的机构的直播呢,还是获取个人的直播呢,这都是需要通过注释来说明清楚的。

    3、操作逻辑

    一个原型界面上可以进行操作元素的有哪些,哪个可以点击,哪个可以选择,操作后出现怎样的反馈,比如弹出浮层?进入新页面?或是跳出新页面?还是给一个怎样的提示?这些也是需要在原型设计里面说清楚的。

    这三个点是一份完整的原型设计基本需要包含的东西,再配合上之前画好的产品结构脑图和流程图,就基本可以与开发进行轻松愉快的交流了。只有这样,开发者才能明确这个原型设计的开发需求,而不是让开发工程师自己去猜,去揣测数据逻辑、算法应该是什么样的、具体的产品交互方案如何。

    如下图,可以在原型设计上做相关的注释说明:
    原型设计说明

    谈谈产品需求文档(PRD文档)

    与产品原型一样,产品需求文档也是支撑产品经理与团队沟通的重要工具。很多公司都要求产品经理写产品需求文档,撰写产品需求文档是产品经理日常工作中,非常重要的一部分。需求文档的质量好坏,直接影响到研发部门是否能够明确地了解产品定义和产品功能、逻辑。我们来看下一份完整的产品需求文档包含哪些部分:

    产品需求文档内容

    通常来说,产品经理往往不会写的那么详细,能够覆盖到前面四个部分便已经算是一份基本合格的产品需求文档了。

    我们一起来看下文档里面都具体包含什么内容:

    1.概述

    概述部分是概括地说明产品背景、产品目标等。

    1.1产品概述及目标—-包括背景介绍和产品目的

    1.2名词解释—-声明文档中出现的名词含义

    1.3数据词典—-介绍本产品中数据的数据项、数据结构、数据流、数据存储、处理逻辑、外部实体等。

    1.4文档阅读对象—-声明本文档输出的阅读对象和注意事项

    2.产品描述

    产品描述介绍了产品的整体逻辑流程,概括性的描述产品需求、产品版本规划、产品整体的框架结构以及功能列表。产品整体流程与产品框架都需要使用相应的图表展现方式

    2.1产品整体流程-—展示产品框架图和用户流程图。

    2.2产品需求描述—-描述产品核心功能,解决哪些情景下的哪些需求。

    2.3产品版本规划—-叙述产品版本迭代计划,版本号、主要模块、功能点、计划开发时间、计划结束时间、备注。

    2.4产品框架—-展示页面层级及备注信息

    2.5功能列表—-展示产品功能名称、对应模块、功能说明、备注等信息。

    3.功能描述

    功能需求这部分需详细描述产品所涉及的各个功能点。将整体框架拆成数个独立的功能点,分别描述每个功能点的逻辑流程图、界面、字段说明以及业务说明。统一采用UseCase的方式进行描述。

    3.1流程图——包含流程图、顺序图和状态图等,这三种图都可以理解为UML图

    3.2界面原型——将产品概念具象化,也就是将交互原型设计稿贴上去

    3.3字段说明(包括数据字典)——描述产品功能页面包含哪些字段,字段的格式和限制要求等

    3.4业务说明(Use Case)——描述产品的业务场景及相关用户角色说明

    4.非功能需求

    非功能需求,也就是关于产品的其它方面的要求。

    4.1安全需求——能够抵挡住黑客的攻击,保证用户的数据不会丢失等

    4.2统计需求——梳理产品的埋点、统计需求,明确需要统计的相关指标

    4.3性能需求——产品最大并发数等

    4.4可用性需求——产品的加载速度、响应速度、浏览器的兼容性等

    产品需求文档

    嗯,我们已经看到了常规的产品需求文档长什么样了。有一次和一个朋友聊天,说起他们公司的产品需求文档,是一份长达200多页的word形式的产品需求文档,其实这样的文档看起来相当费劲,也不容易更新同步;

    很多开发人员和产品经理之间产生的矛盾,其实都是因为这份又臭又长的产品需求文档。因为无论是谁,都不喜欢看这么长的文字,开发人员其实根本不需要这份文字式的需求告白书,他们喜欢“看图”,这种文字式的需求文档应该是产品经理脑中的思路,而不应该直接把思路描述成文字转交出来。其实我个人也不喜欢这样的风格,沟通成本太高,所以对于创业公司而言,还是尽可能简单直接有效最好。做好如上几点,对于大部分产品沟通场景来说,应该就可以得到满足。

    所以,通过输出产品结构脑图、产品流程图、界面原型加上相关的文字辅助说明业务、用户使用场景,就基本可以替代一份产品需求文档了。于是,你会发现越来越多的互联网公司产品经理已经开始使用Axure来撰写PRD了,这也可以理解为是对需求文档本身的一种认知迭代。

    产品设计的构思

    我们已经了解了原型的相关知识,也掌握了如何熟练地使用一款原型设计工具,那最后就可以进入到真正的原型设计实战阶段了。

    前面已经强调过,工具只是一种手段,关键在于设计的构思与设计背后遵循的产品设计原则,就像每个人手中都有一只笔,但具体写出什么主题、什么样内容的文章,则是写作者需要在动笔之前就好好思考清楚的了。产品经理说到底,也是一个艺术创作者,只不过这种创作是先理性,后感性。事实上,很多经典功能背后的设计都是有着更加深层次的构思和底层原理在驱动的。

    举个大家耳熟能详的例子,微信里面的“摇一摇”功能。

    初期版本的微信只有一个动作(还没有识别歌曲、电视的功能),甚至连按钮都没有,但是你看到图片依然会不由自主地去摇动手机,一个来福枪的枪声突然响起(这个声音非常性感),然后你会看到有一朵小花打开,最后就给你推送跟你同一时刻摇手机的人。这个体验的整个过程其实是非常严实的,它是一种人类的性暗示和性的驱动力在完成整个过程,弗洛伊德说,没有什么吸引你的驱动力比性的驱动力会更加原始。

    总结起来,“摇一摇”这个功能做的好,一方面是它确实做的比较简单,甚至连一个页面提示都没有,另一方面它让你用的很爽,这个爽是来自很深层次的原因,它其实带给了人类一种微妙的心理体验,非常原始的一种动力体验。当然,这也是一个科学,并不是一个道德低下的问题。

    我们再来看一个案例。

    假设你们公司是做SaaS产品,面向B端企业客户,现在要开始设计产品官网,你会从哪几个角度去进行构思呢?

    我们先来把简单能想到的几个点给列举一下:

    1、产品定位、产品功能介绍,让用户了解我们是干嘛的,能提供什么价值;

    2、客户案例,有哪些用户使用了我们的产品,取得了一个怎样的效果;

    3、帮助与支持,能提供的产品帮助与服务;

    4、价格,让用户了解产品的一个基本收费策略,是否分为若干种套餐;

    5、资讯、博客等,让用户了解产品的相关动态,及时获取产品信息;

    6、注册、登录按钮页面,让用户注册我们的产品进行体验;

    ……

    当然还有其它的点,在这里就不一一列举出来了。光看上面这些列举出来的点,可能我们还无法获知它们内在的逻辑是怎样的,但我们是否可以换一个角度去思考问题,比如把自己想象成一个用户,你在什么情况下会去购买一家公司的产品,成为这家公司的一个使用用户。

    大体逻辑,无外乎要经过这四个步骤:了解、信任、价值、转化

    用户首先需要了解这个产品是什么,才能确定自己是否有使用这款产品的需求,来决定自己是否有必要做进一步的认识和了解;接下来,是用户要能够信任这款产品,就好比你去参加会展,所有的展商都跟你说我们的产品多么多么好,但用户为什么要相信你呢,你有什么好的信誉背书吗;当用户对你产生了一定的信任,觉得你这个产品是靠谱的之后,你是不是应该让用户更深入地了解产品的价值,只有当用户真正认识到这款产品能够给他带来的价值之后,才能实现有效地转化。

    所以,我们会发现,上面列举的那些点,都是围绕着这几个方面来做的:

    了解:产品的定位、产品简单的功能介绍

    信任:客户案例、资讯动态

    价值:产品功能的详细介绍、产品价格、帮助与支持

    转化:注册、登录按钮,引导用户进行体验购买

    最后根据上面的设计思路,得出来的产品官网设计就是这样的,如下图:
    诸葛io产品官网

    其实,不仅仅是产品官网页面,在任何一个涉及到需要转化的页面,都可以使用这种产品设计思路,比如下图典型的电商里的宝贝详情页:

    天猫宝贝详情页

    你会发现,其实天猫里面的宝贝详情页的设计,也是围绕着“了解--信任--价值--转化”的设计思路在进行设计,我们也可以简单地来梳理一下:

    了解:宝贝的5张主图、宝贝的主标题、副标题、运费、尺码、颜色、库存;

    信任:宝贝月销量、商品累计评价、服务承诺、收藏商品的人气

    价值:价格、优惠活动、宝贝详情、送天猫积分

    转化:立即购买按钮、加入购物车按钮

    当然,这里涉及到一个转化率的概念,我们上面论述的范围都是从产品设计的角度去讲如何提高商品的购买转化率,如何提高网站的注册转化率、产品使用率等等。但是在实际的工作过程中,很多时候运营人员也会参与到转化率的数据提升上面来,他们可能会运用各种各样的运营数据模型,来进行分析和推演。比如通过漏斗模型,找出影响产品每个流程的细节因子,然后将所有影响因子都用数据工具监控起来,再来逐个优化,最后达到提升转化率的目的。这个时候就需要产品经理和运营进行团队配合,来共同提高产品的整体转化率了,产品和运营都能发表自己对于转化率的看法,但最后谁的方案奏效,依然是要看数据来说话。

    总结一下,说了这么几个案例,只是为了表达一个观点,那就是对于产品经理来说,每一个功能、页面设计的背后,都要有更深层次的思考。给产品做功能加法其实是很容易完成的一件事情,但如何只做少量的工作能起到最优的效果,如何实现“单点突破”,这个才是更能考验产品经理功底和深度思考能力的东西。我们平时在观察优秀的互联网产品的时候,也要试着去多问几个为什么,养成独立思考的好习惯,为什么这个界面是这样设计的,如果换一种设计方式,换一种交互逻辑,布局调整一下,元素的位置、大小互换一下,又会带来什么样的变化。

    分享两个产品设计原则

    简单,Don’t make me think

    什么是简单?张小龙说简单是一种审美观,我深表赞同。

    我们做产品是要做简单,不是说尽可能做得简陋一点,而是你脑袋里是不是有一种审美观念在这里。当你看到一个界面上密密麻麻铺满了按钮,你就知道这东西一点都不美,想要把它给简化一下。而且简单在许多行业和领域内都是通用的原则,比如以简洁为美进行产品设计的厂商MUJI和苹果,都是这方面的典型代表。

    那如何做到简单呢?

    一方面是要做到产品的信息架构简单,只有一个简单的产品架构,才能让人更清楚地理解产品的定位和价值,产品功能之间的逻辑关系和层级关系是怎么样的,我要如何操作才能完成我想要完成的任务;

    另一方面是界面简单,一个产品界面不要堆砌太多的元素。这里给个建议,就是尽量一个页面就表达一个主题,每个页面最终是要引领用户进行某一个操作,从导航到页脚都要围绕这一个目标来设计。这个和摄影很像,摄影讲究构图,一个构图就表达一个主题,这样一张照片的主题就会比较清晰。产品设计也是如此,一个页面就表达一个主题,实在不行,则退而求其次,做到一个页面有且只有一个主要的主题。这种目标上的一致性能够很好的帮助用户了解他们需要在网站或者APP产品上做什么,简单的选择往往能够让用户更轻松参与进来。

    简单直观的设计并不一定非得是极简的,它同样可以是丰富而又有趣的。但是简单而易用的页面的设计过程是需要用心做才能达成的,它需要具备高度的可用性和直观的设计,确保用户在使用的时候足够直觉、不会迟疑。

    以用户为中心

    每个产品经理和设计师时常挂在嘴边的一句话便是,要以用户为中心,产品是和人打交道,产品的用户体验很重要。

    既然我们都知道要以用户为中心,要设计好的用户体验,那么在原型设计好之后,有没有什么好的方法去测量一下呢?

    其实,产品经理在做完原型设计之后,可以多做一些可用性测试,这样可以更好地了解自己的设计是否符合用户的认知和操作习惯。可以将高保真的交互原型打印出来,制作成纸质原型,邀请用户完成产品典型任务,待验证功能点;也可以使用一些原型工具,比如腾讯团队出品一款叫做Demoo的工具,把原型放到手机上直接体验预览。

    这里再给大家简单科普下什么是可用性测试:

    可用性测试就是邀请真实用户或潜在用户使用产品或设计原型,对其在使用过程中的行为进行观察、记录、测量和访谈,进而了解用户对产品的要求和需要,并以此作为改进产品设计的出发点,提高产品的可用性。

    另一个老生常谈的地方是,到底是选择聪明,还是选择善良。

    “善良比聪明更重要”的观点源自于亚马逊CEO杰夫·贝索斯在2010年学士毕业典礼上发表的演讲。他追忆了自己的幼年岁月,讲述自己如何在儿时懂得了“善良比聪明更难”的道理;分享了16年前自己决定放弃优厚工作、创建亚马逊时的复杂心路。

    产品设计也是如此,你在做产品的过程中,到底是要不计一切地展示聪明,还是要选择善良。很多软件产品的安装过程中,都会使用下图这种增加软件装机量的手段,这就是一种典型的选择聪明的价值观。

    百度默认下载软件

    虽然我们在产品中,会有意无意地利用人性的弱点,去击中用户需求的要害,但是,不能把这种聪明过度化,而是需要站在一种坦诚的角度和用户对话,而不是给用户下套。就像选择朋友,大家可能都会认为善良更重要。同样地,用户选择我们的产品,也会如此。

    所以,我还是认为做产品要有道德底线,用小聪明去欺骗用户,用恶意营销去吸引用户下载,最终或许会有不少的关注量和点击量,但最终还是会被用户抛弃。

    展开全文
  • 2位复评专家中有1位以上(含1位)专家评议意见为“不合格”)的10篇硕士学位论文,请有关培养单位根据本单位的相关规定进行处理。对连续2年均有“存在问题学位论文”,且比例较高或篇数较多的学位授予单位,我厅将...

    点击上方“3D视觉工坊”,选择“星标”

    干货第一时间送达

    编辑丨中外学术情报

    研究生毕业越为越严!

    11月9日,湖南省教育厅发布《关于公布2019年湖南省研究生硕士学位论文抽样检查通讯评议结果的通知》,此次抽查发现32篇硕士学位论文“不合格”。

    《通知》要求,相关培养单位要对其所属学科和指导教师培养的研究生质量进行重点监控,省教育厅下一年度将继续抽检该导师指导的学位论文

    原文如下:

    关于公布2019年湖南省研究生硕士学位论文抽样检查通讯评议结果的通知

    湖南省教育厅

    有关学位授予单位:

    为进一步加强学位授予质量监督提高研究生培养质量,按照《国务院学位委员会 教育部关于印发<博士硕士学位论文抽检办法>的通知》(学位〔20145号)精神省教育厅对有关学位授予单位2018-2019学年度授予学位的研究生硕士学位论文进行了随机抽样检查所有抽检论文均送往省外同行专家进行了双盲通讯评议现将硕士学位论文通讯评议结果予以公布,并就有关事项通知如下:

    一、通讯评议结果是学位论文质量的一个客观评价是各单位研究生培养质量的重要体现。各单位将学位论文抽检通讯评议结果尽快告知相关研究生导师和研究生

    二、各单位研究生教育要围绕立德树人根本任务认真探讨如何有效地加强导师队伍建设,提高导师指导水平强化导师责任意识,合理确定导师指导研究生的数量确保培养质量。

    三、对此次通讯评议结果中有不合格评价等次(3位通讯评议专家中有1位专家评价结论为不合格)的32篇硕士学位论文相关培养单位要对其所属学科和指导教师培养的研究生质量进行重点监控,省教育厅下一年度将继续抽检该导师指导的学位论文对被评为存在问题3位通讯评议专家中有2位及以上专家评价结论为不合格或者3位专家中有1位专家评议意见为不合格加送了2位同行专家进行复评2位复评专家中有1位以上(含1位)专家评议意见为不合格)的10篇硕士学位论文请有关培养单位根据本单位的相关规定进行处理。对连续2年均有存在问题学位论文且比例较高或篇数较多的学位授予单位,我厅将进行约谈

    四、研究生学位论文抽检工作是我省学位与研究生教育的一项常规性工作请各培养单位认真分析学位论文抽检结果,根据学位论文的基本要求结合实际情况,制定并落实学位论文质量监控和提高质量的具体措施严把学位授予质量关。

    湖南省教育厅

    20201030

    来源 | 湖南省教育厅

    http://govnew.hnedu.cn:8090/zcms/contentcore/resource/download?ID=88716

    本文仅做学术分享,如有侵权,请联系删文。

    下载1

    在「3D视觉工坊」公众号后台回复:3D视觉即可下载 3D视觉相关资料干货,涉及相机标定、三维重建、立体视觉、SLAM、深度学习、点云后处理、多视图几何等方向。

    下载2

    「3D视觉工坊」公众号后台回复:3D视觉github资源汇总即可下载包括结构光、标定源码、缺陷检测源码、深度估计与深度补全源码、点云处理相关源码、立体匹配源码、单目、双目3D检测、基于点云的3D检测、6D姿态估计源码汇总等。

    下载3

    「3D视觉工坊」公众号后台回复:相机标定即可下载独家相机标定学习课件与视频网址;后台回复:立体匹配即可下载独家立体匹配学习课件与视频网址。

    重磅!3DCVer-学术论文写作投稿 交流群已成立

    扫码添加小助手微信,可申请加入3D视觉工坊-学术论文写作与投稿 微信交流群,旨在交流顶会、顶刊、SCI、EI等写作与投稿事宜。

    同时也可申请加入我们的细分方向交流群,目前主要有3D视觉CV&深度学习SLAM三维重建点云后处理自动驾驶、CV入门、三维测量、VR/AR、3D人脸识别、医疗影像、缺陷检测、行人重识别、目标跟踪、视觉产品落地、视觉竞赛、车牌识别、硬件选型、学术交流、求职交流、ORB-SLAM系列源码交流、深度估计等微信群。

    一定要备注:研究方向+学校/公司+昵称,例如:”3D视觉 + 上海交大 + 静静“。请按照格式备注,可快速被通过且邀请进群。原创投稿也请联系。

    ▲长按加微信群或投稿

    ▲长按关注公众号

    3D视觉从入门到精通知识星球:针对3D视觉领域的知识点汇总、入门进阶学习路线、最新paper分享、疑问解答四个方面进行深耕,更有各类大厂的算法工程人员进行技术指导。与此同时,星球将联合知名企业发布3D视觉相关算法开发岗位以及项目对接信息,打造成集技术与就业为一体的铁杆粉丝聚集区,近2000星球成员为创造更好的AI世界共同进步,知识星球入口:

    学习3D视觉核心技术,扫描查看介绍,3天内无条件退款

     圈里有高质量教程资料、可答疑解惑、助你高效解决问题

    觉得有用,麻烦给个赞和在看~  

    展开全文
  • 目前全国奶牛情绪稳定 作者:塘山村人 提交日期:2008-9-13 0:46:00三鹿事件得到妥善处理 目前全国奶牛情绪稳定 新华厕消息:三鹿事件发生以来,党和政府高度关注,要求全力救治伤员,处理不合格产品。...
  • 合格的程序员应该是怎样的?

    千次阅读 2009-12-12 15:43:00
    在这半年当中,我一点一滴地积累、一步一个脚印地实践,顺利完成了公司产品升级模式的转变,从原有的纯手工操作迈向半自动化的模式(服务器端通过工程人员维护,客户端实现自动安装自动升级);同时亦接手了公司的...
  • 图像处理之滤波算法

    万次阅读 2016-05-05 14:17:38
    一、学习心得: 在我学习基本滤波算法原理的时候,因为刚接触不是很理解算法具体是... 滤波算法,可以理解成一种过滤算法,就像我们筛选产品时,把次品去除掉,只留下合格产品。而在图像处理中的滤波算法中,处理
  • 合格CTO之二三事

    千次阅读 2012-08-14 17:23:48
    合格CTO之二三事  给CTO画个及格线本身就是件可能的事吧?!写出这个标题来也只是说想给这个线做个注释。做CTO以来一点点个人感悟吧算是!  首先要说CTO不是技术经理。如果只是处理某一方面的问题,比如建...
  • 合格的售前工程师

    千次阅读 2005-02-03 15:42:00
    合格的售前工程师1)认真规划自己的职业方向,选择一个行业时,是否真正对其有兴趣,与你的理想是否合拍?请慎重安排自己的职业道路,而选中了一条路,就要认真做下去,只有对一个行业有了深入地了解,你才有资格...
  • 软件产品研发总则

    千次阅读 2012-08-09 12:29:18
    这些原则和理念中的一部分同项目开发是一致的,部分则是相悖的,因此我们可以以项目的方式组织和推进产品研发,但是能完全用对待项目的态度去对待产品。 以做“精”为目标 一直以来,公司在产品研发中以实现...
  • 一个合格的程序员应该读过哪些书

    万次阅读 多人点赞 2012-08-14 15:59:34
    本书的产品设计应用神经生物学、认知科学,以及学习理论,这使得这本书能够将这些知识深深地印在你的脑海里, 容易被遗忘。 本书的编写方式采用引导式教学,直接告诉你该怎么做,而是利用故事当作引子,...
  • 一个合格的初级前端工程师需要掌握的模块笔记

    千次阅读 多人点赞 2021-02-04 09:43:23
    一个合格的初级前端工程师需要掌握的模块笔记 文章目录一个合格的初级前端工程师需要掌握的模块笔记前言Web模块html基本结构标签属性事件属性文本标签多媒体标签列表表格表单标签其他语义化标签网页结构模块划分CSS...
  • 典型委外处理

    千次阅读 2010-04-22 15:55:00
    产品的某道关键工序企业自有生产工艺满足了需求3.随着产品生命周期不断缩短,为了避免企业生产投资负担,某道工序外包低于自制成本4.企业产品线长, 可以将非核心的业务外包以降低成本等等。对于这种半产品
  • 做一个合格的Team Leader -- 基本概念

    千次阅读 2015-05-20 13:41:34
    他们喜欢被管理,喜欢像牛一样被驱赶或指挥。 管理者强迫人们服从他们的命令,而领导者则会带领他们一起工作。 管理是客观的,没有个人感情因素,它假定被管理者没有思想和感受,必须被告知要做什么和该如何...
  • 对于刚入行的产品经理来说,首先要思考的,并是如何去做一个改变世界的产品,而是想清楚,哪些体验让用户感觉是负分? 新人产品经理首要思考的问题是:完善自身的知识体系,优化现存问题的体验。 因此,新人...
  • 产品管理职位的级别都有哪些

    千次阅读 2011-10-17 16:42:21
    在我正睡得稀里哗啦的时候,手机的短信响了,真够烦人的,睡觉关手机本不是我的习惯,但是以前的公司要求这么做,美其名曰是“可以随时找到产品经理”,我就纳闷了,大晚上的找产品经理干什么。 但是你还不得...
  • 如何画出一张合格的技术架构图?

    万次阅读 多人点赞 2019-04-11 09:23:57
    如何用一张图描述我的系统,并且让产品、运营、开发都能看明白? 画了一半的图还清楚受众是谁? 画出来的图到底是产品图功能图还是技术图又或是大杂烩? 图上的框框有点少是不是要找点儿框框加...
  • YES!产品经理(上、下册)

    千次阅读 2011-10-14 16:19:47
    产品经理(上、下册)  汤圆 编著 ISBN978-7-121-14107-2 2011年9月出版 定价:128.00元(上、下册) 16开 904页 内 容 简 介 这是一本融合了经管、工具和职场小说特点的图书,作者是国内产品经理咨询界...
  • 偶然性可重现BUG怎么处理

    千次阅读 2005-03-24 15:45:00
    偶然性可重现BUG怎么处理? 在软件工程论坛上,kasad“问偶然性可重现BUG怎么处理?”我和一些网友进行了讨论,下面就是整理的一些记录,主要是me的。原帖参看:...
  • 产品经理的职业发展路线是什么

    千次阅读 2011-10-17 16:54:00
    产品经理的职业发展路线是什么   几日无事。 人一旦心中无虑,看什么都是美好的,就连早上煎饼摊摊的煎饼都觉得是最好吃的,尽管摊煎饼的大姐总是习惯于用一只手收钱和递煎饼。 我甚至在想,当时要是和周扬说,...
  • 在对平衡的分类数据集进行建模时,机器学**算法可能并稳定,其预测结果甚至可能是有偏的,而预测精度此时也变得带有误导性那么,这种结果是为何发生的呢?到底是什么因素影响了这些算法的表现?   在平衡的...
  • 近期,江苏省镇江工商局对流通领域老人手机商品进行了专项质量监测,结果让人大跌眼镜:共抽检10批次手机,9批次不合格不合格率高达90%。 整体质量堪忧  据镇江工商局消保处负责人介绍,此次抽样检测的老人...
  • 产品经理是“通”才还是“专”才

    千次阅读 2011-10-21 16:38:52
    产品经理是“通”才还是“专”才     周五,刘宇到岗。 我协助郭姐姐把一切需要走的流程、需要办的手续都搞定后,我和刘宇坐在办公室等着周扬来开第一次部门会议。 当然,我知道以前我俩在办公室的交流算...
  • 在Android平台一般使用OpenGL ES进行图像处理。在OpenGL ES中编写算法,实现效果,最后将处理的结果传输给 CPU,然后生成最终的照片。直播中的美颜,对性能有很高的要求,无法使用特别复杂的算法。我们只能在算法和...
  • 产品开发的项目管理

    千次阅读 2015-10-14 15:10:06
    通过新产品开发的质量管理——严格控制新产品开发的质量控制,研发出质量合格产品;通过新产品开发的成本管理——在保证新产品质量和时间要求的情况下,以最低的成本,为企业赢得最大的利润。  [关
  • 从程序员到产品经理

    万次阅读 多人点赞 2018-07-13 16:11:36
    一直以来我都觉得自己是个典型性程序员。 比如出门时候我总是穿格子衫、牛仔裤,戴着黑框眼镜背个双肩包; 比如休闲时候我是个死宅,喜欢玩游戏和看小说;...就这样波澜惊的工作了几年以后,突然有一天我想...
  • 【转贴】合格的高级程序员

    千次阅读 2004-12-22 08:59:00
    那么作为高级程序员,以至于系统分析员,也就是对于一个程序项目的设计者而言,除了应该具备上述全部素质之外,还需要具备以下素质: 第一,需求分析能力 对于程序员而言,理解需求就可以完成合格的代码,但是对于...
  • WeTest导读 本文通过对内存泄漏(what)及其危害性(why)的介绍,引出在Unity环境下定位和修复内存泄漏的方法和工具(how...相信大家出门旅游,都有看过下图类似的标语,作为一名合格的程序猿,也应该能够处理好代码中...
  • 本文档对GMT 0062-2018 《密码产品...1. 产品形态说明 (对应标准第四章) 1.1 产品形态划分 (对应标准4.1节) 产品形态 特征 典型形态 上电用电情况 随机数检...
  • 合格的软件需求规格说明书软件需求规格说明作为产品需求的最终成果必须具有综合性:必须包括所有的需求。开发者和客户能作任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明那么它将能作为协议...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 29,637
精华内容 11,854
关键字:

如何处理不合格产品