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

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

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

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

评论

51 楼 flyong 2008-11-13  

zqrain 写道

引用

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

其实每个人都希望成功，但为什么很多人还是把事情搞砸？！

有成功意愿的大多不具备成功者的知识，见解和能力。所以，普通人大多数不怎么成功。

如果LZ公司的市场人员和大老板具备充分的知识和能力，也不太可能出现发生在楼主身上的事情了。

to gigix， 你的理性分析很有用，但是前提是，听你的分析的人（比如市场，大老板）具备跟你（或者说我们）一样的知识背景和思维逻辑。

我也说说我的想法：
1 我以前的项目周期一般是一年半左右的，销售关心的只是项目的汇款（应该是项目额度的90%），往往跟项目的销售和签单的销售不是一个，销售只关心自己的利益，自己的提成。
2 然后销售去客户那里要钱，客户说了一大堆系统需求中之外的需求或者增加不合理的需求（概括客户总会有需求），销售一举拿下。客户问：“多久能做完？” 销售说：一个月，两个月，x个月，总之销售答应的很干脆。问题就在A，销售不知道客户说的需求是计划内还是之外的？他不清楚;B 他不知道开发人员要实现客户的需求要多久？就给客户答应某个时间。
3 然后销售告诉老板级人物，说“客户说 如果x个月实现了什么什么功能，马上验收，付钱”，老板高兴，马上打电话给pm。
4 boss对pm说：x个月实现什么功能，我等着拿钱，你负责一下，抓紧一下。
5 下来pm有压力，对tl，组员说某某需求，必须在什么时间内完成，若时间有限，可以考虑加班
6 下来受苦的是编码人员，加班，在加班，
7  终于有些进步，pm给客户演示，客户说，好好，但是，这个地方得加些什么.......，有一大堆需求出来了，deanline却没变，于是程序员噩梦又开始了，不好的消息是6，7，不定期循环出现。
8 于是程序员忙了，问题还没完，销售在deadline之前跑到客户要钱去了，功能没实现，在客户那里碰了灰，回去之后向老板反映，施压，老板给pm，pm给tl,组员。。。。。。

这个恶性循环怪谁？销售，老板，pm，还是程序人员？
这是我以前公司的情况。项目大概是百万的项目。

最后，感慨一下：程序员最苦，既干活，又受累！

50 楼 weidewei 2008-11-12  

技术只是一个工具.自我超越,自我满足才是人生追求的最高境界! 各位写代码的有多少人可以达到真正实践自我价值.我没见过...  继续混日子吧!

49 楼 cyberblue 2008-07-24  

jimmy.shine 写道

A-->B-->C-->A

原因在这里

48 楼 hyhongyong 2008-07-23  

市场和原则，有矛盾的时候，还是坚持原则吧

47 楼 cyberblue 2008-07-22  

这事不怪楼主，怪技术总监和项目经理的沟通不够，双方都无法总结出一套Pattern，就是将设想转化为实现的方法，或者有Pattern也无视，只一个劲地让程序员写，这里有个反面教材

http://gceclub.sun.com.cn/NASApp/sme/jive/thread.jsp?forum=10&thread=47490

楼主看到这些够解气的了吧 

46 楼 tj19832 2008-07-21  

市场是老大，这是毫无疑问的，但是请仔细思考自己到底是处于哪个市场里。明明在劳动力市场里，却想左右软件销售市场的事情，这事颇不靠谱

45 楼 fengzhang 2008-07-21  

其实任何事物的产生都是由于有了需求。市场就是最大的需求，如果我们脱离了市场，所作的任何产品只是一堆废品。

大部分人都是做应用开发的，应用开发的目的是什么？就是将客户的业务需求，用计算机来实现，如果最后实现的不是客户想要的东西，我想你也知道这种情况的后果了！！

44 楼 thinkforever 2008-07-21  

让你技术至上你能做出什么等级的东东？

43 楼 冉翔 2008-07-18  

gigix 写道

引用

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

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

我一看到这种标题，第一个想到的就是这问题太适合gigix回答了。不出所料，沙发就素你。哇咔咔。拜一下熊老师

42 楼 gdzer 2008-07-18  

fight_bird 写道

楼主描述的现状是国内小软件公司的一个典型生态，没有在这种氛围下做过项目的人是很难理解这种困境的，给楼主几个建议：
1、停止抱怨，立即沟通。
情绪解决不了任何问题，大家是一条船，项目开发经理的一个关键职责是沟通，让老总、销售、开发部门经理明白工作量所在、成本所在，若能做到这一点，你后面抱怨的问题就有解决的可能。
2、实现技术积累
国内小软件公司的最大软肋就是没有技术实现（不仅仅指技术）上的积累，导致的结果是项目越大越低效，楼主应该通过几个项目的时间，逐渐建立起这种技术实现上的积累和升华，比如：共性的技术组件、业务组件，这样你后续的项目会越做越高效。
3、组建合理梯队，分担压力。
楼主还在写大量的代码，这是我曾经经历过的状态，虽说这是因为国内小公司的低成本开发模式决定的，但楼主应该慢慢学会考虑做个“懒人”，组建一个合理的技术梯队，即使小到3人行的小组，也应该考虑技术梯队的问题，逐渐摆脱底层的细节编码，把这些精力腾出来做更合适的事情，如沟通、协调、积累。
4、需求变更要综合考量
天下没有免费的午餐，销售、老总拿客户当爷伺候是有所期待的，这里不存在迁就谁的问题，对于需求的变更要综合考虑，客户的潜在价值、变更的成本、客户强弱势状态，这本质上还是沟通、协调的问题，一旦决定了就是一个合理的工作量，必须完成的，楼主要尝试站在销售、老总的角度换位思考，当然对于小公司，此类变更控制可能人为的随意性比较大，楼主应该积极参与或主导这个流程的制度化管理。

痛并快乐着，这是楼主的现状，只要对这个公司还有信心，就去勇敢面对吧，这也是人生的财富。

有道理，改变思考的角度，尝试去沟通，只站在本位的角度去埋怨，无济于事。

41 楼 qkjava 2008-07-17  

又不是造原子弹火箭卫星操作系统的，那么牛干嘛。那种层面技术水平的成把抓。

40 楼 lz_cleaner 2008-07-17  

老兄啊，咱们是同命相怜啊！难啊，这就是小公司的弊端，也是生存下去的一个看似必要的条件。

39 楼 RCFans 2008-07-16  

zqrain 写道

gigix 写道

zqrain 写道

to gigix,如果你的意见是，用反抗和“公事公办”的态度对待那些错误者，那你的命运将取决于错误者改正错误的速度。

如果你的职业经验告诉你，那是对的，我只能唏嘘感叹：为什么我在职业经历上没有碰到这么好的合作者？：）。

你想明白了前面那段以后再来想这段
好的环境可以碰到
不过更多的时候要靠自己找到，甚至自己来创造

我大概明白你的意思。

对于“甚至自己来创造”这句话，你的意思是在现有环境中创造，还是独善其身以获得好环境的资本？

如果是在现有环境中创造，问题还是回到了如何在一定程度上减少错误者的损坏，以及如何扩大自身影响力，从而改变错误者。

如果是独善其身以获得好环境，我也不敢苟同。

我的职业生涯初期（其实总共也不长），跟你表达的思路一样，总是希望找一个好一点的环境。后来，发现其实无论大公司还是小公司，无论是国内企业还是国外企业，甚至那些以先进的管理著称的公司，实际总有很多不如人意的地方。

不可否认，有时候离开是一个不错的选择。但是，我渐渐明白，适应现有环境并改造它，是期望在职场上成果的人士的必修课。

这一点我更赞成 http://www.iteye.com/topic/132181 主贴的观点。

很多时候，改变并没有想象中那些困难！在尝试之前，请不要轻言放弃！

这种尝试，甚至主观上并不是为了帮助所在的公司，而是实现自身价值和抱负的高回报投资。

呵呵，越来越赞同zqrain的观点了。
一个团队中能力有高有低，每个成年人都有自己的想法，能力高的人是特殊的个体，本来就是异于团队的，这更需要多沟通去推行自己的独特观点！

38 楼 RCFans 2008-07-16  

zqrain 写道

引用

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

其实每个人都希望成功，但为什么很多人还是把事情搞砸？！

有成功意愿的大多不具备成功者的知识，见解和能力。所以，普通人大多数不怎么成功。

如果LZ公司的市场人员和大老板具备充分的知识和能力，也不太可能出现发生在楼主身上的事情了。

to gigix， 你的理性分析很有用，但是前提是，听你的分析的人（比如市场，大老板）具备跟你（或者说我们）一样的知识背景和思维逻辑。

说得好，顶！
没有这个能力来趟混水，被淹死也正常啊！

37 楼 xo_tobacoo 2008-07-16  

开发人员只管写代码 ,实现功能，其它的和你有嘛关系啊 ！改就改 ，需求一天变上万次，也改 ！反正你拿工资，做完就走人  ！不过在责任上 得明确，你要让老板知道 ：不是你没写出来导致项目延迟，而是需求人员的需求，每天给你的都在变。不要给需求人员有机会把全部责任推卸给你 。这种推卸责任的鸟蛋很多 。简单的办法就是每次需求更改都要求他们给你发正式的邮件。
作为好员工 ，偶尔向老板发牢骚，唠叨一下问题，发表下意见也无所谓 。

36 楼 [e-mail] 2008-07-16  

我理解，维护即使有钱也不能到楼主的口袋里，但是问题是这些工作都要维护的人完成，累呀，做过电信项目的人就明白了。无法控制的需求，一个接一个，加班加班。。。，至于技术，当然退到旁边了，客户高兴就行。

35 楼 tiannet 2008-07-14  

我也经历过这种事情，但是依然未找到很好的解决办法。
如上面某位网友说的，既然已经打算离开，那不妨和老板、销售人员、客户讲清楚，需求变更是要付出很大代价的，
并且可以推荐老板销售人员看一本书《人月神话》，
让他们明白随便变更需求会对项目造成的伤害，
你应该发挥让你的智慧，让老板和销售人员明白做项目研发的难处，让他们明白你们的困难。

34 楼 soleghost 2008-07-12  

对于专门定制客户化软件的小公司来说，市场就是第一，没有钱公司无法运营，这就是公司的原则和立场。
对于PM个人来说，谁都不愿意看到一个需求改了又改，结果可能是无休止的编码-测试-上线，导致最后项目很难控制，以至于失败，最终还是公司利益受损。

所以我觉得对于客户变更要有一个度，不是什么需求变更都可以做的。

在这种公司做PM和客户打交道是会遇到这种问题，关键在于和客户的沟通了。也许做产品是条好出路，呵呵

33 楼 fight_bird 2008-07-11  

楼主描述的现状是国内小软件公司的一个典型生态，没有在这种氛围下做过项目的人是很难理解这种困境的，给楼主几个建议：
1、停止抱怨，立即沟通。
情绪解决不了任何问题，大家是一条船，项目开发经理的一个关键职责是沟通，让老总、销售、开发部门经理明白工作量所在、成本所在，若能做到这一点，你后面抱怨的问题就有解决的可能。
2、实现技术积累
国内小软件公司的最大软肋就是没有技术实现（不仅仅指技术）上的积累，导致的结果是项目越大越低效，楼主应该通过几个项目的时间，逐渐建立起这种技术实现上的积累和升华，比如：共性的技术组件、业务组件，这样你后续的项目会越做越高效。
3、组建合理梯队，分担压力。
楼主还在写大量的代码，这是我曾经经历过的状态，虽说这是因为国内小公司的低成本开发模式决定的，但楼主应该慢慢学会考虑做个“懒人”，组建一个合理的技术梯队，即使小到3人行的小组，也应该考虑技术梯队的问题，逐渐摆脱底层的细节编码，把这些精力腾出来做更合适的事情，如沟通、协调、积累。
4、需求变更要综合考量
天下没有免费的午餐，销售、老总拿客户当爷伺候是有所期待的，这里不存在迁就谁的问题，对于需求的变更要综合考虑，客户的潜在价值、变更的成本、客户强弱势状态，这本质上还是沟通、协调的问题，一旦决定了就是一个合理的工作量，必须完成的，楼主要尝试站在销售、老总的角度换位思考，当然对于小公司，此类变更控制可能人为的随意性比较大，楼主应该积极参与或主导这个流程的制度化管理。

痛并快乐着，这是楼主的现状，只要对这个公司还有信心，就去勇敢面对吧，这也是人生的财富。

32 楼 gurudk 2008-07-03  

一蓑烟雨任平生 写道

优秀的项目经理，要能打硬仗、打恶仗，成了是英雄，败了当炮灰，有什么好说的。先想着怎么把事给做成了再说吧。

是该有这种魄力！！