项目中的风险控制:如何尽量不让自己的项目推倒重构？
作者：互联网
声明本文纯个人见解，欢迎持不同意义的朋友理性交流。
1.一切从需求出发，一切由业务决定非流行的技术决定。
业务需求决定决定技术需求，比如我们要定制一套MES系统，因为系统的定制性很强，所以完成没有必要使用Saas模式。
这就比给乞丐一辆豪车，他就是能开，但加油费都出不起也没有个锤子用！
2.技术采用层面上不要激进采用新技术，先采用成熟的技术满足需求后再做锦上添花。
对标题做个说明：
1.采用成熟的技术是在满足业务需求为前提的；
2.为什么不要激进呢？新技术如果没有做过足够的可行性校验很可能做到最后做不下去，切记，切记；那个时候造成的成本事小，工期是大。凡事以结果为导向，那个时候很难收场。相信我，到时只有你也仅有你会负责任。
3.重视并做好调研工作
不要轻视调研工作，要静下心来做好调研工作。七分调研三分开发，相信我这是有道理的。记得郭德刚的一个段子：好不容易挖了一口井，结果不但没有给工钱反正要打人；原因是把客户的图纸看反了，是让他建个塔。
4.沟通角度区别
我始终认为一个合格的项目经理沟通能力是最基本的要求，一个优秀的IT项目经理还要具备一定的技术能力【最好是开发出身】。因为这个职位是一个界于需求方与实现方的桥梁，在需求提出时要有最基本的可行性分析（大家还记得项目经理要求程序员实现按手机壳的颜色自动切换APP颜色主题，程序员与项目经理对打的真实事件吧）。沟通过程中不要情绪化，更不要翻旧账。
与需求部门的沟通：
1.关注点集中在需求上（最主要先了解具体要解决的问题或者是想达到的目的），很多人太专注细节本身。
2.尽量用通俗的方式进行沟通；
例如：我要实现一个根据任务类型批量生成任务列表，这里就需要有一个类型表、类型模板表，然后通过Insert into (select * from 类型模板)，但在沟通过程中我会举例：类型就叫饭店的菜名，类型模板就好比具体的做法，任务就好比是来了个客人根据菜名来点菜。切不要涉及技术问题。
3.不要指着一次沟通就能全部了解他的需求；这时需要你去引导他做选择（切记不要替他做选择）
4.沟通结果要形成文档后把你对他的理解转换成文字并讲给需求以确认你的理解；
与开发部门的沟通：
1.关注点应该是业务逻辑关系、实现方式。
2.一定要有开发需求档（语言尽量简明并且准确），减少沟通的频次，增加开发效率。
3.一定要开放式沟通；收集风险点与难点。
5.项目对接人
项目一定要找一个具体的人需求对接人，而不是你亲自去找具体业务流程中涉及的人员去沟通，相信我如果这样干下去，这个项目的交期会不可控。
所以经常看到项目经理到每个部门去核实需求会东一句西一句，每个部门都站在自己部门的角度考虑问题，而通常在一人部门增加一个人的人力，可能另一个部门会省去三个人的人力，但考核过程中增加人力的部门主管会觉得我的KPI增加了至于其它部门是否减少与自己部门没有半毛钱关系！两个或两个以上的部门会扯皮，最后做了一个平衡后发现不是大老板想要的，项目经理则里外不是人！
6.开发人员管理
有一个原则 ：讨论的时候各抒己见，那怕是明显错误的，很可笑的，不可能实现的都要听人把话讲完（六个帽子思维方式）；但是最终需要拿主意的时候，Lead不能优柔寡断，因为最终你是要为这个项目的结果负责的，所以你要坚决站出来做个决定，决定后不要再重复再讨论同一问题，最后要求开发人员全力执行，那怕错的也要执行。事实证明：民主泛滥会增加内部资源消耗！
7.摆正态度
任何需求不可能是一成不变的，需求的变更一定会有业务的变更。所以如果无论是开发人员还是项目经理如果不能理解那我会劝你这个行业真的不适合你。
这时正确的要做的事是要把相应的变更需求整理好并让需求方确认（或签字），工期与工作量是由需求方承担的；（这句话很多人会误解：1.如果需求方本身和你就是一个公司也有必要这样吗？是的，因为你作为负责人需要把自己的小团队看作是一个小公司 2.会有很多人觉得没有必要这么做！因为这样做会让提出需求方在提需求时怕担任责任而忽略了实现情况，其实不是这样的！事前需要沟通清楚，表示新的变更是三七开的，三分在需求收集方，七分在需求提出方；大家把责任分清楚，至于我帮你修改是人情而不是义务【做人一样，你在帮一个人的时候要尽量做到这是帮他的而非是你的义务】，避免让需求方觉得你的劳动是廉价的，是义务的！）
标签：需求,重构,项目经理,不要,沟通,项目,推倒,部门,需求方 来源： https://blog.csdn.net/weixin_44690195/article/details/115011229