转载

开发产品学到的一些事

　　这几年都在 start-up 打滚，跟着做了一些产品，也有一些小小心得，就纪录下来跟各位分享讨论。

　　不要一开始就写程式

　　你（或你们公司）想到了一个好点子，这时你要做的第一件事是什么？马上捲起袖子把点子实作出来吗？千万不是！你们要做的第一件事是确认真的有客户需要这个点子，而不是草率投入大量时间、人力、金钱成本，最后做出来的东西却可能没人要。

　　或许你会想说东西都还没做出个雏形来，怎么知道有没有客户呢？方法有很多种，例如你们可以把点子解释给陌生人听，看看对方的反应如何。或是先快速开发一个 landing page 来介绍你们的点子，并收集使用者的回馈。

　　确定真的有人需要这个点子，并且确定这个点子真的需要写程式之后，再开始动手写。

　　写好 User Story

　　你可以不写 Spec，但千万不能没写 User Story。User Story 的写法很简单，长得大概就像这样：「为了解决什么问题，身为一个使用者，我希望在某种情况下，能够做某件事」。

　　写 User Story 有几个好处：

　　可以让所有人都看得懂

　　因为 User Story 就是用大家都明白的语言，把想要做的事写出来，所以无论是不是技术背景的人，都可以看懂「为何需要这个功能、这个功能是为了解决什么问题」。

　　可以帮助整理思路

　　因为你得把你在什么情境底下想要完成什么功能写出来，在写的过程当中就可以整理自己的思路，检查这样的需求是否合理。然后因为大家都能看懂，所以无论是否有技术背景的人，都可以一起来讨论，这样就可以帮忙找出盲点，并且完善整个需求。

　　可以让开发者用最适合的解法解决问题

　　为什么我会觉得不需要写 Spec 呢，因为写 Spec 的人不一定是要开发的人，所以很容易就写出很莫名其妙的 Spec。更糟糕的是，有可能一开始就写 Spec，少了互相讨论完善的阶段，结果最后整个歪掉。

　　所以我会说不要写 Spec，写 User Story 就好，然后把 User Story 写完整。有经验的开发者看到 User Story 自然就会找出最适合的方式去解决问题。千万不要外行领导内行，乱下指导棋。

　　方便验收

　　既然 User Story 都写得那么完善了，要验收的时候只要一一对照 User Story 就可以知道是否完成所有需求。对验收人员来说，看 User Story 就会知道这个功能到底是什么，也就代表很容易就能理解要验收什么。

　　一定要使用版本控制系统

　　版本控制系统的好处我就不多说了，无论是单打独斗或是团队合作都应该要用版本控制系统。我个人最推荐的当然是 Git，虽然它的入门门槛颇高，但熟悉它之后所带来的好处真是让人无法抗拒的。

　　近年来 Git 有越来越多好用的 GUI，已经大大降低初学者上手的难度，SourceTree、Tower、GitUp 都是不错的选择。至于要如何将版本控制系统整合到你的开发流程，可以先参考 Git Flow 跟 GitHub Flow，再逐步调整成适合你们团队的作法。

　　有了版本控制，当然就得记得要下版本号，如果不知道该怎么决定版本号，可以参考语意化版本号的作法。

　　不必一开始就写测试

　　可能有些人觉得这是邪魔歪道，不过我真心这么觉得：「你应该写测试，但你不应该一开始就写测试」。

　　身处在 start-up，无论前期的思虑有多么周到，产品的需求还是很容易就会变更。如果採用「测试先行」的话，最后你会发现绝大多数开发的时间都拿去写测试了，而且因为需求在前期很容易变更，所以你的测试也很容易一改再改因而难以重複使用。（P.S. 降低需求变更机率的一个方法就是好好写 User story）

　　所以我会建议，等产品到达一定的稳定度之后（例如主要的功能或画面都已经固定），再来补上测试。到时可以特地安排一段时间专心来写测试，或是在需要重构程式的时候边重构边补上测试。

　　善用追踪工具

　　做任何决定之前都要有所本，不要突然「通灵」了就做出莫名其妙的决策。那要根据什么做决定呢？很简单，让数据说话。善用至少一款追踪工具（GA、Mixpanel、Flurry、Kissmetrics、Keen IO、Customer.io、Segment ）并在上线第一天就开始追踪使用者的行为，这样才能知道有多少使用者在用你的产品，以及如何用你的产品。总之，就是要透过数据收集与分析，来了解你的使用者。

　　日后当你要做 growth hacking 的时候，追踪工具更是不可少，你会需要这些追踪工具来帮你统计，看哪些修改会有助于你的业务成长，哪些修改反而会让业务衰退，以及成长或衰退了多少。

　　如果有开发 APP 的话，你也会需要想办法取得 crash log，这样才知道程序挂在哪，我推荐使用 Crashlytics 帮你收集分析这些 crash log，它非常的好用。

　　爱用第三方元件

　　近年来 open source 越来越受到欢迎，网路上有各式各样的第三方元件让你取用，所以真的没必要每一样功能都自干，如果有现成的可以符合你的需求，就大胆的用吧。再加上第三方元件的管理程式（像是苹果开发者常用的 CocoaPods 跟 Carthage）也越做越好，早期会遇到的第三方元件版本控管问题已经很少见了，所以我建议各位可以尽量用第三方元件，或是将第三方元件修改成符合自己需求，没事不要自己造轮子。

　　方便的更新机制

　　随着时间过去，你的产品需求一定会有所变化，该怎么向后相容以及如何要求使用者升级就变成一件不得不面对的问题，这里我有几点建议让你参考。

　　设计 API 的时候要考虑版本化

　　同一支 API 背后的商业逻辑很有可能会变化，如果一开始设计的时候没有考虑版本化，你就会为了 API 名称而大伤脑筋：可能原本的叫做 checkout，后来叫做 checkout_new，再后来叫做 the_new_checkout。

　　但如果一开始有考虑版本化的话，你就可以一开始叫做 checkout/v1，后来叫做 checkout/v2。或是直接改 API end point，例如一开始的 end point 是 api.myserver.com/v1/，后来的是 api.myserver.com/v2。

　　呼叫 API 的时候附上环境参数

　　虽然现在送 request 的时候，大部分都会在 header 附上 client 的一些资讯，但每个 client 送出的 request header 格式有可能并不统一，所以要 server 去 parse header 来取得所需资讯，其实成本蛮高的。

　　比较方便的方法是，client 每次在呼叫 API 的时候就主动附带一些参数让 server 好判断。例如可以送 platform 参数指明是 ios / android / web，device 指明是 phone / tablet / desktop，version 表示程式的版本等等。Server 就可以根据这些参数有不同的逻辑与回应资料，例如根据 device 回传不同尺寸的图片网址，或是根据 version 来得知对方是否使用最新版本。

　　In-App Announcement

　　如果一开始就有设计 in-app announcement 机制的话，就可以更轻易让使用者得知最新消息。例如有新版本可以下载了，让使用者知道有什么新功能并引导使用者去下载。或是有在举办什么活动的时候，也可以透过这个机制让使用者知道（例如 Uber 时常会举办不同活动，车子图示也会跟着变）。或是有什么新贴图、新佈景主题、新内容，也可以让使用者知道（例如 Line 或各款游戏）。

　　储存资料的时候要考虑版本化

　　有很多时候我们必须储存一些资料在本机，可能是透过写入设定档或是写入资料库，如果储存资料的时候有考虑到版本化，之后要处理资料相容或是要将旧资料转换成新资料的时候，都会相对简单许多。

　　写文件

　　所有人都知道写文件的重要，但是大概没人会喜欢写文件，但其实文件没那么难写。文件存在的理由是什么？不就是为了日后的查询参考吗。

　　所以 User Story 就是文件的一部分，你一边设计产品的同时，就一边在写文件了。这样有没有觉得写 User Story 很划算，会不会更有动力写好它！

　　代码注解也是文件的一种，现在有很多工具能够将注解转换成说明档，日后只要注解有所变动，说明档就会自动更新，这可以帮忙省下超多时间。像我们的后端都会在代码里头注解说明这支 API 的用途是什么、传入的参数是代表什么意思、是什么型态、是否可以不传、回传值是什么、有可能产生哪些 error，对应的 error code 是什么等等。我个人觉得，维护程式码的注解比额外维护一份说明文件（可能是 wiki 或是 doc 等等）简单多了。

　　文件也不是写完丢在一旁就算了，它是让人日后可以查询参考的，所以最好可以把所有文件统一放在一个地方，然后有个方便的作法让人查询（可能是规划良好的目录结构，或是提供搜寻功能等等）。

　　简单来说，文件有三大重点：要完整、要保持最新版本、要让人找得到。

　　画 Wireframe

　　通常设计师会画好 wireframe 让工程师知道整个使用流程，明白该从哪个画面跳到哪个画面。如果很不幸的，你们公司没有这种东西（可能是不见了或根本就没有），那 APP 开发工程师就认份一点自己画一个吧。对工程师来说，画这个并不难，只要把 APP 每个画面都撷取下来，然后用箭头把彼此之间的前后关系串起来就可以了。

　　拥有一份完整的 wireframe 的好处在于，当你们想要增删或修改某些功能的时候，可以把 wireframe 拿出来，看看增删或修改这个功能之后，整个使用流程是否顺畅合理。千万不要功能都做完，才发现流程变得卡卡的，这样浪费的成本太高了。

　　以上就是我的一些心得，对上集有兴趣的人可以看这里。

　　老实说，就算每一点都做到了，也不保证你的产品会成功，但绝对会让你开发一款新产品时比较不会走歪，就算歪了也可以早一点救回来，降低你犯错的成本。

正文到此结束