项目管理

项目管理

软件项目的年度维护费用有没有什么标准,一般按照合同额10%这个数据怎么来的?

回复

默认分类admin 回复了问题 • 1 人关注 • 1 个回复 • 121 次浏览 • 2017-07-21 16:40 • 来自相关话题

经验贴:总结项目团队管理中踩过的几个坑

默认分类admin 发表了文章 • 0 个评论 • 124 次浏览 • 2017-04-06 08:27 • 来自相关话题

从2月份年后回来到现在4月份初,负责项目团队开始,慢慢地在项目团队管理中踩过了不少坑。自己也是在边学习边成长中去适应这个工作职责。

在这样一个职责中,作为一个团队中坚力量。要学会接受领导的批判和怒火,负责扛起整个团队的过错。学会接受团队中每个成员的小情绪,让他们更加的去完成好每一个工作。在这个过程中不断培养性格和能力的控制力。

一、个人层面

1、外部时间和内部时间

在外部时间和内部时间上没有协调好自己的工作时间,导致很多事情没有做好充分准备。每天的团队内部时间要负责协调好每个工作职能所要做的工作,并协作每个工作职能做到最好。在外部时间中,重在与各部门的协商和工作推进。明确各部门与本部门的工作交际协作和完成工作时间节点。在这样时间安排中,外部工作占20%,内部工作占80%。外部工作尽量协调在做好充足准备,植入主题,完成沟通。内容工作更加深入细节,保证正常运作。

2、先思考后做

很多事情,由于发生的太突然。反而缺少了需要思考的点。没有做到先思考后做。但是这样的情况发生时,需要充分进行快速思考,再行动。先思考后做,会让做事的效率进行提升,并会把很多细节点给充分思考到。

3、每天总结自己的问题

每天没有总结自己的问题。导致第二次,第三次反复出现同样的错误。每天对自己的工作内容进行梳理,并对团队内部的大家工作也进行梳理。去思考哪些不合理点和问题,并马上在第二天进行解决。反复总结和梳理中,提升自己发现问题的能力。

二、产品层面

1、需求文档是技术开发的核心

PRD文档往往影响开发的进度,一份好的文档可以让开发快速进行开发。清晰的逻辑线可以让开发节省很多时间专注于本身的开发实现方面。PRD还起到新来的产品经理进行学习和了解系统用。对于老的产品经理,也可以起到查被的作用。

2、产品版本迭代要抓住核心问题点

敏捷开发是最小开发化的单元,而非大规模开发量。在产品版本迭代中,需要抓住主要问题和次要问题,解决主要问题。特别对需求理解,可以更加深入某个细节点上去考虑。这样的版本迭代可以保持最高效的验证。特别是前端产品,需要不断进行验证。

3、外部沟通要保持协助和引导

外部沟通中,一旦发生没有准备或者引导,会处于沟通的下风,导致可能计划失控。所以在外部沟通中,要做好充分准备,再参加每一个会议。在会议中沟通,要保持非必要性的冲突性,带有可控制性的引导。

三、技术层面

1、细节点不够了解,没有找到合理方案

在技术项目跟进方面,需要与技术人员进行深入沟通。把遇到困难的细节点了解清楚,在清楚同时,与技术人员一起探讨找到解决问题的方案。没有合理的方案,那么碰到困难可能只能一味的拖延工期。

2、项目任务协作保证开发进度

在项目任务中,要合理进行项目任务发布和人员工作安排。这样才可以保证合理的开发进度。不可以因为某些细节点困难,导致整个项目速度延误。时刻关注任务燃尽图,保证项目任务。

四、项目层面

1、保持项目中每个节点控制

在整个项目中,分为产品阶段、设计阶段、开发阶段、测试阶段、上线阶段。对于整个项目阶段,必须在某个阶段中所有的问题点,都需要进行节点控制。特别是项目在相互交付阶段,是最容易出现问题的。

2、始终要让团队保持清醒目标

在团队推进过程中,团队成员会因为目标时间过长,导致失去对于目标的清晰。所以每天需要时刻提醒团队成员,我们的项目目标和进度。时刻让团队保持清醒的状态。这个是团队负责人最需要处理的。

另外,对于团队建设,一直处于最高的地位。团队团结可以势如破竹。一个团队彼此之间没有感情,是很难做成事情的。

在一辆行驶的火车中,作为动力发动力和火车头,如果脱节于整个火车组之外,那么整节火车将被颠覆。所以每一步都需要脚踏实地。

#专栏作家#

晓翼,微信公众号:上海人在北京。人人都是产品经理专栏作家。专注于电商、O2O的产品经理。会IOS开发、会P图、会运营的逗比一个。常关注社交、旅行类产品。

本文原创发布于人人都是产品经理,未经许可,不得转载。 查看全部
从2月份年后回来到现在4月份初,负责项目团队开始,慢慢地在项目团队管理中踩过了不少坑。自己也是在边学习边成长中去适应这个工作职责。

在这样一个职责中,作为一个团队中坚力量。要学会接受领导的批判和怒火,负责扛起整个团队的过错。学会接受团队中每个成员的小情绪,让他们更加的去完成好每一个工作。在这个过程中不断培养性格和能力的控制力。

一、个人层面

1、外部时间和内部时间

在外部时间和内部时间上没有协调好自己的工作时间,导致很多事情没有做好充分准备。每天的团队内部时间要负责协调好每个工作职能所要做的工作,并协作每个工作职能做到最好。在外部时间中,重在与各部门的协商和工作推进。明确各部门与本部门的工作交际协作和完成工作时间节点。在这样时间安排中,外部工作占20%,内部工作占80%。外部工作尽量协调在做好充足准备,植入主题,完成沟通。内容工作更加深入细节,保证正常运作。

2、先思考后做

很多事情,由于发生的太突然。反而缺少了需要思考的点。没有做到先思考后做。但是这样的情况发生时,需要充分进行快速思考,再行动。先思考后做,会让做事的效率进行提升,并会把很多细节点给充分思考到。

3、每天总结自己的问题

每天没有总结自己的问题。导致第二次,第三次反复出现同样的错误。每天对自己的工作内容进行梳理,并对团队内部的大家工作也进行梳理。去思考哪些不合理点和问题,并马上在第二天进行解决。反复总结和梳理中,提升自己发现问题的能力。

二、产品层面

1、需求文档是技术开发的核心

PRD文档往往影响开发的进度,一份好的文档可以让开发快速进行开发。清晰的逻辑线可以让开发节省很多时间专注于本身的开发实现方面。PRD还起到新来的产品经理进行学习和了解系统用。对于老的产品经理,也可以起到查被的作用。

2、产品版本迭代要抓住核心问题点

敏捷开发是最小开发化的单元,而非大规模开发量。在产品版本迭代中,需要抓住主要问题和次要问题,解决主要问题。特别对需求理解,可以更加深入某个细节点上去考虑。这样的版本迭代可以保持最高效的验证。特别是前端产品,需要不断进行验证。

3、外部沟通要保持协助和引导

外部沟通中,一旦发生没有准备或者引导,会处于沟通的下风,导致可能计划失控。所以在外部沟通中,要做好充分准备,再参加每一个会议。在会议中沟通,要保持非必要性的冲突性,带有可控制性的引导。

三、技术层面

1、细节点不够了解,没有找到合理方案

在技术项目跟进方面,需要与技术人员进行深入沟通。把遇到困难的细节点了解清楚,在清楚同时,与技术人员一起探讨找到解决问题的方案。没有合理的方案,那么碰到困难可能只能一味的拖延工期。

2、项目任务协作保证开发进度

在项目任务中,要合理进行项目任务发布和人员工作安排。这样才可以保证合理的开发进度。不可以因为某些细节点困难,导致整个项目速度延误。时刻关注任务燃尽图,保证项目任务。

四、项目层面

1、保持项目中每个节点控制

在整个项目中,分为产品阶段、设计阶段、开发阶段、测试阶段、上线阶段。对于整个项目阶段,必须在某个阶段中所有的问题点,都需要进行节点控制。特别是项目在相互交付阶段,是最容易出现问题的。

2、始终要让团队保持清醒目标

在团队推进过程中,团队成员会因为目标时间过长,导致失去对于目标的清晰。所以每天需要时刻提醒团队成员,我们的项目目标和进度。时刻让团队保持清醒的状态。这个是团队负责人最需要处理的。

另外,对于团队建设,一直处于最高的地位。团队团结可以势如破竹。一个团队彼此之间没有感情,是很难做成事情的。

在一辆行驶的火车中,作为动力发动力和火车头,如果脱节于整个火车组之外,那么整节火车将被颠覆。所以每一步都需要脚踏实地。

#专栏作家#

晓翼,微信公众号:上海人在北京。人人都是产品经理专栏作家。专注于电商、O2O的产品经理。会IOS开发、会P图、会运营的逗比一个。常关注社交、旅行类产品。

本文原创发布于人人都是产品经理,未经许可,不得转载。

做项目的时候,一般利益分配的比例是怎么样的?怎么样做才是妥当的

回复

默认分类admin 回复了问题 • 1 人关注 • 1 个回复 • 167 次浏览 • 2017-01-18 13:52 • 来自相关话题

5年项目管理工作经验工作心得

默认分类admin 发表了文章 • 0 个评论 • 134 次浏览 • 2017-01-01 18:30 • 来自相关话题

作者:aitilaowang
链接:https://zhuanlan.zhihu.com/p/20852368
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

一、要有较好的技术背景和成长经历,死磕自己,学习技术和管理(注重沟通、协调学习项目管理的铁三角),这样才能服务于团队成员,让团队成员心服口服。

二、交流问题时要放低姿态,此时不能把自己当成项目经理,要以技术服人、以理服人,切记摆出领导的架势;而在公司制度、管理方面要严肃,管理方面不能和大家嘻嘻哈哈,这样不利于项目和团队成员的管理。

三、定期和不定期和各位成员沟通,察言观色,了解成员的真正诉求和内心想法,能帮助他们解决的问题尽量帮助。及时疏导心里承受差的同事,排除不顺的情绪,关心特别个性、比较内向的同事,让他们感觉到大家是个整体,没有被边缘化。让他知道除了工作大家是同事,可以一起说说笑笑。

四、向上级领导(部门经理或者总监等角色)定期和不定期的汇报工作,让领导知道我们的项目进度和人力各方面的状态,尽量少给领导添麻烦,要想办法自己解决问题替领导分忧。项目经理要让上级领导真正放心,主动找领导汇报工作成果、进度。不要等领导来问你。

五、沟通、管理等要不卑不亢、不急不躁,表现出沉着稳定的状态。遇到问题不能急不能慌,团队成员或者领导告知你突发状况的时候不能自己都慌慌张张,这样不仅会让领导同事担心你的能力,更有可能被替代。你需要做的是时刻准备着问题的到来,遇到问题时拿出解决方法。技术问题有能力指导尽量指导,没有能力时要协调高级工程师、架构师等人员来解决;沟通问题要自己把握,要和直属领导沟通、和本项目组成员紧密沟通。有需要的情况下还要跨级沟通、跨部门沟通等等(要特别注意跨级汇报,紧急需要时一定要注意技巧。比如紧急情况需要领导决策而直属领导联系不上,这时候越级请示要事先说明直属领导联系几次联系不上等具体情况。总之要灵活对待)。 查看全部

作者:aitilaowang
链接:https://zhuanlan.zhihu.com/p/20852368
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

一、要有较好的技术背景和成长经历,死磕自己,学习技术和管理(注重沟通、协调学习项目管理的铁三角),这样才能服务于团队成员,让团队成员心服口服。

二、交流问题时要放低姿态,此时不能把自己当成项目经理,要以技术服人、以理服人,切记摆出领导的架势;而在公司制度、管理方面要严肃,管理方面不能和大家嘻嘻哈哈,这样不利于项目和团队成员的管理。

三、定期和不定期和各位成员沟通,察言观色,了解成员的真正诉求和内心想法,能帮助他们解决的问题尽量帮助。及时疏导心里承受差的同事,排除不顺的情绪,关心特别个性、比较内向的同事,让他们感觉到大家是个整体,没有被边缘化。让他知道除了工作大家是同事,可以一起说说笑笑。

四、向上级领导(部门经理或者总监等角色)定期和不定期的汇报工作,让领导知道我们的项目进度和人力各方面的状态,尽量少给领导添麻烦,要想办法自己解决问题替领导分忧。项目经理要让上级领导真正放心,主动找领导汇报工作成果、进度。不要等领导来问你。

五、沟通、管理等要不卑不亢、不急不躁,表现出沉着稳定的状态。遇到问题不能急不能慌,团队成员或者领导告知你突发状况的时候不能自己都慌慌张张,这样不仅会让领导同事担心你的能力,更有可能被替代。你需要做的是时刻准备着问题的到来,遇到问题时拿出解决方法。技术问题有能力指导尽量指导,没有能力时要协调高级工程师、架构师等人员来解决;沟通问题要自己把握,要和直属领导沟通、和本项目组成员紧密沟通。有需要的情况下还要跨级沟通、跨部门沟通等等(要特别注意跨级汇报,紧急需要时一定要注意技巧。比如紧急情况需要领导决策而直属领导联系不上,这时候越级请示要事先说明直属领导联系几次联系不上等具体情况。总之要灵活对待)。

技术人员如何确认web产品的需求

默认分类admin 发表了文章 • 0 个评论 • 118 次浏览 • 2016-12-30 10:33 • 来自相关话题

web需求定义涉及到展示和交互两个部分,展示是打开一个页面时呈现出来的页面效果,交互是用户通过鼠标,键盘,触摸或其他外设操作之后系统给出响应的过程。

对于页面的展示要从下面几个角度来确认需求。

一. 界面展示,需要确认展示的逻辑

1)展示逻辑通常要考虑不同的角色进入页面时候的显示是否一致,如果不一致,则要明确不同角色进来后显示内容的异同
2)对于有隐藏内容的控件,必须确认隐藏的内容,例如菜单,tab
3)对于每一个显示单元要确认显示数据的逻辑,例如“最热文章”,必须要确认这个最热文章是如何定义的,是按点击的还是按转贴的,还是其他逻辑,另外还要注意这个最热是否有隐含的时间范围
4)对于显示区域临界条件的确认,要确认数据不足时如何展示,数据字段过长时如何展示

二. 交互需求确认

什么是交互呢? 页面展示出来,用户通过鼠标,键盘,触摸或其他外设操作之后系统给出响应的过程就是交互。

对于传统的web最常见的交互是填写表单和鼠标点击。

我们可以先考虑表单需求的确认。 可以把表单性需求的确认分为三个阶段 1) 表单填写 2)表单的提交 3)表单提交后的响应

先来看表单填写需要确认的需求:

1. 对于输入性控件必须确认输入框是否必填,输入框是否需要格式校验,是否有最大长度限制,是否有相等性校验。
2. 对于选择性控件,也要明确是否有最多选择数,最少选择数,是否可以不填等边界条件
3. 另外要注意是否有键盘操作便捷的需求,例如按回车或Ctrl+回车提交,按tab键要到下一个表单元素
4. 是否需要在进入界面时自动focus到某一控件上
5. 当用户将焦点移向下一个控件时是否需要做交互判断(最典型的是注册用户填写用户名后自动校验用户名是否存在)

上面5点前两点是边界条件的确认,第3,4是便捷性需求的确认,第5点是用户友好性的确认

表单填写完毕用户就可以提交表单了,提交表单有异步和同步两种方式,最好给产品经理确认提交的方式,另外还要评估表单提交是否涉及到耗时的操作,如果操作很耗时,应该要求产品经理给出应对用户等待焦虑的方案。

最后需要明确表单提交之后需要明确后端处理的业务逻辑,和处理成功或者失败之后的提示或页面跳转。

除了表单之外最常见的交互是鼠标点击,例如点击删除链接,删除一条记录,这时候要确认点击前需要客户端如何响应,点击服务器收到成功响应后如何显示,失败时如何显示。

对于一个系统来说添加或者修改一个功能点,往往会影响其他功能点,在做需求确认时还要明确当前操作会影响到地方,影响是什么样子的,如果因为性能原因使用了缓存,要给产品同事明确缓存时间。

总结:

技术人员在确认需求是要考虑界面效果,要考虑显示逻辑,也要考虑后台的业务逻辑,以及当前需求点操作逻辑对其他地方的影响。

必须在确认需求阶段就充分考虑好界面显示的边界条件,用户输入的校验条件,用户交互的显示逻辑,有错误发生时的处理。

业务逻辑中一定要考虑到当前用户是否分了角色,操作的对象是谁,这个需求是否有时间范围,操作是否有其他的前提条件,是否影响到其他地方。 查看全部
web需求定义涉及到展示和交互两个部分,展示是打开一个页面时呈现出来的页面效果,交互是用户通过鼠标,键盘,触摸或其他外设操作之后系统给出响应的过程。

对于页面的展示要从下面几个角度来确认需求。

一. 界面展示,需要确认展示的逻辑

1)展示逻辑通常要考虑不同的角色进入页面时候的显示是否一致,如果不一致,则要明确不同角色进来后显示内容的异同
2)对于有隐藏内容的控件,必须确认隐藏的内容,例如菜单,tab
3)对于每一个显示单元要确认显示数据的逻辑,例如“最热文章”,必须要确认这个最热文章是如何定义的,是按点击的还是按转贴的,还是其他逻辑,另外还要注意这个最热是否有隐含的时间范围
4)对于显示区域临界条件的确认,要确认数据不足时如何展示,数据字段过长时如何展示

二. 交互需求确认

什么是交互呢? 页面展示出来,用户通过鼠标,键盘,触摸或其他外设操作之后系统给出响应的过程就是交互。

对于传统的web最常见的交互是填写表单和鼠标点击。

我们可以先考虑表单需求的确认。 可以把表单性需求的确认分为三个阶段 1) 表单填写 2)表单的提交 3)表单提交后的响应

先来看表单填写需要确认的需求:

1. 对于输入性控件必须确认输入框是否必填,输入框是否需要格式校验,是否有最大长度限制,是否有相等性校验。
2. 对于选择性控件,也要明确是否有最多选择数,最少选择数,是否可以不填等边界条件
3. 另外要注意是否有键盘操作便捷的需求,例如按回车或Ctrl+回车提交,按tab键要到下一个表单元素
4. 是否需要在进入界面时自动focus到某一控件上
5. 当用户将焦点移向下一个控件时是否需要做交互判断(最典型的是注册用户填写用户名后自动校验用户名是否存在)

上面5点前两点是边界条件的确认,第3,4是便捷性需求的确认,第5点是用户友好性的确认

表单填写完毕用户就可以提交表单了,提交表单有异步和同步两种方式,最好给产品经理确认提交的方式,另外还要评估表单提交是否涉及到耗时的操作,如果操作很耗时,应该要求产品经理给出应对用户等待焦虑的方案。

最后需要明确表单提交之后需要明确后端处理的业务逻辑,和处理成功或者失败之后的提示或页面跳转。

除了表单之外最常见的交互是鼠标点击,例如点击删除链接,删除一条记录,这时候要确认点击前需要客户端如何响应,点击服务器收到成功响应后如何显示,失败时如何显示。

对于一个系统来说添加或者修改一个功能点,往往会影响其他功能点,在做需求确认时还要明确当前操作会影响到地方,影响是什么样子的,如果因为性能原因使用了缓存,要给产品同事明确缓存时间。

总结:

技术人员在确认需求是要考虑界面效果,要考虑显示逻辑,也要考虑后台的业务逻辑,以及当前需求点操作逻辑对其他地方的影响。

必须在确认需求阶段就充分考虑好界面显示的边界条件,用户输入的校验条件,用户交互的显示逻辑,有错误发生时的处理。

业务逻辑中一定要考虑到当前用户是否分了角色,操作的对象是谁,这个需求是否有时间范围,操作是否有其他的前提条件,是否影响到其他地方。

不可能完成项目的Scrum实践

默认分类admin 发表了文章 • 0 个评论 • 122 次浏览 • 2016-12-29 21:26 • 来自相关话题

  某一天老板或者销售人员跑过来亲切和蔼地拍拍你说:有个战略性产品需要在一个月之内开发出来,对搞定几个重点大商户至关重要,时间没有商量的余地。党组织从众多的党员同志中选择了你,这是党对你的信任,也是考验你的时候了。在生活的压力和生命的尊严之间,你只好泪流满面地接了下来。

1、不可能完成项目的典型特征

    对于互联网公司及做传统系统集成的公司的同志们而言,接到这样不可能完成的项目开发任务的情况已经司空见惯了。这些不可能完成项目的典型特征如下:

老板说:项目对公司具有战略意义,必须搞定
项目突发:销售跑过来告诉你,一个月内必须搞定这个项目
需求不明确
对现有系统架构有较大冲击,改动风险很大
项目给的时间很短且交付时间固定(time boxing) ,只能够倒推
销售过度承诺,必须实现狂复杂、狂大的需求
资源有限
设计诸多部门协调,很难短期搞定

2 、失败项目的典型症状

项目组所有成员及利益相关者对项目愿景及目标没有达成一致
为了赶进度,压缩需求分析、系统设计时间,需求理解尚未统一就投入开发
每个人只关心自己负责的一小块业务,对系统整体需求、架构、设计没有达成一致
为了赶进度,只关注功能的完成而忽视了功能实现的质量,导致大规模的返工
为了赶进度,不进行统一设计,由各模块负责人自己设计,设计存在较大缺陷
公用问题没有专人负责,工作重复
项目组成员沟通不畅,出问题后才沟通,导致无谓的时间浪费
项目组没有形成团队文化,团队成员只是为了完成项目目标而加班赶工,没有归属感

3、不可能完成项目的Scrum实践

    对于这样的不可能完成项目的管理使用Scrum这样的Time Boxing迭代开发过程很恰当,关于实践方法有兴趣的可以参考脑图。





  查看全部
  某一天老板或者销售人员跑过来亲切和蔼地拍拍你说:有个战略性产品需要在一个月之内开发出来,对搞定几个重点大商户至关重要,时间没有商量的余地。党组织从众多的党员同志中选择了你,这是党对你的信任,也是考验你的时候了。在生活的压力和生命的尊严之间,你只好泪流满面地接了下来。

1、不可能完成项目的典型特征

    对于互联网公司及做传统系统集成的公司的同志们而言,接到这样不可能完成的项目开发任务的情况已经司空见惯了。这些不可能完成项目的典型特征如下:

老板说:项目对公司具有战略意义,必须搞定
项目突发:销售跑过来告诉你,一个月内必须搞定这个项目
需求不明确
对现有系统架构有较大冲击,改动风险很大
项目给的时间很短且交付时间固定(time boxing) ,只能够倒推
销售过度承诺,必须实现狂复杂、狂大的需求
资源有限
设计诸多部门协调,很难短期搞定

2 、失败项目的典型症状

项目组所有成员及利益相关者对项目愿景及目标没有达成一致
为了赶进度,压缩需求分析、系统设计时间,需求理解尚未统一就投入开发
每个人只关心自己负责的一小块业务,对系统整体需求、架构、设计没有达成一致
为了赶进度,只关注功能的完成而忽视了功能实现的质量,导致大规模的返工
为了赶进度,不进行统一设计,由各模块负责人自己设计,设计存在较大缺陷
公用问题没有专人负责,工作重复
项目组成员沟通不畅,出问题后才沟通,导致无谓的时间浪费
项目组没有形成团队文化,团队成员只是为了完成项目目标而加班赶工,没有归属感

3、不可能完成项目的Scrum实践

    对于这样的不可能完成项目的管理使用Scrum这样的Time Boxing迭代开发过程很恰当,关于实践方法有兴趣的可以参考脑图。

4.png

 

开发一个业务逻辑复杂的系统,应该怎么样设计才能使项目的扩展性更好?

默认分类admin 发表了文章 • 0 个评论 • 129 次浏览 • 2016-12-29 21:01 • 来自相关话题

既然业务逻辑复杂,那意味着项目前期的业务建模、需求分析、分析设计极为重要,直接抛开这几个阶段进入技术实施开发阶段,不管套用什么设计模式、架构模式,系统的扩展性肯定难以保证。

项目的扩展性虽然最终体现为系统架构、技术实现的扩展性,但系统扩展性的根源在于系统业务架构及业务模型的扩展性。大家经常骂xx系统烂、扩展性差,大都将原因归结为技术实现烂,但总结那些成功的大型项目或产品的最佳实践,原因都会有:某某是业务专家,对xx业务很熟悉,能够衔接业务与技术。因此一个好的项目角色中,应该有行业专家/领域专家、业务过程分析师、系统分析师、软件架构师等角色,从业务架构、信息架构、技术架构保证系统的扩展性。

具体怎样进行业务建模,搭建良好的业务架构和业务模型,从而为技术架构、信息架构、技术实现奠定良好基础,有一些较为成熟的软件开发过程可供参考。例如 RUP(Rational Unified Process,统一软件开发过程)。一个标准的RUP工作流程包括:业务建模,需求分析,分析设计,实施开发,测试,部署,配置和变更管理,项目管理,环境。当然RUP只是一个方法论,且过于庞大,大部分项目很难完整执行其过程,需要根据实际情况进行裁剪,但其方法论对于复杂业务逻辑系统的建设具有指导意义。像互联网产品设计中常用的用例分析技术就源于RUP。

因此对于题主描述的一个复杂系统,标准的过程应当在业务建模,需求分析,分析设计,实施开发,测试,部署完整过程的分析设计(与开发语言无关)或实施开发(分析设计的成果映射为具体语言,例如Java、.NET等)阶段才考虑设计模式、架构模式的引入。设计模式的使用会经历僵化->固化->优化的阶段,类似禅修中“看山是山、看水是水”的三个阶段,才能体会模式的运用之妙。

值得强调的是:如果是偏交易(例如支付、金融)的系统,在考虑扩展性时候,一定要将信息架构、信息模型的扩展性纳入到考虑范围,此类系统数据模型至关重要,也不可能频繁变动。

上面描述方法的特别适用与传统软件、系统集成等需求偏稳定的项目,对于互联网偏创新性的项目就不一定完全适用了,此类项目的现实情况如下:业务模式不确定,会不停试错,验证模式;需求不停变化,要求能够快速响应;全新的行业,没有行业专家,没有行业标杆可借鉴(至多有跨界标杆可参考);此时候,类似精益创业、Scrum之类的敏捷开发模式更适合,但对于复杂的业务而言,业务建模->需求分析->分析设计的理念仍然值得参考借鉴。

最后,最最重要的是:完美系统的架构和扩展性是管理出来的、持续重构出来的。正如各大城市马路不停翻了再修、修了再翻的命运一样,中国大部分公司后任会不停否定掉前任的架构、系统,推倒再来一遍,然后等新系统刚开发出来不久,尚未上线或上线运营一段时间后,再换一帮人继续折腾,然后。。。

总结这么多年的经历,深刻体会到:再烂的系统和架构,如果能够强化管理、持续积累、持续重构、持续完善,都能够有机会成为完美的系统,完美的系统不在于其架构的牛逼和完美,而在于:符合公司的业务模式,能够完美支撑公司业务的高速发展和市场需求的快速响应。

 

http://www.zhihu.com/question/ ... 06943 查看全部
既然业务逻辑复杂,那意味着项目前期的业务建模、需求分析、分析设计极为重要,直接抛开这几个阶段进入技术实施开发阶段,不管套用什么设计模式、架构模式,系统的扩展性肯定难以保证。

项目的扩展性虽然最终体现为系统架构、技术实现的扩展性,但系统扩展性的根源在于系统业务架构及业务模型的扩展性。大家经常骂xx系统烂、扩展性差,大都将原因归结为技术实现烂,但总结那些成功的大型项目或产品的最佳实践,原因都会有:某某是业务专家,对xx业务很熟悉,能够衔接业务与技术。因此一个好的项目角色中,应该有行业专家/领域专家、业务过程分析师、系统分析师、软件架构师等角色,从业务架构、信息架构、技术架构保证系统的扩展性。

具体怎样进行业务建模,搭建良好的业务架构和业务模型,从而为技术架构、信息架构、技术实现奠定良好基础,有一些较为成熟的软件开发过程可供参考。例如 RUP(Rational Unified Process,统一软件开发过程)。一个标准的RUP工作流程包括:业务建模,需求分析,分析设计,实施开发,测试,部署,配置和变更管理,项目管理,环境。当然RUP只是一个方法论,且过于庞大,大部分项目很难完整执行其过程,需要根据实际情况进行裁剪,但其方法论对于复杂业务逻辑系统的建设具有指导意义。像互联网产品设计中常用的用例分析技术就源于RUP。

因此对于题主描述的一个复杂系统,标准的过程应当在业务建模,需求分析,分析设计,实施开发,测试,部署完整过程的分析设计(与开发语言无关)或实施开发(分析设计的成果映射为具体语言,例如Java、.NET等)阶段才考虑设计模式、架构模式的引入。设计模式的使用会经历僵化->固化->优化的阶段,类似禅修中“看山是山、看水是水”的三个阶段,才能体会模式的运用之妙。

值得强调的是:如果是偏交易(例如支付、金融)的系统,在考虑扩展性时候,一定要将信息架构、信息模型的扩展性纳入到考虑范围,此类系统数据模型至关重要,也不可能频繁变动。

上面描述方法的特别适用与传统软件、系统集成等需求偏稳定的项目,对于互联网偏创新性的项目就不一定完全适用了,此类项目的现实情况如下:业务模式不确定,会不停试错,验证模式;需求不停变化,要求能够快速响应;全新的行业,没有行业专家,没有行业标杆可借鉴(至多有跨界标杆可参考);此时候,类似精益创业、Scrum之类的敏捷开发模式更适合,但对于复杂的业务而言,业务建模->需求分析->分析设计的理念仍然值得参考借鉴。

最后,最最重要的是:完美系统的架构和扩展性是管理出来的、持续重构出来的。正如各大城市马路不停翻了再修、修了再翻的命运一样,中国大部分公司后任会不停否定掉前任的架构、系统,推倒再来一遍,然后等新系统刚开发出来不久,尚未上线或上线运营一段时间后,再换一帮人继续折腾,然后。。。

总结这么多年的经历,深刻体会到:再烂的系统和架构,如果能够强化管理、持续积累、持续重构、持续完善,都能够有机会成为完美的系统,完美的系统不在于其架构的牛逼和完美,而在于:符合公司的业务模式,能够完美支撑公司业务的高速发展和市场需求的快速响应。

 

http://www.zhihu.com/question/ ... 06943

一个好的开发流程是怎么样的?

回复

默认分类admin 发起了问题 • 1 人关注 • 0 个回复 • 147 次浏览 • 2016-12-29 19:52 • 来自相关话题

请做一下自我介绍

回复

默认分类admin 发起了问题 • 1 人关注 • 0 个回复 • 142 次浏览 • 2016-12-29 14:49 • 来自相关话题

如何对软件项目开发过程中的风险进行风险控制?

默认分类admin 发表了文章 • 0 个评论 • 180 次浏览 • 2016-12-27 17:11 • 来自相关话题

识别和分析风险并不是软件风险管理的最终目标。针对所发现的每一个软件风险,尤其是高危险度的软件风险,风险管理还需要对它们进行有效的控制,包括:(1) 制定风险管理计划:针对各个重要风险制定风险管理计划,并确保它们的一致性;(2)化解风险:执行风险管理计划,以缓解或消除风险;(3)监控风险:监控风险化解的过程。

n       制定风险管理计划

针对每一个重要的软件风险,制定相应的处理该软件风险的计划。风险管理计划主要描述有关软件风险处理的以下内容-          软件风险名称

-          软件风险由谁引起

-          软件风险的表现形式是什么

-          软件风险可能什么时候发生

-          为什么会发生该软件风险

-          如何避免或者消除软件风险的发生

-          软件风险发生后的处理措施

n       风险化解方式

执行风险管理计划,以缓解或消除风险。一般地,软件风险化解有以下几种方式。

-          避免风险

采取主动和积极的措施来规避软件风险,将软件风险发生的概率控制为零。例如针对用户可能没有时间参加需求评审这一软件风险,项目组可以考虑选择用户方便的时间来进行需求评审,这样“用户不能出席需求评审会”这一软件风险就不会发生。

-          转移风险

将可能或者潜在的软件风险转移给其它的单位或个人,从而使得自己不再承担该软件风险。例如如果开发某个子系统存在技术和人力资源方面的风险,可以考虑将它外包给其它软件开发公司,从而将该软件风险从项目中转移出去。

-          消除发生软件风险的根源

如果知道导致软件风险发生的因素,那么针对这些因素,采取手段消除软件风险发生的根源。例如如果发现导致小刘离开项目组的主要原因是薪酬太低,那么可以通过给小刘增加薪酬来消除发生软件风险的根源。 

n       风险监控

在风险评估和控制过程中,项目组人员和负责人必须对软件风险的化解程度及其变化(如发生概率、可能导致的损失和危险度)进行检查和监控,并对收集到的有关软件风险信息进行记录,以促进对软件风险的持续管理。

风险监控的主要内容包括:监控和跟踪重要软件风险,记录这些软件风险危险度的变化以及软件风险化解的进展,确认软件风险是否已经得到化解和消除,是否有新的软件风险发生等等。
  查看全部
识别和分析风险并不是软件风险管理的最终目标。针对所发现的每一个软件风险,尤其是高危险度的软件风险,风险管理还需要对它们进行有效的控制,包括:(1) 制定风险管理计划:针对各个重要风险制定风险管理计划,并确保它们的一致性;(2)化解风险:执行风险管理计划,以缓解或消除风险;(3)监控风险:监控风险化解的过程。

n       制定风险管理计划

针对每一个重要的软件风险,制定相应的处理该软件风险的计划。风险管理计划主要描述有关软件风险处理的以下内容-          软件风险名称

-          软件风险由谁引起

-          软件风险的表现形式是什么

-          软件风险可能什么时候发生

-          为什么会发生该软件风险

-          如何避免或者消除软件风险的发生

-          软件风险发生后的处理措施

n       风险化解方式

执行风险管理计划,以缓解或消除风险。一般地,软件风险化解有以下几种方式。

-          避免风险

采取主动和积极的措施来规避软件风险,将软件风险发生的概率控制为零。例如针对用户可能没有时间参加需求评审这一软件风险,项目组可以考虑选择用户方便的时间来进行需求评审,这样“用户不能出席需求评审会”这一软件风险就不会发生。

-          转移风险

将可能或者潜在的软件风险转移给其它的单位或个人,从而使得自己不再承担该软件风险。例如如果开发某个子系统存在技术和人力资源方面的风险,可以考虑将它外包给其它软件开发公司,从而将该软件风险从项目中转移出去。

-          消除发生软件风险的根源

如果知道导致软件风险发生的因素,那么针对这些因素,采取手段消除软件风险发生的根源。例如如果发现导致小刘离开项目组的主要原因是薪酬太低,那么可以通过给小刘增加薪酬来消除发生软件风险的根源。 

n       风险监控

在风险评估和控制过程中,项目组人员和负责人必须对软件风险的化解程度及其变化(如发生概率、可能导致的损失和危险度)进行检查和监控,并对收集到的有关软件风险信息进行记录,以促进对软件风险的持续管理。

风险监控的主要内容包括:监控和跟踪重要软件风险,记录这些软件风险危险度的变化以及软件风险化解的进展,确认软件风险是否已经得到化解和消除,是否有新的软件风险发生等等。
 

软件项目的年度维护费用有没有什么标准,一般按照合同额10%这个数据怎么来的?

回复

默认分类admin 回复了问题 • 1 人关注 • 1 个回复 • 121 次浏览 • 2017-07-21 16:40 • 来自相关话题

做项目的时候,一般利益分配的比例是怎么样的?怎么样做才是妥当的

回复

默认分类admin 回复了问题 • 1 人关注 • 1 个回复 • 167 次浏览 • 2017-01-18 13:52 • 来自相关话题

一个好的开发流程是怎么样的?

回复

默认分类admin 发起了问题 • 1 人关注 • 0 个回复 • 147 次浏览 • 2016-12-29 19:52 • 来自相关话题

请做一下自我介绍

回复

默认分类admin 发起了问题 • 1 人关注 • 0 个回复 • 142 次浏览 • 2016-12-29 14:49 • 来自相关话题

项目经理的职能和角色分别是什么?

回复

默认分类admin 发起了问题 • 1 人关注 • 0 个回复 • 146 次浏览 • 2016-12-27 13:06 • 来自相关话题

经验贴:总结项目团队管理中踩过的几个坑

默认分类admin 发表了文章 • 0 个评论 • 124 次浏览 • 2017-04-06 08:27 • 来自相关话题

从2月份年后回来到现在4月份初,负责项目团队开始,慢慢地在项目团队管理中踩过了不少坑。自己也是在边学习边成长中去适应这个工作职责。

在这样一个职责中,作为一个团队中坚力量。要学会接受领导的批判和怒火,负责扛起整个团队的过错。学会接受团队中每个成员的小情绪,让他们更加的去完成好每一个工作。在这个过程中不断培养性格和能力的控制力。

一、个人层面

1、外部时间和内部时间

在外部时间和内部时间上没有协调好自己的工作时间,导致很多事情没有做好充分准备。每天的团队内部时间要负责协调好每个工作职能所要做的工作,并协作每个工作职能做到最好。在外部时间中,重在与各部门的协商和工作推进。明确各部门与本部门的工作交际协作和完成工作时间节点。在这样时间安排中,外部工作占20%,内部工作占80%。外部工作尽量协调在做好充足准备,植入主题,完成沟通。内容工作更加深入细节,保证正常运作。

2、先思考后做

很多事情,由于发生的太突然。反而缺少了需要思考的点。没有做到先思考后做。但是这样的情况发生时,需要充分进行快速思考,再行动。先思考后做,会让做事的效率进行提升,并会把很多细节点给充分思考到。

3、每天总结自己的问题

每天没有总结自己的问题。导致第二次,第三次反复出现同样的错误。每天对自己的工作内容进行梳理,并对团队内部的大家工作也进行梳理。去思考哪些不合理点和问题,并马上在第二天进行解决。反复总结和梳理中,提升自己发现问题的能力。

二、产品层面

1、需求文档是技术开发的核心

PRD文档往往影响开发的进度,一份好的文档可以让开发快速进行开发。清晰的逻辑线可以让开发节省很多时间专注于本身的开发实现方面。PRD还起到新来的产品经理进行学习和了解系统用。对于老的产品经理,也可以起到查被的作用。

2、产品版本迭代要抓住核心问题点

敏捷开发是最小开发化的单元,而非大规模开发量。在产品版本迭代中,需要抓住主要问题和次要问题,解决主要问题。特别对需求理解,可以更加深入某个细节点上去考虑。这样的版本迭代可以保持最高效的验证。特别是前端产品,需要不断进行验证。

3、外部沟通要保持协助和引导

外部沟通中,一旦发生没有准备或者引导,会处于沟通的下风,导致可能计划失控。所以在外部沟通中,要做好充分准备,再参加每一个会议。在会议中沟通,要保持非必要性的冲突性,带有可控制性的引导。

三、技术层面

1、细节点不够了解,没有找到合理方案

在技术项目跟进方面,需要与技术人员进行深入沟通。把遇到困难的细节点了解清楚,在清楚同时,与技术人员一起探讨找到解决问题的方案。没有合理的方案,那么碰到困难可能只能一味的拖延工期。

2、项目任务协作保证开发进度

在项目任务中,要合理进行项目任务发布和人员工作安排。这样才可以保证合理的开发进度。不可以因为某些细节点困难,导致整个项目速度延误。时刻关注任务燃尽图,保证项目任务。

四、项目层面

1、保持项目中每个节点控制

在整个项目中,分为产品阶段、设计阶段、开发阶段、测试阶段、上线阶段。对于整个项目阶段,必须在某个阶段中所有的问题点,都需要进行节点控制。特别是项目在相互交付阶段,是最容易出现问题的。

2、始终要让团队保持清醒目标

在团队推进过程中,团队成员会因为目标时间过长,导致失去对于目标的清晰。所以每天需要时刻提醒团队成员,我们的项目目标和进度。时刻让团队保持清醒的状态。这个是团队负责人最需要处理的。

另外,对于团队建设,一直处于最高的地位。团队团结可以势如破竹。一个团队彼此之间没有感情,是很难做成事情的。

在一辆行驶的火车中,作为动力发动力和火车头,如果脱节于整个火车组之外,那么整节火车将被颠覆。所以每一步都需要脚踏实地。

#专栏作家#

晓翼,微信公众号:上海人在北京。人人都是产品经理专栏作家。专注于电商、O2O的产品经理。会IOS开发、会P图、会运营的逗比一个。常关注社交、旅行类产品。

本文原创发布于人人都是产品经理,未经许可,不得转载。 查看全部
从2月份年后回来到现在4月份初,负责项目团队开始,慢慢地在项目团队管理中踩过了不少坑。自己也是在边学习边成长中去适应这个工作职责。

在这样一个职责中,作为一个团队中坚力量。要学会接受领导的批判和怒火,负责扛起整个团队的过错。学会接受团队中每个成员的小情绪,让他们更加的去完成好每一个工作。在这个过程中不断培养性格和能力的控制力。

一、个人层面

1、外部时间和内部时间

在外部时间和内部时间上没有协调好自己的工作时间,导致很多事情没有做好充分准备。每天的团队内部时间要负责协调好每个工作职能所要做的工作,并协作每个工作职能做到最好。在外部时间中,重在与各部门的协商和工作推进。明确各部门与本部门的工作交际协作和完成工作时间节点。在这样时间安排中,外部工作占20%,内部工作占80%。外部工作尽量协调在做好充足准备,植入主题,完成沟通。内容工作更加深入细节,保证正常运作。

2、先思考后做

很多事情,由于发生的太突然。反而缺少了需要思考的点。没有做到先思考后做。但是这样的情况发生时,需要充分进行快速思考,再行动。先思考后做,会让做事的效率进行提升,并会把很多细节点给充分思考到。

3、每天总结自己的问题

每天没有总结自己的问题。导致第二次,第三次反复出现同样的错误。每天对自己的工作内容进行梳理,并对团队内部的大家工作也进行梳理。去思考哪些不合理点和问题,并马上在第二天进行解决。反复总结和梳理中,提升自己发现问题的能力。

二、产品层面

1、需求文档是技术开发的核心

PRD文档往往影响开发的进度,一份好的文档可以让开发快速进行开发。清晰的逻辑线可以让开发节省很多时间专注于本身的开发实现方面。PRD还起到新来的产品经理进行学习和了解系统用。对于老的产品经理,也可以起到查被的作用。

2、产品版本迭代要抓住核心问题点

敏捷开发是最小开发化的单元,而非大规模开发量。在产品版本迭代中,需要抓住主要问题和次要问题,解决主要问题。特别对需求理解,可以更加深入某个细节点上去考虑。这样的版本迭代可以保持最高效的验证。特别是前端产品,需要不断进行验证。

3、外部沟通要保持协助和引导

外部沟通中,一旦发生没有准备或者引导,会处于沟通的下风,导致可能计划失控。所以在外部沟通中,要做好充分准备,再参加每一个会议。在会议中沟通,要保持非必要性的冲突性,带有可控制性的引导。

三、技术层面

1、细节点不够了解,没有找到合理方案

在技术项目跟进方面,需要与技术人员进行深入沟通。把遇到困难的细节点了解清楚,在清楚同时,与技术人员一起探讨找到解决问题的方案。没有合理的方案,那么碰到困难可能只能一味的拖延工期。

2、项目任务协作保证开发进度

在项目任务中,要合理进行项目任务发布和人员工作安排。这样才可以保证合理的开发进度。不可以因为某些细节点困难,导致整个项目速度延误。时刻关注任务燃尽图,保证项目任务。

四、项目层面

1、保持项目中每个节点控制

在整个项目中,分为产品阶段、设计阶段、开发阶段、测试阶段、上线阶段。对于整个项目阶段,必须在某个阶段中所有的问题点,都需要进行节点控制。特别是项目在相互交付阶段,是最容易出现问题的。

2、始终要让团队保持清醒目标

在团队推进过程中,团队成员会因为目标时间过长,导致失去对于目标的清晰。所以每天需要时刻提醒团队成员,我们的项目目标和进度。时刻让团队保持清醒的状态。这个是团队负责人最需要处理的。

另外,对于团队建设,一直处于最高的地位。团队团结可以势如破竹。一个团队彼此之间没有感情,是很难做成事情的。

在一辆行驶的火车中,作为动力发动力和火车头,如果脱节于整个火车组之外,那么整节火车将被颠覆。所以每一步都需要脚踏实地。

#专栏作家#

晓翼,微信公众号:上海人在北京。人人都是产品经理专栏作家。专注于电商、O2O的产品经理。会IOS开发、会P图、会运营的逗比一个。常关注社交、旅行类产品。

本文原创发布于人人都是产品经理,未经许可,不得转载。

5年项目管理工作经验工作心得

默认分类admin 发表了文章 • 0 个评论 • 134 次浏览 • 2017-01-01 18:30 • 来自相关话题

作者:aitilaowang
链接:https://zhuanlan.zhihu.com/p/20852368
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

一、要有较好的技术背景和成长经历,死磕自己,学习技术和管理(注重沟通、协调学习项目管理的铁三角),这样才能服务于团队成员,让团队成员心服口服。

二、交流问题时要放低姿态,此时不能把自己当成项目经理,要以技术服人、以理服人,切记摆出领导的架势;而在公司制度、管理方面要严肃,管理方面不能和大家嘻嘻哈哈,这样不利于项目和团队成员的管理。

三、定期和不定期和各位成员沟通,察言观色,了解成员的真正诉求和内心想法,能帮助他们解决的问题尽量帮助。及时疏导心里承受差的同事,排除不顺的情绪,关心特别个性、比较内向的同事,让他们感觉到大家是个整体,没有被边缘化。让他知道除了工作大家是同事,可以一起说说笑笑。

四、向上级领导(部门经理或者总监等角色)定期和不定期的汇报工作,让领导知道我们的项目进度和人力各方面的状态,尽量少给领导添麻烦,要想办法自己解决问题替领导分忧。项目经理要让上级领导真正放心,主动找领导汇报工作成果、进度。不要等领导来问你。

五、沟通、管理等要不卑不亢、不急不躁,表现出沉着稳定的状态。遇到问题不能急不能慌,团队成员或者领导告知你突发状况的时候不能自己都慌慌张张,这样不仅会让领导同事担心你的能力,更有可能被替代。你需要做的是时刻准备着问题的到来,遇到问题时拿出解决方法。技术问题有能力指导尽量指导,没有能力时要协调高级工程师、架构师等人员来解决;沟通问题要自己把握,要和直属领导沟通、和本项目组成员紧密沟通。有需要的情况下还要跨级沟通、跨部门沟通等等(要特别注意跨级汇报,紧急需要时一定要注意技巧。比如紧急情况需要领导决策而直属领导联系不上,这时候越级请示要事先说明直属领导联系几次联系不上等具体情况。总之要灵活对待)。 查看全部

作者:aitilaowang
链接:https://zhuanlan.zhihu.com/p/20852368
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

一、要有较好的技术背景和成长经历,死磕自己,学习技术和管理(注重沟通、协调学习项目管理的铁三角),这样才能服务于团队成员,让团队成员心服口服。

二、交流问题时要放低姿态,此时不能把自己当成项目经理,要以技术服人、以理服人,切记摆出领导的架势;而在公司制度、管理方面要严肃,管理方面不能和大家嘻嘻哈哈,这样不利于项目和团队成员的管理。

三、定期和不定期和各位成员沟通,察言观色,了解成员的真正诉求和内心想法,能帮助他们解决的问题尽量帮助。及时疏导心里承受差的同事,排除不顺的情绪,关心特别个性、比较内向的同事,让他们感觉到大家是个整体,没有被边缘化。让他知道除了工作大家是同事,可以一起说说笑笑。

四、向上级领导(部门经理或者总监等角色)定期和不定期的汇报工作,让领导知道我们的项目进度和人力各方面的状态,尽量少给领导添麻烦,要想办法自己解决问题替领导分忧。项目经理要让上级领导真正放心,主动找领导汇报工作成果、进度。不要等领导来问你。

五、沟通、管理等要不卑不亢、不急不躁,表现出沉着稳定的状态。遇到问题不能急不能慌,团队成员或者领导告知你突发状况的时候不能自己都慌慌张张,这样不仅会让领导同事担心你的能力,更有可能被替代。你需要做的是时刻准备着问题的到来,遇到问题时拿出解决方法。技术问题有能力指导尽量指导,没有能力时要协调高级工程师、架构师等人员来解决;沟通问题要自己把握,要和直属领导沟通、和本项目组成员紧密沟通。有需要的情况下还要跨级沟通、跨部门沟通等等(要特别注意跨级汇报,紧急需要时一定要注意技巧。比如紧急情况需要领导决策而直属领导联系不上,这时候越级请示要事先说明直属领导联系几次联系不上等具体情况。总之要灵活对待)。

技术人员如何确认web产品的需求

默认分类admin 发表了文章 • 0 个评论 • 118 次浏览 • 2016-12-30 10:33 • 来自相关话题

web需求定义涉及到展示和交互两个部分,展示是打开一个页面时呈现出来的页面效果,交互是用户通过鼠标,键盘,触摸或其他外设操作之后系统给出响应的过程。

对于页面的展示要从下面几个角度来确认需求。

一. 界面展示,需要确认展示的逻辑

1)展示逻辑通常要考虑不同的角色进入页面时候的显示是否一致,如果不一致,则要明确不同角色进来后显示内容的异同
2)对于有隐藏内容的控件,必须确认隐藏的内容,例如菜单,tab
3)对于每一个显示单元要确认显示数据的逻辑,例如“最热文章”,必须要确认这个最热文章是如何定义的,是按点击的还是按转贴的,还是其他逻辑,另外还要注意这个最热是否有隐含的时间范围
4)对于显示区域临界条件的确认,要确认数据不足时如何展示,数据字段过长时如何展示

二. 交互需求确认

什么是交互呢? 页面展示出来,用户通过鼠标,键盘,触摸或其他外设操作之后系统给出响应的过程就是交互。

对于传统的web最常见的交互是填写表单和鼠标点击。

我们可以先考虑表单需求的确认。 可以把表单性需求的确认分为三个阶段 1) 表单填写 2)表单的提交 3)表单提交后的响应

先来看表单填写需要确认的需求:

1. 对于输入性控件必须确认输入框是否必填,输入框是否需要格式校验,是否有最大长度限制,是否有相等性校验。
2. 对于选择性控件,也要明确是否有最多选择数,最少选择数,是否可以不填等边界条件
3. 另外要注意是否有键盘操作便捷的需求,例如按回车或Ctrl+回车提交,按tab键要到下一个表单元素
4. 是否需要在进入界面时自动focus到某一控件上
5. 当用户将焦点移向下一个控件时是否需要做交互判断(最典型的是注册用户填写用户名后自动校验用户名是否存在)

上面5点前两点是边界条件的确认,第3,4是便捷性需求的确认,第5点是用户友好性的确认

表单填写完毕用户就可以提交表单了,提交表单有异步和同步两种方式,最好给产品经理确认提交的方式,另外还要评估表单提交是否涉及到耗时的操作,如果操作很耗时,应该要求产品经理给出应对用户等待焦虑的方案。

最后需要明确表单提交之后需要明确后端处理的业务逻辑,和处理成功或者失败之后的提示或页面跳转。

除了表单之外最常见的交互是鼠标点击,例如点击删除链接,删除一条记录,这时候要确认点击前需要客户端如何响应,点击服务器收到成功响应后如何显示,失败时如何显示。

对于一个系统来说添加或者修改一个功能点,往往会影响其他功能点,在做需求确认时还要明确当前操作会影响到地方,影响是什么样子的,如果因为性能原因使用了缓存,要给产品同事明确缓存时间。

总结:

技术人员在确认需求是要考虑界面效果,要考虑显示逻辑,也要考虑后台的业务逻辑,以及当前需求点操作逻辑对其他地方的影响。

必须在确认需求阶段就充分考虑好界面显示的边界条件,用户输入的校验条件,用户交互的显示逻辑,有错误发生时的处理。

业务逻辑中一定要考虑到当前用户是否分了角色,操作的对象是谁,这个需求是否有时间范围,操作是否有其他的前提条件,是否影响到其他地方。 查看全部
web需求定义涉及到展示和交互两个部分,展示是打开一个页面时呈现出来的页面效果,交互是用户通过鼠标,键盘,触摸或其他外设操作之后系统给出响应的过程。

对于页面的展示要从下面几个角度来确认需求。

一. 界面展示,需要确认展示的逻辑

1)展示逻辑通常要考虑不同的角色进入页面时候的显示是否一致,如果不一致,则要明确不同角色进来后显示内容的异同
2)对于有隐藏内容的控件,必须确认隐藏的内容,例如菜单,tab
3)对于每一个显示单元要确认显示数据的逻辑,例如“最热文章”,必须要确认这个最热文章是如何定义的,是按点击的还是按转贴的,还是其他逻辑,另外还要注意这个最热是否有隐含的时间范围
4)对于显示区域临界条件的确认,要确认数据不足时如何展示,数据字段过长时如何展示

二. 交互需求确认

什么是交互呢? 页面展示出来,用户通过鼠标,键盘,触摸或其他外设操作之后系统给出响应的过程就是交互。

对于传统的web最常见的交互是填写表单和鼠标点击。

我们可以先考虑表单需求的确认。 可以把表单性需求的确认分为三个阶段 1) 表单填写 2)表单的提交 3)表单提交后的响应

先来看表单填写需要确认的需求:

1. 对于输入性控件必须确认输入框是否必填,输入框是否需要格式校验,是否有最大长度限制,是否有相等性校验。
2. 对于选择性控件,也要明确是否有最多选择数,最少选择数,是否可以不填等边界条件
3. 另外要注意是否有键盘操作便捷的需求,例如按回车或Ctrl+回车提交,按tab键要到下一个表单元素
4. 是否需要在进入界面时自动focus到某一控件上
5. 当用户将焦点移向下一个控件时是否需要做交互判断(最典型的是注册用户填写用户名后自动校验用户名是否存在)

上面5点前两点是边界条件的确认,第3,4是便捷性需求的确认,第5点是用户友好性的确认

表单填写完毕用户就可以提交表单了,提交表单有异步和同步两种方式,最好给产品经理确认提交的方式,另外还要评估表单提交是否涉及到耗时的操作,如果操作很耗时,应该要求产品经理给出应对用户等待焦虑的方案。

最后需要明确表单提交之后需要明确后端处理的业务逻辑,和处理成功或者失败之后的提示或页面跳转。

除了表单之外最常见的交互是鼠标点击,例如点击删除链接,删除一条记录,这时候要确认点击前需要客户端如何响应,点击服务器收到成功响应后如何显示,失败时如何显示。

对于一个系统来说添加或者修改一个功能点,往往会影响其他功能点,在做需求确认时还要明确当前操作会影响到地方,影响是什么样子的,如果因为性能原因使用了缓存,要给产品同事明确缓存时间。

总结:

技术人员在确认需求是要考虑界面效果,要考虑显示逻辑,也要考虑后台的业务逻辑,以及当前需求点操作逻辑对其他地方的影响。

必须在确认需求阶段就充分考虑好界面显示的边界条件,用户输入的校验条件,用户交互的显示逻辑,有错误发生时的处理。

业务逻辑中一定要考虑到当前用户是否分了角色,操作的对象是谁,这个需求是否有时间范围,操作是否有其他的前提条件,是否影响到其他地方。

不可能完成项目的Scrum实践

默认分类admin 发表了文章 • 0 个评论 • 122 次浏览 • 2016-12-29 21:26 • 来自相关话题

  某一天老板或者销售人员跑过来亲切和蔼地拍拍你说:有个战略性产品需要在一个月之内开发出来,对搞定几个重点大商户至关重要,时间没有商量的余地。党组织从众多的党员同志中选择了你,这是党对你的信任,也是考验你的时候了。在生活的压力和生命的尊严之间,你只好泪流满面地接了下来。

1、不可能完成项目的典型特征

    对于互联网公司及做传统系统集成的公司的同志们而言,接到这样不可能完成的项目开发任务的情况已经司空见惯了。这些不可能完成项目的典型特征如下:

老板说:项目对公司具有战略意义,必须搞定
项目突发:销售跑过来告诉你,一个月内必须搞定这个项目
需求不明确
对现有系统架构有较大冲击,改动风险很大
项目给的时间很短且交付时间固定(time boxing) ,只能够倒推
销售过度承诺,必须实现狂复杂、狂大的需求
资源有限
设计诸多部门协调,很难短期搞定

2 、失败项目的典型症状

项目组所有成员及利益相关者对项目愿景及目标没有达成一致
为了赶进度,压缩需求分析、系统设计时间,需求理解尚未统一就投入开发
每个人只关心自己负责的一小块业务,对系统整体需求、架构、设计没有达成一致
为了赶进度,只关注功能的完成而忽视了功能实现的质量,导致大规模的返工
为了赶进度,不进行统一设计,由各模块负责人自己设计,设计存在较大缺陷
公用问题没有专人负责,工作重复
项目组成员沟通不畅,出问题后才沟通,导致无谓的时间浪费
项目组没有形成团队文化,团队成员只是为了完成项目目标而加班赶工,没有归属感

3、不可能完成项目的Scrum实践

    对于这样的不可能完成项目的管理使用Scrum这样的Time Boxing迭代开发过程很恰当,关于实践方法有兴趣的可以参考脑图。





  查看全部
  某一天老板或者销售人员跑过来亲切和蔼地拍拍你说:有个战略性产品需要在一个月之内开发出来,对搞定几个重点大商户至关重要,时间没有商量的余地。党组织从众多的党员同志中选择了你,这是党对你的信任,也是考验你的时候了。在生活的压力和生命的尊严之间,你只好泪流满面地接了下来。

1、不可能完成项目的典型特征

    对于互联网公司及做传统系统集成的公司的同志们而言,接到这样不可能完成的项目开发任务的情况已经司空见惯了。这些不可能完成项目的典型特征如下:

老板说:项目对公司具有战略意义,必须搞定
项目突发:销售跑过来告诉你,一个月内必须搞定这个项目
需求不明确
对现有系统架构有较大冲击,改动风险很大
项目给的时间很短且交付时间固定(time boxing) ,只能够倒推
销售过度承诺,必须实现狂复杂、狂大的需求
资源有限
设计诸多部门协调,很难短期搞定

2 、失败项目的典型症状

项目组所有成员及利益相关者对项目愿景及目标没有达成一致
为了赶进度,压缩需求分析、系统设计时间,需求理解尚未统一就投入开发
每个人只关心自己负责的一小块业务,对系统整体需求、架构、设计没有达成一致
为了赶进度,只关注功能的完成而忽视了功能实现的质量,导致大规模的返工
为了赶进度,不进行统一设计,由各模块负责人自己设计,设计存在较大缺陷
公用问题没有专人负责,工作重复
项目组成员沟通不畅,出问题后才沟通,导致无谓的时间浪费
项目组没有形成团队文化,团队成员只是为了完成项目目标而加班赶工,没有归属感

3、不可能完成项目的Scrum实践

    对于这样的不可能完成项目的管理使用Scrum这样的Time Boxing迭代开发过程很恰当,关于实践方法有兴趣的可以参考脑图。

4.png

 

开发一个业务逻辑复杂的系统,应该怎么样设计才能使项目的扩展性更好?

默认分类admin 发表了文章 • 0 个评论 • 129 次浏览 • 2016-12-29 21:01 • 来自相关话题

既然业务逻辑复杂,那意味着项目前期的业务建模、需求分析、分析设计极为重要,直接抛开这几个阶段进入技术实施开发阶段,不管套用什么设计模式、架构模式,系统的扩展性肯定难以保证。

项目的扩展性虽然最终体现为系统架构、技术实现的扩展性,但系统扩展性的根源在于系统业务架构及业务模型的扩展性。大家经常骂xx系统烂、扩展性差,大都将原因归结为技术实现烂,但总结那些成功的大型项目或产品的最佳实践,原因都会有:某某是业务专家,对xx业务很熟悉,能够衔接业务与技术。因此一个好的项目角色中,应该有行业专家/领域专家、业务过程分析师、系统分析师、软件架构师等角色,从业务架构、信息架构、技术架构保证系统的扩展性。

具体怎样进行业务建模,搭建良好的业务架构和业务模型,从而为技术架构、信息架构、技术实现奠定良好基础,有一些较为成熟的软件开发过程可供参考。例如 RUP(Rational Unified Process,统一软件开发过程)。一个标准的RUP工作流程包括:业务建模,需求分析,分析设计,实施开发,测试,部署,配置和变更管理,项目管理,环境。当然RUP只是一个方法论,且过于庞大,大部分项目很难完整执行其过程,需要根据实际情况进行裁剪,但其方法论对于复杂业务逻辑系统的建设具有指导意义。像互联网产品设计中常用的用例分析技术就源于RUP。

因此对于题主描述的一个复杂系统,标准的过程应当在业务建模,需求分析,分析设计,实施开发,测试,部署完整过程的分析设计(与开发语言无关)或实施开发(分析设计的成果映射为具体语言,例如Java、.NET等)阶段才考虑设计模式、架构模式的引入。设计模式的使用会经历僵化->固化->优化的阶段,类似禅修中“看山是山、看水是水”的三个阶段,才能体会模式的运用之妙。

值得强调的是:如果是偏交易(例如支付、金融)的系统,在考虑扩展性时候,一定要将信息架构、信息模型的扩展性纳入到考虑范围,此类系统数据模型至关重要,也不可能频繁变动。

上面描述方法的特别适用与传统软件、系统集成等需求偏稳定的项目,对于互联网偏创新性的项目就不一定完全适用了,此类项目的现实情况如下:业务模式不确定,会不停试错,验证模式;需求不停变化,要求能够快速响应;全新的行业,没有行业专家,没有行业标杆可借鉴(至多有跨界标杆可参考);此时候,类似精益创业、Scrum之类的敏捷开发模式更适合,但对于复杂的业务而言,业务建模->需求分析->分析设计的理念仍然值得参考借鉴。

最后,最最重要的是:完美系统的架构和扩展性是管理出来的、持续重构出来的。正如各大城市马路不停翻了再修、修了再翻的命运一样,中国大部分公司后任会不停否定掉前任的架构、系统,推倒再来一遍,然后等新系统刚开发出来不久,尚未上线或上线运营一段时间后,再换一帮人继续折腾,然后。。。

总结这么多年的经历,深刻体会到:再烂的系统和架构,如果能够强化管理、持续积累、持续重构、持续完善,都能够有机会成为完美的系统,完美的系统不在于其架构的牛逼和完美,而在于:符合公司的业务模式,能够完美支撑公司业务的高速发展和市场需求的快速响应。

 

http://www.zhihu.com/question/ ... 06943 查看全部
既然业务逻辑复杂,那意味着项目前期的业务建模、需求分析、分析设计极为重要,直接抛开这几个阶段进入技术实施开发阶段,不管套用什么设计模式、架构模式,系统的扩展性肯定难以保证。

项目的扩展性虽然最终体现为系统架构、技术实现的扩展性,但系统扩展性的根源在于系统业务架构及业务模型的扩展性。大家经常骂xx系统烂、扩展性差,大都将原因归结为技术实现烂,但总结那些成功的大型项目或产品的最佳实践,原因都会有:某某是业务专家,对xx业务很熟悉,能够衔接业务与技术。因此一个好的项目角色中,应该有行业专家/领域专家、业务过程分析师、系统分析师、软件架构师等角色,从业务架构、信息架构、技术架构保证系统的扩展性。

具体怎样进行业务建模,搭建良好的业务架构和业务模型,从而为技术架构、信息架构、技术实现奠定良好基础,有一些较为成熟的软件开发过程可供参考。例如 RUP(Rational Unified Process,统一软件开发过程)。一个标准的RUP工作流程包括:业务建模,需求分析,分析设计,实施开发,测试,部署,配置和变更管理,项目管理,环境。当然RUP只是一个方法论,且过于庞大,大部分项目很难完整执行其过程,需要根据实际情况进行裁剪,但其方法论对于复杂业务逻辑系统的建设具有指导意义。像互联网产品设计中常用的用例分析技术就源于RUP。

因此对于题主描述的一个复杂系统,标准的过程应当在业务建模,需求分析,分析设计,实施开发,测试,部署完整过程的分析设计(与开发语言无关)或实施开发(分析设计的成果映射为具体语言,例如Java、.NET等)阶段才考虑设计模式、架构模式的引入。设计模式的使用会经历僵化->固化->优化的阶段,类似禅修中“看山是山、看水是水”的三个阶段,才能体会模式的运用之妙。

值得强调的是:如果是偏交易(例如支付、金融)的系统,在考虑扩展性时候,一定要将信息架构、信息模型的扩展性纳入到考虑范围,此类系统数据模型至关重要,也不可能频繁变动。

上面描述方法的特别适用与传统软件、系统集成等需求偏稳定的项目,对于互联网偏创新性的项目就不一定完全适用了,此类项目的现实情况如下:业务模式不确定,会不停试错,验证模式;需求不停变化,要求能够快速响应;全新的行业,没有行业专家,没有行业标杆可借鉴(至多有跨界标杆可参考);此时候,类似精益创业、Scrum之类的敏捷开发模式更适合,但对于复杂的业务而言,业务建模->需求分析->分析设计的理念仍然值得参考借鉴。

最后,最最重要的是:完美系统的架构和扩展性是管理出来的、持续重构出来的。正如各大城市马路不停翻了再修、修了再翻的命运一样,中国大部分公司后任会不停否定掉前任的架构、系统,推倒再来一遍,然后等新系统刚开发出来不久,尚未上线或上线运营一段时间后,再换一帮人继续折腾,然后。。。

总结这么多年的经历,深刻体会到:再烂的系统和架构,如果能够强化管理、持续积累、持续重构、持续完善,都能够有机会成为完美的系统,完美的系统不在于其架构的牛逼和完美,而在于:符合公司的业务模式,能够完美支撑公司业务的高速发展和市场需求的快速响应。

 

http://www.zhihu.com/question/ ... 06943

如何对软件项目开发过程中的风险进行风险控制?

默认分类admin 发表了文章 • 0 个评论 • 180 次浏览 • 2016-12-27 17:11 • 来自相关话题

识别和分析风险并不是软件风险管理的最终目标。针对所发现的每一个软件风险,尤其是高危险度的软件风险,风险管理还需要对它们进行有效的控制,包括:(1) 制定风险管理计划:针对各个重要风险制定风险管理计划,并确保它们的一致性;(2)化解风险:执行风险管理计划,以缓解或消除风险;(3)监控风险:监控风险化解的过程。

n       制定风险管理计划

针对每一个重要的软件风险,制定相应的处理该软件风险的计划。风险管理计划主要描述有关软件风险处理的以下内容-          软件风险名称

-          软件风险由谁引起

-          软件风险的表现形式是什么

-          软件风险可能什么时候发生

-          为什么会发生该软件风险

-          如何避免或者消除软件风险的发生

-          软件风险发生后的处理措施

n       风险化解方式

执行风险管理计划,以缓解或消除风险。一般地,软件风险化解有以下几种方式。

-          避免风险

采取主动和积极的措施来规避软件风险,将软件风险发生的概率控制为零。例如针对用户可能没有时间参加需求评审这一软件风险,项目组可以考虑选择用户方便的时间来进行需求评审,这样“用户不能出席需求评审会”这一软件风险就不会发生。

-          转移风险

将可能或者潜在的软件风险转移给其它的单位或个人,从而使得自己不再承担该软件风险。例如如果开发某个子系统存在技术和人力资源方面的风险,可以考虑将它外包给其它软件开发公司,从而将该软件风险从项目中转移出去。

-          消除发生软件风险的根源

如果知道导致软件风险发生的因素,那么针对这些因素,采取手段消除软件风险发生的根源。例如如果发现导致小刘离开项目组的主要原因是薪酬太低,那么可以通过给小刘增加薪酬来消除发生软件风险的根源。 

n       风险监控

在风险评估和控制过程中,项目组人员和负责人必须对软件风险的化解程度及其变化(如发生概率、可能导致的损失和危险度)进行检查和监控,并对收集到的有关软件风险信息进行记录,以促进对软件风险的持续管理。

风险监控的主要内容包括:监控和跟踪重要软件风险,记录这些软件风险危险度的变化以及软件风险化解的进展,确认软件风险是否已经得到化解和消除,是否有新的软件风险发生等等。
  查看全部
识别和分析风险并不是软件风险管理的最终目标。针对所发现的每一个软件风险,尤其是高危险度的软件风险,风险管理还需要对它们进行有效的控制,包括:(1) 制定风险管理计划:针对各个重要风险制定风险管理计划,并确保它们的一致性;(2)化解风险:执行风险管理计划,以缓解或消除风险;(3)监控风险:监控风险化解的过程。

n       制定风险管理计划

针对每一个重要的软件风险,制定相应的处理该软件风险的计划。风险管理计划主要描述有关软件风险处理的以下内容-          软件风险名称

-          软件风险由谁引起

-          软件风险的表现形式是什么

-          软件风险可能什么时候发生

-          为什么会发生该软件风险

-          如何避免或者消除软件风险的发生

-          软件风险发生后的处理措施

n       风险化解方式

执行风险管理计划,以缓解或消除风险。一般地,软件风险化解有以下几种方式。

-          避免风险

采取主动和积极的措施来规避软件风险,将软件风险发生的概率控制为零。例如针对用户可能没有时间参加需求评审这一软件风险,项目组可以考虑选择用户方便的时间来进行需求评审,这样“用户不能出席需求评审会”这一软件风险就不会发生。

-          转移风险

将可能或者潜在的软件风险转移给其它的单位或个人,从而使得自己不再承担该软件风险。例如如果开发某个子系统存在技术和人力资源方面的风险,可以考虑将它外包给其它软件开发公司,从而将该软件风险从项目中转移出去。

-          消除发生软件风险的根源

如果知道导致软件风险发生的因素,那么针对这些因素,采取手段消除软件风险发生的根源。例如如果发现导致小刘离开项目组的主要原因是薪酬太低,那么可以通过给小刘增加薪酬来消除发生软件风险的根源。 

n       风险监控

在风险评估和控制过程中,项目组人员和负责人必须对软件风险的化解程度及其变化(如发生概率、可能导致的损失和危险度)进行检查和监控,并对收集到的有关软件风险信息进行记录,以促进对软件风险的持续管理。

风险监控的主要内容包括:监控和跟踪重要软件风险,记录这些软件风险危险度的变化以及软件风险化解的进展,确认软件风险是否已经得到化解和消除,是否有新的软件风险发生等等。
 

软件项目经常出现的一些问题及改进方案

默认分类admin 发表了文章 • 0 个评论 • 131 次浏览 • 2016-12-27 17:10 • 来自相关话题

1、 测试人员介入太晚,基本上都是等代码开发完成时,才介入。

改进建议:在项目需求开始启动时,就能有相应测试人员跟进,并随之开始测试的一系列活动;由于在需求阶段可能测试人员的工作量可能较少;可以让其同时兼顾其它项目任务;到测试用例编写阶段才全职投入。

 

2、 需求变化太多太乱,相关文档没有随之更新,文档与项目实际功能不相符;造成很多时候最新的需求都只是藏在个别人的脑中,而测试人员总是最后一个知道需求变化的人。

改进建议:能够建立需求变更体系,到什么阶段时必须停止需求变更(必须在项目前期就让需求提出人明确这一点);每次需求变更必须让需求提出人员确认;需求变化后必须由专人更新相关文档(这些文档都是测试人员编写计划及用例的依据);并能知会相关人员。这样才能做到程序人员修改相应的程序,测试人员修改相应的用例,且能对需求变更后的程序进行正确的测试。

 

3、 项目无分阶段送测,造成无法对阶段性的开发成果进行测试,测试任务积压、问题无法及时发现。

改进建议:在项目前期制定项目计划时,将各阶段性送测纳入到计划中;开发人员根据项目计划进行开发,而测试人员可根据项目计划来安排自身编写用例的先后顺序以及在各阶段性送测时间要求送测(此阶段性送测可视项目的大小、项目与其它系统的关联来定好每个阶段送测的内容);

 

4、 测试人员没有独立的稳定的测试环境,无法控制版本更新;造成太多重复无效的测试,也常会因为提交无效的BUG。

改进建议:最好可以给测试人员提供一个独立的测试环境(包括数据库以及应用程序都是独立的),以保证测试人员所有的BUG都是稳定的、可重复的环境下发现的;如果不能做到独立测试环境情况下,也尽量做到能让测试人员去控制版本更新的频度,以控制测试的有效性。

 

5、 没有一个行之有效的BUG跟踪机制;造成BUG提交重复、回归不及时,或不能正常被回归。

改进建议:项目中的所有成员都利用同一种方式去进行BUG提交、跟踪;BUG分发人员需做到BUG的过滤,来达到BUG的有效性;在BUG表单中需要能及时体现BUG的最新状态;这样项目组人员才都能对项目中已发现、已解决的BUG做到心中有数;项目管理人员也可以对整个项目的状态做到心中有数。

 

6、 无完善的测试用例检查机制,无法对测试过程进行检查,也即无法保证测试结果的真实性。

改进建议:测试人员之间对测试用例进行走查,或开发人员分配时间出来对测试用例进行走查,以保证用例对需求的覆盖率;测试用例能与BUG对应,使用工具管理用例在每个阶段的执行情况,以对测试过程进行跟踪。

 

7、 开发人员与专业测试人员比例严重不合理,而非专业测试(用户测试)介入太早。

改进建议:一般在国内的情况,测试人员与开发人员的比例是1:5左右,但在这里的比例严重不止,一个测试人员都负责多个项目,严重影响测试的质量;对于用户测试一般是在项目验收阶段才介入的,现在都提前介入了;如果用户必须提前介入测试,且作为测试的人力来算的话,那应该由测试来统一安排这些调度,以保证测试的合理分工。
  查看全部
1、 测试人员介入太晚,基本上都是等代码开发完成时,才介入。

改进建议:在项目需求开始启动时,就能有相应测试人员跟进,并随之开始测试的一系列活动;由于在需求阶段可能测试人员的工作量可能较少;可以让其同时兼顾其它项目任务;到测试用例编写阶段才全职投入。

 

2、 需求变化太多太乱,相关文档没有随之更新,文档与项目实际功能不相符;造成很多时候最新的需求都只是藏在个别人的脑中,而测试人员总是最后一个知道需求变化的人。

改进建议:能够建立需求变更体系,到什么阶段时必须停止需求变更(必须在项目前期就让需求提出人明确这一点);每次需求变更必须让需求提出人员确认;需求变化后必须由专人更新相关文档(这些文档都是测试人员编写计划及用例的依据);并能知会相关人员。这样才能做到程序人员修改相应的程序,测试人员修改相应的用例,且能对需求变更后的程序进行正确的测试。

 

3、 项目无分阶段送测,造成无法对阶段性的开发成果进行测试,测试任务积压、问题无法及时发现。

改进建议:在项目前期制定项目计划时,将各阶段性送测纳入到计划中;开发人员根据项目计划进行开发,而测试人员可根据项目计划来安排自身编写用例的先后顺序以及在各阶段性送测时间要求送测(此阶段性送测可视项目的大小、项目与其它系统的关联来定好每个阶段送测的内容);

 

4、 测试人员没有独立的稳定的测试环境,无法控制版本更新;造成太多重复无效的测试,也常会因为提交无效的BUG。

改进建议:最好可以给测试人员提供一个独立的测试环境(包括数据库以及应用程序都是独立的),以保证测试人员所有的BUG都是稳定的、可重复的环境下发现的;如果不能做到独立测试环境情况下,也尽量做到能让测试人员去控制版本更新的频度,以控制测试的有效性。

 

5、 没有一个行之有效的BUG跟踪机制;造成BUG提交重复、回归不及时,或不能正常被回归。

改进建议:项目中的所有成员都利用同一种方式去进行BUG提交、跟踪;BUG分发人员需做到BUG的过滤,来达到BUG的有效性;在BUG表单中需要能及时体现BUG的最新状态;这样项目组人员才都能对项目中已发现、已解决的BUG做到心中有数;项目管理人员也可以对整个项目的状态做到心中有数。

 

6、 无完善的测试用例检查机制,无法对测试过程进行检查,也即无法保证测试结果的真实性。

改进建议:测试人员之间对测试用例进行走查,或开发人员分配时间出来对测试用例进行走查,以保证用例对需求的覆盖率;测试用例能与BUG对应,使用工具管理用例在每个阶段的执行情况,以对测试过程进行跟踪。

 

7、 开发人员与专业测试人员比例严重不合理,而非专业测试(用户测试)介入太早。

改进建议:一般在国内的情况,测试人员与开发人员的比例是1:5左右,但在这里的比例严重不止,一个测试人员都负责多个项目,严重影响测试的质量;对于用户测试一般是在项目验收阶段才介入的,现在都提前介入了;如果用户必须提前介入测试,且作为测试的人力来算的话,那应该由测试来统一安排这些调度,以保证测试的合理分工。
 

2 个考察产品经理执行力和抗压性的实战面试题

默认分类admin 发表了文章 • 0 个评论 • 112 次浏览 • 2016-12-27 17:06 • 来自相关话题

Q1:如果一个项目,需要协调运营、UED、DEV、SQA、DBA、SCM以及其他线PM这些资源协同完成,而且目前需求并不完全明确,需要的资源状况也不明,你打算如何来推动?讲讲具体的做法和详细的步骤。

Q2:如果另外一个项目,是CEO钦点的项目,而且大概会调集全公司1/3的资源来完成,目前完全授权给你,时间只有两周。最近公司技术研发体系新人较多,同时面临着十一国庆长假,该项目在两周上线之后会在CCTV以及各大门户投广告来推广。你会怎么做?

第一问题:
1、在需求并不完全明确的情况下,从需求的来源方,收集需求,分析需求,然后形成需求列表。在需求列表确认后,开始撰写PRD文档和原型的设计。在完成PRD和原型之后,一定要与你的需求来源方,相关的产品人员讨论和确定。
2、在与需求方达成共识后,要组织一个需求分析会,在需求分析会时,召集运营、UED、DEV、SQA、DBA、SCM以及其他线PM共同参加,对你的产品PRD和原型进行讨论和评估。
1)如果不能在会上达成共识,确定要调整内容,及调整时间,下次碰头会的时间。会后总结目前存在的问题,对方案进行调整,准备进行下一次讨论。
2)如果对解决方案能达成共识,在当场要确认,设计,制作,开发,测试的人员及工期。同时要对执行过程中的风险进行评估(比如,你需要使用短信通道进行测试,结果短信通道不可用,是否能在测试时间协调可用)。
3、根据需求分析会确定人员和工期,通过一些项目管理工具(例如Project)记录,并通过邮件等方式把项目进度公示所有人。
4、在整个设计,制作和开发过程中,需要跟踪每个人员的完成进度,并提醒完成日期。中间一旦有请假,或其他事情延后,要尽力协调相关人员追回进度,如果不能追回进度,需要延期,也应提前发邮件通知大家。
5、在项目设计完,需要产品经理确认功能和设计风格后,再转交制作,避免开发完成后,设计不合理再做调整。测试时,产品经理一定要参与测试,测试是最容易发现问题的。
6、在测试完成后,应该请其他产品线的PM及产品需求方进行验收,验收通过方能上线,验收不通过,要对问题进行评估和调整。

第二个问题:
既然是CEO钦点的项目,而且大概会调集全公司1/3的资源来完成,目前完全授权给你,时间只有两周。该项目在两周上线之后会在CCTV以及各大门户投广告来推广。
以上说明该项目非常重要,而且时间比较紧迫。
解决办法:
1、“最近公司技术研发体系新人较多。”说明大家都不太了解,关系比较陌生。可以借用下班时间,请大家一起吃个饭。目的有2个,一是熟悉大家,拉进关系,利于工作的开展。二是借机说明项目的重要,希望大家尽力配合。(至于吃饭的发票公司能报销最好,不能报销可以自己承担)
2、“面临着十一国庆长假,”其实这是同时也是一个赶进度的机会。
1)首先要跟CEO商议,项目时间紧迫,国庆长假加班要给以优厚待遇。(例如:按国家规定发放加班费,给予午餐报销,报销来回打车费等等)。
2)与项目的每一位技术人员协商加班。同时自己也会陪同技术一起加班,随时根据技术的需要解答产品问题。
3)在加班过程中,主动协助项目测试。
要以自己的行动去感染每一个人,希望他们看到你忙碌的样子,也不会丢下你和整个产品不顾的。

补充一下第二问题:
前面只回答了一些协调资源的事情,哪些都是事情的铺垫,是为了事情更好,更顺利的进展。
下面回答项目实施解决方案。
1、对于项目的全部需求进行列表,然后按优先级进行排序。先把重要的核心需求和功能提炼出来,作为一期开发,其他非必须,锦上添花的东西可以进行二期迭代。
2、产品的prd文档和原型利用2天时间完成,并与CEO、运营及其他产品线PM,进行首轮沟通讨论。
3、对首轮讨论中的问题进行微调,然后召集设计、制作、开发、测试等召开产品需求分析会。讲解产品功能,并阐述产品重要性及时间的紧急。并说明完成的上线日期。当时让相关人员确定相应的工期,比如设计1-2天,制作1天,开发3-5天。同时可以考虑无需设计的后台功能技术提前投入开发,在设计完成部分的时候,制作先切图,然后交给技术,各部门同步进行。对于设计和开发的周期控制在5-7天内
4、对于时间比较紧张的可以考虑晚上或长假加班完成。在技术完成部分功能时,提前搭建环境,介入测试。在测试时,邀请公司不太忙的人员参与测试,比如前台,助理类的。
5、整个项目大致的时间规划为:
产品的定义和原型(包括讨论会):3-4天
界面设计:1-2天
界面制作:1天
产品开发:3-5天
产品测试:3-5天
因为会涉及一些功能可以同步进行,比如在设计时,技术要完成数据库建模,架构的规划等。
在2周时间,虽然有些紧张,但是如果参与人员都比较负责的话,足以完成。
因为项目比较重要,为了万无一失,尽量提前1,2天完成。也就是可以利用长假加班,项目完成后可调休或要加班费。 查看全部
Q1:如果一个项目,需要协调运营、UED、DEV、SQA、DBA、SCM以及其他线PM这些资源协同完成,而且目前需求并不完全明确,需要的资源状况也不明,你打算如何来推动?讲讲具体的做法和详细的步骤。

Q2:如果另外一个项目,是CEO钦点的项目,而且大概会调集全公司1/3的资源来完成,目前完全授权给你,时间只有两周。最近公司技术研发体系新人较多,同时面临着十一国庆长假,该项目在两周上线之后会在CCTV以及各大门户投广告来推广。你会怎么做?

第一问题:
1、在需求并不完全明确的情况下,从需求的来源方,收集需求,分析需求,然后形成需求列表。在需求列表确认后,开始撰写PRD文档和原型的设计。在完成PRD和原型之后,一定要与你的需求来源方,相关的产品人员讨论和确定。
2、在与需求方达成共识后,要组织一个需求分析会,在需求分析会时,召集运营、UED、DEV、SQA、DBA、SCM以及其他线PM共同参加,对你的产品PRD和原型进行讨论和评估。
1)如果不能在会上达成共识,确定要调整内容,及调整时间,下次碰头会的时间。会后总结目前存在的问题,对方案进行调整,准备进行下一次讨论。
2)如果对解决方案能达成共识,在当场要确认,设计,制作,开发,测试的人员及工期。同时要对执行过程中的风险进行评估(比如,你需要使用短信通道进行测试,结果短信通道不可用,是否能在测试时间协调可用)。
3、根据需求分析会确定人员和工期,通过一些项目管理工具(例如Project)记录,并通过邮件等方式把项目进度公示所有人。
4、在整个设计,制作和开发过程中,需要跟踪每个人员的完成进度,并提醒完成日期。中间一旦有请假,或其他事情延后,要尽力协调相关人员追回进度,如果不能追回进度,需要延期,也应提前发邮件通知大家。
5、在项目设计完,需要产品经理确认功能和设计风格后,再转交制作,避免开发完成后,设计不合理再做调整。测试时,产品经理一定要参与测试,测试是最容易发现问题的。
6、在测试完成后,应该请其他产品线的PM及产品需求方进行验收,验收通过方能上线,验收不通过,要对问题进行评估和调整。

第二个问题:
既然是CEO钦点的项目,而且大概会调集全公司1/3的资源来完成,目前完全授权给你,时间只有两周。该项目在两周上线之后会在CCTV以及各大门户投广告来推广。
以上说明该项目非常重要,而且时间比较紧迫。
解决办法:
1、“最近公司技术研发体系新人较多。”说明大家都不太了解,关系比较陌生。可以借用下班时间,请大家一起吃个饭。目的有2个,一是熟悉大家,拉进关系,利于工作的开展。二是借机说明项目的重要,希望大家尽力配合。(至于吃饭的发票公司能报销最好,不能报销可以自己承担)
2、“面临着十一国庆长假,”其实这是同时也是一个赶进度的机会。
1)首先要跟CEO商议,项目时间紧迫,国庆长假加班要给以优厚待遇。(例如:按国家规定发放加班费,给予午餐报销,报销来回打车费等等)。
2)与项目的每一位技术人员协商加班。同时自己也会陪同技术一起加班,随时根据技术的需要解答产品问题。
3)在加班过程中,主动协助项目测试。
要以自己的行动去感染每一个人,希望他们看到你忙碌的样子,也不会丢下你和整个产品不顾的。

补充一下第二问题:
前面只回答了一些协调资源的事情,哪些都是事情的铺垫,是为了事情更好,更顺利的进展。
下面回答项目实施解决方案。
1、对于项目的全部需求进行列表,然后按优先级进行排序。先把重要的核心需求和功能提炼出来,作为一期开发,其他非必须,锦上添花的东西可以进行二期迭代。
2、产品的prd文档和原型利用2天时间完成,并与CEO、运营及其他产品线PM,进行首轮沟通讨论。
3、对首轮讨论中的问题进行微调,然后召集设计、制作、开发、测试等召开产品需求分析会。讲解产品功能,并阐述产品重要性及时间的紧急。并说明完成的上线日期。当时让相关人员确定相应的工期,比如设计1-2天,制作1天,开发3-5天。同时可以考虑无需设计的后台功能技术提前投入开发,在设计完成部分的时候,制作先切图,然后交给技术,各部门同步进行。对于设计和开发的周期控制在5-7天内
4、对于时间比较紧张的可以考虑晚上或长假加班完成。在技术完成部分功能时,提前搭建环境,介入测试。在测试时,邀请公司不太忙的人员参与测试,比如前台,助理类的。
5、整个项目大致的时间规划为:
产品的定义和原型(包括讨论会):3-4天
界面设计:1-2天
界面制作:1天
产品开发:3-5天
产品测试:3-5天
因为会涉及一些功能可以同步进行,比如在设计时,技术要完成数据库建模,架构的规划等。
在2周时间,虽然有些紧张,但是如果参与人员都比较负责的话,足以完成。
因为项目比较重要,为了万无一失,尽量提前1,2天完成。也就是可以利用长假加班,项目完成后可调休或要加班费。

IT项目管理中的团队沟通

默认分类admin 发表了文章 • 0 个评论 • 122 次浏览 • 2016-12-27 16:55 • 来自相关话题

在很多年以前,一位好的项目经理并不一定要是一位交流高手。客户们通常并不喜欢这种情况,但是由于项目经理能够向他们提供产品,他们也就接受了。然而,在今天这个崭新的IT世界里,所有的项目都要在客户的合作下才能够完成,而这种合作绝对离不开良好的交流。事实上,项目中出现的很多问题都是交流不善所产生的结果。但是,聪明的项目经理是懂得如何来解决交流中出现的问题的。
问题所在
一旦交流出现了问题,项目的成功就会遇到阻碍。那么问题通常出现在那些方面呢?
期望值不同
项目经理要努力让与项目有关的每一个人建立起同样的期望值,包括项目应该何时完成、带来什么样的结果,成本如何。这些期望值最初在对项目进行计划时就应该在计划书中明确下来。但是,很多项目经理没有能够让关键股东及时了解期望值的变化。人们在做出决策时通常要依据当时所掌握的最佳信息,如果项目经理不能让所有人都对项目的期望值有同样的了解,就会在同步性上出现问题。
意外
如果不能及时了解项目进展,人们就会对项目进行过程中出现的变化感到意外。例如,如果你无法按照预计工期完成项目,而又不想让股东在项目进展报告中了解到这一点,那么该如何去做呢?
前摄性的交流意味着及时意识到无法按照预计工期完成项目的风险。然后继续按照预计工期的要求进行项目。如果你不得不宣布无法按照预计工期完成项目,其他人能够有所准备,不会因此而感到过于不安。人们通常会由于在最后时刻才得知坏消息而感到愤怒和沮丧,因为他们已经来不及适应变化了的情况了。
没有人知道项目的进展情况
在一些情况下,股东们并不真正了解项目的进展情况。如果没有正确的信息,人们是无法做出最佳的决策的。如果他们不了解项目的进展情况,就要花费额外的时间去搜集更进一步的信息。事实上,如果你及时向股东提供项目进展信息,而他们却不停的向你追问更新的信息,这可能表明你们之间的交流还是存在着问题。
人们在最后时刻受到项目的影响
在这种情况下,项目经理没有提前让其他人了解项目会对他们产生的影响。交流通常总在最后一刻,但往往是为时已晚。
这样的例子有很多。例如,项目经理在三个月之前就已经知道自己需要一位专家,但是却在立即需要专家帮助之前一周才开始寻找。这样,其他人就无法做好充分的准备。
小组成员不知道大家对自己的期望值
交流问题不仅可能出现在项目小组与其他部门、人员之间,还有可能出现在项目小组的内部。有一些项目经理没有很好的同小组成员进行交流,让他们了解大家对自己工作的期望值。有的时候,项目经理不知道什么时候该给小组成员布置工作任务,有的时候,项目经理明明知道自己对小组成员的期望值,但却没有及时告诉他们,直到发现他们的工作出现了问题。有的时候,由于项目经理没有说明工作要求,小组成员花费时间做了很多不必要的工作。无论是对于项目经理来说还是对于小组成员来说,这种交流不善的情况都让他们做了很多额外的工作,也难免让他们的心情感到沮丧。
怎么办?
有些项目经理在刚开始的时候并不是良好的交流者。如果你觉得自己属于这一类的话,就应该通过培训或是他人的指导来更好的学习和掌握交流技巧。但是,在大多数情况下,交流出现问题并不是因为缺乏交流技巧,而是因为没有对交流给予足够的重视。很多项目经理把前摄性的交流看作最不重要的一件事。当他们与他人进行交流时,通常既简单又仓促,给人一种他们不愿意花费时间与经历与别人进行交流的感觉。
良好的交流秘诀在于让听者——而不是说者——成为焦点。要站在听者的角度上考虑问题,想想他们想要得到什么样的信息,什么信息对于他们来说最有用。如果你在起草一份项目进展报告,那么一定要注明所有的必要信息,让读者了解项目的进展情况,包括已经取得的成绩、事项、风险、变化以及其他一些问题。如果在下一步的工作中你需要获得某方面的资源支持,那么要尽早同资源经理打招呼。并且要不断的提醒他注意你的需求。
一般来说,如果你的所作所为曾经让他人感到意外,这就是一个交流不善的标志。(唯一的例外是项目经理本身也感到了意外)项目经理同样应该注意同小组成员之间的交流。如果你发现小组成员不清楚项目的工期,或是他们在做一些并不需要去做的工作,那么就该考虑一下自己同他们之间的交流是否存在着问题了。
很多项目都存在着问题。交流不善是导致很多问题产生并且激化其他问题的原因。从另一方面来说,前摄性的交流可以帮助解决很多问题。不要觉得交流是一种负担,通过它可以使项目平稳的进行——大家就会少一些失望,少一些不确定,也不会再感到意外。 查看全部
在很多年以前,一位好的项目经理并不一定要是一位交流高手。客户们通常并不喜欢这种情况,但是由于项目经理能够向他们提供产品,他们也就接受了。然而,在今天这个崭新的IT世界里,所有的项目都要在客户的合作下才能够完成,而这种合作绝对离不开良好的交流。事实上,项目中出现的很多问题都是交流不善所产生的结果。但是,聪明的项目经理是懂得如何来解决交流中出现的问题的。
问题所在
一旦交流出现了问题,项目的成功就会遇到阻碍。那么问题通常出现在那些方面呢?
期望值不同
项目经理要努力让与项目有关的每一个人建立起同样的期望值,包括项目应该何时完成、带来什么样的结果,成本如何。这些期望值最初在对项目进行计划时就应该在计划书中明确下来。但是,很多项目经理没有能够让关键股东及时了解期望值的变化。人们在做出决策时通常要依据当时所掌握的最佳信息,如果项目经理不能让所有人都对项目的期望值有同样的了解,就会在同步性上出现问题。
意外
如果不能及时了解项目进展,人们就会对项目进行过程中出现的变化感到意外。例如,如果你无法按照预计工期完成项目,而又不想让股东在项目进展报告中了解到这一点,那么该如何去做呢?
前摄性的交流意味着及时意识到无法按照预计工期完成项目的风险。然后继续按照预计工期的要求进行项目。如果你不得不宣布无法按照预计工期完成项目,其他人能够有所准备,不会因此而感到过于不安。人们通常会由于在最后时刻才得知坏消息而感到愤怒和沮丧,因为他们已经来不及适应变化了的情况了。
没有人知道项目的进展情况
在一些情况下,股东们并不真正了解项目的进展情况。如果没有正确的信息,人们是无法做出最佳的决策的。如果他们不了解项目的进展情况,就要花费额外的时间去搜集更进一步的信息。事实上,如果你及时向股东提供项目进展信息,而他们却不停的向你追问更新的信息,这可能表明你们之间的交流还是存在着问题。
人们在最后时刻受到项目的影响
在这种情况下,项目经理没有提前让其他人了解项目会对他们产生的影响。交流通常总在最后一刻,但往往是为时已晚。
这样的例子有很多。例如,项目经理在三个月之前就已经知道自己需要一位专家,但是却在立即需要专家帮助之前一周才开始寻找。这样,其他人就无法做好充分的准备。
小组成员不知道大家对自己的期望值
交流问题不仅可能出现在项目小组与其他部门、人员之间,还有可能出现在项目小组的内部。有一些项目经理没有很好的同小组成员进行交流,让他们了解大家对自己工作的期望值。有的时候,项目经理不知道什么时候该给小组成员布置工作任务,有的时候,项目经理明明知道自己对小组成员的期望值,但却没有及时告诉他们,直到发现他们的工作出现了问题。有的时候,由于项目经理没有说明工作要求,小组成员花费时间做了很多不必要的工作。无论是对于项目经理来说还是对于小组成员来说,这种交流不善的情况都让他们做了很多额外的工作,也难免让他们的心情感到沮丧。
怎么办?
有些项目经理在刚开始的时候并不是良好的交流者。如果你觉得自己属于这一类的话,就应该通过培训或是他人的指导来更好的学习和掌握交流技巧。但是,在大多数情况下,交流出现问题并不是因为缺乏交流技巧,而是因为没有对交流给予足够的重视。很多项目经理把前摄性的交流看作最不重要的一件事。当他们与他人进行交流时,通常既简单又仓促,给人一种他们不愿意花费时间与经历与别人进行交流的感觉。
良好的交流秘诀在于让听者——而不是说者——成为焦点。要站在听者的角度上考虑问题,想想他们想要得到什么样的信息,什么信息对于他们来说最有用。如果你在起草一份项目进展报告,那么一定要注明所有的必要信息,让读者了解项目的进展情况,包括已经取得的成绩、事项、风险、变化以及其他一些问题。如果在下一步的工作中你需要获得某方面的资源支持,那么要尽早同资源经理打招呼。并且要不断的提醒他注意你的需求。
一般来说,如果你的所作所为曾经让他人感到意外,这就是一个交流不善的标志。(唯一的例外是项目经理本身也感到了意外)项目经理同样应该注意同小组成员之间的交流。如果你发现小组成员不清楚项目的工期,或是他们在做一些并不需要去做的工作,那么就该考虑一下自己同他们之间的交流是否存在着问题了。
很多项目都存在着问题。交流不善是导致很多问题产生并且激化其他问题的原因。从另一方面来说,前摄性的交流可以帮助解决很多问题。不要觉得交流是一种负担,通过它可以使项目平稳的进行——大家就会少一些失望,少一些不确定,也不会再感到意外。

如何解决团队中的冲突?

默认分类admin 发表了文章 • 0 个评论 • 138 次浏览 • 2016-12-27 16:52 • 来自相关话题

解决团队中冲突的方法主要有一下几种:

1. 解决问题(Problem Solving)

这红方式也成为Confrontation,是解决冲突的最好办法,问题的存在是造成冲突的原因,找到问题的正确解决方法。一个问题存在一个正确的解决方法,而相关的事实会正式这样的解决方案,一旦发现相关的事实,就把这些事实呈给相关各方,而解决方法也会清楚的显示出来,这样得到的解决方案是永久方案,冲突也会消失。这是项目经理最常用的冲突解决方法,也是一种双赢的冲突解决技术。

2. 妥协法(Compromise)

当冲突各方同意各让一步而达成一个解决方案时,就达到了妥协。相关各方决定自己放弃什么,坚持什么最终通过这些放弃,得到一个解决方案。

3. 调和法(Smoothing)

调和法是一种临时的冲突解决方法,即力图让冲突显得并不像实际情况那样严重。冲突各方彼此减少双方之间的分歧,集中主力哪些双方非常一致的地方。

4.撤退法(withdrawal)

撤退法是使处于冲突中的一方或双方从冲突中退出。问题虽然不会得到解决,但是冲突不会继续。

5. 强制法(forcing)

项目经理利用其权利解决恩特,这是一种得-失的冲突解决方案,是一种永久性的解决方案,但是会给团队造成一定的影响。因为人们服从于权利并不意味着他们同意你的观点。 查看全部
解决团队中冲突的方法主要有一下几种:

1. 解决问题(Problem Solving)

这红方式也成为Confrontation,是解决冲突的最好办法,问题的存在是造成冲突的原因,找到问题的正确解决方法。一个问题存在一个正确的解决方法,而相关的事实会正式这样的解决方案,一旦发现相关的事实,就把这些事实呈给相关各方,而解决方法也会清楚的显示出来,这样得到的解决方案是永久方案,冲突也会消失。这是项目经理最常用的冲突解决方法,也是一种双赢的冲突解决技术。

2. 妥协法(Compromise)

当冲突各方同意各让一步而达成一个解决方案时,就达到了妥协。相关各方决定自己放弃什么,坚持什么最终通过这些放弃,得到一个解决方案。

3. 调和法(Smoothing)

调和法是一种临时的冲突解决方法,即力图让冲突显得并不像实际情况那样严重。冲突各方彼此减少双方之间的分歧,集中主力哪些双方非常一致的地方。

4.撤退法(withdrawal)

撤退法是使处于冲突中的一方或双方从冲突中退出。问题虽然不会得到解决,但是冲突不会继续。

5. 强制法(forcing)

项目经理利用其权利解决恩特,这是一种得-失的冲突解决方案,是一种永久性的解决方案,但是会给团队造成一定的影响。因为人们服从于权利并不意味着他们同意你的观点。