一般大中型的软件项目,都会切分为数个细小的任务,由多人协作开发,在这个过程中,沟通相当重要。比如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。
- 我在2010年带领团队费时2.5个月开发出一套论坛系统。
- 协作功用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。
到这一章为止,项目就从规划、协作进入到了具体的细节阶段,下一部分就可以看到用户体验的细节处理,软件是如何抓住真实的用户体验来进行迭代。