分类：3000 项目与文档

关于敏捷|迭代的形象化解释——

李宽在《B端产品经理必修课》里，提出了公交模型。

Marty在《启示录》提出了火车模型。

这篇，我再给出个地铁模型，也许能让大城市每日通勤的从业者们更有直观感受。

先复习一下相关类比。

火车模型发布模式：以固定的周期持续发布产品，如果某项既定功能未完成，就落到下个周期发布。

公交模型：出行线路–>需求管理流程；发车间隔–>需求管理周期；到站时刻–>需求时间。

然后，我再说说地铁模型。

一趟车：一个迭代。

起点和终点站：一个迭代的开始与结束。

站点：一趟车按照站点顺序依次停靠，好比迭代的阶段节点，比如评审完成、编码完成等，背后是一个相对固定的，有时序的需求管理流程。

发车间隔：迭代周期，乘客多的时候，调度会增加车次。

乘客：一个个的需求点。他们有优先级，比如老人孕妇，上车后有更大概率可以有座位（享受更多的资源支持）。

到站时刻：某个迭代，每个环节有固定的时间点，如果需求错过了时间，本班车不会等，但可以坐下一班车。如Scrum之类的敏捷方法，对时间会严格把控，比如每周的周一上午干什么、周五下午干什么，更像地铁而不是公交车。

车厢/座位：比如女性车厢、照顾专座、商务座（如深圳地跌7号线），这是资源的优先级，用来匹配需求的优先级，乘客根据其特性、票价等，可以获取的资源不同。

快车慢车：在一个大的研发组织里，不同迭代的优先级，比如日本的地铁，同一条线路有每站都停的，有快速、有特快。此外，必要的时候会出现让车的情况。

上下客：不是每个乘客都是从起点上车坐到终点的，各个环节，都可能有上有下，需求也有在各个环节搭车的和变更的。当然，临时上的，估计是没座了，只能站着。

早晚高峰：乘客比较多的时候，我们虽然及时赶到站，但依然有可能挤不上这班车。更可怕的是，还没到目的地的时候，可能会被中途下车的人连带着挤出去……

末班车和头班车：地跌每天夜里都会停运，而对于研发，春节前后，或者阿里的双11前后，会有封网的行为，于是会出现没车可坐的真空期。

你还能想到什么类比？

__________

iamsujie，前阿里产品经理，写过《人人都是产品经理》、《淘宝十年产品事》、《人人都是产品经理2.0》，现在做创业者服务，『良仓孵化器』创始合伙人。

 

这次说说产品技术、团队、项目管理相关的话题。

今年初，我玩了一把最简 & 异地的团队，一位兼职设计师（做视觉+交互+前端）、一位兼职技术（服务端+Web）、一位iOS客户端开发，他们在北京，剩下的角色全是我，在杭州。

 

当时的体会，人少确实减少了沟通协调的损耗，但，异地不在一起办公的阻隔、兼职导致的“时差”问题（部分人晚上、周末才可以干活），更麻烦。而且，这样的团队有个前提——必须是成熟度很高、很职业的选手。你很难在本地一下子找齐，全职开干。

 

这两个月，又玩起另外一种，团队角色略多，集中办公，但大家的经验都不太丰富，多为1~3年，没经过专业训练的新手。一上来，花了很多时间跟大家一起定规矩，规矩一定要求，但一定不能复杂，下面分享一下这个简化的产品流程与项目管理方式，如图。

 

角色的简化：

根据事情、团队的现状，做合理的简化，这个还是挺考验经验的，必须见过分工很细的团队，然后理解每个角色是怎么一步步分化出来，设置的目的，才能做好。比如现状对于“小得（项目名称）”，我们的做法是：不区分交互和视觉，无专职测试而全民测试，无运维DBA等细分全部开发承担，前端还是单列出来，所以一共是四个角色：产品、设计、前端、开发。当然，对于最简团队，还可以再去掉一个，产品、设计、开发这三个角色是不可或缺的，注意，是三个角色，不一定是三个自然人。

 

流程的简化：

同样，需要见过更复杂的流程，知道每一步是为了防止出什么状况的，才能合理的简化。最低要求，四个关键节点，这些节点是除了产品技术团队、市场运营的关键人也要参与的，我觉得是没法再砍了。

立项会议：确定目的，为什么，做什么；

需求评审：确定怎么做（对于小于2周的小项目，可以和立项会议合并，总体时间控制在2小时以内）；

功能评审：简单的讲，就是在测试环境下演示一下产品，确定做出来的是不是团队要的（1小时左右搞定）；

发布上线：确定是不是用户要的，用户还要什么……获取反馈，形成闭环。

 

两个分支流程：

变更：一开始可以简化成某个人拍板决定，是否接受变更。

日常：即零散的小需求，只掌握一点，所有需求必须经过产品，不能运营直接找开发，确保产品经理知道所有的需求信息。

 

文档的简化：

几乎可以只有PRD、设计稿、代码三件套。其他都用看板与立会解决。然后，特别强调一个，沟通计划，绝大多数问题都是沟通问题。大家要约定好，是每天开会？线上选一个协作工具？写周报？……这个问题不解决，后面补课一定补得你不要不要的。

 

看板与立会的实际应用

 

研发项目过程中，我们发现还是最原始的看板和立会好用，先说看板里用到的基本元素——任务卡片，也就是一张便签。

 

任务描述：一个词+一句话（如果一个词可以讲清楚，可以不用一句话），比如前端同学写的一张“Detail页面制作”；产品同学的一张“后台订单管理需求细化”。

工时评估：对于2~4周的项目，精确到1~4小时的粒度比较合理，如果一张便签的工作量超过8小时，则需要分拆，这个评估，一开始不准确没关系，每天都会回顾，好好做肯定越来越准。

Deadline：据说Deadline是第一生产力，写明日期即可。

优先级：实际操作过程中，并没有写，当任务越多的时候，越需要。

 

三个角标算是个小创新：

左上表示延期，少量延期是正常的，也是允许的，但要监控。如果发现多数人出现大量延期，则说明计划制定不合理，需要调整，如果发现少量人出现大量延期，则更可能是个人问题，需要延期人自己加班赶上进度。此点团队要达成共识，让别人等、浪费别人的时间是可耻的。

右上表示突发任务，少量的突发是正常且允许的，但如果有大量突发，则说明计划不足，没有经验，或者有『外力』经常干扰项目进程。

左下表示持续任务，可以一直贴在Doing里，比如对产品人员来说的『处理用户反馈』，非持续任务都应该每天从Doing到Done。

右下角标备用，敏捷的基本思想就是方法论边做边优化，团队一起来。

多种颜色的卡片也可以灵活应用，比如我们现在只有4个角色，正好4种颜色——产品、设计、前端、开发。

 

有了便签，然后我们来制作看板。

    

横轴Todo、Doing、Done：

Todo里的是本项目内需要做还没做的事情，只需要明确便签的部分信息：

任务描述：可以概括，比如『手机版的设计』，特别是比较久以后要做的事情，在便签从Todo进Doing时拆分即刻，并废弃掉旧的便签。

优先级：结合工时评估一起，判断每天应该拿哪些便签进Doing。

工时评估和Deadline可以在便签从Todo拿进Doing的时候同步确定。

如果Todo里便签过少，则说明对未来要做什么没有计划，或者，说明当前项目进入尾声。

 

Doing里表示当天要做的事情，如果便签过少，或者工时加起来远远小于8小时，则说明工作安排出问题了，当然，通常一天平均算5~6小时是合理的。做得好的话，每天贴3~5张便签，有一些是必须要完成的，有一些是可以冲击一下的bonus。

 

Done里是已经完成的事情，随着项目的进行，越来越多，记得最后收集起来归档。

 

纵轴分角色，每个角色里再分不同人，在Todo阶段的便签，有些是只确定角色，不确定谁来做的，比如开发的任务『搭建测试环境』。

 

每日立会（叫立会，就是一起站着开会的意思）

每天固定时间，可以是早上一来，或者每天下班前，每周换人召集、主持。

今天做了什么，一边说一边把Doing里的拿到Done；明天要做什么，一边说一边把Todo里的拿到Doing。

会议时，每个人要特别关注需要互相配合，有前置依赖的任务。

 

还有些信息也可以写在看板上，比如当前项目的几个关键节点的日期（功能评审、发布上线），本周立会的主持人是谁（每周轮换），当前看板信息已经更新到哪一天等。

 

每个项目完成，也是会做一下回顾的，看看管理方法上有哪些“好的需要保持的；不好的需要改进的”。

 

Over，可能你也看出来了，里面有大量Scrum的本地化。

 

PS：此实践中提到的项目，是一个知识经验相关的企业服务，有兴趣的可以通过如下二维码关注。

—————————–

iamsujie，前阿里产品经理，写过《人人都是产品经理》、《淘宝十年产品事》，现在做创业者服务，『良仓孵化器』创始合伙人，『小得』平台创始人，『好产品平台』创始人。更多信息可以扫码关注。

我这是在用生命与金钱在淌路，给大家写失败案例啊~~~~~~~~~~

我们做的“好产品”，总算自己走完了一遍AppStore的上架，分享一些经验教训，总结就是一句话：四个拒绝与一个通过，嗯，和那部电影的名字挺像的。

 

看看过程，你就会发现，我们好低级……

 

第一次拒绝，2月20号

Information Needed

We began the review of your app but are not able to continue because we need a demo account to fully assess your app features.

Please provide demo account details, including passwords, in the App Review Information section for your app in iTunes Connect. Please ensure that the information you provide includes any data necessary to demonstrate the functionality of your app features.

低级失误，我们做了一个用微信号的邀请制，服务端有个开关，本来是打算审核的时候关掉，以后打开，结果忘关了……而且，也没提供邀请码。收到拒信后，几分钟就搞定了，但……只能等一周。

 

第二次拒绝，2月27号

10.6 Details

If we chose to log in with 微信, we were required to install 微信 before we could use your app. Apps should be able to run on launch, without requiring additional applications to be installed.

这是第一个问题，原因我们早就知道，是账号不能只支持第三方（如微信）登录，因为看到过有一些只能twitter登录的应用，所以还是想试一试。毕竟做一套自己的账号体系，对于我们的产品来说，短期内不必要，结果证实，2014下半年开始，严格了很多，那些只支持第三方登录的，通常都是很久没更新的App。

解决方案，我们提供了一个本地登录，当检测到用户手机没有安装微信的时候，直接用本机udid生成一个本地账号，后来证明这招有效。

 

We encountered connection issues during the review process. We had tried to connect repeatedly to your server on different times of the day, and on different WiFi and cellular networks, but to no avail. If the issue is due to server maintenance, please provide a time frame during which we can log in to your server.

第二个问题，又是完全的低级失误，服务器未续费，过年期间，大家没太注意，欠费的第一天，正好碰到审核，衰。

 

第三次拒绝，3月7号

2.1 Details

During review, your app crashed on iPad running iOS 8.1.3 and iPhone running iOS 8.1.3 when we: tapped QQ and QQ空间.

Bug，分享到QQ的特性，如果手机安装了QQ，则没问题，如果没安装，会闪退。

提交上去以后，自己已经测出来了，但抱着侥幸心理，没有撤回（不想重新排队），结果浪费了更多的时间，审核人员还是挺细的，而且，他们的手机上，几乎不会有任何其他应用，所以，你的App如果和其他应用有交互，一定要重点测试一下，没安装那些应用的场景。

这一次额外提醒我们，还有很多正常流程碰不到的情况要测试，如共享热点的时候，顶部有一条蓝色的，看看各个页面是否有异常；如低性能机器的情况，还好，我们最低只支持iPhone4。

 

第四次拒绝，3月14号

10.6 Details

Your app includes an update button or alerts the user to update the app. To avoid user confusion, app version updates must utilize the iOS built-in update mechanism.

 

如上图，升级检测不能用自己的，据说是苹果3月初的新规定，没有及时研究……还是要定期仔细看guideline啊。

 

第五次通过，3月22号

所以，终于可以做广告了么？大家已经可以在AppStore搜索“好产品”下载安装，就是那个橙色的大拇指，或者，扫这个二维码。

目标用户：产品经理出身的创业者、未来可能创业的产品经理（无关人士请闪开）

 

暂时还算公测期，很多功能不完善，所以邀请制，看到这里的同学，应该有办法搞到“邀请码”的（即已经在里面的任意用户的微信号），小白鼠们，欢迎各种方式给我反馈问题啊，：）

 

其他感受：

审核还挺规律的，就是太慢了，我们一般周末或周一提交，然后下一个周末有反馈；

最讨厌的一点，审核每次只告诉你一个问题就打回，然后就又是一周，对于我们这种没有专职测试的初创团队还是挺慌的；

还有两个让我们提心吊胆的坑：一是隐私政策，一开始没想加，被拒了两次以后怕了，网上搞了个模板加上了；二是“UGC”内容需要提供举报功能，一直担心这点，但还好，过了。

 

就这样。