原创 开源思路与公司制度

2008-8-29 19:37 1413 1 1 分类: MCU/ 嵌入式

********************************************************************************
我也觉得,开源项目和传统的企业内部项目的确有些不同,各有利弊,准确地说,是互补。比如说公司制度的特征:利益驱动、目标明确、管理刚性强、向上负责制,但是我们要不要按照公司制度来运作这种项目,或者公司制度有什么不足呢? 



随便来说:



1.利益驱动容易变成利益驱赶,这几乎是目前任何一个从业者压力的首要来源;



2.确定的目标压缩了技术发展空间,比如不少做方案的朋友,觉得做过的东西都不是自己最满意的,或者有升级的想法,因超越经营目标而无法获得资源,公司技术落后;



3.而过严格的等级制度,不小心就导致了下级发展受限制,要求服从的同时丧失主动性,给企业管理带来很大负担,比如近两年很书里引用西点军校的例子,把服从看得很重要,但西点军校的文化哪个企业等获得呢?为国家牺牲的为企业牺牲的差距又多大呢?



4.向上负责制与等级制度有相同的问题,另一个缺点是沟通效率不能保证,很多推委作风来起源于这种向上负责制。做为上级,也不一定从向上负责制中获得多少好处,除了工资高点,心里优势搞点,他们承受的压力也大很多。



坦率的说,我觉得Grant写4楼的帖子,还没有完全理解或认同我提出的基本思路。那么,开源项目到底有哪些区别呢?



不妨从上述几点来寻找对应:



1.变利益驱动为兴趣驱动,从谋求生存变为寻找快乐,所以一早就要求参与者应该有谋生手段,这是第二阶追求;



2.变固定目标为可发展的目标,我们不是要去占领哪个市场,不是要达到多大收益为目标,因此,从这个角度来讲目标,我们不设置天花板,只是负责人
可以把目标分为首要目标、候选目标、超越目标,或者近期目标、中期目标、远期目标,大家可以畅想未来,负责人则决定下一个脚印留在哪里,在此基础上,允许
不断的迭代开发,逐步升级。现实中很多很多开源项目都是这么做的,比如Linux内核,在超过十三年的历史中,虽然目前版本只到2.6.x,但已经是第三
代,经过上百个版本的发布不停迭代走过来的. 其他不计其数开源软件也是这么走的,开源软件就象东莞到达深圳的另一条高速公路。



3.之前我们在讨论中曾经提到过不要太看重名份,上贴提到了项目经理的映射,不妨深入一步讨论一下。用利益的驱动使人服从,和让他人因快乐而追随
是两种架构的最大的区别。不用说就看的出,后者的难度是大很多的,公司内部,有高致法律约束的上下级关系,上级说话做事可以更大胆一些,哪怕下级有一些怨
言,也不能不屈服。而开源项目则得不到这样的保护,人们愿意进来,只是对项目现有成员的信任、尊重、欣赏、仰慕,因此项目主力或者在技术上有过人之处,或
者有其他见识,或者乐于助人,或者勇于承担....。。



聚人心而不是实吏治,是开源与公司制度十分明显的区别,虽然公司制度下也讲究企业文化,以人为本等,但那个受法律保护的等级制度太便利,太顺手了,呵呵。



因此开源项目负责人面对众说纷纭的意见,要制定路线,除了选择,不能不注意的操作是“说服”,而不是命令。这里才落到前几天我提到的沟通技巧上
面,看上面Grant几次提到“非议”,这是一个有一定对抗性的提法,就感觉有必要把上述思路再说一下,希望Grant重视并把自己的观点写出来。



4.变向上负责为对自己负责,头脑风暴冲破沟通障碍,通过快速迭代和密集讨论,用兴趣和快乐做燃料,让每个人的大脑细胞都处于氧气充足,运转欢畅的状态,则是我们一早追求的“汇集多人智力、达成创造性目标”的理想状态。



而负责人,可以做为带头人,带领大家往前冲,也可以站在教练的位置,只对大家做错的地方做修正(需要注意,沟通技巧),也可以融入团队,汇集多人形成合力,突破障碍。总之,负责人除了从头到尾往前冲,把所有担子和责任自己一肩挑起来之外,还有其他方式可以选择。



参与完项目规划,等项目运转起来之后,我就想关闭项目策划的工作重点,做为普通参与者找个任务来学习,那是我来这个站的初衷,我的兴趣。 



*我把公司制度和开源思想分成两个相比较的概念来描述,一定会有朋友认为他们是对立和矛盾的,其实不尽然,这两种形式很多要素做法是相反的,但并
不矛盾。现在比较领先的软件公司中,工程师参与开源项目,是受到鼓励的,甚至以公司形式参与开源项目,做为心态调剂也好,做为培训提升也好,做为替公司宣
传也好,在众多因素上,公司制度和开源思路有不错的契合点。



*上贴提到“参与活动的其他人的利益,谁又来为他们已经付出的精神和精力负责?”,我的理解是:

   1.保证每个人对项目所作的工作不被忽略、抹煞,信息不被删除;

   2.把项目做成,追求卓越,每个人都会作为成员分享卓越DemoKit的作者荣誉;

   3.对于把项目当作饭堂想来就来想走就走的朋友,他们的信息也不会被忽略或者抹煞,并且也有机会作为一个卓越项目的参与者或阶段参与者一起分享成功的荣誉(注意,这时太随意的参与者分享到的也许不是快乐哦  )。



这就是我想到的开源项目能够负责的,除了利益外,还有其他很多种获益的途径,这种观点是建立在:即便是虚拟环境,大家也都愿意、并积极为自己的行
为负责的基础上,就象网游如此纷乱的环境下,大多数人愿意扮演一个负责任、有承担的角色,而不是把网游变成一个谩骂聊天室(虽然很多网游看起来就是一个骂
人聊天室,但我相信每年这么多亿的产值,参与者主流不是花钱进取骂人或看骂人或者被骂的吧,哈哈)。



*另外,Grant一直不太认同追求卓越的思路,我也有一些疑问。即便是我们做一个最简单的充电器,在技术规范书的框架内,我们也应该追求完美,
不但能用,经得起使用,而且要经得起后来者和其他专业人员的挑剔,甚至做成智能充电器的典型示范。不知道这个提法Grant是否赞成,也许Grant比较
务实,脚踏实地,觉得我看得比较空。我的理解是,如果目标不定高一些,有些妥协的味道在那里,如果大家遇到一个难题,比如某个指标达不到,恐怕会说“反正
也不太影响使用”而放弃了,最终落个不好不坏的结果。

对于卓越,我的理解是,每次迭代开发中,不打折扣的实现预定目标。卓越不一定是技术的前沿化和系统的规模
化,或者功能的复杂化。这里我想起一个故事,前年一个管理培训师的课程中有一句话,他说:“我们中国人没有什么做不成的,只要咬咬牙要做,就一定能做到,
我们可以试爆核武器,可以发射载人飞船,这些不是世界上任何国家都能做到了。但是,去看看市场上的商品,我们的干电池合格率都不能及格。中国就是这么一个
国家,可以做到世界最先进的,但小事情就是做不好,因为没有咬咬牙。但我们不能期望什么事情都要政府咬咬牙。”



我完全不觉得目前的技术规格不可用,我完全支持尽快搭建一个可用的平台这样的思路。但是我们要确定达到的目标,应该是矢志去完成的。比如目标是
2A或者1.5A的电流,可能都要面临一定挑战,那么如果我们做出来的系统最大只能跑750ma,就不能到此止步,一定要想办法达到目标。这就是追求卓越
的最基本环节。也许第一个版本不算卓越,但只要一步步走,在第二个,最多第三个版本发布的时候,我相信能够让人让大家看到... 



对于中国人,卓越的目标首先是精细,这其实是日本人走过的路子,他们通过精细的把握在战后在技术和制造业几乎有机会超越美国(后来被克林顿用金融市场和知识经济摔了一交直到现在站不起来是另一个话题),我心里所想的卓越,目前的含义可以理解为“精益求精”。




出之:www.ourdev.cn

  网友:Cocal
       
开源思开源思路与公司制度,兼回Grant
http://www.ourdev.cn/bbs/bbs_content.jsp?bbs_sn=844898&bbs_page_no=1&search_mode=1&search_text=%BF%AA%D4%B4%CB%BC%C2%B7%D3%EB%B9%AB%CB%BE%D6%C6%B6%C8&bbs_id=9999


PARTNER CONTENT

文章评论0条评论)

登录后参与讨论
我要评论
0
1
关闭 站长推荐上一条 /4 下一条