标签：七天 bsp 理由 方式 提交 组织 微软 汇报 互联网公司
前两天写《自主开发与带兵打仗》分析了一下自主开发的利与弊，得到了园内不少朋友的反馈，但我觉得还有很多东西没有交待清楚，可能有很多朋友也跟我一样在公司的IT部门，有自己的研发团队也有很多外购的系统或产品。IT部门其实很多情况下对于一个公司其实很多情况下是一个很尴尬的部门，更多情况下在老板的印象里是一个管管机器、管管系统的部门，而所谓的做出点成绩却是要投入大量的成本，而所谓的创新更是无稽之谈。因此我觉得对于一个IT部门来在研发方面很遇到很多问题，而这些问题可能更多跟公司的行业、决策者对于信息化的认知等息息相关的。
其实作为集团下属IT公司的研发团队组建到现在超过三年的时间了（公司的时间要更长点），我刚好有幸经历过了这三年大变革的阶段，从最初的纯PHP团队到纯JAVA团队再到JAVA+.NET团队几乎每年都会有大的调整，大的人员结构变化，可以说在这三年的时候里栽了不少跟斗，而我们自己的印象是公司老在调整，不管是目标还是人员，老板的印象是投了那么多钱却没有什么效益产出。
来看看集团IT的场景吧：
老板：你看咱们有这么多公司，有这么多需求是吧，你们IT这边搞出些系统把这些解决了，对于你们来讲以后就有自己独立发展的可能了，内部公司就作为你们的第一批客户是吧。另外现在市场是有这么多开源的产品你把这些产品整合整合起来不就是自己的系统了嘛。现有很多东西都不需要自主开发了，你搞出一个平台来了有很多人能帮你来开发，说着说着就手起手上的iPad跟我们说上，你看iPad有这么多软件这些都是苹果写的吗？不是，那都是别人帮苹果写的，所以说世界上有这么多聪明的人，你不可能把这些都招聘过来工作，但是如果你有平台的话那么他们就有可能在你的平台上来为你服务，你还不需要给他们付钱，是吧。好吧，咱们就做个平台，这个平台要包含XX、XX、XX、XX、XX、XX、XX、XX、XX、XX、XX，你看你们多久可以搞出来嘛。。。。
IT： 老板这个我们得评估系统功能、工作量、人员，对了还有一部分人在您上次交待的项目上得做完了才能抽出来。。。
老板：我跟你们说你们这种工作方式是不行的，你做不完的工作你可以拆分成任务包嘛，是吧，你可以把这个任务包指派给别人，还可以定一个价格，以后咱们公司就通过任务包来统计工资跟绩效。至于上次那个项目嘛先别做了，现在这是大的概念做好了就可以把上次那个给涵盖到了。所以那个项目的人员从现在开始就调过来好吧。还有工作包的事我觉得这样也不要太久，7天！好吧。为啥七天呢因为上帝创靠人类是用了7天的。所以以后每个工作都要拆成七天。
两个月后，老板又通知IT开会，那个。。咱们现在要搞一个大的XX平台，这个平台可以OOXXOOXXOOXX。。。。，你们看你们IT把人员的都组织一下从现在就开始做这项工作，每周跟我汇报。。。
一年后，老板要求IT提交年度分析报告，汇报刚到一半老板就开始说我投了这么多钱养你们这些几百号人，也没搞出几个像样的产品来出。。。过年前半个月公司开始裁员，开春老板又想了一个新的平台，又开始招人倒腾起来了。。。。
其实我觉得这里面的矛盾有点类似于“我国现阶段的主要矛盾是人民群众日益增长的物业文件需求与社会生产对相对落后的矛盾。”，以上的场景里老板提了很多目前主流的思想，比如：项目产品化、平台接口化、分包、互联网化等等概念。因为随着技术、产品、概念更新得越来越快，很多时候作为公司内部IT已经很难再跟上主流的技术、产品、管理方式。但是由于主流技术或产品又传播得太快导致了IT部门越来越难满足老板的胃口，比如老板刚买了个iPad就想要在上面办公了，而之前的系统其实有很多是不兼容的，修改起来费时费力。当然除了IT部门的原因我觉得很多情况下公司文化主要是决策者（老板）的认识是有很多关系的。我觉得作为内部研发团队会有以下几个问题：
1. 投资不够
其实从一个需求自主开发到一个成熟是一个相对漫长的过程，而在此期间又需要不断的投入以对人员、产品进行调整以优化。但很多情况下作为公司决策者或者业务部门只看到眼前的利益。一个项目如果超过半年以上的话就很难再得到有效的支持了。
2. 团队素质
我们大家都知道“一分钱一分货”，作项目的团队跟做产品的其实从人员技能要求来讲是有很大差距的，但是很多公司往往又无法投入如此大的资源来构建产品团队，更多情况下在严格的成本控制下面很难招到能满足“产品化”要求的人员，如果人员不能满足的话那么就无从谈起产品化了。
3.没有主导权
IT部门在公司里面基本都是“二流”部门，所以很难避免受到公司或者业务部门战略调整的影响，很多IT项目或者人员不得不因为调整而调整。而有时候如果IT部门觉得跟些解决方案其实可以的为业务部门服务，但得不到业务支持的话其实很多情况下也会半途而废。
当然作为IT部门的我们肯定也希望起走这样的困境，毕竟信息化的价值谁都不敢否定，这也是为什么存在的基本理由。初步考虑我觉得以下的一些方面是不是可供参考或借鉴的：
1. 自主开发决策原则
如《自主开发与带兵打仗》里讲到的，其实我们并不是所有的产品或系统是需要自主开发的或者说是值得自主开发的，我觉得如果要决定自主开发来做的话主要是考虑是不是主要的业务方向以便能获取长期的支持，也能积累和提升相应的业务经验与价值，至于这个系统自己有没有能力做或者性价比高不高我觉得倒是其次的了。
2.基础与积累很重要
公司很多项目都需要开发，那么开发的话我觉得不需要一个一个的重头开始做，更不能从PHP、JAVA、.NET整批整批的换，这样的代价太高了。要找准主要方向，管理好相关的代码、文档，当然最重要的还是团队要稳健。还有我最近在考虑要不要用一些像微软的Sharepoint 之类的产品来提高基础平台的能力。这样很多时候开发就不会从头开始了。但是SP的人员成本还满高的可能有待商榷，不过应该是一个方向。
3.新事务要小而快
除了日常的IT及研发工作之后还要对于新事务要采取“小而快”的原则，觉得值得试一试就要快速的组建一个小团队快速的发布成果，并在公司内部培养。
4.规划很重要
很多公司的IT都没有什么规划，或者有的话就只有一年的规划，其实IT建设是一个相对漫长的过程。我觉得主要的规划以三年为一个周期比较合适，然后每年还有一个相对详细的规划。并且这个规划一定要得到决策者的支持。规划里面除了IT和研发的事项之外其实还要考虑到非IT人员的培训、软、硬件重要的升级等事项。比如全员升级到Win7之类的。不然你以后开发系统体魄得考虑IE6的问题。
5.开源值得尝试吗
公司内部的项目除了使用一些开源的解决方案之外有没有办法可以把自己的研发成果开源出去，以便构建社区，提高产品化的可能性。这种方式在互联网公司里面比较普遍，不知道这个否适合于企业研发领域。
总结
好了，我觉得我了解到的还有我的想法交待得差不多了，以上只是个人的小观点，可能有很多夸大或者不考谱的成份，等着拍砖。。。。
标签：七天 bsp 理由 方式 提交 组织 微软 汇报 互联网公司
原文地址：http://www.cnblogs.com/GmrBrian/p/6152895.html
