当初学习这个主要是为了能够对项目管理有一定的了解，对平时的项目开发有一定的帮助，虽然中途因为一些原因没有学习完，对自己的感触也是很大的
系统集成管理里面有很多管理分类，对我这个技术开发人员来说，有几点内容实实在在可以运用到日常的开发中
开发人员贯穿项目立项、开发、运维、消亡的整个生命周期，但是单从最值得我们开发注意的一些点，或者说我比较收益的点，是一下几个方面，在开中我们往往有几点困扰，需求不明确就要去评估工作，中途需求变更，进度因为一些因素不能按时完成等，系统集成管理在里面进行了分析说明
需求如何去管理？其实这一块包含很多内容，从项目立项确定项目目标之后，需要明确项目的需求范围，开展后期工作。一般对于内部项目我们可以去研讨或者群体创新来收集需求，但是对外外部承接来的项目，大多数依赖于产品经理从客户那边访谈后需求结果。收集完集体需求后，一般可以自上而下的分解工作，这时候就形成了需求到人了，形成了需求跟踪矩阵，基本这个时候需求和项目范围一般就确认了。当然这其中可能涉及到一些方案评估，需求调整等。这个拆解到具体对象很重要，方便我们后续需求跟踪。这也就是第二个问题，进度如何把控？
项目进度规划工作，7个过程不可少：规划进度管理过程、定义活动过程、排列活动顺序、估算活动资源、估算活动持续时间、制定进度计划、控制进度。其实说白了就是产品给出需求后，我们来根据各端的资源来配合情况，来制定出各个功能模块的开发起始、结束和消耗的工时。这个为什么能帮我们管控项目进度？一方面能暴露出早期资源协调问题，避免造成后期的交付延期。还有一个能衡量出整个的一个工作量，在交付时间限定的情况下可以砍掉一些需求或者加派人手。这些是我们日常都做的，我们主要的问题是不正常需求变更导致的进度有变啊，一定会有人这样说。那么正常的需求变更是怎么样子的呢？
其实需求变更走的就是一开始立项之后需求确认的一个流程，也就是还要根据新的变更来定义范围，分解工作，重新排期。对其实我就是说了废话，哈哈哈。一句话就是说变更可以，一切都要重新定义了，验收范围，交付时间，工作量都要重新评估。一般来说如果不想变更交付时间，那只能投入更多的钱来让员工赶工，增派人手，如果投入也不想增加，那就一句话，砍需求吧！
越大的项目，发现沟通尤为重要，项目中的冲突屡见不鲜。冲突主要是由于项目的高压环境、责任模糊、存在多个上级导致的。我们要明白，冲突解决要聚焦在问题而不是个人，应该聚焦在现在，而不是过去。一般找到问题症结我们解决即可，但是对于一些两方争执不下的问题，就需要通过强制、妥协、求同存异、合作的方式来解决。避免问题，平时的沟通很重要，需要开展过程中项目负责人需要不停的向相关干系人征询、说明和叙述，确保项目的沟通不是单向的。很多问题都是因为沟通单向导致的，重则引起冲突。
最后，虽然没有学习完，但是也受益良多，之后也会继续学习完成的，从管理角度看整个开发过程也是很有利与我们平时的项目开展的
网友评论