我要介绍的项目参与项目的人员比我高几层.
一般要求是基于Web的问题管理系统.该系统是更大项目的一小部分.
领导下午有一个技术人员应该处理这部分项目.领导下午问我,帮助信息是否正常,不在请求帮助的位置.领导下午提供有关网站的反馈,并希望模态对话框等错误消息,并希望我看一看.我正在看系统,我在想......
一个新的应用程序是在冷融合开发的!？!？
应用具有极其数据验证不佳
应用程序数据验证页面导航远离数据输入表单
应用程序帮助页面导航远离表单
开发人员和pm之间没有讨论db模式
没有讨论db模式,因为它不存在
有一个菜单页面 - 即一旦你去一个页面,你必须回到主菜单,然后转到你想要的下一页
导致pm不知道dbms是什么...
有一个技术下午,她不知道什么是dbms ...
领导下午想要解雇技术pm很长一段时间,但技术下午受到保护......
导致pm表示,在几个专有项目中存在所需的确切功能(其中一些是开源的 - bugtracker,bugzilla等),但技术pm和开发人员不会听.
我有两个问题？
我
解雇开发？
解雇技术人员和保护她的人？
火导致下午？
为他们下载并配置bugtracker/bugzilla,然后解雇所有这些？
为他们下载并配置bugtracker/bugzilla然后去喝啤酒以忘记我的悲伤？
并且不是在项目的早期就讨论和严格考虑db模式的SOP吗？
编辑:
我曾经与各种各样的客户合作,他们拥有不同程度的技术知识(和智能).我总是和利益相关者讨论db模式.如果他们不知道架构是什么,我会教他们.如果他们没有理解的背景,我仍然会与他们讨论架构 - 即使他们没有意识到我们正在谈论架构.在我直接参与的大多数项目中,数据是系统中最重要的部分.彻底挖掘模式/域模型对于深入了解系统以及可以执行和报告的内容至关重要.我非常重视关于SO的海报的意见.值得注意的是,我的方法不是通常的做法.
顺便说一句 - 令人遗憾的是,该项目使用纳税人资金而IT部门是与着名大学的合作......开发人员和技术人员都是长期雇员 - 他们并非缺乏经验.当我知道那些失业的聪明而勤劳的人和那些像这样的人一起工作时,我感到特别难过.
当我年轻的时候,我会在链条上报告这种无能,并期待采取适当的行动.现在我已经处于连锁状态,我发现自己不想微观管理其他人的责任.
我的决心是喝两瓶啤酒,然后回到我的职责......
好的,第一件事,回答你的问题:不,不,千万不!用户不是你应该讨论db schemata的人; 一般来说,你也要和奶牛讨论微积分.即使他们具有技术背景,下次需求变化时又如何; 他们应该参与架构更新吗？
更一般地说,这听起来像是技术主管让问题与"客户"或利益相关者脱节的情况.如果你被要求实际上解决这个问题,我建议你需要建立某种形式的图形用户界面原型,甚至只是一个故事板,并通过走那.然后你会知道事情的立场.
扩展:是的,讨论项目中的DB模式是正常的.我要说你确实需要认真思考一些主要的咨询方式.
扩展更多:我理解你的观点,但问题是数据库模式是一个实现细节.我们已经习惯了数据库,我们让自己失去了对它的追踪,并最终得到了看起来像数据库的应用程序.但数据库不是提供客户价值的东西; 客户是否可以做他们想要的事情.如果您将客户看到应用程序的方式与数据库模式联系起来,那么您将它们绑定到一个实现; 为了使系统更加高效,更改(例如非规范化表格)会成为您必须向客户展示的内容.最好向他们展示观察结果,并将这些细节留给自己.
但我怀疑我们也有一个术语冲突.我会就"域名模式"与你达成一致.如果,通过db模式,您只是表示在用户的系统视图中可见的那些表和关系,如果您愿意,则使用"用例",那么我们将同意.
京公网安备 11010802040832号 | 京ICP备19059560号-6 
