(原创)技术这东西,不可不看,不可全看.(二续,规范的危害)

skylovers 2009-06-18 11:20:49
加精
不想小弟的一片杂论引起了众前辈的指教,实在有些意外和惊喜.

lin_programmer和xp1204两位同仁分别在小弟的帖子第63楼和
(原创)批 :(原创)技术这东西,不可不看,不可全看.(二)
中,分别提出了关于规范开发的意见和建议,在下深感荣幸.在这里在下也讨论一下规范开发方面的问题,希望可以抛砖引玉.

版权声明:
此文章系列CSDN论坛首发.著作权为本人所有.此文章为大纲形式,为方便阅读采取较为通俗的口语化形式.但是不代表此文即为发行版本.着眼高度可提升, 相关问题可展开,如书商有意出版发行,请随时与本人联系,商谈相关事宜,谢绝闲谈.skylover531@msn.com


规范篇
本人承认,在(原创)技术这东西,不可不看,不可全看.(二)中,小弟的举例实在肤浅了许多,甚至忘记了许多开发过程中重要的过程,再这里再次阐述一下吧.

关于开发任务的需求如何明确,这个lin_programmer的观点呢,主要是从便于管理和考核的角度来阐述的.而xp1204主张更倾向于从开发人员的角度如何进行合理沟通角度来说明.明显,这两点都是在下所没有提及的,这两点各有所长,都是很好的做法.

针对二者所提出的"规范",在下还是有些不同的看法的.

限于工作环境,管理背景所限.在下更多的是属于"小公司"开发性质范畴的.开发部经理往往将自己的主要工作定义为任务的转发和技术人员的行政管理.而对于具体内容往往不加涉及.这可能也是因为在此类公司大部头项目开发甚少,属于"修修补补"之类的维护性工作占多数的原因吧.

然后再明确一下,本文的目的不是为了改善现有公司沟通流程,不是为了更好的权责分明.而是告诉大家,怎么做才能更快的升迁,把本文当作一本程序员职场厚黑学来读更有意义.在(一)中我就说了,程序员不是一个事业,是一个工作,而且是一个初级工作.

下面重点说说规范的危害.
规范好吗?很好,权责分明,任务明确.任何事情都有邮件和文档可查.那怎么会说规范会有危害呢?我来讲讲.

1.一切都流程化了,一个需求经过若干领导的层层审批.那么就意味着时间成本增加,这是许多"小公司"所不能忍受的.
2.规范就意味着个人工作范围有明确界定.需要做什么,不需要做什么一清二楚.这利于公司管理和长远发展,但是绝对不利于个人升迁!
3.想个人升迁,那么无论是技术经理,还是业务部门,都需要给你较高的评价.所有东西都文本化,更不利于和业务部门的交流与沟通.
4.规范化和流程化,可能会造成程序员工作的模式化,换句话,就是让程序员能乖乖的做一个听话的螺丝钉.这对于渴求升值和加薪的我们是不可忍受的.

规范化的好处是什么?当我们成为领导的时候,可以采用这个来管理手下的程序员.来使自己的地位更近一步稳固,使自己在开人的时候能够随手拈来一个说得过去的理由.

好了,招人骂的真话说到这里.再来正经分析一下我们的"衣食父母"---决定我们业绩的关键人物---技术经理和业务人员的处境和心态.

在一个业务为先的公司中,技术经理的地位是悲惨的.同样是中层,却远没有销售经理,业务经理,甚至行政经理活得痛快.为什么呢?很简单,技术是一个花钱的部门,看看<世界是平的>就会得出:发达国家早已经将技术支持工作外包至欠发达国家.这说明了两件事:1.技术支持永远不是公司核心.2.技术人员的待遇正在日趋低下.这就导致了技术经理的高工作压力和迷茫:一方面无法进入公司的核心权力圈,说话没分量;一方面自己要应付业务部门,甚至许多部门对技术各式各样甚至千奇百怪的需求.

业务人员是公司的重中之重,老总哄着,红包甚至回扣拿着.无论是出色的人脉还是资深的行业经验都使得他们牛气十足.

在没有一个强有力的规范约束下,这两者沟通的地位立见高下.强势的技术经理在下见过许多,有好下场的倒真没见过几个.技术经理一个比较好的选择就是,除了埋头搞搞"编码规范",给下面的人偶尔来个培训,照着HR提供的绩效考核表给小弟们打打人情分,主要工作就想办法怎么把自己弄成个技术总监,副总甚至CTO.当然,开发流程规范化是一个很好的政绩.但是,有很大的压力.如前面两位前辈所说:一切需求文档化是个很好的选择.权责分明.可是问题也就出在权责分明.权责,权利和责任.开发流程规范化的潜台词就是:技术部门有权利要求业务人员将需求描述的分毫不差,当开发工作在非BUG的情况下出现问题,业务部门有责任为此承担后果.这是业务部门所坚决不能接受的.因为业务人员更喜欢和擅长的是说:我要辆汽车.而不是告诉你发动机要多大排量,轮胎要多大尺寸.相比较来说,业务人员更倾向于用一种他们更为熟悉的业务化语言描述需求,最好还不用为此承担责任.白纸黑字的写下来,在他们看来无非是浪费时间以及增加自己负担的杂事.

在这种背景下,技术经理更倾向于避开和业务人员的直接接触,而是把精力放在更容易和方便出政绩的地方---系统架构的升级换代上面,至于需求分析这样的事情,再专门招人还是自己进行都不合适,于是乎所有的事情都压到了底层技术人员的头上.

当然,以上这些描述在相当成熟的公司和技术为先的公司中可能是不存在的.目前中国这样的公司也不多见.至少在下还没有正式经历过.也就没有发言权了.

当"规范还并不那么规范"的时候,正是我们这些小鱼级程序员建功立业的好时候.所以将"规范"这两个字暂且在你成为领导之前或者进入规范公司之前暂且忘记吧.

再说说小李为什么会做3个网页而不是4个.这里面其实正如lin_programmer和xp1204所说.一个小的程序员是不能够做这样的决定的,这是我例子最失误的地方.小李的王道做法是设计出Demo,哪怕是纸上随笔画的一些草图,只要能准确表达出意思,就可以交由业务人员进行审核,然后由业务人员拍板,找毛病提意见还是比较容易的,是吧.当然,要不要"规范"的记录下来,这个看情况.但是一定要知道,业务人员是不愿意留下什么文字以方便你可以随手抄送给任何人的.所以这个沟通非常重要,而且有必要在你有任何问题,或者想找借口休息一会的时候,都可以去找业务人员沟通或者汇报进度.一方面方便准确的弄清楚需求,另一方面让他们知道你在为这件事情努力.当然,从一个角度来说,这也是符合"极限编程"思想的.呵呵.

一个程序员,带领团队进行全新系统的开发的机会往往不多,更多的是这种维护性的工作.为业务人员做的多了,熟悉和信任随之而来.活干的漂亮,别给技术经理找麻烦,也是我们的宗旨之一.当业务人员已经倾向于有问题就习惯性的想让你来完成的时候,其实你已经被他化作"他的人"的领域了.这就是我们新入公司站稳脚跟的一个小小的里程碑.


连载:
(原创)技术这东西,不可不看,不可全看.(一)
(原创)技术这东西,不可不看,不可全看.(二)
...全文
405 53 打赏 收藏 转发到动态 举报
写回复
用AI写文章
53 条回复
切换为时间正序
请发表友善的回复…
发表回复
xx06212604 2010-07-15
  • 打赏
  • 举报
回复
不明真相的路过
java_2_java 2010-03-29
  • 打赏
  • 举报
回复
lyndamus 2010-03-19
  • 打赏
  • 举报
回复
不错,顶的人不多啊,快点继续
xiaokiss 2010-02-09
  • 打赏
  • 举报
回复
up,学习一下!楼主辛苦啦!
用户 昵称 2010-02-07
  • 打赏
  • 举报
回复
忽悠
Delta 2009-06-23
  • 打赏
  • 举报
回复
来看看。
longzhu007 2009-06-23
  • 打赏
  • 举报
回复
up
KENLIMYTH 2009-06-22
  • 打赏
  • 举报
回复
UP
gangrousishui 2009-06-22
  • 打赏
  • 举报
回复
看看先
zady 2009-06-22
  • 打赏
  • 举报
回复
[Quote=引用 30 楼 skylovers 的回复:]
引用 26 楼 axx1611 的回复:
成功的公司都是有规范的公司



没错,下句应该是:成功公司的创始人都是不拘泥于常规的开拓者.
[/Quote]

关于公司发展,记得以前看到人说有这样3个阶段:
人治
法治
文化治

就小规模公司而言,人治却是有最佳效能比的。

所以个人感觉,就楼主的例子而言,要看公司规模的。
前贴的说法,对于百人以下的小公司,是对的。
确认来确认去花掉的工时是小公司承受不起的。
现贴的说法,对于中大型公司是合适的。
naziace 2009-06-21
  • 打赏
  • 举报
回复
pass
kgduwu 2009-06-21
  • 打赏
  • 举报
回复
up一下
gxhclclgf 2009-06-21
  • 打赏
  • 举报
回复
学习一下
jsnjg 2009-06-21
  • 打赏
  • 举报
回复
不错
lanadi 2009-06-21
  • 打赏
  • 举报
回复
成功的公司都是有规范的公司
lststwhy 2009-06-20
  • 打赏
  • 举报
回复
mark
IceEyes 2009-06-20
  • 打赏
  • 举报
回复
mark
jxkjwmt 2009-06-20
  • 打赏
  • 举报
回复
飘过
mengbei 2009-06-20
  • 打赏
  • 举报
回复
看看
jinxfei 2009-06-20
  • 打赏
  • 举报
回复
在中国,规范不适合大多数公司,因为中国的客户闹的。
加载更多回复(33)

587

社区成员

发帖
与我相关
我的任务
社区描述
提出问题
其他 技术论坛(原bbs)
社区管理员
  • community_281
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧