虽然一开始推荐是build to win 只是发现，收获的不仅仅是to win。
研究员的想法是：
我要单纯地用我的方法，证明这个方法相对于其他方法的优点。 (然后我就可以发论文了）
我（工程角度）的想法是：
用所有能帮上忙的方法，做出好的结果。（我们就可以出产品了）
的确，往往有时候为了完成而完成项目，“从科学研究的角度来说，研究员的想法是挺严谨的，而且是正确的态度. 他们
认为科研项目就应该是 Build To Learn 的过程。通过严谨的开发和数据收集，展示某个新算法的价值，发表文章，以后别人就可以引用此文章
-- 这个算法在 X 应用中，提高了 Y 的效率。”
不是为了完成而完成项目，是要在项目中learn try learn的循环。
在项目中，我们往往希望能在项目中凸显一些新颖的设计或者可视化的东西，不是说不可取，不能光华而不实，以质量和稳定性为基础，to show。
在平时项目中，一般用户需求分析，定制功能。在这之外，是否就行了昵，当然不是，可以的话，可以添加工具在内。也许用户并不一定会用得上，在人性化的角度上，添加一定的工具包，一方面
可以是一种好习惯，一方面用得上的用户也会满足需求，当然，有个serve还不能无脑，不然那就是累赘了。
build to win:在Build To Show 的场景中，大家各显身手，用各种办法展现技术，的确很难在单一的维度上确定谁赢谁输。但是，在Build To Win 的场景中，往往市场就是那么一块， 竞争对手占了70%， 你就只剩下 30%; 如果对手们占了99%， 你就只剩 1% (例如2014 - 2015年的必应搜索和WP在中国的市场份额)。 这个时候，软件团队不能停留在 Build To Show 的幻想中 --
我想给我感触深的莫过于这句话。是的，技术上，质量上也许并没有问题。但是市场就那么一块，你要面对现实， 你有多少市场份额？ 你要正面冲上去打，用更好的产品去赢。
从一切可能的细节上。