市场至上，还是我们应当坚持原则

最近公司的状况有点不一样，市场明显已经占据了公司的重要的决策了，连公司的技术部门的老大都已经是售前工程师（这是一个体面的称呼）了。
让我来细细的审视一下公司的组成，市场部是由公司老总直接领导，再加上技术部部门经理做售前支持（其实就是演示系统），由此可以看出公司的状态已经是市场至上了。
感觉到非常的痛苦，已经到了痛不欲生的地步了，不知道各位的公司里面会不会有这个问题，就是市场部门与技术部门肯定会在某些方面存在着矛盾。
首先从利益的角度上来分析一下，对于市场来说，有奶便是娘，虽不可称之为一个公理，但基本上是一个定理。而从项目经理的角度来说，他们并不关心。而实际上项目实施的难度，大家都可以知道，对于项目经理来说，最大的问题在于，我们无法去把控项目。市场总是会考虑到下一个单子的问题，而对于项目经理来说，如何结束项目永远是第一位的。从现阶段国情来看，客户对于需求的反复是不可避免的。而对于PM来说，如何把握一个度往往是很困难的事情，经过几次需求确认之后，在项目经过验收之后，对于非系统BUG，而是需求变动的问题，项目经理往往不会再去承担，我们可以根据后续的维护合同，再去评估工作量，另行收钱去修改。
现实就是出于市场考虑，做为PM不得不去修改（免费的），市场、老总往往不会关心你修改了一个地方，在维护上收了客户多少钱，而是在意后续会不会有一个单子而来，往往会认为迎合于客户，我们就会有新的单子来。
对于小公司来说，这个问题肯定是普遍存在的。
对于PM来说，往往被迫改了某了个问题不是最重要的，而是客户会理所当然的认为，这是你系统的问题，最后到老总那里就是你都做错了，改还有什么好说的，“你做项目不行，连这个都理解不了”。事实上，笔者就已经经历过了需求的变动，从A-->B-->C-->A，这种，还有就是那种把原来的业务推掉，重新来一个新的业务的问题。却被认为是系统的问题。
我想我永远也无法理解有些东西，明明违背了原则的东西，为什么我们要去做，还要接受是我们系统的问题。
另外，已经感觉不到技术方向有何前进的路线了。

这种问题，不知道大家有没有遇到，又是如何处理的呢？

顺便说一下，大家有好地方，推荐一下，偶看看，要换地方工作了。（：P 高程或者软件工程师即可）

评论

11 楼 gigix 2008-06-17  

zqrain 写道

在我经历的几个项目公司里面，市场人员工作方式有问题，他们可以抱怨市场环境恶劣，而且甚至可以以此“洋洋自得”；但技术人员如果抱怨工作太多太复杂，多数会被鄙视为技术不行。比如因为需求变更引起的反复修改代码，人家不仅不会体会到你的辛苦，反而还会鄙视你，这么简单的东西还做这么。

你这个话我还是不明白。谁更希望项目成功呢？我认为是等着拿10%提成的销售而不是拿定额工资加一点奖金的项目经理。既然是这样，那么谁指的方向更有可能朝向项目成功的方向呢？

10 楼 zqrain 2008-06-17  

gigix 写道

jimmy.shine 写道

可能是我的表达能力越来越差了。gigix可能还是没有明白，做为市场部的，出于市场考虑是正常的，但是做为技术部门的老大，以市场为导向，引导项目，这就不正常了，不知道gigix是不是PM，能否接受到承担不是自己的错误的责任。反正我是不接受，可能是我的思维方式比较西式，对于是自己的责任，我一概承担，非自己的原因，一概不承担。这是我做技术的原则。

我不知道你能承担什么责任。照我理解如果项目失败客户不付钱损失最大的是老板和销售，你不管是作为项目经理还是作为开发人员你受的损失无非是少拿点年终奖而已，而这个损失是整个公司一起在承担的，你并不比其他人承担得更多。那么你作为项目经理只要你守住每天8小时工作时间不加班，那你（和你的团队）还有什么可损失的呢？你还能承担什么责任呢？我就不太明白。而既然你并不因为项目的失败而受多大损失那你又为什么还期望对项目的方向起多大的引导作用呢？这也是我不太明白的。

gigix的理性思维的确很强，赞一个先！

不过，事实并没有那么简单。从我以前的一段经验来看，会有两个问题：
（1）没有良好关系的变更，容易打乱工作计划，干扰项目经理和开发团队的士气，最终导致（或加剧）加班的强度和频度。
（2）变更引起的工作量会降低开发的绩效（从公司管理者和市场的角度看到的绩效），这个黑锅最终多数还是要项目经理来背。（特别是当项目经理的沟通和维权能力不强的时候）

对于第一个问题，可以用gigix的精神胜利法，不予理会。（你市场爱怎么变，就怎么变，反正我就工作8小时）。
但是对于第二个问题，就不是那么好解决的。这个绝对不是年终奖的问题，而更可能是职业生命的问题。

在我经历的几个项目公司里面，市场人员工作方式有问题，他们可以抱怨市场环境恶劣，而且甚至可以以此“洋洋自得”；但技术人员如果抱怨工作太多太复杂，多数会被鄙视为技术不行。比如因为需求变更引起的反复修改代码，人家不仅不会体会到你的辛苦，反而还会鄙视你，这么简单的东西还做这么。

9 楼 gigix 2008-06-16  

jimmy.shine 写道

可能是我的表达能力越来越差了。gigix可能还是没有明白，做为市场部的，出于市场考虑是正常的，但是做为技术部门的老大，以市场为导向，引导项目，这就不正常了，不知道gigix是不是PM，能否接受到承担不是自己的错误的责任。反正我是不接受，可能是我的思维方式比较西式，对于是自己的责任，我一概承担，非自己的原因，一概不承担。这是我做技术的原则。

我不知道你能承担什么责任。照我理解如果项目失败客户不付钱损失最大的是老板和销售，你不管是作为项目经理还是作为开发人员你受的损失无非是少拿点年终奖而已，而这个损失是整个公司一起在承担的，你并不比其他人承担得更多。那么你作为项目经理只要你守住每天8小时工作时间不加班，那你（和你的团队）还有什么可损失的呢？你还能承担什么责任呢？我就不太明白。而既然你并不因为项目的失败而受多大损失那你又为什么还期望对项目的方向起多大的引导作用呢？这也是我不太明白的。

8 楼 cnshenyi 2008-06-16  

1.PM首先要和销售能尿到一个壶里，就是你们要确定好一些底线。不知道你们公司有没有KPI考核制度，我想是肯定有几个指标的。你一个项目花多少工时早就应该在签订合同前就定下来了。
2.对于客户提出的修改，没问题，所有需求变更花的时间计入工时。超过合同签订额外，需要销售去签单，销售没搞定，你作为PM可以拒绝处理，这样你可以给销售压力。
3.你作为PM不单单是技术经理，你说的太技术至上了。你PM还需要和客户沟通。让他们承认你们团队为此系统修改所花的工时。要让他们领导肯为这些改动买单。
4.你要做国内PM的角色，不管是小公司也好，大公司也好，市场导向这点你都要去接受。你所谓的技术无用论在国内是普遍存在的，这是事实，你接受也好不接受也好，这是你需要面对的现实。但是你如果还偏向技术，你可以多去考虑怎么减少开发成本，怎么能让员工快速开发。这点还是值得研究的。

7 楼 selectme_2008 2008-06-15  

jimmy.shine 写道

gigix 写道

引用

现实就是出于市场考虑，做为PM不得不去修改（免费的），市场、老总往往不会关心你修改了一个地方，在维护上收了客户多少钱，而是在意后续会不会有一个单子而来，往往会认为迎合于客户，我们就会有新的单子来。

你说这话就说明你根本没弄明白作为PM你的所谓”原则“到底在哪里。
做了修改客户给不给钱，这事情和你一点关系都没有，因为单子不是你签的提成不是你拿的，你不负责这个事。如果说给钱你就给维护不给钱你就不给维护，你不是在坚持原则，你是在犯傻，因为你对自己不该负责的事情在做决定。
你应该坚持的原则是不加班，说实话，有多少工作量就说多少工作量，让客户来决定在有限的时间和资源范围内做哪些事情。一旦决定了你就把这些事情做好，不管你认为这事情实际上有多么傻x。

可能是我的表达能力越来越差了。gigix可能还是没有明白，做为市场部的，出于市场考虑是正常的，但是做为技术部门的老大，以市场为导向，引导项目，这就不正常了，不知道gigix是不是PM，能否接受到承担不是自己的错误的责任。反正我是不接受，可能是我的思维方式比较西式，对于是自己的责任，我一概承担，非自己的原因，一概不承担。这是我做技术的原则。

另外一点，在我们公司里面，是有绩效考核的，这与个人的工资直接相关，说白了，就是关系到我能拿到钱的问题。另外，做为技术人员，小公司的项目经理不仅要承担项目的进度，项目的开发，还要面对着几倍于程序员的编码工作，这就是小公司的现状。

另对于zqrain提出的关于需求的问题，这不是主要的问题，现阶段是由于许多需求的变更是由于业务的变更引起的，也就是说，并不是原来的需求分析不到位。
另外，不知道大家对于已经通过验收的项目的修改怎么看，如何处理。

PM的定位似乎存在有严重问题，PM的作用应该体现在和利益相关人员的沟通、协调上，以及对属下的技术指导作用，建议你将大部分用于编程的时间去指导下属，发挥他们的积极性，虽然他们比较累一点，但他们会觉得跟着你能学到很多东西，相比之下累一点也就无所谓了。

关于变更管理问题，我们公司的做法是：所有不在需求规格説明书中的内容都属于变更；变更内容要尽量详细；所有变更都必须通过公司自己开发的变更管理系统下发，变更系统会进行多级审查，审查不通过的会退回到客户手中；

6 楼 clamp 2008-06-13  

在项目实施过程和维护过程中，用户提出的需求变更该怎么处理？

关键在于权/责匹配
为客户需求变更的结果负责的人（比如你们这边和绩效考核挂钩）就有决策的权力（是否接受这个变更）

我看你们公司的主要问题在于权责扭曲，市场人员有接受变更的权力，却没有为变更成本买单的责任，把这个责任向后转嫁到技术实施团队。

结论：你们公司的技术团队很弱势

5 楼 zqrain 2008-06-12  

引用

现阶段是由于许多需求的变更是由于业务的变更引起的，也就是说，并不是原来的需求分析不到位。

to jimmy.shine
你说的正是“需求管理”的用武之地！
如果你不把需求管理起来（记录需求，记录需求的变更，记录需求为什么变更，变更的代价，。。。），如何来界定需求变更的责任（你们还是客户，谁是变更责任的承担者）？

PS：需求管理不是需求分析。

一方面，作为乙方，需要适当的妥协和容忍；另一方面，又需要一些技巧，在跟客户沟通的时候可以做到有理有据（拿出你跟客户沟通的历史记录）。

4 楼 jimmy.shine 2008-06-12  

另有一点，不知道大家有没有遇到，对于需求的变更，收取客户的钱对于PM来说，并不关心，如gigix所说，我们并不能拿到一分钱。甚至于连项目奖金都没有，但是是否收钱这个问题，往往决定于是否你错的问题（可能你们会认为是强盗逻辑）。

3 楼 jimmy.shine 2008-06-12  

gigix 写道

引用

现实就是出于市场考虑，做为PM不得不去修改（免费的），市场、老总往往不会关心你修改了一个地方，在维护上收了客户多少钱，而是在意后续会不会有一个单子而来，往往会认为迎合于客户，我们就会有新的单子来。

你说这话就说明你根本没弄明白作为PM你的所谓”原则“到底在哪里。
做了修改客户给不给钱，这事情和你一点关系都没有，因为单子不是你签的提成不是你拿的，你不负责这个事。如果说给钱你就给维护不给钱你就不给维护，你不是在坚持原则，你是在犯傻，因为你对自己不该负责的事情在做决定。
你应该坚持的原则是不加班，说实话，有多少工作量就说多少工作量，让客户来决定在有限的时间和资源范围内做哪些事情。一旦决定了你就把这些事情做好，不管你认为这事情实际上有多么傻x。

可能是我的表达能力越来越差了。gigix可能还是没有明白，做为市场部的，出于市场考虑是正常的，但是做为技术部门的老大，以市场为导向，引导项目，这就不正常了，不知道gigix是不是PM，能否接受到承担不是自己的错误的责任。反正我是不接受，可能是我的思维方式比较西式，对于是自己的责任，我一概承担，非自己的原因，一概不承担。这是我做技术的原则。

另外一点，在我们公司里面，是有绩效考核的，这与个人的工资直接相关，说白了，就是关系到我能拿到钱的问题。另外，做为技术人员，小公司的项目经理不仅要承担项目的进度，项目的开发，还要面对着几倍于程序员的编码工作，这就是小公司的现状。

另对于zqrain提出的关于需求的问题，这不是主要的问题，现阶段是由于许多需求的变更是由于业务的变更引起的，也就是说，并不是原来的需求分析不到位。
另外，不知道大家对于已经通过验收的项目的修改怎么看，如何处理。

2 楼 zqrain 2008-06-12  

gigix说得很好，但是，可能不是jimmy.shine的关键问题所在。

我认为，在jimmy.shine形容的是一种比较普遍的客户环境。这种环境中，PM的一个重要挑战不是技术（开发）管理问题，而是客户管理问题。

如何管理你的客户！（好像，你不是客户的boss，不好管理他们？）

这个是很多人都不愿面对的，但可能又不得不面对的一个问题。（在另外的地方，还有一个说法是管理自己的领导，呵呵，一样又难度）

我的理解是，从两个方面入手：（1）加强与客户的沟通，提升自己的沟通水平和效果，增加客户对你的理解和信任；（2）加强需求管理，对变更的需求予以记录和跟踪，以便在与客户的沟通中掌握充分，具体的证据.

还有最后一点，对这种客户，其实你慢慢会明白：吃亏是福！ 你把他们搞定，让他们满意，并没有想象中那么困难。在他们那边吃点小亏，人家会体会到的，到时候，你下一单把吃亏的钱都赚回来就是了。

西方人的“据理力争”的思维，在中国好像不是很可行，你跟你的客户争，无论输赢，相信你都不是最后的赢家。

1 楼 gigix 2008-06-12  

引用

现实就是出于市场考虑，做为PM不得不去修改（免费的），市场、老总往往不会关心你修改了一个地方，在维护上收了客户多少钱，而是在意后续会不会有一个单子而来，往往会认为迎合于客户，我们就会有新的单子来。

你说这话就说明你根本没弄明白作为PM你的所谓”原则“到底在哪里。
做了修改客户给不给钱，这事情和你一点关系都没有，因为单子不是你签的提成不是你拿的，你不负责这个事。如果说给钱你就给维护不给钱你就不给维护，你不是在坚持原则，你是在犯傻，因为你对自己不该负责的事情在做决定。
你应该坚持的原则是不加班，说实话，有多少工作量就说多少工作量，让客户来决定在有限的时间和资源范围内做哪些事情。一旦决定了你就把这些事情做好，不管你认为这事情实际上有多么傻x。