1.1.1 签单前和用户沟通
一，质量要求需要方便测量，以避免以后产生纠纷。比如：程序不容易崩溃，就不好测量。可以改成：a，平均一天崩溃一次。b，崩溃时不损坏数据。c，崩溃后重启可以解决问题，且重启过程不超过5分钟。二，提供多个不同收费的质量要求，供用户选择，防止提不合理要求。比如：平均一周崩溃一次免费，一天崩溃一次收费10万。三，有些不方便测量的质量需求，可以拆分成可测量的需求。比如：易用性往往可以拆分具体功能需求。四，不方便测量的需求，单独报价，如美观。
1.1.2 签单后和用户沟通
一，由于术语理解得不同，很容易发生误解。用户说的操作一定要拆分到原子操作，那个版本，点击那个菜单、按钮,输入了什么等，整理成文档等确认。如果是第一次沟通尤其如此。二，聆听用户的问题，用户的方案要沟通、优化。有人的电视架子坏了，需要换螺丝，很老的螺丝，抱着试试的心态找了多家五金店，都没有。最后一家店主问要这种螺丝干什么，说清楚后，卖他另一种可用的螺丝。
1.1.3 和产品经理沟通
找到需求的原始去处（客户、上司），一起沟通，看是否有其它可行方案。常见冲突：一，影响开发期质量（如：可维护性）或实现不了，让架构师和产品经理沟通。二，影响工期，让项目经理和产品经理沟通。三，逻辑需要优化，请他按规范整理需求文档。然后在此基础上沟通，看是自己理解错误，还是逻辑需要优化。四，投入产出比低的需求，这个是产品经理的权利和责任。如果不让自己免费加班，听他的 。五，需求经常变化，凭修改记录与之沟通，源头可能在客户那。