随笔分类 -  潜伏中思考

摘要:对项目进行需求调研后期,需要分别对功能需求和数据需求进行调研数据需求就是如果客户之前采用其他的软件产品,上了我们新的项目后需要数据移植或无缝对接时的需求很多项目在后期的失败就是没有重视甚至没有进行数据调研导致! 阅读全文
posted @ 2012-01-16 14:04 倪不鲁 阅读(94) 评论(0) 推荐(0)
摘要:在设计产品和项目产品化时以期望或需求的增量为版本,每个版本按照先启到交付的计划开发最重要一点,每个增量版本都作为一个版本的产品模型保留,日后做本地化开发时,项目组可根据不同的需求选择不同的增量版本。 阅读全文
posted @ 2012-01-16 09:28 倪不鲁 阅读(94) 评论(0) 推荐(0)
摘要:通过期望报告得出的期望点,汇总出最底层的核心平台架构。而后其他的需求功能与后期的新需求都以APP形式在此平台上新增,是规避需求变更风险的一个方式。可以参考wojilu的架构图 阅读全文
posted @ 2011-10-31 21:35 倪不鲁 阅读(155) 评论(0) 推荐(0)
摘要:在带百万千万级项目中,切记要坚持迭代开发原则,并且做到每次迭代的每个任务部分完成后都要封版进行测试,而不是最后快上线了才集中测试 阅读全文
posted @ 2011-09-26 15:13 倪不鲁 阅读(132) 评论(0) 推荐(0)
摘要:数据模型基于数据流动来设计业务模型基于业务领域来设计业务模型封装层做好缓存处理把握以上三点,业务架构设计迎刃而解 阅读全文
posted @ 2011-09-13 15:34 倪不鲁 阅读(101) 评论(0) 推荐(0)
摘要:在项目管理过程中,有时候一周多花一小时做出二维表,很可能在项目进度与成本把握上提高50%的成就,任何说项目XP开发,不需要任何管理模式和所谓的文档的言语都是偷懒的借口。千万不要偷懒。 阅读全文
posted @ 2011-08-17 11:39 倪不鲁 阅读(95) 评论(0) 推荐(0)
摘要:软件项目产品化建设的关键在于 1)中视用户体验,操作不要过于复杂 2)跟踪调查用户行为,不断优化体验业务的产品化主要应当将业务单元拆分,分离出不同的业务领域,从而提炼并搭建起服务,这才是关键,而不是将整个系统进行所谓的整体业务产品化整理,之后还按照项目模式搭建解决架构。 阅读全文
posted @ 2011-08-10 14:45 倪不鲁 阅读(118) 评论(0) 推荐(0)
摘要:绩效制度的首要作用应当是对人力成本与变更成本的把握,其次才是对员工工作的考核。 阅读全文
posted @ 2011-08-10 14:19 倪不鲁 阅读(131) 评论(0) 推荐(0)
摘要:简约直接,并且不会让员工产生反感的绩效制度和一个具有竞争力和吸引力的奖金政策是一个公司人员稳定的必要条件 阅读全文
posted @ 2011-08-10 14:02 倪不鲁 阅读(102) 评论(0) 推荐(0)
摘要:基于数据流动的数据模型设计思想:任何系统的数据模型设计都离不开两个类型的设计---实体类型的数据模型与业务动作类型的数据模型。其中,实体类型的数据模型基本就包含两部分,一部分是静态不变的信息,另一部分是可变信息,可变信息一般只add不update,这样他也可以作为操作日志来使用,并且可以适应任何和基本信息相关新增需求。业务动作类型的数据模型说白了,就是记录的被弄的目标(object)被从哪地方(source)弄得到啥地方(target),咋弄得(category),谁弄的(oper),什么时间弄的(updatetime)。基于此设计,可适应大多数需求变动与业务。并且更适合DDD思想中业务实体的 阅读全文
posted @ 2011-08-09 16:30 倪不鲁 阅读(135) 评论(0) 推荐(0)
摘要:项目需求调研初期,一定要与客户协作确定整理客户期望报告,并将期望划分层次以此来决定接下来的迭代计划,在项目一期设计开放过程中牢记只满足客户的期望底线即可。 阅读全文
posted @ 2011-08-05 16:19 倪不鲁 阅读(118) 评论(0) 推荐(0)
摘要:一切项目都要以满足客户的基本需求期望为前提,在满足这个前提之前,不考虑任何花哨的交互,牛逼的架构以及华丽的界面。切记,项目的v1.0版本永远是简约风格的,其他一切都是v2.0以后的事情,这是大多数项目或技术leader会忽略的事情。 阅读全文
posted @ 2011-08-02 17:12 倪不鲁 阅读(122) 评论(0) 推荐(0)
摘要:在打算做一个新的职位之前,一定要把该职位所有职责用列表形式列出来,分清那些是主要职责,哪些是次要职责,哪些职责承担多少。再看每个职责是否超出自己的能力范围,最后检查自己的能力胜任几个主要职责,多少个次要职责,我想,最后你就会清除自己是否可以真正胜任此职位。 阅读全文
posted @ 2011-08-02 15:27 倪不鲁 阅读(114) 评论(0) 推荐(0)
摘要:在UML设计时,要细化到涉及人每一个操作的最细化动作,通常为一个功能页面的每个按钮功能,这样可以根据其设计最上层业务层接口和提炼服务时的依据。 阅读全文
posted @ 2011-08-02 11:12 倪不鲁 阅读(97) 评论(0) 推荐(0)
摘要:在项目技术方案架构设计时,一定要建立系统字典表,避免常量以及类别等分散到各处。 阅读全文
posted @ 2011-08-02 11:12 倪不鲁 阅读(111) 评论(0) 推荐(0)
摘要:如果项目由多系统构成,各系统之间数据交流频繁,在设计初期,应化较长时间整理系统之间的交互需求,通过UML方式详细记录。并做系统之间交流提炼出可共享可复用的service接口设计,重要的是设计接口以及数据协议。(服务接口设计为先) 阅读全文
posted @ 2011-08-02 11:05 倪不鲁 阅读(101) 评论(0) 推荐(0)
摘要:做项目,先解决从无到有问题,如果无迭代设计,采用先出可交付东西,哪怕很简陋。剩下的问题属于与客户交流时技巧,例如告诉客户打算征求客户意见,公司美工正在做美化,客户可提出可随时定制。(从无到有) 阅读全文
posted @ 2011-08-02 11:04 倪不鲁 阅读(107) 评论(0) 推荐(0)
摘要:1. PM必要知道组内成员的薪资待遇,再分配工作时候,根据项工作垃圾重复程度安排合理薪资成员完成,以保证项目组成本的合理化。简单例子,比如需要开发一个B/S的ERP系统,页面布局都很复杂,这样软件工程师不要考虑页面布局问题,只需要把所需控件摆页面上,然后完成逻辑功能。专门一个低成本的人员来做排页面工作。简单的方式,很少有人采用。往往用项目紧为借口,全员纵向开发。(多钱人干多钱工作) 阅读全文
posted @ 2011-08-02 11:03 倪不鲁 阅读(115) 评论(0) 推荐(0)