Blueveees 智富列车农民工项目产品线规划

摘自:《就这么做产品》P.90

产品愿景

创新一条围绕农民工职业生涯的培训就业、互联网及移动增值服务、信用体系建设及小额贷款金融服务的价值链。

产品线设计

第一层面业务:当前现金流业务,线上和线下的劳务派遣就业安置和职业培训平台,整合“寻求市场——争取订单——宣传招生——按需要培训——技能鉴定——劳务派遣安置就业——跟踪服务——信息反馈——评估分析——解决问题”的就业培训链。

第二层面业务:具有比较优势的业务,农民工web2.0 门户平台及相关的移动增值服务,通过将网上行为、网下培训用工历史等记录在库

第三层面业务:未来竞争业务,数据挖崛,建立农民工信用体系,扩展未来的金融服务

 

要特别注意产品线上产品的统一性,即产品规范。 在创新、继承、改进的设计方法中,作为产品设计师更要注重继承这个环节,所谓一个公司一个产品,作为产品设计师必须为产品的可继承性、通用性以及兼容性进行考虑。一个公司的产品不应该有两套视觉风格,在同一个功能模块的不同调用中不应该有两种不同的交互方式。产品的统一性可以体现整个产品的品牌。

麦肯锡三层面理论的核心

麦肯锡三层面理论的核心是建立并管理业务更新渠道、确保企业长期可持续增长。在企业确保第一层面核心业务——企业大部分利润来源——的基础上,选择投入增长潜能的正在崛起的业务——第二层面业务,同时为未来长远发展选择第三层面业务!

 

企业需要稳步提升,则需要在保证主要业务持续增长的情况下,不断的去发崛新的增长点

BCG矩阵

根据公司的战略定位、业务规划和产品生命周期等,我们要以用波士顿BCB矩阵评估与分析现有产品线。BCG矩阵中有四大产品类型:

瘦狗产品,即在一个低增长的市场环境中该产品又仅仅有低市场占有率,不妨理解为苟(狗)延残喘;

金牛产品,即在市场上高份额,低市场增长率,因为接近饱和期,是能产生持续现金流(可挤出牛奶)的产品;

明日之星:处于成长率高的市场,而企业有相对竞争优秀;

问题儿童产品:未来不确定性高,因为它虽然享有高成长率,但是现阶段竞争力较弱,市场占有率不高。

 

BCG矩阵主要是用于企业产品布局规划,其目标是将资源进行有效配置。一般的策略是逐渐放弃或卖出瘦狗级产品;尽量挤出现金牛产品,投入资源保持明星级产品的竞争优势并确保其市场占有率;投入资源将问题儿童产品提升竞争优势,使其成为明星产级产品。

IT项目中如何更好地控制客户需求

凡是做过不止一个国内的项目的项目主管人员可能都经历过这种场合:公司的销售人员兴冲冲的拿来一份与客户签订的合同交给你,声称这项目又搞定了,但 是当你拿过来合同(或者任务委托书)一看,关于项目范围的说明只有寥寥数行,要么是一些高举高打的套话,要么只说项目都包含什么样的模块,而对具体的业务 只是一两句话就完事儿了,如果是一位身经百战的管理者并且对于项目的具体业务很熟悉还可以,如果不是那该如何开始这个项目呢?还有一种情况,客户在项目进 程中,不断对移交的系统提出修改意见,更可气的是,有些问题开始提出更改,某一天客户突然就发现情况不对,又要求你给改会来,看起来客户的需求总是无穷无 尽,作为项目的承担者该如何应对这种令人沮丧的局面呢?

一、客户需求为何过渡膨胀

作为项目的承担着,在规定时间用有限的资源来保质保量的完成项目,让公司和最终客户都满意是项目组的神圣职责。但是为了让客户满意就要满足客户所有的需求吗?因为不断满足客户的需求会不会导致项目失败怎么办呢?为了弄清楚这些原因,首先应该找到这些问题发生的根源。

1. 签订合约的时候,项目范围描述不清楚。这是最常见的问题之一,也正是早期的这些问题没有引起项目组的足够重视,导致后期项目无穷无尽的修改。

2. 客户和项目组对写成纸面文件的需求理解不一致。这种情况也较常见,虽然客户已经确认了项目组提交的项目范围说明书,项目组也是完全按照这个文件规定的内容 做的,但是客户还要求改,当项目组拿着纸面的文件与客户对质的时候,才发现客户也认可这需求,但是同一件事情,客户的认知和项目组的认知完全不同。举个简 单的例子:客户要求系统能够电子签名,项目组的成员就模拟了一个,自动产生客户的签名在系统中,但是当移交给客户的时候才发现,客户要求的电子签名实际上 是想把原来手写签名的工作也移植到电子化的系统中,让领导能够通过画图的方式产生一个手写的签名在文档中应该落签字的地方!有时候就是当初一点点疏忽,导 致项目后期大量修改甚至项目延期。

3. 客户总有在结项之前把每一件事情都做得淋漓尽致的初衷。一般来讲,在项目结项之前,客户都会把所有的想法尽量逼着项目组解决,因为一般的客户心理都会认 为:一旦结项了,再想找项目组成员对业务系统进行修改可就难了,因为IT公司人员流动性强的特点,即便以后能够找到承包商,当初做项目的项目组成员也不一 定在了,或者很多公司因为业务繁忙,已经顾不得原来已经结款的客户了。

4. 项目组人员总是无条件迁就客户,客户有求必应。这种做法的出发点是好的,目的是要客户完全满意,但是实际上这种做法不一定能达到目的。一般的客户需求都是无底洞,这样做对整个项目经常也会带来很多负面影响。当然,如果过分控制客户的需求,客户肯定也不会满意。

二、解决办法

针对上述项目问题以及发生的原因,结合以前一些项目的教训经验,我感觉可以通过以下几点来有效屏蔽客户需求过渡膨胀的问题,让项目完成得更加漂亮。

未雨绸缪:

项目初期一定要制定清晰的目标和项目范围,并且让项目主要干系人(最重要的当然是最终客户了)确认。

不管通过什么途径得到的项目,作为项目主管,在项目前期,可以分三步走。

第一个想到的问题应该是“为什么”,也就是客户做项目有什么目的,知道这些以后,才能在以后的工作中更加想客户之所想,不至于项目方向错误,最终争取达到双赢得局面。

知道了“为什么”以后,接下来就要非常清晰的知道“做什么”,有一个比较好的办法就是用一两句非常简洁的话概括出来整个项目,并且能够用这种方法概 括出项目中的各个子任务,并且能够让前台业务人员和后台研发人员都能够心领神会,那么说明项目主管对项目的内容在大方向上已经有很好的把握了。

最后就要弄明白“怎么做”了,对于比较陌生的项目来讲,这一阶段工作量比较大也很重要,在

这个阶段多花点精力绝对值得,当然,根据具体的情况,也可以在这个需求调研阶段简化一些不必要的工作,这需要项目主管具备平衡那些彼此冲突的项目目标的能 力。在实际的工作中,这需要一个过程,值得注意的是,在需求整理完毕形成文档以后,最好先让项目组人员把自己总结的需求跟客户比较详细的讲一遍,在实际的 操作中,这种做法不仅能够把项目人员与客户在业务层面的歧义问题数量大大降低,还可以很好的发先潜在的问题,并且掌握一些沟通技巧,也会让客户更能深刻的 感觉到承包商对他们的重视。另外,如果项目前期得需求人员对技术非常不了解,根据实际情况最好在需求每次提交给客户前与研发人员沟通,以避免不必要的给客 户的承诺,更加准确的界定工作量。总之,有效的计算出项目范围将会占用一定的时间,但是同样会节省资源、资金以及解决项目今后令人头疼的问题,例如:需求 (范围)变更。

另外一个很值得注意的问题是:项目的需求经过几次确认以后,要让有权力的客户明确确认,最好有书面签字,这个有说服力的文件会在以后客户发生需求变 更的时候起到很好的作用,很显然,因为客户已经签字确认,总是反悔肯定理亏呀,即便因为业务变化不得不对项目进行大的调整以至于项目延期,这种情况下也会 是项目组处于有利地位,不至于让自己的公司非常不满,甚至可以以此为依据来要求客户重新考虑项目经费。当然,对于客户来讲,通过这些很好理解的需求的阐 述,也会以此作为以后交付产品的依据,做到心里有数,消除不必要的疑虑,这个对双方有同等的约束力,很有好处。

灵活应变:遇到变更要与客户沟通

经常有这种情况,项目都已经执行到最后阶段,客户突然提出了新的要求或者要求对已有需求进行更改,这会让项目主管非常为难:一方面要尽量满足客户的 需求,另一方面又不能对系统做太大的改动,影响进度计划。这种情况发生除了和需求阶段有关以外,同时说明在实施过程中没有与客户有密切的联系,缺乏沟通。

从客户的心理来分析。由于软件的特殊性,客户通常非常关注后期的服务,尤其是在国内大家做的软件绝大多数都是与实际业务紧密相连的。作为项目管理 者,非常忌讳的是在做项目的过程中对客户置之不理,而最后交付的时候才与客户突然发生大量接触,本来后期的实施过程出现问题的可能性最大,之前与客户又比 较生疏,很可能会造成非常大的风险。比较稳妥的办法就是在项目进程中也要让项目组与客户保持联系,相互了解,建立更加融洽和谐的沟通气氛,为以后关键的实 施移交阶段可能与客户发生的冲突做好准备。值得一提的是:在项目进程中阶段性的给客户呈现一下项目的进展状况,让客户对项目有一个更加直接可视化的认识, 更能及早的发现解决问题免除后患,在不断的沟通过中,应该让客户认识到项目组时时站在客户角度着想,让客户的主要负责人也能深深的感觉到他们是项目组的重 要组成部分、荣辱与共,并且项目组能为客户提供完善持续的后续服务,这样可以有效的避免客户绞尽脑汁想把所有的事情在第一次结项之前做完。

即便前期工作做得再好,很多情况下,需求变更是不可避免的。项目主管通过良好的沟通机制随时掌握变更情况和可能发生的变更,一旦发生了变更,项目组 一定要冷静处理这些问题,专家判断这四个步骤来首先评估需求变更,并且尽快形成项目范围变更书面的说明书,它是以后项目决策的基础,当然比较稳妥地办法还 是让客户对明显发生的变更做出确定(选择签字最好),尤其是在评估了变更可能导致的工作量增加以后,让客户认识到过多的变更很显然会造成项目延期,客户对 此也要负责任。

在客户提出需求变更的时候,一定要掌握一定的沟通技巧,一定不要总是无条件迁就客户。一般来讲客户对IT都不太熟悉,他们认为很简单的事情,可能要 花费项目组大量的无谓得多余精力,所以千万不要认为客户所说的就一定是他想得到的!大部分客户都是第一时间突然脑海里面冒出的火花,所以项目组人员要冷静 的分析一下:客户到底想要实现什么目的,抓住问题得本质。一般来讲,实现客户本质的需求有很多种办法。在与客户的沟通中,一定避免与客户正面冲突。在初期 认真倾听客户意见,多问一些“您还有什么想法”之类的问题,等客户把他的想法都表述清楚以后,项目组成员成员最好迅速评估一下客户的建议,如果实现起来实 在太困难,可以给客户一些更加中肯的提议,多问些“您看这样行不行?其实可以达到同样的目的。”之类的问题,最后还有一个重要的过程就是要与客户确认这次 沟通的结论。

总之,项目整体管理是平衡那些彼此冲突的项目目标的一种能力。看起来简单,但是实际上很复杂,项目主管在项目进程中要学会如何对常见变更进行控制,控制客户需求的肆意膨胀,保证项目健康稳定的进行。
1. 在项目启动时,公司会批准一个新的项目阶段的开始。
2. 在范围计划编制的过程中,将制定一份说明书来描述在项目中将做什么。
3. 在范围定义中,项目的主要部分被分成更小的部分。
4. 在范围审核时,需要验收项目的范围。
5. 在范围变更控制中,随着时间的过去,需要对项目范围变更进行监督。

客户需求

客户的需求往往是多方面的,不确定的,需要我们去分析和引导,很少有客户,尤其是消费品的购买者对自己要购买的物品形成了非常精确的描述,这时就需要增强对客户的沟通与互动,对客户的需求做出定义。

定义客户需求是指通过与客户的沟通互动,对其心中设想的产品或购买产品的用途、功能、款式等进行逐步求精式的发掘,将用户心理模糊的认识以精确的方式描述出来的过程。