人才测评

技术

  1. 对开发者最有用的5个网站
  2. 你经常使用的开发工具
  3. 你经常浏览的5个网站
  4. 你最好的技术是哪些?各有什么特点?

知识

  1. 你最喜欢的专业领域是什么?
  2. 有没有对某个问题或事物进行过深入思考,结论是什么?

个人

  1. 你最欣赏的性格特征是什么?
  2. 做过的最有趣的事情是什么?
  3. 做过的最成功的事情是什么?
  4. 做过的最后悔的事情是什么?
  5. 是否有职业规划,是什么?
  6. 你有什么优点?有何佐证?

公司

  1. 你最在意的公司环境有什么?
  2. 什么样的公司是个好公司?

试用

  1. 在时间充足的条件下,是否能够检查自己完成的工作,优化自己的工作成果。即:精品意识
  2. 是否有钻研学习的欲望

为自己的利益而奋斗-新员工系列

我的老板及其严厉的人,有一次,我作为项目经理和老板去跟客户谈一个项目,不是很顺利,回来的路上,顺口问同事,“PSTN是个啥呀”,身边的老板立马发作了,“你丫的,PSTN都不知道是什么,跟人家客户谈个毛项目呀,都不知道他妈的先学习基础概念?”,靠,哥们我一听也他妈的气愤了,“妈的,我是一个程序员呀,又不是搞通信的,这我怎么该知道?”,当然,这些话,只能在心里骂。

人有情绪是应该的,但是总是被情绪控制,就比较傻逼了,到底是“公司先给我涨工资,我才更好的去工作”,还是“我更好的工作,公司给我涨工资”,显然,谁主动,谁就小亏。那么是不是我们就要天天撞钟,等老板给多点钱,才去干点扫地的这个事。时间和5毛钱,那个更重要呢?

道理看起来很明显,现实却很骨感,初出茅庐的我们,总是嫌得到的少,而不愿意去付出。即便付出了,也没有使出10分的力气,敷衍了事,事事凑合。领导严厉一点,还一堆的理由,岂不知,你所经历的才是你的财富,别人给予的,只是利息而已。没有大量的财富,谈何丰厚的利息。而且,这个利息还是驴打滚呀。

那么我能做什么呢?

  1. 凡事多动脑:不要以为,凑合能用就行了,你可知,商品品质20%的差异,价格可以差10倍,想想悲催的诺基亚吧,曾经以为完美的存在,瞬间就被秒杀了
  2. 寻求帮助是一个好方法:但是一定要先自己尝试解决要,万事不决问google,之后再问人,不要浪费别人时间呀,首先看看这个主题
  3. 多动手操作:任何知识,要向据为己有,知识听听看看是不行地,“自己动手丰衣足食”是恒古不变的法则
  4. 不要拒绝批评:面对批评,心里不爽是可以地,一直不爽就是傻逼地,人生中有人愿意冒风险给你批评,是你的福分呀,当然,也不能一概接收,还是要有独立思考能力地
  5. 审视自我:很多时候,我们在自己画的圈圈中打转,无法前进,这时候就要自省了,什么时候能开悟,就看造化了,所谓:佛渡有缘人
  6. 多花时间:我们都是凡人,要想在某个方面超越别人,多花时间是不二法门(你是乔布斯,就当我没说)
  7. 锻炼沟通的能力:提问是门艺术,提问的质量决定答案的质量

利益最大化现实途径,其实就是多干活,更快的提高自己的能力,提高自己本身的价值,形成长期的利益最大化。是不是多干活一定能提高能力?这里面牵涉到一个能力转化率的问题,某些人做一个项目能够明白5个技术点,而有些人只能明白3个,长期积累,个人能力的差距会越来越大,一个项目涉及方方面面的内容,管理、需求、设计、编码、测试,可能每个人的兴趣点不同,人也不可能面面俱到,只要在你自己选择的方向提高即可。那么如何来提高转化率,复杂而又简单的问题,

尝试、归纳、思考、总结、改变。

个人感觉,就是这么个套路,具体的执行情况,就看每个人自己的执行力和欲望的大小了。

坚持迭代!!!

需求分析与功能设计 案例分析

注:本实例绝非虚构,针对初级开发者,改变程序员=打字的困境

需求分析

背景:证书打印功能,能够打印3份证书:正本(机构名称、住所)、副本第一页(编号、发证机关)、副本第二页(机构名称、法人)

  1. 第一次需求描述:需要个能够打印证书的功能
  2. 第二次需求变更:经营范围固定为某段文字,不能修改,自动生成证书编号
  3. 第三次需求变更:需要在证书打印功能中增加打印记录功能,要求1天完成
  4. 第四次需求变更:打印第一页时填写的内容,能够在第二页复用,要求尽快完成
  5. 第五次需求变更:增删改查打印内容,之后根据填写的打印内容打印证书,并能导出打印内容列表(作为绩效)

问题总结:

  1. 每次都是听客户两句话就要求开发完成功能,未深入挖掘需求
  2. 第五次需求完成时间比第三次需求要求时间晚2周,而每次要求都是紧急,导致无法全面规划功能设计
  3. 第五次需求完全覆盖第四次需求,浪费开发资源

解决方法:

  1. 充分与客户沟通,深入分析客户需要,完善需求。参阅 写出一份有意义的需求文档
  2. 尽量争取合适的开发时间

功能设计

在需求挖掘不够充分,描述不清时,开发人员有责任通过自己的主观分析来引导需求完善

此次分析,依据:第三次需求变更

明确目地

第三次需求变更,可以设想出两种不同的目的:

  1. 客户是希望知道谁在什么时候打印了什么,打印了多少次
  2. 证书需要每年更换,第二次打印希望能够复用上一次的打印数据

不同的目地有不同的设计思路

目的一:关注于什么人什么时间打印了什么;此时要注意:打印错误如何标记; 目的二:关注于如何减少用户的工作量;此时要注意:是否可以结合 机构档案、机构年审功能 来处理 证书打印功能;

本案例,目的一与目的二不冲突。完全可以同时实现,但功能实现的时间要求有限,同时也没必要完成客户不需要的功能,所以选择哪个方向,应继续与客户沟通。

错误的方向,走的越远,错的越远。

设计分析

背景:选定实现第一个目的

第一次设计

打印记录表结构:机构名称、住所、编号、发证机关、机构名称、法人、打印时间、打印人

功能:没点击一次打印,增加一条打印记录

缺点:3个不同的打印,能够填充的字段不同,记录看起来总是不完整的。

第二次设计

表机构修改为:打印人、打印内容、打印时间

功能修正:将所有的打印数据整合为一个字段-打印内容

第三次设计

表结构修改为:机构名称、打印人、打印内容、打印时间

功能修正:将机构名称独立出来,作为数据整合的基准,比如:要查看某个机构的所有打印记录

缺点:实际上3份打印内容,才算一次完整的打印记录,现在的设计无法体现这个概念

总结

iphone发布前,进行过无数次的设计修正,那可是世界顶级的设计师,而我们每次写代码前都是不加思索,错误百出,为何不在开工前先想好呢?无论你是什么等级的工程师,请在编码前,将自己的设计思路推翻两次以上

代码组织

此次分析并不涉及代码组织的分析,为了突出代码组织的重要性,在这里再次说明请在编码前,将自己的代码组织思路推翻两次以上

案例:材料管理是我们公司最有技术能力的人独立完成的项目,此人熟知各种技术、能够解决各种疑难杂症,但是这个项目却久经维护,依然破烂不堪,让人头痛。代码是需要组织的,不是拼凑起来就管用。能够驾驭万行代码才是真技术

写出一份有意义的需求文档

重要性

  1. 需求作为软件开发的排头兵,决定了项目发展的方向,方向错误,全局失败
  2. 需求的频繁变动,不仅影响项目的进度,更影响编码人员的工作热情、工作态度(人心散了,队伍就不好带了)

参考:项目设计与代码组织-案例分析

视角

以客户需要为视角

应该以客户的视角来书写文档,以客户实际的需要作为中心。比如:工单管理,应写明客户为什么需要求救工单,客户现实中是如何处理求救工单的,而不是直接将需求具体为:录入工单、回访工单

以软件设计为视角

必须以定量分析来描述文档,而不是概念描述,比如:一般情况下、通常、大概、有时候,这些概念性的内容,计算机乃至程序员是无法理解的,应该将各种不同的情况加以分析,转换为可以判定条件,比如:美女筛选这个业务,1.身高大于170cm 2.体重小于45kg 这些定量的数据,可行,而 3.皮肤白 4.气质佳,这样无法定量的条件,就需要深入思考、妥协,转换为定量的数据,比如:3.白 > #333333 4.智商大于120并且情商大于>130,或者调整业务,增加人工投票的功能。

系统目标

不能是笼统的,走形式的,是真正的目标,有意义的目标,不多,但是必须有,如果根本都想不出来,那就需要先考虑系统存在的必要性

  1. 解决了什么问题
  2. 优化了什么业务
  3. 增加了什么便利
  4. 或者达到了某种目的(圈钱、面子工程等)

根据目的,来确定系统要实现的功能,实现功能的方法。比如:

  1. 面子工程:就不需要搞复杂的业务逻辑,而是展现更多的功能,但不需要每个功能很强大,有就行,而界面要符合某些人的口味。
  2. 便利性:则着重突出UI交互,让用户一看就懂,不学就会用
  3. 优化业务:那就需要把业务流程搞清楚
  4. 解决问题:需要找出本质的问题,而不是表面的问题

没有哪个系统能够满足全世界的需要,强大如iPhone也没有征服全世界,必须有所取舍,找出自己的亮点。

业务分析

以场景演练为出发点

最好能够以实际用户的身份,对现实的业务流程进行操作,熟悉每个业务步骤的原始执行方式,体会操作的实际效果及意义,在没有实际操作条件的情况下,也要尽量在脑海中,将每个业务过程演练多边(要有带入感,就像过电影片段一样),了解现实的操作方法之后,才能抽象出符合客户需要的产品设计方案。

穷尽特殊情况

对于某些复杂的业务运算,应穷尽各种情况,让用户进行解答,从而找出正确的计算方法:

??

明确优先级

  1. 项目功能较多时,应分析出功能点的优先级,指导开发安排进度
  2. 尽量指定各个功能点希望完成的时间点(技术部根据期望的时间点和功能的难易程度,规划进度表)

文档的组织方式

很多需求文档都是对功能的罗列,1、2、3、4、5,仅仅是一个一个的罗列,读起来索然无味,根本无法调动阅读者的积极性,让人读得很勉强,引不起思考。甚至,不谈功能与功能的联系,苍白的义务式的罗列。

功能组织

将能够完成一项特定任务的功能,按照业务逻辑走向,进行分组表述,是一个较好的方法,恰当的功能表述顺序,与内容组织,更容易让人理解作者的本意

而对于那些诸如:参数设置、业务字典、部门管理等等一些无脑功能,基本是固定不变的内容,简单罗列即可

罗列基本、突出重点、详尽难点

长篇累牍,重点不清的文档虽然也能说明问题,但是会增加阅读的难度,容易被程序员抵制,甚至抛弃,即便是强制去读,也不利于理解。

比如:客户管理这个大功能

如果分解为:新增客户、删除客户、修改客户、客户资料查看、客户信息统计,并详尽说明;有多大意义?

较好的分法:

  1. 客户档案管理:新增、修改、删除、查看(一行文字就ok了);然后列出客户档案的字段,针对较复杂的字段,进行特别说明
  2. 针对客户的类别分别描述不同的客户有那种不同的业务处理方式
  3. 针对不同的统计内容,画出对应的统计结果草图,并略微说明统计的意义
  4. 对一些特殊的界面需求,比如:查询条件,做出具体要求,并说明其中的用意
  5. 与客户相关的业务,指明必要的链接

对于一些较复杂的业务逻辑,比如:运营补贴的计算方式(因素很多),要穷尽各种因素的组合,进行详细描述。

用业务实例辅助说明

以实例来描述业务场景,通常更容易理解,比如:老人档案审批


  1. 社区填写老人档案,提交给街道,进行第一次审批
  2. 街道第一次审批
    1. 通过后,提交给区县,进行第二次审批
      1. 区县审批通过,则将老人档案设置为 已审批档案
      2. 区县未审批通过,则将档案退回到街道重新审批
    2. 审批未通过,则退回给社区
      1. xxxxx
      2. xxxxx

备注:

  1. 每次审批,有:通过、未通过两个选项,对于未通过的审批,必须填写审批意见。
  2. 其中街道在审批过程中,可以修改:审批意见、截止日期

  1. 场景中可以使用实际的客户名称,比如:金水区民政局、丰庆路街道办等,增加可阅读性
  2. 对于描述的内容,可增加 斜体、粗体、下划线 等因素,将角色、业务点、业务数据 等内容,着重标出,提高内容质量

文档优化

  1. 使用更形象、合适的语言描述,比如:移动用户的增加,是“新用户入网”,而不是“新增用户”,“新增团队”也没有“创建新团队”更贴切

笔者注

  1. 系统及文档迭代化:系统的第一版不要追求过大过复杂,而应紧抓核心目的,仅完成核心目的必须的内容,随后的功能逐步添加;类似于抛砖引玉
  2. 系统可持续交付:每个功能的完成,系统都是完整的、客户可用的

谨慎使用Ajax动态引入Js(附代码与结果)

代码(index.php):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<html><head>
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<script>console.log("header",new Date());</script>
</head><body ryt12134="1">
<script>console.log("body_header",new Date());</script>
<script>
(function($) {
    $(function() {
        console.log("$$$$" + new Date());
    });
})(jQuery);
$(document).ready(function(){ console.log("ready",new Date());});
</script>
<script type="text/javascript" src="http://42.121.117.187:8899/test.js?<?php echo time();?>"></script>
<script>console.log("body_footer",new Date());</script>
</body></html>

代码(index.html):

1
2
3
4
5
6
7
8
<html><head>
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script></head><body ryt12134="1">
<script>
$.get("index.php",function(html){
    $("body").append(html);
});
</script>
</body></html>

测试结果:macos:firefox、chrome、safari -- win8:ie10 基本相同

  1. 将js文件放在header中,document.ready()会等待js加载完成后再执行(header中的js是优先于body加载的)
  2. 将js文件放在body中,则 不考虑js是否加载就会执行(将jquery放在最后面,会导致js出错)
  3. 直接请求index.php的执行结果

    header Date {Thu Aug 29 2013 14:32:51 GMT+0800 (CST)}
    body_header Date {Thu Aug 29 2013 14:32:51 GMT+0800 (CST)}
    qian_test.js Date {Thu Aug 29 2013 14:32:54 GMT+0800 (CST)}
    hou_test.js Date {Thu Aug 29 2013 14:32:54 GMT+0800 (CST)}
    body_footer Date {Thu Aug 29 2013 14:32:54 GMT+0800 (CST)}
    $$$$Thu Aug 29 2013 14:32:54 GMT+0800 (CST)
    ready Date {Thu Aug 29 2013 14:32:54 GMT+0800 (CST)}
    
  4. 请求index.html的执行结果(显然document.ready优先于js中的代码执行)

    header Date {Thu Aug 29 2013 14:44:01 GMT+0800 (CST)}
    body_header Date {Thu Aug 29 2013 14:44:01 GMT+0800 (CST)}
    $$$$Thu Aug 29 2013 14:44:01 GMT+0800 (CST)
    ready Date {Thu Aug 29 2013 14:44:01 GMT+0800 (CST)}
    body_footer Date {Thu Aug 29 2013 14:44:01 GMT+0800 (CST)}
    qian_test.js Date {Thu Aug 29 2013 14:44:04 GMT+0800 (CST)}
    hou_test.js Date {Thu Aug 29 2013 14:44:04 GMT+0800 (CST)}