23.第一次外包经历的经

第一次外包经历的经验教训

从2017-2-14至2017-3-15正式带完一个小项目。虽未失败，但 历经坎坷。我分别从项目启动前、启动会议、项目执行期来 谈谈这一次小项目带给我怎样的经验与教训。 项目启动前，无疑是谈需求。谈完需求，就该大致评估一下 工期。

第一个失误：当时我们评估的工期至少要到4月10日。但是由 于客户要得急，这也是第一个项目，所以就从了客户。这也 为我们累死累活埋下了伏笔。 教训：项目并不是非接不可，明知没办法完成的，时间太紧 的，可以不接，天下项目那么多，何苦执着一单，砸了自己 口碑！既然决定接下这单，那就开始写需求分析，我们的需 求分析采用敏捷开发中的backlog。

第二个失误：由于我底气不足，盲从技术人员的建议，将 backlog一改再改，最后backlog被改得面目全非。需求文档面 目全非的后果就是，技术人员不知道写完这个需求，下一个 需求是什么，需要天天问项目经理，然后项目经理就超级超 级忙，忙得焦头烂额，技术人员离不开项目经理，这不是一 件好事。 教训：一个项目只能有一个backlog,backlog就应该采用纯业务 语言，讲清楚一个操作的入口、出口。是否会产生弹窗属于 交互语言，不应该出现在backlog中；文字颜色大小等属于UI 语言，不应该出现在backlog中。backlog（需求分析文档）仅 仅只写业务语言，让大家都能看得懂。

第三个失误：客户是传统行业的，对IT行业完全不懂，只以

为第一次跟我们说他想要什么东西后，以后花了钱就不用管 事了，包括我们后面要把需求理细，客户都很不耐烦，觉得 这点“小事”怎么都要问他。客户每次派过来沟通需求的人不 同，所以往往要问一个可能他也不知道需求是什么的人，来 告诉我需求。 教训：开始时，就要告诉客户，需要有一个专门对接需求的 人，他要超级清楚需求，就算遇到疑问不能当即排版，至少 不能让我们技术方来告诉他，之前XXX提的是这个需求。

第四个失误与教训：域名、开通微信公众号、购买短信等需 要提前告知客户他们需要准备哪些资料。这样才会让客户更 好地配合我们完成整个项目。

项目启动会议。 项目启动会议主要就是分工，可以暂时只分出第一个演示周 期的人员和工时的分工。

第一个失误：我们这次项目启动会议，就分了谁写前端谁写 后端，然后了事，关于使用什么技术框架，没有提及，等我 反应过来时已是一星期后的事了，一个如此紧迫的项目，他 们使用的是以前没接触过的新技术框架，此时已经不能再改 技术框架了。 教训：一个全新的项目时，搭建框架、选用技术都应经过所 有技术人员的评估，不建议在外包项目中使用自己不熟悉的 技术框架。

项目执行过程。 项目执行期间，项目经理主要工作就是跟进。 第一个失误：跟进得很马虎，每天早会过前一天任务的完成 情况时，技术人员说已完成，我就标注已完成，从来没有自 己去检查。项目快上线时才发现，那些已完成的其实只是开 始做了，完成了一部分而已，所以导致最后项目快要交付

时，连续3天加班打2点多；最后交付时，也是bug多多。 教训：每个人都会报喜不报忧，技术人员也是一样，只要没 有完成100%的，只要功能没走通的，就应视为未完成。既为 了项目进度的管控，也为了项目质量。

第二个失误：没有绘制燃尽图，导致项目是否有延期风险， 掌控得不及时，所以项目进展半个月后，原本2个人完成的项 目，临时又抓了一个“壮丁”。虽然新进来的技术人员很快上 手，但是增加了项目成本。 教训：燃尽图是个好东西，一眼就能看出项目是否存在延期 风险，可以及时处理风险。

第三个失误：没有及时通知客户尽快准备培训等事宜，虽然 我们按时交付，但客户真正投入市场使用已经是4月份了。 教训：虽然有客户本身不在乎的成分在，但我们应该事先通 知客户的；我们应该帮助客户达成既定的目标。

第四个失误：按PMP来讲项目管理75%以上时间在沟通上， 但是我们实际执行中，与客户沟通非常少，可能还不到 20%，只有在问题出现了，我们才与客户沟通，但那时已经 引起客户不满了。 教训：我们应该每当每个演示周期，就向客户汇报我们进展 到哪一步了，哪怕有风险，也应该在过程中就让客户心理有 个底，不要等到临近交付时，才让客户知道有风险。平时的 沟通，可以促进我们与客户的联系，减少客户与技术的对 立。 如果在项目前期、会议、执行期都进展顺利，交付应该是不 成问题的。

评论区：

1 : 这坑历历在目啊，只是有些没跳

2 : 多谢分享

3 : 我也经历过...

4 : 一样一样的经历

5 :

6 : 目前即将担当甲方客户的角色，准备重点考察乙方承包问题

7 : 总结得不错，谢谢分享！

8 : 多谢分享