证明一件事其实是很难的

法律貌似是说谁主张谁举证. 但是如果只是推断和臆测是不可能得到正确结论的. 但即便如此,只要有人认准了,别人却很难改变他的观点, 只能依靠时间来揭开这个难解之谜了.

其实如果有一些起码的信任,有些事不需要证据也会觉得是个错误的判断. 总之, 太难了, 尤其是要证明你一个人每一个时间点都有证人证明. 时间越久越难. 而一点有模糊的地方,就会增加错误的判断.把结论向错误的方向推动.

如果能换位思考,会怎么样呢? 这个只能是假设,因为不可能真的换位, 所有的思考都是基于自己的出发点的。另外人做事不都是有目的性、一直很清晰的,又不是高考考试那个装态. 实际上, 就如同那个老套的恐怖故事一般,能看懂的都是变态, 但也有的事先知道答案的,冒充一下变态的啊..  可是这个就很难证明了, 即使他说看过这个故事, 如果考察者只依据回答, 必然会判他死刑了.  很悲剧的就是一棒子打死好了, 我有点理解 为什么文革时候 冤假错案多了.  有些事太难证明了.

尽管说的是句句实话,但是却不一定所有人都这么认为, 相信的人可能他也是一直如此, 不信的人可能他也喜欢对人说谎, 还有和你建立了坦诚的人也会相信你的每一句话,即便是你说了轻微无害的谎言或者十分严重的谎言, 这就是信任。
上学时好像学过可信威胁与不可信威胁, 信任其实也可以分类, 有威胁信任, 无威胁信任, 日久就可以分辨出来. 很难短时间分清.

Read More

项目的不同生命周期需要不同的流程.

很长一段时间 总是以完成功能为目标, 没有太担心其他的事情. (无知者无畏)  随着项目的上线,才发现还有很多被遗漏了的工作没有做.  比如自动测试.
随着时间日益紧迫,愈发的 凸显出程序测试的重要性.  没有这个为保证, 很难在经历了很多次代码修改后,依然保证所有功能都是ok的. 当然这不是要替代人肉测试.
毕竟人更强大一些.

题外话, 我想目前我们的团队可以着手进行这方面的工作了. 因为项目的生命周期决定的, 在没有非常多的功能开发工作情况下, 每一个bug的修复都是那么的微妙. 稍有不慎 就会带入更多的bug. 而谁都无法承担这样的bug带来的 客户流失的责任.所以迫切需要加强. 规避风险.其实一直以来的一个忧虑就是如果开发测试代码的时间与功能代码的时间冲突的话,或者说超过正常功能的时间的话, 也会是一个问题, 貌似很多人眼里认为, 测试部分的时间不是开发时间噢.
之所以说项目周期决定的,也是因为时间的安排问题, 以前不可能有这个时间从零开始进行这个实践工作, 而且还可能会打乱现有的工作流程.  影响工作效率.

这是这么些年来,感受颇深的一点, 没有代码测试而进行的项目是多么可怕, 单纯依赖用户反馈 只能是一直处于被动. 而同时就可能流失了很多用户.  当然也得把功能做出来, 功能都没实现 就去考虑怎么测试 也是没有意义的. 测试再好, 功能没实现有毛用.

如果在同一个地方跌倒, 真的也需要怀疑一下自己的搭档了.  有没有无休止的重复修改?  有没有一直重复出现的错误.   这些年,我似乎一直在发现问题,然后想办法修正..  如果有人能早一点告诉我什么样的才是完美的, 多好.  不知道是我聪明,还是我们缺少一个睿智的领袖.   如果能有机会与业内先锋多多交流就好了.  咨询公司是做这个的吗?

领袖有一种是:不停的问下属, 然后做选择题.  还有一种领袖是让下属做选择题.  我更喜欢后者. 因为后者会更有生命力, 而前者只会让一切更加混乱, 不是所有事情都可以 通过民意调查 选择出来的,  一个团队需要一个睿智的人引领方向.  最好是带领了所有的人, 而不是踩着所有的人上了船..其实还有第三种,不闻不问者,只有在表彰会时才会出现.. 其实如果是在征询了下属的意见以后再结合之做出决策的话,也算不错. 第一种说的是纯不动脑型。

Read More