供应链式项目管理

最近我们重新规划和设计敏捷项目总体流程,对需求伊始直至项目上线的目标、指标、时间节点和责任人都做了定义。但当我们制定更详细的计划时,发现一个严重的问题:这是一个“梦幻日程计划”。在项目生命周期管理的探索与实践上,我们经历过瀑布式、迭代式、增量式以及混合的Scrum敏捷式,如果只针对项目管理而言,我相信在一个Sprint周期内,做到“一切尽在掌握”是可行的,但放眼至一个季度甚至半年的最终目标上,梦幻计划的完美主义的思想又成为了另一个极端。 继续阅读

产品出来后

把产品做精,先有用,后能用,最后好用。有用就是抓住核心价值,核心价值都没有的产品就是浪费生命;能用就是能走通流程,完成既定情景下的操作,另外就是稳定高效。还不能用就不上线,能用就上线再慢慢优化改进;好用就是上线后不断优化用户体验,根据用户需求和运营需要,对功能推陈出新,使产品趋向完美的过程。

运营伴随着产品的生命周期起始。成长期做产品式运营;成熟期做营销式运营,颠倒次序会搞死所有人。产品式运营的目的就是让产品更好用,需要数据的支持和分析。数据是避免主观决策的基础,没有产品式运营,做产品就是自娱自乐;营销式运营的基础是产品好用,也就是用户体验好。残疾的产品不抓紧时间优化,神马KPI神马用户活跃度都是浮云。

拿出20%的时间思考、交流、学习,井底之蛙做不好产品;拿出20%的时间建设团队,21世纪人才最珍贵;拿出20%时间做好规划和计划,并跟进计划及随时调整,及时沟通统一目标;剩下的时间去解决问题、设计方案。对员工,除了给20%的时间去思考,要求80%的时间完成100%的执行力,激励要落到实处。

控制好节奏,把握好需求出口,一步步来;承担责任,不扯蛋,抓紧时间。

推荐一本书:Thinking in UML

推荐一本目前正在读的书:咖啡小驻的《Thinking in UML》(09年度行业畅销书)

这本书以UML为载体,将面向对象的分析设计思路融入的建模过程中,从理论到实践,深入浅出,是一本不可多得的好书!

适用于软件设计师、架构师、程序员、产品经理、产品设计师……当然,其中的建模方法对其他行业的童鞋认识和分析事物也有所帮助。

站在产品经理的角度讲,这本书提出了需求分析的一种标准化方法,并介绍了建模工具Rational Rose的使用。用Visio画流程图,用Rational Rose建模做用例,用Axure设计交互原型,很好很强大的产品设计组合。

点击以上购买链接可以直接购买《Thinking in UML》,相信我,绝对值这个价!

最近太忙了,让博客休了个长假。在这期间付出了很多,也收获了很多,生活也有了新的憧憬,下周开始继续更新博客吧。

互联网初级用户带来的思考

年初的时候,UCDChina上掀起了一股“装不装用户”的话题热,当时本想凑个热闹,可总觉得拾人牙慧没什么意思,只是看了个热闹。从keso的别装了,你不是用户,到白鸦的装,是必须的,都是一个设计者对待自己产品的态度,而其中最为矛盾的问题就是,设计者在设计产品时,往往都无法站在用户的角度考虑问题。其中最重要的原因,一方面是设计者不了解用户需求,另外就是设计者与用户对产品理解上的巨大差距。刚刚我很无奈又很耐心的装了一回设计师,而我老爸就是我的用户,我在向他介绍如何使用QQ这种工具,而他则无比的焦虑和烦躁。因此,我才在“装不装用户”这个话题结束一个月之后,才觉得,自己真该为此写点什么,为互联网的初级用户写点什么。

老爸是一个网民(CNNIC发布的09年中国互联网行业报告将“半年内使用过互联网的6周岁及以上中国公民”定义为网民),很初级的网民,但我相信他这样的用户,在中国占绝大多数。刚刚他只是在使用百度查找手机方面的信息,看到一款喜欢的,想知道这款手机商家的联系方式,但是却找不到,于是打电话问我如何查找。我叫他上Q,想叫他将地址发给我,我好帮忙看一下,事情的经过大概就是这样。注意,问题来了:

1、截图

我需要那个网页的截图,通过QQ截图工具可以很好的达到这个目的。我告诉了老爸截图的使用方式(之前他从未使用过截图),而老爸的问题在于:不知道什么是截图(解释了10分钟);以为点击截图后,能将QQ的聊天记录隐私截图下来被我看到(所以先清空了聊天记录,虽然那是我跟他的聊天记录);以为截图只能在QQ聊天框以内工作(所以给我截的前10副图都是聊天记录中的空白);不能理解“按住鼠标不放选择截图区域”;不能理解为什么要“双击截图区域”……我用了一个半小时的时间在电话里解释,最后他终于成功的对所需屏幕区域的“截图”;

2、复制粘贴

我需要那个网页地址,通过在地址栏复制,在QQ聊天框粘贴后发送,即可实现。我一步步告诉他,双击地址栏,右键后选择复制,回到聊天框,右键后选择粘贴,点击发送(我是不是很有耐心?)。而老爸的问题在于:不知道什么是地址栏(最后我截图告诉他,还好之前明白了截图是什么);复制后,没有任何变化和提示,他以为没有复制成功,于是复制N次(这个问题……);回到QQ聊天框后,他又去点击网页,准备复制地址,可是QQ聊天框又消失了,于是他在两个程序间不停切换(不能理解复制的内容在系统内存中保存);成功粘贴后,觉得一大堆乱七八糟的字母错了,于是删掉了后面的内容,只发给我了网站主页地址……后来,我又用了半个小时解释,他终于成功将那个网页的地址发送给我了;

当我以为终于成功的时候,打开那个网页,发现那是百度的一个搜索页,页面中是他要搜索的产品结果。他说那个网页找不到了,说自己头疼,早点睡吧!

而后,我马上写下了这篇东西。我在想,为什么我们平时认为如此简单的操作,在大多数网民中(我相信我老爸代表了绝大多数网民)竟是如此困难。刚刚我老爸的烦躁和焦虑,我身同感受,还好他是我老爸,如果那是我的客户,相信早就拂袖而去了。

我相信很多人看完后,都会觉得是我爸代表的大多数网民仍旧处于低及应用阶段,这不是产品的错,但问题的关键在于,他们是网民,他们是客户,难道客户也有错吗?对于我爸而言,他获取信息的渠道太多,为什么要通过上网,使用这些让人觉得自己是白痴的操作程序,去自作自受并且浪费时间呢?还不如去打个电话问问朋友(客户有很多选择,我们的产品并非唯一)。

我们是高级网民,我们是互联网专家,我们总以为自己设计的就是正确的,自己应用的就是最正确的。我们装成用户去设计、去思考;如果用户不买账,我们要培养用户,教会用户。而我们从未想过,为什么没有专门为初级网民设计的电脑和互联网呢?这只是个工具而已,我们还有很多更重要的事情做。比如赚钱,比如享受,比如思考……

或许,我爸需要的电脑是这样的:她是人工智能的,可以直接跟你对话;她没有复杂的键盘,没有碍事的鼠标;你告诉她你需要什么,她会自己搜索后告诉你最佳答案和备选答案;她会分析你输入的信息,理解你不专业的表述,甚至根据你的表情、眼神、脑电波分析你真正的需求;她不会烦躁,不会嘲笑;她会告诉你喝酒前该注意什么,告诉你身边的人你喝多了需要帮助;她会告诉你去某地应该怎么走;会告诉你情人节到了,是不是给爱人送一束鲜花,或许,她已经帮你选好了……

或许科技最发达的时候,人类能将大多数精力直接用在需要的地方,而非搜索、寻找、比价这些需求的中间流程上,这时候的用户体验是最好的;而设计师的任务,就是不断的设计出更加强大和人性化的“她”罢了……

初级用户总是占大多数的。Iphone之所以是一个里程碑,因为我妈这种几乎不会玩手机的人都可以很开心的使用;我期待,IT行业的里程碑。

需求变更-要效率还是要规矩?

需求变更在项目管理中是经常遇到的问题,特别是当项目进展到尾声时,一个需求变更对成本产生的影相往往比项目初期成几何级放大。虽然我们在需求阶段细致入微,在开发阶段滴水不漏,在流程管理上规规矩矩,但无奈的是,我们的客户总是希望拿到更完美的产品。于是乎,变更就成了结项后的潮水,一波一波,无休无止。不是你的产品坏,是这个世道变化快……

如何对需求变更做科学的规划和控制?在做好需求变更管理的前提下,分级管理客户需求不失为一种很好的方法。但是如果客户的需求变确实需要在将要结项得产品中尽快体现时,应该如何处理呢?特别是一些在需求中非常重要,但从技术上很好实现的需求变更时,是否还要走正规的需求变更流程?要效率还是要规矩,就成了许多产品经理心头的疑问。

首先,需要确定:是否真的需要走需求变更流程?灵活点说,需求是变了,但走不走这个流程是另一码事。如果项目几乎结项了,这时的需求变更就像百米赛跑后,裁判说这个跑道不标准,少跑了一米要重新跑一样;一鼓作气后,项目团队都疲惫不堪时,再次击鼓的效果可想而知。其实针对这时需求的变化,特别是技术上很好处理的问题,直接在结项后作为升级内容即可;毕竟版本得改动可小可大,小的版本变更从流程上讲要比需求变更简单的多;

其次,还有一个偏方,是我最近经历的项目变更得解决方案,即将这个需求分解放在其他相关项目中完成。在项目日程已经排满,并且项目间有一定相关性时,这不失为一种好办法。如果项目是迭代设计的,那么采用这种办法再合适不过了;

最后,当非变更不可时,如果没有针对不同变更得不同流程得话,唯一要做得就是做好前后沟通了。在有正规流程时,走正规流程是必须的,也只有这样,项目才能真正可以控制。如果对流程不满,除非能够很快吧流程修改或完善了,否则一步一步做吧。所谓得追求效率而抛弃规矩,是对项目不负责任的原则性问题。

需求变更就像误差,可以控制,但又无可避免;但是因为前期工作没有到位而引起了需求变更,就太不应该了,错误是不应该出现的。出现需求变更时,先不忙着救火,而是冷静下来先考虑问题产生得原因,比做救火员要有意义的多。后面会详细讨论这个问题。

如何设定分类目录–我的目录是这样规划的

以下将介绍本博的分类目录设置,一方面为了对博客建设做具体规划,另一方面使读者了解本站基本内容。当然,这些分类下的具体文章的更新频率我会保持平均三天/篇,并保证原创。

1、产品
产品的概念很宽泛,具体的商品与服务,甚至一体化的解决方案都算作产品。由于本人目前从事互联网产品方面的工作,所以本博的产品多指IT类相关产品。当然,我不会机械化得对某个网站或者某样概念作评论;也不会跟风追潮报道每日的互联网新闻。我希望我所指的产品,首先是我比较清晰的理解后,分享给大家的东西,或者很有争议性的话题;当然,并不是每个人都从事着互联网或者产品相关的工作,但李彦宏不是说了么:“5年后不会再有互联网公司,因为所有的公司都在用互联网!”,这是产品方向的计划。而具体到产品本身,相信不管你是从事销售、市场相关的工作,或者技术相关的工作,产品都跟你有着或多或少的联系。当然,我也希望能够以博会友,还请大家多多指教。 继续阅读