从严谨的角度触发,应该基本按照同样的标准实现项目和产品。
很可惜,在实际工作中,这基本上是不太可能的,除非项目比较大,客户要求比较严格。
本文主要谈以下几点:
1、需求差异
2、实现差异
本文的读者主要面向程序员和项目经理。内容属于一家之言。
本文目的绝不是鼓励工程师糊弄设计,糊弄自己。
我们应该尽量认真地对待自己饭碗,认真对待技术,客户,自我。毕竟软件工程始终是一门严谨的工程,当你总想着糊弄别人,那么很可能也会糊弄自己。
大体可以理解为遭遇战,是突发的事件。
这个时候项目在老板和项目经理眼里就意味着:一次性、较短的时间、较为一般的质量、少支出多赚钱。
必须强调:项目至少应该呈现的质量必须达到客户要求,无论功能、性能、ui,文档、维护
一个可以重复销售的系统代码,一个只需要经过较少定制化或者不定制化就可以使用的系统代码。
产品意味着:多次,持久,高质量
注:下表的差异描述只是针对一般情况而言,不排除有部分项目是严格完成的。
分类 | 个性化 | 生命周期 | 扩展性 | 乙方可维护性 |
项目 |
通常相当一部分个性化很强 不具有可复制性 这是大部分软件公司存在的基础 |
通常3~5年 | 对扩展性要求不高 |
这种维护性对乙方 不是非常友好 |
产品 |
一般不提供个性化。主要通过设计 来满足可扩展,但也只是有限地支持。 |
可能10几年,甚至 是几十年... |
在一个中长期内要 支持较大的扩展 |
对乙方(软件工程师) 友好 |
首先有个前提,通常项目经理管理工程师,或者说控制项目工期和交付质量等。
项目:设计不会花费那么多时间,因为不太需要考虑扩展,可维护性;规范执行可能不会那么严格
特殊情况下,工程师自己也是糊弄(不过基本属于菜鸟和没有职业道德的那一伙),逼不得已也有的。
产品:花费很多的时间设计产品,必须仔细考虑扩展,性能,可维护性等问题;编码的时候严格遵守规范
产品:基本同工程师
项目:抓需求,比较不关心设计,如果能抓,也主要是ui等直接可视部分;抓工期,比较不关心质量
项目经理需要懂得技术,最好是技术出生的项目经理,在保证设计和质量的前提下控制进度和成本等等。
有一小部分项目属于糊弄的,项目经理根本就不过问技术。至于为什么糊弄,大家都懂的。
如果项目经理不会技术,那么基本上怎么糊弄也为不过,首先就会被手下工程师糊弄。
所以公司招聘项目经理的时候,最好是技术出身,或者是给项目经理配备可信的技术负责人。
糟糕的项目大部分人都有体会,本人觉得没有什么必要写出来,毕竟做得很好的项目反而是少数。
但优秀的产品倒是很常见,因为不优秀,那么就不会和我们大部分人见面。
以下几个产品都是个人认为比较优秀的:
优秀的太多,就列这么几个。
虽然项目的设计相对较差,但是不同的项目之间差异相当大。
按照工程师对待项目的态度和项目的结果,可以分为6级别:
1级-非常糟糕:通常属于政绩项目,大家都懂的,除了有样子,其他都是糊弄的。钱一般也能收到一些,甚至是全部。生命周期通常是1~2年,或者是验收就结束。
这种项目没有人关心设计-它存在的主要目的是为了花钱。但也有好处,某些时候让某些苦命的乙方得以喘息。
老板喜欢这种,但工程师内心一般不太喜欢。
2级-设计和需求不对等:很容易烂尾,一般属于政府项目或者是一些财力有限的甲方。
这些项目设计它的设计和需求就不是对等的。可能要求很好的设计,但需求实现上确不允许,典型地想占乙方的便宜。
老板和工程师最烦这种项目。这个主要是乙方市场部的问题。3级-打折的设计:设计上各种打折,但也能将就这用。一旦甲方要求变更,那么就要钱,这基本属于糊弄不懂行情的有钱甲方。
4级-维护性不友好的设计:设计上大体算是尽心尽力,项目也基本完成了,不过对于扩展性和可维护性没有什么考虑,规范性执行一般
5级-大体上没有什么问题,算是良心项目,对甲乙双方都好
6级-优秀的设计,甲乙双方都可以通过项目获得较大的利益,和同类相比也比较出众。
本人做了不少项目,达到6的寥寥无几,倒是相当一部分属于1,2。
大部分工程师内心都希望设计完美的产品。
但很多时候,都不得不妥协,混口饭吃,胳膊拧不过大腿,主意太多反而让项目经理不喜欢-耽误了进度,浪费了成本。
工程师眼中理想的项目通常应该具备以下条件:
1.理性的甲方
2.合适的预算和时间
3.负责任的老板和项目经理
这种项目能够产生良性循环,构建一个良好的业态。
提升自己,找个更好的公司,或者更好的环境。
如果无法更换环境/公司,那么应该:
1.尽力做好设计和编码,遵循规范-尽自己的一片职业良心
2.根据老板/项目经理的要求,该舍弃的还是要舍弃。不要浪费太多的精力和情感,不值得,也没有必要对着干
1.项目设计总不如产品来得那么认真,完美
2.工程师要尽自己的一片职业良心
3.该舍弃还是要舍弃,胳膊拧不过大腿
4.不要和没有什么职业道德的人混,不要自甘下流,久了就变成下九流