如何做好开发组长工作

转自Express158

开发组长，在软件开发部门中属于最基层的管理者， 相对于部门经理、项目经理，其位算不了什么，但在参与共事的小组成员中有着其特殊地位。

首先，对上一级，需要通过开发组长或者项目组组长了解整个项目的进度情况以及小组各成员的工作情况，很多时候上一级都会比较忙，而他要了解底下的人员做得怎么样，大多数时候都得靠小组长提供这些信息。另有什么新的任务，也需要通过小组长去具体的分配，因为小组长可能更了解项目组成员的特长及任务的熟悉情况，只有找对了人，完成任务的效率和质量才能得到保证。

其次，对于项目组成员，需要通过开发组长了解项目的总体规划与安排，同时在具体实现的过程中可能会遇到一些困难，同样需要通过开发组长向部门经理或项目经理汇报、寻求解决方法。日常中的意见、建议大多时候也可能通过开发组长向上去传达，因此，开发组长有点像一个中间件，起到很好的衔接作用。

与此同时，开发组长也有自己的工作需要做，但他必须得顾及上述的两点，因此，对于自身参与开发的部分应该是一些接口性质的，类似集成，相对而言，实际工作量不会太多，但需要综观全局、综合起来应用。在技术上，开发组长的知识面、深度都极其重要，只有能普遍的把问题解决，才能在项目组中赢得威信、树立起榜样。业余时间必须得多钻研、多测试，随时都可以为项目组成员解决一些问题。

作为组长，是一名基层管理者，除了技术上要求有过硬的本领之外，必须得学习、领悟、运用一些管理学的知识，在日常工作中，注意留意项目组各成员的工作情况、态度、情绪，这些都必须有所了解，否则将直接影响到整个项目组的工作进度及良好工作氛围的营造。

虽说上有老大，下有手下，但真正做好一个开发组长并不容易，需要在平时多加琢磨、总结、领悟；既要注意提高技术水平，也要留意管理学知识，作好基层的管理工作，处理好项目组成员间的关系；只有这样，才能带领好整个项目组完成一个又一个开发任务。

程序员(英文Programmer)是从事程序开发、维护的专业人员。一般我们将程序员分为程序设计人员和程序编码员，但两者的界限并不非常清楚，特别是在中国。

作一个真正合格的程序员，应该具有的素质。

1：团队精神和协作能力

团队精神和协作能力是作为一个程序员应具备的最基本的素质。软件工程已经提了将近三十年了，当今的软件开发已经不是编程了，而是工程。独行侠可以写一些程序也能赚钱发财，但是进入研发团队，从事商业化和产品化的开发任务，就必须具备这种素质。可以毫不夸张的说这种素质是一个程序员乃至一个团队的安身立命之本。

2：文档习惯

文档是一个软件系统的生命力。一个公司的产品再好、技术含量再高，如果没有缺乏文档，知识就没有继承，公司还是一个来料加工的软件作坊。作为代码程序员，必须将30％的工作时间写用于技术文档。没有文档的程序员势必会被淘汰。

3：规范化的代码编写习惯

知名软件公司的代码的变量命名、注释格式，甚至嵌套中行缩进的长度和函数间的空行数字都有明确规定，良好的编写习惯，不但有助于代码的移植和纠错，也有助于不同技术人员之间的协作。 一些所谓的高手甚至叫嚣高手写的代码一般人看不懂，我只能说他不是一名合格的程序员。

4：需求理解能力

程序员要能正确理解任务单中描述的需求。在这里要明确一点，程序员不仅仅要注意到软件的功能需求，还应注意软件的性能需求，要能正确评估自己的模块对整个项目中的影响及潜在的威胁，如果有着两到三年项目经验的熟练程序员对这一点没有体会的话，只能说明他或许是认真工作过，但是没有用心工作。

5：模块化思维能力

作为一个优秀的程序员，他的思想不能在局限当前的工作任务里面，要想想看自己写的模块是否可以脱离当前系统存在，通过简单的封装在其他系统中或其他模块中直接使用。这样做可以使代码能重复利用，减少重复的劳动，也能是系统结构越趋合理。模块化思维能力的提高是一个程序员的技术水平提高的一项重要指标。

6：测试习惯

测试是软件工程质量保证的重要环节，但是测试不仅仅是测试工程师的工作，而是每个程序员的一种基本职责。程序员要认识测试不仅是正常的程序调试，而要是要进行有目的有针对性的异常调用测试，这一点要结合需求理解能力。

7：学习和总结的能力

程序员是很容易被淘汰的职业，所以要善于学习总结。许多程序员喜欢盲目追求一些编码的小技巧，这样的技术人员无论学了多少语言，代码写起来多熟练，我们只能说他是一名熟练的代码民工，他永远都不会有质的提高。一个善于学习的程序员会经常总结自己的技术水平，对自己的技术层面要有良好的定位，这样才能有目的地提高自己。这样才能逐步提高，从程序员升级为软件设计师、系统分析员。


作为高级程序员，乃至于设计师而言，除了应该具备上述全部素质之外，还需要具备以下素质：

1、 需求分析能力

2、 整体框架能力

3、 流程处理能力

4、 模块分解能力

5、 整体项目评估能力

6、 团队组织管理能力


1，激情。

我曾经遇到许多“职业程序员”，他们从事IT是因为觉得这是一种职业，他们只在工作时间编程，除非送去培训否则他们不会学习新东西，这不是好的程序员。我认为一个好的程序员总是对编程充满激情，而且好的开发者会做一些编程工作即使这没有报酬。激情是一个优秀程序员的重要指标。

2，自学好学

编程领域始终发展变化着，不出一年有些新技术就变成了老技术，这并不是说好的程序员要对所有新技术跟进，但有些却对学习任何新技术都没有兴趣。他们通常在学校学习了编程，然后工作后单位安排学什么就学什么。如果在招聘中你听到“让我培训一个星期我就会胜任这个工作”那不要雇佣他。实际上，真正优秀的程序员始终谈论着你所不知道的新技术，向人们解释为什么你必须用这个技术，哪怕没有听众听得明白，哪怕他自己也不明白。

3，聪明

聪明包括很多因素，情绪和社会交际只是其中之一。好的程序员绝不木讷，他们是最聪明的人，他们中的许多善于交际，健谈、兴趣广泛。

4，隐性的经验

—好的程序员通。常有自己的私人的一些研究、爱好、项目，而这些是他们不写在简历上 (通常觉得不值得写)，但表现出来却可能恰恰是他的潜能、深度和后劲所在。

5，技术多样性

由于好的程序员喜欢学习和涉猎新技术，所以一般来说超过22岁的都熟知很多新技术，而且对多种技术的长短有 “强烈”的个人意见/见解，喜好尝试新鲜技术。

6，资格证书

资格证书并不是识别真正程序员的方法，MCSE、SCJP、说明不了什么，它们只是让别人认识和获取的，顶多代表这个人在某个技术有一定的知识。

原文作者在文末写道：以上所说的标准并不是绝对的，因为有些优秀的程序员确实不符合上述，而有些bad程序员却符合了。但相信这些对大多数真正的程序员都适用。

总结而言，优秀的程序员通常有一下特点：

n 对技术充满激情；

n 将编程作为一种爱好

n 如果你允许会滔滔不绝地跟你谈论技术

n 有过个人的开发经历（与4意思相同）

n 坚持认为某种技术最好

n 如果让他用他认为不好的技术他会非常别扭

n 聪明、健谈、兴趣广泛

n 在大学和工作前就开始接触程序



只有做一个专业的程序员，才有可能有希望。

加油，加油，！！！1

软件研发人员的考核

软件研发人员的考核一直是软件企业管理的难点，笔者在长期的研发管理实践与咨询实践中，总结了进行软件研发人员考核的一些基本原则，整理出来与大家共享：
　　◆Ø要体现公司的价值观

　　公司的价值观体现了公司认可什么类型的人员？要挽留哪些人？提倡做什么？对这些人员的认可可以通过具体的考核办法落实下来。比如企业鼓励在某一个业务领域内积累丰富的领域经验，鼓励在某个技术方向上进行深入钻研等，对于提倡的这些行为，要有具体的奖励措施。所以在定义考核办法时，需要首先考虑清楚要体现企业的哪些价值观。

　　◆Ø要体现多劳多得，质与量并重

　　不能让那些完成了大量艰苦工作的人员吃亏，否则就会打击真正努力工作的人员的积极性。多劳多得原则的实现，基于对工作量的计算。规范的管理都是以人为本、以过程为核心、以度量为基础的。要做到多劳多得就需要做好对工作量的度量，如果仅仅注重工作量而不关注工作质量，显然是不对的，而对于质量的考核，可以通过多个渠道来获得数据，如发现的缺陷个数、客户的反馈等等。当然多劳多得的前提是团队的目标达成了，如果目标未完成，多劳未必多得。

　　◆Ø要鼓励创新与规范管理

　　管理与创新是软件企业发展的2个轮子，通过规范管理可以确保企业的常规发展，通过创新实现企业的跳跃式发展，管理为创新提供了转化为生产力的基础，创新可以快速地提高企业的竞争能力，因此在考核办法中要体现出来对这2者的认可。有的企业设立了创新基金，专门用来奖励那些技术创新、管理创新等，有的企业在研发人员的考核指标中加入了对过程改进工作的支持等指标。

　　◆Ø要鼓励技术复用

　　成功的软件企业必须在人员、技术、过程三个方面加大投入。软件复用是目前软件公司提高软件生产率的最有效的手段之一，为了在企业内建立组织级的技术复用体系，首先就要鼓励大家主动去提取可复用的各种构件，主动贡献可复用的构件。对于这种提取可复用构件的行为，应根据其可能带来的收益，适当给予奖励。

　　◆Ø要因时而变，但要尽可能保持连续性

　　考核办法的制定都有一定的针对性，具有一定时限性，随着公司内外部环境的变化，随着公司文化的逐步稳定，对考核办法要逐步调整，在改变考核办法时，要注意保持考核办法的连续性，不要变化太大，否则就会让被考核人无所适从，产生观望的心态，或者在研究考核办法上花费很多时间，造成不必要的生产效率的下降。

　　◆Ø要量化与非量化结合

　　如果没有量化的考核指标，全靠非量化的指标，对于开发人员来讲，很难体现多劳多得的原则，很容易走向吃大锅饭的模式，无法调动开发人员的积极性。如果全量化也很难，在开发过程中，有很多工作难以量化，比如需求开发的工作，就很难定量的计算工作量。因此在考核时，在尽可能量化的基础上，也允许有一些非量化的指标的存在。至于2者的比重，可以根据当前企业的管理水平来确定。对于管理比较规范的企业，成熟度比较高的企业，可以采用量化的指标多一些，量化的比重大一些。

要区分不同的岗位，不能一刀切

　　对于项目经理、需求分析人员、设计人员、程序员、测试人员、质量管理人员等，工作性质、能力要求、绩效表现的特征都有比较大的差别，因此要区别对待。这样便于体现考核办法的内部公平性与外部公平性。比如对于质量管理人员，大部分是日常的事务性的工作，其工作业绩的体现是长期的，他们的工作重心是预防缺陷的产生，采用量化的数据就比较困难，可以考虑采用改进率等指标来考核，而程序员的主要工作是实现设计，任务的规模与他们的工作效率、质量是可以量化的，这2种类型的考核办法就应该是不同的。

　　◆Ø要保证被考核人的及时知情权

事先要将考核办法告知被考核人，考核结果要及时通知被考核人。考核的目的是为了发现改进工作业绩的方法，激励员工更加努力地工作，考核办法也代表了公司的价值观，因此要让被考核人对考核办法很清楚，让他们知道什么是应该努力去做好的，这样才能起到激励作用。考核的结果应及时通知被考核人，这样能够给他们一个及时的肯定或者否定的刺激信号。

　　◆Ø不以被考核人自己提供的数据为考核依据

　　如果以被考核人自己提供的数据作为考核依据，则会造成数据的失真。在软件企业中推行开发人员的个人日志时，遇到的最大的问题就是日志的失真问题，为什么呢？因为开发人员担心自己填写的日志会成为自己的考核依据，会成为评价自己的工作努力程度的依据，因此本能地会倾向于满负荷地填写自己的工作量。

　　◆Ø考核指标要和被考核人直接相关，被考核人对考核指标的达成能发挥重要的作用

　　在很多软件公司中，经常发现员工的考核与公司的利润、部门的利润或者项目的利润挂钩，对于销售部门、事业部或者其他直接与市场相关部门，这种考核是有激励作用的，对于研发人员来讲，这种办法的激励作用就不那么明显了。利润的形成有多方面的原因，可能大部分原因不是开发人员所能决定的，将不由开发人员所决定的因素与其考核挂钩，是不合理的，即使开发人员再努力，也不能对利润的形成起到实质性的帮助作用，为什么要和利润挂钩呢？

　古人云：知易行难。道理很简单，落实时却涉及了企业的方方面面，有历史的原因，有现实的问题，有未来的不确定性，但是这些都不应该成为逃避考核问题的理由，必须去尝试，才有可能解决这个问题！

研发经理日记

ENP 1.0发布一个月了，还是无法推向客户。

我十分失望。

作为结果来说，4个月前我所设想的利用放权、流程和引入专业用户界面来达到低成本开发用户满意的设想是失败了。

方蕾已经非常努力了。我真的很难以责怪她。她的人脉，敬业，在处理一些其他问题上的创造性，是使我觉得可以一试的底气。但就如武林高手对决一样，无论事先如何能如何策划周密，动起手来还是要靠武功决定胜负。她毕竟在对软件产品和技术本身的把握上还是难以达到一流高手的境界。

我也无法责怪柳平。带着几个报酬和工作经验一样少的研究生，管系统构架，管数据库设计，管代码整合，管技术难点……可是，当我打开源代码的时候，还是几乎大光其火。90％的代码没有任何结构，数据库查询语句和其他代码混合在一起，业务逻辑处理代码和页面显示代码纠缠不清。我这写了十几年代码的老程序员，花了一天没看懂一个程序文件！

上海的用户界面设计师呢？我能怪他们吗？他们反应迅速，设计的模拟软件在外观上也中规中距。可是，还是很难用啊！很多东西根本就是牛唇不对马嘴。

还有测试组，他们有没有脑子啊？

算了算了，还是我的问题。我在组建好队伍，定义了高层需求后，基本上就放手不管了。这显然给我一个重大教训。

教训一：任何下属，无论多么敬业和具有其他优良素质，如果专业技能和本身能力尚未达到承担某一任务时，即使有良好的流程，也不能通过简单放权来企图达到一劳永逸的结果。建立周期性的反馈是毕不可少的。这也是上司的责任，通过反馈来培训下属。

行动指南：建立针对项目的周期性一对一会议。

明天早上我就去设立一个与方蕾和柳平10分钟的周会，定在周二吧。

杨疾的人和个性一样独特。他是我最近招到ENP小组的高级程序员，不过他以前从来没有开发过Web程序，因此他每天都学习到晚上十点；他上周末回老家了一趟，居然把右手弄骨折了，因此输入程序只能单手。他说是练拳练的，“医生说以后再也不能练拳了。”，他跑到我办公室向我提出ENP中的设计问题的时候，很有点惋惜的说。我很怀疑他和人打架，可也不好说什么。

“我觉得我到了这个公司就像手脚被捆住一样，你知道，我从深圳回来损失的不是一点点”，他的话很有点刺痛我。如果我的团队不能让新人觉得有益，他们就会离开。他提了一大堆关于设计，产品和代码的问题，也让我觉得他确实很有洞察力。我和他谈了一个小时，让他觉得舒服了一点。可是危机感越来越重的围绕来我的脑中，我的头又开始痛了。昨天忘了吃脑心通，今天似乎大脑就有点堵塞。我得做点什么。

6/1/04

早上起来，天气非常好。我跨上笔记本电脑包，下楼，出小区，心情非常好。六月天，空气渐渐变热，伴随路边花树绽放，蜂蝇倏忽，心情陡然好转。我决定走路上班，不就二十分钟嘛！笑。

走了一半路，右边电脑包沉重，举手把它甩到左肩。突然，一个想法过电在大脑里。干吗周会？开日会不更好吗？记得极限编程的一个实践就是每日晨会。以前对EVP项目是太抽象管理了，现在每天十分钟，迅速Ping一下，可以了解项目，也可以观测每个人的能力品行。实际上，重组换人的决心在我心中已经定了。

早上到了公司，还是得处理完全部的邮件，结束时，已经十点半。赶紧回顾了一下极限编程的知识，觉得有底了，召集所有EVP成员开会。

方蕾、柳平、陈丫丫和大部分人都到了。我看到杨疾剃着平头，斜靠在一张椅子上，面沉似水。

我先叙述了一下当前的问题，我讲的很小心，避免讲出“你们实在做的太烂”的话来。但每个人还是感到了我不满。我嗅到空气中略有些紧张气氛的时候，话题转向今后要做什么。下属也许是这样，如果听到上司对日后的事情还有具体安排，大概会觉得事情还能过得去。我现在还得需要他们齐心协力。

对诸如极限编程这些软件实践，我向来抱着拿来主义的态度。我特别不喜欢应用的时候，先冠个名，然后再推行。就好像扯块布当大旗似的。所以我讲的内容讲完了，一个字没提极限编程，只是告诉大家：

每天早上八点四十五，所有的开发，测试都到EVP开发工作区，开十分钟的站立晨会。

方蕾还是负责项目管理，产品特性管理并和上海产品设计中心确定所有的UI，每个UI要经过我的确认。

会开完了，我嘘了口气。我看到杨疾还是面沉似水，一只手裹着绷带，回到座位去了。

这天晚上，我回到家，继续处理不停传来了信件。我想起一句话，这家经理没有下班和周末，他们的周末只不过是每隔五天有了可以休息的机会。

“Buzz”，我的IM叫唤了。是杨疾。

以下是我们IM对话：

杨疾: 我想和你谈谈

我： 好啊

杨疾: 但是要找一个相投的人,否则,对牛弹琴

我: 我喜欢和有想法的人沟通

我: 有人能合理地挑战我,我最喜欢

我: :)

杨疾: 其实我只是想,在没有人打扰的情况下,我们就你现在的目标,讨论一些实际可以操作的方案,这是我的想法

杨疾: 其实,我曾经做过你的位置,想到一些和你一样的问题

杨疾: 但是有些想法老板不支持

杨疾: 很正常

杨疾: 因为,他们要求的就是短时间出产品,怎么出他们不管,

我: 到目前为止,老板都很支持我.

我: 他想要的是我给他建设一支上千人的企业

杨疾: 你约个时间,我们好好聊聊,我请你吃饭如何

杨疾: 我确实想好好发展

杨疾: 我现在把你当成我的好朋友

杨疾: 我告诉你,我在这儿的目标是什么

我: 好啊,你说

杨疾: 从公司角度来说,我要求能够充分展示我能力的环境和场所

杨疾: 并且能在我和大家的努力下,不断变好,我会有成就感

杨疾: 从个人角度来说,经常和一些水平高的人下棋,结果是自己的水平不断的提高

杨疾: 我的能力的提高,使我梦寐以求

我: 其实公司还有很多人很有水平,你可以都看看

杨疾: 我知道,我上次开公司的失败,告诉我我的能力还是不够的

杨疾: 我早听说了

杨疾: 一直无缘套近

杨疾: 是我的失败

杨疾: 你所说的一切和人好像都是技术上的,

杨疾: 有没有管理方面的呢

杨疾: 其实,我不知道你有没有感觉,一个队伍是不是有战斗力,主要看管理

我: 你想,作这些东西,带这么多人,没有管理行吗?

我: 他们每个人都具有很强的管理能力

杨疾: 你看我们公司现在的队伍有了这么多的好手,

杨疾: 我觉得应该会有一个大的发展

我: 我们和Microsoft一样,需要的是技术和管理都精通的人

我: 我充满信心

杨疾: 我知道你的意思,但是那你为什么这么操心呢,

我: 因为他们包括我还不是世界一流

杨疾: 这其实就是说明,我们公司还有需要改进的地方,特别是管理

杨疾: 我知道了

杨疾: 我本人也想趁上这艘大船,到达彼岸

我: 我们也有打输的可能噢

杨疾: 扯远了,

杨疾: 不要这么想

杨疾: 谁都害怕失败

杨疾: 就拿我到公司的时候,

杨疾: 我担心的不是转不了正,而是怎么样才能提前转正的问题

杨疾: 我不怕失败,我在深圳的公司,先天夭折,我也只能接受,再去努力,

说实在的，我第一次碰到这么直接的人，不过，我喜欢。：）

EVP项目的本质是工程师的野心。张总让我启动这个项目的时候多半刚看过比尔.盖茨的《未来之路》。

“我们应该建立公司的数字化神经网，你可以读一读《未来之路》”，张总是集团技术副总裁，也是公司的奠基人之一。张总从公司一创建就就追随董事长，在技术口算是一杆大旗。学生时代的张总号称神童，至今保持着技术人员本色，经常会写一些程序处理日常事务。

“象你们研发中心，到底现在有多少项目，谁在做，做得这么样？现在，”张总笑笑，“我们都很难直接搞清楚”。

我背上一阵紧张，“我每周送到总裁办的周报应该列出了……”，张总不等我说完，“我没有批评任何人的意思。我只是在说问题。建立ENP的目的就在建立整个企业神经网络平台，每个神经末梢的变动都可以让大脑感知到。”

“张总，你知道的，做企业内部系统是最难做的事情。”我说，“为什么我们不去买一套呢？RUP，或者其他产品。”

“呃，”张总发出他惯有的声音，我知道这是他思考和准备说服人的前奏。“商业软件总是不那么灵活，而且实施也很麻烦。再说，现在是Web时代了。”张总看着我，“如果ENP做的好，可能就进入公司产品线了。你想，这会是件很妙的事情，技术口的想法，能被市场部接受”，张总笑了几声，有点干。

“好吧，能不能再给我几个编制？”我终于把憋着的话说出来。张总的声音变得缥缈，“你看，人的问题总是这样的，你做一点，然后我们一起审查一下，如果结果是好的，那我就再给你加几个。我们过去不都是这样吗？”

看到我有点沮丧，张总最后一句话变成“你现在还可以这样做嘛。”

我花了几天天的时间，终于写完了EVP重构的指导性技术文件。想来也是受杨疾的影响。这些天，他经常到我办公室来，和我谈EVP系统构架的问题。但是，有时他的思路经常会飘到开发一个全新产品上去。有时我对他的发散思维稍稍鼓励，他就恨不得马上就去实现。我很担心他会偏离了方向。也许是这种压力吧，我写完了这篇文件。（只保留文件结构框架）

EVP重构

日期
作者
贡献者
注释

6/6/2004
Cunruizhai
杨疾
初始文档

6/10/2004
Cunruizhai
张总
增加SLA

1. 介绍

本文档描述了如何重构ENP系统结构。

1.1. 需要解决的问题

1.2. 效率低下

1.3. 源代码可读性差

1.4. 源代码难于维护

2. 系统构架设计

2.1. 四层结构

2.1.1. 表现层

2.1.2. 业务逻辑层

2.1.3. 数据对象层

2.1.4. 数据访问层

3. 系统构架实现

3.1. 一般实现过程

3.1.1. 入口点

3.1.2. UI表现和数据更新

3.2. 例子

4. 系统设计

4.1. 全局对象

4.2. 安全性

4.3. 那些模块需要重构

4.4. 目录结构

4.5. 文件命名规则

5. 代码风格

5.1. 一般代码规则

5.1.1. 缩进和行长度

5.1.2. 控制结构

5.1.3. 函数调用

5.1.4. 函数定义

5.1.5. 注释

5.1.6. 包含文件

5.1.7. 文件头注释

5.1.8. 变量命名规则

5.1.8.1. 类

5.1.8.2. 函数和方法

5.1.8.3. 常量

5.1.8.4. 变量

5.1.8.5. 全局量

5.2. ENP专门代码规范

5.2.1. 类

5.2.2. 变量

5.2.3. Cookie/Session

5.2.4. 其他风格

6. 白盒测试

7. 任务安排

8. 流程变化

文件写完了，就该宣灌了。我召集了方蕾、柳平、陈丫丫和所有的开发员测试员，一段一段的讲了一遍。我特别强调了白盒测试：“所有测试员要抽检开发员的代码，不符合代码规范的就报告一个20级的Bug！”

“另外，我也想谢谢杨疾，他给了我很多建议，也给了我压力和动力来写完这些东西”，我看了看柳平和杨疾，似乎看不出什么反应。

高效团队之最佳实践

1. 迭代开发
2. 优秀框架
3. Bug和需求管理
4. 源代码管理
5. 高效沟通
6. 周计划/总结会议制度
7. 使用任务列表进行项目管理

我觉得核心的问题是：
你觉得什么流程和措施才能使得你自己觉得这个项目是可控的？

这个随着开发人员组合、公司的管理制度和文化、项目的要求不同而不同，但是总有一些基本的原则在指导，譬如上面诸位所说的沟通、检查、最佳实践等等。

老实说，做了这么多年系统和程序，对这个问题我也是非常迷茫的，最近带了一批新大学生来做系统，结果只能用惨不忍睹来形容了。

唉，反思，反思、再反思！！！

个人觉得，项目管理最重要的是人的管理。从这篇日记来看，这位研发经理对人的管理还需要进行改善。在项目进行中，最主要的是能调动所有项目组成员的积极性，尤其是项目管理者。要对项目的发展持有乐观的态度。如果项目最终失败，我觉得最后主要的原因肯定是项目管理者的问题，毕竟其他实施人员只是按照管理者的意愿进行操作和实现的。
不过杨疾这名员工我觉得可以好好的利用一下！一方面也是投其所好，会让他工作时更积极！给他提供一个好的机会。他会为实现自己的目标更卖力。其他的人员，我觉得应该也要好好的进行交流！其实项目时间紧并不能成为不做任何事的理由！

定出一个具体到编码细节（类、接口）的开发文档，是不是可以保证项目的进度？
但我觉得这种文档要花很长的时间去完成，最后反而编码的时间不够了。
如果文档不细致，项目经理又要花很多的时间与程序员沟通，而程序员最后的理解可能会有些偏差，加上没有全局架构的意识，虽然功能实现了，但编写的代码与项目经理的计划相去甚远，这样长久累积起来，当需求有变动的时候，重构就成了大麻烦。

代码风格这种东西现在才提？在招人的时候从笔试写的代码里就应该看出来。如果实在工钱低找不到好的人才，那就进来后专门培训2个礼拜。

另外每次co<wbr>de check in 的时候你经常去做一下co<wbr>de review不是更好？没时间的话让下面那些有经验的leader去review一下也行，不要说你手下没一个能拿得上台面。</wbr></wbr>

研发心得

1.不管给别人打工还是自己干，都要全身全意的工作，因为你所做的任何一点工作都会让自己的人生多一点筹码。

2.多与市场人员交朋友。可能觉得他们知识比你少，比你有点黄，但实际上他们比你懂这个社会，参加到他们的圈中去。你会通过他们接触到另外一个世界。

3. 机会远比钱重要。如果有机会参与除本职工作以外的一些项目或产品的研发中（包括有人拉你做一点小生意之类的事），那怕是帮忙的性质，也要积极介入。至少你会交到很多朋友，这样你的人生会多出很多机会。

4.老板参与项目管理未必都是坏事，也不一定是不信任，要与老板一起学习，要积极面对，猜测别人的想法是沟通的障碍

5.项目经理要尽量争取组员的利益，即使他要离开也不能压其工资，要有自己的“格”。方正为格，如果一个人全是圆的，一点方法都没有，适合作幕僚。

6.要吸取老板失败的教训，他的投资是你学习教训的最合适的机会。

7.分配任务,当偏移出现时,要做时间日志,以备后用,得出实际上团队只用了五分之五十的工作用来进行实际的编程和调试,其余时间包括机器的宕机时间,高优先级的无关琐碎工作,会议,文字工作,公司业务,疾病,事假等

如何在研发项目中提高RDC的研发能力

ISMP项目的感受

在谈这个话题的时候，我先需要说说对目前ISMP项目的感受。ISMP项目，是我所参加过最为“大型”的项目，整个项目组超过50人，这个在我以前是从来没有遇到过的。之所以加引号，是因为类似的项目，如果放在我原来的公司进行进行研发，我想项目组人员不会超过10个人（所以不是真正的大型项目），象 ISMAP Server，目前ISMP项目组有7、8个人，要做至少三个月，如果是以前我的公司，工作量也就是一个人做两个月。

为什么同一个项目，所需要开发资源有这么大的差异呢？并不是说我原来公司人员水平比现在的公司高，而是我们RDC没有任何积累，我们没有通信系统软件的编程框架、没有专门的计费系统、没有PORTAL框架、没有工作流，但所有这些，在我原来的公司，全部都具备，因此需要做的开发工作量少很多。没有积累，意味着需要耗费更多的资源，意味着时间和成本的提升。

以ISMP为例，如果公司要同时实施五个省的ISMP系统，意味着我们研发中心面临着五个省的项目和客户，尽管中国电信定义了许多标准和规范，但是落实到各个省的实际项目中，实际客户的需求都不尽相同，比如计费的需求，比如PORTAL，比如报表，诸如此类，再加上中国电信ISMAP规范的升级，同时项目实施的周期也很长，一般要持续0.5-2年才能完成从项目实施到终验，对人员资源占用很大。

因此，如果研发中心定位在一个Service Offered Center，那么如何提高研发的效率，降低研发成本，是一件非常重要的事情，因为研发中心面向的项目会非常多，来自客户需求会非常多，面向中国这样一个客户需要快速响应的市场，如果不能建立一套优良的软件程序框架，未来面向实际的商用项目，我们很难担负起更多重任。

软件的复用

在我原来的公司，有个笑话，说有N个开发人员，在开发过程中需要使用一个list类（那个时候没有STL），都觉得别人写的类不好，结果就是各自开发了N 个列表list类，结果十个都有BUG。其实每个开发人员都自己从头开始开发软件，效率和质量都是很低的，但是如果N个开发人员，都去使用并且共同完善这个list类，情况会如何呢？哪怕这个类一开始是很糟糕的，但是通过不断的应用，这个list类一定会得到完善和改进的。（这其实也类似现在Open Source的理念，用的人多了，不完善也会变得完善）

list类是公用代码的例子，再举个公用模块的例子，今后很多项目都会应用到短信发送和接收功能，因此我们需要实现各种短消息协议比如SMPP、 SMGP、CMPP等等，目前ISMP的项目开发出了SMPP Control和SMGP Control，但是在下一个其他项目，如果需要应用到这些SMS协议，目前的这些Control是否能够使用？还是需要重新开发？如果要重新开发，其实还是和前面举的的那个列表类一样，就是没有积累，未来开发人员就需要为不同的项目，维护N个不同的SMS Control类。

很多软件开发的书籍都强调代码复用，我认为，这个思想，不仅仅是对个人软件编程的要求，而且是对RDC的开发理念的要求。有公用的模块，才有积累，有积累，才有效率和质量，我认为这是一个Solution Development Center很重要的能力。

公用软件体系框架

RDC的研发能力，我个人认为包括两部分，一部分是人员的研发能力，另一部分是RDC的公用模块和公用软件体系框架。人员的研发能力是通过项目和培训不断提高的，和个人水平和进取心也有关系，这里不详谈。公用模块的好处上面我也谈过了，我主要谈谈公用软件体系框架。

以通信软件框架为例，目前我们应用ACE构建了ISMAP Server，这是一个好的开始，但是我们还需要做的更好，下次做SAG的时候，ISMAP Server是否留下了一个可复用的体系框架？我这里指复用，不是简单的COPY代码，而是要在ACE上通过不断实践，构建一个良好的通信软件框架（选择合适的Thread Mode，选择合适的TCP Server和TCP Client设计结构，实现高性能的分布式架构），这个框架是可以通过项目不断提升和完善，使得开发人员无需关心通信软件的通信控制部分，而更加专注于软件的业务逻辑处理。有了这样框架，在开发通信软件的时候，才能够更好的提升软件开发的效率和质量，做到事半功倍。

类似的软件体系框架还包括数据库统一接口（不需要每次都让开发人员去熟悉OCI的开发接口）、计费系统（如何应用EMM到中国市场？还是自己开发一个 ISMP计费系统？）、报表模块（运营商最关心的功能之一）、Workflow模块（我知道BEA的Portal很贵，实际项目是否采用BEA的产品，值得考虑）等等。

我举的例子，并不是说我们研发中心都要做，有些可以应用公司已有的产品，有些可以应用第三方的软件，但是我们需要深入考虑有那些软件框架是研发中心未来几年中要使用到的，并且是需要自己开发的软件框架。

行进中开火，过程中沉淀

我们研发中心成立的时间很短，面临的项目任务很多，实际上是没有任何时间来专门开发我上面所说的软件体系框架和公用模块的，但是，借助于项目过程来开发这些体系框架和公用模块，是完全有可能的，而一个体系框架，也不是凭空想象出来的，而是在项目的实际开发应用中产生和完善。

这里用一句话小结：

行进中开火，过程中沉淀。

对软件研发人员考核的几点思考

可以将员工考核分三个方面考虑：一、考核标准；二、考核的方式方法；三、激励和改进。
考核标准从三个方面考虑：一、企业核心价值观的认同情况；二、岗位目标的达成情况；三、对岗位的胜任能力。这三方面隐含了这样几个事实：企业的核心价值观应该有一个可执行层面的描述；企业有一套完整的岗位体系，岗位描述清晰；企业管理以目标为导向，目标层层分解，逐一落实到可执行的层面。
考核的方式方法是要求企业有一个稳定、规范的考核步骤和流程。其中最重要的是“谁考核谁”的问题。现在很多企业搞360度的考核，也就是你的上级、下级、同级，以及凡是和你的工作有关联的相关部门，都以不同权重参与对你的考核。
激励和改进的问题，说白了就是怎样把考核结果跟股权、晋升、加薪、奖金、评优、转岗、裁员挂钩的问题。

接下来想澄清几个问题：
一、考核和多劳多得的问题。在企业没有建立目标导向的管理体制之前，多劳多得是合情合理的。但是在一个以目标为导向的企业里，考核标准应该重点考虑目标的达成情况。在这种情况下，多劳未必多得。
二、研发人员考核量化的问题。现在软件工程并没有解决估算和度量的问题。说估算和度量多么准确，听起来就跟电视上的减肥广告差不多。当然，以这种意义上的估算和度量来评价整个项目或研发组织，还是有一定参考价值的。若用来考核个体研发人员的工作，我认为还不成熟。
三、对不成熟的考核标准要放弃。有些企业的领导基于这样的观点：现在的方案的确有问题，但是目前也提不出更好的方案了，那就按照现有的方案执行吧。可以肯定，这样的方案过不了多久就要寿终正寝。这种思考问题的逻辑表面是合情合理的，仔细想想，其实是“流氓逻辑”。社会上很多不合理的制度就是这样产生的。对于不成熟的考核标准，我认为要搁置，否则不得民心。

东拉西扯几个问题：
据我看到的一份资料，联想对薪酬的考虑是：外部因素占70%，主要是与竞争对手比；内部因素占30%，主要考虑成本等因素。这个比例合适与否姑且不论，这里面透露了一个很重要的信息：在内部折腾得再热闹，抵不住竞争对手一忽悠。在业界保持一个有竞争力的薪酬体系非常重要。
薪酬通常包括工资、奖金和福利三部分。其中工资是一个基础指标，福利中最重要的三险一金即是以工资为基数。其实算奖金也大可不必另起炉灶。很多企业是将个人奖金按照月工资的百分比下发的。比如，张三是1.2，表示张三的奖金是他月工资的1.2倍。这里面基于这样一个事实：基本工资是企业对员工价值的评价，并且是劳资双方认可的约定。如果工资结构不合理，要调整工资，不能靠奖金平衡。以工资为基数计算奖金，体现了企业对员工评价上的一致，一定程度上避免了奖金分配上的混乱。
考核是企业对员工制定的游戏规则。这个跟分赃不一样。员工必要的时候可以用脚表达意见，但是不要反客为主。

研发管理的困难

做管理很难，难就难在每个人都有自己的感情，不可能理想化的做到资源的最合理分配。研发管理更难，从自己的感觉，技术人员性格要强的比例远比其他职业要多。怎么管理？

项目管理和行政管理在目前的情况下是不可能截然分开的，如此更加增大了管理的复杂度。研发人员普遍的态度是首先要服你，或者技术水平上对他们能够起到一定引导作用，或者具有绝对的利益分配权。然后才有可能进一步的服从工作上的分配。我不否认，这种状况反映出了管理的低效，但是应该很多研发部门经理都遇到过这种情况吧

确实不一定要在技术上让技术人员服你，其实作为研发管理，如果一直把自己定义在研发的位置上是很悲哀的事情。作为一个项目组或者部门的经理，最大的职责是保证项目能够按照计划保质保量的晚上，反而有些事情要故意放手。项目经理不可避免地要参与项目的设计，但是是否要独自一人完成，如何调动项目组人员的积极性。如果做不到，那么哪怕自己累死工作上仍然是失职。
作技术管理忌讳技术上不懂装懂，不需要太关注细节，但是一定要让项目处于自己了解和可控。更忌讳凡事插手太深，须知三人行必有我师，自己能做到的事情必定有限。
我所讲的关键是，技术人员很少有特别虚心承认自己水平不足的。大家有体会刚做代码时看到别人代码时候的不屑，是不是常常讲，推倒自己写一个？这个思想要不得，但是却客观存在？
一个研发经理不懂技术？不参与到技术如何能够服众？如何保证你所知所了解的是真相？

让研发团队找准市场需求

郭富才

建立一个虚拟的团队，定义合理的流程，寻找真正的客户需求。

“我们公司没有市场营销部门，只有销售部门，销售人员只管销售目标的完成，客户反映的信息不能传递到研发部门。研发部门主动到销售人员那里了解市场信息时，他们往往说‘我只管销售，你先把产品拿出来再说’。”

“从销售部门那里得到的市场信息不系统、不详细，对研发部门来说只能起参考作用，但真正的客户需求我们也不知道，只能闭门造车。”

“现有产品在市场上出问题了，公司才去组织跨部门团队主动收集市场信息，所以我们开发人员处处去救火，成了救火队员了。”

“我们公司没有建立清晰的信息传递流程和模板，也没有建立由市场和开发人员组成的跨部门团队负责市场信息收集，文件、会议、电话、邮件各种方式都有，很凌乱，信息传递很不顺畅。”

“公司没有客户需求收集工具来指导工作，所以收集的客户需求信息不系统、不全面,客户的真正需求不能发掘出来，研发团队得到部分市场需求就开始开发产品，开发过程中老是需求变更。”

相信你对这些话应该不陌生，市场营销部门如何与产品研发部门协调合作是困扰很多企业的问题。其根源是没有建立一个横跨市场和研发部门的团队负责收集市场需求，并将其传递给产品开发团队，其次是没有建立一套跨部门的端到端的业务流程来指导市场需求收集与传递工作，三是没有一个客户需求分析工具来指导系统性地收集客户需求。

建立跨部门的虚拟业务团队

企业中一般有两种性质的团队在同时运作：一种是职能性质的部门，它们相对于业务团队（如产品开发团队、组合管理团队等）而言是一种服务性质的团队。此外，还有另一种性质的团队，就是跨部门的、虚拟的业务团队。

产品开发不仅是研发部门的事情（但我们发现许多人甚至企业领导都认为，产品开发就是研发部门的事情，把市场表现不成功的责任都推给研发部门），而是整个公司的事情。公司的高层领导要在关键时刻决策，市场人员要组织广告宣传、提供市场和客户需求，生产人员要对新产品进行生产策略制定和试产，销售人员要建立销售渠道，财务人员要进行收益分析等等。

为了便于职能部门之间产品开发信息的传递，就需要建立跨职能部门的虚拟团队。这种虚拟团队得到职能部门支持和服务，他们关注的是产品在市场上表现得成功与否，如产品的累积收益、市场占有率等指标，这些正是一个企业要真正关注的目标。

为了产品概念的正确定义，组建的业务团队为PMT（组合管理团队）和PDT（产品开发团队）。PMT 团队一般由市场营销、销售、技术、财务、情报和质量人员等共同组成，PDT 团队一般由市场营销、销售、技术、财务、质量、生产和技术支持人员等共同组成。PMT执行市场管理流程，在产品开发过程中其职责就是收集市场信息、研究市场、关注客户需求，并把这些信息传递给产品开发团队（PDT）；产品开发团队也会在产品开发流程的第一阶段（概念阶段）进行主动的市场需求收集活动。组合管理团队(PMT)、产品开发团队(PDT)与其他产品开发业务团队的场景如图1所示：

公司级投资评审委员会，负责公司级的投资决策和产品平台规划。

产品线集成组合管理团队，负责产品线的产品路标规划和产品投资决策。

公司集成技术管理团队，负责公司的技术规划与技术开发决策。

产品线组合管理团队，负责对市场进行分析，提交产品线业务计划、细分市场需求等。

产品线产品开发团队，负责产品线产品实现。

技术开发团队，负责公司技术开发。

PMT 团队在产品规划任务下达后开始组建，职责是“了解市场、细分市场、组合分析选择目标细分市场、制定业务计划”等市场管理活动，在这个过程中进行市场需求收集，并提交“细分市场客户需求分析报告”，在报告中要对细分市场客户需求进行描述，对客户需求要素的优先级进行排序，并回答“客户为什么会购买我们的产品”以及“客户为什么不购买我们的产品”、“客户对竞争对手的产品是如何评价”等问题，PMT 把这份细分市场客户需求分析报告在市场管理流程结束时传递给产品开发团队（PDT），作为PDT 团队开发产品包的依据之一。

PDT 是产品开发流程执行的主体，在概念阶段组建，也是一个跨职能部门的团队，PDT在概念阶段进行信息收集，并融合其他方式（展览会、客户满意度调查、高层拜访、包括上面所谈到的PMT传递的市场需求）收集的产品包需求，编制“产品包需求说明书”，经过评审后作为产品包开发的依据。

过程定义是关键

在企业运作中，仅建立组织，如果没有相应的流程或者制度来指导运作，往往会导致团队工作没有方向，工作思路不统一，内部冲突不断。在与西方企业咨询顾问的交流过程中，经常会听到他们对中国企业管理现状的评价，其中有一个论点是“中国企业的员工，就单个人来说都是很聪明的，思路也比较清晰，但就整个团体来说，由于他们思路不统一，工作方向不一样，就像分子的布朗运动，整个团队合作时，会存在能量抵消的现象，甚至合力为零，中国企业更应该重视流程建设，把大家的智慧统一起来。”一个了解中国历史的咨询顾问这样说, “中国不缺少哲学家，不缺少思想家，缺少的是将这些智慧思想转化为具体的‘过程定义’来指导企业日常运作！”他所说的“过程定义”就是指企业中的流程、制度、规范、作业指导书建设工作。

目前产品开发最佳的管理流程是端到端流程。这是区别于职能式的产品开发模式，建立的产品开发流程是跨部门的、关注业务实现的、客户到客户的业务流程。企业中与产品需求相关的主要有三大流程体系：市场管理流程、产品开发流程、需求开发流程。在市场管理流程的第一阶段（了解市场阶段）、在产品开发流程的第一阶段（概念阶段）都会定义客户需求的收集活动，用需求开发流程来支撑需求收集活动。三者的相互关系见图2。

指导PMT工作的流程，我们称之为市场管理流程，它分为六个阶段:了解市场、细分市场、组合分析、制定业务计划、融合业务计划、管理业务计划。PMT要调用需求开发流程收集客户需求，作为细分市场的基础，同时在市场管理流程结束时将细分市场需求连同产品开发任务书移交给产品开发团队（PDT）。

产品开发流程也是分为六个阶段，其执行的主体为产品开发团队（PDT），在概念阶段，这个由跨部门人员所组成的产品开发团队将调用需求开发流程，继续对产品包需求进行收集和分析，通过评审后形成产品包概念定义。需求开发流程的执行主体是PMT团队和PDT团队,这个流程作为市场管理流程、产品开发流程的子流程，以指导这两个团队进行市场需求收集、分析、分配工作。

$APPEALS：收集市场需求的工具

$APPEALS规定从8个方面进行客户需求分析，确定客户的购买准则，并评价公司自身产品与竞争对手之间的差距。$APPEALS 所包括的8 大要素如下：

$ Price 价格

A vailability 可获得性

P ackaging 包装

P erformance 性能

E ase of use 易用性

A ssurances 保用性

L ife cycle cost 生命周期成本

S ocial influences 社会影响

针对客户需求分析工具$APPEALS每个要素，可以识别出二级甚至三级要素，而且不同行业子要素不同。针对IC产品开发，价格包括的二级子要素为:产品价格、付款方式、折扣和运费等，可获得性包括交货周期、交货方式、代理商/ 直销商、网上目录查询和预订等。而针对卷烟产品，价格包括的子要素为零售价、促销价等，可获得性包括商场上柜率、烟草公司(代理商)、零售商等。客户购买要素是由客户来确定的，而且针对每个要素的权重也是不同的，当然也是由客户来确定的，而不是研发人员在实验室中想出来的。

客户$APPEALS 工具使用的方法有两种，一种是可以使用$APPEALS 工具模型编写调查问卷进行个体调查；另一种方法是可以用来编写挂图，进行客户群组访谈。

调查问卷的内容一般包括甄别问卷和主题问卷两部分。甄别问卷主要包括被访谈者的年龄、职业、收入、性别、爱好、文化程度等。主题问卷包括内容是客户$APPEALS 模型中的有关内容，必要时可以增加此模型没有包括的内容。

使用客户$APPEALS 进行客户群组访谈时,对已经识别出的要访谈的客户群进行分组分析，并识别出其决策部门和核心人员,编写群组访谈计划（包括客户列表、沟通时间、沟通方式、责任人等）。根据访谈计划对外部客户进行访谈,对访谈的信息、数据进行整理，并对数据进行筛选、分类、优先级排序等分析活动，编写初步的“细分市场需求说明”或“产品包需求说明”。对较模糊的需求进行分析后和客户进行确认，确认的方式为电话、邮件、传真等方式，必要时可以和重点客户对“产品包需求说明”进行评审。■

研发中心工作规范

为了给大家创造一个舒适、愉快、健康的工作环境，特制订以下日常工作规范，请大家自觉遵守。

1、 大厅是大家工作的环境，请为了大家的健康，不论上、下班都不要在大厅抽烟。

2、 会议室是大家一起讨论工作、进行交流的地方，请抽烟的同事，自觉维护好会议室环境，不要乱弹烟灰，乱丢烟蒂。

3、 会议室采用预约制，如果要使用请提前在会议室门口的登记表上填写。

4、 会议结束后，请自觉清洁干净会议室黑板。

5、 在公司外楼道抽烟的同事请注意安全，不要乱扔烟蒂，以免发生火灾。

6、 请大家在下班后离开公司时，自觉关闭电脑和显示器电源。

7、 请下班或加班后最后一位离开公司的同事，关好窗户、大厅内的灯、空调并锁好大门，将钥匙交于三楼前台。

8、 请保持地面整洁，切勿乱丢纸屑垃圾。

9、 请节约用纸，能用再生纸就不用双面空白纸张。

10、 凳子靠板因坐姿不好，重心后压导致损坏的现象较多，请大家保持良好的坐姿。

软件研发知识三分法

什么是“三分法”？

从应用范围的角度，我把软件研发所需要的知识分成大类，或者我把它叫做“三分法”。

第一类知识是现代软件研发方法，包括面向对象分析、设计、编程，设计模式，重构，以及轻量级的敏捷的、迭代的现代开发过程。这些知识居于现代软件研发最基础最核心的位置。具有最大的应用范围。

第二类知识是平台知识，包括编程语言（如C++, C#, JAVA等），操作系统，以及一些通用的开发平台（如MFC, .Net, etc）。

第二类知识我统称为领域知识。比如TTS，视频编解码，网络传输协议等等一定领域的专门知识。

“三分法”有何意义？

作为专业的软件研发人员，面对领域众多的软件产品，面对日新月异的研发技术，一定或多或少地经历过如何安排自己的学习，如何提高自己的学习效率的痛苦。诚然，作为现代人，终身学习基本是一个人在生活上得以安身立命的基础。不过在工作、学习、生活中，如何更有效的安排学习内容，从而最大化自己的学习投入的回报，始终是让我们生活更容易的关键。

“三分法”的意义一：In long term，三分法使我更有效的安排学习，使我的学习投入产出比最大。

从我自身的研发经历中，我把软件研发知识根据其应用范围分为三大类。在任何时候，我始终尽量安排学习和关注最具应用性的知识。当然这基本也和人们常说的做最重要最紧急的事情是相通的。比如，在平时和工作不忙时，我尽量把大量时间分配到第一类和第二类知识的学习，这不光是我深深感受到了基础知识的力量，比如面向对象技术使我软件的分析、设计能力成倍提高，这也是源于我的工作的特点。我基本算是主要解决软件研发工程上的问题，如果了解需求，如何设计软件架构，如何设计类结构，如何控制软件研发的风险。这些是我的主要工作。相信也是绝大多数软件研发从业人员的主要工作。由于学术背景和行业特点，我研发的软件领域跨度极大，再加上有时候不得不换换工作，使第三类知识的深入细致的研究对我很难是个长期的追求。我不鄙视第三类知识，反倒觉得精专的领域知识是许多软件项目成败的关键。不过落实到个人，或者我所看到的绝大多数程序员的生活，第三类知识大都只能做到follow，很难有环境让你清心寡欲的在某个领域深入研究和创新。如此说来，对于90％的程序员，就应该把主要精力放在第一类和第二类知识的研究、学习和实践。让我们最漂亮的解决工程上的问题。其实从一个专门领域研究的突破到成熟的软件产品面世，我们程序员们需要做很多很重要的工作。不要因为自己没有专门领域研究的机会和能力，就觉得没什么好做的了。其实对于大型项目，往往工程化问题更关键。所以我乐于学习第一类知识，认真的研究第二类知识。

“三分法”的意义二： In short term，三分法让我面对眼前问题或者选择目标方向时，更有的放矢。

作为专业的软件研发人员，发现问题解决问题就是我们的日常工作。面对问题，我习惯从本源来考虑它，分析其产生的原因。看我需要哪类知识的提高才能解决问题。比如分析发现需要大量领域知识突破的，我们就要找专门的人来协助，或者采用外协的方法，尽量控制研发风险。另外在工作方向选择时，根据自身的技术积累和兴趣爱好，以及公司大环境，选择自己最能复用已有知识的方向，也是让自己工作更轻松，贡献最大的方法。

研究（研发）类项目的经验

在多元逻辑组合处理及标题语义分析的项目过程中体会到，研究型项目亦及早确定问题领域、算法框架以及评估体系，然后依据实验数据的分析与评估结果进行后继研发——即采用实验效果驱动模式。这个过程中，比较重要的一点是，实验会输出大量的实验数据，对这些实验数据制定评估标准，进行深入分析，审查机器利用原定算法思路所能得到的各种类型的处理结果（也就是黄老师所提到的对机器输出的语料的分析利用），从而进一步思考原算法的优点及缺陷：这个步骤，是项目算法和研发过程双对象沿可预测的、合理的轨迹进行“收敛”的关键保证、动力与着力点，是项目成功的保证。
在商业应用中使用的研究性项目，优先由架构师给出接口定义：这对分割架构开发与专业领域算法的研发工作是有好处的。