《播客》项目总结——项目管理方面
引言：
如果标题改成《被管理总结》的话，我可以滔滔不绝的说上个半天，但是如果是管理项目的话，我实在肚里的货有限，因为到至今做过的最高职位不过是个“班长”而已。
但是这次《播客》项目在管理方面的确出了问题，而且是满严重的问题，以至于到后来项目差点失控，而且最终的交付作品质量的确让人汗颜。如何避免下面程序员很累，但效率却很低；上面不停的催，产品却一个bug接一个bug，完全没法交付；项目经理累的要死，项目却仍然处于失控状态这样的问题和局面？在一个差点失控的项目刚刚结束后，这些问题难道不值得好好的总结和反思吗？虽然我在项目管理方面的能力有限，但是我仍然希望通过这样的总结，让下次的项目尽量避免和改进这次出现的问题。我很高兴，因为我依然走在“好好学习，天天向上”的道路上……
最近在看《快速软件开发》这本项目管理方面的书，本来想按章按条的对照这个项目来写出总结，但是我发现那样的死书读来又有何用呢？那样得出的结论还是你真正实际感受到的项目方面的问题吗？那样的文章还会有人看吗？那样条目的罗列还能给别人和自己以启示吗？所以，最终我放弃了那种想法，而采用这种可能词汇上很“外行”，但是却是来自亲身经历的感悟的方法来写。
正文：
时间真的够吗？
也许是我做日本外包项目时间比较长了，所以当我听到这个《播客》项目需要在一个月内从无到有的出来的时候，我很惊讶，因为这样的“人月”资源可能只相当于我以前在日企“人月”资源的1/5，甚至更少。也许你会说我们不需要那么多的文档，那么严格的流程。所以如果把“需求分析”的时间去掉，把“概要设计”的时间去掉，把"详细设计"的时间去掉，而且我们不需要程序员去测试，我们有专门的测试小组。所以既然去掉那么多的步骤了，所以时间缩短到1/5应该完全是可以的吧。但是你知道吗？项目管理不是简单的“3-1“再"-1"那么简单的加减运算。当你用3-1的时候得到的不是2，而是1，甚至更少，过于冗余的东西的确可以被精简掉，但是很多的东西，当你在初期认为是可以精简的时间而精简掉的时候，后期会花费2-10倍的资源来弥补，那将是得不偿失的，例如“需求分析”。我很遗憾的看到这次项目竟然没有“画面迁移图”。所以导致后来页面的跳转很乱，甚至出现，一些页面虽然做出来了，但是却没有入口的情况。
听团队里一个资历较老的同事说，他们上一个项目经理，从不考虑时间够不够，上面定的完成时间从来都不反驳。上面说一个月完成就是一个月，上面说一个星期完成就一个星期。“那能完成吗？”，我问。“当然完不成了，加班呀！死加！结果加班也完成不了，然后就对上级说程序员效率低。把责任都推给下面的人。” 结果，后来整个团队的人心全散了。而赵就是在这样的情况下接下了摊子，所以我听了这个故事以后很为他捏了把汗。
参考解决方案——
时间估算是个有力的工具。在项目初期可能估算的差浮很大，但是在每个“里程碑”的阶段以后再次作出的时间估算将更准确一些。直至最项目完成时，时间估算将趋于精准。这给予我们的启示是——
1：项目初期，不要把时间期限限定死了，而是应该在一个范围内。“对不起，在没有作出充分评估和分析之前，我不能回答你准确的完成日期，但是初步估算，这个项目需要1个月到3个月之间。最有可能完成的时间是2个月”。这样的回答将是比较好的。很可能上面会被你的“3个月”这个上限吓住，但是，当你的项目真实的是在2个月的时候完成的时候，那么最终你的评价将会更好。讲个小故事：我小时候就是喜欢吃糖果。特喜欢附近小店1块钱10个的那种硬糖，每次买一块钱的。每次去买时，如果是老板娘，她总喜欢，抓一小把先放到我手里（大约5个），然后再一个一个地加到10个。而老板的话，他却喜欢抓一大把放在我手里（大约15个），然后再一个一个地拿走，直到我手里还剩10个。不知道何故，我超喜欢老板娘，却恨死了老板。
2：每次进行到一个“里程碑”的工作之后都要重新进行时间估算，以提供更为准确的时间范围。同时也便于总结为什么上一个阶段花费了那么多的时间。
到底做成什么样子？
作出时间估算的最基本的依据就是需求分析。到底要做成什么样子？到底在什么环境下使用？到底需要哪些功能？到底有多少页面？各个页面之间到底是如何跳转的，这个页面的是从什么地方进来的，又可以从什么地方出去？……有多少项目是在真正搞清楚这些需求后才开始的？还是更多的是——“差不多就是做成那个样子”，“先做着，一些功能反正以后可以再加”，“策划部说，现在能不能把这个功能也加进去？”……需求不明确就开始动工的危害我就不多说了，但是有个数据我还是要列举一下——“初期花费1个资源单位能够解决的雏形问题，如果发展到后期将需要2-10个资源单位来解决”。
参考解决方案——
如果真的时间很紧的话（毕竟对于软件或者网站来说，特别是商业软件或者商业网站来说，发布时间、抢占市场是第一位的），我认为像详细设计这样的东西的确可以精简一些，但是需求分析，画面迁移图这样的东西还是要求严格一些比较好。其实项目的初期，很多的人都是很闲的，一些东西完全可以先由比较空闲的人来完成，然后大家讨论然后定论一下来完成。这样不仅可以完成这些至关重要的东西，而且对于团队的热身和保持活力很有益处。不会出现“闲的时候闲死，忙的时候忙死”的现象。
注意，这些东西都需要文档，而不是口头上的决定。
坏苹果
因为就如同我面所提到的，上个项目经理把这个队伍带散了，整个人心都乱了，所以这个团队根本没有什么团体文化而言。甚至出现了“拿工资混日子”的“bad apple”。但是如果仅仅是“拿工资混日子”那样的话危害好像还不是很大，如果出现这样的“worse apple”的话，整个项目将危如累卵了——
参考解决方案——
也许对坏苹果最快速和有效的解决方案是——开掉！但是那真的是最好的办法吗？有没有想过是什么土壤滋生了这些“坏苹果”？我就在我们的公司中发现了2个很不好的问题——
1：没有明确的奖励制度。就如同以前文革的时候吃“大锅饭”一样，干好干坏一个样，反正每个月就是那么多的工资。如果每个人真的都那么想的话，那么惰性就出来了。
2：只有不合理的惩罚措施，虽然技术中心还没有这样的措施，但是听说编辑那边，上传的文章如果出现了错别字是要扣钱的。我最反对的就是“扣钱”这样的措施。因为特别容易激起员工的“抵触情绪”。也许你会说，如果上班迟到不扣钱的话，那么大家都迟到要怎么办？其实，扣钱和奖钱是相对的。将本来应该给予的钱抽出一部分（当然下面的员工是不知道的）。然后做的好就在全额发下去，如果有违规就去掉一部分，然后将余下的发下去。就如同很多企业所谓的“全勤奖金”一样。没有什么深奥的东西，心理策略而已。
所以虽然“开掉”是最有效和快速的方法，但是如果很多滋生坏苹果的土壤不改善的话，再怎么开也没有用，坏苹果还是会一个接一个的冒出来。建立良好的团队文化，合理的公司制度，一个积极向上的团队才是最根本的解决方案。
跟踪和反馈
在项目初期，项目还在掌控之中的时候这个做的还是比较好的，但是到了后期这些东西却没有被很好地执行和贯彻。给我印象比较深刻的是对bug的跟踪问题。到了后期，一些bug出现对应不明确，甚至出现bug没人修正的现象。bug的修正任务分配下去，下面却忘记修正，或者虽然修正了，但是修正不正确不全面。还有就是下面的人对修正的bug不进行测试，甚至连跑都不跑一下。出现这样的现象，后期程序员比较累，惰性比较大是一个方面，但是更多的是因为没有有效的跟踪和反馈机制造成的。
参考解决方案——
刚进公司的时候，赵问我“你们公司PL （Programmer Leader）是怎样一个职位？都做些什么？”。我说，“其实PL就是PM到PG的桥梁”。也许那时候还没有那么深刻的体会到所说的这个比喻，但是现在似乎有更深刻的理解了。这次项目，到后期，赵（PM）几乎可以说忙的没有办法了，所以像bug跟踪和反馈这样的问题也只能放下了。但是PM不管，那让谁了管呀。其实这样的事情就是应该PL来做的。PL去走整个完整的bug修正工作流，然后对PM汇报即可。什么bug，修正了没有，修正好了没有，有没有测试，有没有引起其它的新的问题，有没有反馈给测试部。这些详细的工作流都是应该让PL来跟踪的。PL走完这个工作流以后，然后向PM汇报就可以了。这样PM也可以在总体上进行跟踪。上个项目，有一个人没有被充分的利用，那个人就是——我。我是负责页面样式和web标准的。这些东西在初期是最忙的，但是到了后期别人最忙的时候，我却是最清闲的。不过是偶尔修正一下页面上的反馈问题罢了。其实这个时候，我应该充当起PL的这个角色，把赵在初期做的一些过于细节性的东西（例如一些跟踪和反馈的工作流）接过来做。而PM这个时候去专注于更紧急和更重要的事情上去。因为刚进公司，所以，上个项目我完全是一个new comer。所以很多的事情，我都在尽量的保持低调。以免给别人留下过于突进和浮躁的印象。所以，到后期，看到别人很忙，而我却很轻松的时候，我有些不安。所以在下个项目中，我将尽量的主动的去承担一些我能够胜任的工作。以在一定程度上减轻赵的负担。
代码review太浪费时间？
这次项目算是吃够了代码质量低下的苦头。到了后期甚至出现很多代码需要赵重新来写一遍的情况。出现这种情况的代价是巨大的。部分模块所编写的代码完全推掉重写，毫无疑问这些所花费的资源都就将被浪费。到了项目后期项目最紧的时候，PM却在写代码！PM的精力也是有限的，他的时间也是有限的，如果他在写代码，那么是谁在进行项目管理呢？更重要的是他让人们感觉整个项目漏洞百出，从心理上打击整个团队。在项目初期，特别是项目时间估算过短的话，代码review好像的确很浪费时间的样子，但是“bug发现的越早，修正的越早，所付出的代价越小”这句话绝对是真理。
参考解决方案 ——
提高代码质量，重视项目品质，绝对是项目管理中的重中之重。而提高代码质量和项目品质的比较有效的方式就是代码review手段。严格的、统一的代码我感觉比“散落的”、“个性的”代码拥有更好的可读性和维护性。还有我感觉代码review对于新人的进步和编码的习性上有很好的指导意义。很多企业对新人培训很头疼，其实我觉得最好的就是方法就是review他写的代码，在他还没有养成坏习惯的时候，给予制止和指导。
版本控制
版本控制如果失败，真的会如我在《《播客》项目总结——web标准页面设计方面》所说的，轻则令人抓狂，重则吐血身亡。这次项目在部署的时候就出现一些值得深思的现象——当部署的时候，执行的存储过程竟然不是最新版本的问题。结果导致最终部署的时候花费了大量的时间和精力用于调式和查错。同样是因为版本控制的问题，项目后期竟然出现了几乎将线上的真实运行环境当作测试环境的严重问题。想想，如果，以后真的访问量很大的时候，用户点点就出现“黄屏”的情况，那将是多么严重的事情。
参考解决方案 ——
其实版本控制的软件大家都有，而且都大同小异，为什么别人的版本控制成功，而我们的版本控制那么混乱？其实根本的原因不再源码控制软件或者说版本控制软件上，而是工作流程和工作态度的问题。很多的时候为了图个方便就不按照严格的工作流程来走，结果到最后工作流程形同虚设。自然会出现那样或者这样的问题。版本的控制问题只是这些坏的工作习惯的诸多恶果中的一个罢了。
后记：
写着写着突然感觉有点乱了，感觉到处都是问题，又到处都是已经上面讲过的问题。所有的大大小小的问题搅浑在一起，让我感觉眼前一篇浑沌。其实，这些问题就如果程序跑不通过时的提示错误，几百个，甚至几千个，其实都是由那几段核心代码的错误造成的，你会发现，如果修正了那几段核心代码后，那成百上千个的错误提示都会随之消失。就如同项目管理上的，如果真的建立起一个健康向上的团队，所有的看起来浑沌一片的问题也都随之消失了。
前面的文章中其实也只是列举了部分的问题，所谓的参考解决方案更是井底之蛙所见，各位看官看看也便罢了。
相关文章链接：《播客》项目总结——web标准页面设计方面
keyword:软件项目总结,软件开发项目总结,项目管理工作总结,项目管理总结,软件项目总结报告,工程项目管理总结,软件测试项目总结,软件项目总结范文,软件项目管理,软件项目管理案例,软件项目管理经验总结
如果标题改成《被管理总结》的话，我可以滔滔不绝的说上个半天，但是如果是管理项目的话，我实在肚里的货有限，因为到至今做过的最高职位不过是个“班长”而已。但是这次《播客》项目在管理方面的确出了问题，而且是满严重的问题，以至于到后来项目差点失控，而且最终的交付作品质量的确让人汗颜。如何避免下面程序员很累，但效率却很低；上面不停的催，产品却一个bug接一个bug，完全没法交付；项目经理累的要死，项目却仍然处于失控状态这样的问题和局面？在一个差点失控的项目刚刚结束后，这些问题难道不值得好好的总结和反思吗？虽然我在项目管理方面的能力有限，但是我仍然希望通过这样的总结，让下次的项目尽量避免和改进这次出现的问题。我很高兴，因为我依然走在“好好学习，天天向上”的道路上……
最近在看《快速软件开发》这本项目管理方面的书，本来想按章按条的对照这个项目来写出总结，但是我发现那样的死书读来又有何用呢？那样得出的结论还是你真正实际感受到的项目方面的问题吗？那样的文章还会有人看吗？那样条目的罗列还能给别人和自己以启示吗？所以，最终我放弃了那种想法，而采用这种可能词汇上很“外行”，但是却是来自亲身经历的感悟的方法来写。
正文：
时间真的够吗？
也许是我做日本外包项目时间比较长了，所以当我听到这个《播客》项目需要在一个月内从无到有的出来的时候，我很惊讶，因为这样的“人月”资源可能只相当于我以前在日企“人月”资源的1/5，甚至更少。也许你会说我们不需要那么多的文档，那么严格的流程。所以如果把“需求分析”的时间去掉，把“概要设计”的时间去掉，把"详细设计"的时间去掉，而且我们不需要程序员去测试，我们有专门的测试小组。所以既然去掉那么多的步骤了，所以时间缩短到1/5应该完全是可以的吧。但是你知道吗？项目管理不是简单的“3-1“再"-1"那么简单的加减运算。当你用3-1的时候得到的不是2，而是1，甚至更少，过于冗余的东西的确可以被精简掉，但是很多的东西，当你在初期认为是可以精简的时间而精简掉的时候，后期会花费2-10倍的资源来弥补，那将是得不偿失的，例如“需求分析”。我很遗憾的看到这次项目竟然没有“画面迁移图”。所以导致后来页面的跳转很乱，甚至出现，一些页面虽然做出来了，但是却没有入口的情况。听团队里一个资历较老的同事说，他们上一个项目经理，从不考虑时间够不够，上面定的完成时间从来都不反驳。上面说一个月完成就是一个月，上面说一个星期完成就一个星期。“那能完成吗？”，我问。“当然完不成了，加班呀！死加！结果加班也完成不了，然后就对上级说程序员效率低。把责任都推给下面的人。” 结果，后来整个团队的人心全散了。而赵就是在这样的情况下接下了摊子，所以我听了这个故事以后很为他捏了把汗。
参考解决方案——
时间估算是个有力的工具。在项目初期可能估算的差浮很大，但是在每个“里程碑”的阶段以后再次作出的时间估算将更准确一些。直至最项目完成时，时间估算将趋于精准。这给予我们的启示是——
1：项目初期，不要把时间期限限定死了，而是应该在一个范围内。“对不起，在没有作出充分评估和分析之前，我不能回答你准确的完成日期，但是初步估算，这个项目需要1个月到3个月之间。最有可能完成的时间是2个月”。这样的回答将是比较好的。很可能上面会被你的“3个月”这个上限吓住，但是，当你的项目真实的是在2个月的时候完成的时候，那么最终你的评价将会更好。讲个小故事：我小时候就是喜欢吃糖果。特喜欢附近小店1块钱10个的那种硬糖，每次买一块钱的。每次去买时，如果是老板娘，她总喜欢，抓一小把先放到我手里（大约5个），然后再一个一个地加到10个。而老板的话，他却喜欢抓一大把放在我手里（大约15个），然后再一个一个地拿走，直到我手里还剩10个。不知道何故，我超喜欢老板娘，却恨死了老板。
2：每次进行到一个“里程碑”的工作之后都要重新进行时间估算，以提供更为准确的时间范围。同时也便于总结为什么上一个阶段花费了那么多的时间。
到底做成什么样子？作出时间估算的最基本的依据就是需求分析。到底要做成什么样子？到底在什么环境下使用？到底需要哪些功能？到底有多少页面？各个页面之间到底是如何跳转的，这个页面的是从什么地方进来的，又可以从什么地方出去？……有多少项目是在真正搞清楚这些需求后才开始的？还是更多的是——“差不多就是做成那个样子”，“先做着，一些功能反正以后可以再加”，“策划部说，现在能不能把这个功能也加进去？”……需求不明确就开始动工的危害我就不多说了，但是有个数据我还是要列举一下——“初期花费1个资源单位能够解决的雏形问题，如果发展到后期将需要2-10个资源单位来解决”。
参考解决方案——
如果真的时间很紧的话（毕竟对于软件或者网站来说，特别是商业软件或者商业网站来说，发布时间、抢占市场是第一位的），我认为像详细设计这样的东西的确可以精简一些，但是需求分析，画面迁移图这样的东西还是要求严格一些比较好。其实项目的初期，很多的人都是很闲的，一些东西完全可以先由比较空闲的人来完成，然后大家讨论然后定论一下来完成。这样不仅可以完成这些至关重要的东西，而且对于团队的热身和保持活力很有益处。不会出现“闲的时候闲死，忙的时候忙死”的现象。
注意，这些东西都需要文档，而不是口头上的决定。
坏苹果
因为就如同我面所提到的，上个项目经理把这个队伍带散了，整个人心都乱了，所以这个团队根本没有什么团体文化而言。甚至出现了“拿工资混日子”的“bad apple”。但是如果仅仅是“拿工资混日子”那样的话危害好像还不是很大，如果出现这样的“worse apple”的话，整个项目将危如累卵了——- 对自己的代码极为不负责任，垃圾代码过多，对自己的代码从来不进行测试，以程序跑通为最高准则。
- 从来不考虑代码的运行效率，用最简单的方法完成功能即可。
- 对于bug从来都是抵触，推托责任，甚至对自己的bug拒绝修正。
- 独立独行，不服从上级安排。
- 蛊惑人心，以尽可能的破坏团队文化为乐趣。
- 拒绝与上级配合，甚至与上级争吵。
- 更多危害项目开发的行为……
参考解决方案——
也许对坏苹果最快速和有效的解决方案是——开掉！但是那真的是最好的办法吗？有没有想过是什么土壤滋生了这些“坏苹果”？我就在我们的公司中发现了2个很不好的问题——
1：没有明确的奖励制度。就如同以前文革的时候吃“大锅饭”一样，干好干坏一个样，反正每个月就是那么多的工资。如果每个人真的都那么想的话，那么惰性就出来了。
2：只有不合理的惩罚措施，虽然技术中心还没有这样的措施，但是听说编辑那边，上传的文章如果出现了错别字是要扣钱的。我最反对的就是“扣钱”这样的措施。因为特别容易激起员工的“抵触情绪”。也许你会说，如果上班迟到不扣钱的话，那么大家都迟到要怎么办？其实，扣钱和奖钱是相对的。将本来应该给予的钱抽出一部分（当然下面的员工是不知道的）。然后做的好就在全额发下去，如果有违规就去掉一部分，然后将余下的发下去。就如同很多企业所谓的“全勤奖金”一样。没有什么深奥的东西，心理策略而已。
所以虽然“开掉”是最有效和快速的方法，但是如果很多滋生坏苹果的土壤不改善的话，再怎么开也没有用，坏苹果还是会一个接一个的冒出来。建立良好的团队文化，合理的公司制度，一个积极向上的团队才是最根本的解决方案。
跟踪和反馈
在项目初期，项目还在掌控之中的时候这个做的还是比较好的，但是到了后期这些东西却没有被很好地执行和贯彻。给我印象比较深刻的是对bug的跟踪问题。到了后期，一些bug出现对应不明确，甚至出现bug没人修正的现象。bug的修正任务分配下去，下面却忘记修正，或者虽然修正了，但是修正不正确不全面。还有就是下面的人对修正的bug不进行测试，甚至连跑都不跑一下。出现这样的现象，后期程序员比较累，惰性比较大是一个方面，但是更多的是因为没有有效的跟踪和反馈机制造成的。
参考解决方案——
刚进公司的时候，赵问我“你们公司PL （Programmer Leader）是怎样一个职位？都做些什么？”。我说，“其实PL就是PM到PG的桥梁”。也许那时候还没有那么深刻的体会到所说的这个比喻，但是现在似乎有更深刻的理解了。这次项目，到后期，赵（PM）几乎可以说忙的没有办法了，所以像bug跟踪和反馈这样的问题也只能放下了。但是PM不管，那让谁了管呀。其实这样的事情就是应该PL来做的。PL去走整个完整的bug修正工作流，然后对PM汇报即可。什么bug，修正了没有，修正好了没有，有没有测试，有没有引起其它的新的问题，有没有反馈给测试部。这些详细的工作流都是应该让PL来跟踪的。PL走完这个工作流以后，然后向PM汇报就可以了。这样PM也可以在总体上进行跟踪。上个项目，有一个人没有被充分的利用，那个人就是——我。我是负责页面样式和web标准的。这些东西在初期是最忙的，但是到了后期别人最忙的时候，我却是最清闲的。不过是偶尔修正一下页面上的反馈问题罢了。其实这个时候，我应该充当起PL的这个角色，把赵在初期做的一些过于细节性的东西（例如一些跟踪和反馈的工作流）接过来做。而PM这个时候去专注于更紧急和更重要的事情上去。因为刚进公司，所以，上个项目我完全是一个new comer。所以很多的事情，我都在尽量的保持低调。以免给别人留下过于突进和浮躁的印象。所以，到后期，看到别人很忙，而我却很轻松的时候，我有些不安。所以在下个项目中，我将尽量的主动的去承担一些我能够胜任的工作。以在一定程度上减轻赵的负担。
代码review太浪费时间？
这次项目算是吃够了代码质量低下的苦头。到了后期甚至出现很多代码需要赵重新来写一遍的情况。出现这种情况的代价是巨大的。部分模块所编写的代码完全推掉重写，毫无疑问这些所花费的资源都就将被浪费。到了项目后期项目最紧的时候，PM却在写代码！PM的精力也是有限的，他的时间也是有限的，如果他在写代码，那么是谁在进行项目管理呢？更重要的是他让人们感觉整个项目漏洞百出，从心理上打击整个团队。在项目初期，特别是项目时间估算过短的话，代码review好像的确很浪费时间的样子，但是“bug发现的越早，修正的越早，所付出的代价越小”这句话绝对是真理。参考解决方案 ——
提高代码质量，重视项目品质，绝对是项目管理中的重中之重。而提高代码质量和项目品质的比较有效的方式就是代码review手段。严格的、统一的代码我感觉比“散落的”、“个性的”代码拥有更好的可读性和维护性。还有我感觉代码review对于新人的进步和编码的习性上有很好的指导意义。很多企业对新人培训很头疼，其实我觉得最好的就是方法就是review他写的代码，在他还没有养成坏习惯的时候，给予制止和指导。
版本控制
版本控制如果失败，真的会如我在《《播客》项目总结——web标准页面设计方面》所说的，轻则令人抓狂，重则吐血身亡。这次项目在部署的时候就出现一些值得深思的现象——当部署的时候，执行的存储过程竟然不是最新版本的问题。结果导致最终部署的时候花费了大量的时间和精力用于调式和查错。同样是因为版本控制的问题，项目后期竟然出现了几乎将线上的真实运行环境当作测试环境的严重问题。想想，如果，以后真的访问量很大的时候，用户点点就出现“黄屏”的情况，那将是多么严重的事情。
参考解决方案 ——
其实版本控制的软件大家都有，而且都大同小异，为什么别人的版本控制成功，而我们的版本控制那么混乱？其实根本的原因不再源码控制软件或者说版本控制软件上，而是工作流程和工作态度的问题。很多的时候为了图个方便就不按照严格的工作流程来走，结果到最后工作流程形同虚设。自然会出现那样或者这样的问题。版本的控制问题只是这些坏的工作习惯的诸多恶果中的一个罢了。
后记：
写着写着突然感觉有点乱了，感觉到处都是问题，又到处都是已经上面讲过的问题。所有的大大小小的问题搅浑在一起，让我感觉眼前一篇浑沌。其实，这些问题就如果程序跑不通过时的提示错误，几百个，甚至几千个，其实都是由那几段核心代码的错误造成的，你会发现，如果修正了那几段核心代码后，那成百上千个的错误提示都会随之消失。就如同项目管理上的，如果真的建立起一个健康向上的团队，所有的看起来浑沌一片的问题也都随之消失了。
前面的文章中其实也只是列举了部分的问题，所谓的参考解决方案更是井底之蛙所见，各位看官看看也便罢了。
相关文章链接：《播客》项目总结——web标准页面设计方面
keyword:软件项目总结,软件开发项目总结,项目管理工作总结,项目管理总结,软件项目总结报告,工程项目管理总结,软件测试项目总结,软件项目总结范文,软件项目管理,软件项目管理案例,软件项目管理经验总结
