分类目录归档:全部

Ping++大会·增长

12.12 周六下午到外滩3号参加Ping++2015的年度收官活动。

初识Ping++是两个月前逛拉勾网,看到这家公司的简介以及面试者的评论,觉得这家公司工作氛围非常硅谷化,是一家非常活跃且愉快的团队。于是我就投了它的产品经理岗,次日HR就将我的简历判为不合适,没有争取到面试的机会。

从那以后,我就一直有意无意在关注着这家公司的动态,前两个星期,Ping++的微信公众号发了一个活动邀请,当时我是在下班的公交车上,看到这个邀约页面,我毫不犹豫地报了名。

这个大会主要讨论的主题是“增长”。大会邀请了几家较为成功的初创互联网公司的founder来分享他们当时在用户增长这件事上做出的尝试和努力。

亿欧网、爱抢购、M.Cake和Teambition这四家公司的founder的分享,总结下来就是:先把产品做到极致,在用户面前保持谦卑。

纵观现今所有优秀的互联网产品,无一不是在一开始就把所有精力投入到产品中,把产品的设计和用户体验做到团队所能做到的极限,然后谦卑地根据用户的真实反馈去快速迭代完善。

另外,对于一款全新的产品或者是互联网模式,一开始肯定是不被大多数投资人看好的,并且绝大部分人都看不懂。如果一个模式很容易被投资人接受,基本已经不适合初创团队浪费精力在这上面了。

反观自己负责的公司EPR产品–HOSS,一个支持公司全国所有业务开展的管理后台,有没有做到把产品做到团队所能做到的极限?有没有在用户面前保持谦卑?我认为我们团队现在是没有做到的。产品在用户体验方面还存在很多需要完善的地方,存在很多用户骂娘的地方,存在很多用户都不知道怎么使用的地方。而我们团队并没有花太多精力去服务于我们的用户,一年来似乎都在匆匆忙忙地赶做老板们需要增加的新功能新模块,老板们最关心的是上线时间,于是前一个大功能刚上线,下一个全新的大功能又得投入紧张的开发中。整个团队没有人去关心我们的用户,没有人去问用户我们产品上线后用起来怎么样?这个过程中作为产品团队的我是应该负责任的,产品经理有时候就必须在服务于老板与服务于用户之间找到一个平衡点。一味地迎合老板的要求不是合格产品经理的应当有的职业素养,因为在做好一个产品的技术层面上,产品经理是比老板要专业的,迎合老板的不专业的意见而且还不给老板指出,这样的产品经理并不职业。

所以,接下来,我需要做的是:

1.完善系统的交互设计,让系统在可用的基础上变得好用;

2.解决用户的疑问并且改进系统设计,直到最蠢的用户都能上手使用系统开展工作;

3.完善系统的报错信息,让每一个报错信息都清晰明了。

目标:让使用系统最频繁的业务员不再骂娘!

2015.11月总结

充实而内容零散的一个月。去了售楼中心,修复了几个系统bug,参与了两个项目的原型制作,其中一个是互联网金融产品后台系统,设计原型过程中让我初步认识互联网金融产品。

工作

历时2天的业务调研。入职以来第一次去售楼中心调研,这次只身一人去的是苏州渭城区的一个在建的楼盘“俪珠华庭”。这次调研,我的思路是观察项目上的客户经理在售楼中心正常开展业务的流程,使用系统的操作习惯。整个调研过程中,我大部分时间是静静在旁边观看,也断断续续会询问一些问题。这一次调研结果还是让我满意的,自己真切地了解了客户经理的业务操作流程,同时发现系统不完善的地方。产品经理,真的需要非常亲近自己的用户才能够做出优秀的产品。

产品在做无用功,其实是自己的错。所在部门因公司组织架构调整更换了领导,我们产品线的工作方向也根据新领导的规划而有所调整,原定的计划全部搁置,新领导安排的“完善产品操作上的体验”排到优先级最高的位置,我们小组用了1个星期左右的时间,完成了第一版方案的原型制作。按小组leader的旨意,完善版方案的原型在UI上并没有过大的改动,基本只是改变原来的界面的元素布置位置,nothing special的一版原型设计方案,感觉小组的每一位都不是非常用心。也许道理大家都懂吧,ERP系统所谓的用户体验是基于业务功能性上而不是UI上的,如果非得一个星期内出一版完善方案,而并没有业务调研的基础的话,确实也只能动一动界面的布局什么的。出现这样的局面,其实归根结底是我们产品经理没有做好自己的工作,没有在领导面前去据理力争,没有尝试去将道理跟老板讲清楚。双方不在同一频道上沟通的时候,只能委曲求全地做一些无效工作以应付。其实,这是我们产品小组内部需要反省的最严重的一点。在互联网产品设计方面,我们的专业度肯定是高于老板的,如果老板的一些不合理的提议,我们产品经理没有将优缺点跟他表述清楚,没有跟老板据理力争,是我们产品人的不足,不是老板的不足。

面对面的沟通合作会更有效。HOSS系统的收支数据是跟我们使用的支付公司(快钱)的系统对接的,而这个月我们使用的支付公司的系统出现了2次事故。第1次是它们升级了支付系统,导致全国大部分未升级的POS终端的数据同步出现乱码异常,而在此之前,快钱并没有提前通知进行POS终端系统升级。第2次事故是出现一天时间内所有刷卡记录未推送的事故,而这个问题虽然过后他们帮忙重新进行了数据推送,但并没有正面回复过该问题产生的原因。跟合作公司进行产品对接上的合作,我觉得如果有条件的话,真的应该争取面对面沟通交流合作的机会,让彼此留在对方的印象中不只是一个闪动的QQ头像,而是一个活生生的人,或者是一个可以信任的同事。这样的话,沟通合作起来会更有默契,合作的效率更高。

初识互联网金融。11月末我们小组接手了公司一个金融后台的构建工作,是一个针对C端的理财产品系统后台。业务逻辑是在财务总监的主导下梳理完成的,我们是负责产品逻辑的设计。整个后台原型设计花费了3个工作日左右,还算是比较高效的。经过这一个项目方案的设计,我对于互联网金融产品有了初步的认识,非常有兴趣接着去研究互联网金融这个方向的产品。

生活

半个月时间都在感冒中度过,身体脂肪含量太少,导致气温差异变化较大的时候,自己的身体无法缓冲适应,容易得感冒。平均每两个月感冒一次,身体实在太虚弱了,是时候制定自己的锻炼计划了。

第一次当面试官

好屋中国2016年校招面试,我被国梁拉去一起面试应届生。面试前什么都没有准备突然就被招呼去一楼其中一个小会议室面试,心里还是有点紧张的。

今天参加面试的都是同济大学校园招聘会筛选的简历,下午总共来了4位面试的同学,其中3位同学都是硕士生。

第一位进来的是一位女生,学工业设计的,去德国包豪斯艺术学院交流过3个月。招聘经理在旁边问了一些基本的情况,包括自我介绍啊,自身优势啊之类的。交流的过程中,发现她之前并没有接触过互联网产品相关的工作,也没有尝试过去了解互联网产品需要的基本素质。于是我们就避开不谈太过于专业的问题,我只是问了一下,她手机里哪一款app是她最喜欢用的。她说“额,女生嘛一般都爱用美颜类的app,我觉得是美颜相机吧?不过,如果说到最常用的,当然是微信啦,我觉得微信的公众号非常好,可以订阅很多资料去看。”虽然我承认这样的回答是她的真实感受和想法,但老实说,我对于这样的答案是比较失望的,我更期待她说一个小众的我闻所未闻的app,然后给我详细介绍这款她最喜欢的app是什么样的。接着,我再浏览了一遍她的简历,努力去寻找可以交流的共同话题,但是这个来参加面试同学的简历,真的让我很难去找到我可提问的问题,因为我也怕去谈论我所不熟悉的领域,这可能也是大部分面试官的感受吧。然后我就再问了一下她关于包豪斯的问题,我问她包豪斯风格的工艺品里,她自己最喜欢的一款产品是什么?她迟疑了好一会,然后吐出一个英文“The BHS”,我期待地看着她,希望她给我介绍一下。她皱了皱眉头说“你不知道The BHS吗?”我说我不知道,然后她就说这是一款沙发。后面就听她介绍了一些她在万科策划部实习的一些情况,然后就没有然后了。面试官其实是非常想跟面试者聊天的,前提是展示给面试官的简历信息是面试官熟悉的,感兴趣的,能产生共同话题的。否则,呵呵。

第二位进来的也是一位学艺术设计的一位女生,她简历上显示之前在“移民帮app”实习过3各个月,做产品经理助理。然后我们自然就会问一些她实习中遇到的问题,比方说“你在实习的3个月中,具体是做什么工作?怎么去做的?”我们以为这个问题比较简单,但是这位同学回答得很困难,并说这是很久之前的事儿了,不太记得搪塞而过。招聘经理提醒说她带来作品来,于是我们兴冲冲地打开电脑去看她的作品。这位同学带来了2份平时做的竞品分析报告,一份是关于音乐类app的,另外一份是关于海淘类app的。这两份竞品分析真的很很普通,只是不断套用“用户体验要素的5个层次”来写,生涩难读且无趣。我心里想,其实我无非是想看看你怎么看待这几款app的,是你的观点,不是网上普遍的观点,也不是书本上用户体验要素要求的观点。然而让我失望的是,直到最后还是没能看到面试同学自己对于这几款产品独特的观点分析。

第三位进来的是一位学电子通信系统的女硕士,简历上写熟悉C语言、熟悉MySQL、熟悉TCP/IP协议之类的,觉得这位同学可能比较靠谱。但是聊下来,原来她的硕士研究方向是通信材料,而不是软件系统。对于编程语言是基本了解,从来没有参与过软件程序的制作过程。感觉没什么共同话题之后,我就不多问了,留给招聘经理去问一些人事关心的问题,比如说性格特点啊,优势劣势啊之类的。

第四位同学是这次参加面试的唯一一个男生,同济高材生,成绩排名TOP 5%,且在Ebey实习过研发岗(NodeJS),在苏宁云商实习过产品岗,自己在学校也做过互联网学生创业项目 — 一个基于微信公众号的校园水果配送平台。基于一个微信公众号服务商提供的接口去做二次开发,开发时间半个月就上线运行,历时4个月后据他说是被其他的公司收购了,整个项目过程盈亏持平。面试这位同学,整体感觉非常优秀,可聊的点很多,于是就聊得比较久。这是今天面试同学中最合适的人选,不过我觉得他最后不会接受我司的Offer。

 

2015.10月总结

十月份是一个内心浮躁的月份,有很多想法,也有很多顾虑。主要还是工作的过程中,对于自己的工作内容以及个人价值实现产生了一些怀疑。刚进公司的时候觉得一切都是那么新鲜有趣,想去探索,而现在8个月过去了,感觉自己对于这个环境中的空气都熟悉到有点厌恶,感觉自己能力提高的空间遇到了瓶颈。这是一件自己所无法忍受的事情,毕竟我才23岁,我疯狂燃烧的岁月才刚刚开始。

工作

国庆长假在家宅了7天,上班后就投入到10月13号晚上的发版准备工作中,测试环境中的系统不断地出现各种bug,于是就不断地跟测试开发的同事商量解决。

10月13日晚,熬了一通宵发版HOSS一个大迭代,增加了影响面较大的几个主功能。然后后续的一个星期,都在解决因新迭代发版影响到的业务问题,包括跟快钱系统对接出现的刷卡记录不到达问题,新系统无法兼容部分老数据问题。

整个十月份,85%的工作时间都在解决业务同事操作hoss系统过程中遇到的异常问题,各种各样数据异常问题,人为的和系统bug导致的……每天,自己都是在充当传声筒,将业务的问题反馈到测试开发去查数据库里的数据,然后来断定问题,再解决问题。扪心自问,自己在这个过程中是没有成长的。

我每天都很担忧,产品这个岗位需要的技能很多,但是必须要的技能却很少。主动进修的人可以学到很多,主动去揽活儿的人能够学到很多,在一个比较有挑战性的团队能够学到很多…….道理我都懂,所以,要么改变环境,要么改变自己。

10月下旬,集团子公司考拉社区的VP微信找我,问我有没有兴趣过去他的团队做产品,我反应了10秒左右,回复“肯定啊”。因为我想换一个环境去挥发自己的热情。

上班路上跟一个关系较好的公司的前辈一起聊天,她真诚地劝我尝试去找一家做事风格不一样的企业去历练自己。我感谢她的真诚劝告。

10月末的一个傍晚,部门的boss临时打电话给我叫我去共进晚餐,席间他跟我说了很多。他说,领导分配你一个有挑战性的工作,最好的方式就是毫不犹豫地答应下来,并把事情做好,这样领导下一次才会分配更有挑战性的工作给你。我同意他的说法。

…….

生活

10月的尾巴,我跟媛媛去杭州旅行。我们的首站去了灵隐寺,每次去古寺旅行,总感慨寺庙的建筑风格才是最中国风的,最值得现代建筑设计借鉴和学习的。古寺配大树,让人置身其中,能够瞬间让人安静下来,让思维正在理性地去思考问题。

灵隐寺中,虔诚的信徒专注地跪拜,祈福。而有几个问题一直萦绕在我脑海中:跪在地上虔诚地叩头的信徒们,为何如此虔诚?

什么样的生活才是自己想要的生活?

什么样的事业是自己愿意托付终生的事业?

 

 

系统分析师和产品经理的故事

重零开始做一个系统的功能,产品经理跟系统分析师之间到底有什么差别呢?

以下是摘自知乎的两个故事,代表了两者之间主导工作过程的差别。

故事一(产品经理跟程序员)

第一天,产品汪跟程序员说,A商家要做活动,打8折促销,这个功能你实现一下,程序员照做了;
第二天,产品汪跟程序员说,B商家也促销,打7折,可以马上上线吧?
程序员一楞:怎么可能,这得一天;
产品汪:你昨天不是做过A商家的打折活动,复制粘贴一下不就行了吗?
程序员心堵:得重做。
产品汪:不都是打折吗?
程序员恼,不搭理产品汪,埋头重新做了一次;
第三天,产品汪跟程序员说,C商家做活动直降50元,程序员一楞,心里骂句MLGB不早说,然后又埋头重新做了一次;
第四天,产品汪跟程序员说,D商家做满300减80,
程序员怒了:你妹的,有啥需求你不能一次说清楚? 
产品汪也不高兴:妹的,这需求都是商家提的,他们也没同一天来找我说呀;
程序员说:你丫不会想想清楚,规划一下再给我?
产品汪说:这怎么规划,我又不是神仙,我怎么知道这么多商家会有这么多奇怪需求?
程序员说:这次老子认了,下次别找我。 然后把代码写了。
第五天,产品汪找到程序员:E商家要做“第一件半价”活动;
程序员:……!!……!!……滚!!
产品汪找到了开发经理:你们有个同学不配合。开发经理出场镇压。
程序员心里想:你小子给我记着,敢打我小报告,看我以后怎么玩死你……
第六天,产品汪找到程序员说:A商家不做打折了,他们也要做满400减100
……
有没有发现,这就是 产品 与 程序 之间的万年宿怨
产品经理:这帮技术宅态度有问题,一个个拽得258万似的,工作不配合,产品经常推不动;
程序员:产品经理就是帮213,完全没脑子,需求根本没有规划,今天提了明天改,明天改了后天加,大后天又玩新花样,动不动就说:这是老板要求的、这是客户要求的、这是用户说的,CAO!

故事二(系统分析师与程序员)

客户跟系统需求工程师说要做打8折促销,系统需求工程师马上想到打8折只是一个促销实例,
为此需要构建一个 促销模型 ,可以根据不同的促销方案 和 力度 配置不同的实例,
于是找到开发经理说:我们要搞一个促销系统,建议用策略模式实现,可以做成后台界面配置的方式,暂时只需要实现打折类型的促销,打折幅度需要后台可以配置,可以找个一两年经验的程序员搞一下,顺便让该程序员也提升一下对设计模式的了解和掌握,学到点新东西,相信他会觉得很有意思。
后来,客户陆续跟系统需求工程师提了无数种促销方案:直降、满减、买送……
程序员同学非常嗨皮的徜徉于 设计模式 的学习中,需求来得慢的时候自己重构重构,看着代码又优化了就幸福的忘了自己没有妹子,还不时主动攀着系统需求工程师问:哥们,客户有没有新的想法啊?比如,秒杀、随机免单什么的呀?现在很流行的,我可以做的!

其实这两个故事也很直观地反映出产品经理和系统分析师之间对于主导软件系统开发过程的差距,产品经理这个岗位是将需求转化成PRD的,而系统分析师是将需求转化成UML图的。从研发推进的角度来看,肯定是系统分析师占优势的,因为系统分析师是为研发分担了核心设计工作。

产品经理
主要技能:需求解析、画饼
主要工具:Axure、office系列、Xmind等
主要产出:概念、脑图、产品界面原型 等组成的 PRD
要求:思路清晰,头脑灵活,沟通能力强,推动力强

系统需求工程师
主要技能:需求解析、系统分析与设计
主要工具:UML工具
主要产出:UML架构图
要求:5年以上开发及架构经验,思维结构化、层次化,善与人交流

以其说这是市面上产品经理与系统需求工程师(系统分析师)之间的差距,还不如说这是产品助理和真正的产品经理之间的差距。只看过几本用户体验设计的书,就大谈产品用户体验设计的,不是产品经理,只是产品助理。而能够做到将需求转化为系统设计方案,并直接地影响着研发效率的,才是真正的产品经理。

 

三本产品入门书籍

最近花了点时间,好好研读了三本跟产品相关的书籍,分别是:

  1. 《启示录》
  2. 《简约至上–交互式设计四策略》
  3. 《点石成金–访客至上的网页设计秘笈》

1.《启示录》

产品经理的工作,可以说在不同的互联网公司,其职责与工作内容都不一样,而这本书就是告诉读者,标准的、高效的、硅谷式的产品经理的工作方式与工作内容。这本书把产品经理的工作内容事无巨细的提及到了,是一本产品经理的行事指南,其内容概况起来大多是“如果你在工作过程中遇到____的问题,你可以这样做。”比方说,产品经理如果在评估产品机会的时候没有头绪,书里就列出了几条切实能行的产品机会评估步骤。另外,作者全书都在强调在做产品说明文档还不如直接把高保真原型做出来这一观点。这本书是干货十足的“教材”型产品书籍,常读常新,没事的时候建议多翻翻。

2.《简约至上–交互式设计四策略》

这本谈论交互设计的书,谈得比较抽象,大多讲一些概念性的东西。给读者传达一种理念就是,不管是在设计一个网页还是在设计一个电视遥控器,都要突出用户需要的功能,删去不必要的文字和功能,力求坐在给用户呈现用户迫切使用的功能,本书强调了观察用户环境的重要性。

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

之前看网上说,马化腾在05年左右最爱这本书,并且给很多员工都送了这本书。今天看来,这本书确实好!!好在什么地方呢?这本书谈论的每个观点都有实例说明,清晰明了;对于网页设计的改进,作者会把每一版的改进都列出来,然后分析这样改进的原因以及效果。这本书我最大的收获是,基本知道怎样去组织一次可用性测试了,因为作者将一个真实的可用性测试例子放在书里。

这三本书都是非常棒的书,而我觉得在产品工作中可以经常翻看《启示录》这本行事指南,在网页设计以及产品体验报告中可以多参考《点石成金–访客至上的网页设计秘笈》这本书。

2015.09月总结

九月份是个心情复杂的月份,也许这是步入工作的必经阶段吧。入职公司第七个月,却不知怎的有种已在这待了很长时间的感觉。没有了前几个月刚入职时的新鲜感,甚至没有八月份自己扛迭代的使命感,九月份,其实是心特累的一个月。感觉这个月过得似乎异常漫长,经历的事情比前面七个月都要多。九月,心苦了。

工作

九月份的工作是在心受委屈的状态下开展的。回想七八月份,hoss产品组跟开发测试同事沟通最密切的是我,测试开发的需求问题,我是非常及时去应答,唯恐他们觉得产品经理响应不够迅速。从而也一度让他们误以为,HOSS产品组只剩我一个产品经理了。这样的工作节奏忙碌,但起码心是充实的。

九月初,研发部门更换了CTO,一场技术部和产品部之间的撕逼战莫名开启了。不知道是项目组里研发测试同事反映问题的时候歪曲夸大问题,还是研发部门领导有意为难。反正结果就是,我被自己老大劈头盖脸批了一顿,说我跟这次迭代需求变更过于频繁,并且跟研发测试的同事还有发生口头争吵。当时我真心体会到什么叫被冤枉,委屈和不解。那一刻,我对整个项目组的人感到寒心。幸好,Alan和大牙陪我聊了一晚上,让我也看开了很多。没有一份工作是不委屈的。

这件事情多多少少影响了我工作的积极性,然而工作仍需要推进,我也很快收拾好自己的心情继续投入到工作中。接下来,其他产品线的产品经理同样出现这种情况,也让我明白,以前推进产品迭代的方式并没有错。我还是不太放心,我又问了同组的资深产品经理国梁,我问他之前在易居工作的时候,推进产品迭代过程有没有出现这样的情况,他说易居的研发和产品关系非常融洽,从来未曾出现过研发这么苛刻要求产品的事情发生。

九月份的工作当中,我少了很多激情,也可以说是多了几分稳重吧。我尽可能地减少自己做产品需求决策的几率,有什么产品上的决策,我都会跟同组的资深产品经理商量。我自己心里也明白,这样的状态不是能做出好产品的状态,但是这样的团队氛围底下,我真的还没想到更好的独善其身的方式方法。

后续工作:

1、明确目标:学习做一套完好的企业后台系统的过程中,切实地将HOSS系统做到业界最佳(同比于竞品公司的系统)。

2、后续的行动计划:

一、研究同类系统,做调研分析;

二、取长补短,将学习到经验运用到现实工作当中,不断完善HOSS系统;

三、学会更好的与上级沟通的方式,让自己的想法切实融入到产品设计方案当中;

生活

9月26日,靖然和谨明的婚礼在苏州举行。这对恋人对于我有特别的意义,他们从接触、交往过程都有我的掺合,看到他们最后修成正果,心里真的非常开心,非常满足。

阅读

这个月看了三本书:

《关键词》梁文道著

《人物》

《大江大海1949》龙应台著

 

水下城池

水下城池,故名思议,就是被淹没在水底下的古老城市。

为什么我会突然对“水下城池”感兴趣呢,因为最近看了一本书,龙应台的《大江大海1949》,里面介绍到作者的母亲的故乡,浙江淳安,一开始我连淳安这个名字都没听说过,后来书里介绍到千岛湖景区的时候,我才恍然大悟。

千岛湖是著名的人工湖,因五十年代建设新安江水坝蓄水形成,那一千多个湖中岛屿,其实之前是一千多个山峰。千年古城淳安,就淹没在千岛湖底,一个祖先世代生活的城市,一个明朝海瑞曾再此任职四年的古城,突然之间就成了湖底之城,真的给人一种沧海桑田的感觉。

淳安,让我不由得想起另外一个命运相仿的城市,贾樟柯导演的《三峡好人》中的三峡移民城市—重庆奉节县。一个因为建设三峡水坝蓄水淹没的城市。

同样是因为国家兴土木而淹没掉的城市,我不能评判这样做是否值当,我只想借此代入一下,如果那是我的故乡,因历史的车轮滚滚前行,我的故乡被注定要作出牺牲,要被淹到水底,我的心路历程会怎样?

冯仑的《野蛮生长》

看完冯仑的这本《野蛮生长》,让我对冯仑这个人,对他创立的公司“万通地产”肃然起敬。

冯仑通过直白地讲述他自己的故事,来传达自己的世界观和价值观。对于我来说,这本书同时是我普及中国民营企业发展史的历史书。这本书主要谈论两点:快乐和伟大。

第一,快乐。冯仑认为有专业爱好的人比没有专业爱好的人快乐很多,越是专业爱好多的人实际上获得快乐的源泉也越多,他也会更快乐地应对生活,更积极乐观地面对现实世界。因此想快乐有一个好的办法:发展你的兴趣,扩展你的特长,然后使自己陷入一种痴迷状态,你就会很快乐

第二,伟大。冯仑认为伟大主要靠两点,一是时间,二是时机。

时间,是指要做一件事情是否能够坚持足够长的时间。一件事是不是伟大要靠时间,阿拉法特做了45年之后,国家还没有建立,但45年已经成为一个成就,一个传奇,所以这45年是一个阶梯。所以当你要做一件你希望它伟大的事情时,你首先要考虑你准备花多少时间。如果一年,绝对不可能伟大;20年就有机会了。

时机,是指选择做事情的合作伙伴以及地点。 “所谓创造历史,就是在伟大的时刻、伟大的地点和一群伟大的人做一件庸俗的事情。”他以万通地产竞标建筑纽约世贸大厦重建工程成功为例,万通集团作为第一个非美国本土公司竞标获得重建世贸大厦的机会,当时也很多人反对他们去做这个事,很多人不解,很多人阻挠,然后做这个项目的过程也很繁琐以及普通,但是他们最后却创造了历史,成就了伟大。今时今日,伟大的时刻就是中国经济快速发展,互联网技术突飞猛进。伟大的地点就是中国的一线城市。伟大的人就是那些有成就伟业激情与梦想的人,在他们身上可以看到闪闪发光的热情,而不只是为了挣一笔钱的那些人。我相信,这些人聚在一起能够产生化学效应,即使最后没能真正改变时代,也如流星般划过长空。最后的最后,也还会被一些对着流星许愿的人们记得,并承载了那些人的美好愿望。

与伟大相反的就是虚度人生。那就是在平凡的时刻、平凡的地点和平常的人做一些平凡的事,并去议论一些伟大的人与伟大的事。

20–30岁,是最有激情和梦想的年龄段,我想跟自己说,不要害怕试错,不要害怕未知的领域,去找寻伟大的人,去捕捉伟大的时机吧!

 

 

从R0827到R1013,迭代计划延期47天的故事

R0827、R1013是我们公司后台系统的产品迭代号,R0827的意思是该迭代计划8月27日上线。

       下面是我跟进R0827迭代的故事和其中的故事:

        这个迭代中的部分功能是从7月份就组织过评审会跟研发测试同事沟通过,那时HOSS资深产品经理余哥还在。其中大部分功能的起始设计规则都是余哥操刀的,余哥8月初离职后,我和国梁将这个产品线接了过来。

        8月5日,新的HOSS产品组针对于该次迭代计划的功能组织了第一次需求评审会,国梁是现在HOSS产品线leader,因为我比他早入职公司,所以这一迭代的功能设计我比他要熟悉。第一次需求评审会,是我作为主讲,把该次迭代功能的主流程过了一遍,然后由测试部门的同事提出问题。测试同事提出的几个问题,主要是计划的功能影响到系统原有的功能,当时就把我们问蒙了,只能说“我们产品回去再考虑一下这个影响的解决方案”,然后草草收场。

        接着第二次、第三次需求评审会也还是这样,这次迭代的功能影响深远,套用前任产品经理的话说,这个迭代的功能基本可以算重新构建一个系统的工作量(当然,这也是接口啦)。直到第四次的需求评审会,我们才把主流程全面跑通,开始落到每个页面的展示规则上来讨论。前面三次需求评审会,都根据测试同事提出的问题回来反复调整原型图,并急急忙忙去跟业务部门同事做调研。第四次需求评审会终于是结束了,那时已经是8月12日。距离8月27日上线还有15天。

       后面就是跟迭代开发的过程,我一直奔忙于产品部办公室和研发部办公室之间,任何人员对这期迭代的功能有任何疑问都找我确认。有很多疑问,其实我也不知道怎样做决定比较好,因为我对于该系统以前设计的功能的很多细节也还是不够熟悉的,很多时候测试抛出一个需要产品确定的问题的时候,我很犹豫,因为我没办法自信地评估全部影响面。而且,我这次做得最最最不到位的一点是,在跟各个同事沟通确认下来的细节需求后,没有记下来并修改原型。后来,会导致同样的问题,测试同事问我跟研发同事问我,我的回答是不同的,因为我在两个模棱两可的需求决策中,我心里潜意识会想“这个需求不影响主流程啊,哪个方案都可以接受。”于是,就导致后面我自己都不记得自己定下来的规则是怎么样子的。半个月时间里,我基本在重复上述的错误做法。开发周期将近一半了,测试用例评审会过程中,还是存在很多没有定下来需求,只能在测试用例评审会中定。

       经过这次的教训,我明白了一个道理:产品在原型上多花一个小时时间去尽可能完善,会给测试开发同事多省下几个工作日的时间。

       所以,以后:

       原型文件及时更新!

       原型文件及时更新!

       原型文件及时更新!(重要的事情说三遍…)

       8月27日上线是之前领导定下的一个非常理想化的计划发布时间,研发同事在熟悉原型需求以及评估开发量之后,调整了计划发布时间为9月17日。后来因公司其他产品的一些紧急迭代上线,占用了研发资源,所以又把之前的大跌代发布计划由原来的9月17日推到了9月24日。在产品研发测试同事都憋着一股气为在9月24日上线做努力时,领导一句话就把9月24日发版的迭代推到了国庆节后,即10月13日。据说是因为国庆小长假是房地产销售黄金时段,新系统上线会在一定程度上影响业务人员的工作效率。于是就有了R0827到R1013的故事,项目足足延期了47天。

      最后总结一下这期迭代总结到的产品经验:产品跟测试开发之间的合作,每个公司的工作流程和习惯都不一样,而产品经理的工作就是在不同部门的合作中寻找平衡点,比如原型精细程度与时间成本之间的平衡点,开发成本与功能实现之间的平衡点。每一个公司都有其特定的工作氛围和环境,最适宜这个环境下的平衡点就是最佳平衡点。只有熟知这里的游戏规则,才能最大限度地去利用规则做好自己的产品。

     还有就是,原型一定要画得仔细、再仔细、再仔细…….