说的对，如果开始需求设计时考虑了组织机构变化的问题，那就比较简单，如果没有考虑，那就有比较多的修改工作量。
【 在 MyWorkLife 的大作中提到: 】
: 组织架构是树状结构，有些甚至是网状结构
: 如果一开始的需求不够开放
: 有可能技术设计做的不够灵活
: ...................
--
FROM 218.69.75.*

所有的问题都是管理问题。而最直接有效的管理就是以身作则，你如果能打个样儿，那其他人都不再有任何话可说。可以把管理和技术之间的N层瞬间去掉。不在需要瞎猜和勾心斗角。
【 在 omelet 的大作中提到: 】
: 说的好，先给他们打个样
--
FROM 117.133.52.*

为什么要自己做呢
直接买多好


【 在 ohfaint 的大作中提到: 】
: 这里大神多，来这问问。
: 接了个项目，客户的厂区巡检系统，需求就是客户集团有多个厂区，每个厂区有多个设备需要按公司的5S标准巡检。巡检完后打分（设备归属到不同部门），最后再给部门排名，就这么简单。
: 做完第一版后，客户的组织架构发生了重大调整，调整幅度至少在70%以上。在我的理解中，把所有设备的归属部门重新对应一下，设备本身的属性字段什么的都不用修改，巡检操作也不用动，应该是个工作量很小的改动。
: ...................
--
FROM 221.219.211.*

那么问题是：作这个程序的时候，有没有给做灵活性的时间?
【 在 rliw 的大作中提到: 】
: 这输入参数变一下就行
: 程序架构又不动。
: 如果程序架构连这点灵活度都做不到
: ...................
--
FROM 111.196.134.*

作的时候说：赶紧出活。
等遇到问题说：程序需要灵活

灵活是天上掉下来的么？
【 在 rliw 的大作中提到: 】
: 一般老司机都会习惯性这样搞冗余吧。
: 比如要算1+2，
: 简单的会直接printf出结果，
: ...................
--
FROM 111.196.134.*