我的软件项目分级理论

2019-09-09

   前两年就开始做一个项目体量分级，这个基础的概念，不说清楚，总感觉不好。现在笔记总结的差不多了，整理发布博客吧。这里只谈交付产品为软件，或者软硬件一体的项目类型。对于当下的软硬件一体的项目，大多重点在软件上，在算法上，结合在一起，可能虽然名义上软件不单独售卖，也不收费，但是，可以说，软件仍是其核心所在。我们软硬件开发者，经常会对一个项目的大小进行评价，但是，缺乏一个统一的标准。甲说的一个大项目，在乙看来只是中型项目，那么，交谈起来，可能就有偏差了。
  我结合自己的项目经验，制作了一个分级表格。我为什么要提出这个表格？很简单，减少沟通的障碍。表格不准确也没有关系，我们都不准确，但是，我们是在谈论同一个东西。随着讨论多了，不断修改，总能达成一致。不准确是可以慢慢修正的。沟通上不准确，可是有大问题的。这里只针对新立项的项目为讨论对象，对于那种已经有1.0版本，但是需求有变，想要2.0版本的项目，并不是我们的讨论对象。因为，对于已经作过的项目，需求分析、代码架构、技术难点、文档等工作，大部分都是作过的。顺便讨论一下文档、流程等。三级A、B、C，分别对应大中小，每个级别 三个档次：如A1，A2、A3。不用分的过细。

Class	Sub Class	Human Month	Worker Num Limit	Description
A（大型）	A1	196 ~ 256	36	500w，大概率一年以上，2年内。 18 ~ 24
	A2	108 ~ 196	28	400w   12 ~ 18
	A3	72 ~ 108	24	300w   10 ~ 15
B（中型）	B1	48 ~ 72	18	200w，7 ~12 个月。
	B2	24 ~ 48	15	120w  5 ~ 9月
	B3	12 ~ 24	10	70w    3 ~ 6月
C（小型）	C1	8 ~12	7	50w
	C2	4~8	5	30w
	C3	1~4	3	20w

    更高级的S、SS级别项目，如淘宝、京东、支付宝，天知道到底投入了多少人月、多少资金。因为很少人遇到，样本也很少，暂时不讨论了。

    对于项目级别的衡量因素，分为两个方面：持续时长（人月），涉及到的人数。 有些项目比较 任务拆分 比较 分散，环节过，且难以不同环节的技术差异度偏高，但是，需要的人月却不多。涉及到的人多了，就表明协作上的复杂度高。就意味着环节a的人难以理解环节c、d的人负责的内容，在做系统设计上，就有更大的概率出现疏漏、偏差。故参与的人数上限 非常重要。另外一方面，总“人月”较高，并不代表工程大，可能只是做的慢。或许其他团队去做，一半的人月都是 可能的。所以，“人月”是一个波动范围的较大因素，我们想要这个因素稳定，经理需要稳定的人月规划，老总更需要，那么，我们就需要让团队稳定。负责人应该竭力组建稳定而强大的团队。
一、小型项目
   一家小公司内，三五个人，花费三五个月能完成的项目，只能算小型项目。更小的，就是个人发起的，三五个朋友一起做的，甚至可能在业余时间做。这样小的项目，绝大多数只会产生一两个程序。即使写需求规格说明书、系统设计、概要设计、详细设计等文档，都可能没有中型项目一个文档内容多。三五个人，大家都是熟人，啥都敢说，都敢责问，要的就是迅速迭代，盲目要求文档反而是累赘。
   因为开发者太少，甚至连敏捷、XP等流程都走不起来，大家早晚开一次会，同步一下进度就行了。小型项目，最多派一个人来做测试。因为可能项目不重要，测的不仔细也行。出bug了再改。或者个人项目，自己兼职UI、测试、运维。怎么说呢，这些工作本来就是程序员该干的，只是当下分工更细致了。
   项目越小，死掉的概率越大。个人项目，大概率会死掉。这便是不需要文档的一个次要原因--没用。但是，总会有成功的。成功后再改版，却发现很多东西都忘了，这就糟糕了。所以，开发中间产生的各种文档、设计稿、笔记等，都尽量保存下来。C级别不需要 严格遵守统一过程、或者文档需求，只需要注重 需求、概要等文档保持更新即可。大概率业务很简单，连用例图、流程图、活动图都不需要。稍微写一下文档，也是为了帮助梳理业务，帮助思考。

二、中型项目
   我们分析的重点，也是中型项目。不像三十年前，那时候编译理论才刚刚完善、OOP出现不久，AOP仅仅是学术问题，也没有互联网，也不知道持续迭代、持续交付。年纪小的朋友可能不知道九十年出C++编译器要卖三千美刀，linux还是个玩具，GNU还没有内核。可想而知彼时的工具链与生态环境。1968年出现的”软件工程“术语，彼时只有20年历史，一个学科在20年与50年之间会发生什么呢？所以，软工教材上的东西，看起来与多数人多数项目的情形并不一致。这十余年，也是Scrum、XP等方法论发展流行的阶段。但，没有人能说，自己的做法是标准的，是最高效率的。各种变体、各种修改，被团队采用。我们可以观察到，采用这些方法论的项目，多是市场变化较快的，to C端的互联网项目。to B端项目，即使项目偏小，也会采用传统的Rational Unified Process (RUP)，或者准确来说，是AUP。简单总结：既要快，也要稳定，需要文档。可能B3项目只注意概要设计，不注意详细设计。而B1项目，会细致到每一份文档。
   要明白，文档是用来干什么的？1，规范化的文档减少了交流障碍；2、为了防止撕逼。参与者多了，队员之间可能都不是那么熟悉，遇到代码或者设计上的问题，脑子就会盘算，是不是自己的问题，咱也不敢说，咱也不敢问。这是人之常情。这也是为什么团队要经过磨合才能有效工作。也是团队为什么要保持稳定的原因。软件工程实践告诉我们，沟通成本随着人数增长超线性增长。而标准文档化，能帮助我们在口头沟通与文档沟通之间达到最佳效率。大白话就是：以最省钱的方式把活儿干好干完。
   总的来说，B 级别，必需要保证 需求、概要、详细 等文档，有余力者，保证 各种UML绘图、测试用例文档。至于各种文档相关的问题，我会在接下来的总结blog中分析。
   对于软件开发者，我们做的大概率是B级别项目，毕竟，中小公司多是社会的常态，普通技术水平也是社会常态。帕累托法则应该还是有效的。对于软件开发者而言，要争取多写文档，即使领导说没时间。这样，既能防止了撕逼，保护自己，也能实打实的加快进度。   
   对于项目技术负责人、产品经理，其职责就是就好需求分析、概要设计；对于技术负责人、小组长，其职责就是做好详细设计。不能把自己应该做好的事情丢给下层的人。占了title，就因该干好分内之事。而现状就是，不少技术管理岗的人，把职责下放。出了设计上的问题呢，就大家一起扛，实在不利于项目。

三、大型项目

    我还没有见过仍采用传统统一过程的项目。我曾参与三个大型项目。毕业时的互联网公司主业务项目，注册用户刚突破千万。但是是互联网项目，持续运营了多年，对于这种持续迭代型的项目，我也不确定对其分类是否合理。第二份工作的游戏本来是B1级项目，硬生生的被老板变成了A级项目。14年的末，开始做的虚拟试衣项目，算作A1级项目。所以，我主要的分析经验，来源于此项目。
   A级别，必需保证统一过程中所有文档。中大型项目，大概率会有后续版本更新，而且，由于项目持续时间很久，团队人员变更会更为频繁。我不希望每个新来的人，都来问我。我希望，文档就能教会他80%的项目知识。
   虽然人数多，但是，项目常驻 人员可能较少。可能对于一些人，只需要投入几个月的时间。例如A1最多32人，可能持续开发者只有20人。由于项目很大，每个人的个人技能有限，难免产生盲人摸象的现象。所以，我们以前的实践里，会就大项目里涉及到的各种技术做分享会，争取让所有人，对于整个产品都有直观的认识。可以不了解原理，但是，一定要了解目标。
   我们都知道，随着项目的持续运营，新的需求会持续的加入进来，特别是一些早期并没有被考虑的需求，若不更改架构设计，将导致采取一些特殊设计的方案来解决。随着”特例“的增加，系统将变得难以维护。直到有一天，有人受不了了，要重构。如果在项目开发周期内就出现了重构，大家就要注意了，就是负责做设计的人，没有干好分内工作。
   对于中型项目，人月评估大概是准确的。而对于大型项目，人月预估会变得不准确起来，因为项目复杂度的增长不是线性的。没有找好专业的负责人，就贸然评估并开干，时间加倍也很常见。

如果有任何意见，欢迎留言讨论。


[ 主页 ]

COMMENTS