- 主题:可能我真的没法理解挖苦ex这个行为吧
你知道吗？你说话给我的感觉就是：我说1，你说：不，不是这样的，应该是1。
如果说有差异的话，你并没有把重点放在差异上。
【 在 vkisiter 的大作中提到: 】
: 各人自各人活法，这个无需过多说明。
: 只是分享个人看法，从我看来，断就是断，清清楚楚明明确确的say byebye。所有问候都是对现任的挑战。没有所谓的干净和纯洁，无非是几个漂亮的词语去粉饰不为人知的目的而已。
: 还有，生理心理或有强弱，家庭身份位置无分高低。签了合同就规规矩矩做好自己那一份。别整什么妖蛾子。
: ...................
--
修改:MidNiter FROM 221.216.147.*
FROM 221.216.147.*
哈哈，我这类人碰电脑比较多的人比较简单，0就是0，1就是1，
如同写需求规划说明书一样，场景、流程、功能、接口、字段、业务规则、技术指标和约束条件等很多的要求必须明确，不能有岐义和曲解，要评审要确认，不然的话，就没有边界，流转给技术做完之后，客户就会再提这个没有结束，要求再继续免费的做下去。
同样，你知道你的文字给我的感觉是什么？是一个没有边界的描述，只凭意会，而每个人对此的理解可以衍生不同的理解，从我的职业习惯上来看，认为这是一个重大失误。
【 在 MidNiter 的大作中提到: 】
: 你知道吗？你说话给我的感觉就是：我说1，你说：不，不是这样的，应该是1。
: 如果说有差异的话，你并没有把重点放在差异上。
--
FROM 1.202.121.*
我说的不是0和1的事，是1和1的事。你说话有点自说自话，跟人讨论没有说清哪里赞同，哪里有分歧，这不是明晰的逻辑和表达方式。所以，且慢表扬自己。
我不知道你具体干什么，反正你这样的去分析业务逻辑会是个灾难。需求分析首先得会听和理解，然后把理解的客户视角的业务逻辑用开发者需要的规范方式表达，而不是要客户适应你的预设框架。
其中含糊的地方要弄清避免歧义，也要留下足够的灵活性，因为需求确实会变，或者对需求的表达和理解会变，这不可避免。限制需求变化是需要的，但是首先应该尽量理解需求，能尽量抽象，保留灵活性和适应性才是高级和低级架构设计的区别。
【 在 vkisiter 的大作中提到: 】
: 哈哈，我这类人碰电脑比较多的人比较简单，0就是0，1就是1，
: 如同写需求规划说明书一样，场景、流程、功能、接口、字段、业务规则、技术指标和约束条件等很多的要求必须明确，不能有岐义和曲解，要评审要确认，不然的话，就没有边界，流转给技术做完之后，客户就会再提这个没有结束，要求再继续免费的做下去。
: 同样，你知道你的文字给我的感觉是什么？是一个没有边界的描述，只凭意会，而每个人对此的理解可以衍生不同的理解，从我的职业习惯上来看，认为这是一个重大失误。
: ...................
--
FROM 221.216.147.*
还发信息呀
呵呵
看来是和平分手
哈哈哈
【 在 joey220104 的大作中提到: 】
: 虽然有好几个ex，在一起的时间有长有短，分开的原因有的因为我多一些，有的因为ex多一些，有的也没法归类为到底因为谁，但不太能理解直接对ex讽刺挖苦，更别提当面说了。跟不太熟的人都不至于这样，何况相处那么久的身边人呢。
: 我直到现在逢年过节或者平时偶尔还会跟ex们互发发信息，现任也都知道，也会跟ex们讲讲现任的事情，这样大家都挺平和的状态不好吗？
--
FROM 219.143.174.*
厚道人
【 在 joey220104 的大作中提到: 】
: 虽然有好几个ex，在一起的时间有长有短，分开的原因有的因为我多一些，有的因为ex多一些，有的也没法归类为到底因为谁，但不太能理解直接对ex讽刺挖苦，更别提当面说了。跟不太熟的人都不至于这样，何况相处那么久的身边人呢。
: 我直到现在逢年过节或者平时偶尔还会跟ex们互发发信息，现任也都知道，也会跟ex们讲讲现任的事情，这样大家都挺平和的状态不好吗？
--
FROM 116.149.204.*
到底是0与1还是1和1，大家各留各自的观点吧。大家际遇不同，态度不同，讨论个输赢是件没意义的事。
关于需求的理解和输入是前置条件，这个认同，有前才有后面过程部分，但拿时序的倒来倒去，我并不认为这是一个好方法，认同你说的理解用户需求此点，这是每个BA的应知应会，对你所说的保留灵活性和适应性并不认同，因为所有项目基于成本，看钱办事。项目实施不是实验室研究，一切只有一个目利，就是实现商业利益，做活并不是就是对，很多时间的代价往往比保守要大得多，适得其分才是生存之道。
【 在 MidNiter 的大作中提到: 】
: 我说的不是0和1的事，是1和1的事。你说话有点自说自话，跟人讨论没有说清哪里赞同，哪里有分歧，这不是明晰的逻辑和表达方式。所以，且慢表扬自己。
: 我不知道你具体干什么，反正你这样的去分析业务逻辑会是个灾难。需求分析首先得会听和理解，然后把理解的客户视角的业务逻辑用开发者需要的规范方式表达，而不是要客户适应你的预设框架。
: 其中含糊的地方要弄清避免歧义，也要留下足够的灵活性，因为需求确实会变，或者对需求的表达和理解会变，这不可避免。限制需求变化是需要的，但是首先应该尽量理解需求，能尽量抽象，保留灵活性和适应性才是高级和低级架构设计的区别。
: ...................
--
FROM 124.127.220.*
码农同志，您好
【 在 vkisiter 的大作中提到: 】
:
: 哈哈，我这类人碰电脑比较多的人比较简单，0就是0，1就是1，
: 如同写需求规划说明书一样，场景、流程、功能、接口、字段、业务规则、技术指标和约束条件等很多的要求必须明确，不能有岐义和曲解，要评审要确认，不然的话，就没有边界，流转给技术做完之后，客户就会再提这个没有结束，要求再继续免费的做下去。
: 同样，你知道你的文字给我的感觉是什么？是一个没有边界的描述，只凭意会，而每个人对此的理解可以衍生不同的理解，从我的职业习惯上来看，认为这是一个重大失误。
:
--
FROM 113.247.178.*
你的理解力确实有问题，我说的问题在于：你的说法，往往是别人说1，你说不对，应该是我说的1。所以这里的问题是你并没有清楚地分清和表达出沟通中双方观点的异同在哪里，跟别人如何消除分歧达成共识？这对于需求分析是个灾难。我不认为你是个你想让人以为的那种技术高手，因为你脑子不清楚。
【 在 vkisiter 的大作中提到: 】
: 到底是0与1还是1和1，大家各留各自的观点吧。大家际遇不同，态度不同，讨论个输赢是件没意义的事。
: 关于需求的理解和输入是前置条件，这个认同，有前才有后面过程部分，但拿时序的倒来倒去，我并不认为这是一个好方法，认同你说的理解用户需求此点，这是每个BA的应知应会，对你所说的保留灵活性和适应性并不认同，因为所有项目基于成本，看钱办事。项目实施不是实验室研究，一切只有一个目利，就是实现商业利益，做活并不是就是对，很多时间的代价往往比保守要大得多，适得其分才是生存之道。
:
--
FROM 221.216.147.*