年度概览
经历
01月01日 - 05月13日 协同
05月16日 - 07月15日 艾联科
07月25日 - 至今 优能天擎
能力指数变化
|
领域 |
技能 |
原先 |
当前 |
说明 |
|
流程控制 |
企业文化 |
5 |
25 |
意识到重要性，并重视 |
|
风险迭代 |
50 |
55 |
经验积累 |
|
|
流程分工 |
30 |
40 |
初步实践 |
|
|
节奏控制 |
30 |
50 |
持续实践 |
|
|
产品质量 |
解决方案 |
10 |
30 |
意识到重要性，初步实践 |
|
需求分析 |
25 |
50 |
持续实践 |
|
|
架构设计 |
25 |
50 |
持续实践 |
|
|
代码实现 |
65 |
70 |
CLR框架与应用模板持续重构 |
|
|
知识库版图 |
10 |
30 |
意识到重要性，初步明确 |
工作成绩
PDT调度台界面
基本完成呼叫/短信/遥晕遥毙的基本功能，以及配置/号码簿两大支撑功能。
性价比评定
需要比较其他公司在调度台上投入及效果，需要比较公司之前在同类产品上的投入及效果。没有得到过明确的肯定或否定，自己评价相比之前的作品提升了半个层次。
部分感悟
通过文档降低项目交接困难
在协同的最后一个项目以及在艾联科的项目，都是在项目后期开始接手，前者是用C#重写用C完成了一半的程序，后者是继续开发。接手后因为没有文档或是文档质量低劣杂乱，代码注释极少，异常处理很不严谨，总体上就是一个烂摊子。接手后的过程一般是依据代码反向推理设计和需求，然后写代码重新实现，有时候可能几句话就能写明白的需求规则，可能要“猜”上几天。
把软件比作一个城市，需求相当于区，设计相当于街道，代码相当于建筑，文档就相当于地图，新接收的人相当于外地人；没有地图，外地人就可能迷路或走弯路，本地人也会忘记不常去的地方；能让人越快找到地址并获得路径的地图就是好地图。
通过沟通减少人与人间隔阂
前面两个公司在离职时都和领导做了一次沟通，结果或多或少都消除了之前的一些误会和分歧，而这些误会分歧或多或少能影响我决定是否离职，特别是在协同。我经历过的多个公司，基本都没有可以对项目过程的方方面面畅所欲言和深入交流的氛围，加上自己不够主动，自然会产生一些不必要的误会和分歧。
今后至少在一些大的问题上还是需要尝试通过主动沟通来达成共识和解决问题。
通过共同参与和必要的妥协完成合作
在需求和设计上，直接相关的人员都能参与讨论，这点优能比前面的公司好很多；讨论后难免有分歧，如何面对分歧：首先尊重最后的决策，然后记录分歧便于日后反思总结。
通过携带轻便、操作简洁、界面美观的产品占领市场
年初时巧合之下接触了IPAD，非常震撼：原来电子产品可以做成这样。之后还阅读了一本关于乔布斯创新的书籍，想了解IPAD如何问世的。同时关注了WINDOWS和安卓系统的界面设计上变化。
初步反思后，附带的也有了下面疑问：界面软件怎样能做的更简洁美观？集群通信的在功能上的一些弱项真的不能突破吗？集群手机/交换机/基站不能做的更小更轻吗？公司在产品特征的追求上真的清晰和准确吗？苹果对仅有的几款产品，围绕其核心价值反复的升级，不断追求完美的研发过程是否值得借鉴？
通过控制工作节奏提高效率
基本做到了分时段使用时间，合理安排内容。
下年规划
主要目标
自学界面设计原则，掌握XMAL界面编程语言。
尝试通过明确的测试体系方案和自动化测试工具，达到量化软件质量。
次要目标
尝试使用GIS/GPS接口开发应用
尝试使用Kinect / SAPI接口开发应用
闲聊公司
相比前两家公司，在优能工作的5个多月，总体感受还是不错的，有较多时间去重构优化，我很喜欢这种研发节奏。之前的公司屡犯不改的错是采取封闭突击这种研发方式的时间过长，导致研发人员身心不协调，最终不仅效率低，而且大大降低团队的凝聚力；如果项目通过封闭突击的方式在10天内完不成，那就通过劳逸结合和奖罚分明的方式进行持久战。
初来乍到，对公司的观察基本都是被动的，下面是对公司的一些模糊的表面的直觉，仅供闲聊。
企业文化
产品的愿景不清晰，团队基本和睦但缺少激情，沟通平台和奖惩制度不给力，鼓励创新和进取的意识不强。
指数：3星
迭代风险
有季度和周的工作计划和汇报，但对项目风险因素的认识似乎并不准确，迭代阶段的整体目标和验收标准不清晰。进度和质量控制的严谨性务实性有多少？
指数：？星
分工流程
基本上每一模块安排一个人负责，没有成文的严谨的流程和平台。任务分配时的验收标准不清晰，任务分配时的人员职责交叉较少，任务提交时的审核不清晰。
指数：3星
解决方案
没有受过关于系统整体和局部产品的核心价值的培训，也没有明确讨论过。
指数：？星
需求分析
重视需求，但对需求分析的原则和标准还处于探索阶段。
指数：2.5星
架构设计
重视设计，但面向接口的原则意识不强，设计文档的简洁性/精确性/务实性未知（缺少别人利用文档解决问题的测试标准）。
指数：？星
代码实现
总体上各自为战，缺少对代码质量广泛和深入的讨论；依赖Telnent调试，适用范围存在局限，效率也不高；重视测试，但测试用例不够明确。
指数：？星
改进建议
背景：经理对所有人的总结进行了总结，并征询意见，我的意见如下
1.涉及到的问题如果划分现状、原因、目标、执行方案、执行难度、重要性、紧迫性，可能逻辑上更加清晰，还要突出执行方案的“具体明确”
2.公司和个人都该尝试建立自己的能力指标体系，明确不足和目标，以及奖励，逐步减少“混”的态度，增加“积极主动”的态度，我想进步和创新会源源不断。例如，公司方面明确项目中有变更通知不及时的问题，如果管理者或普通员工通过都认可的方法解决了，这就是明明白白清清楚楚的工作成效；例如，当前嵌入式的调试效率低适用性差，谁用公认的好的方案和工具解决了，谁就该奖。不足和目标可以写在显眼的地方，就像“好好学习天天向上”一样，所有人都能专注。
公司的愿景和产品特性催生出必须的指标体系，所有的改进都该围绕明确的量化的指标体系。
3.警惕“有形无神”的改革，强调“严谨务实”的态度。从无到有，形式上的变化可能比较容易，装一套软件或是制定一个制度，但这不是必然带来质量或效率的提高，反而有可能降低效率；首先要认清问题的本质，然后还要有严谨的方案和务实的衡量标准，最后还要有誓不罢休的改革意志。