不要浪费开发时间：给初次创业的伙伴们的 6 个软件开发建议

初创公司因为产品定位还不明确，常常花一堆时间做好功能，却发现没人要用，浪费了宝贵时间。

犯过这种错误几次之后，我们慢慢整理出一些比较有效的开发方法。

这些方法帮我们省下很多开发时间，今天跟大家分享一下！

一、别在一开始就想要流程全自动

常常听到正要创业的团队担心“要是我们太受欢迎怎么办？”、“要是我们太红怎么办？”

直觉的想法会是“当然要先做好准备再上线！”、“把系统做到全自动，让工作人员不需要介入，整个流程就能顺利跑完！”

这个错误我们也犯了几次：一开始就把架构做得很大、完整到能够应付大量需求。…结果发现上线之后没什么流量，呜呜！

所以我们后来设计新功能、新产品的时候，就不花时间让系统自动化了。快速写出一个“半自动”的系统，然后直接上线。收集 Feedback 系统？用个 Google 表单嵌入在网页里面就很像了。

自动寄出电子发票系统？做个“寄出发票”按钮，给客服人员自己找时间去按就好了。

合作伙伴注册系统？用个 Google 表单嵌入蒐集资料，然后自己用 Email 一个一个联络就好了。

商品具有多种状态的全自动物流系统？其实在数据库用不同整数代表各种状态，给物流人员手动调整所有商品的所有状态就够用了。

做出几个功能按钮，让负责人员自己判断什么时候去按那些按钮就好了。情境判断与自动化的程式码都先别写了。需求量大到负责人员忙不过来再写就可以了。

二、信任你的内部人员

不信任的成本是很高的。

公司常常需要针对管理员、工程师、合作厂商、实习生等等不同角色，开发权限系统。真的要针对每种角色，在后台管理面板写一套大企业等级、能够做完整内控的权限管理系统吗？

底层不作严格检查、只针对各角色显示不同资讯，真的不够用吗？相关的内部人员真的会恶意到去测试系统漏洞、乱改不属于他们的资料吗？真的发生这种事，在算帐时会发现不了吗？被影响到的人不会来反应吗？

我们也曾因为预计之后会有独立的 PM 权限，于是在目前的 ADMIN 权限之外多写了 PM 权限。结果因此浪费很多开发时间，而且根本没那么快招募专门的 PM 人员。完整的权限系统会需要在 controller 或是更底层的 layer 写一堆检查的程式码。

更糟糕的是，各个角色的职责跟功能也变动得很快，复杂的权限系统会让各种功能改起来更慢。先实作一套简单阳春的后台权限检查，通常会够用好一阵子。

三、把功能拆分成阶段上线

这是所有建议里面，我们付出最多代价，才学到的教训。不要在一开始就把功能做到丰富完整。

大部份的功能，都可以在讨论过后，拆分成阶段上线。

讨论出功能最基本的长相（Phase 1），试着在几天到几周内开发然后上线。Phase 1 上线后会碰到各式各样的问题，像是使用者不想用、不会用、用了却不爽…等等。

不如让 phase 1 先上线，再根据结果，思考 phase 2 要做哪些事，或是干脆搁置这个功能不做下去。这种作法能让服务快速上线、团队的下一步明确、省下不必要的开发时间。

四、尽量去追踪网站的使用情况

网站到底哪些功能常被使用？哪些地方客户逛了但是没去用？哪些地方客户根本逛都不逛？除非你站在客户旁边看他操作系统，否则很难得到答案。

网站的下一步要怎么改善，团队里的每个人都有不同想法，这种时候，最好能用数据来说话。因此，应该要尽可能地去纪录每个按钮、每个连结、每个页面的使用数据。

安装 Google Analytics 是基本的。

除此之外，记得替几个你觉得重要的按钮加上Google Analytics 的 Event Tracking功能；有在网络上公开的文章、贴文，可以用Bitly之类的工具纪录网址使用情况。再不行的话，就在系统本身建几张资料表，直接用程式码去纪录某些功能的使用数据吧。

五、工程师做做看客服，做做看业务

这点跟开发没有直接相关，但还是会影响开发速度。负责客服的同事可能多次向工程师反应过某个页面很难懂、按钮很难用。

工程师常常会去忽略这些反应，心想“那个页面最好是有这么复杂”、“你跟那些客户多解释一下就好了”。然后就会导致每个人对于接下来什么事最重要有不同看法。这种时候，如果工程师花点时间去做客服，通常会有很大帮助。他可能会惊觉“居然这么多客户反应同样问题”，于是充满斗志的把功能改好。也可能会发现 “同事没讲清楚，但其实加点字、改改按钮颜色就解决了”。

同样的，如果工程师花一些时间做业务，可能会突然理解为何负责业务的同事会一直要求某个功能。工程师偶尔换一下角色，做点其他事情，不但能让团队沟通更有效率，开发起来也会更有士气。