从大的方面来说，公司的人事结构里也许本身就存在混乱的问题，就导致项目实施过程中负责人不明确。也有的公司文化单调，人际关系单薄，团队工作时就常常出现信息传达不及时不同步，甚至不完整。
互联网公司尤其讲究团队协作，一个项目通常不可能由一个全能的人完成，也是因为这样的人实在不多。因此，项目中出现的问题大多是团队沟通问题，并非技术问题。在我的经验中，团队沟通问题五花八门，代价颇高，如果想要一个项目能够顺利完成而又至于太费神费力，那么解决沟通问题就很有必要。
首先，如果一个公司不是太有钱而且愿意给员工支付较高工资的话，员工们的工作积极性和责任感一般是十分平淡的，每个人都只做自己分内的事情，而且尽量利用各种机会和理由把自己分内的事情压缩到最少。我们也就不能保证员工不会因为懒惰而把事情搞糟。他们常常都不把自己的分内的工作做到位，更不用说帮助别人做好工作，保证项目的顺利进行。由于他们的消极应对，很多别人的工作效率和质量会因为需要承前启后而大打折扣。
其次，项目经理如果意识到沟通顺畅在项目中的重要性的话，他会应该定期或者不定期地组织不同部门项目相关人员的沟通会议，以确保每个人了解工作进展情况，出现的问题，需要注意的东西和努力的方向。我认为这一点至关重要，因为不同部门需要合作的相关人员常常会因为各种个人原因而使工作得不到及时有效的沟通和问题反馈，所以由项目经理主导的把握全局的沟通会议就十分具有意义。
再者，需求的问题就多了。有时，需求不明确，常常需要产品经理或者UE/UI人员揣测，有时不得不咨询各个部门相关人员。就我的经验来说，由于提出需求的人在美国，时差正好12个小时，中国白天，他们晚上，沟通的不便常常需要我去花费很多精力去做本应该已经由别人做好的工作。
有时，需求太明确。明确到不只要求了业务的需求，还要求了产品设计相关的细节，即市场人员提供了一个文档：既包含市场需求文档内容，还包含产品需求文档内容。准确的说这是越了产品经理的权，但这种事情因为缺少明确的要求，所以还是会出现。还有些时候，需求不正确。因为在业务层，所以通常只有项目经理或更高层领导才能发现问题，而一般都在项目完成后或进行了很长时间才发现。所以就影响了项目进度，浪费了人力物力。
而产品经理，则往往事无巨细，方方面面都被扯入，是项目中最忙最累的人。业界有句戏言：“产品经理是条狗”，并非毫无道理。只是其实有许多关于业务需求的产品功能并不由产品经理来决定，有许多产品之外的问题也不该由产品经理来解决，但现状则不是应该的这样。
至于设计与开发，它们的工作十分密切，问题也比较多。在没有错的基础上，由于设计的工作具有主观的特点，开发会认为设计不够好，干涉设计的工作。同样，开发还会认为设计太好，不愿意去实现这些更高级的功能，因为本可以由更简单的，快捷的方法去实现，但由于通常这些在设计看来都是十分丑陋或者体验差的做法，所以争执在所难免。事实上开发只应该有质疑设计功能逻辑上正确与否的权利，并不应该主观地“认为”设计怎么样，因为这是设计的工作，为了整体项目工作的完成，在设计通过审核并提交后，开发应该按照设计按时按量完成。
最后，项目安排本身也会出现问题。有时由于某些原因，项目在一段时间内会集中出现，多个项目的重叠就要求工作人员被迫提高工作效率，但团队工作效率在重压之下并不总是能良性的提高，结果常常是以降低产品质量为代价来实现项目的及时完成。这就导致开发出的产品bug多，体验差，后续长期的维护和优化工作又沉重的展开，每个人都疲惫不堪，叫苦连天，如此恶性循环。因此，项目经理应分析团队人员配置情况， 估计项目周期和工作负荷，合理安排项目分配和进度计划。
团队工作中，永远不可能一帆风顺，项目的问题总是层出不穷，但只要机器的智能还没有超越和取代我们的工作，那么我们就必须解决这些问题，当然只要问题是明确的，解决方法也就是明确的。
