个人对技术的追求:代码少而精捍;思路清晰美观;可扩展好维护;技术驱动商业; 人生格言:只要你有信念,有追求,并且坚持,那你一定比随波逐流,行得远行得正...
我曾所在的两个项目组,如果处理不好“不”,则会给自己和团队带来很多问题,发生在我身上也有好几次。 项目组A:在不看好项目组开发方法的情况下仍旧敬业工作。 我在项目组A曾经担任过开发人员、开发经理和项目经理,我也在这个项目组投入了很多精力,它给了我很多成长环境,包括现在看到的OpenExpressApp 的思路以及对架构方法的兴趣也都是从那里一点一滴积累思考而来的。
在为企业做流程管理项目的时候,我们经常会反复的给企业流程经理灌输这样的一种思想:流程管理,并不仅仅是把流程图画出来,装订成册就结束了,流程管理其实可以做的更多。流程管理实际上是一种建立在流程基础上的管理体系,是从流程入手,借助流程这个平台将各种管理方法结合在一起的管理模式。
如果有一种方法能使你的软件缺陷率降低63%,核心缺陷率降低79%,整体投入减少62%,整个项目开发的时间缩短69%,你会采用这种新的软件开发方法吗? 在回答这个问题之前,你可能会问:是什么方法能达到这样的效果?答案是:敏捷开发。
由于国内外软件土壤差别巨大,适合国外的一些理论在国内不一定行的通,而国内的一些资料往往都是根据国外的资料直接搬过来用的,这也直接导致国外的软件架构师在国内变得水土不服。今天本篇随笔的内容则是在一些培训资料的基础上,加上自己的思考,总结出来的适合国情的软件架构师职责范围。
有段时间没有更新技术blog了,现在有空每天都写写围脖,记录生活和工作的点滴,但是有时候发现有些技术的想法和工作总结没有像过去那么完整的写很大一篇,但是也有零零散散的不少点滴,因此想着随意的写这么一个连续的片段分享。
需求管理是软件开发全生命周期重要的一个环节,我们每个人都知道它的重要性,但是要真做做好并不简单,我也写了一本在线电子书业务分析与需求.pdf来讲解需求相关内容。对于每种技术和方法,就像以前我写过的企业架构成熟度模型(EAMM)的一样,我们都不可能一下子就精通,而是按照一种学习的曲线进展,本篇本篇主要介绍一下需求管理成熟度的六个级别。
前言:之所以有此一文,不是空穴来风,也不是故意的哗众取宠,而是最近的一些所见,所感。在本文中总结出来,希望对大家有帮助。 因为一些工作原因,其他的系列文章没有接着写下去,还望大家见谅。 不要成为代码的机器 开发人员的事情就是coding,没日没夜的coding,而且大家都是这样在coding,但是效果和结局就不一样:有人coding了N多年,技术还是原地踏步,编写出来的代码还是bug连连;有人coding就变成了技术骨干,甚至有人成为了CTO, 架构师等。
我们在业务流程管理(BPM)领域里摸爬滚打已经很多年了,最近看到人们对它的关注不断提升,这是非常有趣的一件事。对这一趣事儿起催化作用方面的有,工具的日渐成熟、新BPMN2.0规范的形成、以及更多更好的相关出版物带来的人们对BPM的进一步理解,它们代表着BPM领域内最重要的进步。
简介 作为架构师和设计者,我们常把手头的事情作为工作焦点,很少反思过去如何。我们应该温故而知新。我从作为skype架构组领导的55 个月经历中总结了6个经验。其中一些是技术性的,另外一些是架构师较为软性的观点。
MSF,MicrosoftSolutionFramework,微软解决方案框架是一个在预算范围内按期创建一个业务解决方案需要一种经过检验的方法。 本文将结合MSF在项目管理中的实际应用进行讲解,如果您是软件项目的参与者,如项目经理、开发工程师、系统架构师、顾问、质量管理人员等,想找到项目管理中遇到问题的解决方案,相信本文会给您一定的帮助。
周六又被老板招呼去开会,烦!在会上,老板说要对我们软件部实施绩效考核,并要求我们几个项目经理在一起商量下,把具体的实施细则给敲定下来。结果我们几个经理们在公司会议室一直讨论到晚上八点多才大体弄出个实验品来,准备周一就开始在软件部开展实施。
引言 前两天一个朋友给我打电话,问我如何估计项目开发时间。对此我很诧异,问他以前他们是怎么估计的,他说以前基本都是大家开个会,大约都说说自己意见,最后负责人一拍脑袋,给出一个时间。不过这次遇到一个非常认真的客户,要求不但要估计出项目开发时间,还要明确说明具体的依据和估算方法,这下我这朋友有点犯难,才询问我。
如何将项目的开发掌控好是技术领导(Team Leader)必须做好的。何为掌控项目的开发,即开发的进度和质量在计划内,不在期限快到时慌手慌脚,也不需交期到时天天加班,更不能删减测试时间。总而言之,就是开发工作有节奏,按部就班到达预期目标。
中国人性喜围观,然而在中国,大部分新闻并没有围观的价值,这未免让人失望。但是,只要是加上“唐骏”这个名字,新闻总是能让我们围观者觉得值,觉得得到某种满足,从这一点上来讲,唐骏牛!真的很牛!! 这一次,唐骏给大家带来的是“假文凭事件”,整个事件的发展,真是一波未平一波又起,可谓波澜壮阔,最后发展成为事关“诚信”的大事件。
前几天跟朋友聊天时,朋友说他刚刚从一家知名软件公司面试出来,朋友去面试的是一家公司的技术管理岗位,所以在面试的时候被问及的问题也偏重于技术管理方面的问题,在与朋友的聊天中将这几个问题归纳了一下,大致归为如下几个问题。
设计师不等于美工 设计无所不在,但大多数企业不知道如何使用它。现代设计进入中国大概是二十多年的时间,而在国外,尤其在美国在欧洲,大概有一百年的历史。二十多年前中国是没有人讲用户体验这个词的。那个时代讲究技术和美术的结合,叫技术美学。
一个项目中需求调研的充分与否是项目日后成败的关键要素之一,这一点我想没有哪位项目经理不认同吧?不过咱说的需求调研可不只是拿张纸记记客户说什么就完了,调研顾名思义就是调查和研究客户的想法,我感觉应从以下几个步骤入手: 1、客户想要什么? 2、要这干什么? 3、为什么这么想? 4、会不会有别的想法? 这里也说一个最最最最基本的,只谈项目别谈钱,我们可以说,价钱嘛需要我们回去详细的分析过您的需求后再给您提供一个整体的解决方案,您放心价钱一 定合理,不会超出您的预算(真超了再说)。
IT项目中,我们最恐惧什么? 项目中止?不是,因为对于尽心尽力的我们而言,“项目中止”很少是因为咱这些苦哈哈,也许是财务危机、也许是项目的必要性已不存在、也许仅仅是无限期的延迟。 所以,这里我们讨论的是:一个正在执行的还算正常的项目进程中的事情。
最近有不少朋友写信问我一些关于团队开发的问题,由于这段时间有些忙,没有回复.今天写一篇这方面的文章向大家介绍一下我是如何带领团队开发工作流项目的 关于团队建设,项目管理的文章网上已经有很多了,在这里我就不谈这些理论了,直接给大家展示一个我在 项目开发方,后台服务开发方式,前台UI开发方式,...
在一个老团队中,推行一项新的实践是非常不易的。 如果要求,每天10点站立会议增强团队成员之间沟通。大家会心里先衡量一下,恩,不就是每天站个十几分钟,自己说几句话,然后听别人说嘛,不难做到。
大学里跟老师做的项目几乎没有一个是按时间完成,都是在拖时间,一拖再拖,每次老师初步地估算这个项目需要多少时间,我脑袋里都下意识地想(老师估算的时间*2,或*3,或者更多),其中最糟糕的一个项目估计用一个月,结果用了一年才勉强结束,实际时间=估算时间*12,我的天呀,当时估计也就是学校这种地方做得出来。
前面说到过,刚开始带小组,接到一个任务,我就估算了我大概要多少时间,然后小组多少个人就算是多少个我,估算时间=我要的总时间"小组人数(好笨的想法呀,不用时间跟组员交待任务的吗?个个组员都是我吗,比我强的还好,顶多做完了休息,差一点的就麻烦了),结果实际时间多了很多,而且小组里有的人做完了无事可做,有的人则忙得焦头烂额,容易打击组员的积极性,造成组员之间的不满。
我们知道现在的软件开发最大的问题就是变化,其实这也不是软件本身的问题,我更觉得是软件的特点。因为他不像建筑,画个建筑图,一般不会偏到哪里去。然而很多需要软件的人,他可能希望软件能达到什么目的,至于具体是什么样子,他自己也不知道。
一个公司宛如一只球队,成败不是一个人的事情,是一整队的事情。那么球队在某一场具体比赛里面最重要的角色是哪一个?不是教练,如果说整个赛季如何可能是教练的功劳。如果是某一场比赛,最重要的角色是中场。对于公司也有这么一个中场的角色,不过不是老总,而是具体的那个产品经理。
公司要我给项目经理做一个培训,关于项目经理的做事情的方法和观点方面。我就采用了Workshop的方式,Workshop不是会议模式,而是侧重于交流会谈的一种模式,毕竟大家都是项目经理,并非说我的做法就是对的,所有的一切都是自己的经验之谈,所以我只是说大家彼此分享经验,交流心得。
Donald Knuth说“过早优化是万恶之源”(premature optimization is the root of all evil)。这话也许有些夸张,但“过早优化”的危害我觉得不能忽视。
自2007年参加工作以来,参与的项目也有好几个了,但都是以项目成员的角色参与,从来没有以项目经理的角色参与项目。中国有句古话叫“旁观者清”,同一个问题站的角度不同,可能会形成不同的结论。下面我就以一个普通项目成员的角度谈一下对项目管理的几个看法,希望大家给予指正。
最近在带领一个异地的团队在进行.Net B/S系统开发工作。两地相隔1000多公里, 两地都有开发人员,源码的统一管理就成了需要解决的问题。针对这个问题,想到如下的解决方法: 一、利用Microsoft Visual SourceSafe的Internet功能 优点: 1.考虑使用VSS是因为他与Microsoft Visual Studio集成的很紧密。
中午吃过了午饭,端着杯茶做在休息室里正稍稍休憩。公司内部特别开辟出一个空间,并装修成吧台,高脚转椅,微高的台面和酒吧里面的样子多少有点类似。不少人见过微软、google的office的专修格调,让多少人羡慕而又渴望。
估计绝大部分的公司都在提倡一个口号:“注重细节。”但是往往是口号容易喊,行动却是千辛万苦,何谓细节?也就是自身工作的每一个环节、每一道流程的琐碎小事,而这些小事又常常容易被人忽略。有很多人有雄才大志,内心中充斥着舍我其谁的非凡气魄,但其眼高手低,小事不屑,大事难成,最终只落得一事无成的悲哀。
超仔刚刚推门进来,屁股还没有碰到他的椅子上已经让人感觉到他欢喜轻飘的神色,我抬头望着他眼睛,神色中洋溢的满是欢快。我看着他那兴奋的样子,微微笑着问道:“签完了?结果还可以吗?” “还不错!” “能满意就可以,继续努力。
这篇文章是我的一个外国的同事Gareth推荐给我的,我和他一起工作过一段时间。他之所以觉得非常不错,是因为这篇文章让他身有体会,他觉得我也一定会有体会,并让我考虑一下翻译到我的blog上来。我看完后觉得很有代表性,而且觉得说得太对了,所以翻译过来,希望大家都读一读,最好转给你的公司老板。
要成为一个好的项目经理需要学会逆水行舟。虽然顺水推舟有时也能到达目的地,但学会逆水行舟,你才能到达任何地方。 “虽然很有道理,但我认为现实不允许,很多项目都有规定的期限。中途还有给客户演示效果,往往实际项目中都是按最后上线日期来进行项目规划管理的。
1:使用分布式的版本管理系统 如果你觉得不需要使用版本管理系统,那我们沟通会有代沟,如果你是cvs、svn的粉丝,或者由于某种原因没有使用过分布式版本管理系统,比如git,那强烈建议你去看一下“why git is better than x”。
“不可能的;有难度的;你懂不懂技术的;这个功能要放在二期才能做;要做可以但需要时间;把那个项目停掉我就给你做……”,如果经常听到技术这样说,那你的产品很有可能已经被技术绑架了,接下来你想再多的功能,只要技术说不可以那就没戏。
错误一:错误的需求调研阶段,导致很多项目永远无法结束! 在软件行业,在界面设计没有正式展现给客户之前,所有的工作都处于需求调研阶段。其实建筑行业已经给我们做好了先例:客户买房子之前是先要看看样板房和模型的,什么都看不到,这房子你敢买么?除非你不是自己住!而在我们所学的软件工程概念模型中,这是三个阶段:需求调研、需求分析、概要设计。
最近做的一个项目从需求分析到上线绵延了四个月之久,这也是目前接手过功能点最繁复,产品线对接最多的一个项目。从中得到的一些关于设计较大型产品的心得,拿出来跟大家分享。 立项前 1、统一元素设计需考虑周全 也许是初创团队的缘故,我不得不感叹团队对产品经理要求之严格之缜密,项目全程只有一个人负责,所以大到产品线对接,小到一句提示的位置和展示形式都需要一一推敲。
几乎每种行业都有基层主管(或基层管理人员),而软件行业的基层主管一般是项目经理、技术经理、开发经理、组长等。其职责是资源协调、风险预估、项目管控、团队建设,说白一点大多数的企业现状就是项目负责人带领团队攻下一个又一个项目的过程。
相关文章:DevOps,不是一个传说! 过去一年以来,一批来自欧美的、不墨守陈规的系统管理员和开发人员一直在谈论一个新概念:DevOps。DevOps 就是开发(Development) 和运维(Operations)这两个领域的合并。
引言:进入现在这个我们内部号称“豪门”的项目已经两个多月了。现在回想起进入项目前一位前辈的话:“大项目有大项目的问题,但大项目也有很多东西可学“,自己此时深表赞同。两个月的时间,自己从刚来前两周的观察学习,到现在的基本融入,在这个过程中自己有了很多的想法和思考。
这是关于一个项目的故事,与其它项目相比,既不非常复杂,也不是很简单: 一个应用程序与数据库以及其它两个系统通信。这在技术和架构角度都是主流,而在管理角度则是标准情况: 所有工作都应该在昨天完成,但还有很多没有完成的。
项目开发过程中,每每有人感叹,曾几何时,队伍如何好带,如何好用,而如今,人心繁杂,队伍不好带了。很多人的想法是“人望高处走”,不停的寻找待遇及其他方面更好的单位。其实,这种现象在当今社会也很平常,尤其在中小企业,毕竟,在经济等利益的驱使下,有几个人会与金钱过意不去。
在项目过程中,会有旧面孔的离开,但也有到很多新面孔的加入,什么样的新人是比较讨喜的呢?作为管理者来说,最希望花最小的代价而获得最大的收益,但事实上这样的新人太少了,下面从几个方面谈谈我在工作中期望的新人。
这段时间,一直在负责一个项目的管理与开发。在时间短、任务紧,而团队人员又大部分是没有经验的菜鸟的恶劣情况下,我带领接近40人的团队,终于在客户规定的时间范围内如期交付产品。这其中,经历了需求变更、人员变动(因为其它任务,先后有近10人离开团队)等诸多问题,项目仍然取得成功了,不能不说有几分侥幸,但此外也有一些经验与教训可以与大家分享。
在连续封闭N个月以及再后来的N个月的加班后,项目终于以延期N个月的结果结束了。不管曾经发生过什么,不管项目是否延期,重要的是项目结束了,所有的项目成员都可以松一口气了。曾经和同事开玩笑说:在我经过过的失败项目中多了一个项目,以后就能避免同样类型的失败了。
项目进行到今天,我突然发现项目已经花费了快70%的时间,而离编码结束似乎还很遥远,面对着领导质问般的眼神和组员迷茫般的目光,我深深地吸了一口气,大脑开始了高速地运转,到底谁动了项目的时间? 项目情况 首先介绍一下项目的大概情况: 其实项目倒不是很复杂,一个处理业务流程的系统。
一个系统不仅需要优秀的分析和设计,更需要一个良好的过程将其从蓝图转化为实现。这个过程中最重要的是对团队的管理,也就是人的管理。一个优秀的团队和一个糟糕的团队的效能是天壤之别,她们之间的比例不是1:100或1:1000这样量化的数字能够表示的。
软件架构引言之项目管理的问题 很多朋友都有过或者正在管理一个或者多个软件项目,那么我的文章就从这个问题开始:如果单纯从表象来说,软件项目管理过程中暴露的最大问题是什么? 不同的人的会有不同的答案,但是大致这样的答案我想大部分人都是会认可的,那就是“进度拖延”。
//上个月给我们老板的mail.洋洋洒洒6000多字. //为了方便公开,改了一下.以致可能有些地方前言不搭后语. //不管他同意不同意,先在我们组实行了再说. //请多大家多提提意见,日后看有没有机会找老板当面交流 经历的几个项目,项目的进度老是不尽如人意。
1. 什么是微型项目 微型项目是指绝大部分工作由一个人员负责的项目,这个核心成员负责项目的系统分析、构架、及绝大部分的编码工作。项目的持续时间一般不会超过一个月。项目的参与人员除了核心的程序员外还可能一部分辅助人员,包括第二程序员(负责一部分编码工作)、美工(负责界面设计)等。