大家好！许久不见，甚是想念。之前我写过Vue相关的技术文章，在决定写《Vue填坑指南》之前，我想先来一点非技术类干货。准备好啤酒和瓜子，我们开始了。
在我们常规的意识里，程序员的主要职责是coding，这没有问题。试想一下，当一个程序员既可以编码，又可以做一部分交付工作，是不是很酷。因为程序员如果去主动承担或者分担交付工作，首先是对自己代码的自信，这一定程度上为项目质量增加了一层保障。其次又有技术优势，加上程序员一贯给人的踏实稳重的形象，出招一定无往不利。那么这篇文章来谈一下，作为一个程序员，如何为DM做助攻，更好的完成项目交付。更多的，我也把他当成是自己的项目回顾和经验总结。
我们说项目成功，诚然，它不是我们做项目的唯一目标，但确实是我们要争取达到的一个理想结果。那如何定义项目成功？在我看来，代表成功的标准很多，但终究不能绕开的，唯“客户满意至上”。我们说的顺利结款、开展后续可能的合作、为我们介绍更大的客户，都建立在“满意”的基础上。验收交付，有的时候是可以运用技巧的，像下一盘棋，和客户过招，从而在这场运筹帷幄之中取得胜利。这看似很美，可是客户是不应该拿来被推到对立面，甚至作为我们的手下败将，来增强我们的功力与荣誉感的。而 “满意”是一种自发的感觉，是由提交的项目质量，感受到的服务态度，服务细节等多方面因素共同来决定的。在这场高手对决中，没有输家和赢家，互利共赢才是彼此的最高追求 。而在这一点上，程序员能创造出的价值，其实可以有很多。
当一个程序员，开始认同自己的职责，not only a programmer，but also a PM,QA, and even a DM.他就不仅仅需要对自己的代码质量负责，还要对客户满意负责，甚至能够去揣摩作为经理人，作为产品，作为运营等等不同角色客户的心理，找到他们的痛点，并提供帮助。然而很尴尬的是，往往一个码龄较短，或者对代码不敏感的程序员来说，做到对自己的代码负责有时候都有些困难。这是不是代表他就可以专心提升技术而不考虑其他呢？我认为不是的，技术是一个程序员甚至一家技术公司安身立命的基石，是一定要去做好的。其他的，都是在此基础上锦上添花的，我们当然不应该去拒绝锦上添花的东西。所以成为一名程序员，技术首先要过硬，然后我们再往下谈。
曾经做过这样一个固定价格的项目，项目周期很短，但是交付时间比较长。开发期间，我们少有机会和客户直接交流意见，很多产品中的决策，是由项目的后端和我（前端）共同探讨，画成原型或者思维导图，再去邮件询问DM的确认。这里就会形成一些理解偏差。很幸运，在欧洲同事的共同努力下，项目最后的交付是成功了，高兴也有点遗憾。我常常会想，我们做出的东西，真的是客户心里最想要的那一款吗？很多功能，客户在用户故事中轻描淡写一下，在代码实现需要考虑的很多，需求是唯心的，而逻辑是那么地唯物。当想法慢慢的复杂，会不会逐渐脱离产品最初的意向。当我们和客户的预期开始有差别的时候，也就开始埋下未来交付不会那么顺利的伏笔。这个时候，敏锐的程序员，应当及时发现，It might cause a problem，并主动争取和客户沟通的机会，如果想法有所偏离，要迅速从技术轨道，并入产品轨道。在出现端倪的最初，把风险降到最低。相比于每天都可以和客户交流的ODC项目，固定价格项目把握此点，尤为重要。然而固定价格项目，既要做好，又想盈利，如何合理划分PM，DM与程序员的职责，如何合理评估报价，又是一门学问。我在这一领域所知甚少，不敢班门弄斧，还希望能和有心得的同事一起交流。
上一段介绍了我对于程序员在开发阶段的助攻心得。在交付阶段，程序员一样可以贡献自己的力量。what if change your main role from a programmer to a DM who can also build nice code too? 因为这个时候，你扮演的更多的角色应该是一个DM，一个会编码会改bug的DM。以下是我能想到的，我们在这个阶段可以去做的：
- 时刻把握客户对于项目的满意度（基于事实）
- 在基于客户对现有项目满意度的基础上，考虑如何增加客户的满意度
- 让客户感受到你的服务态度和解决问题的能力
- 在与客户往来的邮件中，尽可能多的准备详实的资料，并用严谨的文字为DM做出总结
- 总结现有产品仍存在的不足之处（又不在本次开发合同内的），从技术角度提出解决方案，配合DM争取二期合作。
重点谈一下第二点，“增加客户满意度”，这个说法其实不怎么准确，因为我们仍然需要考虑项目成本。客户提的需求，总不能不计成本的全去实现，所以我们有时候要在客户的“预期”上做平衡，要高于他的预期，又不能让他的预期高于我们的成本。抛去外在的商务技巧，当项目到了交付阶段，我认为更多的是人与人之间的交往，建立在信任的基础上，而不是纯技术的范畴。尤其是面对公司规模并不太大的甲方。我们假定，在交付阶段，项目质量已经到达了客户能够接收的范围内（当提交的项目质量本身无法让客户接受，再多的努力都是徒劳）。这时候能提升客户满意度又不怎么费力的方法，我能想到的，有以下几点：
- 让客户感受到，你给他提供的，总是比他想到的多。
举个例子，当年我还在读书，给一个老师介绍的朋友做logo，本来就是学生的身份，logo的报价自然不会太高。然而我想的是，一个图本身没有多少价值，如果给客户一个logo全家福大礼包，这样会不会物超所值一点。于是我就附了详细的logo提案，介绍了思路和配色，将logo运用到一些vi形象设计中，又适当展示了我还可以做网站的能力。这并不怎么复杂，最终却报出了高于纯logo好几倍的价格，客户也欣然同意（报价时我的内心也是忐忑的）。当然事后我也会思考，客户想要的就是个logo，我做那么多，logo还是那个logo，报价却增加了。会不会有点不实诚。但我认为不是这样的，只要客户认同，愿意为你的作品付费，100元和1000元没有区别，都是价值。所以，做的比客户想到的多，让客户觉得你还能为他做很多，客户会觉得花的钱值。 - 先客户一步，想到他会问你什么，提前把答复准备好，或者直接以文档的形式提交。 这会比较累，你要想很多。但是常言道，不打无准备之仗。而且你主动告诉别人，总比别人来问你的好。
- 在态度上，多给客户明确的答复，而不是含糊不清，或者让客户觉得你很反复。答复要尽量完善，给到的截止时间不可以爽约。
- 自己先把诚信这根弦蹦起来，去信任客户，再去赢得客户的信任。
这一点我曾在上个项目中有很深的感触。还是那个欧洲的项目，当客户迟迟不肯痛快付款时，我产生了不信任客户的想法。当一个人不肯去相信合作的对方，当然会有戒备心，不肯拿出好的服务。这时候纪成跟我们说：“我们还是选择信任客户”。有时候啊，心态的转变就在一瞬间。当自己首先放下揣测和怀疑，先做好自己，别人的信任也会接踵而至了。 - 最后一点最重要，迅速跳出程序员思维和乙方思维，开启产品视角和客户视角。多去想客户现在在想什么，在困惑什么？他在想什么，就和他聊什么。他在困惑什么，就帮他解决什么。感情到位，一切好说。其实这本质上是从甲方乙方的雇佣关系，上升到基于信任的合作共赢，继而上升到基于人品和工作能力的相互认同。这一点，做到很难，维护下去更难，但我们要努力去做。
上面说了这么多个人看法，不一定都对，也有一些不成熟的地方。其实只要有一两句话能让大家有所认同，能应用到工作中并见到成效，我就会非常开心啦。最后，我总结一下，其实万变不离其宗，像是一个行走江路的侠客，身上带着一把倚天剑和一把屠龙刀，倚天剑上刻着“what can I do more for you”，屠龙刀上写着“how to solve this problem”，相信一个拥有如此武林秘笈的程序员一定可以在工作的江湖中所向披靡，那还等什么呢，助攻吧，程序员！