水木社区手机版
- 主题:到底是我要求高，还是他们水平渣？
- 这里大神多，来这问问。
接了个项目，客户的厂区巡检系统，需求就是客户集团有多个厂区，每个厂区有多个设备需要按公司的5S标准巡检。巡检完后打分（设备归属到不同部门），最后再给部门排名，就这么简单。
做完第一版后，客户的组织架构发生了重大调整，调整幅度至少在70%以上。在我的理解中，把所有设备的归属部门重新对应一下，设备本身的属性字段什么的都不用修改，巡检操作也不用动，应该是个工作量很小的改动。
结果写代码的兄弟说工作量非常大，几乎“相当于重新弄一遍”。
虽然本青没有实际写过项目，好歹excel里搞点对应，引用之类的还是不成问题，我特么的就真无法理解了。
忘了说，是.net技术，不是java
以下记录每个我觉得很坑的内容。
==分割线==
6月20日：刚发现代码哥又挖了个坑：
如果巡检小队人员变化了，巡检任务要重设，而不是增减了人员任务继续有效。
业务逻辑是这样的，一个巡检小队比如4个人，当天任何1个或几个人共同完成所有的点位巡检，就算任务完成（这样就可以不考虑谁休息谁请假的场景）。
我感觉就是一趟公交，不管上下多少人，不影响这趟公交本身啊，从用户角度讲是不是这个理？
再从程序角度讲，这个难不难实现啊？
==分割线==
6月20日：刚又发现一个坑。
人员信息导入，只能导增量，不能修改存量。比如张三在A部门，现在A部门拆分成BC部门，张三归为B部门。那么想改的话，只能手动，一个一个改。把张三在表格里的部门改为B，重新导入不生效，除非是新来的员工李四，系统里没有存在过的，才行。
看了下，大概有200多个。
==分割线==
6月25：系统里有两个地方可以修改人员手机号，而且改一个另外一个不同步。
==分割线==
6月26坑：设备归属从A部门调整到B部门，它的检查内容清零，需要后台重新设置。真是强行给自己增加工作量。
==分割线==
7.1坑，无操作日志。好几个管理员谁乱删了数据不知道。
==分割线==
7.3日坑，一个巡检计划，3个人从1号开始循环执行到月底。比如到5号的时候来1个新员工，不能在该计划里增加人员，只能把原计划删除，再从5号开始制定一个新的4人计划到月底。更奇葩的来了，原来的3人计划要一条一条删除，每天1条，不能一次性作废。
--
修改:ohfaint FROM 125.70.78.*
FROM 125.70.76.* - 我理解这部分变动就是excel导入一下的事，根本用不着动代码，实施人员就可以完成，结果还花了大概两天。
而且做成这种方式，可扩展性非常好，下次再有调整也不怕。
【 在 hothail 的大作中提到: 】
: 自己都说了
: “客户的组织架构发生了重大调整 70%”
: 这部分变更基本就是重做啊
: ...................
--
修改:ohfaint FROM 182.138.156.*
FROM 182.138.156.* - 小作坊，我的疑惑就是组织架构调整能不能做得非常便捷，仅excel导入就可以方便地修改，这事应该不难吧
【 在 foliver 的大作中提到: 】
: 对于一个领导来说，最重要的就是要了解自己团队的研发能力。你们的设计师架构师呢？
: 总体来说，出现偏差，要么换人，要么听从建议。光你自己认为是没有用的。
:
--
FROM 182.138.156.* - 你可能讲到关键了。
那么还有一个情况需要说明一下，这公司不是第一次做这种项目，事实上已经有十来年的项目经验。拿以前的代码改改抄抄，也不至于这么弱。或者说这么多年就一直这么过的(￢_￢)
还有一个细节把我整笑了。我提了个xx改进之后写代码的哥们儿说，这个点不会改了以后也用不上。
以我有限的编程知识，越模块化的以后越方便维护升级对不对。
除非是那种网传的段子，就是越容易维护的代码，公司开掉你代价就越低，所以有的人故意整得只有自己能搞。
【 在 chglele 的大作中提到: 】
: 做这个系统之前，有没有把需求讲的很清楚，说可以动态调整这种匹配关系。解决一个问题有很多种方法，有时候为了快，糙快猛很可能就没这么设计，现在需求变更，就是需要重新搞
: 发自「今日水木 on iPhone 12」
--
FROM 182.138.156.* - 甲方是传统企业，信息化程度很低，他们只提功能方面的要求，怎么实现不会管。
但是要调整下什么组织架构，新增几个人员开通对应角色之类的实施工作就得我来，让人无语的是新增组织架构都是人工一个一个手动添加的（后来在我要求之下才增加了导入功能）。我对这种打着信息化旗号自己却干的刀耕火种的事情相当无语。
【 在 hothail 的大作中提到: 】
: 做成什么方式是应该是甲方要求的，当时也是认可的吧。
: 怨也只能怨需求没写清楚
: - 来自 水木社区APP v3.5.7
--
FROM 182.138.156.* - 那我说下实际情况，这也是客户信息化水平低，和我们经验不足导致的“组织架构调整70%”。
就是最开始找客户拿组织架构的时候，靠他们一个人手写给我们的。
最后系统准备验收的时候，发现客户一直沿用的报表和系统里的部门大部分对不上，所以都得推倒了重来。
如果最开始直接找出报表的人拿数据，就没这事了(￢_￢)
【 在 blackhill 的大作中提到: 】
: 就你原帖这个情况，怕的不是组织架构里数据发生调整，怕的是组织架构的形式发生变更，那么如果之前数据结构设计时考虑的简单了，没有兜住更通用的可能性，就会涉及到数据结构的调整，这确实是大活。
--
FROM 182.138.156.* - 这就是我的疑惑之处
【 在 ggym3 的大作中提到: 】
: 巡检系统与组织架构变动应该没有太大的联系，，只是把巡检点的归属重新调整一下吧。就是调整数据库表格内容而已。跟重写没太大关系吧？
--
FROM 171.213.48.* - 看，我担心的事情就呼之欲出了。
马上系统会往更多部门更多内容推广，写死之后扩展性太差。
【 在 MyWorkLife 的大作中提到: 】
: 组织架构是树状结构，有些甚至是网状结构
: 如果一开始的需求不够开放
: 有可能技术设计做的不够灵活
: ...................
--
FROM 118.112.57.* - 刚发现代码哥又挖了个坑：
如果巡检小队人员变化了，巡检任务要重设，而不是增减了人员任务继续有效。
业务逻辑是这样的，一个巡检小队比如4个人，当天任何1个或几个人共同完成所有的点位巡检，就算任务完成（这样就可以不考虑谁休息谁请假的场景）。
我感觉就是一趟公交，不管上下多少人，不影响这趟公交本身啊，从用户角度讲是不是这个理？
再从程序角度讲，这个难不难实现啊？
对这哥们儿的脑回路无语了
【 在 ggym3 的大作中提到: 】
: 程序应该有自行业务调整功能，这个功能我们单位在10多年前就实现了。随着业务调整，人员调整。巡检点也跟着调整。首先巡检点本身不动，增加个表格，实现人员对巡检点的一一对应就行。不过巡检点多的话，调整的比较慢而已。
: 现在是电子围栏式巡检了，巡检点巡回的方式已经落伍了。
--
FROM 118.112.57.* - 今天的两个坑，补充在主贴了
【 在 hothail 的大作中提到: 】
: 上公交时侯，人也要上楼梯
: 有了系统，有时候人和组织也要进化的
: 希望继续后续报道，喜欢看
--
FROM 118.115.195.*