下面是从文章中摘录的30条：

　　资源和产品质量

　　◆　你是否确认已经明确了需求?

　　◆　你是否有一个经过核算的预算?

　　◆　你是否有一个被认可的路线图?

　　◆　你是否有一个被认可的进度?

　　◆　你是否能够准时交付产品?

　　◆　你的人手是否足够?

　　◆　你的团队是否有能力处理变更?

　　◆　你是否能够使团队保持注意力，抵制变更?

　　◆　对于发布的产品，你的客户是否遇到了很多质量问题?

　　◆　你的团队是否对工作的好坏有一个评价体系，并找出改进办法?

　　沟通

　　◆　你的团队是否了解公司的策略?

　　◆　你的团队是否了解工程的路线图?

　　◆　你的团队是否了解为什么根据路线图能够达到公司的目标?

　　◆　你是否很好得使用了例会和email的沟通手段?

　　◆　团队成员是否会及时的告诉你那些坏消息?

　　◆　你是否从你的团队那里听到关于自己团队的事情，而不是从其他地方?

　　◆　你的团队成员之间，团队和公司的其他部门之间是否能够很好的沟通?

　　◆　你是否会在老板来询问你之前提供他(她)所想要的信息?

　　◆　公司里的其他人是否知道你的团队在作些什么?

　　◆　你的沟通是否采用了正确的方式?

　　授权

　　◆　你的团队是通过开发还是购买来保持进度?

　　◆　你是否避免“微管理”?

　　◆　你是否可以把任务委派下去，并且是其不受干扰的进行?

　　◆　你是否使团队中的每个人都清楚他们的义务?

　　◆　你是否给团队成员提供了表现他(她)领导才能的机会?

　　◆　你的团队在争论的时候是否能够意识到事情的紧迫?

　　◆　你是否让每个人明确了自己的角色和职责?

　　◆　团队成员在周末可以回家之前是否都明白自己在本周所应达成的目标?

　　◆　是否每个人都清楚“责任”和“微管理”之间的区别?

　　◆　团队成员对自己的团队是否认可。

　　“微管理”的几个表现：

　　◆　推翻以前自己已经认可的观点，然后不断询问现在的状况。

　　◆　当错过了交付日期的时候勃然大怒。

　　◆　不断的改变任务分配。

　　◆　口头表述传达的，而不是明确的需求。

　　上面都是从管理者的角度说明项目中管理者应当明确的事情，现在变换角度，来看看从程序员的角度，应该问自己些什么。

　　质量

　　◆　你是否确认自己已经明确了需求?

　　◆　你是否有一个被认可的进度?

　　◆　你是否能够准时交付产品?

　　◆　你的设计和代码是否有能力处理变更?

　　◆　对于发布的产品，你所负责的模块是否出现了很多质量问题?

　　◆　你对自己的工作的好坏是否有一个评价体系，并找出改进办法?

　　沟通

　　◆　你是否了解公司的策略?

　　◆　你是否了解项目的路线图?

　　◆　你是否了解为什么根据路线图能够达到公司的目标?

　　◆　你是否很好得利用了例会和email的沟通手段?

　　◆　你是否会及时告诉管理者那些坏消息?

　　◆　你和团队成员之间，和公司的其他部门的同事之间是否能够很好地沟通?

　　◆　你是否会在管理者来询问你之前提供他(她)所想要的信息?

　　◆　团队里其他人是否知道你在作些什么?

　　◆　你的沟通是否采用了正确的方式?

　　执行

　　◆　你是否拒绝“微管理”?

　　◆　管理者是否可以把任务委派给你，并且你可以独立，保证质量地完成?

　　◆　你是否清楚在团队中的自己的义务?

　　◆　你是否表现出了自己的领导才能?

　　◆　你在争论的时候是否能够意识到事情的紧迫性?

　　◆　你是否明确自己的角色和职责?

　　◆　在每天回家之前你是否都确定已经完成了应达成的目标?

　　◆　团队成员对自己是否认可。

　　对于团队来说，项目的失败是每个人的失败，试图把责任都推到某一方或某个人头上只会让你下次再犯同样的错误，同样是对自己的错误找借口，在困难面前的逃避。在工作中不断提醒自己，反问自己：“你作到了么?”。在困难面前的，反思，总结，坚持，工作中以一种平稳，积极的状态取对待每个人，每件事，最后项目的成功也是每个人的成功，这时管理者和开发者获得双赢。