上一篇: 复盘 | 初次接项目的血与泪，扎坑了老铁

上篇文章主要讲踩坑。初次接项目，在项目开始前夕遇到的一些坑，并提供了一些个人建议。最后说到原型的迟迟交付、需求方对接人员的变更、硬件开发团队人员离职等等，各种因素都在拖累项目的进度。

当然，项目中也不是只有坑，也有一座高山。今天就继续回顾接下来项目过程，讲讲如何爬这座山。

既然选择了远方，便只顾风雨兼程。—— 汪国真 《热爱生命》

万事开头难

中间因为需求整理、原型设计、经历长假一连串的折腾，等到原型最终交付出来，距离合同签订时间已经过去了一个月。如果按照合同上的交付时间来算的话，也意味着我们开发时间已经少了一个月。

合同上写明自签订日期开始项目正式开始，直到 xxxx 年 x 月 x 日。因为前期准备工作耽误了太多时间，如果就这么下去的话，项目风险很大，且会违反合同交付时间。基于此，我和对方人员沟通一下，明确是因为前期需求整理和产品原型设计耽误太多时间导致整体进度 delay，并确定整体进度预计会后延多少个工作日，这一切都拟定一个补充协议。

千里之行，始于足下

项目要开始，自然不能一股劲儿干，做好开发计划，不打无准备之仗。我们采用敏捷开发模式，所以下面这些内容很多是基于敏捷开发模式。

消化需求

首先，组织大家阅读消化项目需求。需求的理解非常重要，我见过许多开发人员，没有理解需求，上手就是一个字：干，然后开发过程各种问题，手忙脚乱地开发，还抱怨时间少、进度赶，结果自然开发效率和质量难以乐观。

仔细理解项目需求，正是磨刀不误砍柴工。设计人员理解了，可以更好的设计用户交互；开发人员理解了需求，可以避免后续开发中遇到因为需求不明而导致的逻辑问题；项目经理理解了，可以更好地把控项目的进度和细节，也更有效率地和团队人员沟通，不至于因为中间出现问题项目经理表示一脸茫然。

任务拆分

在理解需求之后，我们开始进行任务的拆分。任务拆分中，基于几个原则：

• 任务粒度原子化。 最小粒度确保开发目标清晰，不涉及其他任务，可以更好的评估任务复杂度和开发估时。

• 目标为独立个人。避免单个任务产生人员依赖，如有需要多人参与的任务，可以独立划分给相关人员。

• 任务需要有优先级。如有强依赖，可定义好前置依赖。

举例：用户登录的功能，需要怎么拆分？UI设计一个任务、前端登录一个任务、后端登录一个任务？说是一个登录功能，里面可能包含：

* 账号密码登录（手机号、Email、用户名）
* 手机号快捷登录
* 第三方登录（微信、微博、QQ等）
* 其他方式登录（如卡号卡密登录、SSO登录等）

手机登录需要涉及短信 SDK（注册申请、后台接入 SDK）、获取验证码、发送频率限制、黑白名单等等；Email 涉及 Email 发送、验证；用户名涉及敏感词检测、唯一性检测；第三方登录需要涉及第三方 SDK（注册申请、后台接入、前端接入）。

所以你看，任何任务的拆分，都应该首先从业务角度出发，列出到底有多少种应用场景和可能性，然后逐个拆分细化。只有不断的将任务一点点地解剖到骨肉分离、细节毫发毕现，才能避免因为经验和时间的问题，没有看到一些暗藏的功能和细节，导致开发过程中处处踩雷。

时间评估

任务拆分后，评估时间的时候，开发人员一般会比较乐观，另外一般项目也因为赶进度压缩时间，我的建议是在条件允许的情况下，尽可能预留充裕的开发时间和缓冲时间。长期地压缩开发时间快速开发和赶进度，会压缩开发人员深度思考的能力，当然最终影响到的还是产品的质量。

外包项目中，时间评估上尽可能细致周全，将需求整理、原型设计、UI 设计、架构设计、项目搭建、功能开发、测试联调、文档整理交付、交付验收、项目上线等时间都区分开（因项目、需求而异会有不同）。

任务拆分和评估时间后，所有的信息都输出到项目管理工具上，然后制作燃尽图。即使没有项目经理也可以实现成员自我管理。如有项目经理，也可以基于此整理出一个开发排期表和甘特图。

Let’s go!

如果一个外包项目合同已经签订下来，项目正式启动，那么就早些动手吧。避免拖延症，尽早地让团队齐心协力，向着完成项目的目标前进。尤其是业余时间做外包项目，有各种理由和原因迟迟不行动，最终耽误的时间还是会由自己埋单。

这次外包也遇到这个问题，因为前期准备工作耽误时间太久的缘故，项目整个处于 blocked 状态，过了一段时间询问相关开发人员进度，得知还没有开始。

技术选型

技术选型要贴合业务场景，外包项目更要如此。当业务初期时，技术要灵活，以便快速验证业务模式，就是说要能灵活地改改改；当业务处于稳定期，技术要稳定，不能拖技术后腿，就是说业务正常了系统不能整天出 Bug 或者服务器没事就提出一个问题；当业务处于维护期时，技术要讲究妥协，就是说不能还花费大量精力折腾项目，维稳就好。

总之，技术选型都是为了业务服务。比如因为对方有 iOS/Android 两端 App 的要求，在仔细评估需求后，决定采用 Native + React 模式开发，这样开发效率提高了，开发成本也降低了。

时间管理

时间管理上，因为是业余时间做外包，所以本职工作和外包上的时间花费一定要平衡好，不能因为外包耽误本职工作，当然也不能将外包置之一旁。

每个人有自己的时间管理观念和舒适的状态，比如我，我个人比较喜欢的状态是早起写一阵代码，如果是工作日的话大概是一个多小时，上班时间专心处理公司事情，下班回家后继续处理外包工作一两个小时，这样每天可以有将三个小时左右的时间处理外包任务。夜晚务必早睡，这样可以保证第二天的状态，不影响本职工作。如果是周末的话，早上会运动，洗澡吃饭后精神倍爽，一口气可以持续工作到中午。

外包过程中务必找到自己最习惯的节奏和最舒适的状态，本职工作和外包项目一定不能顾此失彼。当然更重要的是，个人的健康状况，毕竟身体是革命的本钱。

项目管理

前面提到，敏捷开发会采用一些项目管理工具，如Tapd、Tower、Trello、Teambition等。基本上当一个团队有了经验后，都可以使用这些工具实现自管理。但因为是初次接外包，和团队成员磨合也是一个挑战，加上每个人个性不同，和外包项目的特殊性，作为项目管理人员需要在项目管理上投入一定的精力和时间。

项目管理千差万别，项目管理人员也千差万别。记得以前公司有过两任完全不同风格的项目管理人员，一个是每天晨会出现一次，其它时间见不到人，基本没什么存在感；另一个是每天像班主任一样跟在团队成员屁股后面催进度，结果导致团队产生了严重的依赖性，在他突然离职后，项目基本处理停滞状态，团队成员也完全无法适应。

我的想法是，团队成员可以有不同的时间管理方式，和投入方式，但是务必保证有持续性的产出。所以，在项目前期，我们便花一部分精力搭建了 CI 系统（持续集成），后台和前端人员在实现功能提交代码后，可以选择自动发布项目或者一键发布，工作成果开发团队和外包需求方都可以查看。使用 CI 后，项目的进度就一目了然，不会处在一个黑盒里面。CI 的意义是以最小的精力，实现最大的价值。

外包项目如果周期很长，会是一个持久性的拉锯战。因为团队成员都在一个城市，所以我们除了日常的开发和沟通外，定期会组织大家坐在一起工作，这样面对面地沟通交流，将之前因异步沟通无法解决的问题提出来解决。比如租个酒店房间，大家周末一天或者两天时间呆在那里，没有其它的干扰，可以全身心地投入到项目中。一般这样的一天，可以有几天的产出。当然这样高专注度、高强度的工作也会使人比较疲惫，所以不必经常这么做。

当然主要还是大家日常开发、沟通，所以养成线上及时同步开发进度、共享开发中存在的问题很重要，我们当时是每日在微信里面沟通进度，然后如果 CI 有更新，大家可以相互体验测试，发现问题，有问题直接在微信里沟通，如果落实下来，直接输出到问题管理系统里。

在整个开发过程中，可以将重要的、难度比较大的任务优先解决，这样防止后续时间不充足的情况下，解决难度大的问题没有太多的精力。

里程碑交付

里程碑交付也是外包项目中关键的一环，在之前任务模块拆分和评估时间后，项目经理可以根据进度安排里程碑交付，在一定周期内按时按量交付已有功能模块，避免项目周期持续太久客户接收不到产出。尽早的交付，可以验证一些功能，也可以暴露一些问题，甚至了解客户的验收喜好标准等等。

例如，一个购物网站，可以根据功能划分为商品模块、会员模块、订单模块、购买支付几大模块，然后依据优先级分期交付一些模块。

记得之前在云沃客上接项目时，项目里面会有里程碑的历史记录，详细记录了每一个阶段的任务、截止日期、金额和状态，每一个阶段都会有交付工作和申请结款两种操作，将里程碑线上化，工作者和需求方都能清晰地查看到每个阶段的工作状况和历史交付产品。

交付验收

辛苦一段时间，最终将项目交给客户手里，因为前面已经有 CI 系统和里程碑交付，所以对客户的验收标准是有一些心理准备。项目中的一些问题，也尽量会在开发阶段就沟通处理掉，争取不在最后交付验收时遗留问题。最终交付给客户一定是包含完整功能、能稳定运行的系统。

关于后续维护，开始签订合同时已经约定好免费维护周期，这期间只包含处理线上问题和解决 Bug，不包含新功能的开发和功能变更。如有相应需求，可追加相关协议。

最后总结

项目到此也结束了，回过头看看，整个项目最花费时间精力的地方，还是开始时和对方沟通整理需求，因为相隔两地，线上沟通效率又不高，花费了大量的时间和精力在业务层面。

当然，现在一般的外包项目都是需求很明确，只需要将之由需求层面实现出来就好，这样让专业的人做专业的事。所以建议大家想图省心的话，还是上正规的外包平台接活，因为做一个外包项目要当项目经理、产品经理、开发人员，真的太累了:(