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

第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%的余量。


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

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 打赏
    打赏
  • 扫一扫,分享海报

参与评论 您还未登录,请先 登录 后发表或查看评论
©️2022 CSDN 皮肤主题:精致技术 设计师:CSDN官方博客 返回首页

打赏作者

HustPM_Dapeng

一杯快乐肥宅水就能满足

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值