一 定好的计划有时会被突如其来的事情所打扰，打破原有计划，可能会演变为不按计划进行，临时有事临时解决。懒的按计划行事，每天撞钟
解决办法：所有事情都会有时间限制的，不会任由人无限期完成。对每件事都留有一定的缓冲时间，将期限定为一个阶段，而不是一个固定的死值，对于有经验的人来说，会提前预见到某个阶段会发生的时间，也比较好定计划的完成时间，比如对财务软件来说，年尾会为年结峰期，应该为此事设定恰当的计划时间。定合理的时间计划，既不会因催促完成而影响质量，也不会因过于悠闲而变的散漫
二 开发团队每个人单打独斗，不清楚自己同事的开发情况。
解决办法：
每个人的技术水平都参次不齐的，每个人对自己代码的负责认真性也都是不一样的，所以要想提高稳定性，必须专门从队伍中找一个人，他作为公共代码开发员。每个产品或项目的修改需求，必须首先经过他的思考，能做成公共代码，能封装成函数，由他来做
三 客户需求不合理：比如：我不会用鼠标，你给我做一个语音输入吧。我们还想要一个类似QQ的东西供我们内部沟通，你们给我们做一个吧
解决办法：
1） 客户业务部门不能随便提需求。必须集中汇总到客户IT部门，由客户IT部门汇总过滤完，再集中报给软件公司（但一般乙方没IT部门）
2）客户IT部门的需求，必须客户方负责IT项目的老板签字才能生效，才能报给软件公司（项目经理负责）
3） 不能随时报，每3个月集中报一次（那估计得急死）
4） 不能口头报（即使在现场实施支持也不行），不能电话报，只能MAIL或传真来报（电话报不好评估工作量）
5） 必须按我们规定的格式报，要严格写清楚需要实现的功能的界面，输入数据或输出数据，输入输出数据的格式要求，谁操作，多长时间操作一次。（这个很有必要，但一般客户做不来，还是得项目经理来做）
6）软件上线后只能免费修改3次。以后再有需求，就必须另签合同另收费，否则不予修改。（拉倒吧，岂止三次）
四 研发的产品别的部门不会用
解决办法：需要一个文案人员（其实写文案和培训的人应该由最牛逼的人做），写帮助说明，制作操作视频，制作学习版数据库，参与辅助测试（这个很重要，否则文案人员不熟知产品，无法写出有质量的文案）。有了这些文案的基础，最熟悉产品的非开发人员就有了两个岗位：测试兼技术支持，那么文案就兼起培训工作（由于他自己写文案自己用自己的文案做培训，在培训中会有各种提问，会更加增进他对文案和产品的理解，能写出更好的文案。而且他不是开发人员，他能站在使用者的角度上来写来讲，而且他属于开发部门，他会给产品开发带来更多更好的产品易用性建议
五 离职率高导致业务，技术断档
解决办法：
1 )向潜在的员工提供比较现实的工作信息，包括待遇、工作环境、条件等，确保员工形成适当的预期
2）员工不离职是不大可能的，但理想的阶梯团队是有必要的
领导的风格
3）给予新员工更多的关心，在很大程度上，新员工对直接上级的感知就是对公司的感知。需要该部门的负责人接受如何做好管理者等方面的培训，通过学习来改变自己的领导方式
4)合理的报酬 ，绩效（每三个月），与职称（成就感）
