让步还是继续前进

   到现在项目已启动将近2个 月了，前期准备不足，导致现在出现很多问题。需求调研的延期，需求的不断变更，而作为项目负责人的我，更是开始惶恐。
   虽然知道管理是应该以实践为主要的，不过我希望是在有理论基础上，而又是靠近现实的理论。虽然看过了一本IT项目管理的书籍，但是书中的理论并不适合我现在这个项目的环境，而且书里是纯理论，没有讲到任何问题的解决方案。
   我想看的是一本理论与实践相结合的项目管理书，也就是书中应该举些实际上的例子，然后提出最终的解决方案，这样我想应该还是可以借鉴下的。现在很想学习scrum的管理方法，不过昨天看关于scrum的书籍时，发现很多东西我们都难以实现，不知道是我太悲观还是怎么的。
   现在我在这个项目中已经运用到的一般能想到的，比如代码规范，jira的bug跟踪，junit测试，cc持续集成，dbdeploy数据库版本控制。。。等等，scrum中提到的东西，在我了解scrum之前就已使用。然而，或许因为我个人原因，这些东西现在都没能执行的很好，实际上并不是用上这些就能让项目很顺利的进行，甚至说只是带来益处。如果没有去好好的执行相当于没有，甚至比没有的效果更差。
   现在这一堆东西都已创建，只等待着执行和使用！实际上这些东西我都还是第1次使用，我有时候在想，在这个时间这么紧张，只赶进度的项目上，这些东西的使用是否没有必要？不过，那总是一瞬间而已，平常时候，我还是认为这些项目管理的工具只要去好好执行就绝对可以带来好处的。问题就看能不能好好执行。
  当然以上都是我个人的想法，或许有人会认为工具并不能起什么作用，希望大家能给我推荐一本好的项目管理的书和建议。
  现在思维有点混乱，加班加的。有些语句可能很凌乱，请大家不要介意。 继续等待老板通话中。。。。

评论

36 楼 taelons 2008-12-05  

国内的项目都是领导拍脑袋说了算,外行领导内行.千万别看书,书上说的实际根本用不上,也没时间看,哪有一边看书一边开工的.
现在各方都是在忽悠,然后作忙碌状!实际工作让底层的coder/programmer去受罪去折腾.
软件厂商说他的软件能提高工作效率降低成本,忽悠!从没见过哪家用了他的软件,就轻松了舒服了,都是越来越忙越来越烦.如果真能提高工作效率, 就没事做, 经济一不景气,就等着裁员吧,所以宁可作忙碌状.
降低成本就更别指望了,软件厂商都是饿狼,对客户口袋的钱虎视眈眈,客户一烧钱就停不下来.
客户也愿意烧钱,反正不是他的钱,有进有出,现金流动顺畅是好事啊嗬嗬,敢花钱的都有事做.开发商夹在中间,三方玩一把金钱倒手的游戏,为全社会的GDP添砖加瓦.你看美国政府和中国政府都争着花钱,一花就是几万亿,花了就能刺激经济,钱去了又来,老百姓手头就好使了,政府也有钱了

所以大家都要看开了,凡事都别太认真,大事小事,都不过是忽悠,然后作忙碌装,GDP就上去了!社会就和谐了!

35 楼 hanbin51987 2008-12-01  

   怎么听楼主的话，弄的跟我们公司一样，我们是隶属公司的一个开发部门！管理层的混乱，还有我们公司压根儿就不知道谁是真正的项目经理，我们也有小经理！虽然天天呆在公司吧，可是技术可以说是什么都不懂，只会提出 “这个好，你把这个给我实现了，恩，那个好，你把那个实现了！”然后在我们辛辛苦苦，加班加点做完了之后。来了句，我要的效果不是这个样子的，从新返工吧！
   他根本不明确这都意味着什么，我也不知道他是怎么当上小经理的~一个比我还小一岁的经理！才21岁！
   以下是我想的，如果按照这个样子下去，呵呵~永远别想指望项目成功~
   我想大家都无法接受这两个条件同时成立吧！1.项目要做的完美  2.在不段更改需求的前提下，按时完成（当然说的有点夸张，只是一天到晚不停的跑到我们部门催~，怎么还没有完？）我就一直在想，是不是在他脑子里 我们就是万能的，他一说要实现，我们是不是半个烟的功夫就可以给改完！况且有的时候还牵扯到数据库的变动！
  气氛的说！
  看到楼主说的 我更冒火了

34 楼 Ethan 2008-11-15  

的确，有好的工具帮忙掌握代码质量的检测，更需要一套执行机制去完善现有的代码，不能够说知道问题在哪就是不解决，那其实更可耻。

33 楼 snomile 2008-11-11  

领导宣扬X理论，这个实在是太可怕了，那“命令”就真是他唯一的管理手段了……
但我感觉只有最笨的领导，没有读过任何软件开发管理书籍的领导才会信任X理论吧。跟着这种领导，除非有政治手腕，否则就没前途了。shishi11兄是在什么公司，方便透露一下吗，也可以给论坛里面的兄弟一点借鉴意义。

32 楼 shishi11 2008-11-06  

snomile 写道

shishi11 写道

看来，管理层还是很空闲的。当然不是说想怎么做就怎么做，要符合客观规律。
其实有另一个话题，管理层向你要一个最优方案，你提交的他们又不满意，要你再优化。你真的能再优化，管理层会觉得你开始时的方案有水份，“看来每次都要挤呀”;你没有新优化方案，管理层会觉得你故意不管理层过不去。其实你不得不稍加改动，把时间，质量，成本三个方向调整一下，说明要满足某个要求是可实现的，但要降低另一些要求，或提高另一些风险。
“圆滑”有书上写的，我的理解也有些偏差，“进步”，我不知怎么理解，也许以退为进吧。

大家都知道被管理层挤海绵的感觉，我觉得这是一个具有普遍意义的代表性事件。我对这种情况的总结是：被管理层挤海绵，是因为管理层不知道你究竟还有没有水分。所以，如何让团队的真实情况展现在管理层面前，是解决这个问题的key。你例子中举的把时间、质量和成本进行调整，那么管理层知不知道你在做这种调整呢，这种调整背后的含义是什么，会带来什么问题。如果这几个问题的答案都是No ，那被管理层挤海绵就是定局。因为管理层什么都不知道，就好像瞎子一样，唯一的办法就是抓紧带路的人（项目经理）。

当然，很多小公司的管理层根本就称不上管理层，一不懂技术，二不懂管理，根本没法管理软件开发，最多是“命令”软件开发。所以管理层和项目经理的互相教育，是小公司软件开发管理改进必不可少的环节。如果项目经理没有能力和胆量教育管理层，最后被管理层挤海绵，那也是个没办法的事情，呵呵。上压下顶，处处不被理解，也是小公司项目经理的永恒之痛吧。

首先，是“说明要满足某个要求是可实现的，但要降低另一些要求，或提高另一些风险”，试着让管理层明白现在的情况。
第二，互相教育其实不如说互相信任，Y理论，只可惜我们领导是X理论，而且宣扬X理论。
第三，大公司我不知道，我们公司1000左右人，作坊一样开发，只在小范围内，由于一些部门领导对项目经理充分信任，全权交付，软件开发才挣些钱。
所以，在原则以内调整，已经是能做的比较好的。

31 楼 snomile 2008-11-05  

shishi11 写道

看来，管理层还是很空闲的。当然不是说想怎么做就怎么做，要符合客观规律。
其实有另一个话题，管理层向你要一个最优方案，你提交的他们又不满意，要你再优化。你真的能再优化，管理层会觉得你开始时的方案有水份，“看来每次都要挤呀”;你没有新优化方案，管理层会觉得你故意不管理层过不去。其实你不得不稍加改动，把时间，质量，成本三个方向调整一下，说明要满足某个要求是可实现的，但要降低另一些要求，或提高另一些风险。
“圆滑”有书上写的，我的理解也有些偏差，“进步”，我不知怎么理解，也许以退为进吧。

大家都知道被管理层挤海绵的感觉，我觉得这是一个具有普遍意义的代表性事件。我对这种情况的总结是：被管理层挤海绵，是因为管理层不知道你究竟还有没有水分。所以，如何让团队的真实情况展现在管理层面前，是解决这个问题的key。你例子中举的把时间、质量和成本进行调整，那么管理层知不知道你在做这种调整呢，这种调整背后的含义是什么，会带来什么问题。如果这几个问题的答案都是No ，那被管理层挤海绵就是定局。因为管理层什么都不知道，就好像瞎子一样，唯一的办法就是抓紧带路的人（项目经理）。

当然，很多小公司的管理层根本就称不上管理层，一不懂技术，二不懂管理，根本没法管理软件开发，最多是“命令”软件开发。所以管理层和项目经理的互相教育，是小公司软件开发管理改进必不可少的环节。如果项目经理没有能力和胆量教育管理层，最后被管理层挤海绵，那也是个没办法的事情，呵呵。上压下顶，处处不被理解，也是小公司项目经理的永恒之痛吧。

30 楼 。。。 2008-11-04  

搞技术的人喜欢从理论上寻求解决方案。从一大堆名词术语中试图寻找管理的规律。西方的东西用在东方不一定有效，把一套软件项目管理理论生硬的套到自己Team上也可能会抛class cast的。量肚吃饭，量体裁衣；见过某些一点点大的小Team硬要搞一套“科学的、完善的、规范的”开发流程，于是二手需求变多、开发周期变长~~~管理成本膨胀......小公司染上大公司病还是有点风险的。

29 楼 shishi11 2008-11-03  

snomile 写道

我倒不觉得一定要使用“圆滑”这种技术人员很不擅长的手段。技术人员应该有技术的办法。
以前我的理解也是让管理层在面子上过得去，但私底下还是想怎么做就怎么做。但管理层不笨，时间长了他必然知道咱们在底下乱搞。所以后来我转变了一下策略，我在不断地做改进，而且我要把这种改进的成果show出来，让管理层看到（当然前提是咱们得让他们看得懂），只要管理层看到你一直在进步，很大程度上就可以让管理层的心放下来。

看来，管理层还是很空闲的。当然不是说想怎么做就怎么做，要符合客观规律。
其实有另一个话题，管理层向你要一个最优方案，你提交的他们又不满意，要你再优化。你真的能再优化，管理层会觉得你开始时的方案有水份，“看来每次都要挤呀”;你没有新优化方案，管理层会觉得你故意不管理层过不去。其实你不得不稍加改动，把时间，质量，成本三个方向调整一下，说明要满足某个要求是可实现的，但要降低另一些要求，或提高另一些风险。
“圆滑”有书上写的，我的理解也有些偏差，“进步”，我不知怎么理解，也许以退为进吧。

28 楼 sg552 2008-11-03  

kayzhan 写道

很明显，我是技术出身的。更明显的是，我性格天生就是直爽，藏不住话，也不懂得隐藏情绪。不知道圆滑这个是否能慢慢学来，不过我还是想尝试一下！

似乎我们做技术的都这样。

不过藏不住话没关系，你说的时候，一定要心平气和的说，让对方觉得你说的有道理。
不要太过情绪化，否则你有道理也变得没道理了。

27 楼 sg552 2008-11-03  

冰冻三尺非一日之寒。

想要用UNITTEST, 持续集成，JIRA BUG 跟踪，CHECKSTYLE, 先要确保你的小组成员是否都掌握了这些技能？

也许有局限性吧，我的绝大部分同事，几乎都没有使用UNIT TEST的。CHECKSTYLE也从来不用。持续集成更不用说了。JIRA倒是有用过。不过用的人素质不行。表达能力差得人，用了JIRA之后提的BUG,一样让人摸不到头脑。

所以管理真的是门学问，不是说说就能拉出去练的。

如果我是你，想达到（规范代码，使用UNIT TEST, 持续集成）这些目的，就一定要先保证小组成员都基本掌握这些技能。不会单元测试，你就举出几个ActionTest, ServiceTest。 不会checkstyle，你就先给他们一个eclipse/jalopy code convension,让他们有空就格式化下代码。他们闻不出代码的坏味道，你就带头做review。大家觉得持续集成没用，你就学习pragmatic programmer- automation 中的，自己买个绿灯泡，红灯泡，放饮水机前面，程序出错就亮火警灯吓吓他们。对于JIRA的使用做个视频，然后规定提交BUG的人要说明白出错时的环境，信息，报错情况，预期正确结果。改BUG的人注明BUG出错的原因，修改的思路和具体办法。


ps.
上面说的也是我自己一贯坚持的原则，只是我不喜欢命令别人，所以只好对自己下手，除了没有在饮水机前面放警示灯，其他的都做过。效果非常明显，非常好：）

如果你也跟我一样是个小兵，可以在自己身上先试试这些。只是在使用cruisecontrol时，log4j的 显示级别一定要在WARN以上，否则那LOG文件就太大了。。。

26 楼 cuiyi.crazy 2008-11-03  

snomile 写道

我倒不觉得一定要使用“圆滑”这种技术人员很不擅长的手段。技术人员应该有技术的办法。
以前我的理解也是让管理层在面子上过得去，但私底下还是想怎么做就怎么做。但管理层不笨，时间长了他必然知道咱们在底下乱搞。所以后来我转变了一下策略，我在不断地做改进，而且我要把这种改进的成果show出来，让管理层看到（当然前提是咱们得让他们看得懂），只要管理层看到你一直在进步，很大程度上就可以让管理层的心放下来。

比较认可这个兄弟的观点；
这就是一个所谓的”安“的问题，对客户老板手下；其中给老板的安心，表现形式就是让老板看到改进和成果；

举个不太贴切的类比：做技术的人往往更注重底层或者业务层一样，老板注重的更多的是可见的形式化的，所以改变你的观点和层面，结合你的优势，对老板有交代，对手下有交代，从而形成一些层面的安

25 楼 snomile 2008-11-01  

我倒不觉得一定要使用“圆滑”这种技术人员很不擅长的手段。技术人员应该有技术的办法。
以前我的理解也是让管理层在面子上过得去，但私底下还是想怎么做就怎么做。但管理层不笨，时间长了他必然知道咱们在底下乱搞。所以后来我转变了一下策略，我在不断地做改进，而且我要把这种改进的成果show出来，让管理层看到（当然前提是咱们得让他们看得懂），只要管理层看到你一直在进步，很大程度上就可以让管理层的心放下来。

24 楼 kayzhan 2008-10-31  

很明显，我是技术出身的。更明显的是，我性格天生就是直爽，藏不住话，也不懂得隐藏情绪。不知道圆滑这个是否能慢慢学来，不过我还是想尝试一下！

23 楼 shishi11 2008-10-31  

冲突的解决，我在这方面也处理的不好。
策略：解决，妥协，圆滑，撤退，强迫。在所有策略中，圆滑最难，特别是理工科出来的做技术出身的项目经理，几乎不会圆滑。这是个性所致，但作为一种技能，圆滑也是必要的。说白了，就是明一套暗一套，口是心非，如果做过客服，这方面能强得多。

22 楼 kayzhan 2008-10-31  

snomile的回复很有道理啊！现在我感觉项目终于开始有点进展了，至少内部的协调和编码能力比一开始好很多，当然虽然有点窃喜，却不敢松懈。因为随时都有突发状况的可能，而这个可能又肯定会引起我和老板的冲突，但是经过这么一说，我想我会学会控制自己，并且表现出来认同与顺从，而我们内部的流程不会因此而改变，希望这样能慢慢改变局面。

21 楼 snomile 2008-10-30  

kayzhan 写道

   到现在项目已启动将近2个 月了，前期准备不足，导致现在出现很多问题。需求调研的延期，需求的不断变更，而作为项目负责人的我，更是开始惶恐。

对楼主遇到的情形深有体验，说说自己的切身体会，希望能给楼主带来些参考价值。


这里面混杂了两个关键问题，一个是管理层面的，另外一个是技术层面的。

在不考虑公司的规模和管理成熟度的前提下，从管理层面看，如果管理层（老板）连需求调研延期和需求不断变更带来的危害，以及管理层应该做出的相应反应都不清楚，说明你首先需要把这些问题带来的后果展示出来。最起码的，应该让管理层认识到这些原因会导致哪些问题出现。然后，管理层会做出相应调整决策，例如换人、增加资源、与客户加强协调，等等。

从技术层面看，需求不断变更，这是一个客观存在的事实，而对需求变更的控制能力，远不是靠管理层的“保证书”就能搞定的，对需求控制，需要有丰富的行业知识，能够对业务知识做出非常强势的判断和控制，能够在客观上说服客户，而不是靠管理层卖人情和稀泥。

作为技术人员，往往因为自身没有业务知识上的优势地位，会寄希望于管理层说服客户写“保证书”。但实际上在不是很规范的小公司，管理层很少会给开发团队作担保去说服客户写保证书，更常见的做法是换人，换高手，因为管理层认为就算写了保证书，客户一样会变，这种保证书，根本没什么用（事实也是如此）。

所以对于小公司来说，“需求调研的延期，需求的不断变更”在很大程度上是一个技术问题，而非管理问题，从管理层面切入是解决不了这种问题的，换句话说，找老板也没用，搞不好自己还被换掉。要说解决办法，还是会落回老套路上——提高团队自身的业务能力和开发能力，业务能力得慢慢提高，而XP提供了很多很基本的提高团队开发能力的技术手段，尤其是结对和持续集成，可以迅速将团队的平均开发能力提高到团队最高开发能力附近的高度上。


说来说去，提高团队的自身开发能力才是真本事，除非风险已经非常非常明显了，找老板也没用，因为他不是专门搞软件的，看不出来有什么风险。等到管理层能认同了团队发现的风险时，再与管理层一起做项目管理改进吧。
过早地与管理层发生冲突，会对双方都带来伤害，因为此时管理层和开发团队还不能互相理解。从楼主说老板在捣乱就能看出这种情形了，其实老板何尝不是在认为我们也是捣乱呢。

20 楼 kayzhan 2008-10-30  

哎！可惜就是上层不支持啊，反而捣乱，我们都只能在没有被捣乱的时候抽出时间干点正常事。不过也因为这样，我对老板开始有不满了，而且表现出来了，同样老板也开始对我没有那么信任了，因为我没有同意他很多说法。当然我清楚这个倒是我的问题，我不应该表现出来，而且是我的说话方式有问题，让他能很明显地听出我在反驳他的意见。

19 楼 shishi11 2008-10-30  

sg552 写道

为什么18个小时前的帖子我才看到啊？
我平均2小时刷新一次啊。

而且浏览量是 ：1 ？


发了个回复，就变成 74了。 诡异。。。

大概是静态页的机制，如果实时刷计数，系统压力太大，不可能单为一个读数去更新静态页。

关于主题，和我们的情况差不多，所以，感觉沟通方面的比其它的要重要，只要能达成一致就好，用什么方法和手段在其次。一些工具化的东西还是要的，一方面有利于规范操作，另一方面回溯性好。当然，第一次用感觉好累，也没什么效果，但这些东西好多是为了过程管理的，认为有好的过程就有好的结果。但关键在人，实际上是要人来熟悉以至主动按规程工作，效益从长期角度讲的，第一次往往是痛苦的。所以在还不太熟悉这个套路时，人们出于惰性可能反对他，或不认真执行，那其实也是项目管理的一部分，不过最好是有高层的支持。

18 楼 pekkle 2008-10-29  

这个帖子看完，我才发现gigix是个牛人。
说的一些建议太有棒了

17 楼 pangyi 2008-10-29  

你现在应该感觉很头大吧！

任何人不是天生就能做项目管理，这需要一个过程。你现在只是拥有成为合格项目经理的机会。

给你提点建议。
1   不管项目有多大压力，作为项目经理，你要保持自信；
2   找你认为能帮助你的人，与他仔细沟通项目的现状，协助你认清项目的问题所在，并做好相应的对策；
3   从现在开始，做好项目中的文档；
4   不要所有问题自己扛，调配周围的资源；