项目组中管理者与被管理者的关系与说话态度、语气等的问题

这位朋友你好。我无意跟你的故意对立。大家都是在讨论问题。如果我上面的帖子的言论有冒犯之处，请多多包涵！
答：我说的“系统的学习下管理知识”，就是说全面的学习 管理学方面的专业知识。
    我没有作出“你没有系统的学习过管理知识”这个结论。只是觉得用“严厉”来进行管理，很不合适。我个人从来没有听说过哪本管理类的书籍是这样写的。
    我和我周围的人说话很正常啊。我无意跟你做对立。
    论坛不是讲坛。我只是和别人交流我的观点。没有资格强迫谁接受。
---------------------------------------------------------
我的回答：了解！





没有做过Tester, Designer，只是Programmer。如果你划分的这三个角色跟过程化的编程方法定义的角色一样的话。
我写的代码在风格上算是自己满意，结构简单，尽量做必要，清晰的注释，尽量每个关键方法有一个测试方法。使用测试驱动编程。及时的重构。

我的问题1：一天写出高质量的代码，这个“多少”是如何衡量的？不是行数吧？质量是如何保证的？
我的问题2：我个人觉得，过程化方法所划分的各种角色，在国内没有走通。我经历过的所有项目，基本每个人都有写代码，做设计，做测试的工作。集成测试人员这个角色倒是可以比较独立的任命。你觉得呢？
---------------------------------------------------------------------
我的回答：就是行数。team内部的话，就是team review
没错，是每个人什么都干，但是比较好的话，是自己清楚的划分每一个任务是在什么阶段，什么角色在做，每一个都搞精，就是说，对于每一个角色，都有自己的一套深刻体会，能够抓住要害和风险。因为不同的角色的任务和特点是不同的。否则，你永远也搞不清楚问题将要出现在什么阶段，也就是永远也看不到风险，因为在你看来，各种角色业务都是一样的重要。只是在做不同的事情。






唯一做过一次所谓的管理人员，是两年前。上面一个。老板兼技术老总。下面 2 本科 4研究生 3培训机构人员。
使用盗版的 Project .
最大的项目  8 个人。开始预计40天。后来到80天。人日请读者换算吧！只看工资的话，成本是 20W+
没有做过作准的开发流程。（因为我不知道啥叫作准）
Schedule管理： 麻木的使用盗版Project先做个规划。把估计时间X2，做成报表。之后大概2。3天就填一下各种数值。
风险管理：只是前期跟上级提出了。上级不管理。我也就没管。（回忆起来，项目确实毁在了最初提出的风险上。）
Cost管理：基本没有。
Scope管理：不知道这个是什么。。。 - -

我的问题：  上面的这些内容，大部分都是过程化的开发流程。我认为这个东西非常理想化。没有作用。因为实际情况根本就不是想象的那么顺利，计划不如变化快。尤其是“人日”，这个概念很不合理。《人月神话》《软件工程中的事实与谬论》等很多书都批判过了。
-----------------------------------------------------------------------------------
我的回答：你说的没错，我也不喜欢人日。我最喜欢的就是没有时间限制，一个人做自己的事情，虽然不知道什么时候做完。随性！

但是和客户谈项目，用的数字就是这个。管项目用的也是这些，时间，人，钱，成本就是这样算出来的。你说你该怎么管理schedule，要么就放羊？人日是不一定很精确，但是放弃人日，连基本的schedule管理也做不到。中国没有搞人日，是因为中国人的人力成本不高，多几个人也无所谓。如果搞IT的每个人一个月工资都是2万以上，我看你在乎不在乎。

项目有变化是正常的，这个在当初预算的时候在一定程度上要考虑。这个应变的能力就是大公司和小公司的区别。我做了很多项目，就没有发现有，没有变化的项目（包括内部项目）。所以，我们的方法是，清楚的划分开发流程，搞清楚，问题处在什么阶段，为什么会出现？如何避免？否则，作多少个项目，也是白搭，没有任何改进。

举个简单的例子，有个SCOPE管理的概念，意思就是说，清楚的定义要干什么事情，之外的事情一律不干。比如，当初说好的这么作，某一天，那个领导一拍脑袋，不要了，那么做不好，改掉。这个就是变化。如何解决这一类问题，对于一个有信誉的，好的公司，刚开始谈项目就应该把SCOPE定义的很明确。没有免费白干的活。你要变化，可以啊，给钱就行。有些项目呢，会有一个变更预算，也就是说如果出现小的，可以接受的变更，项目的10%（比如，根据项目不一样，数字会变化）作为成本。

你也许会说，我要是和这些人谈SCOPE，他们就不给我项目，这个我想不是项目管理的问题，是做人做事的问题。





客户谈过项目。06年因为自己基本在单干，接触过不少客户。后来进了公司跟人打工，也谈过。
项目出现非常大的问题，只有一次。发现自己无法解决，只好将项目变成“失败”。我损失了时间，钱和健康。
《与熊共舞》看过一遍。对风险的产生，看起来很有感觉。一边点头一边读的。
---------------------------------------------------------------------
我的回答：嗬嗬，同感。一般会有四种。
1.从前书中看过的，现在遇到了，深有同感
2.从前现实中遇到，后来看书书中看到了，深有同感
3.书里看过，从来没有经历过
4.经历过，书里没有

我想这个世界上最难的就是第四种吧！因为这个问题就是等待你去解决的问题。实践出真知，就是在这些地方吧。





恩。我也是很认真的回复你的帖子。
每个问题回答完之后，浏览一下，在软件专业方面，你的大部分问题都属于“过程化开发方法”。把人员角色强制划分，使用人月这样不合理的估算方法。倾向于接受繁多的各种Leader, Manager。我觉得，这些方法和概念，都被证明是低效率的，不合理的，容易导致失败的。

你也说到了《与熊共舞》。你觉得里面对风险量化的过程的看法如何？（比如，里面的曲线图，有的地方是2次方曲线，有的地方是 1/2次方曲线，它们描述的是否符合实际？如何验证结果？ 对风险的量化如何作到准确？ 在风险管理的过程中，有多少步骤会涉及到跟人打交道呢？）
-------------------------------------------------------------------------------
我的回答：没错，前面也提到，包括RISK，COST等等，其实最终的目的只有一个，细化所有的步骤，使自己能够看清楚。使别人能够看清楚，同时还可以使自己看到，那些地方可能看不清楚。

风险管理真的是一个很难的话题，说来就长了。我目前做过的项目也就在做完全部过程之后，得到数据然后做一个分析，风险控制，几乎是渗透到每一个步骤中，一直都在尽量避免风险，但是往往难以避免，最后我的结论是，焦点放在了项目上，如果每一个步骤都控制的，或者说做的比较好，那么风险就很低。我的做法也许应该叫风险控制，谈不上管理。注意，我说的方法是谁都能够做到的，也许会有人水平比较高，鼻子比较灵敏，能够闻到所有的风险。但是大多数情况下，我们需要确凿的证据来说服别人或者领导，这个地方存在风险，所以一些细化的数字还是必须的。

至于书里提到的曲线，一定程度，是符合的，除去一些杂音或者叫做现实中的空气，风量之类的因素。验证结果，你必须有足够的准确数据。我个人认为最大的风险就是在人上。所以我会天天和人打交道，来避免或者降低风险。

最后来一句总结：
我想这一次交流，是成功的，让我知道了你的一些看法，也在一定程度上让你了解了我的一些看法。谢谢。

其实大家讨论的核心就是

传统的等级管理制度 和 扁平化的敏捷的协作式
的管理的差别


前者是大多数公司
后者比如 ThoughtWorks

个人觉得协作式的制度是趋势 但是还有很长的路要走。
传统的管理方式的核心是“人治”，有很多封建的思想成分，一定会被历史淘汰。

嗯，讨论的很认真和深入，赞一个，关于风险，贴个PMBOK上的风险管理过程活动，希望对大家有所启示：
+风险管理规划：
决定如何采取和计划一个项目的风险管理活动
+风险识别：
确定和文档记录影响项目的风险及其特性
+风险定性分析：
对项目风险和条件进行定性分析，将它们对项目目标的影响按优先顺序排列
+风险定量分析：
测量风险出现的概率和结果，并评估它们对项目目标的影响
+风险应对计划：
开发制定一些程序和技术手段，用来提高实现项目目标的机会和减少风险对实现项目目标的威胁
+风险监控：
在项目的整个生命周期内，监视残余风险，识别新的风险，执行降低风险计划，以及评价这些工作的有效性

至于软件项目倒不必那么兴师动众地防范风险，贴出来，只是感受一下系统性思考。

分类过于绝对，期待第三条道路。

现在不管什么制度还是流程，哪怕是CMMI几级，对于一个软件产品的开发来说，相对传统工业产品都还是小工厂阶段。这需要一些专业人士分工出去思考，我一个程序员就不发言了~