【猎云网（微信号：ilieyun
）】9月3日报道（编译：冬冬）
如果Lou Montulli为现代软件工程师留下至理名言的话，恐怕Steve Jobs或者Elon Musk之类的大师都要靠边站了。他会引用美国诗人的名句：
我广阔无边、包罗万象。
自从担任Netscape首席工程师几十年来，Montulli见过很多创始人转型成为公司CEO，而产品经理成为名副其实执行产品规划的人员。但是就开发产品这一领域来说，他发现分工更细致，更专业。
作为一个工程师，Montulli俨然成为开发人员眼中的博学大师，为人景仰。他推出的作品耐用、创新，堪称工程界的完美之作。Montulli研发了两个早期的网站浏览器Lynx和Netscape。此外他还推出了cookies（储存在用户本地终端上的数据）以及最早用来直播的Fishcam。他对互联网的贡献奠定了互联网元素的基础，比如SSL、Javascript、CSS都顺势而来，所有这些都是他和Netscape团队其他成员的心血。在成为连续创始人之前，他还担任Shopping.com和Shutterfly的工程领导。
他认为不论以上哪个角色，要想扮演好，都受到创新驱动文化的启发，这也正是他在新公司JetInsight努力培养的企业文化。在这次独家采访中，Montulli为我们剖析这类文化，并且解释了该类文化培养的所需元素。成功的核心就是分工不同的工程师，他们能够跳出各自的管辖区域创建产品。这种文化的培养对于任何创企建立自己工程团队的公司大有裨益。
分担问题，而不是一味开发产品功能
如果说建立创新驱动文化有其关键所在，那就是不断的尝试让更多的人参与解决问题，而不仅仅是增加产品功能。这看上去是无足轻重的小事，但却影响深远。Montulli表示：“这就好比给你的员工七巧板还是空白油画布，尽管两个都能构出一样的风景，但是过程和结果却是天壤之别。前者参数已经设定好，唯一的挑战就是执行和分配；而后者规划、解决问题的过程和结果一样需要创新思维，有很大的发挥空间，这样一来你就能更贴近问题本身。”
全新的PM角色
尽管产品经理的概念广为人知，Montulli准备介绍另一种PM，那就是问题解决大师。他说道：“这不是正式的头衔，但是这恰是我希望我的公司能够招纳的工程师类型。我拿自己的亲身经历来举例，当初Lynx刚刚成立的时候，我一手包揽所有事情，不光是产品本身，还得处理相关的各种问题。我不得不身兼多职，不仅亲自回复所有的邮件、包裹，还要研究产品的编程、管理。长此以往就习以为常了。”
对于刚刚起步的创始人来说，身兼多职是家常便饭，但是如果有新成员加入，他们能够复制你之前的思维模式的话，那么奇迹就会发生。Montulli表示“当我们最初成立Netscape的时候，我们这个小团队一心想要创造价值连城的产品。我们对分配任务没有异议，每个人各自负责大工程的部分区域，但是我们反对流水线分工的方式。我们每天都在寻求发现更多问题，然后我们就会想出很多新奇的解决方法，不仅解决了原先的问题，还提出了用户暂未遇到或者思考的新问题。”
“当工程师们加入我的团队，他们会发现等待他们的不是功能的开发，而是问题的解决。比如说我们不会把用户界面的实体模型图片发给工程师，告诉他按样开发功能，我们会提出一个问题。用户需要追踪每日开销，他们目前使用纸和收据记录，但是期待有更佳的方法。”
当工程师担任创新者的角色
“首先，如果你的工程师们担任产品经理的话，能够大大减少他们与研发员之间缓慢的交流过程和激烈的火花碰撞。否则，你们碰到的问题还会引发额外的讨论：‘你确定你想要用这种方式？你为什么要这样做？让我们开个会来讨论一下，好吗？’”
PM和工程师角色的合并不仅能够避免费时的交流，更重要的是能够给工程师自主解决问题的机会。Montulli说道：“我曾经有过一些最原始，但却极具影响力的想法，后来都一一实现。从cookies到网页浏览器中，我尽早发现了需求，并且思考可能的解决方法。很多信息都在PM和工程师的交流之间被遗漏，不仅是准确率还有一些技术上的小细节，甚至是创新点都被疏忽了。”
要真正成为一个创造者，工程师必须学会利益共享，风险共担。Montulli 说道：“如果工程师要求产品能够照顾客户的需求，那么开发员就必须探索如何建立更适合用户的产品而不是一味地开发下一个功能。这种转变直接影响了编程。工程师并没有硬生生地将功能转交给用户，而是亲手递上，这种方式更具亲切感，而且会让顾客满意。”
“工程师自身使用的产品一般都比他们为用户设计的更加优良，因此只要他们更多地挖掘用户心理，他们设计的产品就能更适应市场的需求。与顾客见面能够帮助工程师了解不同的消费群体，这些消费群体使用的产品可能并不为他们日常生活所用。”
这里有一些细节，关于JetInsight在工程师与客户访问方面是怎么做的：
入职时，工程师们要轮流去观察和学习，最关键的是要明白客户对产品的第一印象如何，要怎样才能让客户试着去尝试我们的产品，以及工作流程是怎么样的。
季度访问时，工程师应该在客户身上下足功夫，哪怕这要花一整天。在这些时间里，工程师应该熟悉客户的好恶，并看着他们使用产品。
用户的记录工具：“每周我们都会用FullStory去记录客户是怎样使用产品的。工程师要去听听别人的销售电话和演示，这会对他们有所帮助，并会告诉他们一个公司里销售与其它部门之间的关系。”
一个成功的创造者必须在客户身上花时间，哪怕占有产品开发的时间也无妨。
Montulli承认与客户交流并不是每个工程师的强项，但要打造绝佳的客户体验，这方面的交流就不必可少了。“如果他们和客户的交流很糟糕，那就在下次交流时让另一名工程师和他一起参与。最不济，他们和可以在事后和同事们交流去了解这个客户的观点看法。人无完人，但这一点起码要达到。”
增加信息共享度，而不仅仅是交流
创新文化想要创造的产品，在开发过程中管理和设计缺一不可。在独立解决问题时，每个人之间需要协调。“作为一个领导人，当你允许你得工程师自由解决问题时，你就放弃了绝对控制权。在这种模式下，管理就相对来说比较无力。”Montulli说道。“我们不会选择混乱的管理，也不会选择死板的金字塔式管理，我们要的是一种相对无摩擦的状态，并且能把你正在忙活的事情告之每个人。这意味着创造者会与利益相关者会同舟共济。”
举个例子，最近JetInsight工程师正在解决一个和飞行员有关的问题。“FAA通过限制飞行时间，并记录两趟航班之间的间隔来限定飞行员一次能飞行的距离。这些复杂的规则每个飞行员都必须遵守。”Montulli说道。“我们就是要记录这些规则，并在飞行员将要违规的时候提醒他们。结果证明这是个大问题，这需要大量的数据输入，包括飞行训练以及其它相关的因素”
这个工程师想出了一些办法，并与内部人员进行了探讨，并收集了信息反馈。这个过程非常快，通常只有几个小时，随后他就给客户建立了早期模型。“在花时间去建立一个原型之前，工程师们以及他们的同事对这个问题提出了多种可能的解决方案，他们不仅是在讨论，并展示了不同解决方法具体会产生什么样的影响。几个小时过后，如果有了创造者觉得合适的方案，那么他就把原型做出来。如果没有，就重新回到绘图阶段。这个过程会让整个团队更团结，大家可以自由发表想法，但相对来说整个过程就要慢很多。”Montulli说道
这个例子中，这个工程师与同事反复提出了多个解决方法，而其中最佳的方法就会被制作出来。“这位工程师将飞机的具体规格共享给了团队的每一个人。这就是共享的效果。交流只能告诉别人你已经知道的东西，而共享会让别人发现你没发现的东西。”Montulli说道。
当信息共享解决不了问题时，领导层应该出来发挥作用。对于小公司，可能就是联合创始人；对于中型公司，可能就是产品部或设计部的副总裁。“说明白点，工程师们不可能想干什么就干什么。设计部或产品部的领导人应该把握好有哪些问题需要解决，并不断地去解决当前最重要的那些。在JetInsight，我会分享所有我知道的，有关我们正在进军的市场信息，比如我们想要获得的客户以及这些客户在将来可能面临的问题等。”Montulli说道。这有在这样的背景下，创造者们才能相信自己正在解决的问题非常重要，并且与公司息息相关。
创新驱动文化的告诫
这种创新驱动文化可能在小创企里可行，但在大公司里也许就要发生变化。“正如最纯粹的民主曾存在于雅典和斯巴达，但这并不意味着它在任何地方都适用。随着你公司规模的扩大，每个成员都变得更专业化，他们往往都只专精于解决某一类问题。这也是为什么我在一个20多人的小团队时成功构建了这种文化。在那之后，不论从管理还是执行的角度，这种文化都难以维持。”
公司越大，主要设计人就越要花精力在产品和功能上。“这就类似四重奏到交响乐之间的转变。因为这越来越复杂，新增加的元素越来越多。这也是为什么我们要花更多的注意力去协调不同的创造团队，越庞大的团队就越难去协调。”Montulli说道。
一个方法就是让解决类似问题和设计类似功能的工程师聚到一起。“通过把这些类似的问题汇集起来，你可以减少他们之间频繁的交流。你就是要让他们做到，在这样的背景下，他们不需要开口，就能让别人理解自己的意思。”Montulli说道。“工程和问题解决上运用模块化处理会着实增加人们独立工作的能力和效率。正如随着Netscape的发展，我们要让公司模块化运作才能增加效率。”
把上述讲的都践行起来
创新驱动文化就是通过将大问题分工成小问题让工程师们去解决，从而去建立更好的产品。那些多才多艺的工程师在这种文化中会如鱼得水，他们不仅敢于挑战传统管理方法的权威，又乐于去和客户交流，因此他们会感觉自己受到了重用，并参与到产品构建中。这种模式适合创企，随着公司规模的扩大，需要进一步地去协调。
