|
本文转自程序员杂志，文中内容不代表本站观点，仅提供参考
说起职业素养，可能大家脑子里马上反应出的是西服领带公文包的精干白领形象，其实作为程序员来说，有更多内在的职业素养?一个具有职业素养的程序员应该是什么样的呢?本期调查分享两个研发小组的故事，让大家在统计数据的基础上进一步了解——什么是程序员需要的职业素养?
案例一：对客户坚称“一点也不复杂”的团队A
DDD公司是个在发展壮大中的贸易公司，由于业务发展员工从刚开始的10人半年内增加到150多人，管理上出现了沟通效率低、对员工工作难以监控的现象。公司想近期上OA系统，以加强公司的工作效率、支持快速增长的业务。DDD公司找到了OA专业开发公司OOO公司，经过几次与OOO的销售沟通后，双方确定了合作意向。而在OOO内部，有两年开发经验的开发工程师苏成自告奋勇希望承担该项目的开发管理工作，公司考虑到苏成不错的开发能力、希望提高自己的期望，安排他成为这个项目的项目经理带领三个开发人员，建立了项目组A，开始了这个DDD的OA项目。
项目不大，公司没有特别安排需求开发工程师。按规定作为项目经理应该在与客户确认需求后进行开发。但初为项目经理的苏成信心爆棚，认为自己开发能力强，当项目经理也一定成。
ü 对外，苏成采用了就想当然地按照合同后附的简单需求说明草率进行开发。
ü 对内，苏成认为项目经理拥有绝对权力。“今天不努力工作，明天努力找工作。”成了他的口头禅，每次用威胁的口气说出时，苏成都会有种满足感。同时，任何关于开发的不同意见都听不进去，在第一期快结束时，苏成已与项目成员发生了N次争吵，大家纷纷要求调离项目组，团队面临全面崩溃。
在二个月未与客户沟通的状态下，苏成项目组向DDD提供了OA系统一期产品，按合同规定包括了：员工管理一项功能和其他四个子项(公司纪律规定、部门工作分类表、职务分配表、工作内容调查周报表)。
看完基本功能演示之后，苏成随即向客户提出希望尽快部署和收款的要求。
DDD公司的HR经理Helen几乎要尖叫起来!于是，发生了下面的对话。
(H：Helen，Z：苏成)
H：“这个员工管理怎么没跟考勤部分联系想来呢?而且按你说的在这个系统里增加一个新用户需要五步!太复杂了吧。”
Z：“一点儿也不复杂，一点儿也不复杂。我现在给你再演示一下。”
一边说Z一边动起手来。系统是按他自己的理解开发的。运用起来自然十分娴熟，演示增加人员的步骤5秒钟都没用，当然，H也和刚才的演示一样，没怎么看清楚。
H：“还是太复杂了，能改成一步吗?”
Z：“一点儿也不复杂，要不要再给你演示一次。”
H：“算了，先不谈这个。我们希望在这部分里加个统计功能，之前也和你们销售讨论过这个问题，我们希望能统计出公司员工交周报的情况和部门比例。”
Z：“这个有困难，做不了。其实公司人也不多，建议这部分还是手工统计吧。”
H强压怒火：“按这个思路都可以手工统计，根本不用您来开发，但公司是因为要发展才要上软件的。”
……
实际情况是，因为开发时即没要求留下文档，加之团队其它几个成员均已准备离开项目组，任何在此模块中的小小变化都会面临所有代码重新开发的局面，更不要新增什么功能了。苏成非常清楚，客户是不会再花一个项目的钱，只开发一个新功能的。所以，苏成压根儿都没提因为需求变更，要加钱做这个功能的事儿。
最终结果可想而知，苏成辛苦开发几个月没有得到相应回报，客户不满意、项目组成员不满意、研发部总监更是对他的能力产生了怀疑，在几经努力拿到DDD公司在第二期项目开发合同之后，更换了项目经理。
Leo点评：程序员如何以明确需求为基础与客户沟通?
如果有专门掌握需求编写技术和经验的需求工程师作为客户和程序员之间的桥梁是最理想的状态，但是，以国内目前的国情下，每个项目组都配有需求工程师的并不多。因此，无论是从现实出发，还是从程序员自身提高的角度出发，正确地帮客户表达需求、正确地理解需求就成了程序员的基本素质之一。否则，到最后多是像本文中提到的苏成，搞得人、财两空。此次调查中66.67%的被访者认为“能帮助客户正确提出需求”是程序员自身的修炼之一，此种修炼肯定能在中国当今的环境下，提高程序员自身的能力和素养，可见在程序员内部已就此达成了相当的共识。认为“能使客户需求更完善”是程序员自重重要修炼之一的占到此次调查的55.13%。说明超过一半的程序员认识到，帮助客户完善需求会节省双方的时间和精力。
上一篇:BPEL模型基础
下一篇:BPEL的基本活动介绍
|
精品推荐