如何组织一场好的brownbag Session
写在前面：
昨天老板让我写一个brownbag session ，我接到任务很是懵逼，啥叫brownbag
后来去网上一搜，这个词的来源是：国外的食物经常都会放在一个牛皮纸袋里，大家聚餐的时候就会一起分享来吃，所以brownbag 其实可以理解为分享的意思，简言之，老板想让我出一个培训计划，指导各方用户上线后顺利使用系统，于是我又去搜了一通相关的借鉴，摘出一些有用的
不定期摘读一些对自己有用的文章，用于分享学习和记验收录，无其他商业用途
互联网产品上线前，做些什么——产品、开发、测试的视角
互联网产品上线前：产品经理、开发、测试该做些什么？这是近些天，我们的项目团队在做的事情。写一些心得吧，来自腾讯、YY、迅雷的工作实践汇总，有些杂乱，不一定全对，供大家参考，有兴趣的同学可以整理一下。
产品经理的自查
- 需求文档是否补充完整？例如交互图、设计稿是否已经更新；
- 客服文档是否已经提交并进行客服培训；
- 每个功能特性是否有确定的输入、处理、输出？
- 是否有异常结果的处理？
- 页面跳转是否有给出明确的地址？
- 产品文字是否已检查？（包括但不限于页面文字、广告语）
- 发布策略是否已考虑，灰度发布是否在文档中有说明？
- 已有功能、标识的改动，在其他模块的呈现，是否覆盖完整？
- 如涉及现有产品的老功能删减，需要和客服沟通；
- 需求特性是否区分用户身份？
- 未实现的需求是否在文档中注明？
- 除了正常状态，异常条件下的兼容措施是否考虑？
- 统计需求是否明确提出？数据是否正常上报？
草拟了一个产品经理的自查表，供大家参考。
QQ20151019100042
模块表格的字段如下：
- 页面
- 功能点
- 用户状态
- 输入（操作）
- 处理
- 输出（结果）
- 异常处理
- 跳转
- 文案
- 统计需求
- 备注与问题
产品运营的自查
- 产品的冷启动是否已经准备完毕？
- 内容运营的更新机制是否已经确认，并进行部署，是自动更新，还是人工更新，有无更新机制和审核发布机制？
- 产品活动运营是否已经进行规划？是否有专人负责？周期性的活动，是否已经有运营模板？
- 产品数据是否已经正确上报？是否通过数据测试？数据报表是否已经就绪？
- 新媒体运营的账号是否已经建立，是否有专人负责？是否有内容规划？内容获取途径是否已经建立？
- 渠道运营是否已经建立，例如应用商店的合作，SEO，ASO的计划和实施；
- 用户消费充值的路径是否顺畅？数值是否准确？
开发自查
- 每个功能是否全面自测？边界/异常参数的确认和验证（如果有以类似lib方式对外提供被调用API）
- 是否进行高危函数扫描？
- 是否进行安全漏洞扫描？
- 是否有内存泄漏的检测和结果（如果是C/C++代码）？
- 不必要log是否删除了，以及log信息是否清晰完整详细？
- 统计上报是否完整？
- 代码在编译环境已编译通过？
- 是否有socket泄漏？
- 是否影响其他相关模块功能表现？
- 自身系统压力是否已评估？
- 后端支撑系统负载变化是否已评估？
- 是否对业务流量有影响？
- 转测试文件和ARS单是否完整
- 产品体验是否通过？体验反馈的问题是否已修复？
- 是否需要灰度，采用何种灰度方案
- 是否需要提前发布配置？
测试人员自查
- 产品通过测试的发布标准建立；
- 用例编写是否100%覆盖需求；
- 是否及时有效地修改自动化用例(CGI的修改涉及到自动化用例部分的内容) ；
- 用例编写是否有考虑异常逻辑&优化(如web前台,性能等)的情况 ；
- 是否有认真阅读提测邮件的测试重点,有针对性的编写用例；
- 是否有发起用例评审,并根据评审意见修订用例；
- 测试Bug是否进行有效性跟处理,直至闭环；
- 版本发布时是否确认Bug单的状态为已关闭或已挂起,否则不允许发布 ；
- 测试报告是否及时发送；
- 开发完成后，页面重构人员把版本内涉及的文件提取并入测试环境原版本内 ；
- 提供相关ARS单信息给开发pm提单操作；
- 配host到测试环境，确认代码版本正确，确保无bug，确保页面准确还原设计稿；
- 测试过程中，会提出为改善用户体验以及细节的缺陷，测试人员会通过XXXX系统提交bug单发送给相关责任人；
- 评估名下bug单的优先级和处理时间点，统一时间处理；
- 处理完成后，及时更新bug单的状态；
- 代码是否上传XXX系统？
- bug状态是否已更新？
- 遗留bug是否已经过PDM、PM、TE评估？（致命及严重bug需要测试leader和总监确认）
- 发布时间和内容是否符合发布规范（例如版本中包含后台server发布，晚上高峰期需要经过审批才能发，日常版本不能包含cgi等）
- 配置文件的修改是否恢复；
- 外网运营环境版本是否与测试环境一致；
- 影响到其他模块表现的，发布前对方测试人员是否已做功能验证并确认ok
- 版本发布后是否留守进行外网验证,发出验证报告后才离开
- 外网验证的Bug是否有跟进处理(严重Bug要跟进及时处理,其他Bug阶段性的跟进处理)
互联网产品领域，可以笼统地分为前台产品和后台产品。前台产品即是C端的产品，后台产品可以笼统地概括为各种管理系统。
我们常说的C端产品价值在于满足用户需求、提升用户体验，后端产品完全不同，第一要义是对业务的支持和提升，通过业务操作和数据的线上化，来标准化业务管理流程、提升业务运转效率，以及发掘数据的价值，进而在各环节影响到公司的成本和收入。
这对于主营业务为电商、O2O等任何形式交易的公司来说尤为重要。四五年前，当互联网还处于线上产品为主的阶段，业内会说有很多公司不注重后台。但现在互联网各行业各类线下服务早已层出不穷，都9012年了，如果还有认为后台产品的价值小于产品的公司，可以倒闭了。
我本人在小公司做了一段时间的公司内部支持系统，总结出了一部分关于后台产品的个人经验。
本文分为六个部分，按后台产品设计过程的顺序，分别是后台产品有什么用、有哪些后台产品、业务需求怎么对接、产品本身怎么设计、如何上线和如何跟进使用情况。
这是第三篇，主要写上线和使用情况跟进相关的内容。这两块比较偏向于项目管理范畴，很多规模不是很大的互联网公司，产品经理都会承担一些项目管理职责，比如研发进度跟进，上线的过程，以及各种和业务方的协调。其实本人并不太擅长项目管理相关的事情，因此这篇只是把我把经历过的项目过程和想法描写一下。
五、后台产品的上线方式
5.1 为什么后台产品上线要单独拿出来写
我刚开始做产品，接触到所谓的上线，就是研发把代码提交了，发个邮件通知下相关人员就行，用户端的再写个版本更新说明，应用市场提交下安装包。后来当我第一次做涉及到系统整体更新的项目时，我的老大一直在跟我说，梳理流程做功能不难，怎么上线才是难点，哪个版本上，什么时候上，如何培训，这些都要提前搞清楚，弄不好就会做完了上不去。然后我去人人都是产品经理等网站上找内容参考，结果写上线过程的一篇都没有。接下来我只能一边向老大和有经验的研发求助，一边摸索着上线大项目，最后虽然有点延期，总算是上线成功了。
所以说后台产品的上线本身值得单独拿出来写。它和用户端产品上线不一样，用户端上线需要做的事情是发版。大版本和1.0版本，更多要考虑的是上线后运营层面的事情。
至于后台产品，如果只是上线一些小需求或者个别不复杂的页面，那自然发个邮件通知下就可以。
如果是1.0版本，或者系统整体迁移更新的项目，那产品上线等同于一块业务的上线，产品经理在上线的前后需要在和业务方的配合下，推进整个业务开始使用。
如果上线事项没安排好，那好一点的结果就是上线后没人用，大家继续用原来的方式，坏一点的结果就是没法用造成公司业务停滞。
本文就写一个我所经历过的大项目上线的整个过程。
5.2 大版本上线标准
大项目上线前的第一步，是确定上线标准。
后台产品的产品迭代过的思路很不同于用户端产品。用户端产品是MVP原则和小步快跑，1.0版本的方向是做最简单的部分，上线后快速验证。而后台产品因为业务本身涉及面广，各个业务模块之间的耦合性很高，因此从宏观层面来看，1.0版本必须是一个主要业务流程闭环的大系统，达到能支持核心业务流转的标准。如果只做部分模块上线，流程未闭环，操作了流程前半截，后半截没了，那显然没有意义。
在此基础上，互联网行业的后台产品又不能像传统软件企业那样，一次性交付一个大系统，做完完事没有迭代。那样不仅研发周期超长，解决问题时效性慢，而且上线后一旦有问题，影响面非常广，会牵扯到很多流程。
因此上线的标准需要做到流程闭环和小步迭代的平衡，在微观层面上，一些不重要的业务流程没必要全部做，只需要预留能手动操作的入口，有个办法让业务都能进行下去。
具体操作本身不需要设计得太精细，同样是实现必要的操作，满足业务的流转即可。一些查询统计类的需求，先实现明细数据的查询功能。1.0版本的操作不会很方便，只能上线让业务方正式用起来后，再对操作细节的体验进行优化。毕竟使用起来后，有些具体操作上的问题才可以看得到，迭代起来更有针对性。
以上就是后台产品1.0版本的上线标准了，核心流程闭环全覆盖，非核心流程预留操作入口，具体操作实现功能但不需要精细。
此外，如果是系统整体迁移更新的项目，除了以上标准之外还有一个条件：原先旧系统中已实现的业务模块，在新系统中同样需要实现。也就是说更新后的新系统1.0版本的功能涵盖范围会比较广，一定大于等于旧系统。如果因为涉及到业务模块过多、开发周期太长，一部分稍微不重要的业务流程可以先照搬旧系统，如果需要调整可以等新系统上线后再改。
举个例子。我曾经参与过一个电商/O2O的供应链系统整体迁移更新的项目。项目的背景是旧版系统功能很简单，而且很久没有迭代，很多模块已经不符合实际业务，因此开发新版系统，实现业务流程每个环节的支持。1.0版本的上线范围当时想了很久，最终的方案如下：
首先，供应链的底层逻辑：库存结构，和核心业务：采购、调拨（订货）、订单消耗，作为四个核心模块，开发过程分为四个子版本，并根据实际业务情况进行系统流程重构，实现完整的流程闭环，上线后替代旧版系统的业务操作。然后，旧版本缺失的流程模块，比如售后退货，以及非核心的盘点、买断等操作，因为不影响系统迁移，新系统1.0版本中先不做，通过额外开放一个特殊出入库的模块实现这些业务。至于数据统计、出入库记录查询类的页面，通过加导出数据明细的功能实现，提供数据让业务方手动查询，后期再针对性地做统计报表。
不过当时这个尽可能缩减的1.0版本，还是因为前期准备不足，花了4个月的时间开发才上线，算是踩了一个大坑。
5.3 上线事项
分享一下我所经历的一个后台产品迁移更新项目，整个1.0版本的上线过程。我把它分为了12个步骤，1-4是产品本身的事情，5-9是上线前项目管理方面的事项，10-12是上线的时候要做的事情。因为是系统迁移，所以相对比从零上线1.0版本要复杂一些。
具体事项大致如下：
0）需求对接、产品设计、研发、测试这些事项。在大项目中，将具体业务模块分为多个版本，进行这几个阶段，直到达到上线标准的版本测试完毕；
1）操作说明文档的编写；
作为业务培训的资料，在培训之间需要完成。想要写个全面又可读性强的操作文档，是件很花时间的事情；
2）业务方验收；
将新版系统和操作说明文档给到业务方的对接人，让业务方进行验收。尽量用真实的数据进行测试，所有流程模块都需要试一遍。我们需要通过观察并与业务方确认三类问题：
第一是否有流程模块漏下导致没有闭环。在系统迁移更新的过程中，会出现一些在旧系统中可以进行、或者无需进行的操作、数据查询，在新系统中无法进行，设计的时候没有考虑到的情况；
第二类是对操作效率、体验影响比较大的功能交互问题。让业务方用真实数据跑一遍之后，一些我们自己想不到的问题，以及实际操作过程中很关键的小细节，业务方使用后都能看出来。当然这里业务方会提出一大堆问题，有些重要、影响面高的是需要上线前完成的，有些相对不重要、有临时解决方案的，是可以上线后再优化的。
第三类是是否还有bug。
3）遗留流程模块补全和操作细节优化；
将上一步梳理出来的问题，安排小版本进行优化。
这两步的耗时可能会比较长。我当时的项目，在之前制定的上线标准版本到最终上线，中间还做了两到三个小版本，都是在补全一些必要的功能；
4）关联系统的配合调整；
一个大的后台系统的某些业务模块会和其他系统相关联，比如电商领域的供应链系统、订单系统、统计系统之间有不少业务和数据有强关联。在系统上线前，这些关联的系统需要配合进行调整，包括规则上的和数据结构上的。这一步也和前面一样，需要梳理出哪些调整是现在就要完成的，哪些是可以上线后再改的。
调整之后，在最后上线的一步一起上；
5）人员、事项的安排；
这一步开始可以正式安排上线前的事宜了。与业务方的负责人一起确认上线事项，包括时间、涉及到的人员、培训计划等。安排好后发邮件；
6）业务方培训；
将系统详细的规则和操作方式，给业务方具体的使用者进行培训，让所有人知道新系统怎么用。前面的业务方是直接对接的负责人，这一步则是下面具体使用的人员。有些公司这一步会有业务方进行，不过一个比较大的系统的培训，还是由产品经理直接进行比较合适。如果操作人有其他城市分公司的，需要进行视频培训。
这两步会遇到的问题是业务方人不全。业务方有些人可能会很忙、不关心系统的事情、不看邮件、在其他城市，会导致我们反复通知、大规模培训后，他们有人还不知道新系统的事情。如果是在我们力所能及的范围之外，只能让业务方的负责人帮我们做一些强制规定；
7）人员角色和权限分配；
在系统上配置每个角色的权限，和所有相关人员的角色；
8）大范围内测；
培训和权限配置完成后，让业务方使用系统的人员进行内测，用真实数据跑一遍核心流程。内测的目的主要有两点，一是让业务方熟悉操作，二是再看一遍，有没有比较重要的，上线前需要优化的交互操作。
这一步比较耗费人力物力。如果系统没那么复杂的话，可以跳过。
要注意的是，截止到这一步，所有业务操作依旧需要继续在旧系统中进行；
9）基础数据的配置；
支撑业务进行的一些基础业务数据，需要在上线正式使用前完成配置，比如供应链系统的仓库库区库位结构、库存类目结构等。如果是之前从没配置过的数据，需要业务方的对接人预先完成配置；如果是系统迁移过程中旧系统已有的数据，可以直接进行迁移；
10）关闭旧系统的功能和权限；
这一步开始是正式上线的事情。选一个月黑风高的夜晚，提前通知业务方，几点后不能再进行业务操作。然后在到点的时候，关闭旧系统的权限和功能，让那些没听到我们通知的业务方无法再进行操作；
11）数据处理；
通常新系统和旧系统的底层数据结构逻辑是不一样的，所以这一步就是把旧系统中的业务数据统一迁移到新系统中的过程。这一步需要研发人员通过脚本跑数据，如果数据量大，那么就需要一直奋战到半夜，到一两点是很正常的。我们产品虽然帮不上忙，但尽量陪着研发一起加班；
12）正式开始使用；
上线成功，第二天早上，业务方正式开始使用新系统。我们需要从一大早开始帮着回答各种问题，跟进处理各种功能和数据上的bug，新的一轮业务推进事项就此开始。
以上主要针对的是系统迁移更新的过程，如果是新产品的1.0版本上线，事项也大致是这几项 ，上线本身的过程没有那么麻烦，旧系统权限关闭和数据处理这两步就没有了；
如果是一个正常系统的版本迭代，上线一个大的业务模块，那么培训、内测相关的事项不需要那么细致，上线本身的过程也没那么麻烦。但存在新规则上线后会影响旧规则和操作的情况，需要考虑上线这个时间节点前后，业务方具体操作的影响。
六、后台产品的使用情况跟进
6.1 为什么要跟进使用情况
我们做用户端产品，每个版本上线之后，接下来要做的事情是通过数据验证是否达到了预期的效果，观察用户反馈是否满足了用户预期。后台产品也一样，同样需要观察上线后是否达到了这个版本的目标、效果。
后台产品对公司业务本身的相关性很强，某种程度上来说，后台产品的上线可以代表一个业务的上线。新的模块上线后，只有通过具体的使用情况，才能判断我们做的东西与业务的贴合度、和对业务的帮助有多大。
我最开始做后台产品，做完后发个邮件给到业务方，然后就结束了，业务方有没有在用，到底怎么用的，只会等他们来找我。要是不找我，我就以为一切顺利。后来我的老大开始问我，你的产品上线后是否真正解决了问题，要是老板来问你做了这些的业绩是什么，怎么回答。
于是我逐渐开始做上线后各种跟进擦屁股的事，以及开始制定指标或者阶段目标，并根据业务方的使用情况复盘。后台产品做了有没有用，有哪些之前没想到的问题，都需要我们自己去跟进观察，甚至亲自使用后才能发掘。
后台产品从业务方的实际操作中获取到反馈还是比较容易的，在具体的功能和操作的层面上，上线后可以直接通过沟通、观察，了解到业务方对新功能的接受程度，找到需要优化的点。
此外，有些公司对后台产品也会有类似于KPI的数据指标考核。当我们做一个目标是对业务进行提升的后台产品后，老板肯定想知道，做了这个东西对业务到底有什么帮助，这个时候就需要通过数据指标来验证后台产品。
在实际业务过程中，我们需要根据需求本身的不同目的，制定不同的方案，来检验后台产品需求是否实现了目的。
6.2 要跟进验证哪些事情
上线一个新的后台产品或新模块后，我们需要跟进业务方，验证如下几个事情：
1）业务方有没有开始用；
这是很关键的。事实上我们上线一个新模块后，业务方不用是个比较常见的情况，我见过的原因就有好几种，比如流程设计得不对、和实际业务不符，比如功能复杂、业务方看不懂不会用，比如为了某些管理的目的增加了他们的工作量，导致他们不想用，再比如业务方自己没定好业务计划，产品上线后业务本身迟迟不启动，等待。
这个时候得先想办法，通过功能的调整、优化，甚至是通过与管理层沟通，让产品被使用起来，因为使用起来后才能谈别的，不然这产品就白做了；
2）是否有bug或者数据不准确；
一般bug在测试的时候就能解决了，但有一些需求是需要上线后，用真实的业务数据才能看出问题来，比如统计类需求。这时这些测试环节的事情也是我们需要上线后验证的；
3）实际使用的效率，业务方的满意度；
这是使用层面的问题，对方对我们的产品使用起来是否满意，是否存在不通畅的流程和不好用的功能，导致操作繁琐、效率降低。有时候一些细节的筛选、搜索功能，会直接关系到整个业务效率。通常上线一个新的产品或者模块后，很多细节操作问题需要不断优化迭代才能达到最佳。
这一点是相对易于理解、容易操作的，直接找业务方沟通，了解他们的问题和实际操作场景，或者亲自按照业务方的操作方式，走一遍流程即可。
4）从业务角度看实际业务的运作情况；
在业务对接环节中，我们已经对产品如何满足业务的运作设计了方案，在上线后，需要通过验证业务本身的运作情况，观察是否符合我们设计的方案，业务本身是否有变化或没有对接清楚的地方，以及很关键的，是否有我们遗漏、没预料到的情况出现。通常以业务支持为目的的后台产品，上线后都需要验证下实际业务情况。
举个简单的例子，我做过一个采购系统的产品上线过程，对接设计的是主业务流程，上线后发现有两个部分没有按照系统规则使用，一个是某些量很小的第三方合作的业务，和主流程有些出入，导致有些环节流程走不下去；另一个是找供应商售后换回的部分，没有采购价格，导致这部分库存的成本为0。
这些特殊情况有些是业务对接过程中有遗漏，有些是预留的需要后续再改。业务方能有办法在系统上通过其他方式操作，但是和我们设计的初衷不一样，会造成系统的数据不准确等情况，因此有必要尽快调整。
这一点，除了业务方的反馈之外，还需要去现场看业务方的实际操作，以及观察系统中的真实业务数据，来发现一些隐性的问题。
5）以对业务本身提升为目标的，通过数据统计验证效果；
前面写到，当我们做一个目标是对业务进行提升的后台产品后，老板肯定会需要一个数据指标来衡量产品对业务的效果。上线一段时间后，通过对比指标的变化，来验证是否达到了我们预期的目标。
后台产品对业务的提升，常见的有通过精确匹配、智能计算、高效业务流转，来提升效率、达成率、准确率这些方向，比如一项业务的完成时长，订单的取消率，仓库的缺货率等。需要制定的数据指标就是实际业务的指标。
举个例子，假如公司要做个客服工单系统，业务形式是用户下单后通过呼叫中心第一时间响应沟通，旨在通过客服工单的分派机制来加快订单的响应时间，保证5分钟内响应，以此提升用户体验。那么订单响应时间就是业务数据指标。产品上线后，通过前后响应时间的对比是否提升，和超过5分钟响应订单的比例是否下降，来验证产品对业务提升的效果。
不过后台产品的数据分析会相对困难一些，因为指标通常比较隐性，不像用户端产品那么明显，而且一个业务指标的提升不一定完全是由产品本身带来的。以我个人的观点，后台产品是否要定指标要根据不同产品具体分析。
三到五点，分别对应了在第一节里写到过的后台产品三个目标：提升操作效率，标准流程管理，和业务驱动提升。根据产品的目标，选择对应的验证方式。
希望读完的你也有所收获
参考原文：
http://www.woshipm.com/pd/1914697.html
http://www.woshipm.com/pmd/220190.html
