以下内容由本阿康真实经历改编，如有雷同，纯属巧合。
客户：我可能，好像，貌似，绝对，要做个网站。
阿康：嗯，可以作为我们承接流量的阵地。
客户：不过，时间有点紧！
于是乎…轰轰烈烈的网站搭建工作开始了。
阿康并不知道的是，等待他的是一个又一个难解的局和一次又一次的夜不归宿。
网站搭建的正常过程是这样的：阿康与客户谈来谈去，确认网站的所有需求。沟通设计师设计全部页面，沟通技术同事开发前后端，最后安装部署到客户服务器上就大功告成了。
很简单有没有！
But那是书面的流程，来看看残忍的现实吧。
死、局、七、连、杀
死局一、
阿康：网站页面这么多，设计要花一周，你们确认后，开发也要一周，部署测试要2天，10天真的来不及上线啊。
客户：那预算也没了。
阿康：等一下！
破局示例
阿康：全体听令，设计师开始设计网站主视觉，技术同事同步搭建后台功能。其后，设计师每完成一张页面设计就发客户。客户请当天邮件确认。技术同事每收到一张设计确认图即开始该页面的前端开发。三条线同步进行！
破局法则
多核多线程，设法沟通各方将非递进关系的工作，统筹安排成同步开展模式，压缩时间。
死局二、
阿康：这次的主视觉设计，客户要高端大气上档次，五彩斑斓的黑。
设计：你再说一遍信不信我P个蛇精脸戳死你！
破局示例
阿康：客户想要的是苹果风，扁平化，主色调用黑金的。这是示例图片。
破局法则
一定要搞清楚客户的目的！深挖客户对设计的需求，解析到底，细化成设计师能理解的内容。最好让客户给、示、例。
死局三、
阿康：虽然有些羞于启齿，但是这个图要重做。技术开发要psd格式的，你给我的是ai格式的。
设计：之前怎么不说！
阿康：今晚饭我请。
设计：滚！
破局示例
提前沟通客户、技术开发同事，在开始设计工作前，汇总并告知设计师全部要求！
破局法则
规格！格式！非常重要！提前确认，及时告知，否则这可能会让你前功尽弃！
死局四、
阿康：网站的搭建需求我整理好发你了，记得后台要支持网站内容的新增和更改哦。
技术：需求已看，工期20天。
阿康：What！！之前不是说7天吗！！
破局示例
阿康夜不归宿，和技术同事热火朝天地……促膝长谈，掰开揉碎地核对每条网站开发需求所要达到的效果。结果发现对于“后台可以支持更改”这一处，程序员同事理解为要开发出支持网站运营人员可以完全自主改动的系统，但阿康我要的只是网站支持程序员以后换个图片，换段文字而已。
破局法则
除了发送书面开发要求，一定要再口述解释一下，确保他真正理解你的需求。书面内容也不可少，技术人员可以随时查阅核对，减少后续沟通成本。
死局五、
阿康：按照排期，明天下班前测试版本能出来吧？
技术：够呛，这两天一直在调整这个动效，因为它 #include<stdio.h> int main(void){ printf; return 0 ; }
阿康：#include<stdio.h> int main(void)是什么？
技术：#include<stdio.h>int main(void)是……你懂了吗？
阿康：我懂…我懂个大头鬼！
破局示例
阿康再次夜不归宿，和技术同事促膝长谈：我需要明天下班前能收到测试版，目前影响项目进度的是哪个部分耗费了过多时间？如果只是卡在一个无关紧要的动效，完全可以商量其他替代方法或简化，保证项目正常推进。
破局法则
千万不要与技术深聊技术问题，你会被聊晕。把控完成时间节点才是你要关注的重点。在此基础上，沟通技术人员快速处理或替换那些耗费时间的非重点环节。
死局六、
周六中午
阿康：在吗？客户回复对设计的修改意见了，连带开发也要调整。
技术：自驾途中。
设计：我和技术在一起。
破局示例
穿越回周五下班前
阿康：星期六客户会回复修改意见，本周末有可能需要加班哦，麻烦设计和技术同事留在家中等我通知。周一活动开始，网站必须上线！
破局法则
预测工作，提前协调告知，特别是假期。保持“意外是一个常态“的态度，安排工作时提前留出足够的应对时间，执行中的意外和无奈反而会少得多。
死局七
网站部署阶段，我司技术和客户技术狭路相逢
我司技术：要顺利部署，对方服务器必须支持@#￥%……&*语言和系统
阿康：@#￥%……&*，我告诉他们哈……
阿康：我们技术问你们的服务器是不是@#￥%……&*
客户技术：@*&……%￥#应该也可以吧？
阿康：这又是什么，我再问问哈……
破局示例
阿康：我已经建好群了，这是我司技术@技术1，还有客户技术大牛@技术2，大家可以愉快地沟通啦。
技术对接技术，很快完成了安装部署。
破局法则
技术最好直接对接。敲黑板，但一定要实时关注，防止技术们为了互相碾压而打起来。
阿康：网站上线啦，好像结束了？
客户：不，一切才刚刚开始！
