一般大中型的软件项目，都会切分为数个细小的任务，由多人协作开发，在这个过程中，沟通相当重要。比如xdite的OTCBTC项目，大概有600个任务，数十名开发人员，如何协作和管控项目质量和进度呢？看xdite用了什么工具，如何拆解任务以及跟踪任务的？

不同项目适合不同类型的项目管理软件

• 根据项目不同的体型，用的项目管理软件也不太一样。
• 小型项目：Trello（看板式）
  • 一般小型协作项目的开发，我通常会推荐Trello。
  • （30个以内待办事项需要管理）Trello是看板式管理。
  • 适合待办事项状态简单型的项目（如：尚未实做，实做中，已结束）
• 中小型项目：Tower （列表式）
  • 中小型项目，我推荐Tower。
  • (100个以内待办事项需要管理）
  • Tower 适合待办项目中多类别型的项目。
  • 比如，我写书就会用Tower，第一章需要完成什么，第二章需要完成什么。
• 复杂型项目：Redmine
  • 至于公司内部软件开发，我们用的就是重武器Redmine。
  • Redmine是一套开源软件，非常适合管理复杂的项目。
  • 这套软件里的常见功能，跟一些复杂型项目管理软件（Trac 、Jira）相似。
  • 但另外有一些特殊功能。
    • 子母任务（可以展开User Story）。
    • 里程碑 （可以做逆向法）。
• 非常适合本书之前章节提到的流程，加速前进。

当项目任务超多时，项目管理软件必不可少，程序员大多比较安静，习惯打字不擅长说太多话，一个好的项目软件是必不可缺的。xdite接下来介绍了她是如何用Redmine来协助项目开发的。

协作其实是一门大学问

• 要进入大型协作（一个项目至少10个人以上参与），就一定要用软件管理。
• 项目管理工具可以帮到项目什么呢？
  • 通常项目管理工具多具备这些功能：
    • Issue的主题。
    • Issue的内容。
    • Issue现在的状态 (新创建、已指派、已解决、已回应、已结束、已搁置……等)。
    • Issue优先权 (正常、重要、紧急、轻微、会挡路……等)。
    • Issue发生日期。
    • Issue希望解决日期。
    • Issue实际解决日期。
    • Issue被分派给谁。
    • Issue的附件。
    • Isuue的观察者。
  • 项目管理软件主要能提供以下这些价值：
    • Issue List：透明列出所有需要被执行的项目。
    • Issue Milestone ：一个区块可以列出阶段内需要被执行的项目。
    • Project Daily Progress：项目今日整体动态。
    • Issue Ticket：一个可以记载 内容，状态、优先权、日期、分派者、观察者，且具有“permalink”、“许可权控管”，且让大家可以讨论执行项目细节的地方。
    • Related Tickets：可以Cross reference或具有子任务功能。
    • Wiki：一个地方可以整理统合项目现在所有的相关信息。
    • Personal Dashboard：一个地方可以看到自己今天需要Focus进行哪些项目。
    • Custom Query：一个地方能让Manager可以看到自己的同事正在进行哪些项目，这些项目目前的状态是什么。
• 协作功用1：展开User Story
  • 我在2010年带领团队费时2.5个月开发出一套论坛系统。
    • 开发流程也是一模一样。我们先写好主干User Story，然后一条一条展开次级故事开发。
    • 而这就需要在协作软件上，一起讨论完成，并且让团队每个人都明确知道所有的User Story。
• 协作功用2：利用倒数计时法管理项目
  • 在展开大项目的故事之后，我们开始利用“逆向法”。
  • 结合Redmine的Milestone功能，把这些Issue一张、一张归类到Milestone去。
  • 这样对每一周需要做哪些项目，就有很明确的归属。
  • 必须要让团队成员，透过协作工具，看到每一周明确冲刺的进度很不一样：
    • 第一周：准备工程。
    • 第二周 ：困难技术研究。
    • 第三周――第五周：主要功能开发。
    • 第六周――第八周：次要功能开发。
    • 外包细节单独Milestone控管。
    • 倒数三周：UI修正。
    • 倒数两周：封闭测试任务。
    • 倒数一周：上线前细节任务。
  • 每一周都有很明确的任务，以及要完成哪一些任务。
• 协作功用3：加速协作沟通
  • 我惯用的Redmine，缺省配置只有三种状态 ，“新创建”→“制作中”→“完成已结束”。
  • 我们会扩充到六种不同的状态，以配合现实中会发生的状况：
    • 新创建。
    • 实做中。
    • 已回应。
    • 已解决。
    • 完成＆结束。
    • 搁置不实做。
• 协作功用4：决策与程序码整合实做(Ticket Branch)
  • 有时候技术改进的决策，在程序码上面无法被叙述追踪。
  • 因此往回追溯Debug时，就会无意间破坏原始的设计。越改越烂。
  • 所以我们在工程上做了一些改进。配合 Git版本控制，希望软件工程师在开发功能时以一张Redmine Issue作为开发单位。
  • 这样的实做方式可以让：
    • 每一行程序码背后都能重现决策。
    • 程序设计能够将任务切分干净，而不会有一大堆任务作不完的感觉。
  • Redmine切任务切得恰当，有办法让程序设计感觉像沉浸在打怪、升级、破关之中，而不是陷入一个永远没有尽头解不完的大泥淖。
• 利用Redmine加速：加速把Story切得更细，实做更快
  • 单用User Story，可以把角色关系厘清得更干净。

单用Redmine项目管理工具，可以协作的更快速

https://www.redmine.org/projects/redmine

说太多好处，还不如去这里下载Redmine软件来试试，开源的。

协作工具有了，管理软件有了，下一步就是要将软件项目切分成小块，如何切分你的软件项目？

如何拆解任务，保持速度

• 以下我会分析一些切分任务的诀窍：
• 粗切：根据开发周期
  • 在第一阶段，我们会根据开发周期粗切。
  • 大致上归类到每个MileStone去。
  • 这一类任务的细微性大致上就会是这种等级：
• 再切：根据工作天切分
  • 比如说这一周，必须要完成“身为一个商家，
  • 我要能够在后台上架卖币广告，并且设定上架贩卖”这个大Story。
  • 那么我们就再把这一个大Story，
  • 让负责的程序设计细切成单天可以解决的任务。
• 细节：切成一口气可以做完的大小
  • 每个人都喜欢自己可以一口气“破关”的感觉。
  • 所以必须再把任务切到可以“一口吃”的大小：
• 会卡住进度的任务切出去
  • 有时候，我们在做某些功能的时候，某些关键功能无法一个人独力完成，甚至后续必须要花费很多时间。
  • 这时候，“切分任务”这一招就非常有用。我们内部有一个原则，凡是：
    • 三小时之内没有解法。
    • 需要其他人给答案。
    • 或者需要辩论。
    • 或者需要非常复杂的实做，甚至外包参与。
  • 一律将这类问题，开任务出来，分配给其他人。
• 每一次的版本都是完整版
  • 有时候，我们没有办法一次性把功能写到最完美。
  • 所以我们将User Story难度降低：
    • 第一版，降低到双方可以留言，并且上传截图（但是不能实时更新）。
    • 第一版写完之后，第二版加上实时刷新功能。
    • 第三版，接上专业pusher协力厂商服务，重构成真正聊天室。
• 每一个流程独立都开票
  • 在开发中，我们并不会强求，在一张票（一个需求、任务）里面完成所有细节。
  • 相反的，我们鼓励把同一个功能的票全部切开独立进行：
    • 讨论。
    • 画面设计。
    • 后端实作。
    • UI调整。
    • 测试验收。
  • 全部切开独立进行，相互关连，好处是不会让一张票过长。
  • 整理一下我们的切票（切割任务）原则：
    • 大脑当机就该切票。
    • 被人卡住就切票。
    • 每个半天都要解掉1-3张票。
    • 有问题就切割出去问，不要耽搁到开发进度。
  • 切到每张票都能够有“直接解法”，或者是该张票的“主要任务”就是“被切出去弃置”。
    • 这种“开票法”，会开出非常多任务。
    • 相对的，我们也在当中逐渐把很多细节厘清，
    • 并且搁置很多因为时间，预算，风险因素，必须要放一边的待办事项。
    • 虽然任务越开越多，但是进度其实会越来越快。
    • 票开越多，才不容易森林大火，因为开票实际上是划出防火巷的一个作法。

像xdite这样的切法，必然任务越切越多的，如何控制任务的方向呢？其实跟大多数作法一样：砍掉不重要的，抓住最要紧的，也就是抓所谓的“指挥官任务”看下来的介绍。

每一周聚焦的方法 ：指挥官任务

• 我们内部做项目有一个独特的工具以及机制：“指挥官任务”。
• 这是我在知名辩论家黄执中在罗辑思维“你如何听懂我说的话”学到的一个概念。
• 只能做一件事，你做什么？
  • 有了“指挥官任务”，队员自己就会权衡什么是轻、什么是重。
  • 指挥官任务，就是“只能做一件事，你做什么？”
• 开发产品“充满意外”，
  • 你没有办法预测三个月之后的事
  • OTCBTC 开站第一个月摆脱死亡漩涡，后续甚至暴冲打下江山的那段过程。
  • Growth = Conversion（转化） – Churn（流失）
    • 坊间对增长这门技术的印象，就是不断的曝光，不断的增大转换率。
    • 但是创业公司所处的世界，却是这样的：增长的确得不断的增加转换率，但是降低流失率也是增长另一个方向。
      • 特别是创业绝大多数时候，甚至是最初一个月，流失率是远远大于增长率。
    • 如果不把火力集中在“阻止流失率”上，增长只是空谈。
  • Intercom真是我们的秘密武器。
  • 我们当时是唯一一间，做到早上抱怨，晚上就修复上线的币所。
  • 全拜Intercom所赐。很多早期流程上的瑕疵，就是用实时客服抓出来的。
• 第一周的指挥官任务：拼命创造深度
  • 我们发现，体验在其他互联网产品可能是最重要的。
  • 但在 OTC 圈不是。OTC 币所，最重要的是深度。
  • 创业界有一句话是说，可以的话尽量别创需要搞“双边市场”的公司，难度真的太大。
  • 因为双边市场你得同时解决“供应方增长”、“消费方增长”的问题。而且也要同时解决“供应方流失”与“消费方流失”的问题。
  • 很不幸的，OTC 平台就是“双边市场”。
  • 我意识到要是我在第一周没办法解决这样的问题，那么“就没有下一周”了。
  • 所以第一周。我们推出了“永久千一会员”计划。千一会员计划造成了一个效果。
• 第二周的指挥官任务：优化卖家体验
  • 我突然间意识到很严重的一个状况。
    • 我们并不是职业交易员，感受不到他们的痛。
  • 所以我立马安排三个内部同事。
    • 给他们一人二十万人民币。
    • 吩咐他们的工作每天就是在上面跟站上的卖家一样职业交易。
    • 赚钱算他们的，亏钱算我的。
    • 果然我们马上抓到一堆“严重”的基本面问题。
  • 例如：防爆仓机制，聊天室通知，改价动线。
• 第三周的指挥官任务：降低客诉率
  • 第三个星期因为量都起来了，深度也足够了。
  • 开始会有一些交易的纠纷。
  • 所以我们又花了一整整个礼拜，针对这一些交易不诚实的举动，全面调整了机制。
• 一周只做一件事
  • 这一些举措都不是“预先规划”的。
  • 而是我们用Intercom侦测到的高并发客诉归纳总结出来的。

不管怎样，创业公司的软件开发，是有时间和资源限制的，所以任何阻档前进行任务，都要考虑砍掉或克服。

产品创业跟你想得不一样

• 开发产品进度时“不能被挡住”
• 营运公司时“不能被害死”
• 不能被挡住
  • 所以我们在做产品开发时，每一周都有一个明确要完成的“主干相对完整版”。
  • 并且优先权摆在得扫除会卡住的关节进度任务。
  • 至于票怎么展怎么砍，原则就是不能 delay。
• 不能被害死
  • 是我们上线第一个月，细节打磨，就超过了1000票。
  • 这些票都不是预先的规划。而是“不做这些就会死”。
  • 我们团队方向不是方向精准，不是老是下对正确决策
  • 规划永远与发生的不一样。
  • 但这不代表不需规划，而是得做好心理预期，规划有可能不会如你想像的发生，
  • 甚至 180 度大拐弯
• 灭火最重要，姿势不重要。
• 战场上面没有明确与周全，只有 what ever it takes。

到这一章为止，项目就从规划、协作进入到了具体的细节阶段，下一部分就可以看到用户体验的细节处理，软件是如何抓住真实的用户体验来进行迭代。