项目管理

  • 加班也得慢半拍

    加班也得慢半拍

    前两天和一个期货行业的前辈交流,谈到了当前流行的996以及加班理念等等,他说不应该太加班,一是会影响第二天的工作效率,二是大家都应该多多陪伴家人,并说到了他的团队日常的工作效率很高,不需要通过加班来赶工,还说到他们的系统做了四年了还没完事,我说都做四年了为啥还不着急呢?他说他们的系统很复杂,并且是从无到有做的,很多东西得从头开始,我说类似的量化交易系统像恒生这样的公司都有比较完善的产品了,为啥不买来做定制化开发呢?他说没有系统源码,未来自己接不过来,我说可以在招投标的时候定个硬性条件,就是必须提供源码。他说他们只招...

    项目管理 2019-03-30 297 1 团队996
  • 系统架构设计师知识导图

    系统架构设计师知识导图

    本人一点点整理的软考知识点导图,有利于进行快速整体性回顾,对比记忆,适合想要参加系统架构设计师的软考人士,或对系统架构知识有兴趣的朋友,目前已整理的章节如下,其它内容将陆续推出……,了解更多请关注博主公众号URItker,留言:软考...

  • 架构的权衡分析法(ATAM)及成本效益分析法(CBAM)

    架构的权衡分析法(ATAM)及成本效益分析法(CBAM)

      ATAM的九个步骤:  (1)ATAM 方法的表述:评估负责人向参加会议的项目代表介绍ATAM(简要描述 ATAM 步骤和评估的结果)。  (2)商业动机的表述。项目决策者从商业角度介绍系统的概况。  (3)架构的表述。对架构进行详略适当的介绍。设计师要描述用来满足需求的架构方法或模式,还应描述技术约束条件及与其他系统的交互等。  (4)对架构方法进行分类。通过研究架构文档及倾听上一步的表述,了解系统使用的架构模式和方法(进行明确命名)。  (5)生成质量属性效用树。可以选取这样一棵树:根——质量属性——属性求...

  • 业务需求获取的方式方法探究

    业务需求获取的方式方法探究

    企业管理信息系统项目的实施,无论按何种方式来组织,都必须经历需求分析阶段。因为需求是系统开发的源头,是信息系统开发过程中关健的一环,只有真正弄清楚企业信息化需求的目标和要求,才能做到对症下药、在后续的开发中设计出达成目标的系绕体系构架和实现方式,并且不断改进,使之逐步完善。需求获取是需求工程的第一阶段。对于较大型的开发项目,其复杂性主要来自客观和主观两个方面。从客观上说,需求工程面对的问题几乎是没有范围的。由于企业信息系统的应用涉及企业管理的各个层面和广泛的活动领域,与其管理活动的特征和施行过程的习惯性密切相关;客...

  • 论价值目标

    论价值目标

        通过对两年来的需求开发数据观测和分析,发现需求的质量相差相当悬殊,有的功能上了基本不用,有的投入很大的人力做了效果却很差,有的在时间很紧的情况下上了以后竟然过了很久才使用……这些都是对资源的浪费,资源的最优配置更无从谈起。于是下决心尝试探索价值目标可行性。     这个问题我思考了很久,任何一个理论体系的建立首先是建立在一到两个公理的基础之上,推过推演得到各个维度的定理,从而创建起来一座理论大厦,这在数学和物...

  • SVN服务器迁移实战

    SVN服务器迁移实战

      作为代码管理主流工具,svn的优劣自有程序猿界的各位大拿评说,在此不再赘述。  由于公司使用移动网络的缘故,时不时的出现svn代码管理平台无法上传和更新文件的问题,这对于程序猿来说就好像战场上的战士武器被缴一样致命,如果不是程序猿天生的隐忍和同理心,恐怕会引起异常暴动也未可知,所以移动网络处理不给力,迁移svn平台至内网成为唯一方案,已刻不容缓。  任何一种迁移方案都必须满足几个条件才算迁移成功:1、各历史版本信息要迁移 2、源文件迁移 3、用户要迁移 4、权限要迁移  一开始我想的挺简单,建一个svn服务,把...

  • [转]从关注紧急的事到关注重要的事

    [转]从关注紧急的事到关注重要的事

        黄卫伟 1 9 9 6 年因受华为公司邀请参加 《华为公司基本法》起草,第一次见到 任正非总裁.交谈之中,任总的一句 话给我留下了难忘的印象: "重要的 事情不着急,着急的事情不重要. "从 那以后,在企业咨询中,经历过大大 小小的事情,心里一直在细细体味这 句话的含义.越体味越觉得这是一句 总揽企业全局和决定总裁优先日程的 座右铭.甚至后来读了斯蒂芬·R·科 维 的 畅 销 书《 高 效 人 的 7 个 习 惯 》 (Stephen R. Covey: The 7 Habit...

    项目管理 2014-03-06 954 0
  • 优秀技术型领导的标准

    优秀技术型领导的标准

          最近看到一篇文章,从各个维度讨论什么是好的技术型领导,什么是差的技术型领导,无论是技术型还是管理型,无论是哪个行业哪个部门,其观点多是相通的,在此对其一一做个点评,并借此此自省吾身。 团队合作   一个优秀的技术领导必然是团队的一份子,他们认为当整个团队成功时自己才称得上成功。他们不仅要做好繁杂和不讨好的本职工作,还要清除项目中的障碍,从而让整个团队能够以100%的效率运转起来。一个好的技术领导会努力去拓宽团队在技术上的可行...

1