开发思维到业务思维的转变
1、项目全局观
开发工作不是流水线的工作，不仅仅是每个项目干的漂亮就行。
而是从整个项目全局来看，小到为整个项目负责，大到为每一个用户所呈现的产品负责。
在排期相对合理的情况下，
我们有足够的时间，边做、边思考、边总结。这样是不是最佳实践，有没有更有效的方法，现在的流程是不是还可以优化，怎么让项目变得更好，更便于维护，便于新人上手等。
这是除了做好每个需求外，更深层次还可以做的。
2、开发思维到业务思维的转变
举个需求变更的例子。
从开发/实现角度去看，有些东西变来变去，改来改去真的不胜其烦。可能进一步怀疑合作伙伴，上下游配合是不是有问题，甚至怀疑能力的问题等等。
但是我们换成业务角度，去看需求变更这件事，就会更加的理性。比如这次变更对用户的影响，是否对我们达到产品目标有积极作用，或者对我们未来决策的是否有帮助，对我们以后项目维护扩展更有利等等？
有了这些思考，就会很乐意做一些好的正向的需求变更，因为这种变更对于用户是更合理的，是有效的需求变更。
另一方面，我们也会根据自身掌握的专业知识结合业务背景，给出更好的建议，加速产品上的决策，亦或屏蔽掉那些无用的需求变更。
如此，大家就能促使需求尽快达到一个稳定的状态，而不是在此之前永无休止的尝试，变更和成本浪费。
时间久了，整个团队的各个角色都会形成合力，合作的效率也会大大提升。
3、产品不光是产品负责，此产品非彼产品。
一个是产品岗位，一个是产品本身。
产品的好坏不应该只是产品岗位的某个人负责，而是从上到下每一个产品流程的参与者都应该负责。
有了这个前提，那也就意味着，产品的决策不应该只是产品岗位的人说了算。
所有的参与者都有权利/义务提出自己的建议和意见，帮助产品做出更好的决策。
说的更通俗些，就是我们不仅仅是照着prd或者设计稿去执行就可以，而要抱着批判性的思维，不断问自己，这么做合理吗？凭什么要这么做，我有更好的想法可不可以提出来？
其实，产品的终态都要朝着更合理的方向发展的，而在这个过程中，需要通过漫长的反馈来不断修正和迭代。那如果有效的建议和决策能加速这个过程，对整个团队和产品本身将带来巨大的收益。