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

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

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

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

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

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

评论

19 楼 一蓑烟雨任平生 2008-02-01  

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

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

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

18 楼 hlxiong 2008-02-01  

引用

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

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

17 楼 ak_2005 2008-02-01  

这个是很有必要的。我原来公司就专门成立了一个架构组，为其它team提供一个通用架构，并且提供技术支持。当然架构组的成员可以是各个组的team leader。他们负责开发框架，技术培训，疑难问题解决。。。

16 楼 gurudk 2008-02-01  

mxtah 写道

抛出异常的爱 写道

能不能提高工作效率？
能的话，可以与老板谈
必要资源有多少？
如果不能拿到人员组格权，不用想了作了也不爽。
如何交流？
你公司原来的组织结构可不可能在不用强力行政手段就可以作到
底层的交流。
如果我就不会去作。
因为如果没有先例的新事务是很难成功的。
我会找个以前的闲置的部门来作新部门的壳子
借壳上市。

关于工作效率这个东西可能是长线投资，如果公司希望能走很长一段路，那么我想复用组件应该在长远的项目中能体现出价值来的，当然如果公司是想着捞一票就走，哪天倒了算的话，可能老总考虑的更多的是如何从目前的项目中去得到现金了。
另外我想问一个问题，不知道国内或者说北京吧，现在的公司是不是会自己再对流行的框架进行封装或增强？我们公司是有专门做这个的，我觉得很有必要。

我们公司还是非常稳定的，给中石化一个炼油厂的提供服务外包的，每年服务费近千万，发发工资不成问题，比又想发展又想填饱肚子的小公司好多了。这样的机会，你说发展不起来，能怪比人吗？只能怪自己了。关键看领导有没有这个眼光，我门下面的只能提提建议。

15 楼 gurudk 2008-02-01  

gigix 写道

引用

我想听听大家所在公司的情况，就是你们公司有专门研究技术的人员和部门吗？这些人不参与项目的开发，而是开发技术框架，为开发人员提供技术支持和培训，对公司的技术资源进行积累，形成公司技术资源库。

这个部门在H公司的二级部门下面叫总体技术部，落在三级部门里面叫系统组，里面的人叫SE。而H公司正在做的一件事情就是要打破SE和开发团队之间的隔阂，让SE投入到项目开发里面，因为他们发现自己做出来的设计既不足够指导开发又有浪费。
我经常说的，太阳底下没有新雪。与其坐而论道，你还不如去调研一下H公司这种典范都做过些什么。

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

14 楼 gurudk 2008-02-01  

抛出异常的爱 写道

能不能提高工作效率？
能的话，可以与老板谈
必要资源有多少？
如果不能拿到人员组格权，不用想了作了也不爽。
如何交流？
你公司原来的组织结构可不可能在不用强力行政手段就可以作到
底层的交流。
如果我就不会去作。
因为如果没有先例的新事务是很难成功的。
我会找个以前的闲置的部门来作新部门的壳子
借壳上市。

1.工作效率肯定是可以提高的，和专业化分工的道理是一样的。
2.必要的资源我心里有数，就看老板给不给了，我还没谈过。
3.是的，就我老哥一个，是干不起来，我不是神啊。
4.借壳上市不太可能。
5.新事物是发展过程中的必要，所谓不破不立，任何发展都需要变革，就是打破现有的东西，尝试新的东西，这是普遍发展规律。

13 楼 mxtah 2008-01-31  

抛出异常的爱 写道

能不能提高工作效率？
能的话，可以与老板谈
必要资源有多少？
如果不能拿到人员组格权，不用想了作了也不爽。
如何交流？
你公司原来的组织结构可不可能在不用强力行政手段就可以作到
底层的交流。
如果我就不会去作。
因为如果没有先例的新事务是很难成功的。
我会找个以前的闲置的部门来作新部门的壳子
借壳上市。

关于工作效率这个东西可能是长线投资，如果公司希望能走很长一段路，那么我想复用组件应该在长远的项目中能体现出价值来的，当然如果公司是想着捞一票就走，哪天倒了算的话，可能老总考虑的更多的是如何从目前的项目中去得到现金了。
另外我想问一个问题，不知道国内或者说北京吧，现在的公司是不是会自己再对流行的框架进行封装或增强？我们公司是有专门做这个的，我觉得很有必要。

12 楼 mxtah 2008-01-31  

另外，我们部门在项目中(我们研发的产品也是按照项目走的)，严格控制对公用模块的修改，即使要修改，也得报给技术经理或者框架组去处理。

11 楼 mxtah 2008-01-31  

我刚刚新加入了一个公司的研发中心，我们公司目前有个职位是技术经理，基本上他只需要负责新技术、新模块、新框架的研发和积累，同时和他对等的职位有个产品经理。产品经理更多的职责可能是如何更好的使用公司目前有的技术和框架，去解决新产品的研发问题。
同时说一句，我们公司的实施任务还是很重的，很多时候研发都要派力量参与或者协助实施，不过技术经理基本上是不会参与这个。
所以我想技术经理这个角色还是很重要的，需要重视。

10 楼 gigix 2008-01-31  

引用

我想听听大家所在公司的情况，就是你们公司有专门研究技术的人员和部门吗？这些人不参与项目的开发，而是开发技术框架，为开发人员提供技术支持和培训，对公司的技术资源进行积累，形成公司技术资源库。

这个部门在H公司的二级部门下面叫总体技术部，落在三级部门里面叫系统组，里面的人叫SE。而H公司正在做的一件事情就是要打破SE和开发团队之间的隔阂，让SE投入到项目开发里面，因为他们发现自己做出来的设计既不足够指导开发又有浪费。
我经常说的，太阳底下没有新雪。与其坐而论道，你还不如去调研一下H公司这种典范都做过些什么。

9 楼 gurudk 2008-01-31  

Lucas Lee 写道

这个在一般做项目的公司是不容易的。
中国公司大多没有核心技术，这个还是现状，所以对于技术不会有很大的动力和兴趣。

这个跟专有技术的较高整体成本有关，比如人员跳槽之类的因素。

其实项目多，不用什么技术含量也都能完成，赚的钱的不少。但我感觉这只是权宜之计，不能长久这么干下去。
做这个并不一定很厉害的技术人员，只要肯学习有兴趣就行，要长期坚持做下去。可是，一般厉害的开发人员，
领导都不太肯放，都是在做多个项目的技术支持。

8 楼 gurudk 2008-01-31  

ztka 写道

软件重用收益是长期的，但是公司领导基本以短期利益为重。
国外，像moto，sony等大公司早在10几年前就已经考虑基于组件的重用了，我们国内目前公司都停留在比较低层次的重用。


不同公司 侧重点不同，你举例都不是以开发项目，外包为主的这些公司，有没有这种公司的很好的实例，你再谈你的思路是否能成功。

1.长期做定制开发项目，收益率很低的。我们是做一个行业的，虽然不能都产品化，但还是有些东西可以产品化的。
2.我感觉有没有好的实例不重要，只要探讨这种思路可行，就可以去实践。况且有我这种想法而且去实践的，应该不少的吧。

7 楼 LucasLee 2008-01-31  

这个在一般做项目的公司是不容易的。
中国公司大多没有核心技术，这个还是现状，所以对于技术不会有很大的动力和兴趣。

这个跟专有技术的较高整体成本有关，比如人员跳槽之类的因素。

6 楼 ztka 2008-01-31  

软件重用收益是长期的，但是公司领导基本以短期利益为重。
国外，像moto，sony等大公司早在10几年前就已经考虑基于组件的重用了，我们国内目前公司都停留在比较低层次的重用。


不同公司 侧重点不同，你举例都不是以开发项目，外包为主的这些公司，有没有这种公司的很好的实例，你再谈你的思路是否能成功。

5 楼 抛出异常的爱 2008-01-30  

能不能提高工作效率？
能的话，可以与老板谈
必要资源有多少？
如果不能拿到人员组格权，不用想了作了也不爽。
如何交流？
你公司原来的组织结构可不可能在不用强力行政手段就可以作到
底层的交流。
如果我就不会去作。
因为如果没有先例的新事务是很难成功的。
我会找个以前的闲置的部门来作新部门的壳子
借壳上市。

4 楼 gurudk 2008-01-30  

抛出异常的爱 写道

楼主说的很像是责任分担
自己不想承担这样的责任
认为新建一个部门就可以
把这样的问题产生出来的矛盾转嫁给别人了。

PS：那个部门的人也是人不是神。也是由程序员里找到的人。你要是作不到的事，让别人来作别人也很为难的。

我不是不想承担这些责任，其实我有完整的想法，而且基本都写成方案了。也成立了项目组做技术平台，但是这个项目组除了我之外，都是兼任的。公司明确说了，以项目为主，结果我这个项目组的人大部分都在做项目。做技术平台的人相当于临时工，不好控制，而且他们都有部门经理，人不归我管。成立这样的部门，我是想当这个部门负责人，我的部门任务就是服务于开发部门，从组织架构上讲，职责也是清楚的。分工越来越细，越来越明确是整个社会发展的趋势。

软件重用收益是长期的，但是公司领导基本以短期利益为重。
国外，像moto，sony等大公司早在10几年前就已经考虑基于组件的重用了，我们国内目前公司都停留在比较低层次的重用。
比如重用源代码（外包模式里的代码copy），重用类库（API），重用技术框架（比如Struts+Spring+Hibernate）。现在大部分公司是重用类库，一小部分公司能够利用开源框架为基础，构建自己企业的开发框架。有的做的完善，有的做的不完善，但大部分还是停留在技术框架的重用，这种框架是可以解决一些问题。但对更大粒度的重用，比如业务组件的重用，据我了解，一般公司都没有。比如你给一个客户开了了一个系统，假设含有100个模块。 推广到另外的客户时，发现其中50个模块能用，40个模块需要修改，10个模块不能重用。如果没有一个技术平台做支撑，可能的做法就是在svn中建一个分支，在整个代码树上做修改。如果推广100个客户，维护的工作量是不可想象的。所以才有了基于组件的开发，大公司可以在产品线范围进行抽象，封装组件，提高重用性。Eclipse的插件体系结构是个很好的参照，我们公司有两个技术体系，一个是dotnet,一个是java。在dotnet上，开发客户端应用，我参考Eclipse的插件体系结构，网上资料不少，但都是demo这个层次的，这块我已经开发出一个雏形，采用组件+服务的理念构建的，参考OSGi规范。框架级的重用是带有局限性的，比如基于两种技术框架构建的应用，很难在业务逻辑层次进行整合。Java这块算是比较好的，客户端应用有好多实现OSGi规范的框架，有Eclipse RCP。B/S架构有JSR-168,268标准的Portal架构，这个可以达到业务组件的重用，但这些平台普遍较慢。我们公司用开源Liferay Portal，做了几个项目，客户普遍觉得慢，不过这个Portal架构我还是看好发展前景的，各个大公司IBM，BEA，SUN，Oracle都有产品。现在有OSGi在Server端的实现，我没仔细了解过。当然，即使有了技术平台，对业务领域的深入分析还是非常重要的，可以说比以前更重要了。如果你采用插件体系结构来开发，插件划分的不好，一样重用性很差，但这个技术平台是两个层次的关系，技术平台是基础，深入分析是保障。组件的重用我认为可以分这样几个层次，比如基础组件（权限，工作流，日志等）和特定领域业务组件（比如OA里的新闻发布， 消息管理，工作日志等等）

3 楼 抛出异常的爱 2008-01-30  

楼主说的很像是责任分担
自己不想承担这样的责任
认为新建一个部门就可以
把这样的问题产生出来的矛盾转嫁给别人了。

PS：那个部门的人也是人不是神。也是由程序员里找到的人。你要是作不到的事，让别人来作别人也很为难的。

2 楼 一蓑烟雨任平生 2008-01-30  

重要性是不言而喻的，怎么做呢？能说说你的计划吗？

1 楼 willim 2008-01-30  

说的好，我们公司好像也缺乏这样专门的人