软件项目的工作中最容易产生挫败感的往往不是难以攻克的技术点，也不是不让人活的 deadline，而是那反反复复的无用功。为何总是走了很多弯路才跌跌撞撞踏上征途？甚至绕一圈了才发现原点是最好的选择？
首先，我们得有一个前置观念：工作中写代码是商业活动中的一个环节，符合基本的商业规律：降低成本，增加收益。所以 “一切决策以公司利益为大前提” 也算是作为一个软件工程师应有的职业素质。
我们以小团队开发为例，当产品经理（PM）兴奋地跟你说，“用户要是能够看到自己最希望看到的商品就好了”，显然这里的“最希望”是相当不明确的，是 PM 的错吗？当然不是，他为了让产品提供更好的体验以增加公司的收益而想出一个相当不错的 idea，只不过有待深思熟虑。我们作为一个工程师，有责任去 引导 PM 整理思路，让“最希望”从用户体验层面落实到产品功能上，也许 PM 最终想要的是：根据最近购买/浏览产生一个推荐列表。
大致明确了功能点后可不能直接跟 PM 拍胸脯说：“我一周能做好，没啥问题”，这样说对自己和团队都相当不负责任。功能点只是一个方向，后面的路还很长，第一步就得保证自己对代码库有个整体的把握，然后思考加入新功能的复杂度，对于不熟悉的模块不要只看文档甚至凭空猜想，最好能跟这个模块的开发者作简要的沟通。
有了整体把控，然后跟 PM 以及协作开发的同事开会讨论实现细节。当然与会的同事得了解和认同“最希望”这个需求，同时也得对自己的负责系统有整体的了解。接下来就是在 PM 的协调下，各方开发确定功能第一版效果和发布期。然后再讨论一下各个环节的时间节点：文档，测试上线，联调，正式上线，持续监控维护。
各个阶段相辅相成，所谓 “正确方向远比盲目的努力重要”，对产品需求的理解抽象和对现有代码的熟悉度直接决定了正确方向的确立。
