做甲方的正确 “姿势”

甲方的世界你不懂！

虽然我不懂产品，但是总能提出更人性的设计；

虽然我不懂设计，但是指点江山是我的拿手好戏；

虽然我不懂开发，但是指定上线时间一点都不难；

虽然我不给你开工资，但想不想干了是我的口头语；

虽然我没什么理由，但还是想让你们改；

甲方的世界真是令人羡慕，拿着多少薪水暂且不提，还随时随地上演 “ SM ” 大戏。

然而，甲方的生活也并非只有幸福，还有着不为人知的痛：

1. 怎么选择乙方服务公司？
2. 怎么才能给公司省钱？
3. 虚报工作量怎么办？
4. 项目出现风险怎么办？
   1. 项目不能按时交付怎么办？
   2. 项目质量太差怎么办？
   3. 实际项目与预期不符怎么办？

针对这些问题，我们今天聊聊做 IT 项目甲方的正确 “ 姿势” 。

如何选择服务公司？

随着数字化转型的浪潮，很多企业每天高喊要数字化转型，然而还有很多企业仍然在信息化的门前徘徊。这并不是他们不想走进去，而是自身不具备 IT 能力，需要借助服务公司来完成。

服务公司多如牛毛、鱼龙混杂，稍不留神就会被坑。

选择服务公司常见的做法有 3 种：

1. 选择价格最低的；
2. 选择开发周期最短的；
3. 排除法：去掉一个最高价，去掉一个最低价，剩下的再做对比；

选择价格最低的：

与其他商品一样，IT 系统建设也是 “一分钱一分货”，所以表面上看起来价格低，实则未必。

我曾经见过一些极其不靠谱的服务公司，价格极低。后来才知道，甲方需要什么人员，服务公司就去市场上抓，甚至不经过自己面试，直接外派到甲方。如果甲方没有技术人员把控多半是被坑了，但即使甲方有技术面试仍然有坑，甲方只是帮服务公司做了面试是筛选，那些不合格的人员服务公司也不会录用。

所有，没有平白无故的性价比，低的价格必定隐藏着诸多隐患。单纯追求价格低，找一些靠谱的程序员，都比这种低品质的服务公司靠谱。

选择开发周期最短的：

有些企业把时间放在第一位，要求快速见到效果。这样的观点没有问题，但对于 IT 系统建设，时间往往与质量是成正比的，时间越短质量越差，写出来的代码也就越糟糕，这些糟糕的代码最终会拖慢开发的进度，成为恶性循环。

当然不排除有些公司在这些系统建设上有一些 “积累”。

很多公司售卖 OA、ERP、CRM 等这样的产品。产品化意味着稳定性，同时也意味着难以做个性化定制，所以选择时要根据自身的需求在 稳定性 与 个性化 之间做取舍。值得注意一点是这样的系统是没有知识产权的，只有使用权 。

而没有产品化的系统，情况要糟糕的多。大多数人认为，有一大笔遗产是件好事，但对于 IT 从业者的角度来看就不同了，我们通常把这样的系统叫做 “遗留系统”。在一个遗留系统上做二次开发，程序员通常会觉得比较痛苦，痛苦的过程中还会留下更多的 “坑”。

排除法：

去掉一个最高价，去掉一个最低价，剩下的再做对比；

或是

去掉一个时间最长，去掉一个时间最短，剩下的再做对比；

这是一个不会犯大错误的安全选择，能够剩下的几乎是同类型的公司。

当选择甚少时就会让你心慌。

分享一个做甲方朋友的小故事：

单一的维度对比是不全面的

我们建议从价格、质量、开发周期、售后、交付方法、公司规模、行业影响力、行业口碑这几个维度共同来选择。

价格、质量、开发周期、售后、公司规模 这些指标大部分公司都会考虑。值得一提的是交付方法。

交付方法

瀑布式

国内大部分公司还采用瀑布式的开发方法，如同火箭发射，需要在计划阶段做充足的准备，预测各种可能出现的问题，一旦发射无法再根据情况做出调整，只能听天由命。

瀑布式开发几乎就是这样，在进入开发阶段就很难再修改，直到上线才发现软件与设想存在巨大差异，后期修改要付出高额成本。

这种模式下，强调的是两个完美：完美计划、完美执行。

敏捷开发

敏捷开发是基于敏捷宣言定义的价值观和原则的一系列方法和实践的总称。

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

迭代是将上面的流程放到每一个小的交付周期，缩短反馈循环。让每个迭代都有相应的价值产生，通过快速迭代来验证是否满足客户（市场）的预期。

加快响应速度之后同时需要增加质量保障，否则高响应力只是在假设 “死亡” 而已，敏捷还需要内建质量如 TDD 等等。敏捷的实践还有很多，在以后的文章里再详细讨论。

敏捷与瀑布对比

业务价值： 瀑布在软件最终上线后才发挥其价值。敏捷在每个迭代都进行上线，价值也是不断交付。

用户能见度： 瀑布在软件最终上线才能够让用户看到。敏捷在每个迭代都进行上线，所以每个迭代之后都可以知道软件是否满足预期。

风险： 瀑布风险一直很高，因为无法知道是否满足用户预期，直到上线才能够得到验证。敏捷在交付的过程中不断验证，所以敏捷的风险是逐渐降低的。

响应变化： 瀑布式开发只有在开发之前具备响应变化的能力，开发阶段响应变化的能力就逐渐降低。而敏捷一直保持着响应变化的能力，每个迭代都可以根据客户的需求变化来调整开发计划。

行业影响力

行业影响力要看这家公司为 IT 行业做过哪些贡献，比如：是否出版过一些书籍、是否发布行业白皮书、是否提出过一些行业内的解决方案，或是为开源做出过哪些贡献。

这些一方面意味着在行业的专注与专业，另一方面也是行业的风向标，在为客户提供服务的时候能够比其他企业提出更适合的技术方案。

合作态度

不知何时起 “甲方” 就成了 “大爷” 的代名词，国外还好，国内更甚。

通常服务公司需要为甲方扮演三种角色：助手，专家，合作者。

助手

在一些简单的项目上甲方知道如何去做，并且不愿意投入自己的精力时，甲方更倾向于将服务公司作为助手，服务公司不需要过多 "思考" ，只要 "听话" ，在必要的时候向甲方汇报，就可以满足甲方要求。当然，这样的前提是甲方能够掌握所有知识和技能，并且能够预知可能存在的风险，否则服务公司则成了背锅的对象。

在项目过程中，甲方对项目的成功承担了 100% 的责任，而一旦出了问题，则可能全部由另一方来承担。

专家

在甲方没有相关知识与技能时，服务公司充当了 “专家” 这一角色。甲方将项目全权委托给服务公司，也就意味着服务公司对项目的成功承担着 100% 的责任。

通常服务公司会用自己的专业知识去理解需求，并且想当然的认为甲方需要 (或者不需要) 某些功能。在这种全权委托之下反而缺少紧密沟通，以至于在某种程度上项目风险更高。

服务公司也会因为一两次的项目意外，失去甲方的信任。

合作者

服务公司在扮演 “合作者”时，他们不只是帮助甲方完成一个项目，更多是运用自己的专业知识完成一个 “正确” 的项目。服务公司会站在甲方的角度给出建议，挖掘出项目背后的真正价值，同时使用更加有效的方式去验证项目的假设。

在服务过程中，服务公司会对甲方进行赋能，将一些有效的工作方法传授给甲方，让甲方在脱离乙方之后帮助仍然具备处理一定问题的能力。

要促成这种 “合作关系” 需要双方紧密沟通与建立信任。双方均为项目的成败承担 50% 的责任。

明确需求

甲方有责任明确自己的需求，而往往事实却令人沮丧，多数时候人们并不清楚自己想要什么，只是清楚自己不要什么。即使人们明确告诉你我想要的是什么，无论他们有多肯定，都可能不是真的。

需求应该怎么提？

功能不是越多越好，跟不要钱似的，重要的是满足自己的需求以及需求背后的价值。我曾经见过一个需求：系统要支撑 1000 人同时在线，每天处理 10 万条日志数据。而实际使用的用户只有 500 人，其中还有一些偶尔使用的领导层。不同使用容量的系统设计是不一样的，设计较大容量需要付出较高的成本，相应的硬件设施也要有所增加，这些因素同样会影响着开发的效率。

需求要从价值出发，通过最小的成本实现价值最大化。一些原则可以让需求不偏离其价值， INVEST 原则有些难度 （这个可以留个服务公司去做） ，可以使用 SMART 原则：

• SMART 原则 —S（Specific）——明确性

需要必须是明确的。能够清楚的表明用途。

例如：“我想要个锤子，能砸开核桃就可以了！”

反例：“我想要个超级屌的武器，可以毁天灭地那种的！”

• SMART 原则 —M（Measurable）——衡量性

需要必须是衡量的。验证这个需求是否达成。

例如：“我想要个锤子，能砸开核桃就可以了！”

反例：“我想要个锤子，越屌越好！”

• SMART 原则 —A（Attainable）——可实现性

需求必须是可实现的。

例如：“我想要个锤子，能砸开核桃就可以了！”

反例：“我想要个超级屌的武器，可以毁天灭地那种的！”

反例：“我想要五彩斑斓的黑！”

...

• SMART 原则 —R（Relevant）——相关性

需求必须是与实现的价值相关。有些需求可能是辅助的，但一定要与实现的价值相关，比如电商系统它的价值是购买商品，而登录则是为了用户能够更好的使用电商系统，其创造出的价值是间接。明确的价值则可以更好的做功能排序。

例如：“我想要个锤子，能砸开核桃就可以了！同时，手柄处要有一个挂带，抡起来的时候不至于脱手。”

反例：“我想要个锤子！还要再锤子的两侧加上两个漫步者音箱，在我挥舞锤子的时候可以播放音乐。”

• SMART 原则 —T（Time-based）——截止期限

需求要明确出截止期限，以便于排列优先级。

当遵循这些原则后，服务公司利用自己的专业知识和对需求的理解，更好的提供有价值的服务——砸核桃不一定要用锤子，可以用胡桃夹子。

需求变化

信息化时代，瞬息万变，风云莫测。今天还受万众追捧，转眼就成过眼云烟。

唯有快速响应变化才能够活下去。所以变未见得全是坏事，能够满足市场需求，给用户创造价值，我们又怎么能拒绝呢？

然而，无论哪种原因，需求的变化总会带来额外的成本。 羊毛出在羊身上，表面上压榨总是会在后期得到 “补偿”。

修改有时就像是在已有管道系统上再接出新的管道，最终成为一团乱麻。生产效率持续直线下降，直至为零。没人能搞清楚管道为什么会变成这样。

如果使用敏捷开发情况则会好的多，但修改的成本仍然存在。

举措清单

知道如何服务公司，正视合作的态度，除此之外还需要建立一些关键举措的清单。这部分是写给 CIO 或者信息部门的一些建议，清单可以预防可能出现的不规范。

• 细化工作量。 需要服务公司评估时工作量时要尽可能细化工作量，通过细致的评估可以帮助双方更好的进行项目规划，同时需要服务公司提供评估规则，避免出现 “拍脑门”的情况。

• 尽可能统一编程语言。 许多甲方由于不懂技术，所以编程语言和技术栈都由服务公司来选定，如果只有一家服务公司这种情况还好，而多数情况下甲方拥有多家服务公司为其提供 IT 服务。各家使用的语言各不相同，会使甲方深陷多种编程语言的 “沼泽”。

  当然，某些时候在特定领域的确需要特定的编程语言来支持，并非完全不能引入。需要甲方存减少编程语言的意识。

• 建立代码管理系统。 甲方需要建立自己公司统一的代码管理系统，并且开通公网访问的策略。可以使用 GitLab 进行搭建，如果甲方不具备搭建的能力，也可以使用 码云，或者 阿里云 的 Saas 服务，稳定性和访问速度绝对高于自己搭建，并且费用不高。要求服务公司必须将项目中的所有代码提交到相应的仓库中。

• 建立测试覆盖率。 据说华为要求服务公司代码测试覆盖率达到 90% 。不一定需要像华为要求如此严格，不过 70% 左右的覆盖率还是要有的。内建质量可以尽早的发现 bug，也可以保证后面的重构和新需求不打破已有的功能。

• 建立质量网关。 多种编程语言给建立质量网关增加了一定难度，不同编程语言都有各自的 Lint 工具，但无法作为质量网关。 SonarQube 是一个代码质量管理系统，开源、免费。可以扫描代码中的 “坏味道” 和可能存在的安全漏洞。同时会将测试覆盖率上报到 SonarQube ，当测试覆盖低于一定伐值则会报警。

• 建立持续集成流水线。 持续集成是一个很大的话题，简单来说可以将提交代码->运行单元测试->代码扫描的任务串联起来，任何一个环节出现错误就会报警。

  常用的持续工具有 Jenkins，GoCD，CircleCI 等，GitLab 也增加对持续集成的支持。

  

• 建立任务管理工具。这部分是一个可选项，尤其是全权由服务公司自主完成的项目。但一个好的服务公司也会自己建立任务可视化工具，将开发过程中的每一项任务都放到看板系统中。

  常见的工具有 Jira(收费)，很好很强大。也有一些免费的 Saas 服务 如 Trello，如果嫌 Trello 访问速度慢，也可以使用国内的 Teambition 、Worktile 等。

最后

IT 系统建设的最终目的并不是解决有没有的问题，而是能否依靠 IT 系统帮助企业加速对市场的响应力、创新力，以及能否拉近企业与用户之间的距离，让 IT 系统成为企业创新的基石和增进企业与用户沟通的重要桥梁。

让服务公司成为你 IT 的合作伙伴。

转载于:https://my.oschina.net/xbl/blog/3041857