在it领域，唯一不变的就是经常要变。为此，工程师们疲于奔命。作为过来人，应对策略如下：
1，需求要正式的提，正式的传播，正式的分发：组织需求调研会、沟通会，形成会议纪要抄送给各方，即：项目各方统一认识，形成需求基准，留痕。
2，所有的开发计划基于双方达成共识的需求版本。开发计划传播出去，给到项目各方，留痕。
3，如果要变更需求，请参考第一步。同时，开发计划做同步延期，声明是因为需求做了变更。延期后的计划，要做正式的提交、传播，书面留痕，即第二步。
4，把前面三步做扎实之后，需求再变更，你怕个dei：你团队就这么几个人，就这几杆枪，即使加班也就24个小时。天塌下来有老板顶着，客户如果不服翻邮件怼他。即使打官司你都输不了。
如果客户非要变更，请他发正式邮件（重复上面1-3步，等待乙方排期），客户如果豪横，那就加钱、老板加人，或者老板重新划优先级。这岂不是多赢的局面！
不会写代码、不会设计产品的项目经理不是好律师。
作为曾经的医疗软件研发工程师、曾经的医疗大数据产品经理、持软考高级职格上岗既干总包又干分包的系统集成高级项目经理，现在的法律工作者，欢迎关注我的微信公众号“it与法”。