【避坑】初次接项目的血与泪，扎坑了老铁（二）

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

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

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

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

万事开头难

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

合同上写明自签定日期开始项目正式开始，直到 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，不包含新功能的开发和功能变动。若有相应需求，可追加相关协议。

最后总结

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

固然，如今通常的外包项目都是需求很明确，只须要将之由需求层面实现出来就好，这样让专业的人作专业的事。因此建议你们想图省心的话，仍是上正规的外包平台接活，由于作一个外包项目要当项目经理、产品经理、开发人员，真的太累了:(