团队缺乏的不只是管理。做管理起码要能承担责任，这是最基本的素质。谁都害怕承担责任，我也是！我能否习惯敢于承担责任呢？能否习惯敢于承诺呢？承诺后我估计还有可能完成，不承诺，基本上没有完成的可能性。同样的道理，你的项目经理职位又没有让给别人做，你拿的经理级工资又没有分给别人，那项目失败了，你为什么要把责任推到别人头上呢？三人团队中的那个领导，不是要程咬金一样的牛人，而是要李离一样的死士。项目完成不了，切脑袋的事倒不必做，递交辞呈的那点勇气总是要有的。从管理的角度看，项目失败与否与项目经理的经验直接相关。项目的成功是由两个方面来评估的：项目完成质量；项目完成时间。皮之不存，毛将焉附。没有确定的组织机构，又如何能指望做出来的管理制度“合用”呢？在更加普遍的情况中，动摇了制度的人往往不是犯错的员工，而是管理者自己。如果在制度面前，既做得到“人性化”，又做得到“公平性”，那么当管理者的便可以多做几次黑脸的包龙图，而脖子上的脑袋便可以比李离顶得长久一些。现在，有了会“比较快速地”编程的愚公，而且有了公司，我们完成了组织机构建设，我们还找到一名（或好多名）项目经理，他们一不怕死，二不怕苦，更为可喜的是我们还有了开发部：对内，我们订了一套规章制度；对外，我们还拿到了单子。“那我们就开始开发吧”。如果非要精简到两个角色的团队模式，那么在这种情况下，通常是开发经理兼任项目经理。因此这位开发经理一定要能清楚地区分这种双重角色的身份：在任何时候，明确自己是在进行“团队内协作”，还是“团队管理（和组织）”，还是在与“团队外交流”。更好的选择是明确分工，而不是弹性分工。你应该明白，重要角色的更替通常极具风险的，如果所有人都在思考“什么是增值税发票”，那么你的组织结构将立刻溃散。因此，明确分工是你的管理职责。做管理不等于做伯乐。
沟通的三层障碍。沟通的第一层障碍，并不在于你要表达的内容，而在于你如何表达。这种情况下，你需要“组织语言、学会说话”。沟通的第二层障碍出现在跟聪明人的讨论中，让人觉得“不知所为”。这种情况下，你应当预设前提，并尽早阐述结论。第三层障碍的主要表现是：不知缓急。解决之道，则是不要把沟通目标设定为“让对方认同”。应该清楚的是，保障每一次沟通的有效性都是最重要的事。沟通不是打电话或者请客户吃饭那么简单的事。你得到的每一次沟通机会，都是向客户了解更深层次的需求的机会，因此最好在见到客户之前，你就已经设计了所有的问题和提问方式。使用与不使用UML，其根本的问题在于沟通方式的选择。只要是行之有效的、能在各个项目角色间通用的，就是好的沟通方式。