作为创业公司很重要的一个环节就是在有限的时间和资源下把产品需求落地为产品，也就是研发和项目管理，毫无疑问，这个阶段的主角是开发人员，那作为一个PM，把做项目管理的过程也当成做产品的过程的话，是不是应该多思考下怎么面向开发人员来优化整个研发过程和项目管理流程。本文就是我们如何通过优化开发环境搭建，代码管理，需求生命周期管理，开发任务分配和追踪，项目整体进度管理来提高研发过程中开发人员效率，通过持续集成和交付让开发中的问题更早暴露，通过合理的测试反馈工具让开发人员最快定位和解决问题。
一点前提条件和背景
印象中很多关于产品和开发为了进度撕逼的段子，其实作为一个开发转的产品，对这两块都有所了解，就我的看法是研发效率不止是研发人员本身的技术能力和工作效率，而是整个研发过程和项目管理流程的效率，但我自己理解的高效的研发和项目管理有两个前提：
- 公司内各团队有个大家认同的沟通协作方式：因为所有的流程和工具都是为人所用的，只有团队有主动性去沟通协作才能提高效率，这也是我这个系列第一篇写“异地创业团队如何做团队沟通协作”的原因。
- 尽量清晰的需求定义：产品经理的任务就是让研发团队开发正确的任务，我所碰到的开发延期或者交付失败很多时候就是由于自己对需求的认识不够，开发中过多需求的变更造成的，一个表达清楚，考虑完善的需求定义才能保证下面的研发和管理是不是在做无用功，所以本系列的第二篇是“聊聊针对异地团队的需求协作和原型、设计的评审”
说到创业团队的研发和项目管理的实践，就逃不开先要说一下我们研发和项目管理中的工具作为背景：
- 即时交流和协作：Slack，这个我在“异地创业团队如何做团队沟通协作”里重点谈到过，鉴于它的开放性，已经基本连接了我们用到的文件管理，设计评审，持续集成，测试分发，Bug Report等一系列工具。
- 代码管理：Git+Gitlab，在VPN环境内自己搭建Git和Gitlab一定程度上保证了代码的安全性，不过维护和备份都是个会耗费精力的问题，对没有专业运维的创业团队推荐直接Github托管。
- 项目管理：Redmine，老实说Redmine一直都不是项目管理上的最佳方案，专业级的有JIRA，轻量的有Asana、Tower等很多，我们就是已经习惯了，有一套Githooks在上面，并没有什么动力去换。
- 持续集成：Jenkins，虽然Java的坑也很大，维护起来也不时被坑，不过功能和插件确实齐全，搭起来也不易，有兴趣的可以尝试Travis CI或者Gitlab CI。
最后切入正题了，本篇涵盖的是我们在研发过程和项目管理流程，以及当中在DevOps上做的一些努力去优化开发人员的体验，就试着从各个环节总结一下，因为不同团队的研发流程和项目管理都不一样，各位看官可以挑有兴趣的来看：
- 研发环境的搭建：包括如何kick off新开发者，如何搭建日常开发环境
- 代码的管理：包括源码管理，Code Review和组织公共库
- 需求在研发中的生命周期管理：包括功能需求清单，功能需求定义和其中的开发任务项分配和状态管理
- 项目进度的管理：包括如何通过Redmine有效的执行敏捷开发
- 研发阶段的产品测试和反馈：包括在产品测试和反馈中的一些经验和工具分享
- 持续集成和持续发布：包括如何针对Web, Android和iOS分别搭建持续集成和发布
一、研发环境的搭建
如何让团队新的开发者尽快上手
对新的开发人员，一般都会有开账号，装系统，配环境，跑代码这些过程，我自己发现每次都低估这些工作的耗时，以前就发现有时候不小心就一两天过去了还没跑起来代码，一两周还没搞清楚目前产品的功能，我总结了两点加快这个进度的方法：
1.加快能让代码跑起来的速度
有很多可以加速的环节，一个比较重要的就是自动构建代码，就是指开发人员checkout代码后通过简单的构建脚本就能完成代码依赖安装，代码编译，单元测试运行，也就是我们常说的跑起来。以Web为例，可以通过npm的脚本完成npm依赖的安装，然后用gulp完成代码的构建和运行，这也是持续集成的基础。
2.对产品功能需求和目前进度的了解
在背景的里说的保持一个尽量清晰的需求定义的一个用途就在这，新的开发人员可以通过浏览产品的需求文档来了解产品功能，我们的做法是在Redmine上把“系统功能汇总(含已排期未完成功能)”作为一个Custom Query，将所有功能的PRD列出来，有两种视图可以选择，一个就是下图这样按照产品线，能看到每个产品线的功能：
另一个视图就是按照功能完成的时间来归类，可以知道以前每个版本都做了什么功能，未来有什么功能正在排期中：
如何方便开发人员进行日常开发调试
目前对于Web开发来说，一般构建的过程中代码都会进行混淆、合并、CDN地址替换、CSS Sprite生成等等操作，造成在Dev服务器上调试很不方便，我们采取的解决方法是在web的Gulp构建流程中分不同的Build Target，本地调试使用未混淆的代码加本地搭建的Python环境，连接Dev数据库，方便Web开发人员本地调试。
二、代码管理
首先最重要的就是代码必须用源码管理工具，我们一直用的Git。代码的查看和管理都在Gitlab上，可以查看代码，code review，合并分支，打版本tag之类的，不过Gitlab对开发者不是必须要用的，所有这些操作都能用git command解决的事情，有两点我觉得需要关注的：
1.怎么让开发人员高效的使用第三方库
项目开发的过程中去抽象公共组件，使用第三方库或开发工具都可以提高开发效率，但需要做好模块和版本管理，有时候碰到一个开发人员引入了一个不合理的依赖，或者学习成本陡峭的组件，每个参与开发人员都要增加学习成本。这个一般都是根据不同的技术栈有相应的一套工具可以使用，我们自己在Web、Python、iOS、Android上面都有自己习惯的选择，需要加新的组件或者替换正在使用的都可以一起讨论之后加入，以免发生重复或者后期的分歧。我们主要考虑的点有下面这些。
2.如何做新功能开发的代码管理
只要多人开发，而且多功能并行开发都避免不了要考虑如何管理代码，一般有Feature Toggle和Git Branching两种，目前我们根据自己的需求定义了一个Git brancing model，对于复杂的新功能建立feature branch来开发：
虽然我个人更喜欢Feature Toggle的方式，不过实践起来需要的模板开发和构建方式上的配合，不如Git Branching对开发来说上手更简单一些，暂时就没有更换，建议看一下Baidu FEX的<<Feature Flag 功能发布控制>>去考虑自己适合哪一种。
三、需求在研发中的生命周期管理
对于开发人员来说，开发工作一般是围绕着具体的功能需求进行的，而背景中提到过的“清晰的需求定义”就是研发的主要输入，由负责的PM来主导需求(User Story)的状态更新，本节以一个功能需求(User Story)为例，先上一个时序图来说明单个功能在研发中的生命周期是什么样的：
从功能需求(User Story)的时间线上可以看出来其分为下面几个状态：
PM创建后协作编写需求文档(New)->需求确认(Confirmed)->开发中(InProgress)->待测试(Waitfor)->已完成,可以上线(Finished)->完成,可以关闭(Closed)可以划分为需求确认，需求开发，需求测试和上线三个阶段：
1. 需求确认
对于需求文档的编写和确认，不同团队方式不一样，我在前一篇<<“聊聊针对异地团队的需求协作和原型、设计的评审”>>聊了如何通过怎么协作完成清晰的需求定义，我的理解是包括功能需求的前置条件和后置条件，用户流程和规则，完整的产品交互原型，评审确认的设计稿。下图为在Redmine上定义的一个功能需求(User Story)
2. 需求开发
在需求定义清晰后，开发前需要整个开发团队的参与确认任务的分配。任务分配的原则就是将功能需求对应的任务按树形结构分解，敏捷开发里的学名就是“Work Breakdown Structure (WBS)”，保证其中每个任务都是可以开发，并且是可以测试的。下图就是一个功能需求对应的任务的实例：
具体到其中一个单独的任务项(Task)，里面会有它所属的功能需求(User Story)，当前的状态，优先级，任务指派的开发者，任务所属的产品线(Web, iOS, android…)，一个简单的任务描述的，所属的milestone，预计开发时间和结束时间，任务当前的状态和进度等等。如下图所给的就是一个Task的实例：
从上文中“需求在研发中的生命周期”的时序图上可以看出其对应的任务的生命周期是如何管理的，包括前端和后台之间的任务协作是如何完成的，简单来总结的话Task有下面几种状态：
新建->开发中->待代码复查(目前仅junior developer需要被code review)->待测试->反馈->完成(可以上线)->关闭(上线以后可以关闭)开发人员主要负责的就是开发的同时更新自己任务的状态，看起来状态蛮多，如果开发需要每次登录redmine来改也确实蛮累，在实践的过程中我们引入了一下优化的方法：
- 为Redmine自定义一些Git hooks来更新状态。通过自定义git提交语法，让Git提交能自动更新在Redmine相应的issue上，既节省了更新状态的时间，又能保持一个干净的git logs。下面是我们定义的Git提交语法：
[component]Abc:(Issue#Id) + Message (Issue Status)[component] 就是任务所属的模块，比如[ios], [android], [backend], [web]，这和Jenkins的Build Job绑定，当有相应模块的代码提交就会触发相应部分的持续集成和交付。 Abc 就是操作的Action是什么，比如Add, Mod(ify), Ref(actoring), Fix, Rem(ove) and Rea(dability)，用来让代码提交信息的目的看起来比较清晰。 (Issue #Id) 就是对应的Task的Id是什么，为了将changelog和task绑定在一起。提交以后就会自动更新Redmine的Task：
- Server端接口文档自动生成。在需求定义里可以将规则和逻辑写的很清楚，但在前端和服务端协作开发的过程中，如果服务端没有文档可能会经常被前端打断，询问接口具体参数的名称或参数类型，也是比较烦的事情，可以考虑用Documentation Generator在代码中添加注释来自动生成文档，我们使用的“Sphinx”作为Python的文档生成工具，用Python的推荐使用。
- 开发中的持续集成和交付。这个后面会专门来讲如何操作，具体的意义就是开发人员提交代码之后在Dev服务器上进行自动构建和发布，这样一方面每次提交都做Lint检查，有单元测试的做单元测试，降低代码最后集成的时候出现问题的风险，另一方面让PM可以尽早的接触到成品，尽早进行反馈。
2. 需求测试和上线
当单个功能需求下面对应的所有任务都开发完成后，由PM进行测试和反馈，在确认与PRD一致后可以由PM更新为“待测试(Wait for test)”。这里“待测试(Wait for test)”的意义就是该功能需求可以在发布到测试服务器(Test Server)，由业务团队及测试用户参与测试。当测试没有问题后，如果是Web功能则根据上线计划上线到Production Server；如果是Native App，则按照版本计划，可能需要固定时间发布或者等待几个功能完成后一起发布。
由于这里讲的是单个功能需求的研发周期，而测试和上线更多是在整个项目这个Scope上来讨论，所以针对测试和上线的部分在后面持续集成和发布的部分会来细说。
四、项目进度的管理
顺着上面的思路，当你有单个需求研发的流程后，整个项目的管理就是管理所有的需求，安排优先级和迭代计划，然后对所有需求进行同样的研发流程管理。敏捷开发里把一个迭代周期称为一个Sprint，每个Sprint做一次产品发布，然后回顾Sprint内的问题，规划下一个Sprint的开发任务，如下图：
我们的实践不完全是Scrum，但比较接近，我们的迭代周期为一周，保证每周至少都往Production上做一次同步。项目的进度管理在Scrum的实践里其实就是在它的三个Meeting时完成的：
- Sprint Planning Meeting：从整个产品的Product Backlogs里一起规划出下一个Sprint要完成的功能，可能对应着很多团队的需求评审会
- Daily Standup Meeting：在一个Sprint里每天和开发人员一起回顾昨天的开发进度，讨论碰到的问题和确认当天的工作计划，其实对应着为开发人员诟病的项目日报
- Sprint Review Meeting：在一个Sprint结束回顾项目进度，问题和下一个Sprint的计划，一般对应着PM要做的项目周报
在产品体验的优化中有个理论就是在所有直接接触用户的‘Touchpoint’上进行体验优化，其实我个人觉得这三个Meeting就是项目进度管理里的Touchpoint，在这三个Meeting上PM会和开发人员或者Product Owner进行接触，如果这里体验不好就会影响项目的管理。其实我们总结的优化方案也比较简单，就是通过项目管理工具Redmine去实现的功能需求和开发任务的“看板”：
Sprint Planning Meeting
平时积累下的需求我会建立一个Future Milstone来存放，这样在Planning Meeting上可以直接以这些作为Product Backlogs，作为产品以后可以去做的内容，这些需求可以按照功能模块来组织，然后在Sprint Planning Meeting上一起规划出下一个Sprint要完成的功能：
Daily Standup Meeting
每日的站立会议是粒度最细的会议了，就是追踪每个人每天的任务情况，在这里我们在Redmine上建立一个叫“本周需要完成的任务(开发人员)”的Custom Query，将这个Sprint里的任务按照不同类别( 网站，后台管理，iOS或者Android)来归类，作为我们的看板：
对于开发人员，只需要按照前面提到的提交代码来更新任务状态，完全不需要额外的工作就可以汇报自己每天的进度。每天早上一上班，所有的开发人员聚在一起，按照不同的类别一个个过任务项，同步昨天完成的任务，确定今天的任务，有疑问的就在早会解决。
Sprint Review Meeting
对于项目进度Review来说，Scrum的看板管理是将任务项按照状态来分类，这样能更清晰的看出来哪些已经完成，哪些还没有开始，可以通过变换Custom Query来实现：
不过Sprint Review Meeting一般就不只是研发团队参与，为了辅助相关的业务人员和测试用户一起来Review，我们通过在Redmine上建立一个叫“本周已经完成的任务(业务人员)”的Custom Query准备上线的功能，里面是这个Sprint已经完成的功能，将已经完成功能的按照来归类，PM可以按照这个来测试已经完成的功能，全部完成测试提交到测试服务器以后，相关的业务人员和测试用户也可以按照这些任务来试用，节省一下每次都要介绍更新了什么的时间:
五、研发阶段的产品测试和反馈
产品发布到测试渠道后的反馈
当产品发布到测试渠道就是希望在正式发布前得到业务团队或内测用户的反馈，对比开发人员的测试反馈，业务人员和测试用户的反馈一般都比较抽象，就是问题描述不具体，环境上下文不清晰，没有复现流程，解决这些问题最好借助反馈辅助工具：
- 移动端的Bug反馈工具目前我们使用BugTags，目前只用在Test版本上，可以让测试人员通过截图标记的方式描述反馈内容，发送时候也会附上环境和App日志，能节省不少对于反馈的处理时间。不过这个是显式的反馈收集工具，需要测试用户主动提交，如果需要隐式的反馈收集可以考虑AppSee，我自己没有试用过，但一些测评都表示可以记录用户行为的视频，统计界面点击热图和漏斗分析，不过收费比较高，有机会可以尝试下。
- 移动端的录屏工具的话可以选Lookback，其实是个用研的工具，功能就是语言录屏+面部摄像，目前还在Beta期间，免费试用，可以Mac直接连接录屏后发送到它的网站，也可以在它的本地目录里找到。
- Web端的Bug反馈工具可以也使用BugTags，之前没发现它也提供了Web版，后来有网友提醒，我就试了下，确实可以截图标注反馈。另外的话，曾经在《How Google Test Software》里面看到Google曾经开源的Chrome插件工具BITE，有各种web上bug记录和复现的黑科技，不过在Google Code上一副年久失修的样子，我没有勇气去尝试，如果有知道其他类似合适的可以推荐一下。
- Web的线上用户追踪的话，我们目前使用了Mouseflow，它可以记录用户的行为，然后在它的网站上通过iframe你的网站帮你复现出来，虽然不是100%精准，但可以观察一些用户的行为。
产品发布前的测试用例表
我自己的经验是每次发布前的测试都需要产品经理亲自来做，一方面确认发布功能的正确性，另一方面重新走一遍用户流程，确认产品目标可以达到。测试的方法比较笨，暂时就是通过Google Sheet维护一张测试用例的表，如果是移动端就每个版本维护一个测试用例表，开发版测试时会把表格分享给所有开发人员，每个人都可以遍历测试用例提交自己发现的问题。测试用例表的结构为：
一级目录，二级目录，三级目录，用例名称，优先级，前置条件，执行方式，操作步骤，预期结果，测试状态，测试备注，是否自动测试覆盖六、持续集成和持续发布
前几年有一段为海外客户做移动产品设计开发和咨询的经历，这里面一个重要的痛点就是不停发测试版给客户，征求意见和反馈，但对于移动app来讲之前每次打包都需要打断开发人员，等待编译，改文件名加版本号，上传等一系列繁琐的过程，然后还经常因为客户没有装最新版而造成沟通时间的浪费，所以早期我们就开始着手建立持续集成和持续发布体系来避免这些问题。
我理解的一个完善的持续集成应该包括代码提交后的构建->部署->测试->发布几个阶段，可以看‘The Product Managers’ Guide to Continuous Delivery and DevOps’上这个图来理解：
自动构建
在上文Redmine的Git hooks提到过githooks在持续集成中的作用，其实就是当Git Commit Message出现相应的模块，就会在代码提交成功后能在持续集成服务端(CI Server)触发相应的Server，Web，iOS或android端的自动构建，这是持续集成的基础。
这里面有个针对开发这边的优化就是尽量缩短自动构建的时间消耗，我们的Web编译就是个反例，优化前有10来分钟的时间，现在稳定在3分钟，还有优化空间：
持续部署
部署分为客户端部署和服务端部署两种，就是构建以后要把可运行的代码发布到相应的服务器和手机端。
持续测试
这部分在服务端和每种客户端都分为单元测试和集成测试，理论上来说能在持续集成的过程中执行测试，是对产品质量极大的提升，不过对团队的规模和时间要求比较高，一般还是按自己的实际情况来。
自我检讨来说我们客户端的单元测试这块做的比较少，自动化集成测试的话每个项目都只对主要流程做一下覆盖，这也是个从Linkedin早期开发流程里看到的经验，可以通过分析用户行为得到主要用户流程，然后先自动化测试这些流程。早期在Android开发的时候实践过，通过Jenkins+Spoon+Robotium可以在CI上跑多种不同的Android设备来对主要流程截图，实现多设备的测试，在CI的效果是这样的：
虽然效果确实不错，可以在持续集成阶段发现在什么版本或者分辨率下出现问题，但用Robotium测试写起来还比较麻烦，后来我在Github上fork过一些优化测试的方法进行优化，但如果不是非常长期维护的产品还是慎用吧。
持续交付
持续集成后的持续发布是我们主要需要解决的痛点，发布的对象分别是给开发和测试人员的Dev版，给内测用户的Test版和给最终线上用户的Production版，发布的渠道又分为Web端和Mobile端，需要分别来考虑，一个涵盖上面所有的情况项目的Jenkins大概是这样的：
在之前Gitflow的图上有展示到，我们将发布的dev,test和production分为三个不同的服务器：
- 对于Dev服务器就是由Git hooks来触发，每次代码提交都会更新Redmine对应的Task，然后Redmine发邮件给这个Task的Watchers，同时触发CI集成新版本到Dev上。
- 对于Test服务器就是当有新功能测试完成，准备上线的时候，就先同步到Test服务器上，通知内测用户下载测试，相当于Staging服务器。
- 对于Production的正常的流程就是当Sprint Review Meeting之后，按照确认要上线的功能进行发布。这里我有个习惯就是发布的时候在CI上检查一下发布对应的redmine tasks，避免有不该被同步的内容。
需要注意的就是，Web的持续交付相对来讲比较简单和成熟，但Android端和iOS端处理起来都比较麻烦，首先就是对于Production版本，都不能直接发布到AppStore或者国内的一堆Android市场，能在CI上做的就是build好production以后自动在Git上打版本tag。然后对于Test版本的分发，可以考虑使用Testflight或者国内的蒲公英，绑定到CI上，可以集成好以后直接发布上去，然后通过Slack建立测试用户Channel，自动发送通知消息，收到通知可以直接点击下载安装。
后记
关于团队沟通，需求协作和项目管理三块的总结终于写完了，很久没码文字了，写出来感觉蛮生硬，很多地方没有说清楚，不过水平确实也就这样了。写的过程中还是想到不少现在的方法里面有缺陷的地方，正好给自己一个ToDo List，以后去优化。
聊聊针对异地团队的需求协作和原型、设计的评审
MARCH 10, 2016 / WANGCHAO / 3 COMMENTS
摘要：做产品的都知道，需求是无处不在的，可能来自于用户的反馈，业务团队的反馈，用户行为的挖掘，团队内部的idea或者上级的要求，人人都是产品经理也就是人人都可以提需求吧…既然有需求就要细化需求文档，制作原型，设计界面，这是几乎每个产品团队都会做的流程，本文不涉及如何更好地写需求文档，只聊一下作为异地的产品团队怎么针对需求文档、原型和设计评审进行协作。
一点背景
我所谓的异地的产品团队，可能会和远程工作有较大区别。远程工作是大部分人员都不在一起工作，就像37Signals的畅销书《Remote》说的那样，而异地的产品团队是说一个团队里产品开发人员和市场业务人员不在一个地方工作，这个在一些瞄准海外市场的早期产品团队里是比较常见的，我们就属于这种情况。
在异地协作的创业团队，尤其是存在时差的情况下，会遇到的最大的问题就是对于无论是需求，还是原型和设计，都存在一个异步确认的过程，不能面对面吵一架解决，那就需要合理的协作机制能方便的讨论，反馈和追踪。
需求文档需要协作的内容
我这里说的产品需求文档(PRD)就是对于一个产品或者某个单独的功能，PM需要通过与整个团队一起来协作完成的需求描述：
- 与用户、客户、业务人员或产品团队内部的沟通后梳理出需要解决的User Story
- 细化功能需求的前置条件和后置条件，用户流程和规则
- 完成产品原型
- 和设计师沟通输出设计稿供团队评审
- 开发前与开发团队沟通数据模型和任务分配
- 上线前和市场推广团队一起确认功能的Tracking Goal
这个过程不同的团队不尽相同，但都是需要整个团队一起来协作完成产品需求文档(PRD)的过程。
以前遇到过的坑
先说一下以前我自己碰到过的坑，也就是这些坑让我们不断思考如何更好的去协作：
- 第一，无数个版本的需求文档
我最早做过的一些项目几乎都是用Word来写PRD，无论是像中国电信这样大型国企，还是在海豚这样的创业团队，在做需求的过程中就会发现一个需求来回讨论确认是很常见，有时候仅仅就是对某个文案的修改，但来回沟通就要发邮件，新建一个版本，然后就会变成下面这样…
文档里面还有更多小版本修改的说明，显得很专业的样子…但是word的评审功能都在本地完成，有时候一个细小的改动也要传文件找修改，实在很out，而且以前的版本在那儿根本没有人去看过，真的想去看讨论中到底做了什么修改的话，做个Diff也是真的很困难。
- 第二，确认的需求文档开发人员根本不看
做需求文档的目的就是服务功能的开发，但长篇的需求文档真的对开发人员极不友好，对某个特定功能需求的搜索和反馈都不方便。
- 第三，产品迭代中没有人去维护需求文档
开发过程中的需求变更基本是每个项目都会碰到的，新的需求一般都当面或者邮件的形式沟通好直接就开发了，一段时间后就再也不知道这个需求是谁提出来的，什么时候加的，因为PM很难及时去更新Word的PRD，而且保证每个开发都看最新的PRD开发。
基于文档协作平台(Google Doc)的需求协作
碰到“无数个版本的需求文档”问题很自然的想法就是通过在线的文档协作平台来解决，协作平台选择的是Google Doc，协作主要的方式就是由PM把整个PRD放上去，邀请相关核心的业务人员(可能就是Product Owner)，市场人员和开发人员参与讨论，通过Comment的方式来协作完成PRD及相关文档的审阅，用来组织周期性会议(Sprint Meeting)。
我自己觉得这种轻量的协作方式适用的场景是和不太愿意参与产品开发过程的客户协作的时候使用，因为虽然解决了交流协作的问题，但对产品开发团队内部来说依然存在复杂的长文档，小变更难以维护的问题。
基于项目管理平台(Redmine)的需求协作
我们从5年前开始接触项目管理平台，开始就是需求文档做好以后通过项目管理工具(Redmine)进行任务分配和进度追踪，大家做开发的都懂，写代码大家都还挺high，但不停汇报进度就很烦躁了，我们通过Redmine REST API开发Git hooks让开发可以通过标准格式的commit message提交代码就能更新任务进度来改进流程，得到了开发人员的推崇，这5年来经过不下50个开发人员都使用的很愉快，没用什么学习时间，大部分的开发任务都能拿到较完整的代码提交上下文。
但在做项目的过程中，我们还是不断遇到上面说的需求协作的问题影响到开发效率，初创产品不断改需求经常让大家争吵某个需求到底是什么时候加进来的，在PRD上怎么找不到。我们就思考是不是可以把整个PRD融入到Redmine上，这样的话：
- 可以用极简的Wiki语法写功能的需求文档，不用纠结格式，还能逐步加入功能相关的流程图，原型和设计稿的链接和相应的开发任务，甚至每行相关代码的提交记录。
- 可以把特定需求的整个上下文都track下来，包括需求的描述，对应的原型和设计以及围绕这些的讨论，向下能包含所有相关开发任务和任务的完成度，向上又能追溯到关联的需求，这样团队都能尽量focus在没有讨论过的问题和需要开发的任务，而不是重复地产生“这个我们以前确认过…”这样的声音了。
下面具体到需求协作的流程中来实际操作一下：
一. 记录需要解决的User Story
摘要里说过，需求是无处不在的，可能来自于用户的反馈，业务团队的反馈，用户行为的挖掘，团队内部的idea或者上级的要求，我们不可能拿到需求就开发，首先需要先记录下来，我们的流程是由PM从各处汇总后在周会上讨论，确认哪些是需要考虑放在哪个milestone来开发，哪些现在不考虑的会放在一个叫future version的虚拟版本里以后再考虑，这两类都新建User Story放到Redmine上进行track。
然后我们对进入Redmine的所有User Story按照不同客户端分为PRD-mobile，PRD-User Site，PRD-Web Admin，PRD-Wechat四类，有的团队可能习惯按照功能模块来划分分类，取决于项目规模，项目规模太大确实有必要。
最后在Redmine上我们会有自定义的Query来查看这些User Story，可以按照状态过滤出目前系统不同客户端已经完成的所有功能，对内部人员来说相当于一个完整的产品需求文档。当然也可以按照不同milestone，是不是已经完成等各种条件来过滤查看。
二. 细化和讨论确定功能需求
对于确定要排入milestone的User Story，PM需要按计划完成需求描述，通过协作和各方确认需求：
- PM描述功能的用户流程，用户规则，说明前置条件和后置条件，包括补充流程图和原型来说明。
- 为User Story添加相关的业务，设计和开发人员作为Watchers，需求的协作流程和开发任务的类似，就是当User Story的状态为Confirmed以后，大家可以通过评论来反馈来交流有问题的地方。
- 最后，当讨论确认需求和原型之后就得到下面这样的最终的User Story，整个讨论和修改的history都被记录下来。
三. 流程图和产品原型
制作流程图或者低保真的产品原型都是为了向业务和设计团队展示功能流程，在投入大量时间做设计和开发前得到早期反馈。
- 流程图
流程图绘制工具很多，我一般用Xmind来做，和任务管理系统共同使用，做好流程后作为附件放到Redmine相应User Story的描述里，通过Redmine的评论进行讨论协作:
- 低保真产品原型
制作低保真产品原型是的工具有很多，我习惯用Balsamiq和Axure，场景有点差别：
- 基于Balsamiq Mockup的原型和流程描述
用Balsamiq Mockup制作原型用在Mobile项目上非常合适，因为对于我这种手残的来说可以很轻松制作看起来还过得去的原型，我自己一般的用法是用把原型串成流程图带一些注解，其实以前有个工具designboard.cc可以在线这么做，不过已经不维护了，反正原型都做了其实就是把几个拼成一张流程就可以，做好流程后作为附件放到Redmine相应需求的描述里，协作同样通过Redmine完成：
- 基于Axure Share的原型评审和协作
Axure还是原型界的老大，Dynamic Panel和全局变量能满足大部分复杂交互描述，Master模板可以加快原型制作速度，加上有着丰富的类库可以选择，更新也很及时，现在推出Axure Share之后可以做页面级别的评审回复，还是我目前主力使用的原型工具：
四. 基于InVision的设计稿评审
一般来说需求阶段很大一部分时间都是花在设计师将原型输出为设计稿之后，往往大家对设计图的评审讨论是最多的，出问题概率最大的地方，之前我们也是设计完成之后放在Redmine来讨论的，不过在实践当中还是发现两个问题：
- 设计稿的讨论经常是针对一两个比较细节的点来讨论，每次讨论都要描述到底在说哪里
- 如果针对一个流程做一系列设计稿，用文件的方式组织就不如像原型一样来的好理解
本来考虑过也是用Axure里低保真原型替换为高保真的设计稿原型，不过因为Axure Share的评审功能还是基于页面而不是元素，对于细节丰富的设计稿来说还是不太够，后来试用了在线原型工具inVision，它的评审功能和Live Share讨论比较惊艳，后来推出的Workflow也很实用，下面重点说一下我们基于inVision的设计评审和协作流程：
- 相关的人员需要先注册参与评审，一般来说User Story的Owner，设计师，核心开发人员都需要参与进来进行评审。
- 由设计师在相应Project上传设计图。我们所有的设计素材都在Dropbox上，可以直接连接Dropbox上传，绑定Slack进行评审人员通知，可以完全不用人工挨个通知。
- inVision的Workflow将设计图划分为固定的几个步骤，默认的Workflow并不是完全合适我们的审核流程，我们给它的意义做了自定义：“待审核(Need Review)”，“开发中(In Progress)”，“已审核上线(Approved)”和“未来版本(On-hold)”，小团队的话可以像我们一样用这些预设的状态，企业级用户可以自定义更多状态。
- 由业务团队和技术团队对待审核的设计稿进行评审，可以在Web点击任何元素来评论。
- 对于Mobile版的评审，也有App可以获得更真实的测试环境，进行录屏和录音反馈。
- 开会讨论时可以直接使用Live Share实时语音讨论，在设计稿上白板演示。这是inVision一个主要卖点，不过可惜网速问题我们用得比较少。
- 最后把确认好的设计稿都更新在inVision上，把设计稿链接放到Redmine相应User Story的描述内。
就安利到这里，目前缺点就是付费版Workflow还不能自定义，另外国内连接性真是很堪忧，也就能FQ用…
五. 确认开发任务分配
当需求和设计都确认以后就是安排开发任务了，基于项目管理工具来做需求的好处就是可以将所有的任务作为User Story的子任务，这样一个需求的完成度就能很容易的得到，这个更多是项目管理里的部分。
六. 确认功能推广目标如何记录
在需求文档里以前经常漏掉的一点，因为推广运营过程中需要对一些数据进行记录和分析，这个在开发之前要考虑好，保证是可以track的，免得上线之后发现一些数据无法获取，浪费推广资源。
后记
回过头来总结为什么团队想这些方法去提高需求协作的效率，其实就是为了提高团队的执行力，让开发人员把精力放在开发上。既然不是专业做开发协作的，那肯定有很多疏漏或者不科学的地方，现在的流程只是目前的局部最优方案，欢迎感兴趣的与我交流。
异地创业团队如何做团队沟通协作
MARCH 1, 2016 / WANGCHAO / 6 COMMENTS
摘要：本文是对如何制定团队沟通协作的方法的一些思考，适用的团队大概应该在10-30人左右，最好focus在一个产品上，和业务团队有一定地理或者部门距离，不能完全坐在一起工作。
开篇的一点废话
本来只想写一篇总结一下我们一个跨国创业互联网团队是如何做团队沟通协作，需求协作，原型和设计协作，开发的管理和持续集成和交付测试的协作，不算是best practice，只是一个实践过程中的思考和记录，更多是给团队成员作为以后新人须知来看，没想到废话有些多，为了不伤眼，干脆分开写成一个系列：
- 《团队沟通协作篇》
- 《需求文档与原型和设计协作篇》
- 《项目管理与持续集成和交付测试篇》
基本回过头来进行一个总结之后，和Scrum的一些理念对比，还是有些比较接近的地方，只是并没有刻意去遵守，而是这几年从团队的实践中对流程和工具做一个思考和应用。流程的话其中有很多做的不够的地方，也还有很多没有解决的问题需要改进。工具上基本选择海外的工具或者自己搭的服务，因为团队部分在海外，而国内服务基本不能在海外正常访问，业务团队不方便使用，而开发团队自己可以用VPN，不过说实话网络环境真是很恶劣，这个忍不住要吐槽一下GFW…
公司各团队间的沟通协作
在管理创业团队的这几年随着团队从纯技术人员组成的开发团队到有市场和业务人员形成的Fully Functional的小公司，最大的感受就是沟通问题的重要性在不断提升，不同的职能背景的出发点往往不同，在开发看来理所应当的事情不一定在市场和业务团队是一样的结果，异地工作的团队就会更加加剧这个问题，尽量设置良好的沟通机制是其他所有协作的基础。
与公司业务人员和销售人员的协作
- 及时沟通和反馈
我们做的是一个跨国产品，大部分用户在海外由业务和客服处理，但是有任何问题都第一时间反馈在公司对应的群组里。这样开发团队尝试介入快速解决，提升用户的体验，如果不能解决也能了解问题发生的用户场景，对开发团队来说比过后冰冷的bug report要体验更深，更有修正的动力，正如YC Startup的《如何做出用户喜爱的产品》里提到Kayak会在开发的办公室放一个客服电话，不过那个极端了点，但可以理解一点。- 参与业务流程设计
有时候我们对用户知道收集反馈，数据化用户行为来优化，但对自己的业务人员反而不关注或者参与太少。
这里我的教训就是曾经对一个稍微复杂的线下销售业务流程，我们按照标准的工单追踪模型开发了一整套，但由于实际业务人员使用同类销售系统的经验并不丰富，不知道如何提需求，最后工单追踪模型开发出来业务人员都觉得用起来很麻烦，增加了很多沟通成本才勉强用起来很简单的功能，开发的时间和业务的时间都浪费了。
后来在新的业务流程里，我们尽量设计很简单的流程，然后让业务人员去使用，然后反馈，开发团队在业务的反馈中再加入流程支持，虽然刚开始难用一些，但一开始订单量也小，有足够流程优化的时间。- 周期性会议一定要记会议纪要，并且全员共享
会议的内容会分享给整个团队，让大家都知道一周的focus在哪里，有哪些问题正在讨论和解决，更好的协调大家的目标。
我们的实践是每周开一次所有部门负责人的周会，周会前在Google Doc上准备一个会议记录，主要准备目前正在focus的工作，上周完成的工作，需要讨论的问题和下周准备做的工作。其中上周和本周要完成的工作都是从任务管理系统Redmine里直接把相应的主要任务项复制过来。对于会上讨论的内容及时在项目管理系统上都开出相应的任务项进行追踪。
我自己是比较反对频繁开会，蛮浪费时间的，但对于跨地域协作的团队来说又是没办法的。与产品开发团队内部的协作
- 产品思路的共享
有时候PM会抱怨功能和需求改动无法让开发有效配合，其实大家都是为做产品好，如果每个决定都是透明的，让开发团队知道关于产品和功能来源的思考过程，用户角色和场景是什么样的，功能的解决方案构思又是怎么来的，开发团队不仅会全力配合，更有可能提出更佳的方案，不要吝啬这个解释的时间。- 产品运营数据的共享
产品所有运营数据统计工具的账号密码在项目的Wiki内共享，让开发团队可以看到自己的工作和产品之间的正反馈能激发团队的斗志，如果数据不够理想，我想这样的机制也能给运营和开发团队压力，是一个互相激励的过程。- 周会纪要的共享
跨地域的团队最担心的就是缺乏沟通的开发之后两边重心和步调不一致造成的损失，全公司的周会纪要对开发团队共享能让公司每个一线开发人员也知道产品目前的进程和focus的点。日常沟通工具
- 微信
微信是整个公司使用的最多的沟通工具，因为产品，业务和客服都需要用微信和用户沟通，方便快速直接的解决问题，但微信缺点也是很明显，一是没有云端聊天记录搜索，二是不方便贴代码。合适业务去实时沟通，并不适合产品开发过程中的即时通讯需求。- Slack
我们为了保证国内和国外都可以使用，之前尝试过Gtalk，Telegram，都还不错，不过直到Slack的出现，实在太杀器了，聊天记录的搜索和贴代码这两个问题解决以后还通过Channel和集成插件提高协作的效率，我相信有很多文章来介绍各种实用的技巧，我这边举两个我们正在使用的例子安利一下Slack：
- 服务器异常报警
建立一个#Monitor的Channel，服务器运维和相关人员可以订阅，由Slack集成New Relic和其他服务器监控程序，每当有服务器警告或者网络问题，得到报警之后，运维可以及时通过Slack了解，在Channel里告诉大家影响及预计修复的时间。下图就是个New Relic警告和修复的例子：
- 有新版本发布到测试渠道
建立一个#Publish的Channel，业务和测试人员可以订阅，由Slack集成持续集成平台Jenkins和测试App发布渠道Fir.im，当有新版本发布的时候，自动向Publish发送新版本更新通知，省的一个个去通知，和持续集成的流程共用就可以实现一键完成发布和通知。下图为现在Fir.im的新版本提示：
Slack丰富的API可以保证有更多的玩法可以自定义自己的开发和沟通流程，我们并没有太多时间探索，希望以后可以尝试。
后记
总结起来觉得虽然理论上看起来都比较简单，不过实践起来确实没有那么容易，比如让业务人员尝试使用Slack这件事我就一直没有完全的实施起来，需要找到足够的痛点让业务人员和开发人员一样享受自动化带来的好处，这和让用户使用新的产品一样是一个需要摸索和不断尝试的事情，所谓路漫漫其修远兮，吾将上下而求索…
Github Advanced Search猎头大法
JANUARY 6, 2015 / WANGCHAO / 9 COMMENTS
摘要：标题党了，其实就是随手记录下怎么用搜索一下潜在的程序猿候选人，纯属个人经验，虽然略有骚扰嫌疑，不够大家都是码农，就算不能共事，互相认识下应该不会非常介意吧：）
一点背景
作为一个创业团队，找靠谱的开发小伙伴是前提条件之一，相信每个团队负责人都经历过找开发者的窘境，但靠谱的开发者是稀缺资源，一般不是Post个职位就能找来的。作为一个前求职招聘类产品创业者，我也算见证了拉钩网和内推网这样互联网垂直招聘网站靠着这个难点崛起，我自己也在上面招到过优秀的小伙伴。不过，当你要招人的时候当然要火力全开，尽量找到更多候选人，码农都知道Github和Stackoverflow大法，也有人说这里是最好的开发者招募地，但怎么在Github上来主动出击呢，我做过下面的尝试，仅供参考。
Let Github大法 Begin…
招募目标：前端一枚，熟悉Jquery，对响应式Web开发有所了解，最好接触过grunt或者gulp之类前端工作流工具，coding experience在两年左右，毕竟项目比较紧，方便上手
工作地点：武汉
第一步：找到候选人的集合
先热个身，如何找到所有Github上在武汉的前端呢？
打开Github Advanced Search，输入“location:wuhan”，OK，895只程序猿出现了…(联系方式都有，不过码是我打的哈)
很小的功能哈，不过同样的功能在Stackoverflow Career上搜一搜，一个月要$1000哟（额。。。是的，没钱才折腾）
Github Advanced Search提供了按照用户“开发语言，粉丝数，项目数”的过滤，输入“language:JavaScript location:wuhan”就能找到所有Github上在武汉的132个前端了，Problem one solved
第二步：缩小候选人的范围
接下来就要尽量缩小范围，找到可能符合我们要求的候选人。
首先呢，上面说的Github Advanced Search页面最下面提供的按照用户“粉丝数，项目数”的过滤，能过滤掉一些完全不活跃的用户
然后呢，搜索结果页面的排序功能能过滤出粉丝较多，或者coding experience合适的候选者
我自己用“粉丝数>5，项目数>10”锁定了一个16人的list（PS:第一个就是前同事真的不是故意的==!），这对我就差不多是个适中的候选人列表了，之后呢就比较费时了，翻看一下他们的项目，看有没有和需求相关的repo或关注了类似的repo，这样就能比较精确了。
最后当然是要简单社会工程下了，微博，Blog，Stackoverflow什么的都要看看，要知道哪些候选人是可能在找工作机会的，哪些人没有，不要闹笑话了，这段就太邪恶了，还是跳过吧。
第三步：联系候选人
OK，这时候我们已经有一个符合我们要求，并且可以联系了，可以分成两组：
一组是暂时没什么希望的，可以介绍下自己和自己的产品，说明怎么找到联系方式的，主要是为了认识一下，最好能介绍一下身边同样符合我们招聘条件的人，人以群分嘛，这样换来的候选人比较有希望。
第二组当然是可能正在找工作机会的，同样要介绍好自己和产品，争取一下互相了解的机会，这里肯定就是自由发挥啦，看看有没有可能共事，先预祝大家都能招到合适的小伙伴：）
收个尾
用了蛮久的，一直说记一下的，不过这写完回过头来一看，居然颇有某网络热帖里屌丝用大数据追女神的感觉…结果这忙活了半天是找基友，太心酸了，关机睡觉了==！
PS：鉴于这个文章转载还不错，我要打个广告了，麻烦各位有海外租房和海外房产投资的亲们移步洋房东，各位转载的时候也麻烦带上，感谢！
