说实在，工作还不够两年，业内业余也接触不少项目，基本来说，没有一个非常出色、非常成功的。

业内来说，目前在某企业做外包，工作完全不着调，时而闲得无聊，时而忙得连接杯水的时间都要挤空。回忆两年前公司说只是交付一个两个月的项目，才发现自己已经陷得太深。

业余接触，其实也算不上接触，朋友找帮忙、公司除外包外的项目等，虽然不多，但也令人很纠结。

经过这近两年的经验积累得出，所谓烂项目，无非是因为需求不明确、技术不成熟、领导无方甚至客户不明确，就像目前外包项目所属内部业务部门，职能其实不见得有多重要，却还有源源不断的需求、业余，而做出来的东西往往需要很久时间打磨才能派上用场，这个打磨的过程又是多个短暂的周期拼合，所以，累积的只能是千疮百孔的烂程序，故而，烂程序+烂程序=烂项目。

下面无针对性的聊一下个人见解。

先说说需求不明确，见过很多次，项目拿到手，就是一句，没有需求，先做出来，有人用了才会有意见、有需求，这完全是产品型的做法，却发生在企业内部应用上。只能证明一点，内部部门竞争激烈，争先恐后漏风头，说白了就是瞎折腾，腐败的企业架构造就了一批以瞎折腾为荣的”领导”。更有甚者，需求传递丢失甚至变味，中间传递人不经确认就定方案，最终导致方案大改（其实也不算方案吧，毕竟都是一群臭皮匠，凑在一起侃大山式的拼凑出来的）。

技术不得不说，实际上就是，很多开发人员凑在一起搞实验，实验次数多的就比较牛逼，少的又很不服气，一起比想法、比能力。最终谁看别人都是烂代码（层次相差不远的情况下），心中又怒不可言，只能导致最终项目质量参差不齐，这也印证了所谓的质量管理工具存在的意义。而事实，除我见过银行做此类管控比较严格，像鄙人目前所在企业的做法大多是敷衍、后期补填……

其实最重要还是领导无方，甚至无能，有时候领导有能力也用不对地方，举个例子，一个估算人力二百多人天的项目，蹒跚学步的代入人家模式做敏捷，要一周出版本，却不知道拆分，大企业的弊病就在于此，一层层的所谓领导分配下来完全是瞎分，尤其是人资外包的项目团队，遇到甲方员工就自命领导，不得不说，有些强人，但有些与项目技术层面不沾边的过来把控技术，真能让人抓狂。

回归话题，各种各样的问题，最终导致项目的失败、重构，苦的是程序员，费的难道不是公司的钱，如此以往，软件届真就此形成了恶性循环，除了大企业的重要部门，剩下的就只能是吃饭睡觉打豆豆的节奏了？

以上内容纯属个人见解，请勿对号入座！