曾经看过有人根据市场营销策略来谈择偶。大概如下:
进行“自我包装”、
开发“个人品牌”、
确定“目标市场”、
扩大“市场宣传”、
实施“大众推销”、
如何筹划“找丈夫”经费预算、
盘点季度业绩、
评估计划实施成果。
这本书我已经加入收藏夹中前5位,近期准备好好研读一下。
下面说说我的想法。
昨天发了一段摘来的文字:“
男人和女人都很喜欢在自己的人生设一个deadline,比如说:
我18岁之前一定要谈恋爱,
我25岁一定要结婚,
26岁一定生孩子,
30岁的时候一定要有房子,
所以很多决定就很草率。
如果刚开始你找的那个人就不对,往后再怎么努力都不对。
有时候,我们常常会觉得婚结了,所有的问题就没了。
那如果结婚后还有问题,就赶快把小孩生一生。
其实你的问题在这个阶段没解决,在下个阶段只会变大。
”
看了很有感触。
我是干软件开发的。
在工程开始阶段,需求分析一定要做好。
否则后面做的东西哪怕天花乱坠,都是错。
因为不是对方想要的。
接下去是可行性分析。
如果这个需求,根本就做不来。
还是趁早死了心吧。
接下去概要设计也很关键。
因为人与人的理解不同。
对方说的未必是他想要的。
你听懂的未必是他说的。
更别提他想要的。
数字与模拟的转化,必然伴随着数据的缺失。
但人与人的理解,却有可能背道而驰。
将意念中需求转化为规格化的设计。
这是一个统一,一个标准。
双方对其与自己的理念对照。
就算日后对帐,也能说得清楚。
详细设计就是细化概要设计。
具体的统一标准。
最后的编程会依据详细设计进行。
再往后是测试,维护。
一个瀑布模型的软件工程开发周期大致如此。
开始阶段很重要。
如果开始没做好,后面会一步错,步步错。
差之毫厘,谬之千里。
从我软件专业来看择偶的话。
第一,这是一项艰巨的工程。
客户是自己。
开发者一定有自己,也可以结合资深专业人士。
结果是婚姻。
项目启动后,烦恼就开始了。
任何一个环节出漏,都要定位问题所在,解决bug,有可能重新追溯到上阶段。
每一步都面临着返工,全盘推翻和项目崩溃的危险。
而且可怕的是,Delay这个巨大的阴影会随时笼罩头顶。
一旦不能如期release,结果会怎样?
把现在这个毙掉,重新开始下个项目?
还是不停的打补丁,打补丁,艰难地维护直到周期尽头?
无论是顺风顺水,还是历经坎坷,结果成功release了,恭喜你。
但别太高兴。
后面维护更麻烦。
一个做得好的项目,维护起来不会很差。
一个滥项目,维护起来会更滥,叫人悔不当初。
第二,你的付出未必如你所得。
就算每个环节严格把关,兢兢业业。
也未必有好结果。
因为市场资源变数太多。
运气好的话,开发时间不长就很快release。
维护也相当省心。客户满意度也高。
运气不好的话,开发中会遇到很多瓶颈,磕磕绊绊release掉就算不错了。
客户不满意又能怎么样?
第三,需求分析很难做。
要找一个什么样的人呢?
客户不同,需求定位也有差异。
而且还会随着时间,心情,经历等等因素变化。
如果客户自己都不知道自己要什么。
这分两种情况。
一种客户浑浑噩噩,不了解自己的情况,不了解自己的需求,当然更不了解市场了。
“找个什么男人?没想过。遇见哪个算哪个呗!”
这种不挑剔的客户,也许能很快release。
另一种的确不知道自己要什么。
因为要得太多,而且变得还快,一会儿要这个,一会儿要那个。
“我也不知道找什么样的?反正有感觉就行。”
开发者头大了。
“怎么就算有感觉?”
“只可意会不可言传。”
需求分析没法做了。
瓶颈一。
如果客户有明确的需求。
还要分析,这种需求是必须吗?
“我要找......要......不要......”
“你为什么非要找这样的男人呢?有必要定得这么死么?”
“一定一定的!非这样不可!”
这样的客户,把自己限制在条条框框中,也许根本不了解自己真正需要的。
因而错过了很多适合自己的机会。
瓶颈二。
第四,可行性分析不能含糊。
需求明确了。
下一步的可行性分析很关键。
也许客户的需求根本满足不了,那再往后开发也没有任何意义。
“我一定要找威廉王子那样的!或者贝克汉姆类似的也行!”
开发者一定要明白,并非“人有多大胆,地有多大产。”
第四,维护很重要。
维护占周期很长时间。
进行“自我包装”、
开发“个人品牌”、
确定“目标市场”、
扩大“市场宣传”、
实施“大众推销”、
如何筹划“找丈夫”经费预算、
盘点季度业绩、
评估计划实施成果。
这本书我已经加入收藏夹中前5位,近期准备好好研读一下。
下面说说我的想法。
昨天发了一段摘来的文字:“
男人和女人都很喜欢在自己的人生设一个deadline,比如说:
我18岁之前一定要谈恋爱,
我25岁一定要结婚,
26岁一定生孩子,
30岁的时候一定要有房子,
所以很多决定就很草率。
如果刚开始你找的那个人就不对,往后再怎么努力都不对。
有时候,我们常常会觉得婚结了,所有的问题就没了。
那如果结婚后还有问题,就赶快把小孩生一生。
其实你的问题在这个阶段没解决,在下个阶段只会变大。
”
看了很有感触。
我是干软件开发的。
在工程开始阶段,需求分析一定要做好。
否则后面做的东西哪怕天花乱坠,都是错。
因为不是对方想要的。
接下去是可行性分析。
如果这个需求,根本就做不来。
还是趁早死了心吧。
接下去概要设计也很关键。
因为人与人的理解不同。
对方说的未必是他想要的。
你听懂的未必是他说的。
更别提他想要的。
数字与模拟的转化,必然伴随着数据的缺失。
但人与人的理解,却有可能背道而驰。
将意念中需求转化为规格化的设计。
这是一个统一,一个标准。
双方对其与自己的理念对照。
就算日后对帐,也能说得清楚。
详细设计就是细化概要设计。
具体的统一标准。
最后的编程会依据详细设计进行。
再往后是测试,维护。
一个瀑布模型的软件工程开发周期大致如此。
开始阶段很重要。
如果开始没做好,后面会一步错,步步错。
差之毫厘,谬之千里。
从我软件专业来看择偶的话。
第一,这是一项艰巨的工程。
客户是自己。
开发者一定有自己,也可以结合资深专业人士。
结果是婚姻。
项目启动后,烦恼就开始了。
任何一个环节出漏,都要定位问题所在,解决bug,有可能重新追溯到上阶段。
每一步都面临着返工,全盘推翻和项目崩溃的危险。
而且可怕的是,Delay这个巨大的阴影会随时笼罩头顶。
一旦不能如期release,结果会怎样?
把现在这个毙掉,重新开始下个项目?
还是不停的打补丁,打补丁,艰难地维护直到周期尽头?
无论是顺风顺水,还是历经坎坷,结果成功release了,恭喜你。
但别太高兴。
后面维护更麻烦。
一个做得好的项目,维护起来不会很差。
一个滥项目,维护起来会更滥,叫人悔不当初。
第二,你的付出未必如你所得。
就算每个环节严格把关,兢兢业业。
也未必有好结果。
因为市场资源变数太多。
运气好的话,开发时间不长就很快release。
维护也相当省心。客户满意度也高。
运气不好的话,开发中会遇到很多瓶颈,磕磕绊绊release掉就算不错了。
客户不满意又能怎么样?
第三,需求分析很难做。
要找一个什么样的人呢?
客户不同,需求定位也有差异。
而且还会随着时间,心情,经历等等因素变化。
如果客户自己都不知道自己要什么。
这分两种情况。
一种客户浑浑噩噩,不了解自己的情况,不了解自己的需求,当然更不了解市场了。
“找个什么男人?没想过。遇见哪个算哪个呗!”
这种不挑剔的客户,也许能很快release。
另一种的确不知道自己要什么。
因为要得太多,而且变得还快,一会儿要这个,一会儿要那个。
“我也不知道找什么样的?反正有感觉就行。”
开发者头大了。
“怎么就算有感觉?”
“只可意会不可言传。”
需求分析没法做了。
瓶颈一。
如果客户有明确的需求。
还要分析,这种需求是必须吗?
“我要找......要......不要......”
“你为什么非要找这样的男人呢?有必要定得这么死么?”
“一定一定的!非这样不可!”
这样的客户,把自己限制在条条框框中,也许根本不了解自己真正需要的。
因而错过了很多适合自己的机会。
瓶颈二。
第四,可行性分析不能含糊。
需求明确了。
下一步的可行性分析很关键。
也许客户的需求根本满足不了,那再往后开发也没有任何意义。
“我一定要找威廉王子那样的!或者贝克汉姆类似的也行!”
开发者一定要明白,并非“人有多大胆,地有多大产。”
第四,维护很重要。
维护占周期很长时间。