• Feeds

  • 新兵训练营的故事

    受到《打造Facebook》一书的启发,以及对改善环境的美好期望,春节后几个同事都信誓旦旦的表示要搞一个团队内的新兵训练营,尽管大家的出发点及理解不太一样,但没有影响积极前行的信心。

    最开始是由L同学在前期张罗,L同学的核心办营理念是打造具备综合素质的人才(原话不一定如此),因此需要一个丰富的课程体系,让新人从无到有掌握应有的技术技能。即使有一些具备丰富经验社招的同学不需要部分内容,L同学的观点是这些课程可以根据对象进行裁剪,类似大学的学分制。

    由于一些原因,大旗转移到另一个T同学来主导,T同学更偏精英团队营造,认为在老的群体中有一些不好的做事方式及技术体系,需要从新人开始全部隔绝,“需要一个全新的开始”。T同学也开始小范围的训练营试点。

    这时候出现了一些办学观念的碰撞,比如“是否只考虑校招不含社招”、“是否课程目的主要为传授知识点或经验”、“是否不考虑团队现在的,通过新人创建一个理想的团队”等之类问题。

    L同学在QCon大会上跟新兵训练营可仰望的Harry交流了一些细节,Facebook新兵训练营的做法

    1. 了解公司公共的技术体系(共性的,帮助以后更好的了解兄弟部门业务)
    2. 公司文化及业务介绍
    3. 推荐及撮合部门,介绍新人去合适的业务团队
    上述说明在《打造Facebook》一书中有详细描述。

    经过一段时间的讨论,都已经基本达成共识,认为较为可行的新兵训练营的思路是通过案例讨论的形式,了解并分析目前技术体系现状,鼓励改进及创新的想法,辅助传递核心团队文化。新兵训练营每一堂课程除了新人之外,还有各个领域的核心员工及技术主管,新兵训练营的重要的思路是让新人了解目前体系,融入现有的团队文化。

    新兵训练营倾向于讨论没有标准答案的技术案例,甚至倾向选择有争议性的话题,以便讨论过程中了解争议的前因后果,以便更好的理解各种技术及业务场景。

    最新的新兵训练营由Q同学在主导,第一期新兵训练营,讨论开放平台的技术组成部分、以及搭建中可能遇到的技术问题。

    结网随想

    最近看了图灵的《结网 – @改变世界的互联网产品经理》修订版,这本书是糗百创始人王坚编著,书中有马化腾前言的光环,也有不少不错的案例分析。仅从技术角度谈一些心得。

    1、产品经理是否需要懂技术 (P10)


    现在产品经理群体里面部分群体不懂技术,确实技术不是必要条件,但也看到不少缺乏对技术理解,而对产品未来视野存在瓶颈的情况。在大多情况下,对技术有更深理解的产品经理应该更具备竞争优势。

    2、创新者与模仿者的问题 (P26)

    一些创新者与模仿者的案例
    AltaVista -> Google
    Napster -> iTunes
    VisiCalc -> Lotus 123 -> Excel
    Apple Newton -> Palm Pilot -> BlackBerry
    IBM PC -> Compaq -> Dell
    Double Click -> Google AdSense

    这个世界上,为什么模仿者摘了这么多果子,唐。道奇发现创新者往往缺少兼备技术原件和管理能力的领导者。

    大部分团队里面,缺少具备技术远见和管理能力的综合人才。技术人员关起门来做事情的占多数,综合能力的培养和实践欠缺、视野不够、看问题抓不住本职等不足影响了技术舞台的大小。而这些团队里另外一部分具有管理能力的人员,心思通常又放在专业或者业务上,毕竟在大部分环境,如按任正非提倡屁股面对老板终究是风险极大的。多方面因素导致技术精英的缺失。

    3、授权与发挥空间 (P85)

    《理解漫画》中有这样一个观点,图片越抽象,读者理解起来就有越大的发挥空间。
    如果你想造一艘船,不要抓一批人来搜集材料,不要只会他们做这个做那个,你只要教他们如何渴望浩瀚的大海就行了。 -圣埃客絮佩里,小王子作者

    引申这一点,团队领导者在传达愿景时候有两种思路,一是完全直白的指示,团队直接按指示执行即可。另外一种思路就类似上面的,给得是一个有很大理解空间的愿景,根据不同的团队背景,也许团队会做出让人惊喜的成果,这样的环境也更适合有想法的人去翱翔。

    4、危机管理 (P100)


    互联网在线业务出了故障或问题,如何跟用户沟通反馈上面已经提到。缺的是一个企业从上到下塑造这样的文化。

    团队内部出了问题不应该遮掩,道理都懂,真正做到这一点的团队不多。敢于直面问题、将问题坦诚的公开并透明的进行进展公示,是衡量一个团队及领导者是否值得信赖的一个重要标志。

    5、其他

    另外还有一些不错的观点,因为没有更深思考,就不再赘述,有意读者可以关注以下部分。

    • 倾国倾城的案例,P66
    • 价值3亿美元的按钮,P124
    • 平台拉动的分析,P154
    • 20%的特性可以满足80%的用户,但是都不是同样的20%才是问题,P176
    • 压力管理,P195

    6、建议

    本书总体感觉操作层面描述较多,如果能够透过这些技巧、案例引导读者一起思考深层次的问题就更好了。对于新的产品经理而言是本不错的书。

    谈分享、创新与开源

    2013来了,又过了一年,以下是元旦假期的一些随想

    分享

    2012写的东西偏少。一方面由于关注的问题相对宏观问题多一点,导致在细节方面能分享的并不多;而大部分宏观问题也跟具体工作相关,不适合分享。宏观领域的粗浅理解容易导致对具体领域的忽视。比如“互联网系统架构近五年技术缺少实质性变化”的断定,会让所有对细节的关注趣味索然,进而也加剧了减少在具体问题上的分享。另外一方面由于工作岗位的原因,需要在管理方面消耗一些精力(当然这些精力投入有它另外的价值),导致专注一个领域研究及阅读时间减少。同时作为一个管理者,需要顾虑未经深思熟虑的表态可能会造成误解,尽管博客只是个人随想的表达,但无法避免被当做一种管理者或者官方的声音去解读。

    以上种种,对于一个习惯写一些东西的人并不是一个非常好的状态,但是这些是未来需要克服的困难。并且在新的一年,也打算关注及分享一些新的技术领域,先留个记号。

    创新

    技术人员创新体现在运用技术来为产品产生更大的价值。比如在大部分开放平台中,用oauth2代替oauth1是一种创新,它在提升安全性的同时,也极大降低了开放平台使用门槛,并间接促使了开放平台领域的进一步繁荣。

    但是,技术人员的大部分群体还是工作仅局限在本职工作上,即怎么样按时按质的完成所分配上的任务,技术上的挑战并不算大。尽管如此,但是在大部分企业中,技术团队往往被视为整体瓶颈之一,比如对产品的质量及细节(包括稳定性、速度、体验等)的把控不足、团队的开发效率不够理想(体现到产品的迭代速度)、技术团队对于行业关键技术的掌握能力偏弱等。比如以上情况目前在移动开发领域比较普遍。而且由于行业由于更新迭代速度快,一些技术团队未能有效掌握所需最新核心技术,而导致产品开发效率变低(对于宏观管理者而言,这些信息通常被掩盖),极端情况下,这些缺乏更新技术方法的人员也可能成为阻碍产品创新的力量。

    对关键技术的把握及是否具备创新思维能力,是衡量当前创新型企业技术团队成熟度的标志。

    谈到团队创新能力,常规的金字塔型团队(即少数能力强的带领一群普通的)未必创新能力很强,也许倒金字塔的更好,一群能力突出的人在一起碰撞会更利于创新。

    今天看到南方周末2012/12/27期一篇文章《城市:创新的天堂》,部分摘录如下

    但是,West最有趣的发现来自那些不遵从“Kleiber定律”的数据。West及其团队发现大量的城市统计背后隐藏着另一个指数法则:所有与创造力和创新能力相关的数据,比如专利产生数、研发预算、超级多产的发明家数量等都遵从同一个指数法则。与“Kleiber定律”不同的是,跟创新有关的指数法则是正相关,而不是负相关。一个城市如果是另外一个城市规模的10倍,那么它的创新能力不只是另外一个城市的10倍,而是17倍。一个城市的规模如果是另外一个城市规模的50倍,那么它的创新能力就将会是另外一个城市的130倍。West的数学模型表明认为创造的城市打破了生物学意义上的生命模式:城市越大,产生思想的能力越强,速度越快,人均产生的专利和发明数量也越多。这就是所谓的“超线性缩放”现象。

    (此文应译自New York Times,A Physicist Solves the City

    开源

    开源社区已经运作多年,行业对于开源运动也都有各自深入的理解。补充一点看法,目前的业界环境下,技术转化为产品再经过运营得到用户认可,是一件门槛相对较高的活,因此对于一个小型团队,如果拥有一些对用户有所帮助的技术,这些技术直接创造价值还是存在一些机会问题,因此通过开源的方式或许可获得另外一种技术产生更大价值的方式。