月度归档： 2005年12月

　　编了几个月的程序，写了许多烂代码，也管了一堆琐碎的事情，感触比较深。我心目中的合格的程序员应该至少具备以下几点能力吧：
　　一定的英语水平。如果你发现你的同事的代码里净是拼写错误、不符合语法规范和命名规范的变量名甚至是注释，你是通知他修改，还是让它们傻乎乎的留在那里呢？你更不要奢求他去查找并阅读英文甚至其它语言的资料了。如果这个人英语能力比较差，严肃的讲，他对项目通常是没有任何利用价值的。
　　大局观。要经常审视自己和自己的程序在整个项目中所处的地位，与其它模块的联系，要学会与整个项目的架构、进度保持步调一致。这样写出来的程序，才真正是项目中便于维护的部分，而不是一颗定时炸弹。同时，没想过当将军的不是好将军：每个人都是有升职机会的，但没有大局观念，领导就不会首先重视你，这种能力，一般半个月到一个月就可以考察出来了，如果一个人没有全局意识又不乐于考虑代码以外的事情，那么，我们只好安排他继续堆代码，他就永远不会按照自己的意志工作。
　　足够的沟通能力。在开发过程中，程序员经常需要向其它部门请求资源，比如一行文案如何写，一个界面的样式及其交互如何设计，仅凭项目经理去调度是不够的，因为后期精确的调整，还需要程序员与其它部门对应同事点对点的直接交流。沟通能力体现在以下几个方面：一是对一件事物的精确表述，例如描述一个 bug，要说明详细输入和输出数据，以及当时的系统环境；二是倾听，交流之前必须理解别人的话和想做的事，同时也是一种礼节。沟通能力不同于前两点，它是一种软技巧，是与技术无关的，与这个人的综合素养有关，也是技术人员升职加薪最重要考察的一个方面。
　　勇于犯上。这是沟通能力的延伸。有两点前提：一是你的领导技术出身，跟你有共同语言，且能够听取下属的建议，二是你的领导在公司有足够的发言权和调度资源的权力。当你发现你所在部门在工作中遇到了一些显著的瓶颈，例如人手不够，进度制定不符合实际，内部矛盾重重，某些人无法胜任工作等等，就要找合适的机会，用Email、IM、小型封闭会议等方式告知领导，并最好提出一个解决方案，而不是倒苦水。沟通的时候注意方式，例如：我觉得我们项目组欠缺一个人手，想撺掇领导多招几个人，怎么办呢？可以这样说：“随着项目结构的不断复杂和功能的不断增加，原有的人力可能无法维护所有的模块，可能还需要更多的人来帮忙。我们这个项目运用了很多领先的技术，新人来了可以迅速成长，为公司培养人才，如果日后人手富裕了，还可以将他调至其它部门。”也可以这样说：“我们这个项目目前开发状态趋于稳定，但有一些潜在的设计缺陷需要进一步的微调，是否可以考虑增加人手来负责测试和文档维护呢？这样就有机会探索出一套成熟的项目管理方案，供兄弟部门参考。”不过这样说就不聪明啦：“现在这个项目的进度有点紧，老总觉得我们的功能还有很多值得改进的地方，所以我们现在有些忙不过来，我担心今后还会出现同样的情况，您觉得能不能……”虽然这很有可能是实话，但领导显然不会同意：一是担心你把老总的行为夸张化，并用来压他，二是仅通过人手绝对匮乏这一表象会让他无法判断问题是出在人力不够上还是你的管理协调能力上（他当然不会事先怀疑自己的工作方法或是公司的组织结构出现了问题），从而本着宁缺毋滥，宁可涨加班费不多发工资的精神，拒绝你的请求。
　　可能还有其它方面的能力，在这里不一一列举了，随着以后工作的不断深入，还会有更多的感想，也欢迎大家在这里展开热烈的讨论，谢谢。

　　在项目的开发过程中，有很多的业务需求和设计缺陷，包括内部产生的和外部产生的，紧急程度各有不同，并且存在着相互依赖。简单的表格、甘特图不一定能够直观准确的反应上述情况，于是我试着将目前要做的事情画成一张构思图，理顺了一些头绪。
　　我们可以用不同的图标来修饰构思图中的节点，比如问号代表这个需求的必要性或可行性正遭受质疑，感叹号代表这个需求的开发进度比较紧迫，灯泡表示这个需求很有建设性，但正处于规划阶段，且优先级不高，是锦上添花的动作。