《启示录：打造用户喜爱的产品》第一部分 人员5 产品管理与软件开发

Posted 2022-04-13 普通网友

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

 
定义正确的产品与正确地开发产品
 
        如果说成功的产品是真实用户需求与现阶段可行性方案的结合，那么产品经理与开发团队之间(合作)的关系的重要性自然不占而喻了。
 
        产品经理负责定义产品方案：开发团队最了解哪些产品构思是可行的，他们负责产品的开发与实现。作为产品经理，你很快能体会到，只有与开发团队融洽合作，才有可能开发出合格的产品；否则等待你的将是一段漫长、难挨的日子。

【笔记】建议产品经理在交付给开发之前先让技术经理或者项目看一下需求，先从总体把下关。举个最简单的例子，最为产品经理，我们肯定是希望系统能快速响应并查询出结果，比如你可能希望一下子查询出10万数据，然后支持关键词搜索、筛选、排序、分页、导出等功能，但是开发人员会很明确的告诉你，从性能角度来说会很难实现。

当然在开发过程中，还会存在各种各样的细节问题，比如界面进去的默认值，甚至查询时间范围的起止时间，以及展示形式，甚至字体颜色和字号……这些都是在实际开发会遇到的。产品经理不是神，一个人的精力也是有限的，需求文档不可能详尽的描述细枝末节，这些只能在开发过程不断完善。
 
        形成合作关系的关键是双方承认彼此平等——任何一方不从属于另一方。产品经理负责定义正确的产品，开发团队负责正确地开发产品，双方相互依赖。你要求开发团队完成任务，必须先取得他们的认可，确信为了达到产品质量标准必须这么做；开发团队也要留给你足够的空间，设计有价值、可用的产品。
 
产品管理和软件开发相互促进。开发人员可以帮助产品经理完善产品定义。别忘了，他们最清楚你的产品设计是否可行。
 
开发人员帮助产品经理完善产品定义的方式有如下三种。
 
1.让开发人员直接面对用户或顾客，体会用户的困惑和疑虑，了解问题的严谨性，这样好点子常常会随之而来，譬如，可以邀请一名开发人员参加产品原型测试。【不太现实，毕竟实际生产中开发人员的排期都非常的紧迫，很难腾出时间来跟用户去对需求】
 
2.向开发人员了解最新的技术发展动向，讨论哪些新技术可以用到产品里。开展头脑风暴，看看目前已实现的技术或即将实现的技术能不能解决手头的问题。
 
3.让开发人员在探索(定义)产品的初期阶段参与评估产品设计，协助策划方案。产品经理常犯一类错误，即完成产品定义后，便扔给开发团队，置之不理。这样做只会贻误协调需求与可行性的最佳时机，等到发现问题时，为时已晚。【在我看来，这是错到离谱的骚操作，需求文档不能直接丢给开发，务必要拉着项目经理or技术经理，和所有的开发一起开会把需求从头到尾过一遍】
 
同样，产品经理也应该配合开发人员的工作，方式如下。
 
1.产品经理只定义满足基本要求的产品(参见第20章)。 产品经理应该意识到，自己要定义的不是最终产品，而是满足基本要求的产品。只有这样，产品管理与软件开发之间才能形成良好的互动。
 
2.一旦产品进入开发阶段，要尽可能避免修改产品的需求和设计。虽然有些事情超出你的控制范围，导致项目波动是不可避免的(开发人员也能理解)，但是千万不要在此时尝试突发奇想的点子。
 
3．产品开发阶段难免会产生诸多问题，比如，用例丢失，用例设计考虑不周全等，这很正常，最优秀的团队也避免不了。产品经理应该迅速采取行动，在维持产品基本功能、尽量避免修改的原则上，拿出解决方案。
 
        我经常鼓励出色的开发人员尝试产品管理工作。我告诉他们，如果产品没有市场价值，那么无论开发团队多么优秀也无济于事。很多优秀的产品是程序员抓住用户需求，自己创业研发出来的。放宽眼界不仅仅有利于开发人员自己的职业发展，也有利于产品、顾客和公司。
 
如何与异地的开发人员沟通?
 
        如今产品经理与开发团队各处一方的情况很常见。如果开发团队不在你身边，沟通和执行的难度将进一步加大。提高与异地开发困队之间的沟通效率，我有三条建议。
 
        l.开发团队距离越远，语言、文化．时差带来的沟通难度越大。如果产品经理不确定开发什么样的产品(或者反复改变想法)，异地开发团队就只能疲于奔命，白费力气。这简直就是一场灾难，丝毫不亚于医生开错药方。
 
        我将在第18章讨论把高保真原型作为产品说明文档基础的重要性。如果你与开发团队相隔很远，无论是讨论产品文档的内容，还是讨论修改产品设计，一定要借助高保真原型进行交流。阅读文档毕竟不轻松，如果文档是非母语的，或者阐述不清楚，那沟通效率就更低了。

【笔记】新冠疫情期间，居家办公，异地开发，我们团队依旧运作的很好。主要就是因为需求文档是图文并茂的，所有的内容都是高保真的原型图和需求说明。通过讨论组、语音、及时会议等讲解和沟通，虽然可能没有面对面沟通效果好，但是最终的产品还是比较满意的！
 
        2.我们很容易发现和解决本地开发团队里出现的各种冲突(比如，两个管理者给出相互抵触的指导意见)。异地开发团队则会发生很多意想不到的情况，往往过了好几个月才发现问题，因此，必须有人在本地负责与异地团队的协调工作。这并不是说所有沟通工作都必须经过此人，而是应该明确异地开发团队只接受他的命令。这项工作可以由本地的项目经理、资深开发人员或者其他主管担任。

【笔记】在开发过程中，务必形成以产品经理为核心的需求文档唯一出口，有任何变更一定要通过产品经理，而且必须落实到需求文档中，通过技术经理或项目经理，把变更的内容准确无误的传递给每一个人。
 
        3．如今商业沟通手段很丰富，除了电子邮件和即时消息外，还有视频会议可供选择。尽管如此，当面交流的优势依然不可替代。每个季度，产品经理至少应该前往异地与开发团队见一次面。面对面交流有助于改善(合作)关系，提高沟通效率。此外，交换人员也是一种有效的沟通方式，可以让主程序员来本地与产品经理共同工作一段时间，或者让产品经理到异地工作一段时间。
 
        如果是与印度外包团队合作，由于时差的原因这种合作会让人觉得非常惬意。每天早晨上班时，对方的项目进展已经摆在面前。你可以用白天(对方的夜晚)检查、测试代码，反馈信息，显著缩短项目的循环周期。

请注意，如果是在异地开展与产品原型相关的工作，由于循环周期非常短(一天迭代好几次)，你必须随时准备处理对方的问题，投入更多的精力。
 
另一种解决异地开发问题的方式是在异地聘请产品团队。这种趋势正在兴起，我相信它会被更多的公司采用。
 
关于业务外包
 
        我合作过的所有公司都或多或少有业务外包，但是效果参差不齐。我认为造成效果不佳的原因是多方面的，比如，产品开发流程有问题，或者存在语言、文化差异，但是根本症结在于选择业务外包的初衷不对。
 
        外包不是为了节约成本，而是为了实现合理的人员配置。所以才要超越地理位置的局限，雇用另一个州／区，或者另一个国家的员工，实现最佳组合。

硅谷的生活成本越来越高，雇主支村给普通员工的薪水远不够他们的生活费。愿意长途通勤来硅谷工作的外地人毕竟有限。为了聘用优秀的员工，你不得不另寻他法。
 
        好在硅谷以外还有很多优秀人才。我曾有一支优秀团队，团队成员分布在瑞典、印度，以及美国的硅谷和波士顿。我们当时开发的平台支持两千万的用户，如果没有这些来自不同国家和地区的精英协助，这个项目不可能成功。
 
        我很喜欢mysql这家公司，他们多年来一直贯彻虚拟团队的理念。表面上，公司的两个总部位于硅谷和瑞典，但是他们的产品团队分散在世界各地。他们是虚拟的团队，充分利用分布在全球的顶尖数据库人才和系统软件高手的力量。虽然管理分散的团队不容易，但我相信如果MyS0L是一家集中式的公司，他们不可能取得今天的成就。

正如二十世纪八十年代制造业被迫外迁一样，现在有些工作也逐渐从硅谷消失，例如，客户服务和测试。技术研发也开始出现类似的趋势。日益普遍的情形是软件架构师、测试经理、产品经理、设计人员留在公司总部，其他团队成员要么集中在异地某处，要么分散在全球各地。
 
        选择业务外包的关键是要挑选有能力的员工。很多管理者不明白这个道理，得知相同工种的员工在生产效率上存在着二十倍的差异时，他们表现得异常惊讶。你认为哪种团队更好——由五位精英组成的异地团队，还是雇用十五个平庸的本地人?提高生产效率产生的价值可以轻易超过雇用本地员工节约的成本。从这个角度来看，聘用居住在高消费城市的顶级程序员是划算的。
 
        如果你下决心发包业务，希望你是基于正确的原因——为产品团队寻找合适的人选，而不是仅仅为了节省一点儿小钱。

【笔记】招一个给力的外包至关重要，普通的人员可能只负责机械的开发，技术水平也一般，但是如果是个有能力的外包，那么你收获的真的不是一点点差距。他会跟你深入讨论需求，会根据你的需求去尝试理解你的设计，给出几种不同的理解，针对不同的理解给出合理的解决方案。我有一个这样的外包，真的觉得很满足！

程序员想重写代码?
 
        产品经理最担心听到开发人员这样抱怨：“不能再增加功能了!我们得停下来重写代码。代码库一团糟，就像纸糊的老虎，根本应付不了持续增加的用户。我们维护不下去了!”这一幕在很多公司上演过，现在依然在不断重演。1999年eBay遭遇这一幕时，公司濒临崩溃的情形超出所有人想象。Friendster几年前也发生过这种情况，当时他们正在向Myspace开放社交网络用户。网景与微软展开浏览器大战时，也发生过类似的事情，最后的结果大家都知道。事实上，没几家公司能渡过难关。
 
        一旦公司陷入这种困境，开发团队往往沦为替罪羊。这类问题通常是由产品管理失误引发的，比如，产品经理一直迫使开发团队满负荷工作，开发尽可能多的功能。所有软件架构都存在功能极限，如果忽视这个事实，一旦系统越过崩溃的临界点，就会造成无法挽回的结局。
 
如果重写代码，用户就无法看到产品的任何改进。你可能认为重写代码至多也就几个月，但是实际时问无一例外要多得多。你只能坐在一旁，眼睁睁看着用户投奔竞争对手，而这个时候，竞争对手恰恰在不断地改进产品。
 
        如果你还没有遇到这样的情形，未雨绸缪很有必要。你需要预留一定的技术能力，eBay称为余量(headroom)。很多因产品迅速膨胀产生的问题都与扩展规模有关，余量意味着避免触及技术能力的上限，为用户数量的增长预留空间，为事务增长预留空间，为新增功能预留空间，保证产品的技术构架能够满足国队的要求。
 
        与开发团队合作应该遵循以下原则：在产品管理上为开发团队预留20％的自主时间，让他们自由支配。开发团队可以利用这些时问重写代码，完善架构、重构代码库中有缺陷的部分，或者更换数据库管理系统，提高系统一胜能，避免“需要停下来重写代码”的情形发生。
 
        如果你的糟糕处境已经初现端倪，就应该拿出至少20％的资源进行调整。我担心有些团队连20％都不愿意拿出来。如果你已经身陷重写代码的困境，说明公司危在旦夕，这里给出一点建议供你参考。
 
        第一，针对开发团队确定的产品修改目标制订切实可行的计划和时间表。通常，有经验的开发团队估计的开发时间八九不离十，但是重写代码是例外，因为多数团队没有重写代码的实际经验，估计往往过于乐观。你必须审时度势，仔细检查每处细节，确保计划切实可行。
 
        第二，只要有可能，最好把重写目标分成几大块，实现递增修改，让用户感受到产品的改进，哪怕会因此把九个月的工作时间延长至两年，也一定要采用这种方式。重写代码时，保证让用户看到功能的改进——即使会占用少则25％，多则50％的开发资源——对保持产品(尤其是互联网产品)的市场占有率至关重要。
 
        第三，由于开发用户可见功能的资源有限，必须谨慎选择正确的产品特性，确保产品定义的正确性。
 
        eBay起死回生后，我们发誓绝不重蹈覆辙，马上开始新一轮的代码重写，把危机甩在身后。事实上，由于发展迅速，eBay已经重写了三次代码，最后一次采用了完全不同的编程语言和架构。开发团队花了几年时问，大规模地改写了几百万行代码，同时在不影响用户群的情况下，开发了大量新功能。这是我知道的最惊心动魄的中途重建网站的故事。
 
        临渴掘井不如未雨绸缪，为防惠于未然，别忘了预留20％的余量。

---

分享干货和实战经验，更多精彩内容和读书笔记，大家可以关注和查看专栏《启示录 打造用户喜爱的产品》读书笔记​​​​​​​