1704234006
08. 以上还只说了狭义的功能测试 ，性能测试 、压力测试 怎么办？大众没法帮你模拟10万人同时做某个操作。还有，自动化测试 谁来做？
1704234007
1704234008
09. QA ——质量控制相关的事情还没说呢。
1704234009
1704234010
10. 其实，这个做法接近于UAT （用户接受度测试），也有人叫验收测试 。经常由产品经理代表用户做（当然，有资源最好让用户亲自来），不是找Bug，而是看产品是否满足用户需求、设计是否符合用户认知，等等。
1704234011
1704234012
11. 这事儿很好，有条件都做吧。但更多的目的是找个理由和用户互动，而不是找Bug。
1704234013
1704234014
看了这一段，相信大家对测试工程师也心生敬仰了吧。
1704234015
1704234016
设计与运维环节
1704234017
1704234018
研发生产的主干环节是开发、测试。在其前后，还有设计和发布这两个环节。下面讲一下这两个环节对应的两种主要角色。
1704234019
1704234020
设计
1704234021
1704234022
先说说设计师的分工，主要有以下四种。
1704234023
1704234024
►交互设计： 关注的是产品与用户互动的过程，具体的输出为产品线框图、低保真原型等。
1704234025
1704234026
►视觉设计： 更加注重用户界面看上去的美观、好用，具体的输出为视觉稿、高保真原型等。
1704234027
1704234028
►工业设计： 主要对应产品里的硬件、实物、包装等的设计。
1704234029
1704234030
►服务设计： 更加关注线上、线下的服务流程，以及如何提升用户体验等。
1704234031
1704234032
在需求细化的环节中，产品经理和设计师要并行作业，所以两者任务的界限也有点模糊。如果用一句话来区分他们，就是产品经理负责结构化思维，设计师负责形象化表达。
1704234033
1704234034
接下来以著名的“尼尔森十大可用性原则”其中两条为例，进一步感受一下设计师到底在做什么。
1704234035
1704234036
原则一：所有动作都可视
1704234037
1704234038
所有动作都是可以及时获得反馈的。比如在PC互联网时代，你的鼠标悬停在一个超链接上或单击一个超链接都会看到实时的视觉反馈。
1704234039
1704234040
原则二：对用户操作容错
1704234041
1704234042
帮助用户从错误中恢复，容许用户在操作后反悔。例如，在你误删除邮件后还可以做undo操作。
1704234043
1704234044
发布
1704234045
1704234046
发布相关的概念属于运维的范畴。因为有了丰富的云服务，现在互联网业务的运维工作轻松很多。在团队不大时，甚至可以交给开发工程师代劳，而等到产品发展壮大后，运维工作就非常关键了。运维工作要负责维护并确保整个服务的高可用性，还要不断优化系统架构、提升部署效率、优化资源利用率以提高整体的ROI（Return on Investment，投资回报率）。目前大规模集群已司空见惯，如何管理好成千上万台服务器上的服务，成为运维工程师面临的最大挑战。
1704234047
1704234048
移动互联网时代，发布的工作还包括“发包”。发包是把安装包提交给各种应用市场。俗话说，iOS怕审核，Android烦渠道。具体地说，iOS程序提交到苹果App Store审核之后，总会碰到奇奇怪怪的拒绝理由，关键是每次拒绝审核人员只提出一个问题，改好后再次审核时才提下一个，时间就这样一天天过去，效率非常低下。而Android程序，有太多各式各样的应用商店，发包工作不胜其烦。
1704234049
1704234050
以上提到的都是把产品“做出来”的岗位，但只列出一些线索。研发生产的过程中，还会有些其他岗位的人员也介入进来，比如客服要熟悉新产品、准备帮助文档，市场运营要准备商业上的发布方案等，这属于广义运营的内容，到第09章再说。
1704234051
1704234052
7.4.2 如何做一个让Ta们讨厌的人 本章的最后，继续聊聊在研发生产过程中与他人沟通和配合时的注意事项。下面以与技术人员沟通为例，分享一些简单易学、通俗易懂，能让产品经理在各种配合方眼中迅速变得很讨厌的做法。
1704234053
1704234054
开始实施之前
1704234055
[
上一页 ]
[ :1.704234006e+09 ]
[
下一页 ]