PD15为什么能成功？
PD17为什么能成功？
因为大家愿意加班，流程对，努力方向对。
成功的项目：
A类：稳定的芯片（相当于平台或硬件）
B类：稳定的驱动（相当于不同厂家的软件驱动）
C类：稳定的内核（相当于集成的软件SDK）
D类：成熟的应用 (面向客户层，同一套code也移植到任何平台)
（我们一直在和OCN打交道，一直在做D）,我们的长处是D, 我们的强项也是D。
合作过的芯片厂商：
ST
Broadcom
海思
Mstar
MTK
居然最让人伤心的是MTK。
ST的印象已经很模糊，但印象中也给力。
博通的支持，很积极，很多技术支持耐心的讲解SDK，把博通的讲师录制成视频，反复看3遍以上。遇到bug老是分类…
海思:老从北京派一个人常驻办公室陪你加班，
Mstar：更是每晚有几个人陪你到地铁的最后一班，
MTK：垃圾。
垃圾就是废物的意思，因为有了比较，因为有人帮你挡过石头和子弹，你才能走的很远，而MTK什么都没有帮我挡。
你可以说，那公司出钱少，MTK不愿意多支持我们，也对，但应该像华为，只要说做就花大力气做，要么就不做。老搞半推半就的项目。
为什么说7688项目有问题：
因为D类的人员，在试图解决ABC类的bug，会徒劳无功。
从来没有听说的bug：
One_bug: 模块接上串口就好了，不接串口就有毛病。
Two_bug: 在串口调试中，突然从底层冒充大量的wps的log.
作为一个D类的研发人员：从来没有遇到过以上问题。
没有遇到过并不意味着不存在，其实是C类软件人员已经帮你解决了。
人是一个很容易夜郎自大的动物，觉得自己啥都知道，啥都能干，领导也喜欢啥都能干的人，这恰恰是人生的误区。
当今世界分工愈来愈细，能否自扫门前雪都已经面临很大的压力，是否要别人帮忙扫自己家门口的雪，更没有时间管他人瓦上霜。
我们回想一下：
最近三年成功的项目，到底是不是C类软件人员已经帮你把One_bug 和 Two_bug都收拾掉了。
PD15 和 PD17 自己就搞个很上层的应用：海思和Mstar的人日夜陪你身边帮你搞D类问题。
7688项目：D类的人去调试ABC类的问题，那D类的应用功能谁做？
否则就会出现软件的人越来越懂硬件知识，硬件人越来越软-----一群半桶水。
每个项目都会有问题，到底是硬件问题还是软件问题？
软件问题能使所有的产品模块都出现问题，是设计缺陷，肯定能在每个硬件上重现。
一定要做一个死无牵挂的人：
别----你成功了，让别人却无法复制；
别----你死了，让别人却不得不死。
（大多数人认为钥匙丢了，锁子就没有用了；但你其实可以留下制造钥匙的详细文档）
项目拖的时间越长，参与的人越没有耐心，领导也没有耐心----恶性循环。
今夜在下雪，才知错过了花季，却强要果实，
2015年学到了什么？
2016年准备关注什么？