2012年12月21日，冬至，传说中的“世界末日”安然度过，一切照常运转，开始整理2012年的总结。

这一年，工作和生活相较以前有比较大的变化，对个人是个比较大的挑战，整体而言，完成情况和当初的预期还有一定的差距，如果要打分数的话，我给自己打50分吧。

以下主要是一年多来工作相关的内容，更像是一份工作总结，不只有我，还有整个团队的身影。

工作要从2011年10月23日开始说起，这天到达杭州，加入一家新的公司，从头组建技术团队，开始征途。

一、团队

1.招聘

初期遇到的最大问题是招聘，尝试过微博、招聘网站、同事推荐等多种方式，最终大部分简历来源都是51job，对于刚起步的公司，微博招聘没有太大的吸引力。

11年招聘产品经理和UI设计师各1枚，12年招聘开发工程师2枚，运维工程师1枚，测试工程师1枚，招聘周期拉的比较长，年龄跨度也比较大，70后+80后+90后。中间离职2人（产品及开发各一人），目前是五人小分队，开发、设计、运维、测试各一人，设计师兼UE，页面制作外包。

Update：12月28日，测试工程师结束实习，so目前由五人小分队变为四人帮。

初期遇到的问题是招聘难，后期遇到的最大的问题是磨合，包括个人与个人，个人与团队，个人与公司，中间遇到了不少问题。招人时不仅要看技术能力，还要看协作能力、工作态度等。前期需要根据岗位快速引入人员，逐渐要放慢招聘节奏。

2.协作

团队成员的背景各不相同，有的有2年工作经验，有的基础扎实但缺乏互联网项目经验，有的可以独当一面的，有的刚参加工作不久，也有大四实习生。如何让一群人变为一个团队，整个年度一直在摸索。

前期主要是对以前的工作经验进行裁剪并实施，强化互联网项目的流程、规范，个人深入细节，加强沟通，这个属于指挥的阶段。逐渐这种方式的弊端显现，首先个人很累，再就是对大家的积极性是个打击，个别团队成员在忍无可忍后表达了“强烈抗议”，遂放手发挥大家的主动性，允许犯错，从完成情况来看效果还不错，这个是指导的阶段。更高层次是发动，激励和启发大家用自己的方式来完成工作，这个还远未达到。

3.学习

首先是充实团队的图书馆，前后买了十几本书，包括产品、设计、开发、数据库、虚拟化、运维、营销等各个方面，书单列表见：http://book.douban.com/doulist/1750004/，以便方便整个团队深入学习。从整体情况来看实用性强的效果不错，理论性的效果欠佳。

上家公司每周都会有技术或UED的分享会，大家互相交流学习。这一年也断断续续组织了几次分享会，包括产品、设计、运维、测试等。刚开始内容相对务虚，后续逐渐侧重实用性，同事在完成某项技术研究或搭建新的系统后，进行实际演示和讲解，让大家快速了解相关内容。

为了便于大家跟踪了解新的技术趋势，从今年3月份起开始每周整理一份资讯列表，主要包括资讯、产品、技术等方面内容，内容主要来自微博，一共整理了28期，中间出差断掉了几期，11月份后因工作、生活的原因，停止更新。整理的内容会在每周例会时和大家做个简单交流，前期内容比较庞杂，后期整理时每期侧重一个主题进行整理，比如前端、OpenResty、持续集成等，以便增加深度。从现在看基本达到广度的效果，但深度还远远不够。

4.培训

根据工作饱和度，或工作的需要，针对性地对部分团队成员制定了初步的培训计划 ，明确学习目标，指派专人进行指导，取得了一定的效果。团队成员需要有一定合理的梯次结构，完全招聘有丰富工作经验的人员是不现实的，从我们的情况来看，运维和测试工程师在工作中从不熟悉到熟悉再到独挡一面，成长的很快。

5.团建

今年部门活动主要是以聚餐为主，KTV为辅，时间不固定，一般是在新人入职或临时组织，后半年本计划户外活动，结果天气也冷了。这块儿做得还不够，以后要周期性的组织腐败活动，增进大家在工作之外的了解，活跃气氛，这个是我的弱项，要改进。

6.绩效考核

公司根据PBC制定了绩效考核模板，每月个人评分后部门负责人评分再进行面谈，从实际效果来看，评分基本流于形式，有价值的一点在于每月的一对一绩效面谈，可以和团队成员进行深入的双向沟通交流，听取团队成员的建议、意见，并及时做出调整。

二、产品

今年在产品方面投入了不少精力，和产品经理一起沟通讨论业务逻辑，产品原型。我们要做的项目是传统项目与互联网的结合，和纯粹的互联网项目有很大的不同，中间走了不少弯路，教训深刻。有个人的原因，有公司的原因，中间还有一些不可控的因素。

产品经理的交付物：多个Axure原型文件，200+页面，外加思维导图若干；设计了完整的前后台流程，覆盖面向个人和企业的解决方案，限于各种原因，产品并未正式推出，有机会再让产品来说话吧。

以下是一些经验教训：

1.小公司，最大的产品经理是老板；

2.快速试错，避免闭门造车；

3.构建一半产品,而非产品有一半缺陷；

4.产品路径要短；

5.以客户为中心；

6.做减法，优于做加法；

7.一切不以上线为目的的产品设计都是耍流氓；

推荐阅读：

1.Getting Real

英文：http://gettingreal.37signals.com/

中文：http://cnborn.net/docs/getting_real/index.html

互联网创业者都应反复阅读，并对照检验、修正。

2.《四步创业法》

豆瓣链接：http://book.douban.com/subject/11516567/

这本书来自作者连续创业的体会心得，提出客户发展方法：客户探索→客户检验→客户培养→组建公司，颠覆原有的产品开发观念。

3.《商业模式新生代》

豆瓣链接：http://book.douban.com/subject/6718487/

以画布的形式，系统反映商业模式。4个视角：提供什么？为谁提供？如何提供？成本收益如何？ 9个构造块，如下图：

 

三、设计

我们的设计师，这一年来随着项目一起成长，中间也被我压榨、打击了N次，显示器上多了若干指点江山的痕迹，内心也变得日益强大。

这一年来设计师的工作也由单纯的设计，增加了用户体验部分的工作，并在工作中显现出效果。在设计的过程中，也逐步整理了设计规范，虽然还很简陋，但已经有了框架。

设计是需要有创造力的工作，过多的限制会扼杀设计师的灵感，支离破碎的挑剔会让设计师无所适从，这个也是我做的不好的地方，需要改进。

设计师的交付物：

四、开发

我们的项目使用PHP语言开发，当初选择PHP主要从开发速度和扩展性、人员招聘难易程序考虑。第一位PHP攻城师加入后，对几个PHP框架（ Zend Framework、CakePHP、Yii、CodeIgniter）进行了技术选型，从框架功能、代码规模、学习成本、性能等几个角度进行对比，最终确定使用Yii框架，并很快搭建了项目的架构，完成项目的主要代码。后期又招聘一位攻城师，加快了开发进度。

在项目后期，我们对PHP持续集成方案进行了研究，基于Jenkins搭建了PHP持续集成系统，参考资料见http://www.hopesoft.org/blog/?page_id=719（后续如有时间再做补充），Jenkins安装了项目规模统计、代码风格检查、单元测试、代码覆盖率、静态代码分析、生成文档等插件，服务器同时要安装相应的PHP工具。目前的工作流程为：开发人员开发完毕，在本机测试通过后，将代码签入svn，Jenkins服务器设置半小时自动检查svn服务器代码，如有更新则触发自动构建，生成相应报告，相关人员可以收到构建结果邮件，如构建通过则自动部署至测试环境，测试人员即可对测试环境进行测试。

持续集成平台的引入，可以加快构建及时发现错误，通过代码分析、风格检查等可以准确指出代码中存在的问题，减少部分人工工作。问题就是需要需要投入一定的成本，保证核心代码都有单元测试代码，短期看投入大于产出，长期看会有较高收益，当然还要取决于人的因素。

今年还对一些技术进行了初步的测试，比如章亦春的OpenResty和Facebook的HipHop，虽然未在项目中正式使用，但基本都进行了初步的了解，搜集了相关文档，并进行了部署、测试。

项目代码规模：

推荐阅读：

1.持续交付-发布可靠软件的系统方法

豆瓣链接：http://book.douban.com/subject/6862062/

五、运维

运维工程师是90后，入职前期以公司网络维护为主，后来逐渐转到基于Linux集群的研究，从前期的学习到后期逐渐独立工作，在工作中成长很快。今年主要搭建了Linux集群的测试环境，监控系统、svn服务器、邮件服务器和其它一些基础设施。

Linux集群在内网的测试环境，基于4台虚拟机，使用Keepalived、Nginx，MySQL、MySQL-Proxy（读写分离）、MySQL-mmm（高可用）、Memcached（动态缓存）等。

 

项目正式上线时，会优先考虑使用阿里云主机，并对架构进行精简，随着业务的发展再进行扩展。

六、测试

我们的测试工程师是大四的实习生，参加过测试的培训，也是90后，在加入之前我们的测试工作主要依赖于开发人员自测和产品经理测试，测试的效果比较差。测试工程师加入后，团队的工作形成了闭环，大大提高了测试进度，保证了交付物的质量。

测试工程师除了功能测试和兼容性测试外，还对自动化测试和性能测试进行了学习研究和实践。自动化测试使用Selenium，编写了前台多个流程的自动化测试脚本，可以完成前后台多个等流程的自动化测试，减少了人工重复性的工作。ps：关于自动化测试的投入产出比，和脚本的修改频率有关。性能测试使用LR，通过和开发人员不断沟通、反馈再复测，性能有了一定提升。

小的团队要不要专职的测试人员？可否由产品经理和开发人员完成测试工作？每个团队的情况不一样，所以没有标准答案。我个人理解，如果有专职的测试人员，应该尽量使用工具减少人工的重复工作，并向自动化测试、性能测试、配置管理、持续集成等多个方面多多熟悉了解。如果只是功能测试和兼容性测试，则没有发挥测试工程师的潜力。

测试工程师交付物：158个bug，测试报告若干。

七、工具

今年使用了彩程设计的几个工具，有日志管理（https://www.teamcola.com/）、设计管理（http://www.designboard.cc）、任务管理（https://tower.im/），都非常不错，推荐试用。彩程设计是一家小而美的公司，有很多值得我们学习的地方。

在开始写这篇工作总结时，我感觉没有一个词可以概括2012年，今年经历了太多，在整理的过程中，这个关键词越来越清晰，那就是“成长”，不只是我个人的成长，还有成员的成长，最后是整体团队的成长。

再见，2012！