葵花点穴手 定---走出软件作坊:三五个人十来条枪 如何成为开发正规军(二十四)...

我的手下经常会面临这样一个问题:客户必须让咱们按他们的需求改,您看怎么办?

这种情景大家可能很熟悉,一个业务处理,可以这样处理,也可以那样处理。你的软件采用了你的处理方法

,客户采用了客户自己的处理方法。两种方法平风秋色,没有优劣。但客户用惯了自己的方法,所以必须让

软件改成客户自己的方法。

不改吧。没有理由,因为两种方案都差不多,但客户就是客户,客户占上风,否则就不验收不给尾款。改吧

,又有什么意义?这家客户习惯了这种方法,下一家客户又不适应这家客户的方法怎么办?到一家改一家?

这都成了什么事。

我也深被这种问题困扰,至今没有好的解决方法。但我仍然力求找到一些方法去改善。我就是这样一个人,

能改善一点就改善一点,量变就会发生质变(当然,做这样的管理者需要时时观察细致分析研发过程中的问

题)。我这几天看丰田管理方法,丰田连一个工人的左右手空闲和手臂抬高高度和次数都做了细致分析。因

为手臂抬高高度和次数决定了这个工人的有效的工作时间和工作强度,我们工作的时候如果老需要不断扭脖

子,我相信很快就会得颈椎病。

一个软件,经过多年的发展,不断的客户实施,加入了很多客户的需求。我们返回头可能会发现这样一个现

象:我们走的太多,我们甚至忘了我们为什么要走。当时当景,我们觉得客户说的在理,不修改就说不过去

,于是做了修改,但天长日久的修改积累,我们发现软件主要要解决的问题已经被无数的功能左延伸右扩展

,已经不是一个能一句话说清楚到底干什么的软件了。所以,做企业管理软件有句笑话:ERP是个筐,什么都

敢往里装。

说不清楚一个软件到底是干什么的,是个很大的问题。销售给客户说不明白,老员工给新员工说不明白(甚

至新员工不知道这个软件有什么价值,没什么存在的意义),渐渐的,整个员工群体都在糊里糊涂的工作,

反正有这个产品在,就打电话销售跟单呗,客户问什么都说软件都有都能满足。研发呢,客户有需求就修改

。实施呢,签了单子就去实施,有什么软件功能就教用户怎么使,然后尽量让他使起来,管他需要不需要,

管他急需不急需,管他合适不合适。支持呢,有问题就回答。大家都在做一天和尚撞一天钟。

我想到了曾经看过的微软的一种方法:

对于什么目标市场的客户(一定要精确描述好你的目标市场,千万别用什么中小型企业之类的词语)而言,

你的什么产品或服务(针对这类目标客户,你提供了相应的什么产品或服务,这个产品或服务一定要与你的

目标客户匹配),提供了什么主要价值(要精确,千万不要说提高了管理水平。管理这个东西很模糊,就类

似这个企业管理水平低,到底指的是什么),因为你的这个产品或服务提供了什么独到之处(一定要独到,

否则人家为什么买你们,而不是买别人的)。

这是微软的一个产品定位方法。

还有一种我自己总结的方法:干什么,用什么。

例如,杀毒,用瑞星。聊天,用QQ。看新闻,上新浪。写文章,用WORD。就这么定位清楚。我们知道,QQ有

很多功能,不仅仅是聊天,新浪也不仅仅是新闻。但我们能把我们的企业管理软件也讲的这么清楚就非常好

了。记帐,用XX软件。记录进销存,用XX软件。但偏偏这个世界发明了几个很高的词,还云里雾里解释了很

多,越解释让客户听的越摸不着头脑。如:SCM、ERP、CRM、Web2.0、SOA。而做企业管理软件,却又往往要

遇到这几个词。落实下的产品到底是不是SCM、ERP、CRM、Web2.0、SOA,自己和客户谁都不明白,只能是客

户目前有什么需求(这个需求可能根本不属于这些范畴)就做什么需求。

为了防止软件成为大杂烩(想起了猫扑,我一直不知道这个网是干什么的,只好把它定位于搞怪集中地,但

好像也不对。年轻人的门户,好像也不对。),我经常用微软的方法和我自己的那个简单方法来校验产品,

定期给大家传达,让大家渐渐模糊的产品印象又清晰重点起来。

我们也会经常一起讨论,我们的产品最适合什么样的客户,第二适合的客户是什么样的客户,第三适合的客

户是什么样的客户。由此不断校正我们的目标客户群,调整我们的营销策略、销售策略、定价策略、服务策

略、需求定制策略。

我们在描述最适合什么样的客户的时候,为了描述精确,用的方法是拟人法。

我们不会泛泛而谈,我们会从现在的客户群中找出最适合的已经购买使用了我们产品的客户。一一描述他们

的组织结构、企业文化、老板性格、老板管理风格、中间干部的管理流程、考核方法。不过,往往我们无法

找出一个完美客户,能把我们的软件各个功能都是用的很好的客户,于是我们就拼凑,把各个功能使用优秀

的客户分别挑出来,然后都按照组织结构、企业文化、老板性格...等等这些方面来描述,然后把他们综合在

一起,一个“完美”的最佳客户就出来了。

我们在讨论期间,为了深刻的体会,往往都把这些客户的公司名称,城市(中国真是差异很大,东北人,浙

江人,广东人,截然不同),用户姓名,部门,年龄,性别,婚姻状况,从业经历,性格,如何思考问题,

他讨厌什么,他喜欢什么,他关注什么,家乡,什么学校毕业,计算机水平,工作环境,每天大部分基本在

干什么事都描述下来。如,我们老说:XX公司的XX,老喜欢反对别人的意见,不管别人是对是错,总要说出

自己的意见,显得自己很独特。还老爱用手那样捋一下头发。唉,他也是三十五六岁的人了,但还是个小头

儿,老觉得自己满腹经纶老板不赏识。

这样,一个活灵活现的形象就出来了。我们大家的讨论就有了基础。省得老有人提:不可能有这样的事情,

谁傻蛋了这么想。但一说到现实具体例子,大家就都明白了,确实是林子大了,什么鸟都能飞出来。(可能

也有鸟人)

我们以后去做销售、实施的时候,就把当前这个客户和我们设计的这个最佳客户进行对比,很快就能分析出

这个客户最适合使用哪部分,它的优点在哪里,它的缺点在哪里,它的差距多大,从什么方面去提升。所以

做销售,总是很快能把握住客户的兴奋点,做实施的时候也很快能根据客户的关注重点来突破和提升。其实

这种方法,在业界有个很标准的名字,叫“标杆法”。

我们描述完最佳客户,我们就要去列举这个最佳客户的需求。我们到底要解决这个最佳客户的什么问题?

一个企业的经营,都有一本难念的经。每个阶段都有烦恼,小有小的压力,大有大的臃肿,中不溜还上不上

下不下难受。各个方面都会有问题,从老板的管理风格,到企业财务核算,到企业财务报销,到企业考核,

到招聘培训,到销售到服务,涉及到各个层次各个角度。真要数落问题,每个公司数完后都觉得这个公司没

救了,但事实上这样的公司还活的好好的。所以,看事情要平和,你眼睛老盯着灰暗,你会觉得真个世界都

太黑暗了,你活着太痛苦了,这就不对了。这真是自己跟自己过不去(有句笑话:饿你两天,你啥也不黑暗

了,能吃个窝头也感动的痛哭流涕)。

所以,如果我们真要去解决企业这么多问题,我们也不是万能公司,也没有能力解决。我们只能解决我们擅

长解决的问题。但是我们擅长解决的问题,真的是企业现在急需的吗?这又是一个问题。解决了也不疼不痒

,那企业怎会买单?

所以,我们把企业急需,而且我们擅长的,而且我们的解决方法是我们的目标客户能够执行的(别想出一个

解决方法,但要人要钱要时间,哪里有这么充分的条件?这样的解决方法说明就不可行),而且解决后能有

明显效果(很多东西是长期才能看出效果,这类问题的解决就比较痛苦,我们不希望这么做,这样会使观望

的客户的投资购买延迟),而且客户愿意为这样的解决方法买单,而且买单的金额符合我们的盈利目标(我

们也不是雷锋)。

经过这样一筛选,确实剩不下几个急需解决的问题点了。有时候大家讨论偏了,还会讨论到什么点都不剩了

,于是停下来,重新过,不要讨论的那么极端。然后大家在这些问题点上统一认同。我们做营销,就是针对

这些问题点提出我们的解决方案。我们的软件发展导向,也是趋向解决这几个重点问题点。这样,我们的营

销和产品就是统一的。就不会出现我们老看到的一些现象:营销说的是一个东西,拿到手是另一个东西。

全公司同一个思路,同一个目标,这是最厉害的。(这让我想起了,有人曾经想拿UML把客户、设计、开发、

测试都串在一起)。在软件公司中,把营销、销售、开发、实施、服务想串在一起也是非常困难的,大家对

客户的体验是不一样的,关注的重点也是不一样的。所以,用这种方法来描述客户,描述客户问题,全公司

的认识就统一了(当然,那些技术至上者除外,他们可能只想借公司资源把自己练成高高手,我直到现在也

不明白练成高高手而不能解决客户问题到底是为了什么要练。我过去深入学习组件技术,搭建业务平台架构

,学习数据库技术,皆为解决客户手头急需的问题。客户其实只想解决问题而已,什么技术都无所谓,只要

能解决了,最好是越简单越好的解决方法)。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
内容简介   《IT项目管理那些事儿》采用叙事的风格,通过11篇来自一线项目经理的实际经历的文章,分享项目经理人自身的实践和经验的案例,阐述项目管理的实施过程、项目经理的成长和团队成员的培养历程,从而和读者达到共鸣并跟随作者叙事的脉动,以从中得以进一步的思索和升华。   简而言之,通过感受项目经理人的喜怒哀乐、经验教训,达到“它山之石可以攻玉”的目的。   《IT项目管理那些事儿》适合软件工程师、测试工程师、项目经理、IT经理人阅读。 第一篇 项目篇 第1章 中小型民营IT企业项目管理记 1.1 项目管理是什么 1.2 背景介绍 1.2.1 个人背景 1.2.2 公司背景 1.2.3 项目背景 1.3 软件工程 1.3.1 系统概述 1.3.2 系统规划 1.3.3 系统需求 1.3.4 系统设计 1.3.5 系统开发 1.3.6 系统测试 1.3.7 系统部署 1.3.8 系统验收 1.4 之后的事情 1.5 项目经理感悟 1.5.1 大中小型项目管理的区别 1.5.2 系统架构 1.5.3 风险管理 1.5.4 沟通管理 1.5.5 时间、成本、范围和质量的平衡艺术 1.5.6 项目经理自身学习的加强 1.5.7 政治问题 1.6 民营企业IT项目管理之路 1.6.1 完善企业管理基本制度 1.6.2 领导者的学习 1.6.3 建立PMO组织 1.6.4 构建专业的IT项目管理制度 1.7 小结 第2章 电信行业应用软件项目管理案例 2.1 项目背景 2.2 项目阶段义 2.3 项目第一阶段 2.3.1 软件设计 2.3.2 项目团队 2.4 项目第二阶段 2.4.1 需求工程与需求管理 2.4.2 项目计划与跟踪 2.4.3 项目风险管理 2.4.4 项目流程规范 2.5 项目第三阶段 2.5.1 割接的技术准备 2.5.2 割接的组织与保障 2.6 反思与总结 2.6.1 另一种选择 2.6.2 项目经理的成长 2.6.3 对组织级项目管理的期望 第3章 说说银行项目那些事儿 3.1 引子 3.2 知己知彼,百战不殆 3.2.1 银行的基本背景 3.2.2 银行系统的特点 3.2.3 银行项目的特点 3.3 准备行动 3.3.1 项目的前期调研 3.3.2 前期调研的成果 3.3.3 项目成员的物色 3.3.4 项目成员的安排 …… 第3章 说说银行项目那些事儿 第4章 软件外包项目的项目管理和快速开发 第二篇 组织篇 第5章 IT企业PMO工作实践 第6章 小型软件企业CMMI评估实战 第7章 项目管理体系之形成与演变 第三篇 支持篇 第8章 IT项目经理的修炼 第9章 一家互联网公司的项目管理进化史 第10章 如何带好80后研发团队 第11章 项目管理之兵者诡道

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值