序

    一件事能不能做成，和你有什么关系？靠的是你的努力吗？还是说靠的只是一个运气？

    就像买彩票一样，你觉得中奖和个人努力有没有关系；就像和高考一样，你觉得考上北大清华和个人努力有没有关系？

项目管理之管人

    有个朋友说，如果想做成一件事，不得罪人是不可能的，每个人如果都想做好人，那这件事就不用做了。

    项目管理的目标是什么？是按时按质按量的交付产品，在限定的资源限定的成本限定的时间下进行交付。如果大家没有这个统一的目标，事情的进度将远远落后于制定的目标。

    A 在上文中，我们提到了开发者的三个缺点，一个是进度延误，承诺的功能无法按时上线；一个是bug修复的时间长，每次都不能在短时间进行修复；一个是极强的表演能力，甩锅能力一流。

看起来这些问题都不是主观而有之，不是故意的拖延进度，那么我们如果去解决呢，首先找当事人沟通，到底是什么样的原因导致的。例如，承诺的功能无法上线，而为什么要承诺？你猜他的内心是怎么想的？年轻的开发者有野心表演是好事，想在所有人的面前表现一把，从而即可承诺，并且大大压缩时间，但是没有考虑到自己的能力是否达到了这个要求，其实也从侧面提醒我们自己，在没有完全的把握面前，不要随意承诺时间，要用最快的时间，写一个demo，写一个mvp程序来验证方案，然后才能正式的承诺时间，否则，个人信用就慢慢的变成了一张烂纸，打上了一个不靠谱的标签。

BUG的修复时间长，其实也是一样的，开发者的能力不足，导致在写代码的时候，很多关键的日志没有打印，从而导致无法查询问题产生的原因，只能进行复现，同一个BUG，修复了三次，每次都是加日志，这种代码质量只能说，又不是不能用？

个人甩锅能力和表演能力，其实这是人之共性，而造成这样的原因，也可能和过往的经历有关，也有可能是我帮他们培养成了这种特性，因为这个项目出现的所有的问题我抗，这个项目出现的故障我都来背，所以他们无法感受到那种风险和压力，导致代码质量失控。

碰到了这种开发者，你觉得是你的努力导致的吗？还是觉得是运气导致的？

这种事情碰到的多了，就在想，是不是要自己去写代码？时间和能力不允许，那是不是可以换人去写？无人可换，限定的资源。

那么就只能花费更多的时间在过程把控上，从而尽量确保结果是可以用的。首先，在任务分配的时候，讲清楚价值，背景，时间，功能，这个是为了让开发者理解我们为什么要做这个功能，然后再是讲述具体的实现方案，让开发者自己过一遍整体的逻辑，从而在脑海中，能大致形成一个代码的实现路径；然后代码提交测试后，尽量覆盖所有的场景，不断进行回归测试；最后，找一个经验比较足的大佬，进行代码指导，思路指导，保障开发的过程中出现问题能立即解决，例如，所有的操作全部加上日志，各种级别的日志，debug的，info的，应该告警的warn和error，监控图表的绘制。

做了那么多，你觉得可靠吗？不可靠，因为是一个表演者，从而需要评估风险，一个不能担当的开发者，那么产品就不能完全依赖这个组件，如果这个组件挂了，运维能做什么？如果这个组件出现问题，无法排查，运维能做什么？从而我们做了应急预案，如果出现BUG，直接卸载这个组件，手动进行系统组件的配置维护，其实我们就是做了两套方案，一套方案依赖组件的自动化，一套方案就是手动命令进行各种配置，去除依赖才是最好的依赖。。。又不是不能用？如何将低质量的代码造成的风险变得稍微可控一点，也就是去除依赖了。

其实如果时间没有那么紧张，我们可以培养这个开发者，而不是单纯的说换一个来解决问题。我想换个老婆，你觉得换一个老婆就能解决你当下的问题了么？并不能！！！

在进行处理和开发者的矛盾的时候，来回的回归测试的确让人很崩溃，但是要记住，不要扰乱了自己的心态，记住自己的目标，要确保这个事能按时按质按量的进行交付，否则出现问题都是自己的责任。

时时刻刻问问自己，我能做什么？我如何改变目前的困局？我还有什么办法来搞定这种事？

B 在上文我们提到了应用运维，主要负责业务迁移，那么就会和业务沟通，具体的配置，业务验证割接上线。

应用运维无法排期，说明他并不知道他自己需要做什么，到底怎么做，他很明确他的目标，但是他没有一个具体可实现的路径。我们能做的也是先去问问，到底是什么原因导致无法排期，例如说研发很忙，没办法配合，那么如果和研发说只要10分钟，能不能配合？那么如果是研发的老大说你去配合，那么他能不能配合？

应用运维，表面的积极，但是只想动嘴，不想动手，那么原因是什么？是因为怕抗风险，一切涉及到的生产都会有风险，那么我们是不是可以减少风险，提供迁移的步骤，详细说明，重要的关注点，回滚措施。还有一种就是，就是不想动，没有风险也要造出一些风险，那么我们是否能换个人来干？或者是我们自己来干？步骤能不能优化，提供简单而可靠的方式？

   应用运维在背后诋毁项目？其实当我知道这件事的时候，我啥都没做，一个项目有其存在的价值，好的产品应该是自己传播的，而不是靠区区几个人从而造成产品口碑的崩塌，但是最后其实也产生了一个困扰，例如有些研发不信任，要出具各种压测报告，需求承诺开发时间等，但是这也让项目更加正规。

应用运维的资源比较好找，从而。。。我想换个老婆，你怎么知道下个老婆行不行。。。不知道，开盲盒吧，没准行呢？？？

换了个老婆，感觉生活得到了新生，那是真的释放出强大的生命力，不用管，事情就全部做完了，真的是很爽，别人做了6个月没做完的事，他两周搞定。

换人其实是下下策，只有没有办法了，才会去做，因为代价太大，要总监报备，要重新培训，要重新沟通，要重新确定时间，不同的人会挑战项目价值，会挑战项目难度，会挑战你行不行。。。男人怎么能说不行？

换老婆的时候，你能说，劳资就要她，至死不渝？自己选的，跪着也要做完。。。切，当初你的前任老婆也是这么说的。。。

 C 上文我们也说过了，附属依赖的一些问题，看看这个怎么玩

    附属依赖，一般属于基础设施了，是强依赖，很难去除的依赖，听说你想换老婆，但是你老婆的背景很强，你是否有能力换？还是自己再去找个小妈妈？

理念之争，其实就很难了，每个人想法不同，很难统一，只能说达到共存，涉及到个人的包容和开放心，等有时间，或许可以去掉这种依赖。。。等？为什么要等。。。因为太忙了

当吃到的投诉太多，那就不是投诉了，可能也是一种赞美，可能也是对产品的诉求，但是无视的结果就是，如果碰到了不支持你项目的人，会造成致命打击，要很清楚的知道，哪些人会支持你的项目，尽量让更多的人支持你的项目。

魔法攻击，最容易搞心态，其实还是一句话，记住你的目标，你是来解决问题的，其他的都可以忽视的，重要的正轨是如何解决问题，其他的可以认为是娱乐。都是一群臭打工的，还学会了魔法攻击。。。哎哟，这个时候你不说换老婆啦。。。说一些话的时候，也反映了自己的心态喔，两种心态一种是强势，另外一种是假装弱势。

这种其实还是更多的从合作共荣的目标出发，将两个产品绑定，才能更好的发展，不然的话，依赖方要做的事情很多，例如换一个，代价会非常非常大，而且不一定有那么多的资源来做这个，可能是吃力不讨好。

疯言疯语

    碰到什么样的项目，碰到什么样的人，能做成什么样的事，你觉得靠的是你的努力吗？

    可能不止于努力，而更加取决于你的信念，如果你真想做成，那么就靠这个必须做完，无论是谁，都不能阻挡，其他的就是想如何解决问题，哪些资源我可以利用，有没有可以优化的地方，能不能更加可靠。

    会遇到不支持的，但是同样会遇到支持的，从而可以更加依赖支持的，从而做大做强，再创辉煌。没事干的时候，多反思一下自己，看看哪里还能做的更好。。。但是实际情况是，如果你还是根据原来的经验来，没有新的输入，其实这种反思，可能只是一种浪费时间。

    碰到了不如意的人，战况焦灼，你能在短时间内调动士气吗？然后一鼓作气拿下？

    有的风只能让落叶飞舞，有的风是龙卷风，不可抗拒。有的事情靠的是运气，有的事情靠的是人才。

    在一个项目中，你做了什么，带来了哪些改变？如果进度失控，质量失控，你能做出什么改变让一切在可控的范围内？没有一帆风顺的项目，不断解决问题才是常态。