就像一位讲师所讲的那样，每个人去参加培训都是带着他自己的问题去的，因此我记录的笔记大多是针对目前我面临问题的。
微软进行设计的一个好的方法：假如一个十二人的小组，全部拉到外面，比如三位成员一组分为四组，每组针对问题进行设计再发表自己的看法；然后两两合并相近的设计，再进行讨论协调……直到最后大家同意通过。这样既可以发挥群体智慧，又充分调动了开发人员的积极性，由于是大家协调的结果，也比较容易实施。
微软的“三驾马车”——program manager、developer、tester。developer负责开发，tester负责测试，program manager只管事不管人，对developer和tester没有人事上的管理权，但是必须要推动整个项目流程。program manager分为两类，一类基本是由developer转换而来，常常负责设计，一类是process pm，类似传统意义上的项目经理，推动整个项目流程。program manager生成设计文档，developer根据文档做开发，tester根据文档做相应的测试，凡是和设计文档不一致的地方都当作是bug，在developer和tester之间出现的冲突和矛盾由program manager负责仲裁协调。微软流程设计的作用就是用法治来代替人治，微软把这种团队结构当成“三权分立”，项目经理是立法权，开发人员是执行权，测试人员是监督权，在开发流程的不同阶段不同的人起着主导作用。
在项目进度制定的评估上，先是项目经理进行总体评估，估计出大概的时间；然后由负责各个具体部分的开发人员估计各自每个功能需要的开发时间，并详细记录；各个开发组长、测试组长评估组员的开发时间，并进行协调汇总；项目经理评估从各个组长收集的时间和功能进度，并制定出进度表，设置里程碑。
微软开发团队的日常工作：开发人员上班第一件事是查看昨天Daily Build的结果，担心由于自己代码的check in而造成build broken。如果造成了build broken，则当天最紧急的任务就是修改代码，使之能通过build，因为每天的工作都是建立在昨天的build版本上的。如果没有出错，则开发人员接着打开bug管理工具，查看指定给自己的bug，解决高优先度的bug或新功能，在本机上build和单元测试，如果可以则请开发组同事做code review，再check in 代码，在bug管理工具中修改bug状态。开发人员以一封daily report结束一天的工作，包括修改了哪些bug或添加了哪些新功能，哪些问题没有解决等等。测试人员上班第一件事情是打开bug管理工具，看看指定给自己的bug，验证已解决的bug。接着测试人员从发布服务器上去的当天的build版本，根据测试用例检查当天的build，并在bug管理工具中登记新发现的bug，等待开发人员解决。下班前测试人员会发送当天或者一周的bug报告和测试用例报告。项目经理的工作是主持bug专家会诊，更新项目计划、日程表、产品规格书、风险控制列表，发送status report等等。
根据微软开发团队的日常工作，目前我们做的不足的地方有：daily build、unit test、code review以及daily report。在code review上，微软有三种方式，一种是peer to peer，互看代码；一种是group review，比如一个团队每个礼拜三下午抽出两个小时，一起通过幻灯片等方式浏览，另一种是从其他团队或请第三方公司来做code review。本来公司是有daily report的，不仅下班后需要提交一天的工作报告，原本我还规定上班后半个小时内需要提交一份当天的工作计划（模板固定），可惜是没有能够坚持下去，不少开发人员认为这是浪费时间，如果对于计划性很强的开发人员来说，这项工作的确是浪费时间，但是对于大部分计划性不强的开发人员，先把当天的计划写下来，便于提醒他当天需要完成哪些任务，不至于A事还没做完，又去做做B事，导致每样事情都完成一点点，却没有一样能够拿出手来。一位讲师一句话说的非常好，他说其实微软也没什么，无非在一些细节和执行上做的非常好，我对这个观点很赞同。其实上面的很多观点我们都知道，但是细节上的处理和能否坚持下去就成了我们和微软的区别。
PMO是project manager office（program manager office？），它的三类职责是识别和培养项目经理、为项目经理提供支持、管理项目经理。这对于国内大部分中小企业来说还是一个奢侈的机构。这个机构的出现主要是为了针对这类情况：一个公司里面同时进行了好多项目，某些项目经理有出色的技能，能够让项目顺利进行，但是某些项目经理还缺乏一定的技能，不能保证项目的顺利完成，因此就需要一个这样的机构来为项目经理进行支持和管理，也能从公司内部发掘出适合做项目经理的人才。要注意的是PMO是为了增加价值而不是增加负担，enough is enough，不要仅仅是为了一种形式而去做某样事情。
怎样才算一个好的项目经理？项目经理需要具体一系列的技能和应有的态度，技能是可以学的，但是态度很难教会。在优秀项目经理所具有的特征中，促进发展的能力是一个很重要的能力，而我在这一点上还有欠缺。每位经理都可以让事情开始，但是在碰到各种各样的困难后，如何还能推动项目往前进，去克服困难，这个我还需要提高。
微软在人员管理上是pay for performance，not pay for effect，这一点上我们公司的做法也是一致的。一些开发人员进公司后为了完成任务经常加班，看上去很努力很辛苦，可是事实上这是他应该做的，因为分配的任务如果给同级别其他人做肯定是工作时间内能解决的事情，由于自己能力方面的问题造成一些加班和辛苦，公司是没有什么补贴的，要不会提倡了一种上班时间拖沓，把要做的事情留到下班后去做，奖励努力而不重结果的文化。
微软有一种卓有成效的“师傅”制度。因为直接请教上级会让员工觉得不自在，担心什么地方做的不好会造成上级的坏印象，所以新员工进入公司后会分配一位师傅，新员工有任何问题都可以请教。员工进入公司工作一段时间后可以自愿申请成为“师傅”。师傅制度一来让员工快速上手和熟悉工作环境，二来可以培养“师傅”的领导和影响他人的能力，给工作增加心得挑战和活力，使之感觉受到重视，与众不同，有成就感。
唐骏先生在最后讲座上讲到了目前中国IT企业成功需要的一些条件：1.机会 2.成功的商业模式 3.关系。另外好几位讲师都提到了中国IT企业成功所需要的一条，就是制订标准。
最后简单分享一下唐骏先生讲的几个有意思的案例，由于实际上的案例比较长，这里只是简单写出来，希望大家也能领会这些举动背后的含义。
1.微软公司的以人为本。微软中国研究中心办公楼的电梯有问题，六部电梯中只要有一部准备降到底楼，其他的就不会回落到底楼，结果早上上班高峰时大家都在楼下等电梯。微软中国和物业协商无用，最后派几位打扫卫生的阿姨每天早上上班的时候呆在电梯里当电梯小姐，只要电梯上去了就将电梯按回到1层，已缓解高峰状态电梯紧张。
2.中秋基本所有公司都会给员工发月饼，但是微软中国与众不同的是只需要员工提供一个地址，公司会把月饼快递过去，这样员工就可以寄月饼回给父母等等。更不同的是，唐骏先生在月饼包装里夹了一张贺卡，其中汇报了今年微软中国取得的成就，感谢他（她）为微软中国培养了这么一位优秀的员工。
3.微软中国规定每若干时间要选一次优秀员工，每个部门只有几个指标能能选自己部门的人，其他都需要选其他部门员工，这样子最后优秀员工肯定是那些做人好，会帮助其他人的员工。然后微软中国规定所有的晋升者都必须是优秀员工，因为一个优秀的管理者必然要会做人，要善于帮助别人，这样由于晋升者必须是优秀员工，一方面可以帮助实现自己的利益，一方面就在公司内部倡导了一种互相帮助的企业文化，使各部门相互合作。