大公司都不能避免出现多条产品线，这有解决工作效率，沟通等问题。但随着产品线的分离又会出现另一些问题。

    下面总结一下各产线的问题，其实也是接着上次的话题聊，这些问题光想是没有意义的，必须深入到其它的产品线去了解，搜集大家提到的问题，并总结共性的内容。

    引子――听到的问题

    一个公司有很多垂直的产品线，而产品线之间的沟通，解决问题，技术架构为什么千奇百怪。为什么重复造轮子呢？

    这几天和一些同学聊了下，没说多少话，尽可能的倾听，尽可能的得到问题，尽可能的自己想能不能解决这些问题。

    不能算深入的了解，至少是了解到了一些问题。应该说这些问题应该是有同性的。无技术人才储备――有很多产品线的架构很老，当一次产品升级时，没有良好的技术储备，那得到处借人，而结果也是不一定能得到好果子吃。重复调研、造轮子――相信不只一个公司在做这类事，而这类事似乎无解――一个例子是大家写了功能几乎相同的脚本库，但情有可原的是没有一个脚本库能解决所有的问题。踩到的坑我也没说――结果是，很多人都在这块石头上受了点伤。也或者不同的产品线分享信息的方式不一样。其它产品线的人没有很好的办法获取这样的信息。会多――这也不是一个团队遇到的问题。接口不规范――接口没文档，信息推送不及时，每次升级接口要么是不知道发邮件给谁，要么是上线了出现一大堆的问题。总之，这是个连锁反映，不管你改的是bug还是优化，它总是影响其它引用的模块或产品线。这或许是冰山一角。

    但从本质上来看，基本是信息共享的问题。有的公司如果信息化做得足够强的话，是可以解决这些问题的。但问题是我们国内的公司有几家解决了这样的问题呢？只能说还在路上。

    从我自身的经历来看，这些问题都不是纸上谈兵能解决的――开几个会，结论就是再研究研究吧，最后无果而终。

    解决问题的途径就是实践，实践之前的充分了解问题是可以的。但要有个合适的度把握一下。所以在一定范围内先开展。

    分门别类说下我的看法。

    无技术人才储备

    技术储备是每个产品线必须要做的事。我理解这个问题解决起来还比较简单，多招几个人做后续储备即可。

    不建议产品线之间的相互调动及换岗――换岗有可能引发其它的问题，例如对历史问题了解不够导致错误决策。

    人才储备的结构就应该是梯度的。

    一个好的公司既有埋头拉车的，也有抬头看路的。

    leader要看清每个人的特长，让他们在合适自己的位置上发挥自己的才华。

    重复造轮子

    重复造轮子不可怕，而我更关心的是造出来的意义在哪里，如果说每次造出来的东西都有不一样的地方，能解决目前所存在的很多问题。我认为是可以小规模尝试的。

    例如QQ不是天天抄一些别人的产品吗。但不得不承认他们重复造得好，造得妙――现在他们大多数产品在抄的时候都再改进了下这些产品。

    话说回来，也就是说，如果你之前做的东西已经被现在要造轮子的这位同学充分理解了，也懂了那一大堆历史问题之后，他再去写，再针对的解决，回头再与相关的所有同学讨论。――这样造个轮子也无妨呀。

    总结，造轮子的同学都应该坐在一起，大家多讨论，争取把共性问题都能很好解决，个性问题相互学习。这既能提早发现问题，也能很好提高自己的水平。

    踩到的坑我也没说，有关知识分享

    信息分享现在最好的方式是什么？――就是目前最火的模式twitter，即微博模式。那自然它是否可以借鉴这样的方式从而来解决这样的问题呢？――目前正在尝试。

    前阵子与同事讨论这个问题的时候，总结出知识分享的几个要点：知识分享应该有良好的文档结构。有激励机制，例如加入KPI考核，积分机制等。但必须是硬性量化的KPI。有专人维护。――review机制保证知识的质量。好用的平台。――相信比较多的公司原则是，给用户的是最好的，给自己人用的是随便的。所以导致即使前面做得再好，最后一步没有做好，也没有人用。twitter用的人多，记得不错的话70%以插件形式发出。所以，我们也可借鉴。这方面做得好的有MS的知识库，IBM的develop知识库。可以借鉴他们的思路来做自己的知识库，

    不知道网上有没有一个网站，就是记录webdeveloper前端的坑，又有良好的文档结构呢？如果国内能做一个这样比较专业的网站，应该比较受欢迎，又或者已经有这样的网站了？

    会议比较多

    某段时期内，我记得自己曾经一度一周大概差不多七八个会吧。这真是一言难尽呀。所以我干脆把我的IM签名改成下午两点到四点不要打扰我之类的话来发泄，解决我会议多的问题。

    我不得不思考，那么多会议，都是有价值的吗？这我倒不强求每个会议都能达到预期，但至少70%要有针对性些吧，换句话说意思就是必须大伙一起开会解决吗。如果没有的话，开会岂不让很多人都很无聊的看着投影。。。至少我是遇到了很多次。

    没有主持人，没有会议记要，会前没有告诉大家会议中所提到的专业术语等等。。。

    关于这个，我建议大家去培训一下 六色帽子 的会议培训。

    http://www.baidu.com/s?bs=%BB%E1%D2%E9+%C6%DF%B8%F6%CB%BC%CE%AC%B5%C4%C3%B1%D7%D3&f=8&wd=%BB%E1%D2%E9+%C1%F9%C9%AB%C3%B1%D7%D3&n=2

    接口不规范

    月影同学说做个接口平台，这个觉得不错。哈哈，让大家对这个接口提出建议和反馈。至少可以在一个项目中尝试。

    如果好的话，可以做成一个大的开放平台。

    我自己的总结

    从我的角度看，发现现在团队所有的问题比解决问题更困难。

    这需要和团队成员沟通，也需要你自己的观察，更需要的是你团队成员给你的信任。没有信任你什么也做不了。

    我其实很想了解其他产品线的同学们的开发方式，解决某些问题的方法。

    但很多公司是没有这个机会给你的，其一是因为你每天都只关心下一天干什么，其二是你不知道负责人是谁，你只能厚着脸皮和对方聊一下这个问题。

    如果我们有一个比较好的平台，使得我们有良好的沟通和反馈机制的问题。这个平台既可能是程序，也可能是部门之间长时间培养出来的默契与规范。

    那我想这是大象跳舞的前提了。

    说易做难。没有银弹，只有实践才是适合自己的。目前这些正在实践去解决这些问题。

    如果说这里提到的问题你也有，而且能提醒你。这篇文章至少已经有点作用了，呵呵。

建议继续学习：

1. 阿里巴巴离职DBA 35岁总结的职业生涯    (阅读：18113)
2. 开发与研发    (阅读：10654)
3. 如何成为一名黑客    (阅读：9495)
4. 程序算法与人生选择    (阅读：8025)
5. 给想当程序员的大二学生的建议    (阅读：7722)
6. 学你妹的计算机！    (阅读：7056)
7. 给实习生的建议    (阅读：6138)
8. 技术人的发展路线总结    (阅读：5710)
9. 降级论    (阅读：5464)
10. 如何成为一名优秀的web前端工程师（前端攻城师）？    (阅读：5464)