独立开发一款产品是怎样的体验

写在前面

出于对产品的执念,从去年9月开始,我决定动手开发一款开源产品——TailLog

这种冲动和小时候肢解电器或撒尿和泥源自一套逻辑——兴趣,特长,创造。

从酝酿idea,需求分析,产品设计,到开发,到去年10月24日第一个预览版上线,以及随后进行的版本迭代,中间又经历停滞,再至今天正式发布开源版本,终于完成了第一阶段的目标。

如果不出意外,又会停滞一些时间了。

这是我很早就想写的一篇文章,但几次下笔都未能完成。主要是想写的太多,内容又七零八散,太过零碎,没想清楚要表达哪些主题。

想介绍一些专业话题,却发现自己还不够专业。想总结一些经验教训,但事无巨细,不一而足。所以我要讲述的内容即不是教程,也不是结论,唯一的优点是我经历了从0到1的全过程,期间有了一些体会和思考,这种从零开始的状态也恰好代表了很多起步想做产品的想法和疑问,所以我就随性的聊一聊这个产品诞生的“心路历程”。如果对这些话题感兴趣,不妨直接找我直接交流沟通,我会分享的更多。以后若有机会,再沉淀吧。


.

如果被困难打趴下了,那就匍匐前进吧

作为程序员,开发一款产品似乎并非难事,只需要敲敲代码,实现需要的功能即可。但这只是狭义的产品开发。而一款相对完整的产品开发过程一般会包括如下一些关键词:

idea(痛点),需求,原型,UI,UX,研发,测试,运维,运营

在成熟的产品公司里,每个关键词都可以成为一个独立的职位,由专业人士专业完成。每个关键词拓展出来都是一门学问,每门学问都有很多坑,“坑之大,一人填不下”。

因此,独立完成一款“完整”的产品并非易事。hold住全过程,是必须面对的挑战。我也希望利用这个机会实践和总结一下这些年所学所想,发现弥补一些不足。

另一方面,由于是开源产品,非盈利,利用空闲时间完成,虽然产品不复杂但也非一朝一夕之事。没有收益驱动,放弃娱乐时间,能否坚持、自律进而完成产品是另一种挑战。

更何况我是一名传统的后端开发人员,主要的编程语言是Java。而这款“应用”并非技术类框架项目,我需要掌握更“全面”的技术栈,尤其是前端技术,毕竟需要可见可得。所以,我还需要一些额外的“学习成本”。

接下来的内容不会介绍实现产品所使用的编程语言或技术框架。这些“开发技能”是我已经或比较容易掌握的“工具”。这些“工具”主要提升了开发效率和质量,但做出“更好的,有用的,易用的”产品才是我的目标。所以我重点会聊一聊对开发来说,属于比较薄弱,不擅长的两个话题:

1.idea/需求

2.设计/交互

 

.

我有一个程序员,只差一个好点子了

“我没有好想法”是很多想做开源项目,但又自认为没有好的点子或项目来分享的开发者通常会抱怨的一点。这和想创业,但没有好项目的情景一样。我也为此苦恼过,并且至今也没有特别好的解决方案。“好点子”总是可遇不可求。

我也希望做出一个大受欢迎的产品,但我主动降低了这个目标。不是不可能,只是概率太低了,这需要掌握的知识面和分析问题的能力极强,具有良好的商业感以及一些运气。同时,我也为了防止自己总在想点子,防止由于各种顾虑和期望,结果停滞在这一阶段。

我明白,尽早动手,尽早实现MVP(最简化可实行产品),尽早接触用户,由用户反馈来改进产品。

说到“MVP”,这个词有必要多提一句。这是我在目前就职公司学到的第一个,也是最重要的一个概念。详细内容强烈推荐读一读《精益创业》这个本书。

由于一些历史原因,在思考“做什么”时,我先为自己限定了范围:

1. 做工具类型的产品

2. 做开发者相关的产品

这似乎有些不合常理,理论上应该“发散思维”,“放飞自我”。这就要聊一聊“历史原因”了。

我有几个小伙伴,我们都有一颗“做些什么”的心,经常聚在一起“头脑风暴”,“创意无限”。也动手做了一些项目,但这些项目最终都半途而废了。总结原因可以分成两类:

1.人员因素:多人异地开发,周期过长,自由开发,约束力较弱,后期惰性。

2.产品因素:需求离我们太远,为做产品而做产品,认同感不足。

第一类是主观因素,还是有方法克服。但第二类则是根本原因。

我和小伙伴一开始的动机就有待商榷:我们总是为了做产品而做产品,虽然想出了一些自认不错的想法,但有很多是我们并不熟悉的领域,只是管中窥豹,无法把握核心需求,没有经验,分辨不出需求真伪(当然有一些方法,如问卷调研,用户访谈等,这是产品设计和需求分析的内容,不展开)。由于我们没有资源和能力去深入挖掘,所以“臆想”的需求和功能并不能得到广泛认同,成员之间理解程度有偏差,容易产生分歧。最后导致产品形态、方向模糊,动力不足,也就不了了之了。

想法太多,但是不靠谱的想法更多,对于我们这种“业余”选手,如果不是铁了心创业,并且已经深入了解某一领域,那么应该先考虑从身边熟悉的事物寻找思路。

于是,我开始关注我擅长的领域——开发——我是开发,所以我的需求很有可能就是大部分开发人员的需求——毕竟“察己知人”(《吕氏春秋——察今》)。

如果留意身边的问题,并积极思考总结,那么总会发现很多至今没有很好解决方案的问题”。

例如,我想起了工作中常会遇到的一段对话:

测试:“XX,刚才测试客户模块的邮件发送功能,但没有收到邮件,不确定是客户程序还是邮件程序出了问题,要不你先看确认下?先提个Bug放你这儿了。”

开发:其实你可以先看下邮件程序的日志,看有没有收到请求发送邮件的日志,或者可以看到有没有去请求第三方SMTP接口的日志。就能明确是谁的程序问题了”

测试:“你们机器环境太多,程序也多,日志路径又深,查起来很麻烦,要执行好多操作。还是你看下吧,你了解你的程序。”

开发:“······,嗯,主要是查起来麻烦,如果有个工具,配置好这些服务器和日志路径,一目了然,鼠标一点就可以查看日志就方便多了。”

测试:“是的,但那你也就失去和我聊天的机会了~哈哈。”

于是,一个idea(痛点)产生了。开发,调试,测试过程中需要频繁的查看分析日志,但打开日志的过程总是包含相似的步骤和操作。而这些操作是核心工作中非必要的。那么是否可以简化操作?自动化过程?是否有一些好用的工具解决这些问题?

不满就是问题,抱怨就是机会。我为了“偷懒”,决定开发这款工具。

 

.

产品经理失踪了,程序员第一时间到警察局报警。 

警察对程序员说:你先冷静一下,你这样一直笑没办法做笔录

想好了“做什么”,接下来就要考虑“怎么做”了。这时我要变身为“产品经理”。

这令我很兴奋,终于可以做我最想做的工作了,如果不写程序,我一定选择成为产品经理。

这里先聊一个题外话:我们经常会说“做开发,要有产品思维。做产品经理,要懂一些开发。” 这里不去争辩这个观点对错,我比较想强调这句话所表达出的这个“态度”。

这个观点其实是告诉我们应该不断拓展领域知识,学会换位思考,也许并不要求某一方精通领一方的知识技能,而是应主动学习对方的一些思路,了解一些原则,熟悉做事的方法,这将有助于自身工作的专业性。“侵入式”学习能起到相辅相成的作用。比如一个设计师如果了解一些html和css,那么就不会设计一些特别炫酷的动效,阴影让开发人员骂街。如果开发人员拥有良好的产品思维,那么就能更好理解产品口中的需求,理解用户的痛点,进而提高沟通效率,减少实现误差,设计更恰当的程序和架构来解决问题。

关于产品思维,可以参考这篇文章《新人如何培养自己的产品思维》

回到产品本身。在这里,我确实是把自己当成产品经理来工作的。工作内容包括但不仅限于如下几点:

1.需求分析

2.竞品调研

3.需求设计

4.原型设计

5.交互设计

 

 

这些工作并非传统开发人员所擅长,但我都努力去完成。我认为这是必要的,这些过程是比开发更为重要的工作。所谓“低头走路不忘抬头看路”,方向对了才能达成目标,否则越努力,偏差越大。

通过分析、研究、设计,能更好的理解产品,规划产品,实现有价值的产品。

这些技能和知识可以有很多方式学习。我本身对这些很感兴趣,就自学了很多,比如最基本的能熟练使用各种原型工具,思维导图等。


这个过程帮我梳理需求,明确功能点。确认MVP,形成产品闭环。尝试从全局出发去思考一个产品,而不是只关心技术,技术只是一个手段,只是一个产品中的很小的一个环节而已。

我特别想把上面提到的五个点展开来说,可我知道一旦开了口,就停不下来了,这篇文章也就收不住了,所以专业的问题,反而要简单的回答。这里先留个坑,以后来填。

倒是可以推荐一些我看过的适合入门学习产品的书籍:

方法论相关:

《人人都是产品经理 写给产品新人》

《从点子到产品:产品经理的价值观与方法论》

《绝密原型档案 看看专业产品经理的原型是什么样》

《用户故事与敏捷方法》

价值观相关:

《用户体验要素 : 以用户为中心的产品设计》

《用户思维+:好产品让用户为自己尖叫》

《点石成金 : 访客至上的网页设计秘笈》

《启示录》

.

这个字体能不能在放大的同时,再缩小一些?

关于设计,又是一个大话题。

设计需要一些专业技能和经验积累,门槛较高。所以对个人独立产品来说,这一项常常是个弱点,或不受重视,经常以实现功能为先。

但我认为这里很多机会:很多产品已经存在了,是否有必要“造轮子”?有,因为如果你能做出一个更好的,那就是新产品。比如以前使用eclipse,它很强大,很主流,但当intellij出来后,我就被其颜值所吸引,果断放弃了eclipse。

在做竞品分析时,或多或少也有一些类似的产品,但我始终有一个想法:就算是已经存在了这个产品,如果它做的很丑,那么就可以做一个更漂亮的替代它。在这一点上,我会“本末倒置”,特别更重视UI和交互体验,哪怕功能没那么强大。

那么问题来了,非设计人员如何解决设计问题?

先说说我自己吧。

我上学期间学过一段时间美术,当时自认有一些天赋,绘画能力不错。也学过一段时间书法,虽然学习成绩不错,但我却是以“艺术特招生”的身份考入中学。后来为了“学业”放弃了这些,技能也就渐行渐远了。但这些经历培养了艺术的“感觉”。

培养这种感觉很重要。美虽然是主管感受,但符合“主流价值观”比较容易得到共识。

另一方面,我认为应该始终有“精打细磨”,不断追求的态度。之前在华为工作时,有个内部工具由内部IT小组开发,界面分布了很多输入框和按钮,但那些输入框长短不一,按钮也大小不整,组件没有任何排版,仅仅是按顺序排列在页面上,简直忍无可忍,果断辞职!(开玩笑的)

事实上,现在有很多开源的UI交互框架,这在一定程度上解决了独立产品的UI问题,不至于开发出“原生应用”。稍微重视这个问题,利用统一的UI交互框架,基本可以做到不丑。

如果平时比较关注设计,常常溜达一些设计网站,找找灵感,培养一下sense。如有精力,学习常用设计工具就再好不过了。

正如这款产品也利用了这个便捷:Ant Design。

这是阿里开源的一整套设计方案和理念,资料齐全,社区活跃,采用react等。它不仅仅是一套完整的UI,也包含了统一的交互,如按钮,编辑框的动效等。节省了很多时间,提高了开发效率。

然后,我在框架的基础上,按个人理念稍作修改即,比如:首先我明确这是一个开发人员常用的工具,而开发工具往往偏“暗”色系。看起来“酷”一些。然后我寻找了一些设计图,借鉴其用色和风格。

关于Logo

其实这个Logo是个临时方案,是为另一个项目设计的。只是这个logo是个字母T,和产品名称“Taillog”首字母不冲突,就拿来一用。

这个logo很简单,中间字母T,采用特斯拉字体演变而来,通过ps工具修改颜色以及阴影效果。

设计logo是个艰难的过程,整整花费了三天时间,我尝试了一些在线设计logo的网站,基本都是弄些艺术字加一些图形拼凑出来,不甚满意。

尽管现在这个logo也没达到艺术,漂亮的层面,但我觉得还看的过去。

出于对设计的关注,也看了一些书和一些优秀的资源网站,这里也列出来:

书:

《写给大家看的设计书》
《设计心理学》
《About Face 3 交互设计精髓》

网站:

创造狮导航
Dribbble
Behance
站酷
设计师网址
牛大拿
UI中国
字由
MyFont
千库网
摄图网
图虫网
图片压缩
包图网
花瓣
UIgradients
优优教程网
阿里巴巴图标库
EASYICON图标库
Noun图标库
TOICON图标库
WORLDVECTOR
FreeDownloads
ICONFINDER
ICONS8

.

再讲两句

其实还有一个主题可以聊聊——运营推广。

所谓“酒香也怕巷子深”,再好的产品,如果没人知道,也不会被使用。

虽然我知道这个道理,但这个话题真真的是我的弱点。

出于几个原因:

1.我比较反感广告。

2.比较反感软文。

3.比较反感脸皮厚。

所以我目前只是“佛性”运营。但也做了不少工作:

1.申请域名,备案,建立官网

2.建交流群,回复问答

3.编写各类说明文档

4.开源社区推荐

5.接入数据统计分析

6.写了这篇文章

这些工作是我认为我能做到的,就做了,至于一些其他的推广手段和方法,目前没有兴趣去做,就暂且不表了。

总的说来,产品上线至今,在没有大力推广的情况下,就获得了一些关注,平均每天都有一些访问和下载量。也有一些朋友会主动找到我咨询问题,提出建议,甚至希望参与开发。


一些反馈也很好的帮助我更好的设计、迭代产品,比如:离线使用功能

第一个版本需要在线注册登录。其原因是需要保存数据,所以做了后端存储,数据会存在云端数据库。但有小伙伴反馈担心安全问题,毕竟涉及服务器用户名密码问题。所以我第一个迭代版本就重点解决了这个问题。

事实上,必须登录才能使用确实不合理,没必要。完全是“被动需求”,即为了区分用户存储配置数据,才要求用户注册登录。这是工具类客户端产品,这些配置数据完全可以存储在本地。这就是开发思维影响了产品思维。

还有很多话题没有涉及,比如如何解决技术瓶颈,如何测试,如何发布,甚至如何写文案等等,太多了,溜了溜了

 

——2018年6月20日,葡萄牙VS摩洛哥,恭喜C罗又进一球

 

 

 

 

 

 

 

 

 

分享到:

发表评论

昵称

沙发空缺中,还不快抢~