1.一接到任务就开始Coding的程序员，通常就是加班最多的程序员。
记住：积极工作和勤于思考都要占时间。
2.做管理起码需要能承担责任，这是最基本的素质。
3.你的项目经理职位又没有让给别人做，你拿的经理级工资又没有分给别人，那项目失败了，你为什么要把责任推到别人头上呢？
4.经验丰富的工程师能尽可能接近地预估工期，但没有办法保障(预估的)工期是绝对合理的。那么进一步的推论是，由于没有绝对合理的工期，所以项目的完成时间可能总是
被进度变更所修正，所以项目也就总是不能“成功”。项目工期的问题不能解决，就不能保证项目成功。只有经验更加丰富，才能更尽可能地逼近“合理的工期”。因此在此之前，项目
经理面临的就是失败。这个失败可能不是项目经理本身能力所决定，或者也不是团队成员的工作所决定，而是在一开始，那份给客
户的项目协议就签错了。
5.软件工程中有专门的学科来研究项目的工期问题。学者们试图寻找公式来计算项目的复杂度，从而计算出所需的工时和人月。然而在实践中，这被认为是不可行的
6.如果员工在工作中出了纰漏：
没有制度，你没有办法和依据来惩戒员工，因此是管理者的过失；
有了制度而没有惩戒他，是执行者和监督者的过失；
一而再、再而三地犯错，又一而再、再而三地被惩戒，那就是教而不改，就真正是员工的品性和素质的问题了
7.在任何错误被归咎于员工之前，管理者应该先想想是不是自己的问题。是的。你可能很快发现问题出在了管理者。因为管理者没有
确定组织机构模式，或者没有为组织中的成员进行角色定位和分工。如果这样，出现“既不能令，又不受命”的人就是必然的事了
8.一个至少由三个人构成团队：项目经理，开发经理和开发人员。其中，在开发经理和开发人员之间，既存在主从关系，也存在协作
关系。而项目经理，则在团队中处于领导者、组织者和团队保障者的地位。如果非得要精简到两个角色的团队模式，那么这种情况
下，通常是开发经理兼任项目经理，因此这位开发经理一定要能清楚地区分这种双层角色的身份：在任何时候，明确自己是在进行
“团队内协作”、还是“团队管理(和组织)”、还是在与“团队外交流”。如果这个开发经理总是混淆自己的角色，那么，我建议，换人吧。
9.团队真的需要管理吗？
这经常是“经营”开发团队的管理者最容易给错答案的问题。这些管理者兢兢业业，试图细化每一个管理环节，将自己的意愿贯彻
到⋯⋯EN，CPU里去。
实际上，开发团队并不需管理。或者说，在你还没有弄清楚状况之前，不要去管它。
10.禀性难移，要改变一个人都难，何况是改变一个团队的既定习惯。
如果有一群开发人员象蚂蚁一样辛勒地工作着，那么，先不要打扰他们。你应该跟随他们，看看他们是如何做的。发现规律，分析
这个规律的价值，最后再尝试改变它们(的一些负面价值的规律)。
11.尽管弹性分工非常有效，然而真正做弹性分工却并非易事。
更好的选择是明确分工，而不是弹性分工。你应该明白，重要角色的更替通常是极具风险的，例如项目经理或
者开发经理；频繁的开发人员的调度也会直接影响到工程的质量和进度。
12.维护旧项目比做新项目更难，许多人深有同感。然而这些“有同感”的人又何曾想过，自己在做“新项目”的时候，要为“项目维护”这种还不存在的角色，留下一个沟道、对话的渠道呢？
我把项目的History作为跟这种“不存在的角色”沟通的一种方式。History的丰富和准确为项目的后继开发、维护提供了可能。
13.UML的确是解决沟通问题的最佳手段之一。然而如果项目一开始就不能用它，那么强求的结果必然是痛苦的。——要让UML在一个没有经过相关培训的团队及其各个角色之间用起来，几乎是不可能的事。即使用得起来，也存在经验问题。千万不要指望仅仅一个项目，就能让你的组员深刻的理解UML的思想。使用与不使用UML，其根本的问题在于沟通方式的选择。只要是行之有效的、能在各个项目角色间通用的，就是好的沟通方式。
14.流于形式的沟通，可能是使得你的项目被不断推翻和不断延迟的最直接原因。
15.相对于瀑布模型，V模型有改变了什么吗？是的。源于实际的需要，它把测试(和评审)阶段抽取出来，于是就成了V模型。
16.用RUP用不好的人，总会说自己终归还有一堆文档模板可以抄
17. 如果懂得了所谓的模型原本都演化自那个简单的瀑布，那么文档是按XP写还是按RUP写，也就可以应时、应需，因地置宜，择善而从了。
18. RUP中，真正精髓的东西，既不是那个R(Rational)，那是人家的招牌；也不是那个U(Unified)，那是人家的广告。而是那个P(Process)，那才是实实在在的东西。
19.无论是你的团队成员，还是你的老板，对重复的错误以及可预料的错误都是不会宽容的。——在一个团队中，失去了组员的信任比失去老板的信任更为可怕。所以回顾每一个项目，或者项目中的每一个阶段，以及与每一个团队成员交流的细节，是你的日常工作。
20. RUP其实就象一个杂物箱一样“包容”了全部的已知理论。
21. 总之一件事，没有人会跳出来说：我们原本就错了。然而事实上可能真的出在源头：我们把目标定错了。
我们看到，在项目的平衡三角(时间、资源和功能)中讨论的是目标问题，但并不讨论质量问题。也就是说，经典教材中总是关注：如何更快的完成项目，并减少资源占用，以及实现更多的功能。然而，即使平衡了这种关系，项目的结果仍可能产生一个天生的残障。
因为目标可能在平衡中确立，但质量却要在过程中控制。即使在时间、资源和功能三者中取得了平衡，即使客户、项目组和公司同样满意于这个平衡“目标”，它仍然有可能是“不能实施”的。
如果原定的目标(的整体)本身就过大，那么无论如何平衡这三者之间的关系，其结果仍旧是保障不了质量。
22.大多数情况下，管理人员有责任去审核、评估其它成员的工作成果。这个时候可以讨论“细节决定成败”这样的问题，因为这决定了产品的最终质量，而质量是工程的目标之一。
而在另一些情况下，例如管理人员做事件的决策的时候，就必须要学会忽略枝节问题。
23. 从惯于“实做”的程序员一路走来的工程人员，很难分清自己什么时候是在“工作”，而什么时候又是在“决策”。
因此我只好用最笨的方法提示管理者：别管它是细节还是枝节，只要你感到你的脚趾已经沾上了泥淖，就快点回头。
用脚趾去感觉，有时比用头脑去思维来得有效。
记住：积极工作和勤于思考都要占时间。
2.做管理起码需要能承担责任，这是最基本的素质。
3.你的项目经理职位又没有让给别人做，你拿的经理级工资又没有分给别人，那项目失败了，你为什么要把责任推到别人头上呢？
4.经验丰富的工程师能尽可能接近地预估工期，但没有办法保障(预估的)工期是绝对合理的。那么进一步的推论是，由于没有绝对合理的工期，所以项目的完成时间可能总是
被进度变更所修正，所以项目也就总是不能“成功”。项目工期的问题不能解决，就不能保证项目成功。只有经验更加丰富，才能更尽可能地逼近“合理的工期”。因此在此之前，项目
经理面临的就是失败。这个失败可能不是项目经理本身能力所决定，或者也不是团队成员的工作所决定，而是在一开始，那份给客
户的项目协议就签错了。
5.软件工程中有专门的学科来研究项目的工期问题。学者们试图寻找公式来计算项目的复杂度，从而计算出所需的工时和人月。然而在实践中，这被认为是不可行的
6.如果员工在工作中出了纰漏：
没有制度，你没有办法和依据来惩戒员工，因此是管理者的过失；
有了制度而没有惩戒他，是执行者和监督者的过失；
一而再、再而三地犯错，又一而再、再而三地被惩戒，那就是教而不改，就真正是员工的品性和素质的问题了
7.在任何错误被归咎于员工之前，管理者应该先想想是不是自己的问题。是的。你可能很快发现问题出在了管理者。因为管理者没有
确定组织机构模式，或者没有为组织中的成员进行角色定位和分工。如果这样，出现“既不能令，又不受命”的人就是必然的事了
8.一个至少由三个人构成团队：项目经理，开发经理和开发人员。其中，在开发经理和开发人员之间，既存在主从关系，也存在协作
关系。而项目经理，则在团队中处于领导者、组织者和团队保障者的地位。如果非得要精简到两个角色的团队模式，那么这种情况
下，通常是开发经理兼任项目经理，因此这位开发经理一定要能清楚地区分这种双层角色的身份：在任何时候，明确自己是在进行
“团队内协作”、还是“团队管理(和组织)”、还是在与“团队外交流”。如果这个开发经理总是混淆自己的角色，那么，我建议，换人吧。
9.团队真的需要管理吗？
这经常是“经营”开发团队的管理者最容易给错答案的问题。这些管理者兢兢业业，试图细化每一个管理环节，将自己的意愿贯彻
到⋯⋯EN，CPU里去。
实际上，开发团队并不需管理。或者说，在你还没有弄清楚状况之前，不要去管它。
10.禀性难移，要改变一个人都难，何况是改变一个团队的既定习惯。
如果有一群开发人员象蚂蚁一样辛勒地工作着，那么，先不要打扰他们。你应该跟随他们，看看他们是如何做的。发现规律，分析
这个规律的价值，最后再尝试改变它们(的一些负面价值的规律)。
11.尽管弹性分工非常有效，然而真正做弹性分工却并非易事。
更好的选择是明确分工，而不是弹性分工。你应该明白，重要角色的更替通常是极具风险的，例如项目经理或
者开发经理；频繁的开发人员的调度也会直接影响到工程的质量和进度。
12.维护旧项目比做新项目更难，许多人深有同感。然而这些“有同感”的人又何曾想过，自己在做“新项目”的时候，要为“项目维护”这种还不存在的角色，留下一个沟道、对话的渠道呢？
我把项目的History作为跟这种“不存在的角色”沟通的一种方式。History的丰富和准确为项目的后继开发、维护提供了可能。
13.UML的确是解决沟通问题的最佳手段之一。然而如果项目一开始就不能用它，那么强求的结果必然是痛苦的。——要让UML在一个没有经过相关培训的团队及其各个角色之间用起来，几乎是不可能的事。即使用得起来，也存在经验问题。千万不要指望仅仅一个项目，就能让你的组员深刻的理解UML的思想。使用与不使用UML，其根本的问题在于沟通方式的选择。只要是行之有效的、能在各个项目角色间通用的，就是好的沟通方式。
14.流于形式的沟通，可能是使得你的项目被不断推翻和不断延迟的最直接原因。
15.相对于瀑布模型，V模型有改变了什么吗？是的。源于实际的需要，它把测试(和评审)阶段抽取出来，于是就成了V模型。
16.用RUP用不好的人，总会说自己终归还有一堆文档模板可以抄
17. 如果懂得了所谓的模型原本都演化自那个简单的瀑布，那么文档是按XP写还是按RUP写，也就可以应时、应需，因地置宜，择善而从了。
18. RUP中，真正精髓的东西，既不是那个R(Rational)，那是人家的招牌；也不是那个U(Unified)，那是人家的广告。而是那个P(Process)，那才是实实在在的东西。
19.无论是你的团队成员，还是你的老板，对重复的错误以及可预料的错误都是不会宽容的。——在一个团队中，失去了组员的信任比失去老板的信任更为可怕。所以回顾每一个项目，或者项目中的每一个阶段，以及与每一个团队成员交流的细节，是你的日常工作。
20. RUP其实就象一个杂物箱一样“包容”了全部的已知理论。
21. 总之一件事，没有人会跳出来说：我们原本就错了。然而事实上可能真的出在源头：我们把目标定错了。
我们看到，在项目的平衡三角(时间、资源和功能)中讨论的是目标问题，但并不讨论质量问题。也就是说，经典教材中总是关注：如何更快的完成项目，并减少资源占用，以及实现更多的功能。然而，即使平衡了这种关系，项目的结果仍可能产生一个天生的残障。
因为目标可能在平衡中确立，但质量却要在过程中控制。即使在时间、资源和功能三者中取得了平衡，即使客户、项目组和公司同样满意于这个平衡“目标”，它仍然有可能是“不能实施”的。
如果原定的目标(的整体)本身就过大，那么无论如何平衡这三者之间的关系，其结果仍旧是保障不了质量。
22.大多数情况下，管理人员有责任去审核、评估其它成员的工作成果。这个时候可以讨论“细节决定成败”这样的问题，因为这决定了产品的最终质量，而质量是工程的目标之一。
而在另一些情况下，例如管理人员做事件的决策的时候，就必须要学会忽略枝节问题。
23. 从惯于“实做”的程序员一路走来的工程人员，很难分清自己什么时候是在“工作”，而什么时候又是在“决策”。
因此我只好用最笨的方法提示管理者：别管它是细节还是枝节，只要你感到你的脚趾已经沾上了泥淖，就快点回头。
用脚趾去感觉，有时比用头脑去思维来得有效。
扫一扫
414
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
