简述
近年来，机缘巧合之下接触了不少toG类项目。项目上颇多事情，令人疑惑频频。然而屡次沟通，却都不了了之，长此以往，心力愈发交瘁，终究心灰意冷，再无劝谏之心。
令人困惑的项目经理
孟子说天时不如地利，地利不如人和。而项目上遇到的很多事情，天时、地利终为少数，多数在人和。
立项开工，项目经理自然是项目上的第一把手。既为第一把手，自要有调兵遣将，排兵布阵的能耐。
当然用我们业内的话来说，可分为下面几类：
第一等的自然是懂业务又懂技术，这样的项目经理可运筹帷幄之中，决胜千里之外，当然这般的项目经理可遇而不可求。
这第二等的懂业务不懂技术，或者懂技术不懂业务，这样的项目经理，辅以数名参将，只要不瞎指挥，也可稳扎稳打，有功无过。
第三等的项目经理，业务与技术皆是不懂，如这般的项目经理，若尽职尽责，配先锋、军师、参将、辎重，最好再辅之以亲信，也可功成身退。若其是领导亲信，那更可说是有惊无险了。
而这第四等的，业务与技术不懂也就罢了，既无调兵遣将之才，又无同甘共苦之心，更是贻误战机，上下推诿。若其独断专横，那便是孔明在世也捧不起来。
有这般一个项目，公司未设需求经理，常以项目经理沟通需求。工期八月，立项后，多次催促，却不与甲方沟通，以至硬生生拖了两月之后才去。然而不通业务，不明技术。甲方被生耗两个月才沟通需求，这样的情况下，如何能顺利进行，以至于项目返工现象，比比皆是。多次提及需求管理，亦是左耳进右耳出。类类数落问题，甲方、研发、产品都有问题，独独他自身若皎皎之明月，灿灿之莲花。然而纵是项目成员承星履草，夜以继日，交付一版之后。举目皆是项目经理之间的恭维之词。
我有很多朋友是优秀的项目经理。言必行，行必果。沟通起来非常愉悦。偶尔遇到一个这样的人，确实让我大开眼界。
其实我也想过，这并非是项目经理职位的问题，实在是个别人自身的问题，这样的人，在任何岗位都是令人恼火的。
技术人员的无力感
我们互联网从业者经常听到一个词，技术债。技术债是令人难受的，尤其是在做项目的时候。做产品，我们可以制定完善的迭代周期，而项目，当需求都无法把控的时候，那么就意味着一切都是可变的。
糟糕的事情是，我遇到了这样的项目。前期无法明确的需求，项目期间，子虚乌有的需求管理，项目中不断的需求变更，deadline的不断临近，最终造就了代码的无法维护。
我从未想过，在同一个紧迫的时间阶段，让研发进行需求研发、bug修复、代码解耦，仿佛每一件事情都很重要。当然，我更建议提桶跑路，这样的项目管理，完全是忽视客观现实的主观意识。
前端规范难落地
公司是有前端规范的，然而前端规范的落地却很糟糕。如果使用TS，那么对于诸多时间紧，任务重，且只有一名前端开发人员的项目来说，显得太过冗余了。所以依旧使用js，那么代码中单个性化不会少见。使用esLint怎么样呢？这当然很棒，直到你发现大部分成员直接将esLint的检查注释了。或许还可以依靠团队内不断的宣讲与code Review，这是个好主意，然而你会发现，公司的code Review也是那么形式化的过程。
或许对一些企业来说，代码的规范性不重要，所谓的技术类的东西都显得没那么重要。只有政府将钱塞到它的口袋里这件事，很重要。
崩盘的时间管理
那么，因为各方面的原因，项目不可避免的走向了失控。时间管理的崩溃，项目自然开始了不断的延期。在私下里，一些擅长酒桌文化的甲方与项目经理，开始了酒桌上的攀谈，推杯换盏之间，开始了走形式的探讨。灯红酒绿之间，公司又开始了例行的恭维。
当然，我依旧无法理解，即使管理的如此糟糕，只要在酒桌上称兄道弟，那便什么问题都没有了？若是如此，项目经理面试的第一道题，一定是酒量如何了。