下面总结一下各产线的问题，其实也是接着上次的话题聊，这些问题光想是没有意义的，必须深入到其它的产品线去了解，搜集大家提到的问题，并总结共性的内容。
引子――听到的问题
一个公司有很多垂直的产品线，而产品线之间的沟通，解决问题，技术架构为什么千奇百怪。为什么重复造轮子呢？
这几天和一些同学聊了下，没说多少话，尽可能的倾听，尽可能的得到问题，尽可能的自己想能不能解决这些问题。
不能算深入的了解，至少是了解到了一些问题。应该说这些问题应该是有同性的。无技术人才储备――有很多产品线的架构很老，当一次产品升级时，没有良好的技术储备，那得到处借人，而结果也是不一定能得到好果子吃。重复调研、造轮子――相信不只一个公司在做这类事，而这类事似乎无解――一个例子是大家写了功能几乎相同的脚本库，但情有可原的是没有一个脚本库能解决所有的问题。踩到的坑我也没说――结果是，很多人都在这块石头上受了点伤。也或者不同的产品线分享信息的方式不一样。其它产品线的人没有很好的办法获取这样的信息。会多――这也不是一个团队遇到的问题。接口不规范――接口没文档，信息推送不及时，每次升级接口要么是不知道发邮件给谁，要么是上线了出现一大堆的问题。总之，这是个连锁反映，不管你改的是bug还是优化，它总是影响其它引用的模块或产品线。这或许是冰山一角。
但从本质上来看，基本是信息共享的问题。有的公司如果信息化做得足够强的话，是可以解决这些问题的。但问题是我们国内的公司有几家解决了这样的问题呢？只能说还在路上。
从我自身的经历来看，这些问题都不是纸上谈兵能解决的――开几个会，结论就是再研究研究吧，最后无果而终。
解决问题的途径就是实践，实践之前的充分了解问题是可以的。但要有个合适的度把握一下。所以在一定范围内先开展。
分门别类说下我的看法。
无技术人才储备
技术储备是每个产品线必须要做的事。我理解这个问题解决起来还比较简单，多招几个人做后续储备即可。
不建议产品线之间的相互调动及换岗――换岗有可能引发其它的问题，例如对历史问题了解不够导致错误决策。
人才储备的结构就应该是梯度的。
一个好的公司既有埋头拉车的，也有抬头看路的。
leader要看清每个人的特长，让他们在合适自己的位置上发挥自己的才华。
重复造轮子
重复造轮子不可怕，而我更关心的是造出来的意义在哪里，如果说每次造出来的东西都有不一样的地方，能解决目前所存在的很多问题。我认为是可以小规模尝试的。
例如QQ不是天天抄一些别人的产品吗。但不得不承认他们重复造得好，造得妙――现在他们大多数产品在抄的时候都再改进了下这些产品。
话说回来，也就是说，如果你之前做的东西已经被现在要造轮子的这位同学充分理解了，也懂了那一大堆历史问题之后，他再去写，再针对的解决，回头再与相关的所有同学讨论。――这样造个轮子也无妨呀。
总结，造轮子的同学都应该坐在一起，大家多讨论，争取把共性问题都能很好解决，个性问题相互学习。这既能提早发现问题，也能很好提高自己的水平。
踩到的坑我也没说，有关知识分享
信息分享现在最好的方式是什么？――就是目前最火的模式twitter，即微博模式。那自然它是否可以借鉴这样的方式从而来解决这样的问题呢？――目前正在尝试。
前阵子与同事讨论这个问题的时候，总结出知识分享的几个要点：知识分享应该有良好的文档结构。有激励机制，例如加入KPI考核，积分机制等。但必须是硬性量化的KPI。有专人维护。――review机制保证知识的质量。好用的平台。――相信比较多的公司原则是，给用户的是最好的，给自己人用的是随便的。所以导致即使前面做得再好，最后一步没有做好，也没有人用。twitter用的人多，记得不错的话70%以插件形式发出。所以，我们也可借鉴。这方面做得好的有MS的知识库，IBM的develop知识库。可以借鉴他们的思路来做自己的知识库，
不知道网上有没有一个网站，就是记录webdeveloper前端的坑，又有良好的文档结构呢？如果国内能做一个这样比较专业的网站，应该比较受欢迎，又或者已经有这样的网站了？
会议比较多
某段时期内，我记得自己曾经一度一周大概差不多七八个会吧。这真是一言难尽呀。所以我干脆把我的IM签名改成下午两点到四点不要打扰我之类的话来发泄，解决我会议多的问题。
我不得不思考，那么多会议，都是有价值的吗？这我倒不强求每个会议都能达到预期，但至少70%要有针对性些吧，换句话说意思就是必须大伙一起开会解决吗。如果没有的话，开会岂不让很多人都很无聊的看着投影。。。至少我是遇到了很多次。
没有主持人，没有会议记要，会前没有告诉大家会议中所提到的专业术语等等。。。
关于这个，我建议大家去培训一下 六色帽子 的会议培训。
接口不规范
月影同学说做个接口平台，这个觉得不错。哈哈，让大家对这个接口提出建议和反馈。至少可以在一个项目中尝试。
如果好的话，可以做成一个大的开放平台。
我自己的总结
从我的角度看，发现现在团队所有的问题比解决问题更困难。
这需要和团队成员沟通，也需要你自己的观察，更需要的是你团队成员给你的信任。没有信任你什么也做不了。
我其实很想了解其他产品线的同学们的开发方式，解决某些问题的方法。
但很多公司是没有这个机会给你的，其一是因为你每天都只关心下一天干什么，其二是你不知道负责人是谁，你只能厚着脸皮和对方聊一下这个问题。
如果我们有一个比较好的平台，使得我们有良好的沟通和反馈机制的问题。这个平台既可能是程序，也可能是部门之间长时间培养出来的默契与规范。
那我想这是大象跳舞的前提了。
说易做难。没有银弹，只有实践才是适合自己的。目前这些正在实践去解决这些问题。
如果说这里提到的问题你也有，而且能提醒你。这篇文章至少已经有点作用了，呵呵。