重读从程序员升级到工程师有感
　

---

这篇[从程序员升级到工程师]又被人提上来了，重新看一遍，不禁有些许感触。
已经记不清第一次看见这篇文章是什么时候了。只记得当时经验还少，拜读此文，恍然大悟，怪不得我们的软件落后，原来差了这么多。本来觉得自己公司的做法已经够正规了，原来还是差。后来在不同的地方又多次看到这篇文章，这篇文章流传之广，恐怕是程序员圈子里数一数二的，尤其是会上UMLCHINA的程序员，恐怕有不少是受过这篇文章影响的。我本人是随着经验的增长，每次看每次的感触都不一样。尤其是和印度的项目有了实际的接触以后。如今看来，当时的恍然大悟其实不过是经验少带来的浅薄无知罢了。
对于在软件开发的泥沼里苦苦挣扎的程序员来说，有的始终在无序状态，有的见识过所谓的软件工程，却没有多大的实际用处，突然出现了一个印度的成功例子，觉得前景一下子光明起来也是理所当然的。程序员的酸甜苦辣这里出现过的例子也不少了，一下子能变成悠闲，而且还一切尽在掌握中，怎么能不为所动。只可惜这个世界上没有灵丹妙药。
我们羡慕印度软件工业的发达，从这篇文章和其他介绍中我们也了解到印度有完善的软件工程，有CMM，有充足的文档。我们就以为，只要我们也有这些，我们就也能发达。不是吗，印度人都能干到的事，我们聪明的中国人又有什么作不到的。
现在，让我们脱离这个简单的因果关系，动动脑子来仔细分析一下。先从这篇名作开始。
我想，任何一个程序员对这篇文章首先惊讶的应该是开发商能在客户面前坚持300行/人月的开发速度，代码行数虽然没有太大的价值，也是一个简单的参照，国内有哪个软件企业敢这么声称？有没有可能如果我们的软件开发也以此速度作为最初开发的基准，是不是不用别的就能提高开发质量？没有人有这个数据，这个实验不可能在受控条件下可再现的进行。另一方面，如果一个原来30,000行规模的软件能有100个人月的预算，哪怕只用20个人月做设计，也很可能最终能以5,000行就能完成，那么应该如何计算基准时间？是不是意味着同样的功能，用20个人月设计，10个人月编码，测试完成5,000行的开发效率就低于用原来的总共100个人月完成30,000行？然而，这也只是一个数字游戏，事实上在开发时，或者选择了5,000行的方案，或者30,000行的方案，并不会知道别的方案究竟需要多少时间，也就是这个比较其实无从做起。人的因素影响太大。文中同样提到，300行/人月是经验数据，说明这不是基于某个被公认的理论，只是开发商内部的参考数据。这个数据要有效，只有两种可能。一个是现在的开发人员就是提供数据原始统计来源的人员，这意味着这个数据对别的开发组织没有参考价值，因为人员素质差别的影响很大。一个是这是所谓能确保的能力水准数据，人员素质千差万别，但至少能保证这个基本的开发能力，就是说这个是在最坏情况下也能达到的控制线，如果想知道实际上能达到怎样的速度，对不起，没有用。你能知道一群高中生作小学3年级的数学能确保80分，但不会知道需要5分钟，还是10分钟。维持这样的进度事实上浪费了人力资源，却是对项目经理最安全的。而且，任何一个有几年工作经验的程序员都知道，要预计一个开发需要时间是困难的，但还是有可能的。要预计一个开发需要的行数，以100行为误差单位都几乎是不可能的。除非工作只有拷贝+改if判断值/改for的边界值。一周写几千行代码不少见，一周调试排错的结果只是一行代码，甚至某个环境设置的问题也常见。把一个共有函数inline就能增加几百行代码。所以最后的结论就是印度开发商用人月的行代码数作为参考，不过是为自己提供安全余量，要求开发费用的手段而已，对真正的开发过程没有任何帮助。
接下来，我们程序员会对项目进行的流畅程度羡慕不已，不过项目的流畅是因为印度开发商遵循了什么完整的v模型开发过程，还是因为需求分析的内容都没有改过？不否认管理的重要性，无序状态只会带来失败可以算是公理了。但是需要管理，需要流程到什么程度？实际项目开发中很多问题都是需求变化造成的，有不可回避的客观因素，也有需求分析没有做好的缘故，但是设计，编码，测试的步骤并不能帮助最初的需求分析阶段掌握完整的需求也是肯定的，于是问题就是，如果我们有了完整的，不变的需求，是不是还需要这么完整的开发流程？如果由于某些因素，需求还是变化了，这么完整的开发因素是不是真能帮助我们解决问题？如果项目进行到测试阶段，结果需求变更了，前面的流程，review是不是真能避免有时会发生的整体结构变化？这关系到应该在需求阶段还是开发阶段的流程管理投入最重要的资源。所谓两者都重要，得兼顾之类的废话就不用说了，绝对没错，也绝对没有用。项目开始时有100%的资源，需求是投入30%，40%，还是50%，既然是科学的工程，总的有一个实际能用的数字，如果还需要参照项目经理的能力进行自由心证，依赖于随机数这算什么工程科学？同样，这个问题也是事实上无解的。
UMLCHINA的文章不全，原来的文章还有一大堆对程序员的不满，对印度不考虑效率的快速开发方式的崇拜，总之设计，管理上的问题都归中国程序员，项目的顺利结束归功于印度项目经理和设计师。这里就不作引申了。正好，我见过印度开发商宣称需求上没有性能要求从而拒绝改善性能问题。见过印度开发商对客户提出的需求改变意见干脆利落的回答“NO”， 见过印度开发商对客户反映的bug（运行中出现assert）表示在新版本中修改了，客户应该以50万美金购买新版本（虽然这个被拒绝升级的版本是半年前才交货的，所谓的新版本在原来能运行的重要功能也变得不能运行了），见过印度开发商宣称虽然是bug，但是既然用户以前能用别的手法回避这个问题，现在也应该继续回避，不应该要求他们修改。作为商业手段当然值的参考，但是如果学习软件工程的目标是开发这样的系统，我看也就算了。
我们为什么需要软件工程？是为了开发软件，不是符合什么RUP流程，达到CMMn。我们希望需求分析后，能不依赖个人能力，经验就能估算开发规模，需求上能判断哪些是有比较大的变化可能，哪些可能会相对固定。技术上能发现各种方案有哪些风险，哪些技术难点需要尽早解决，不要开发到了一半才发现技术上不可行再改换方案。需要判断需要怎样的人员组合，怎么样的能力。需要决定是培训人员的能力使能实现优秀的设计，还是调整设计使符合现实。决定关注以后类似项目开发的通用性，还是先做出来再说。需要知道当第一个milestone延期时，整个项目按时完成的可能性还剩多少，需要如何调整。从测试结果能不能推算出到最后提交产品还需要多少时间，预计质量如何。我们需要清楚的知道项目能不能，有没有可能按计划完成。需要知道当项目出问题时是减少功能，还是追加工作时间，还是必须增加人手，或是调整发布时间整个时间表。需要能让团队发挥最大效力。这其中牵涉到管理，心理，组织行为，软件工程，时间预算人员压力的平衡。归根结底一句话，人的能力和能让人发挥能力的体制。
我们不需要什么，不需要无数的进度报告，那些无意义的50%，80%进度没有任何价值，不要说90%完成的功能，就算已经完成的机能也随时会因为需求变化，设计变化而化为乌有。如果项目经理不知道实际情况，只会从报告中了解情况，迟早会发现这个世界突然就不转了。不需要理论家来说一些绝对正确，却不能具体操作的废话，只会让人无所适从，变成一仆多主。不需要去追求某个流程，某个标准只是为了某本书上这么说，而不是出于实际的需要。不需要在项目组成员已经了解设计意图的情况下追求生成完美正确的UML图，更不能有了完美正确的UML图以后就放任项目组成员错误理解意图（可能因为只有图的生成者才学对了UML，使用了某些不常用，容易造成误解的形式，充分展现了才能，而别的成员对UML还没有到这么深刻的地步）。不需要大量的管理以至于项目成员的工作不是完成项目却成了提交报告满足各式各样的管理要求。不需要无数的文档以至于没有人知道哪个才是最新，最正确的（也许全是过时的）。不需要那些不懂编程的设计师写出一堆没人会参考的所谓设计图（参考的危害比扔在一边还大）。不需要那些自己也不知道为什么，只知道CMM要求，RUP说，却自诩为元帅的流程工程师设计一堆只会让人精疲力尽的流程和报告，除非这些流程得到的结果有实际上的指导意义。
可惜，需要的还处于人月神话的阶段，不需要的则是登堂入室，喧宾夺主了。
印度的成功在于瞄准软件外包市场，利用人工差价，我们外包开始还没有几年，人工就没有多少差价了。以前还盯着国内市场，国内有什么市场？家用市场是盗版的天下，企业市场，大量的国企是倒闭都来不及。脑白金这样的产品更是在生产管理上投入1元还不如在广告上投入100元，也就只剩少数企业和政府市场了。这时候什么最重要就不用多说了，谁都知道肯定和软件工程无关，大家抢一小块蛋糕，日子能不难过吗。却非要照搬印度经验。
嘿嘿，到处都是说中国国情，不该说的地方也到处都中国国情，独树一帜。到了真正该考虑的时候，我们就和国际接轨了。倒也是奇哉怪哉。也许这才是真正的中国国情。

 回复: 重读从程序员升级到工程师有感
　

---

呵呵，理解蛮深刻，我倒是觉得你还是可以看看“人月神话”

即使这10名全是以一当百的牛人,在有限时间里我也不能完成前者能完成的工
作.软件工业只有两种模式: 人海战术适合于已经有很好技术及代码积累并且
不断做重复的产品的企业,而特种兵战术适合于需要不断研发新产品的企业.前
者适合印度外包型,后者适合于美欧中俄研究发展型.

所以我在我们以前公司内部文档中建议在项目组设立一个职位叫"document
staff"来处理所有的文档,让程序员帮他review,review总是比较容易做的,他
的工作就是每天找程序员聊工作,聊技术,然后把所聊的内容记下来.

　

印度模式其实是一个成功百分比模式。任何一个项目都不重要，至少没有重要到必须成功，不能被放弃。但是组织起足够多的项目后，在有限的人员能力限制下，对重复代码进行加工以确保成功率，只能完成足够比例的项目，盈利就有保证了。所以它可以把程序员当成替代品，因为任务难度不大，替换就容易了，而且实在不行也可以放弃项目。优点不在于能保证项目成功，是10个类似项目中有8个能成功。基于概率，经验而不是科学。
我们学会了程序员不过是随处可得的工人后，在关键项目上对关键人员都能为所欲为，真的辞职了，就嘴硬心虚，说什么公司不挽留主动辞职者。我倒还没听说有公司挽留那些名为辞职，实为开除的人。还是一个挺有趣的笑话。
另外，如果老兄手下的10个人个个以一当百，你就要头疼了。你忍心把这么优秀的人才浪费到一些简单的重复作业上？好歹也得给他们提供一些开发，测试，写文档，整理归纳的助手吧。不过更多的时候只能有什么锅，吃什么饭。有怎么样的人员，做怎么样的设计和开发。项目有充足的资源，人员也都有足够的能力，我以为出现概率是不算很大的。

必要的文档是需要的，但是不能太多。其实就是一个提醒，备忘作用。文档数量少，一个是更新，追踪容易，另一个是项目成员容易参考。
文档一多，就连看的兴趣都没了。结果有用的文档也没人参考了。3页纸的概要介绍会被人仔细看，300页的详细手册能坚持下来的就不多了。混在一起最大的可能就是谁都什么都不看，指望别人看了。

问题是麦当劳能做这么大，和它单家店的汉堡制作方法有多好无关。
学作汉堡，以当最好的汉堡制作者为目标的厨师如果把麦当劳的的生产工艺当成汉堡的最高水准，除了无知不会得到任何别的评价。这就是我们目前的地位。

嘿嘿，“自由心证”，我喜欢

我举那个一千人的例子在于说明编程不仅是脑力劳动,也是体力劳动, 人多有
人多的好处,让一千个人在同一个项目上工作,印度人的方法有可取之处.(当然
不是指和用户讨价还价的本事).当然,这些方法也不是印度人的发明.

另外我不同意你关于基于的统计控制的生产不是科学的说法,也可能是我们说
的是两回事.呵呵,谁知道呢.

 如果真有可靠的统计结果，当然是科学。
　

---

但是印度的统计我理解是基于同一类型项目的开发。
如果换一个领域，或是换一个语言，他们的统计结果就会发生很大的变化。也就是说我不认为他们的统计结果是普适的。他们的成功是商业上的成功，不是开发艺术上的。
统计数据当然有价值，我们知道即便人员水准类似，3个人干5个月不意味5个人3个月能得到同样成果，问题是需要多少调整系数，是需要6个人3个月，还是4个人4个月，或者是先1个人2个月，然后投入10个人1个月。如果有统计数据能给出一定误差范围内的参考意见，当然是很有价值，也能接受不同工具有不同的参数，但如果说关联因子太多，以至于这个参数随时变化，那么就没有实用上的意义了。就好像预测经济增长率给出一个阿尔法因子，却没有人在统计结果出来前能知道这个因子到底是多少。我不觉得这样的公式有多大价值。
目前程序开发时的统计数据恐怕只有bug收敛还有价值，别的说的天花乱坠的基于统计的预测恐怕都是开发组敏感，不能推广的。
写程序当然是体力劳动，但是在项目内投入重复劳动据我看唯一的价值是由于公用这些部分所需要的优秀程序员资源对项目太奢侈了，可能是人工单价太高，可能是人员缺乏，可能是正被别的项目使用。这种商业上的理由其实是所有程序开发中最基本的决定因素。公司需要在项目间权衡重要度，而不是单个项目的完美。简单地增加人员，利用copy-paste可以避免设计复杂的类结构或者减少switch/if，只是对项目有个临界点罢了。如果能有具体的数据可作参考，也会很有价值，只是我怀疑现在是否有类似材料手册之类的足够信赖的数据。
如果说软件工程相当于理论物理，具体的项目开发就相当于实验物理。同样的力学原理，理论上假想的光滑平面是不存在的，所以在设计产品时必须查材料手册获得从实验中总结出来的摩擦系数等。不同点在于实验物理能在一个受控环境下精确的再现，在固定别的设定时调整某个变量以观察相关关系，可以获得无数的数据从而获得统计学意义。而软件项目开发不能重复实验，环境不能控制，不可能固定只有一个变量变化，以至于任何表面上的相关关系都不能被确认。不管我们有多少经验，不管整个行业总结了多少数据，对于一个还依赖于大数统计原则的学科来说，都还是不足够得出什么可靠的结论的。我们只能和经济学一样，从过去的历史，从过去的数据获得的相关关系来猜测，但一个事实就是，过去的真理也随时可能被新发现的事实推翻。在相当一段时间内，软件工程会像心理学，经济学等一样，有大量的流派，有各自的数据支持，实际上却还是直接依赖专家能力，其实还是基于经验和能力。即便物理还有非线性的问题，何况我们。
其实要成功还是要依靠商业。技术不过是手段而已。

 同意前者。至于汉堡
　

---

呵呵，那是因为你吃的都是大规模生产的产物。
如果我们能有机会请一级厨师精工细作一个汉堡，感觉肯定不一样。问题就是代价不一样，而麦当劳能在维持一定的质量水准下，最大幅度地降低汉堡的生产门槛。如果它提高门槛，质量肯定还能上升，只是产量不一样最后的利润也不一样，它把这个平衡点抓得比较好。理由基于商业而不是基于生产最好的汉堡的愿望。呵呵，据说麦当劳的总裁把自己定义为不动产业。那时它最大的资产和利润来源。
其实，我吃汉堡也就是吃麦当劳。

首先对你的文笔和思维,表示钦佩,我从没有这么多话要说,或者思想可以这么清晰的表达出来.
但我认为文档很重要,对于项目组沟通和后期的开发维护必不可少,我觉得是项目成败或成本的关键.
几位老兄说的都是实情,目前我们对文档的使用确实有问题,写的不用心,看的没信心.

其实是文档的结构和建设问题.索引清楚,详略有致,是关键.
每个需要的人可以很清晰的找到自己需要的东西.
文档在不断建设和完善中,每个人都明确负责自己的那部分.
如果可能,项目生命周期内全部内容,都应有记录.
文档不是纸的,是可以快速查询和有维护机制的消息系统.

瞎说的.我也一直苦恼文档问题,但如有可能,我会要求 市场 设计 开发 测试 实施 的同志把文档的制作和阅读做为"完成工作的一部分".

文档也是沟通的一种手段，而且不是任何条件下最有效的手段。说文档是项目成败的关键未免有点过了吧？
你说文档应该详略有致，这很对。而且应该再进一步，“有所写，有所不写”。

具体到一个项目需要多少文档，需要哪些文档，都应该根据项目的具体情况而定，比如开发团队的规模、开发地点是集中还是分散、与客户的沟通是否顺畅、甚至企业文化都会决定文档是需要多还是少、是需要正式的，还是可以随意的。

一个项目组要写的文档越多，维护文档与实际系统同步的工作量就越大。而不能同步的文档实则是“成事不足，败事有余。”

其实文档有很多种，有提交给最终用户的，有在内部交流的，有阶段工作完成的移交。最为重要的就是一个是更新速度，一个就是量。维护文档的最新也是一项很艰苦的工作。如果让全体成员都有保存文档的任务，一个是占用了原本本职工作的时间，一个就是谁都有责任，就变成谁都没责任了。
我以为，一个项目组，应该是指定专人负责文档，视情况可以是专职。他负责更新文档，然后从项目成员回收过时文档。将项目成员间的交流（mail，白板，纸张）全部记录下来，整理归纳。别人就不用操心了。如果要求项目成员的交流必须自己完成要归档的文档，反而是加深了交流的壁垒。很多人就会干脆等别人来找，自己不找这个麻烦了，必须要成员感到轻松，没有压力，交流才会容易展开，对沟通更有利。
另一方面，文档的量也是大问题。项目成员应该能访问想阅读的文档资料，但绝不应该把所有文档都发送给成员，虽然这最简单。按照各自的任务发送直接有关的资料，3，5页的资料对方会抽空看看，动辄就是三五百页的资料，其中有用的不过10来页，一般人是会连看目录的兴趣都不会有，更不用说去找了。多半是反应到有空再看，项目一忙起来，一周下来积累的文档就不会是能读完的了，而且还不知道有多少是已经变得过时了。所以及时回收过时文档也很重要。其实很容易理解，1天有10封mail，会仔细阅读，1天有100封，50%的就是只看个标题了。1天500封，80%就是直接作为垃圾邮件扔掉了。现在网络的发达，通信的便利，主要问题已经不是获得足够的信息，而是从众多信息中找出有用的。
而且量一多，质量就难以保证，源代码里的注释就真的能相信吗。大家都清楚。这是现实，不是单纯某个人的态度问题。至于是纸张还是电子化倒是其次了。
无疑，像测试结果之类的文档是必须而且要保存的，但这些文档是项目历史文件，不应该浪费程序员或测试员的时间把那些项目内快速交流的代号换成正常的说明。应该由专人进行，一个是风格可以统一，二来是有专人负责，不会出现踢皮球的现象。最大的好处就是本来是10个成员每天用1小时在文档上被认为是正常的，现在一个人8小时专职用在文档上面解放了其他人，其实对项目有利，节约了时间，但是项目经理就会有浪费了一个人的感觉，从而有不自觉的压力控制文档量不超过一个人能处理的范围，也减轻了项目成员的阅读压力。报告也可以口头进行了。

所以我以为文档宁缺勿滥，最后提交给用户，项目历史留存可以有大量文档，但在进行过程中，最好是让成员感受不到有专门文档的影响。只有email通知，纸张上几句简单的说明，白板上的讨论之类的，而没有工作到一半，然后放下工作去辛苦完成某个特定格式文档的挫折感。话说回来，付了程序员的工资，却消耗在文档排版上，对公司也不算有价值，对项目经理不也是浪费了项目成本预算？

 至于汉堡
　

---

据我所吃，汉堡还数加利福尼亚州的In & Out 最好吃，其余的象麦当劳、肯德基之流确实吃坏你的口味。

高效的文档是我目前所知最可靠的沟通手段,所以对于文档的作用,每个项目经理都不能忽略.
但正如你所说,组织不好,更新不同步的文档"成事不足,败事有余".

软件开发中的风险中,我想"沟通"占很大的比重,这我有切身的体会,软件开发本身是一个创造性的活动,但它的最终结果是现实的逻辑紧密的产品,让我们的思路收敛明晰,大家达到共识,是这个集体创造活动的成败关键,而我们并完全不能相信人类变化多端飞逸的思想,我们需要文档;我们也不能完全保证个人因素的变化,文档是必要的补充.所以,我一直都在寻找一个合理的文档组织和管理办法,遗憾的是,没有成功,绝大多数项目文档的建立是需求+简单设计分析+测试+用户手册,项目开发的经验(一个公司长远发展的财富)在项目经理脑子里,而不是在公司和集体的脑子里.遗憾.

有点顽固,我还是那句话,尽可能利用可掌握的资源,建立合理的文档;但要加上您的意见:1.文档是手段不是目的,2.不合理的手段,干脆不要.

感谢你的帖子,对我很有用.

还有一个目的,就是公司完善管理,丰富开发手段,捕捉灵感的积累.

你说的不错,我同意.文档是个重要的问题.

因为文档有很多种,目的,作者,阅读者,形式都不一样,所以我们也没有必要完全一概而论.用户需求,用户手册,单元测试,整体测试,项目验收,维护日志,这些完全可以专门专人负责,并有特别风格样式来保证质量.

而设计和开发阶段,就必须灵活一些.资料性定性的技术文档,要有很好的索引和标题,方便大家在需要是快速查询;设计性和未定性的文档,应该有概述,简介,尽量简洁.让每个开发设计人员都负责文档,并不完全指代码中的注释,我更偏向于他对自己负责单元的简单实现描述,接口,术语,测试范例指导描述.

文档电子化,是为了大家检索方便,同时也不存在大家手里版本和别人不一样的情况,就像web和MIS的一个区别.建一课web 文档树.

email不是文档,它很重要,也有效,但不是我们可信的开发依据,我可以发信告诉你,你所需要的解决问题的答案,和在项目文档树中的位置,但并不能对Email 负责,而文档树可以.

文档应该清晰指导大家开发,一定的量是必要的,但开发设计者完全可以只看其中和自己相关的部分.

如果设专门的文档人员,他一定要有足够权威和沟通能力,最好是项目副经理,经理助理一类的人物.

我不否认的文档的作用
但我还是觉得总结作用的文档不应该干扰开发阶段的工作。
文档工作最大的工作量在于同步和更新。而且一个完善的内部文档交流机制永远比不上成员间在喝咖啡，吃饭，简单的小会议上的口头交流。经验需要总结，不过我觉得在项目结束后进行的效果会更好。可惜现实层面上很难。设备一般都不会超过80%的使用率，但是程序员一般被要求120%以上的压力负荷。而且开发时浪费一个月都可以算不得已。开发结束后用2，3天总结就算巨大的浪费了。

另外一千个程序员,今年,在中国很好找的.

你可以简单的发一个email解释一个问题，如果牵涉到设计上的补充或是修改，就必须在全文档范围内查找有无冲突。
文档树是一个达到目的的好手段，不等于有了文档树就足够了。
如果必须登记到文档树上，一个是合理的位置需要判断，一个是check的范围需要判断并检查。如果不交给专人处理，由email的发送方自己负责的话，我不觉得有利于沟通。另外，email是确认设计意图的历史参照，不是说它就是文档了，而是极好的历史参照数据。是必须保存的。然而，个人的环境设置不一样，还有崩溃重装的可能，所以我以为应该在进行过程中对项目成员来说透明地被记录归档。
另外，仅仅是电子化并不能保证成员都用最新的，还有更新速度的问题，一个以确认的修改需要多久才能反映到文档树。很有可能成员最初打印了全部文档，在开发到中后期时，他还按照原来的文档在开发。一个依靠程序员自己随时检查文档的更新状况，另一个就是通知更新了。但是所有内容的更新发送对任何一个成员来说，都是无关内容太多，不容易找到自己相关部分。发送相关消息则是对文档人员压力太大。
至于权限，看项目规模了，可以有低级的文档归纳整理人员，也可以有高级的文档内容检查确认人员。完全看是否拥有足够的资源。
另外我提到代码中的注释，是说程序员实际上连代码上的注释都未必能及时更新，会去更新其他的说明文件可能性就更低了。人的弱点是不得不考虑到的。拥有完美部下永远只是领导们的一个梦想。

如果文档的更新,设计到大片的文档树,软件危机也来到了.文档结构的改善可以尽量减少这种情况,但正在开发的代码和同志们已经落地的思想,却不是管理手段可以轻易改正的,也许只有靠集体的能力和运气了.

EMAIL是重要的依据,很正确,我想说的是,你如果要相信我EMAIL里所说的话,你应该在文档树里找到集体的话.

更新和权限是有很多华而不实的技巧的.可以减少工作量,我也设计过一些,但人是最重要的,项目经理尊重每个成员,并热心服务;每个成员的责任感,有时比能力还要重要.有个趋势,每组成员,对负责单元,都对相当的设计负责.项目经理并不说你们应该怎么做,成员自己在沟通时向别人介绍,表示成文档,对自己说过做过的负责.

吹捧一下,你确实有很多想法和经历,哈.