1、前言
一个项目从立项到交付上线,经历过些许阶段,从销售谈拢,到开发进场,测试与交付,前前后后,要不少时间。比较厉害的项目经理,怼天怼地也在交付之前,交付产品,虽然伤痕累累。
本文本着最近一个项目的案例,通过一些事实,来描述一些对技术上和需求上的感悟和理解。
竞标的时候,售前会努力体现自己家的好,压缩工期,压缩成本,号称我们会帮助企业用最少的人力成本,漂亮的完成项目。
项目是需要技术的,技术是需要技术团队评估的,是先评估,再报工期;反过来,就是另一码事了。赶鸭子上架,大家都是到后边的情况了,开发都会被压榨为烤鸭。
项目中,分为两个角色,产品和开发。是不是少点什么呢?对liao,少了测试和运维啊,那这两个任务到了谁的身上呢?测试分摊给了产品与开发,运维就全部分摊给了开发了(这就给开发后边埋下了加班的坑了)。
2、下面的情形,所见即所得
产品经理们,做好需求文档「注意!这里的需求文档,是不符合开发的要求的,纰漏百出,错误连篇,根本不符合开发用来码代码的要求」,扔给开发。
开发接收到文档,先进行文档的理解,此时此刻并不能完全理解业务,照着葫芦画瓢这样的要求都实现不了,只能看着一只西瓜,猜测可能是要一个瓢。为什么开发不能反驳呢,其实也能反驳,但是一切均以时间紧张为由,给糊弄过去。
时间是紧张,但是连磨斧头的时间都没有,砍柴能快吗?几乎后边每个字段,开发都要进行询问、确认,生怕出了一点差错,要返工,更可怕的是重构。
文档质量不佳。更何况工期要求的太紧张了,预估一天的工作量,其实是【早+中+晚】,约摸得有16-18个小时不等。
产品对文档的质量,前期是不怎么负责的,后边在我们的坚持下,才慢慢有了转变。时间,到底是谁浪费的,是非可辩。
以往的套路,是有人写好材料,有人负责写好文档。板上钉钉,需求需要评审,后期开发,想随意发挥都不可以,改动必须要走流程。不可随意。现在规矩全都乱了,没了契约精神,乱了规矩,没什么体统可言,还要什么体系。
3、关于测试
测试没有章法,随心所欲,甚至都不知道怎么测试【注意,产品的原型,是产品自己设计的,产品自己不会测试,天大的笑话】,浪费时间。
没有集成测试,集成测试只有在上线前夕会有一次,然后给甲方领导演示一次。就over了。
开发首先保证自己开发的测通,这完全没有问题。这部分是必须要花费的时间。
4、关于运维与测试环境。
人肉运维不吹不黑。没有自动化运维平台,完全靠人工,部署环境靠人工,发版测试靠人工,打包、测试、发版,更可恨的是忍受一些,不会使用协同开发工具的人,Git不会使用。忍受一下,有着非常不好的开发习惯的内部人员。主程的工作量会大大的增加,合并代码,发版测试,部署上线。这些都是工作量。
加班在所难免。
5、时间安排
每天上班,上午处理问题,发版,改问题,对需求。对需求是最讨厌的。
注意是“对”需求。不是听需求。产品一个理解,开发一个理解,对一下是不是开发跑偏了,如果产品给的文档顺顺当当,开发能理解错?
期间掺杂着讨论,说明,需求压根没有定下来啊!!这是最可怕的。
下午,发版,开发。
晚上,开会,开完会,改开会改的需求,开发下一项。
一天,15-18个小时,就是这样过去的。
这样的项目流程,如果不加班,工期能延长2.5倍。
6、总结
没有标准,都被快节奏冲昏了头脑。等反应过来,一切都晚了。