笔者从两年前进入公司开始，参与一个软件系统从立项、调研、启动、开发、暂停的全过程。说是暂停，实际上在可预见的未来，该项目都将被封存，这是一次失败的尝试。在立项启动以后，该项目开发进度缓慢，最主要的是，目标不明确，而且变现难度极大。
在项目进度后期，大概项目喊停的半年前，笔者以及身边同事在心态和信心上，已经不如项目启动时积极和充足，而且领导和公司在员工激励上也差强人意，因此，笔者认为，有必要及时调整航向，或者，充分分析业界需求和公司定位，及时决策项目存续，最大程度避免无谓消耗，最快速度推动项目实现正向反馈。在接下来的半年里，一是主要领导被安排作为救火队长参与一个延期的重要商业项目，在推动本项目上心有余而力不足，二来笔者级别相对较低，在工作安排上很难推动项目快速迭代，只能在做好自己本职工作同时，有意识推动其他人工作向前推进。
基于以上，笔者记录在一个失败项目中的经历、得失与思考，正所谓“吃一堑，长一智”，希望在后续职业生涯中避免重蹈覆辙。当然，基于保密的要求，笔者将尽可能的不涉及项目内容。
计划与行动 Plan & Action
作为项目成员，事实上的架构设计人员，最大的感触就是计划和行动的不匹配。再好的计划，如果没有强有力的行动配合，那最终的结果也只有泡汤。
项目期间，存在两种典型的计划与行动不匹配的情况：一是未经完备的思考和周详的设计，就立刻开展行动，结果是在大多数情况下，行动失败，或者遇到意想不到的问题，导致项目进展缓慢；二是项目计划完备，但是开发人员迟迟不能依照设计，快速解决行动中的问题，完成项目需求。这两种情况，深深伤害了项目的健康程度。因此，笔者认为，一个高效的团队，应该具备两方面的人才：给出比较完善计划的架构师，和强有力的行动派，二者互相配合，才能在有了方案之后，快速验证，如果遇到问题或者方案受阻，也能及时调整方案。
因此，如果一个团队，没有架构方面的核心人才，即使大家再努力，也是无头的苍蝇，多半的尝试都是失败的，最终也很难得到想要的结果，这就是方向比努力重要的案例。
主要矛盾
大家都或多或少知道主要矛盾，次要矛盾的含义，但是真正践行起来就很难做到了。在笔者项目中，经常遇到一些问题，工程师总是在解决问题的周边徘徊，而不能在主要矛盾上快速推进和解决，最终导致目标功能进展缓慢，殊不知，这些边缘的问题都是锦上添花。
最主要的，在面对整个项目时，在人力资源有限的情况下，是每人负责一块做到大而全还是多个人抓住一个关键点持续进攻，直到项目稳健到一定程度，然后再增加更多功能？笔者从事的项目在事实上选择了前者，笔者认为，这是项目戛然而止之时仍然不能够达到预期的性能指标的关键原因。
抓住关键功能，从 IO 路径上上做到既优且好，然后再做附加功能，这样反而能更快达到目标。
另外值得一提的是，对于多数工程开发人员来讲，正所谓“工欲善其事必先利其器”，好的编辑编译工具是必要的，但也不是绝对的，一味的追求编辑器插件的丰富功能，是舍本逐末。笔者项目工程中就有工程师总是把编辑器配置的花里胡哨，看似能够帮助开发人员规避很多问题，但是实际上，导致其过于依赖编辑器，求助笔者帮忙调试过好几个并不复杂但是很隐蔽的问题。
主观能动性
就笔者项目组的人而言，有人总能充分发挥主观能动性，积极解决问题，推动当前的关键任务向前走，不管该任务事实上的责任归属。同时，也有人打一鞭子走一步，认为只有自己手头的事情和自己有关系，其他模块的问题与自己无关而拒绝主动参与解决。两种截然不同的方式，自然带来迥异的结果。笔者认为，本项目中，第二种人太多，第一种人太少。
理想中的团队，大家都不应该以邻为壑，而是主动积极参与任务和问题的进程中，贡献自己的才智，以期共同向前迈进。如何能达到“独行者快，众行者远”，而不是“众行者慢”，这就是及时补齐组里的“短木板”，同时不能推卸责任，形成“首要的是解决问题，而不是解决和责备产生问题的人”的良好氛围，这样才能激发组里更多人的主观能动性。
学习与成长
在任何团队和组织中，大家的水平必然存在层次不齐的情况，在日常的工作中，也必然分工不同，如何在最大程度上保持团队共同成长，尽最大可能地保证团队在同一水平线上？那就是推动形成学习型组织氛围。在领到压力下要求分享，必然不能达到很好的效果，笔者的经验和建议就是，在工作时间，建立定期分享的模式，分享内容可以是近期解决的问题，或者新的技术趋势，或者项目中的某个算法，某个工具等，不一而足，学无定法，关键在于定期养成习惯，分享促进深入。假以时日，团队必然可以共同成长。
以上也只是笔者对项目并不成熟的得失总结，希望在接下来的工作和项目实践中，能够趋利避害，从项目和身边人身上不断学习，不断成长。