研发人员应对需求的言与行
2017-06-05 18:23
190 查看
引言
工作三年多,没呆过什么大型的互联网公司,有幸经历了众多因项目环节缺失所引发的种种问题,内心深恶痛绝,打算用几篇博客记之。总结下自己工作,捋一捋收获。分享自己的认识,供大家参考借鉴,当然会有很多不对的地方(比如说错别字),也望各位指正。
前段时间在几大教学网站购买了几套关于
项目集成管理工程师的教学视频,深有所感。
版权所有:_ OE _, 转载请注明出处:http://blog.csdn.net/csnd_ayo
引言
关于需求
需求的定义
为需求设置门槛
阐明需求的利弊
记录需求
总结
结语
关于需求
需求,这个词看着又爱又恨。因为没有需求就没有我们软件开发者存在的必要;而不假思索的需求,又在蚕食着我们那些不为人知的劳动力。作为一个脑力工作者,我们该如何面对这些繁杂错乱的需求。需求的定义
首先,我们的需求不是指那些一两天不到就可以搞定的事情,而是需要8天至10周,甚至更长的时间去完成,才算的上是需求。需求是单指对功能的增加或补充,不是对原功能的修改。以上是我个人对需求的定义
为需求设置门槛
需求文档化简而言之就是让提需求的人写一份文档
让提需求的人明白自己的想法
不要怀疑这个点,因为他真实存在。有很多需求都起于一念之间,有的时候他自己根本没有认识到需求会对哪些资源有影响,心里只是觉得这个点子不错,根本没有深思熟虑。
以表慎重
如果连一份文档都不愿意写,甚至是写不出来,那它还有什么可以执行的价值可言呢?
可重复查阅
靠嘴巴说出来的需求,是不具备确定性的,就是说前十分钟说的内容,再说一遍的时候可能会变了一个味道,虽然中心脉络一致,但不具备可以推敲的实质内容。听的人就更不用说了,前一分钟说的,下一分钟可能就忘记百分之六七十了。
“转述失真”的道理都已经烂大街了,而文档也是目前最好的解决方法。
让大家知道
简而言之就是做一个评审
一个需求的提出,不应该是两个人私下敲定,
这个主意很好吧?
可是..
先做再说嘛,不做怎么知道?,这种僵持之后的
先做再说叫人胆寒。
如果具备真正的执行条件,应当广而告之,集思广益。而且这样也可以对这个需求进行很好的扩充或修补。
阐明需求的利弊
对于一个需求的提出,作为一个有经验的研发人员,应该会有一个初步轮廓性的认识(这是前提)。阐明原因
对于项目方提出的需求,我们可以少谈利,因为作为一个研发人员,你要讲述的是别人不能讲述,或无法轻易阐述的事实。
应该用通俗易懂的话阐明其中利害关系,让普通的业务人员对需求有清晰的认识。
阐明方法
这里以
引入第三方平台为需求驱动。
忌
这样的引入会打破原有的设计,
这个需求会大幅度延缓我们的工期
在阐明的时候,不具备专业知识的人是无法清晰的认识到上面的损失的。
可以做以下的修改。
这样的引入会打破原有的设计
该需求的引入与什么相关联的
基于第三方平台开发,我们开发的A、B、C、D … 模块全部都要作废。因为 A 模块针对解决的是 xxxx, B模块解决的是 xxxx …,而第三方平台已经包含了我们这些模块相似的功能。
前瞻性的影响
若引用并基于第三方平台进行开发,我们分别有 i、e、g、h、c…功能会受到影响,其中还可能会影响到我们关键的 o 功能,这次平台的引入还没有经过准确计算,估计会进入大概为期 n 个月的开发中。
开发周期计算的关联因素有:第三方SDK的文档的完整性、新软件架构设计方案(精细版)、与第三方的交流成本 …
影响开发周期不确定因素有:第三方的配合度,第三方SDK的稳定程度、第三方的专业程度 …
并且在接下来的开发中,若遇到底层模块的错误,不易及时修复。
给予建议
因改动量大,涉及面广,建议走变更流程或重新立项。(从小公司的角度来说就是,改的太多了,这东西有可能要重新做,大幅度的改,损失很显然,你慎重考虑一下。)
这个需求会大幅度延缓我们的工期
具体的影响范围
工期的计算方式
影响的具体时长
不确定的影响因素
给予建议
记录需求
需求的记录,也显得尤为重要,他不单单要记录通过的需求,那些需求提出来,但是被否了的需求,也要加以记录并说明,对于整个项目来说,可以作为很好的回顾材料。(当然他还有比这更大的好处)总结
面对需求,探讨是必须的,除探讨之外,稍微需要时长的工作,你可以做如下应对。需求方提供一份书面说明(若工期长的,应书写正规的需求文档格式)
聚拢关系人以及与需求方同级的领导,对需求进行深一步的探讨
根据需求,提出自己的疑虑,问题关联性强,且关系成败的,要求需求方给予准确的回复
结语
我将用亲身实例来讲解项目过程中所遇到的各个环境的重要性关于需求 1 [点击前往]
关于变更 2 [点击前往]
作者: @_ OE _
Wiki - 软件需求是 (1)用户解决问题或达到目标所需条件或权能(Capability)。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
(3)一种反映上面(1)或(2)所述条件或权能的文档说明。它包括功能性需求及非功能性需求,非功能性需求对设计和实现提出了限制,比如性能要求,质量标准,或者设计限制。 ↩
原有项目以及具体做法,在实施过程中都可能有所改变,这称为项目变更。 ↩
相关文章推荐
- 测试人员遇到不断变化的项目需求该如何应对?
- 探析项目主导型的IT业的人员需求变化及其应对办法
- 探析项目主导型的IT业的人员需求变化及其应对办法
- 阿里云MVP赵玮主题分享:什么才是这个时代最需要的BI人员?BI团队如何高效应对快速扩张的公司的需求?
- 从需求分析想到的测试人员业务分析方法
- 我是如何对研发和测试人员进行量化的绩效考核的
- 河南有大数据算法和系统研发需求的公司情况
- 互联网研发的高级技术人员应该具备怎样的知识结构
- 论测试人员为什么需要参加需求评审
- 研发人员为什么留不住?(2)——原因的解析(上)
- 研发人员为什么留不住?(2)——原因的解析(上)
- 项目管理---项目经理如何应对客户的需求变更?
- 项目管理者如何应对需求的不断变化
- 软件企业研发人员激励机制研究(转载)
- 如何打造139团队(不同层次人员的选择与培养,大型研发团队,大型敏捷开发团队)
- 如何成为一名需求分析人员
- 敏捷开发“松结对编程”实践之一:人员结构篇(大型研发团队,学习型团队,139团队,师徒制度)
- 如何应对没有需求的测试
- 技术人员应对「考核」的一些思考
- 敏捷开发“松结对编程”实践之六:大型团队篇|后记(大型研发团队,学习型团队,139团队,师徒制度,人员招聘,职业生涯规划)