|
锁定老帖子 主题：重用管理和技术研究在软件公司的重要性
精华帖 (0) :: 良好帖 (9) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-02-01
一蓑烟雨任平生 写道 重用管理和技术研究能否分成两块来分别考虑？
重用管理针对以往历史项目的可重用部分进行抽取、标准化管理，可以由CTO通过技术管理部门下达计划和管理考核办法，逐步在生产项目中进行重用部分的实施，并基于采纳情况，对贡献者给予奖励，对违反管理办法的给予惩罚，这项工作可以先动，用不着说太多，关键要先动起来。作为CTO应该可以推动，不需要太多的资源，刚开始的时候不用做的很大，先把一些标准化的工作，比如界面标准、权限管理等内容交给生产项目的负责部门，由他们进行整理，然后进行评估改进，形成标准，具体的工作不脱离实际开发部门。这事慢慢来，一件一件的做，领导那边只要你能说清楚，一般应该问题不大，项目考核中加上“重用资源贡献情况”、“标准使用情况”即可。 技术研究对于服务型项目型企业来说，成立一个独立的部门有些奢侈，这是我个人的看法，项目紧张，能做技术研究的人都是能力很强的，公司领导会觉得把他们放到项目里面更有作用，另外独立一个部门，对企业来说动静太大，处理不好容易出现各种问题，比如人事、薪资和考核，领导会有顾虑。目前一般谈到的技术研究往往是框架设计，CTO如果要跳出来自己来做，弊大于利，首先脱离具体的生产项目和部门，资源不足，做出来的东西是否能合适也未可知，再者CTO不应该去剥夺开发部门的乐趣，框架设计开发所带来的成就感应该交给开发部门，CTO更多的是组织资源提供保障。建议找一个具体的项目，就框架的一个具体内容对开发部门提出要求，由项目组来通过具体项目完成，结合重用管理的政策，激励开发部门带着目标去逐步完成技术研究，这时候CTO可以在项目的几个节点组织相关部门的技术骨干进行评审。等到效益出来后，再看是否需要独立出一个团队出来。 第一个在日本外包组的话叫检证组。 第二个在日本外包的话叫工具组。他们常常用excle写点代码生成工具（不过这个组员都是临时的，用6点以后的时间来作这事。每生成一个工具都会有评估，给与奖励） |
| 返回顶楼 | |
|
发表时间：2008-02-02
hlxiong 写道 引用 我说的技术研究，产品设计开发肯定是产品团队的事。我的意思是技术部门提供技术保障，这是完全不同的很清晰的两个职责。打个比方，在生产企业里，技术部门负责制造和修理生产用的机器，而另一部分人就是用这些机器生产实际的产品。在企业领域，属于支持部门，并不直接生产产生经济效益的产品。 我现在是很想知道别的公司如何做的，也没有机会到一些比较好的软件公司学习，所以在这里发个帖。 貌似偶还比较幸运。。。 偶们公司有研究所，公司的核心开发技术都掌握在他们手里，负责进行先进技术研究和支持。。。 我们部门也有自己的研究室，负责开发维护本部门的开发平台。研究室不直接参与项目开发，属于技术支持力量。。。 做自己的技术开发平台，我想这是正规公司的必由这路吧？否则如何持续发展？总不能永远做一个项目搭一个架子吧？ 我们公司不是没有架子，每个方向都有了架子。但我感觉这些架子和我想象的差距比较远，而且因为没有专人改进它，发展也相当缓慢。 |
| 返回顶楼 | |
|
发表时间：2008-02-02
想法不错。。
技术的分层....可提高基础部分的重用性和健壮性。有利于可持续性发展。 唯一的坏处是会增加成本.... 把握平衡吧，找一个好一点的内部需求收集人员。。 |
| 返回顶楼 | |
|
发表时间：2008-02-02
看技术人员的素质了..好的技术人员会发现框架的缺陷,会主动的去修补框架.增强功能..进行重构的..
|
| 返回顶楼 | |
|
发表时间：2008-02-02
很有必要，我们公司2006年底成立了这样的小组，成立一年多以来对开发的促进效果很明显。不过难点在于研发和项目之间不容易配合。这个缺点楼上几位也都提到了，内部需求收集、打破隔阂、培训推广都是很难做的。
|
| 返回顶楼 | |
|
发表时间：2008-02-02
楼主所提的问题，在我们公司目前已经造成一个瓶颈。
由于我们公司属于典型的领导一锤子决策的国营企业，重业务不重技术，重关系不重管理，搞得我简直犹如一个救火队员，系统运行没有问题，ok，您歇着就成，有问题，就修修补补，然后不停的做这个项目做那个项目，很多时候，研发这块简直就是打杂，好几次部门内部开始系统的做些基础工作，结果被叫停，搞得大伙儿那心啊，都被砸碎了。 其实不同类型的公司，应该采取不同的策略去做楼主所说的问题，比如我们公司，我不可能要求领导成立这样一个部门来做技术研究工作，领导会说，你们现在的人就够多了，还要成立新部门，不行，那成，我在现有部门的基础上，利用合理的时间分派和人力分配，来做这些基础工作，可领导又说，咦，你们的人咋都不工作了，都干嘛了(领导只关心业务部门去了)，xx你去把市场部的电脑全部杀杀毒，只有吐血而亡，再解释也没用，做了很多脏活累活，由于不像业务部门那样看得见，拿得出，即便你写了再多的代码和文档，他只会一句话：你们啥都没做啊。 郁闷啊，我干嘛跑这个公司来遭这罪啊。 有时候技术上的创新和基础工作，对公司来说，其实就是一种长期投资，其回报周期长，但是我们不该短视或忽视！ 借贴发牢骚，勿怪 ：） |
| 返回顶楼 | |
|
发表时间：2008-02-04
Rails 是怎么产生的?
|
| 返回顶楼 | |
|
发表时间：2008-02-08
从技术方面来说，楼主提的问题在专业上已经有细分了。
抛出异常的爱 写道 第一个在日本外包组的话叫检证组。 第二个在日本外包的话叫工具组。他们常常用excle写点代码生成工具（不过这个组员都是临时的，用6点以后的时间来作这事。每生成一个工具都会有评估，给与奖励） 楼主目前苦恼的问题应该说是在技术管理上。一方面软件专业方面的管理，一方面是研发部门的管理，前者大家已经讨论过，有一些可行的方案可以使用，至少有石头可以摸，后者的话就与传统意义上的管理相差不大了，但与技术研发是两码事，在此CTO要充当好研发部门和高层管理者之间的桥梁，保证研发工作可以有效开展。 |
| 返回顶楼 | |
|
发表时间：2008-02-14
强力支持楼主的方式.其实我认为这个部门是做为一个公司的技术核心,支持和维持公司的代码的,可提供技术支持.可进行公司框架设计..也可对项目组成员代码进行监督(让大家写出好代码),这样不是很好吗?为什么会出现否定意见??
|
| 返回顶楼 | |
|
发表时间：2008-02-14
tin555 写道 强力支持楼主的方式.其实我认为这个部门是做为一个公司的技术核心,支持和维持公司的代码的,可提供技术支持.可进行公司框架设计..也可对项目组成员代码进行监督(让大家写出好代码),这样不是很好吗?为什么会出现否定意见??
你做过吗？ |
| 返回顶楼 | |
