产品

展望未来，总结过去10年的程序员生涯，给程序员小弟弟小妹妹们的一些总结性忠告 走过的路，回忆起来是那么曲折，把自己的一些心得体会分享给程序员兄弟姐妹们，虽然时代在变化，但是很可能你也会走我已经做过的10年的路程，有些心得体会你可以借鉴一下，觉得说得有道理的你就接纳，觉得说得没道理的，你就抛弃，以下是我发自内心的，给大家的忠告，特别是针对那些小弟弟妹妹们。 01. 自己的户口档案、养老保险、医疗保险、住房公积金一定要保管好。 由于程序员行业每年跳槽一次，我不隐瞒大家，我至少换过5个以上的单位，这期间跳来跳去，甚至是城市都换过3个。还好户口没丢掉，其他都已经是乱了，好几个城市里，都有交过三金，甚至是一个程序的2个区里交的都有，那些东西，10年后，会变得很重要。你买房子若有公积金，可以取出来，贷款利率也会比较低一些，有孩子了，还需要上学，生病了还需要医疗保险。 特别是买房子时，你要商业贷款与公积金贷款的利率差别还是很大，有可能会有10万的差距。你平时都注意这些，会给你带来的损失会最小，例如每个月缴纳300元的公积金，公司也缴纳300元，你一个月能存下来600元，一年就是7200元，10年就是72000元。我以前都忽视了这些，到我需要买房子时，公积金里可能只有几千元，10年很快就过去了，结果我没能存下来多少公积金，医疗保险，养老金等更别提了，都已经稀里糊涂了，这些损失10年累加起来

LBS概况 LBS （Location Based Service，基于地理位置的服务），是通过电信运营商的无线网络或者外部定位方式（GPS）获取移动终端的位置信息，在 GIS （Geographic Information System，地理信息系统）的支持下提供的一种增值业务 LBS现状 国内外百花齐放 LBS被认为是移动领域的杀手级业务，普遍被行业看好，也有众多公司试水这一领域。在国外，2009年3月成立的Foursquare 是LBS的鼻祖，仅用一年时间就有了100万的用户群，甚至传言要被雅虎以一亿美金收购 国内的LBS市场已经热的发烫，2010年初，拉手网、玩转四方、街旁等创业公司纷纷涌现，网易、腾讯、新浪等门户公司也纷纷投入到LBS的研发中，甚至中国移动等传统通信厂商也开始试水LBS。在投资方面，同众多模仿国外成功的产品一样，也能拿到可观的投资 技术成熟，商业模式尚不明确 LBS相对其他移动互联网产品，技术门槛相对较低，操作起来简单有效，现在一些智能手机利用GPS的定位已经可以达到10米内的精度，因此可以准确定位到某一处商家，某一栋大楼，这在靠基站定位的时代是不可想象的 由于本身不具有目的性和黏性，LBS一般都只作为一种工具出现在某种产品中。通过LBS，用户不需要搜索和查找就可以在地图上快速定位自己的位置，在这个位置上寻找自己感兴趣的内容 用户和商家在接受，LBS

台湾有许多公司，开始跨入 QR Code 的相关应用，热度开始逐渐上升。最近有幸跟许多在这方面有兴趣的朋友们聊天，得到了很多的心得，其中最重要的一个就是，似乎大多数的朋友都觉得：QR Code 是一个功能，不是一个产品。 今天我们就来聊聊，为什么 QR Code 不是一个产品，以及在“一个功能”的思路下，我们该怎么样做到最好。 QR Code 是一个技术概念，并不是一个商业概念 这么说吧，O2O 是一个商业概念，代表了从线上引导客户到线下的消费或服务；E-Commerce 是一个商业概念，代表了在线上直接进行商品的购买。一个商业概念，代表的是它所能带给消费者的价值。但是 QR Code，你一想到它，就会想到一个方正的条码图形，认为它是一种技术、一种规格。 QR Code 若应用到票券上，我们可以说它是 O2O 的商业模式，而 QR Code 的本身，并不是一个商业模式。也因为 QR Code 本身并不是一个商业模式，自然的，它也就不是一个产品。 QR Code 的本质是透过编码过后的图形，去装载资讯。这些资讯可以是任何东西，例如 URL、文字、数字。而通过装载资讯的 QR Code，手机用户可以在实体世界，取得进一步的资讯或是互动；例如产品包装可以用来承载食品的检验资料，名片上可以用来承载联络人资讯，杂志上可以用来承载参考资料……，每一个产业领域，都可以透过 QR Code

【推荐阅读】微服务还能火多久？>>> 起因是我们团队内部无法达成一致，然后我在目标用户集中的地方发帖来邀请大家给意见。一个下午，700多次点击，近20个潜在用户的认真回复，我们最终有了自己的结论。 　　结论稍晚聊，先看看原文： 　　求意见：我们应该增加留言板么 　　现在在初期的讨论，我们有两种意见，谁也说服不了谁- -#，求大家的意见。 　　背景 　　我们产品本身的主要功能是展示程序员个人价值： 　　通过个人简介，过往作品，专业社区影响力展现你的成就和能力 　　通过被关注被联系被赞的次数展现你的热门程度 　　其中只有简介，作品需要手动输入，其余信息基本只要你有Github，知乎或者stackoverflow账户都可以自动抓取，每天更新。 　　目前我们团队内部有两个意见: 　　需要为每一位展示了作品的优秀程序员提供一个留言板，这样对他们的作品感兴趣的人可以在这里给他们留言，请教，给出反馈，然后双方都有意再更进一步联络的时候，可以查看联系方式，用更直接的方式联系。以下效果图中，留言板部分为效果图，履历部分已实现： 　　 　　留言板 　　2.不需要留言板，因为用户可以直接通过查看联系方式的办法来联系对应程序员，进行探讨。再增加留言板功能就复杂了，产品太重，反而没有了焦点。（就是上图没有 留言板部分的样子。） 　　求大家意见，觉得 有留言板，还是没有留言板好。谢谢！更多建议欢迎给我们留言：

　　产品经理的职称最早出现在P&G宝洁公司，因效果非常显著，许多企业纷纷仿而效尤。硅谷知名的产品管理大师Marty Cagan在《Inspired: How To Create Products Customers Love》中，将产品经理一职形容为「 找出有价值、可利用和行得通的产品 」（”to discover a product that is valuable，usable and feasible”）。 　　根据美国产品管理协会PDMA的定义，所谓的产品管理（Product Management）是指：在新产品开发的过程当中，通过不断监控和调整市场组合的基本要素（其中包括产品及自身特色、沟通策略、配销渠道和价格），随时确保产品或者服务能充分满足客户需求。而产品经理就是针对上述特定产品活动肩负所有责任的人。 　　即便是产品经理的角色很重要，但在多数公司却不一定受到重视，原因之一就在于—对于 “产品管理制度” 及 “产品经理定位” 存在许多的误解。 　　 1.产品经理与项目经理，哪一个比较重要？ 　　经常很多人问的问题就是两种PM之间的差别？有些甚至于以职务大小、责任轻重来做为两者的差异…而这些都是普遍存在很多解释不清楚的地方。实际上，产品经理与项目经理的不同，在于产品经理必须对产品全权负责以及对产品的整个流程负责。一旦该项目被完全理解成产品来看待，项目经理则消失了

当我们初次接触 产品需求文档 时，首先会从网络上寻找 产品需求文档模板 ，希望从中了解和学习具体的写作要求，但实际上，现在网络上绝大部分的 PRD文档 都是与实际工作不相符的，或者说是复杂的。 前几天一位从事产品类工作的朋友，发来一份他写的产品需求文档目录截图给我(下图)，当时我就郁闷了，这些类目更像是 MRD文档 ，而不是 PRD文档 了，因此我决定写几篇讲述写作PRD文档的文章，分享一些我关于PRD文档的见解和写作方法。 PRD 是英文 Product Requirement Document 的缩写，中文的意思是产品需求文档，具体的名词介绍大家可以询问 Google 。 PRD文档 是基于 BRD 、 MRD 的延续文档，主要用于产品设计和开发使用，因此阅读这份文档的人群绝大多数是设计与技术人员。在这类人群中，设计师更多依赖于原型进行交互或视觉的设计，因此看这份文档的人就会偏向于技术人员。相对于技术人员，他们不太关注产品的商业需求和市场愿景，因为在进行产品讨论立项时，产品的定义就已经向参与设计和研发的人员宣讲过，因此技术人员更多的是关注界面、功能、交互、元素等等内容，因此PRD文档是一份详细的产品功能需求说明文档，是产品文档中最底层和最细致的文档。 PRD文档 是一份没有闲话，直入主题的功能说明文档，因此我们在写作时，脑海里构思的是成品产品的界面功能的逻辑线框图

现在几乎所有的 App 都会有一个功能叫做「意见反馈」，这是我们听取用户声音的一个手段，以下是某新闻客户端和某电商客户端的「意见反馈」界面： 看功能界面挺简单的，但是开发起来事儿一点也不少，一般来说以下几个基本步骤是少不了的： 客户端工程师实现界面功能； 后端工程师建数据表、写相应的前端调用接口； Web 前端工程师实现意见反馈查看列表。 如果要做到好的用户体验，可能还需要将意见反馈接邮件系统，这样当用户提交了反馈，我们可以通过邮件及时看到并处理，要做好不简单吧？如果有好几个客户端，可能还需要重复发明轮子。 现在，Bugtags 为以上问题提供了很好了解决方案。 Bugtags 认为，用户的「意见反馈」应属于应用 Bug 的一种类型，应该与手动提交的 Bug、自动收集的闪退一起管理，那么我们应该怎么做呢？ Bugtags 所提供的是一种轻量级的解决方案：只提供数据接口，不提供 App 内的提交界面。这样每个 App 都可以按照需求实现不一样的「意见反馈」界面，比如上面所说的某新闻客户端和某电商客户端「意见反馈」的需求和设计就不一样。但是，他们都可以通过 Bugtags 意见反馈接口来实现数据收集。 Bugtags 这个魔法接口就是 sendFeedback： /** * 发送用户反馈 * @param content - 反馈内容 */ + (void)sendFeedback:

很感谢开源中国这个平台能提供这样一个技术性的场地，供技术爱好者们勇往直前的学习。下面给大家讲述一下作为一个技术人员的转型史（工作经验），百转千回最后到了产品，做产品其实也没有想象中的那么容易，毕竟更多的事都是在反复的确认需求的环节中，眼光放长远一点可不仅仅只是在熟练的使用原型工具画着要输出的效果图给经理，客户，设计，开发人员看，给他们讲需求，讲流程，在这样一个闭环的沟通中，难免会控制不在需求的往返更改，所以初入职场的产品小白们，还是的更加积极的去学习更多的产品技能，为自己出色的工作选好装备（实力）。 今天给大家带来的是一个产品官网的规划设计，由于上截图不太方便大家看效果，我直接给大家已链接的形式分享。 https://git.oschina.net/Itasks/Axure.git（原型效果演示链接） 如有问题可加入QQ讨论群：146718932 来源： oschina 链接： https://my.oschina.net/u/1258343/blog/702724

以下内容由本人编写,如有巧合,纯属雷同. www.oneapm.com 写这篇文章之前,我特意查了一下软文的概念: 顾名思义是相对于硬性广告而言，由企业的市场策划人员或广告公司的文案人员来负责撰写的“文字广告”。 精妙之处就在于一个“软”字，好似绵里藏针，收而不露，克敌于无形。 诚惶诚恐,我不相信少数人的智力会碾压多数人,更不相信我拙劣的内容会让大家去使用 OneAPM 产品,这更不是什么以柔克刚的法子,我仅仅是想说说搭讪的感想,测试一下头脑风暴指数.(其实刚收到要负责 OneAPM 服务号的时候,我是拒绝的) 故事发生在曾国藩打垮太平天国,收复南京之初,当时首要工作就是恢复秦淮河的游乐事业,像曾国藩生活那样严肃的人,为了繁荣地方自己还到秦淮河去逛逛,以示提倡.一个妓女艺名少如,很有文才,要求曾国藩送她一副对子.曾老打算用她的艺名”少如”这两字嵌到联中,先写上联:”得少住时且少住”,意思是能偷闲在这里休息片刻就休息片刻.因为要考这女孩子的文才到底怎样,就要她对下联,不料这女孩很调皮,开了一个玩笑提笔来写道:”要如何处便如何”. “忽然下的一场雪 飘的那么纯洁……”,起床铃声很重要,让我一天都有个好心情,前几天在书上看到的故事出现在了我梦里,贼真实.身为公司的基层员工,必须要如何出便如何.顺应公司的发展,才能找准自己发展的方向;在这个看脸的社会,虽然我相貌一般.但没个好的身材

　　每一个 产品经理 都有一颗母爱般的心。一个孩子和妈妈走在回家的路上，突然孩子说：“妈妈，我要吃鸡腿。”但是附近没有肯德基之类的店铺，妈妈犯愁了，怎么办呢？可不能饿着孩子啊，妈妈又突然想起来中午买的批萨还有一些，于是拿出来给孩子吃，鸡腿=批萨吗？潜在的需求是：饿+好吃的。从这一点案例分析，产品经理都是设计师，同时又是规划师。 　　那么产品必备的Appstore热搜应用都有哪些呢？ 　　1，乎之原型，是一款快速交互原型制作工具。创建原型：导入效果图，编辑事件，演示原型。可以使用点击、滑动、双击....等各种动作事件，并支持移入、渐隐、翻转...等各种页面加载效果。分享原型：邀请好友查看或评论原型。可以使用手机号码、邮箱...等各种方式邀请好友，支持原型实时同步、分享范围控制...等。duang、duang、duang 特技特技加特技，乎之原型，简单任性。 　　2，原型助手，让你的保真原型可以在手机上演示。支持Justinmind Prototyper以及Axure生成的html原型，以及所有html格式的原型；无须上传文件到服务器，原型制作好即可通过WiFi传到手机。文件通过简单压缩成zip文件进行传输，app内一键解压演示，方便快捷；演示时摇一摇可呼出菜单，减少演示时的干扰；每个原型演示独立设置，互不干扰； 　　3，移动应用设计，一直保持在App