一款产品的从 0 到 1 之旅

一款产品的从 0 到 1 之旅

从 0 到 1 打造一款产品是一种什么样的体验？为了回答这种知乎范的问题，让我来介绍下我是如何打造交易日记这款 App 的过程。需要提前说明的是整款 iOS APP 的全部工作都是我一个人完成的。

全栈开发的体验

全栈开发(Full-Stack)到底是什么？ Google 出的第一条结果说全栈开发就是需要对前后端技术都了解的人，同时可以把产品设计界面转化成代码。总之就是对开发产品涉及的领域什么都需要了解的人。 我们知道现代社会的高效是建立在合理的分工合作之上的，个体的能力有限，所以需要每个人发挥自己擅长的能力，然后合作解决一个大项目。企业的出现就是因为社会的这种需求，所以产生了上班的这个概念。这个话题讨论起来很漫长，所以让我们看看全栈开发又是为何而出现并流行起来的。可能有人不认为全栈开发很流行，这里有一份 StackOverflow 的 2015 年调查报告([http://stackoverflow.com/research/developer-survey-2015])： 从调查结果来看连续三年全栈开发都是位列第一的，不得不说越来越流行。当然我们为什么在中国感受不是很明显呢，看这张图就知道了，因为国人访问 StackOverflow 还是比较少的，而且这个网站并没有被墙。 全栈开发为什么越来越流行？我认为这是因为技术本身的进步带来的，技术发展已经越来越开放并且模块化了，很多产品完全可以用现有的模块去重新组合二次开发，很多关键技术和算法都已经不是什么阻碍了，越来越流行的 Github 和 StackOverflow 已经表明了这一点。连机器学习和人工智能这种高大上的技术都已经有开源模块可以学习并应用，以后这个趋势会越来越强。个体的影响力正在被不断的放大，反而企业的影响力会降低，未来的社会中远程工作和独立工作者的数量会越来越多。社会对群体聚集进行生产产品的模式需求在降低。 那这种趋势的来临对我们个体有什么影响？首先不论你工作和 IT 有无关系，你都会被互联网这种趋势影响的，所以有必要去了解全栈思维对我们个体的影响。首先让我来解释下我理解的全栈思维：它应该是一种解决问题的能力。让我们假想两种思维模式就可以看出这个定义的有趣之处了。 A 是你要打造一款产品，然后你需要了解制作这款产品需要的资源、技术和流程。 B 是你需要学习一门流行的技术来找工作，然后你利用这个技术来做一个 Demo 产品。 A 和 B 的区别在于 A 需要解决各领域的问题， A 是一种全栈思维，以目的为驱动的。为了完善这款产品你也许需要了解产品的各个方面，这在以前对个体是不可能完成的任务，但是在这个不断被链接的世界里，每个人都变得更为专业，通过个体的创作与链接可以使你完成一项大工程，这里面甚至你都不需要组建团队，一个人就可以完成产品的创作。这在接下来的部分我会介绍我如何在三个月内完成一款产品从 0 到 1 的过程。相信看完你会对全栈思维有更深的理解。 那么全栈开发的好处和坏处有哪些呢？我认为好处是沟通成本为 0 ，沟通在一个大工程里面是非常有影响的一个环节，很多时候项目的失败和沟通有很大关系，根本原因在于参与者太多，成本已经大于参与者协作的加成了。那坏处就是什么工作都需要你来做，当然你可以外包一些不重要的部分出去，但是一定要注意沟通成本的增加。

产品设计

我要做的产品是一款有服务器端支持的 APP ，目前我只做了 iOS 版本，未来可能要做 Android 和 Web 版本。这款 APP 已经上架（ http://diary.trade)。它是一款工具类的产品，所以我在开发的时候使用 Native 模式来开发的，并没有用 Web 封装这种方式，因为工具类更适合用 Native 来开发，内容类的用 Web 来开发也不错。 这款产品前身是我设计的一个 Excle 版本的资金管理系统，所以不是很方便，这促使我开发了这款 APP ，因为我本身也是做二级市场交易的，所以这款产品本身就作为我的一个辅助交易的工具，可以节省我很多时间。同时这种交易理念也经受过时间的考验，所以有必要做出来让大家用，可以提高你的交易能力和风险管理能力，这比选股择时更重要。 这是规划中的版本功能设计。

项目管理

整个项目计划管理是用 OmniPlan 制作的。 APP 开发花的时间最长，因为我使用了 Apple 的 Swift 开发语言，算是一遍学习一遍来开发，所以进度要比计划的慢一些。

产品开发

系统模块设计

APP 本身由服务器端来计算很多数据，和服务器通过 TLS 加密通道交换 JSON 格式数据， APP 口令存储在 iOS 本地 Keychain 中，通过 OAuth 服务器获取 Access_Token 来授权认证， API 的设计是 REST 风格。 系统模块做了如下划分：

数据库设计

数据库设计规则：

1. 考虑到 i365 系统中不需要做复杂的事务操作，所以采用 MongoDB
2. Document 间采用关联模式建立连接关系，少部分有内部关系的 Document 采用嵌套模式建立联系 这是用 MysqlWorkbench 画的 ER 图，但是我最终采用的是 NoSql 的 MongoDB ，所以这只是一个参考的图，这不是最终设计版本。

REST API 设计

此处我在 Python 遇到 26 个坑，开发时间半个月， v1 版本代码行数 2K+。

UI/UX 设计

此处的坑在于我没有学过设计，需要不停的画了再删再画直至满意，当然我还是遵循了一些基本的设计原则，这可能是我以前看的设计的书籍还没有忘的原因。 Sketch 的教程我使用的是网上的视频教程。

服务器运维

服务器是阿里云 1G 单核配置，连多进程都玩不了。用 iptables 做了些安全设置。 OS 是 Ubuntu 。 Web 服务器是 Nginx 。 Python 用的是 UWSGI 处理。 数据库是 MongoDB 。 日志监控是 Nagios 。 此处遇到 22 个坑。

APP 开发

开发平台： Mac OSX IDE ： Xcode 开发语言： Swift2 此处遇到 71 个坑，开发时间两个月， v1 版本代码行数 7K ＋。

Web 开发

产品和项目展示页面： http://diary.trade http://i365.tech 直接搜索App Landing Bootstrap Template就可以找出很多免费的模版。

系统测试

API 通过 CURL 来测试 JSON 数据。 APP 是人肉测试。 以后考虑使用单元测试。

域名

万网购买的几个域名包括 cn 、 net 、 tech 、 trade 。费点时间的就是去备案了，这个万网有很详细的流程说明。

产品反馈

通过邮件、微博和微信公众号来接受用户反馈意见， APP 本身没有加入崩溃检测代码，以后可以考虑加入。

寻求帮助

通过 Google 、 Github 、 StackOverflow 搜索来解决问题。但是如果你想对某个主题进行系统学习的话可以通过在线 MOOC 课程。这个以后我会分享我在 Coursera 里面上的十几门课程。

运营推广

产品文案

这个就需要你多看一些产品介绍文案了，然后写多个版本，然后挑选一个最好的。文案的关键是要抓眼球，也就是在最短的时间给潜在的用户介绍你自己，同时也要遵循平台本身的特点来推广，要和平台的逻辑和气质相符效果才棒。 这是我给 App Store 写的产品文案，考虑到 App Store 的搜索只能针对标题，所以标题的设计就很重要，这其实就是 ASO 优化的主题了。如果是 Android 的在 Google 的 Play Store 文案你就需要考虑内容的介绍加入更多的关键词了，因为 Google 会搜索它的。

运营

如果是工具类的产品对运营的需求倒不大，但如果是内容类的产品那么好的运营就很重要了，需要和用户进行互动，不断的制造话题，这方面可以多看看微博和知乎的热门话题产生的逻辑，多尝试并进行分析改善。 热门话题一般都是经过精心设计的。

推广

推广有很多种方式，有钱的话那就有很多种暴力推广方法了，比如微信公众号的推广平均一个用户都涨价至几块钱一位了，所以大家都在做吸引眼球的动作了，只要有关注者，都是钱嘛。以下是几种常见的推广渠道：

1. 邮件列表。优质的邮件列表推广的效果很不错，所以我们可以尝试去维护一个邮件列表，定期发送用户关注的内容，比如做一个 PodCast 或者周刊之类的 Mail List 。邮件列表发送商的话我一般用 Mailchimp ，发送成功率和模版及统计功能都很棒，还有移动端的 App 。
2. 微博。微博的确没有死，焕发出了第二春。微博的好处在于可以制造传播话题，同时和用户互动方便。
3. 知乎。知乎需要专业的去运营，懂得某领域的知识，然后在热门话题下多分享回答就可以不断积累高质量的用户源了。
4. 微信公众号。公众号的好处在于和用户的单向互动，有些不想让用户之间了解的内容需要运营的话很适合用公众号，因为用户之间不可见，可以避免很多问题。
5. 社区。社区的好处在于主题的集中度很高，比如雪球、 V2EX 社区等，都是很专业的社区。

下期内容

世界上最公平的事就是我们每个人的时间都是相同的，那如何科学高效的管理你的时间呢？我们下期见。