文|xiaoxiao
几年工作下来，我越发觉得，做好一个产品，有太多可以共用借鉴的范式和模块，而每个模块，也大多有比较成熟的外部解决方案。撇开大公司不说，对于一个小型乃至创业团队，在初期必须要把全部精力投入到核心业务模型的建设上去，对于外围需求的处理，很难做到完善、健壮，往往后期要重构。
相反的，如果初期把精力都在完善、探索外围需求的解决方案，对时间、人力的损耗也容易积少成多，耽误时间。而这些外围需求，有些是单纯的功能层面的，比如登录注册分享，也有工具层面的，比如持续集成、协作、沟通工具。
所以我才写下了这篇文章。把我所知道的，一个产品（App为主，网站更多是辅助）从启动到成长所需要关注的方方面面，归纳下来，相信自己或者你会用得上。
团队工具
在开始一个新产品之前，让一个新团队能够正常运转往往是一个更困难的事。团队成员来自五湖四海，各自拥有不一样的价值观和工作流，如果不在项目开始的时候硬性的统一起来，那么迟早会在项目中散架。
需求&项目管理
首先，一个统一的需求管理平台至关重要。我在某银行里发现的最令我震惊的事情就是，他们的需求管理是用 FTP 共享的，而且一个需求只有实现了，才会放进 FTP 里做存档，在这之前都是 Word 文档到处传，没有版本管理的概念，因此需要三番五次书面确认。难怪银行的效率都极其低下。
一个正常的需求&项目管理平台应该能够让团队的每个角色的任务清晰呈现，并且可以快速反应出变化，而且不阻碍项目的信息流动。
- 产品经理规划撰写需求，根据情况变更需求；
- 设计师对需求进行设计并且标记完成可用的设计资源；
- 项目经理安排需求所属于的迭代，控制迭代的时间和进度；
- 开发参照需求进行开发，并且适时标记完成的需求；
- 测试参照需求撰写测试用例，并对完成的需求进行测试。
- 每一个需求都应该随着状态的变化在不同角色之间进行流转。
腾讯有内部研发的 TAPD，现在已经部分的对外产品化为 TAPD Lite 可以用。
更多的轻量级的产品有，国外： Trello、Basecamp、Jira、Asana，国内有Tower、Teambition、FengChe、Worktile。
还有一个例外，比较传统、重型的产品，禅道。功能比较全，但是 UI 丑。
缺陷管理
早先的缺陷管理更多的是以独立平台的方式存在，但实际上这会使得测试需要花更多的时间复制一套迭代、版本体系，所以现在的缺陷管理大多都和上述的项目管理平台在一起了。测试在上面录入从各个渠道收集到的 bug，分配给开发，并同样进行状态的流转。
在诸如 TAPD、禅道这样的传统型管理平台上，都包含缺陷管理模块。反而在上文中的轻量级的项目管理平台里，缺陷管理并不是非常容易做，简单的还好，复杂的设计到迭代、版本划归、人员间的流转就不容易了。
而更传统的解决方案如 Bugzilla 等太老旧，不建议考虑。
代码托管
对于开发团队最基础的东西，但在实际中也是大多数团队的软肋。许多观念传统的开发喜欢坚持自己习惯的 SVN 的代码管理方式，带来的分支创建极其麻烦，代码可视化审查门槛高以至于更少人愿意去做。
使用 Git 是走向现代的第一步，第二步是使用有可视化管理界面的 Github 或 GitLab。当然，还可以考虑更激进的云开发平台（包含了代码托管和管理以及更多功能），比如 Coding。
国内的开发对代码托管有一种天然的危险意识，认为托管到外部服务一定会被偷盗、偷窥或者丢失，这或许是源于对国内大厂的不信任。在湾区，更为流行的方式则是托管到 Github 的 Private Repo 或者企业账户，因为它更进一步的减少了代码管理服务的搭建和部署工作，并且大家一直以来都习惯这么做。
云服务＋CDN
Amazon AWS 推了这么多年，再加上阿里云的努力，国内大概再不入流的团队也知道要用云服务而不是自己买机器折腾机房了。虽然少不了备案的工作，但也可以轻松不少。
云服务细分的类型就很多了，传统的有云计算、数据库、存储和CDN，知名的服务商有 阿里云、美团云、腾讯云及新浪云，而比较新颖的还提供基于 Docker 的服务部署，参考 Docker 、Daocloud、云雀科技和云栈科技。
还有独立的 CDN 供应商，比如国外的 CloudFlare （好像已经进入中国了）和 Akamai，以及国内比较大的是蓝讯和网宿（虽然我个人对网宿的印象并不好，参考 App Store 在国内的体验）。
持续集成与分发
大多数初创团队在早期都会有意或无意的忽视持续集成，然而对于产品的改进，持续集成至关重要。曾经在银行的时候（我又来黑银行了），我发现一个版本只有在开发完提交测试的时候，产品才能装到手机上体验一下，而且其中开发做了任何修改，产品不知情，只能定期跑到开发桌面“让开发帮忙装一下新版本”，而那时候任何的体验修正、交互优化之类的需求变更都不可能来得及了。
合理的流程应该是这样：团队中每次有代码提交到主干或在每日特定时间，都应自动以最新代码编译一次出一个 app 版本，并上传到分发渠道上，如 TestFlight。这样产品、测试和其他团队人员随时可以安装并检查最新版本，即便在开发阶段。
传统的持续集成有 Jenkins/Hudson，自己部署自己配置，iOS 的话还有 Xcode Server 的 bot。但，云持续集成已经在逐渐流行起来，Travis CI、CircleCI 就是其中的典型。
内部分发渠道上，TestFlight 在 Apple 买了之后就不是那么好用。而对外的话，国外还有HockeyApp，国内 Fir.im、蒲公英 则是使用的比较多的分发渠道。
而将持续集成和分发渠道联系在一起，除了自己写脚本外，也有第三方工具如 nomad-cli 和 fastlane。fastlane 已经被 Twitter 收入囊中，维护更新都比较及时，覆盖的业务场景也比较全面，甚至还包括自动生成一个用于收集申请 TestFlight 用户账号的页面。因此知名的 app 独立开发者都在用，比如 Tapbot 的 Paul Haddad。
设计资源交付与共享
产品的设计过程相比开发流程是一个更原始更需要被革新的领域。据我所知还有小团队还停留在设计师用邮件传设计稿给产品和开发来沟通的阶段，在超过邮件附件大小的时候还得用上 U 盘，先进一点儿的也只是在用 FTP 或者网盘而已。也有好一点儿的，会用 SVN／Git 来确保版本管理，尽管对于设计流程来说这些都是极其不合适的工具。
这个领域的问题包括三个：版本管理、设计讨论 和 设计交付。
版本管理常见的是 Pixelapse，对设计师来说体验就像网盘。但区别是每一次保存的版本都会被记录下来，可以回滚、在线查看。不得不说大多数设计师都缺乏版本管理的习惯和意识。
设计讨论属于在版本管理上还要多一层，上传了设计稿之后，还要允许在线的修改、批注、讨论，在湾区比较多用的是 InVision。相比用嘴说，显然批注会更清晰且不会被遗忘。
设计交付领域虽然一直在改进，但还远远不足。最早是 Mac 上出现一款叫 Slicy 的 app 可以直接把 psd 文件里的图层自动切出来。后来 Photoshop 自己增加了这个功能，虽然大多数设计师还是不会用，担心自动切图的质量问题。而现在优秀的 UI 设计师大多都在转向 Sketch，一键切图解决了绝大多数切图问题。
另一方面，Zeplin 的出现则把设计师从标注的工作中解放出来，它支持团队内同步设计稿，和直接查看设计元素之间的尺寸、颜色等属性。同类的产品还有 Avocode 也不错。我记得以前在腾讯里，还要有专门的设计助理来负责切图和标注。而其实这些事都应该交给 app 来做。
团队沟通工具
有些团队喜欢用 QQ、微信 来做团队沟通，效果怎么样且不说，但把工作和生活的关系链混到一块显然并不是一个好主意。
一个优秀的团队沟通工具应该做到以下几点：
- 自带组织构架、人员查找
- 方便发起群组讨论
- 多人文件共享
- 和需求管理、邮件、持续集成等其他系统的互通互动更重要
- 手机和桌面版本同样重要，能够随时讨论
- 聊天历史的永久保存和搜索、归类
以前在腾讯里用 RTX 用的比较多，最新版的 RTX 解决了许多老问题，可惜并不对外提供。并且手机版也不好用。
湾区的创业团队估计都在用 [Slack](https://slack.com/ )，国内的新锐 IM 团队基本也都是照着 Slack 的样子来搞，比如 瀑布IM、BearyChat，特点是可以接入各类服务，用起来也都还顺手。不过都是用别人的服务，而不像 RTX 可以自己部署服务器，国内总会有人嘀咕公司那点机密会不会泄漏。
阿里还有做个 钉钉，不过从功能取舍上看，显然是面向传统企业为主，更偏重 OA 的功能。
邮件系统
在保守乃至正常的工作流程中，邮件都是有效的事务推动和留痕工具。需要支持：
- 和组织构架打通
- 清晰的邮件组划分
- 和日历、会议邀请挂钩
- 与沟通工具的互通。
目前只看到微软的 Exchange 可以满足此类需求。
环境与快速上线流程
我刚到某家公司的时候，第一个版本开发完要上线，然后运维们花了一整天，是的，周六加班了一整天，然后才上线成功。这简直把我吓到地上。试想一下，如果上线这么麻烦，那么谁都不愿意轻易提上线，到最后全部变动都要堆到最后一起上，那么出问题的时候一定非常恐怖。
我坚持认为上线拆得越细越好，细到任何一个修改都可以在验证后立即上线或回滚，这和 Github 的分支思路也一致：拆得越细，表面上看起来步骤多了，但是实际上可以更快速的解决很多细节矛盾，而不是等到最后一刻来救火。
所以这部分并没有什么推荐产品提供，只是向各位建议要贯彻这样的思路去架设内部环境和上线流程。
OA系统
又一个看起来毫不相关的模块。聪明的领导者应该意识到团队成员都是人，所以都会有各种行政上的需求。从请假调休、在职证明开具到办公用具和叫外卖，在传统大公司，这些事情往往和冗长的流程挂钩，在许多小公司，这些事情又往往毫无章法，全凭自己和行政沟通，无论哪样都非常浪费时间。所以接入一个高效的 OA 系统对提高团队效率也很重要。
虽然说了这么多，但我也还没找到非常适合互联网团队的 OA 系统，欢迎大家推荐。
App 模块
许多团队在开始 app 的时候往往是拿到需求就开始做，等放出去了才想起来这没有那没有，有些则是想到了也来不及做。所以我先把这些模块列出来，将来做新 app 用得上。
账号体系 第三方登录
电子邮件／手机号短信验证是主流的注册账号体系，有需求可再加微博、微信、QQ的第三方登录。涉及到在三者的开放平台注册并通过审核拿到 Api Key。这里的坑不多。但是如果用第三方平台（比如友盟）提供的统一登录功能，那就要小心了，因为接口和 SDK 都经常升级，不跟上就会导致功能挂掉。
版本更新提示与强制更新
在早期版本就需要预埋好的功能。尽管 Apple 不允许 app 内出现检查更新字样，但仍然可以在检测到有更新的时候弹出更新提示。并且为以防特定版本出现重大 bug，需要支持对老版本可以封停（不允许使用）的能力，也就是强制更新，不更新不给用。
这功能还有一个好处，当你的存量用户里有一些用户还在用依赖老接口的旧版本时，对这个旧版本配置强制更新会比直接关停老接口再通知用户要好得多。
Push 服务
一个强健的 Push 服务后台，应支持高效率的大量 Push 发送，以及对每条 Push 打开率的统计。大多数团队自己开发的后台都做不到，包括发送效率和打开率统计。从运营层面，还会需要支持预设定时发送 Push 等功能。
因此大多数情况下，建议使用第三方的方案。国内做的主要有百度云推送、极光、云巴、个推、腾讯信鸽、友盟，据传百度云推送团队已经没了，极光的后台感觉粗糙但口碑很好，个推貌似新浪微博也没再用了送达率低，云巴不知道，此外知乎用的是 LeanCloud 的推送。
短信下行服务
手机号注册等功能涉及验证码短信下行，需要有一个低延迟、高送达率、不受运营商白名单影响的短信服务商接入。所谓白名单，是指运营商会对一些特殊号码和投诉过的用户号码做特殊处理，不会收一般的群发短信。
国内的短信服务商多如牛毛，收费也从1毛到5分不等，但基本上处于便宜没好货的状态。除了送达率的问题，还有对于17*的新号段常有支持不好，以及运营商白名单中的用户容易送达不到。
最简单的方式是直接和移动等运营商谈，价格不贵且专线保证送达率。其他服务商的免费体验账号都存在上述问题，客服一般反馈都说付费了就好了。
邮件发送服务
依赖邮件的业务，一定需要一个强大的邮件代发业务，因为：
- EDM 邮件需要统计到达率和打开率等，需要支持针对特定用户发送，传统的邮件服务器并没有这些功能。
- 大多数邮件代发服务提供足够多的样式，可以快速编辑产出
- 国内许多邮件商对发送 IP 等都有过滤限制，邮件代发服务则提供白名单的途径可以避免被过滤。
常用的邮件代发服务有：Mailchimp、Mailgun、Sendgrid、SendCloud。其中 SendCloud 是国内做的比较不错的。
数据上报与统计
支持App内的各类规模类、点击类数据上报，并且有支持各种复杂分析的后台，最好能与用户账号挂钩。
这方面国内算友盟做的最有名，其他还有 TalkingData、百度统计等，但做的都一般。国外的Flurry、Localytics 更为成熟，Google Analytics for Mobile 也很强大。
一般建议一个 app 接入至少两个数据上报平台，在也就是在App内封装一层。
内测问题反馈
用于在内测（甚至正式版本）用户发现问题时，可以简单快速的将当前问题反馈到开发团队。需要支持截图和注释。 目前已知有 Instabug 支持此项功能，但是 Instabug 的管理功能很差，幸好他家支持自动与其他缺陷管理平台集成。
建议配置成仅在内测版时启用该项功能，而不是像知乎和 Google 那样正式版里也会随手一摇就触发反馈，很打扰。
用户互动／反馈
在 app 中放置入口，允许用户向开发团队反馈问题或提意见，并且可以收到开发团队的回复。一般以聊天或私信的形式。
国外主要有 UserVoice、ZenDesk 等，国内 LeanCloud 中包含该服务，还有逸创云客服算是对 ZenDesk 复制的比较好的，比其他的更多的是有帮助中心页面可用；此外还有 Udesk 和美洽。 其他 app 如知乎等则选择将该功能和自己的私信功能和在一起。
Crash上报&质量监控
收集每个版本上线的同类 Crash 的 log 或堆栈。后台应支持快速转入缺陷管理。 此类服务国外 Crashlytics 较有名（已被 Twitter 收入 Fabric），国内则有腾讯的 Bugly 做的不错。友盟也提供方案。同时也可以选择自己架设相关上报 server，也有足够多的开源方案。
官方网站
很多 app 没有 web 版，但 app 内有大量的 web 内容。那么就会有两项工作要做：
- Web 内容的 SEO。
- 外部访问 web 内容时与 app 的互动，比如 deep linking、smart app banner 等。
App 分享／安装
一个 app 应当允许用户从 app 内一键分享自己到微信、微博等，发出去的实际上也就是个下载页面。但由于微信的存在，需要开发一个承接页用来判断是否在微信中打开，是则跳转至应用宝的产品页，否再根据平台跳转到对应的商店或下载安装包。所以，你的 app 必须上架应用宝才能在微信里存活。
内容分享
内容分享出去的 web 就要考虑上文所述的和 app 的互动。这里着重说说分享的时候。许多人会选择直接用第三方分享组件提供的 UI，尽管 iOS 已经提供了分享组件。这导致的一个直接问题就是，很多 app 可以分享到微信微博QQ，却连基本的“在 Safari 里打开”、AirDrop 都做不到。更别提那些分享的 UI 其实大多很丑陋难用。
解决方案很简单，自己嵌入各家分享的 SDK，然后把入口做在 iOS 分享组件的 action 区域里就好了。
还有一点时，分享出去的内容因为要做 web 展示，所以必须支持到 Open Graph Protocol，这样各类软件比如微信在转发、读取网页预览时才能有正确的显示，否则，就会只有一个网页的标题。
