写在前面
出于对产品的执念，从去年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.写了这篇文章
这些工作是我认为我能做到的，就做了，至于一些其他的推广手段和方法，目前没有兴趣去做，就暂且不表了。
总的说来，产品上线至今，在没有大力推广的情况下，就获得了一些关注，平均每天都有一些访问和下载量。也有一些朋友会主动找到我咨询问题，提出建议，甚至希望参与开发。
一些反馈也很好的帮助我更好的设计、迭代产品，比如：离线使用功能
第一个版本需要在线注册登录。其原因是需要保存数据，所以做了后端存储，数据会存在云端数据库。但有小伙伴反馈担心安全问题，毕竟涉及服务器用户名密码问题。所以我第一个迭代版本就重点解决了这个问题。
事实上，必须登录才能使用确实不合理，没必要。完全是“被动需求”，即为了区分用户存储配置数据，才要求用户注册登录。这是工具类客户端产品，这些配置数据完全可以存储在本地。这就是开发思维影响了产品思维。
还有很多话题没有涉及，比如如何解决技术瓶颈，如何测试，如何发布，甚至如何写文案等等，太多了，溜了溜了。
网友评论