自上世纪七十年代开始，“软件危机”促使人们研究和改变软件技术以及管理方法。自从进入软件工程时代至今，一个软件团队已经发展到包含多种角色，甚至达到成百上千人的规模。虽然在一定程度上规范了软件开发流程，但却不会解决所有问题。
IT界的各路人马总会拿出产品经理和程序员之间的故事来调侃，由此可见产品经理和程序员之间会在日常工作中摩擦出怎样的火花，更不要说项目中其他需要对接的事情了。那么，程序员怎么做才能使得团队效益最大化呢？我的主张是“退一步”。
与产品对接，要站在产品角度思考
程序员给人的固有印象往往是呆呆傻傻，不懂审美，不懂UI。很多人觉得程序员也就不必懂产品，懂业务了，其实这是大错特错。站在产品角度思考问题并不是为了与产品人员和谐相处，这恰恰是为了能够让自己参透业务以至于精简开发工作量。
要记住，产品人员是最接近客户的人，他们是最了解用户想要什么的人。但是，只有程序员才有可能是那个既懂业务又能将业务落实成代码的人。
通过代码实现业务是程序员的工作。但反过来思考，将用户需求，现实中的业务抽象得出的逻辑恰恰就是代码逻辑。将现实中的业务抽象的越好，开发就会越省力。
与架构对接，要从架构角度看问题
不谋全局者不足以谋一域，不谋万事者不足以谋一时。
程序员每天只写CRUD，同样需要站在软件架构的角度来看待问题。正所谓站得越高看得越远，如果只看脚下，自己永远会有一堆问题，一堆抱怨。比如，前端开发会抱怨后端提供的API不灵活，后端会抱怨前端事情多。每个人都看自己脚下，那么工作时的沟通成本会变得相当高。
只有大家都站在一个高的层级上面协商开发中的问题，才能真正的把问题捋顺，组内成员之间才能够高效的推进开发工作。于此同时，从架构的角度理解自己手头的工作还能让自己的思维不受限制，能有更好的发挥。
自己闲暇时，要能够扩展精进技术
通常一个团队拿到需求都要评估可行性，那么衡量可行性的尺度是什么呢？Torvalds开发Git用两周，如果开发Git的任务落在自己头上用多久呢？
技术可行性的尺度是一直动态变化的，随着时间的推移，自己技术实力的提升，原来不可行的需求也变得可行。切勿停止扩展精进技术的脚步，适当的也要去挑战困难提升自己。今天一味的拒绝那些自己无法实现的需求，那么明天什么需求可能都轮不到自己头上了。
扩展精进技术的另一个好处就是能够为产品，为自己提供更多选择，有了这种灵活才能够面对市场的变化，使得自己不会被市场淘汰。
结语
“退一步”是给自己留出思考的空间；“退一步”是给自己留出倾听的时间。只有这样，在有争议时才能够理性表达自己的观点，给出有建设性的建议，从而推动团队向好的方向前进。
