我的软件项目分级理论

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
POST A COMMENT

(optional)



(optional)