重用管理和技术研究在软件公司的重要性

    先说说我们公司的概况，主要是以一个行业的项目型企业应用为主，有一个技术框架但不完善。

    我想听听大家所在公司的情况，就是你们公司有专门研究技术的人员和部门吗？这些人不参与项目的开发，而是开发技术框架，为开发人员提供技术支持和培训，对公司的技术资源进行积累，形成公司技术资源库。如果不设立专门的人员，而是在项目中积累，就没有统一性 ，开发人员在项目中受进度等项目指标的影响，他们的目的是完成项目，和形成技术积累目标是不一致的。

    我认为软件公司提高开发效率，是应该要有一个这样的组织或部门来进行这样的工作，但实际上很多公司不够重视，结果因为技术支持不够，公司平台和框架不完善，开发效率非常低，以往技术资源的重用也不理想。公司领导对这块不是很重视，认为技术是次要的，项目是主要的。不把技术研究，通用技术平台建设以及资源库当作公司重要的任务来看待。直接的结果是，技术人员参差不齐，工作成果依赖实际技术人员的水平和学习能力，没有公司级的技术支撑。
   
    我认为，在软件公司中，一个人的工作能力体现为四个方面：
    第一 知识。拥有了知识，才有了解决问题的前提，知识面广，解决问题的思路就更宽阔。
    第二 工具。熟练运用工具才能提高工作效率。用的好可能比用的不好工作效率高几倍以上。
    第三 技能。比如精通Spring框架，技能直接体现在工作的效率上，是一个综合的体现。
    第四 制品。这里就是指工作成果，程序员的制品就是写出高质量的代码，需求分析人员就是写出一篇完善的需求分析文档。

    对于现在的企业应用，特别是开发Java应用，经常需要借用多个成熟的框架来完成，学习成本可以说非常的高。对于一个能够胜任工作的员工，应该有统一的获取这些知识，技能的途径。单纯通过自学积累是很难获得的，而且学习效率也非常低。
    对于一个软件企业，如果想长期发展，我认为下面这些东西都是必须的：
    1. 技术平台。公司统一的技术平台，为开发项目和产品提供支持。
    2. 资源库。 积累特性领域模型和业务知识。
    3. 研究中心。负责技术平台的开发，资源库的建设和维护。应该做为一个单独的组织。
           同时负责组织和实施新技术的研究，并转化为公司积累。另外就是组织培训，
           培训工具和开发技能，提高开发人员效率

    目前我们公司的实际情况是，所有人都在参与在项目中，没有人负责技术研究和积累工作，技术框架也不够完善，也没有时间完善。我是技术总监，但人员都在项目中，所有这些事情不是我一个人能完成的，况且我自己也有一些琐碎的管理工作，根本没有精力实施上述计划。
     请大家发表一下看法，不知道我问题有没有描述清楚。

评论

39 楼 一蓑烟雨任平生 2008-02-17  

evanyuan 写道

重用管理的话，搞个PMO （参看 http://blog.csdn.net/crownconsulting/archive/2008/01/02/2010252.aspx），把Project Manager作为一个pool，搞一个leader，负责制定些规章制度和PMO组织发展计划，定期不定期把PMs召集起来。

从哪本书里抄过来的吧，你在哪个公司成功实施过？能够这么做的条件是什么？

38 楼 evanyuan 2008-02-17  

重用管理的话，搞个PMO （参看 http://blog.csdn.net/crownconsulting/archive/2008/01/02/2010252.aspx），把Project Manager作为一个pool，搞一个leader，负责制定些规章制度和PMO组织发展计划，定期不定期把PMs召集起来。

重用技术的话，软件开发公司和业务公司内部开发部门会有些不同。一般可以有R&D Dept或者EA Team来承担。如果你是50~200人的团队，在初期，建议从每个项目组找总共5~10个有经验的核心开发人员，组成一个虚拟的SA (system analyst, system architecture, whatever)团队， 有CTO的或者特有公信的人lead（找不到这样的人可以考虑轮值lead ），当然也是从制订些规章制度和发展计划开始，可以做的事情很多。通过这种虚拟的团队，一可以避免技术团队太脱离业务开发，二来老板和业务开发团队不会老觉得这拨人一天不干正事。当然虚拟团队的同志会比较忙一些，但是从个人发展的角度来说，应该会比较乐在其中。

37 楼 一蓑烟雨任平生 2008-02-17  

怎么感觉gurudk就自己一个光杆司令，公司没有一个技术管理部或者项目管理办公室这样的部门吗？

36 楼 gurudk 2008-02-16  

一蓑烟雨任平生 写道

重用管理和技术研究能否分成两块来分别考虑？

重用管理针对以往历史项目的可重用部分进行抽取、标准化管理，可以由CTO通过技术管理部门下达计划和管理考核办法，逐步在生产项目中进行重用部分的实施，并基于采纳情况，对贡献者给予奖励，对违反管理办法的给予惩罚，这项工作可以先动，用不着说太多，关键要先动起来。作为CTO应该可以推动，不需要太多的资源，刚开始的时候不用做的很大，先把一些标准化的工作，比如界面标准、权限管理等内容交给生产项目的负责部门，由他们进行整理，然后进行评估改进，形成标准，具体的工作不脱离实际开发部门。这事慢慢来，一件一件的做，领导那边只要你能说清楚，一般应该问题不大，项目考核中加上“重用资源贡献情况”、“标准使用情况”即可。

技术研究对于服务型项目型企业来说，成立一个独立的部门有些奢侈，这是我个人的看法，项目紧张，能做技术研究的人都是能力很强的，公司领导会觉得把他们放到项目里面更有作用，另外独立一个部门，对企业来说动静太大，处理不好容易出现各种问题，比如人事、薪资和考核，领导会有顾虑。目前一般谈到的技术研究往往是框架设计，CTO如果要跳出来自己来做，弊大于利，首先脱离具体的生产项目和部门，资源不足，做出来的东西是否能合适也未可知，再者CTO不应该去剥夺开发部门的乐趣，框架设计开发所带来的成就感应该交给开发部门，CTO更多的是组织资源提供保障。建议找一个具体的项目，就框架的一个具体内容对开发部门提出要求，由项目组来通过具体项目完成，结合重用管理的政策，激励开发部门带着目标去逐步完成技术研究，这时候CTO可以在项目的几个节点组织相关部门的技术骨干进行评审。等到效益出来后，再看是否需要独立出一个团队出来。

说的很实在。
关于重用资源这块，有领域模型，有文档，有组件，还有知识经验等。组织收集这些，我认为需要专门人的，领导给我1个人，哪怕是实习的也好。不过这块确实可以慢慢的一件一件的做，我们公司没有绩效考核评价体系，如果我一个人推动，很难做。做项目的肯定以项目为主，目标定在这里，就不可能两者兼顾。领导给态度，给资源就好做的多。我现在也成立了一个平台项目组，组成员也是部门里的技术骨干，但都被拖在项目里，为了项目还经常加班，你说哪有心思做这个。
关于技术研究，我想另外一个做法是设立技术经理岗位，放在研发部门里，我来统一管理和组织，这样做不像成立部门动静那么大，也比较可行。具体的项目一般都有进度的限制，完成功能都是首要任务，哪还管的了重用框架啊。如果项目周期长，这确实是是一个好办法。

35 楼 gurudk 2008-02-16  

tin555 写道

强力支持楼主的方式.其实我认为这个部门是做为一个公司的技术核心,支持和维持公司的代码的,可提供技术支持.可进行公司框架设计..也可对项目组成员代码进行监督(让大家写出好代码),这样不是很好吗?为什么会出现否定意见??

不是否定意见，而是公司没有表示明确支持，我是一直用邮件和公司领导沟通的，领导估计没心思，忙着搞资本运作呢。

另外，我觉得让开发人员写好代码，有几个方面，一个是要有一份公司级的编码规范和最佳实践，并逐渐完善。另外就是靠项目组内的Code Review，再就是为新人要指定师父，经常指导，这种传统的做法还是很有效的。监督的事由质量保证去做了，不过对于写出好代码，最终还是要开发人员水平提高，监督只能起辅助作用。

34 楼 gurudk 2008-02-16  

hyhongyong 写道

LZ的想法，看起来很美！不过要想真正实施，还需要很多的方面的工作：
1、如何保证做技术研究的总结出来的经验、教训是基本正确的？或者应用在项目上是基本正确的？
2、如何保证这些经验、教训能被正确的利用？
3、如何评价这个技术部门的功效？如何控制整体成本？（不能想当然！）
4、如何保证这个技术部门做的东西是工业级的？（最讨厌的就是鸡肋一样的架构）

Re 1: 实践就是检验这些的标准。不过，这些东西是很难量化的。但也有一些判断标准，比如产品周期短了，维护软件成本低了，开发效率提高了，加班少了，有积累了，不用每次重新发明轮子了，工作效率提高了。
Re 2: 按照我原来的想法，这个正是这个部门的职责。
Re 3: 好处不是马上见到，评价还真有些困难。即使这样做真的最后没有什么用，我觉得也需要去尝试和实践，如果什么都不去尝试，都怕，那怎么可能进步。关于成本，做什么事都需要成本，就像质量保证，没有它事情也有可能做好，但为什么很多公司都需要质量保证呢，因为有了它，就从组织上保证了过程的质量。质量保证也需要成本，它的成果也是很难评估的，做的时候程度也可以粗，可以细，但这个工作被一般公司都作为专门的职责来对待，说明它确实是有价值的。回过头来看，软件重用确实是花成本，见效慢，但它是有价值的，有很多国外软件公司重视就是证明，应该把它作为专门的职责来对待，应该是公司的一个重要工作。
Re 4: 你所谓的工业级的是什么样的啊？我们不需要做成工业级的，我们又不是卖平台（除非以后专门干这个），它只是产品线的支撑，可以说是公司级的，这是定位。第二，哪些平台不是逐渐发展起来完善的，做成什么样，和认识深度有关，和架构师经验有关，和定位有关。说白了，就是要有做工业级的决心和信念，但是还是要从公司的实际情况出发。Eclipse的插件体系结构一开始不也是自己的，后来使用OSGI了，中间也发生过很大的改变，这个是发展的必然。

33 楼 gurudk 2008-02-16  

bluemeteor 写道

想吃苹果，那么学会种树浇水，如果别人都再等着吃，你可以选择自己种树自己吃或者给别人吃，如果你不想种树，却整天喊饿是件很可怜的事情。那些成天喊着种树可是连坑都没挖过得人是很可耻的

做这些事情是要组织保证，高层领导支持才行。自己可以种苹果，苹果是好东西。但没有高层领导支持，你就得种水稻，不种就得挨饿，公司也的挨饿。其实我们公司还存在另一比较严重的问题就是职责不清，我是技术总监，我还得带项目，还忙公司规范性和软件过程改进的事，杂事也很多。没有精力完全放在这些技术上面，要说坚持下来，靠激情，也能做下去，但我认为在组织里，这不是正确的做法，也不是好的做法。我们公司准备过CMMI，我想CMMI不一定能管用，但能让公司高层领导认识到职责分工明确的重要性。所以，我知道苹果好吃，也有种苹果的方案和构想，但是领导认为他不需要苹果，他要种水稻就行了，我一个人种苹果太傻了。我也想过另外一种做法，就是可以在各个研发部门设立技术经理的岗位，这些人可以协助我做这些事，也不用成立新的部门。这件事，是临时工作组，还是部门，还是单独的职位，需要的都是决策者的支持，其它都已经不重要了。公司大了，过程和职责都要明确，否则就会紊乱，一团糟。

32 楼 hyhongyong 2008-02-14  

LZ的想法，看起来很美！不过要想真正实施，还需要很多的方面的工作：
1、如何保证做技术研究的总结出来的经验、教训是基本正确的？或者应用在项目上是基本正确的？
2、如何保证这些经验、教训能被正确的利用？
3、如何评价这个技术部门的功效？如何控制整体成本？（不能想当然！）
4、如何保证这个技术部门做的东西是工业级的？（最讨厌的就是鸡肋一样的架构）

31 楼 bluemeteor 2008-02-14  

想吃苹果，那么学会种树浇水，如果别人都再等着吃，你可以选择自己种树自己吃或者给别人吃，如果你不想种树，却整天喊饿是件很可怜的事情。那些成天喊着种树可是连坑都没挖过得人是很可耻的

30 楼 笨鸟先飞 2008-02-14  

完全同意，为了不做重复的东西，为了提高开发的效率，在可控的边界下面，抽象并实现出共性的东西，提供非共性东西的模型实现支持。

29 楼 gigix 2008-02-14  

tin555 写道

强力支持楼主的方式.其实我认为这个部门是做为一个公司的技术核心,支持和维持公司的代码的,可提供技术支持.可进行公司框架设计..也可对项目组成员代码进行监督(让大家写出好代码),这样不是很好吗?为什么会出现否定意见??

你做过吗？

28 楼 tin555 2008-02-14  

强力支持楼主的方式.其实我认为这个部门是做为一个公司的技术核心,支持和维持公司的代码的,可提供技术支持.可进行公司框架设计..也可对项目组成员代码进行监督(让大家写出好代码),这样不是很好吗?为什么会出现否定意见??

27 楼 foxgst 2008-02-08  

从技术方面来说，楼主提的问题在专业上已经有细分了。

抛出异常的爱 写道

第一个在日本外包组的话叫检证组。
第二个在日本外包的话叫工具组。他们常常用excle写点代码生成工具（不过这个组员都是临时的，用6点以后的时间来作这事。每生成一个工具都会有评估，给与奖励）

楼主目前苦恼的问题应该说是在技术管理上。一方面软件专业方面的管理，一方面是研发部门的管理，前者大家已经讨论过，有一些可行的方案可以使用，至少有石头可以摸，后者的话就与传统意义上的管理相差不大了，但与技术研发是两码事，在此CTO要充当好研发部门和高层管理者之间的桥梁，保证研发工作可以有效开展。

26 楼 tuti 2008-02-04  

Rails 是怎么产生的?

25 楼 bluecrystal 2008-02-02  

楼主所提的问题，在我们公司目前已经造成一个瓶颈。
由于我们公司属于典型的领导一锤子决策的国营企业，重业务不重技术，重关系不重管理，搞得我简直犹如一个救火队员，系统运行没有问题，ok，您歇着就成，有问题，就修修补补，然后不停的做这个项目做那个项目，很多时候，研发这块简直就是打杂，好几次部门内部开始系统的做些基础工作，结果被叫停，搞得大伙儿那心啊，都被砸碎了。
其实不同类型的公司，应该采取不同的策略去做楼主所说的问题，比如我们公司，我不可能要求领导成立这样一个部门来做技术研究工作，领导会说，你们现在的人就够多了，还要成立新部门，不行，那成，我在现有部门的基础上，利用合理的时间分派和人力分配，来做这些基础工作，可领导又说，咦，你们的人咋都不工作了，都干嘛了(领导只关心业务部门去了)，xx你去把市场部的电脑全部杀杀毒，只有吐血而亡，再解释也没用，做了很多脏活累活，由于不像业务部门那样看得见，拿得出，即便你写了再多的代码和文档，他只会一句话：你们啥都没做啊。
郁闷啊，我干嘛跑这个公司来遭这罪啊。

有时候技术上的创新和基础工作，对公司来说，其实就是一种长期投资，其回报周期长，但是我们不该短视或忽视！

借贴发牢骚，勿怪 ：）

24 楼 tedeyang 2008-02-02  

很有必要，我们公司2006年底成立了这样的小组，成立一年多以来对开发的促进效果很明显。不过难点在于研发和项目之间不容易配合。这个缺点楼上几位也都提到了，内部需求收集、打破隔阂、培训推广都是很难做的。

23 楼 1314520ln 2008-02-02  

看技术人员的素质了..好的技术人员会发现框架的缺陷,会主动的去修补框架.增强功能..进行重构的..

22 楼 timerri 2008-02-02  

想法不错。。
技术的分层....可提高基础部分的重用性和健壮性。有利于可持续性发展。
唯一的坏处是会增加成本....
把握平衡吧，找一个好一点的内部需求收集人员。。

21 楼 gurudk 2008-02-02  

hlxiong 写道

引用

我说的技术研究，产品设计开发肯定是产品团队的事。我的意思是技术部门提供技术保障，这是完全不同的很清晰的两个职责。打个比方，在生产企业里，技术部门负责制造和修理生产用的机器，而另一部分人就是用这些机器生产实际的产品。在企业领域，属于支持部门，并不直接生产产生经济效益的产品。
我现在是很想知道别的公司如何做的，也没有机会到一些比较好的软件公司学习，所以在这里发个帖。

貌似偶还比较幸运。。。
偶们公司有研究所，公司的核心开发技术都掌握在他们手里，负责进行先进技术研究和支持。。。
我们部门也有自己的研究室，负责开发维护本部门的开发平台。研究室不直接参与项目开发，属于技术支持力量。。。
做自己的技术开发平台，我想这是正规公司的必由这路吧？否则如何持续发展？总不能永远做一个项目搭一个架子吧？

我们公司不是没有架子，每个方向都有了架子。但我感觉这些架子和我想象的差距比较远，而且因为没有专人改进它，发展也相当缓慢。

20 楼 抛出异常的爱 2008-02-01  

一蓑烟雨任平生 写道

重用管理和技术研究能否分成两块来分别考虑？

重用管理针对以往历史项目的可重用部分进行抽取、标准化管理，可以由CTO通过技术管理部门下达计划和管理考核办法，逐步在生产项目中进行重用部分的实施，并基于采纳情况，对贡献者给予奖励，对违反管理办法的给予惩罚，这项工作可以先动，用不着说太多，关键要先动起来。作为CTO应该可以推动，不需要太多的资源，刚开始的时候不用做的很大，先把一些标准化的工作，比如界面标准、权限管理等内容交给生产项目的负责部门，由他们进行整理，然后进行评估改进，形成标准，具体的工作不脱离实际开发部门。这事慢慢来，一件一件的做，领导那边只要你能说清楚，一般应该问题不大，项目考核中加上“重用资源贡献情况”、“标准使用情况”即可。

技术研究对于服务型项目型企业来说，成立一个独立的部门有些奢侈，这是我个人的看法，项目紧张，能做技术研究的人都是能力很强的，公司领导会觉得把他们放到项目里面更有作用，另外独立一个部门，对企业来说动静太大，处理不好容易出现各种问题，比如人事、薪资和考核，领导会有顾虑。目前一般谈到的技术研究往往是框架设计，CTO如果要跳出来自己来做，弊大于利，首先脱离具体的生产项目和部门，资源不足，做出来的东西是否能合适也未可知，再者CTO不应该去剥夺开发部门的乐趣，框架设计开发所带来的成就感应该交给开发部门，CTO更多的是组织资源提供保障。建议找一个具体的项目，就框架的一个具体内容对开发部门提出要求，由项目组来通过具体项目完成，结合重用管理的政策，激励开发部门带着目标去逐步完成技术研究，这时候CTO可以在项目的几个节点组织相关部门的技术骨干进行评审。等到效益出来后，再看是否需要独立出一个团队出来。

第一个在日本外包组的话叫检证组。
第二个在日本外包的话叫工具组。他们常常用excle写点代码生成工具（不过这个组员都是临时的，用6点以后的时间来作这事。每生成一个工具都会有评估，给与奖励）