第章产品管理与软件开发

第5章　产品管理与软件开发　Product Management vs. Engineering

定义正确的产品与正确地开发产品

如果说成功的产品是真实用户需求与现阶段可行性方案的结合，那么产品经理与开发团队之间（合作）的关系的重要性自然不言而喻了。

产品经理负责定义产品方案；开发团队最了解哪些产品构思是可行的，他们负责产品的开发与实现。作为产品经理，你很快能体会到，只有与开发团队融洽合作，才有可能开发出合格的产品；否则等待你的将是一段漫长、难挨的日子。

形成合作关系的关键是双方承认彼此平等——任何一方不从属于另一方。产品经理负责定义正确的产品，开发团队负责正确地开发产品，双方相互依赖。你要求开发团队完成任务，必须先取得他们的认可，确信为了达到产品质量标准必须这么做；开发团队也要留给你足够的空间，设计有价值、可用的产品。

产品管理和软件开发相互促进。开发人员可以帮助产品经理完善产品定义。别忘了，他们最清楚你的产品设计是否可行。

开发人员帮助产品经理完善产品定义的方式有如下三种。

1. 让开发人员直接面对用户或顾客，体会用户的困惑和疑虑，了解问题的严重性，这样好点子常常会随之而来，譬如，可以邀请一名开发人员参加产品原型测试。

2. 向开发人员了解最新的技术发展动向，讨论哪些新技术可以用到产品里。开展头脑风暴，看看目前已实现的技术或即将实现的技术能不能解决手头的问题。

3. 让开发人员在探索（定义）产品的初期阶段参与评估产品设计，协助策划方案。产品经理常犯一类错误，即完成产品定义后，便扔给开发团队，置之不理。这样做只会贻误协调需求与可行性的最佳时机，等到发现问题时，为时已晚。

同样，产品经理也应该配合开发人员的工作，方式如下。

1. 产品经理只定义满足基本要求的产品（参见第20章）。产品经理应该意识到，自己要定义的不是最终产品，而是满足基本要求的产品。只有这样，产品管理与软件开发之间才能形成良好的互动。

2. 一旦产品进入开发阶段，要尽可能避免修改产品的需求和设计。虽然有些事情超出你的控制范围，导致项目波动是不可避免的（开发人员也能理解），但是千万不要在此时尝试突发奇想的点子。

3. 产品开发阶段难免会产生诸多问题，比如，用例丢失，用例设计考虑不周全等，这很正常，最优秀的团队也避免不了。产品经理应该迅速采取行动，在维持产品基本功能、尽量避免修改的原则上，拿出解决方案。

我经常鼓励出色的开发人员尝试产品管理工作。我告诉他们，如果产品没有市场价值，那么无论开发团队多么优秀也无济于事。很多优秀的产品是程序员抓住用户需求，自己创业研发出来的。放宽眼界不仅仅有利于开发人员自己的职业发展，也有利于产品、顾客和公司。

如何与异地的开发人员沟通？

如今产品经理与开发团队各处一方的情况很常见。如果开发团队不在你身边，沟通和执行的难度将进一步加大。提高与异地开发团队之间的沟通效率，我有三条建议。

1. 开发团队距离越远，语言、文化、时差带来的沟通难度越大。如果产品经理不确定开发什么样的产品（或者反复改变想法），异地开发团队就只能疲于奔命，白费力气。这简直就是一场灾难，丝毫不亚于医生开错药方。

我将在第18章讨论把高保真原型作为产品说明文档基础的重要性。如果你与开发团队相隔很远，无论是讨论产品文档的内容，还是讨论修改产品设计，一定要借助高保真原型进行交流。阅读文档毕竟不轻松，如果文档是非母语的，或者阐述不清楚，那沟通效率就更低了。

2. 我们很容易发现和解决本地开发团队里出现的各种冲突（比如，两个管理者给出相互抵触的指导意见)。异地开发团队则会发生很多意想不到的情况，往往过了好几个月才发现问题，因此，必须有人在本地负责与异地团队的协调工作。这并不是说所有沟通工作都必须经过此人，而是应该明确异地开发团队只接受他的命令。这项工作可以由本地的项目经理、资深开发人员或者其他主管担任。

3. 如今商业沟通手段很丰富，除了电子邮件和即时消息外，还有视频会议可供选择。尽管如此，当面交流的优势依然不可替代。每个季度，产品经理至少应该前往异地与开发团队见一次面。面对面交流有助于改善（合作）关系，提高沟通效率。此外，交换人员也是一种有效的沟通方式，可以让主程序员来本地与产品经理共同工作一段时间，或者让产品经理到异地工作一段时间。

如果是与印度外包团队合作，由于时差的原因这种合作会让人觉得非常惬意。每天早晨上班时，对方的项目进展已经摆在面前。你可以用白天（对方的夜晚）检查、测试代码，反馈信息，显著缩短项目的循环周期。

请注意，如果是在异地开展与产品原型相关的工作，由于循环周期非常短（一天迭代好几次），你必须随时准备处理对方的问题，投入更多的精力。

另一种解决异地开发问题的方式是在异地聘请产品团队。这种趋势正在兴起，我相信它会被更多的公司采用。

关于业务外包

我合作过的所有公司都或多或少有业务外包，但是效果参差不齐。我认为造成效果不佳的原因是多方面的，比如，产品开发流程有问题，或者存在语言、文化差异，但是根本症结在于选择业务外包的初衷不对。

外包不是为了节约成本，而是为了实现合理的人员配置。所以才要超越地理位置的局限，雇用另一个州/区，或者另一个国家的员工，实现最佳组合。

硅谷的生活成本越来越高，雇主支付给普通员工的薪水远不够他们的生活费。愿意长途通勤来硅谷工作的外地人毕竟有限。为了聘用优秀的员工，你不得不另寻他法。

好在硅谷以外还有很多优秀人才。我曾有一支优秀团队，团队成员分布在瑞典、印度，以及美国的硅谷和波士顿。我们当时开发的平台支持两千万的用户，如果没有这些来自不同国家和地区的精英协助，这个项目不可能成功。

我很喜欢MySQL这家公司，他们多年来一直贯彻虚拟团队的理念。表面上，公司的两个总部位于硅谷和瑞典，但是他们的产品团队分散在世界各地。他们是虚拟的团队，充分利用分布在全球的顶尖数据库人才和系统软件高手的力量。虽然管理分散的团队不容易，但我相信如果MySQL是一家集中式的公司，他们不可能取得今天的成就。

正如二十世纪八十年代制造业被迫外迁一样，现在有些工作也逐渐从硅谷消失，例如，客户服务和测试。技术研发也开始出现类似的趋势。日益普遍的情形是软件架构师、测试经理、产品经理、设计人员留在公司总部，其他团队成员要么集中在异地某处，要么分散在全球各地。

选择业务外包的关键是要挑选有能力的员工。很多管理者不明白这个道理，得知相同工种的员工在生产效率上存在着二十倍的差异时，他们表现得异常惊讶。你认为哪种团队更好——由五位精英组成的异地团队，还是雇用十五个平庸的本地人？提高生产效率产生的价值可以轻易超过雇用本地员工节约的成本。从这个角度来看，聘用居住在高消费城市的顶级程序员是划算的。

如果你下决心发包业务，希望你是基于正确的原因——为产品团队寻找合适的人选，而不是仅仅为了节省一点儿小钱。

程序员想重写代码？

产品经理最担心听到开发人员这样抱怨： “不能再增加功能了！我们得停下来重写代码。代码库一团糟，就像纸糊的老虎，根本应付不了持续增加的用户。我们维护不下去了！”这一幕在很多公司上演过，现在依然在不断重演。1999年eBay遭遇这一幕时，公司濒临崩溃的情形超出所有人想象。Friendster几年前也发生过这种情况，当时他们正在向MySpace开放社交网络用户。网景与微软展开浏览器大战时，也发生过类似的事情，最后的结果大家都知道。事实上，没几家公司能渡过难关。

一旦公司陷入这种困境，开发团队往往沦为替罪羊。这类问题通常是由产品管理失误引发的，比如，产品经理一直迫使开发团队满负荷工作，开发尽可能多的功能。所有软件架构都存在功能极限，如果忽视这个事实，一旦系统越过崩溃的临界点，就会造成无法挽回的结局。

如果重写代码，用户就无法看到产品的任何改进。你可能认为重写代码至多也就几个月，但是实际时间无一例外要多得多。你只能坐在一旁，眼睁睁看着用户投奔竞争对手，而这个时候，竞争对手恰恰在不断地改进产品。

如果你还没有遇到这样的情形，未雨绸缪很有必要。你需要预留一定的技术能力， eBay称为余量（headroom） 。很多因产品迅速膨胀产生的问题都与扩展规模有关，余量意味着避免触及技术能力的上限，为用户数量的增长预留空间，为事务增长预留空间，为新增功能预留空间，保证产品的技术构架能够满足团队的要求。

与开发团队合作应该遵循以下原则：在产品管理上为开发团队预留20%的自主时间，让他们自由支配。开发团队可以利用这些时间重写代码、完善架构、重构代码库中有缺陷的部分，或者更换数据库管理系统，提高系统性能，避免“需要停下来重写代码”的情形发生。

如果你的糟糕处境已经初现端倪，就应该拿出至少20%的资源进行调整。我担心有些团队连20%都不愿意拿出来。如果你已经身陷重写代码的困境，说明公司危在旦夕，这里给出一点建议供你参考。

第一，针对开发团队确定的产品修改目标制订切实可行的计划和时间表。通常，有经验的开发团队估计的开发时间八九不离十，但是重写代码是例外，因为多数团队没有重写代码的实际经验，估计往往过于乐观。你必须审时度势，仔细检查每处细节，确保计划切实可行。

第二，只要有可能，最好把重写目标分成几大块，实现递增修改，让用户感受到产品的改进，哪怕会因此把九个月的工作时间延长至两年，也一定要采用这种方式。重写代码时，保证让用户看到功能的改进——即使会占用少则25%，多则50%的开发资源——对保持产品（尤其是互联网产品）的市场占有率至关重要。

第三，由于开发用户可见功能的资源有限，必须谨慎选择正确的产品特性，确保产品定义的正确性。

eBay起死回生后，我们发誓绝不重蹈覆辙，马上开始新一轮的代码重写，把危机甩在身后。事实上，由于发展迅速，eBay已经重写了三次代码，最后一次采用了完全不同的编程语言和架构。开发团队花了几年时间，大规模地改写了几百万行代码，同时在不影响用户群的情况下，开发了大量新功能。这是我知道的最惊心动魄的中途重建网站的故事。

临渴掘井不如未雨绸缪，为防患于未然，别忘了预留20%的余量。