关于组织管理和项目管理的一些见解
1.团队的意义
没有具体负责的领域和事情，就不存在团队。反过来说，团队存在的意义就是为了负责处理某一个领域或一些具体的事情。
长久的团队一定有负责的领域，当这一块领域的事情出现后，自动就落在了这个团队上，负责的团队TL会主动把事情揽过来做。
短期的团队是为了解决某些临时特定的项目，当项目完成后，团队自动解散。例如一些矩阵式架构的临时项目组。
组建一个团队或者重组团队，最重要的就是职责的划分和明确。团队管理者需要知道哪些事情是自己的责任。
如果一个长期的团队一直都在接受各种各样，各个领域的临时任务，那么这个团队的状况一定会比较糟糕。
团队管理者在没有具体任务的时候就会无所事事，因为他没有负责的领域，也就不会做这个领域的准备工作，做训练，提高效率提高技能。当没有战事的时候也就不会像有阵地的队伍会去不断的做战前准备，挖壕沟。
2.对团队给出目标并信任团队的管理者
你若信我，我便不辜负。所谓用人不疑，疑人不用。如果信任存在问题，团队也就没有一往直前的勇气了。这个道理大家都懂，但是多数都做不好。
而给出明确的目标，是需要领导和团队达成一致的必要条件，并且这是前提。对团队管理者来说，要坚持没目标，不行动。
一只乱串瞎行动的团队，会让团队成员觉得很没劲。
领导给团队细节目标，不是一个好做法。我们对团队管理的时候，应该先和团队达成一致的项目目标，大家的目标一致了，再说后面的事情。
而直接给细节目标，可能会误导项目目标。大家对细节的理解不一样，倒推出的项目目标就不一致了。
3.领导对团队在任务过程中的监管
如果有精力，领导可以对团队在任务执行过程中进行监管。目标一致了，那么团队在做事情的过程当中，领导的视野更广，角度更多，更可以发现一些问题。
和团队管理者去沟通这些问题，不管是执行前，还是执行中，或者执行后。和团队管理者探讨自己觉得有问题的做法，讨论是不是偏离了项目目标。
如果领导自己没有精力或自己不能确定这样做是不是对的，那么参考2.a，信任自己的团队管理者。
领导自己不可能什么都懂，不可能有那么多精力，所以要减少瞎指挥，让自己的团队管理者能够成长。
4.目标管理
前面也一直在提目标，公司有战略目标，落实到团队是项目目标，然后拆解到个人是具体的任务目标或者行动目标。
有了目标，就需要有结果。目标很重要，结果也很重要，结果是不是符合目标的评价也就很重要。
领导给出项目目标后，需要去核对项目目标是不是完成（这里不是说做了就好，而是要看是不是达到了目标描述的效果）。
只有不断的去核对目标的完成情况，才能发现不足，才能改进。
如果一个目标给出后，不对结果做评价。那么长此以往，执行力会不断下降。
4.项目管理的方式
团队OK，有明确的职责。
团队管理者也OK，互相信任很努力，能力也过得去。
目标管理也OK，大家都知道目标在哪里，一起在努力。
这个时候基本的管理已经没问题了，再要提高效率，就看项目内部的管理方式了。
我们知道做事情，有一种PDCA的方法。
P：做计划
当一个项目或一个任务来了，第一步就是做计划，计划是在把目标分解成具体的事项，并且有前后顺序，依赖关系。
比较顺的做事情，当然效率就高。事情有一搭没一搭的做，一会发现少了这个少了那个的，就容易忙中出乱，返工，效率低。
计划也不是越细越好，因为有很多行动计划的内容，是在做的过程当中变化产生和修改的。
这里也体现的是项目管理者的能力，能把事情想得清楚，计划就会比较靠谱，想不清楚可能就没计划了，或者计划只是做做样子，写完之后就不再看。
D：执行
任务的性质不同，执行过程中的方式也不同。
事务性的：去买包烟，准备一台服务器。这些事情一眼就能看到结果的会比较好处理。
创造性的：比如做一个产品，做一个系统。这里就涉及到软件工程的方法，要做很多的任务分解和分派。
涉及到需求调研，要做需求分析设计，要做系统的规划设计，数据库设计，概要设计，详细设计，编码，测试，联调，部署，维护。
互联网产品、软件产品、定制软件项目的做法都不一样。
需求明确和需求不明确的做法也不一样。
团队成员能力不同（例如有没有好的测试；有没有好的的设计能力的人），做法也不一样。
越是复杂的过程，越是要有一些规范流程，即使牺牲少量的灵活性。
越是复杂的过程，越是考验设计能力。
C：检查
事情做了，就要检查结果是不是符合预期目标。项目管理者要不断检查，不断检查，不断检查。
A：改进
如果发现了问题，就要改进。
改进会涉及到计划的改进，做事方式的改进，任务安排的改进。
并不是完全执行了最早的计划就是好的。