diff --git "a/source/_posts/\345\271\266\350\241\214\344\273\273\345\212\241(\344\272\214)\342\200\224\342\200\224 \345\267\245\344\275\234\346\265\201\347\250\213.md" "b/source/_posts/\345\271\266\350\241\214\344\273\273\345\212\241(\344\272\214)\342\200\224\342\200\224 \345\267\245\344\275\234\346\265\201\347\250\213.md"
new file mode 100644
index 0000000..19db992
--- /dev/null
+++ "b/source/_posts/\345\271\266\350\241\214\344\273\273\345\212\241(\344\272\214)\342\200\224\342\200\224 \345\267\245\344\275\234\346\265\201\347\250\213.md"	
@@ -0,0 +1,167 @@
+---
+title: 并行任务(二)—— 工作流程
+date: 2017-10-11
+---
+
+本文主要介绍开发者工作流程的相关内容。     
+希望能让你，明白流程的重要性，并对自己的情况对当前流程进行微调。
+
+---
+工作中，我们已经接触到了很多很多的流程，比如：请假流程、报销流程、任务评审、交互评审、等等。   
+**那么，**     
+**流程的基本定义是？** 无论我们干什么事，无论在生活、休闲还是工作中，都有一个“先做什么、接着做什么，最后做什么”的先后顺序。  
+
+**流程的目的是？** 流程的最终目的是提高工作效率，通过消除工作过程中多余的工作环节、合并同类活动，使工作流程更为经济、合理和简便。 
+
+**总体来说：** 针对一件经常发生的事情，通过分解步骤，按照一定的先后顺序有节奏地去执行，最终达到提高工作效率的作用。
+
+不知，大家在平时的工作中，有没有对现有的流程进行过梳理或者思考，思考过流程在我们工作中是否起到了作用。      
+
+接下来，将从以下3点来进行讲述流程
+
+>1. 3个主要流程介绍
+>2. **排期最为关键(*自认为精华加星*)**
+>3. 流程可以改变调整，适合自己的才是最好的
+
+---
+
+# 正文
+
+## **一、3个主要流程介绍**
+
+>* 交互稿【产品】
+>* 开发过程
+>* 提交测试【QA】
+>
+>每个流程从步骤、目的、违背的坏处、注意点，4个部分来介绍
+
+### 1. 交互稿
+步骤：
+- 交互稿自评(寻找需要修改的点以及遗漏的点，带着疑问)
+- 交互稿评审(和产品确认修改和补充)
+- 交互稿定稿
+- 中间有变动应及时更新交互稿同时通知QA
+
+步骤对应目的：
+- 了解交互稿的内容以及不足，罗列好问题，能减少在评审时的时间，以及避免对交互稿内容的部分遗漏。其中了解下涉及到的业务逻辑也是很有必要的。
+- 在评审时提出自己的疑问，以及更适合的交互方案。减少在开发过程中的返工以及避免和交互稿有歧义。
+- 根据评审结果，确保产品修改交互稿至最新。因为QA是根据交互稿来进行测试。
+- 有逻辑变动时，需要通知产品和QA。确保交互稿和测试用例一致。
+
+违背的坏处：
+- 延长交互评审的时间
+- 在开发过程中碰到交互问题需要花费额外的时间去理解以及解决
+
+注意：
+**！** 交互稿定稿后，原则上不再接受新增逻辑和功能。交互稿较大变动，需要发邮件说明并抄送相关人员。同时，开发时间需要适当进行延长。
+
+### 2. 开发过程：
+步骤：
+- 评估任务开发量人日
+- 确定排期
+- 前后端定义接口
+- 前后端分离开发
+- 联调
+- **提测前对照一遍交互**
+- **反思任务**
+
+步骤对应目的：
+- 开发前精准地估算出整体的开发工作量，是的之后的排期能更精准。
+- 根据工作量，合理地计算出任务排期，保证开发质量。同时排期是对各方的承诺。
+- 根据技术方案进行提前确定前后端接口与数据交互，减少在开发阶段互相讨论所占去的时间。
+- 在底打扰的环境下开发，提高开发效率。
+- 在真实环境下进行前后端接口联调。
+- 查漏补缺，避免低级错误。
+- 任务完成后需要对开发过程中有一个反思的过程，从中吸取工作经验。
+
+违背的坏处：
+- 把控不了整体的进度
+- 开发时间评估不准确会给别人一种不专业的感觉
+- 不定义接口，开发过程中变化的情况需要额外时间去进行代码修改
+- 频繁地和人交谈沟通，降低开发效率
+
+注意： 
+！当开发有风险时，要尽早提出来，通知各方，寻找解决方法。如果有能力尽量在开发中期提出来。杜绝在开发末期才发现风险。
+
+### 3. 提交测试：
+步骤：
+- 用例评审
+- 开发冒烟，提测
+- 集中修复bug
+- 产品验收
+
+步骤对应目的：
+- 用例评审过程中，产品、开发、QA对交互的理解达成一致。同时对于一些交互上的改动进行同步。以及帮助开发发现遗漏点。
+- 在测试环境上冒烟，保证开发质量，走通主要流程。减少打断QA测试过程的情况。
+- 把一些次要bug放在1个时间段内修复，提高效率。
+- 产品应该尽早介入。产品有时候会提些改动需求，避免上线风险。
+
+违背的坏处：
+- 开发、QA、产品对需求的理解不一致
+- QA测试过程中会出现更多的bug
+
+注意： 
+！当交互或者视觉稿有改动的时候，一定要通知到QA
+
+---
+
+**以上的流程如果有什么不正确的地方，欢迎指正**
+
+---
+
+## **二、开发前的排期，最为关键**
+对于开发者，任务排期一定不会陌生。   
+因为所有的任务都需要进行排期后，才能进入实质地开发阶段。    
+
+排期，顾名思义就是“排列日期”，由一个个日期(时间节点)组成的。   
+
+开发者的排期，简单来说由3个时间点组成：**开始开发时间、开始联调时间、任务提测时间**。  
+通过排期，合理安排3个时间点之间的时间段，同时在开发过程中和各方配合，最终按照预定目标完成任务。
+
+为什么说排期是最为关键的一环？    
+这是因为，在整个工作流程中，排期有着**承上启下**的作用：   
+>- 之前的需求评审、技术评审是为了能更精准地预估出详细的开发时间。
+>- 之后的具体开发提测阶段，则需要遵守先前排期上的时间节点来完成。  
+>- 现在进行任务版本化，准确的排期能为之后的任务排期减少风险。
+  
+和其他任何事情一样。好的排期能带来好的效果(比如促进开发效率)，反之，不好的排期则会引起各种灾难。
+那么，怎样得出一个好的排期？     
+简单的一句话概括：**尽可能地细分需求成一个个耦合性不高的模块，评估每个模块的开发时长。同时不要忘记给自己预留缓存时间。**
+
+**排期就像分生日蛋糕。把每个不同的模块当做分发蛋糕的对象。切出来的每一块蛋糕代表细分后的时间段。**
+下刀之前，我们需要确定要分给几个人。  
+尽可能地了解每个人对蛋糕的喜欢以及胃口，喜欢吃的多分点，不喜欢的则少点。方便能切出合适的大小。     
+因为下刀之后，没有像电视的回放功能那样可以重新切分。
+
+另外，排期是一种承诺。在工作中，亲口给出的承诺一定需要做到，要给他人靠谱的感觉。   
+因此，对于整个流程，由于合作方的关系导致任务有风险。在这个过程中，我们有义务去推动进程，有责任主动去告知每个关系方遇到的风险。
+
+---
+
+## **三、流程不是不可改变，适合自己的才是最好的**
+
+流程是不断完善的，每一个人都可以提出自己的建议，来完善当前的流程。使得流程能适应更多的场景，让整个部门的工作能够愈加顺畅。   
+同时，根据每个人不同的情况，对其中的一些流程进行适当修改或调整，使得能更符合自己的开发习惯。   
+比如：开发一个后端代码复杂，前端逻辑简单的任务。  
+可以把交互稿流程改成：     
+1、交互稿自评     
+2、私下找产品确定交互稿细节      
+
+**TIP：**    
+流程不仅仅用来规范我们的开发步骤，同时我们也可以通过流程来解决碰到的阻碍。   
+比如：     
+1、当2个任务碰撞在一起的时候，可以把两边的产品拉在一起让产品确定开发优先级  
+2、当QA测试时间不够的时候，可以和产品、QA、开发一起制定分批提测      
+
+---
+
+# 总结
+
+读完这篇文章后，如果能使您：  
+对现有的流程有自己的思考和理解，    
+同时能激发你的积极性，即使只有一点、两点。 
+
+那么，便达到了这篇文章的目的。     
+**自我思考是工作中一个很重要的技巧。**   
+
+by jiangren
\ No newline at end of file