程序员怎样提高自己-学会提问
大家一定有体会,在一个新项目开始时和客户交流或和Team里讨论新需求、新设计文档时,讨论的组织者会说如果有问题大家一定要提出来。可是开 会的时候总是问题并没有那么多,但是一下来开始设计或编码的时候,觉得好像很多东西都不清楚,问题一下子就全出来了,我们怎么解决这种困惑。换句话说,如 果能有效解决这种问题,自己的能力就会提高一大步。
一般在讨论之前,有一个准备过程,每个人都会拿到自己对应的文档,分析自己这一块存在的问题。从编码人员开始,考虑的总是如何去实现,所有提的 问题都应当为这个目的服务。那么要确保编码的时候没有问题,之前要怎样做呢?自然是在编码之前脑袋里已经编过一次了。这个时候写代码还早,程序的流程走通 就需要其他工具来辅助了,Visio也好,Word也好,UML工具也好,只要顺手的兵器拿来用就行了。这也是我的一个深切体会,从一个新手到一个经验丰 富的人,中间一定要有工具来辅助。人类现在的能力越来越强,从石器时代就明白一个道理,制造工具并利用工具,使能力无限延伸。
首先将流程图画好,Scope画清楚,这时候就开始尝试将内部逻辑走通了。先按照正常流程走一遍,所有的问题都记录下来,再考虑一些异常的情 况,再记录碰到的问题。如果有些详细的东西不够清楚,尽早请教比你清楚的人,并征求他们的意见,很多情况下提不出问题是因为自己对这个不了解。内部逻辑走 通后,再考虑外部和自己模块打交道的模块进出参数的问题,和他们讨论好方案,并有邮件记录最后的结果。当自己认为这里的问题都理清楚了,那将Scope再 扩大一点,其实也是尝试把自己的能力扩大点,多有整体观会给工作上带来很大的好处。
这时候所有Scope的人一起讨论时,就会有一些重要的问题问了。但一个人的思维是有局限性的,也许你想都没想过的问题,在讨论时有人提出来, 那就仔细听,仔细想对策了,如果想不到,问组织者怎么解决。经过几次这样的训练后,就会知道公司的产品关注些什么,哪些问题才需要仔细的解决。也要学会问 一些经典的问题,比如产品的瓶颈在哪里,性能如何等等,如同面试的时候经典问题:你为什么离开上一家公司。
等到这一步熟练后,慢慢将自己的角色和Scope放大,从编码角度,从设计角度,从质量角度,从安全角度,从市场角度等等多考虑。如果哪一天从 每一个角度都能提出很专业的问题,就说明在这个角度的积累深度。我们以前的读书环境并不提倡一天到晚问问题,但工作里不提问题就是和自己过不去,有些问题 可能对专业人士来说是很浅显的,但不知道一定要问到知道为止。也许哪一天和最高级的老大开会的时候,你问问题的全面性以及逻辑的严密性引起了他的兴趣,那 恭喜你,机会来了。
程序员怎样提高自己-驱动你的同事
想像这样一种场景,PM安排一个任务给你,但Scope比较广,涵盖到一些你不了解的技术和从没打过交道的Team。那么完成这个任务就要驱动 其他Team的同事,但你的级别又不是那么高,说的话不一定有人愿意鸟你。那怎么办,和PM的时间都说定了,难道要动用上级资源来协调?这里总结几种我自 己的方法,如果大家觉得有用就不枉此写!
1. 用PM驱动你的方法驱动你的同事
PM怎么驱动你的呢,看看这个谈话:
PM: lake, 有个任务比较急(老大交代任务多数说比较急),你最擅长这方面的东西,所以我们决定让你完成,这里是需求文档,你看多长时间能搞定?
lake: 公司大概能给多长时间?
PM: 20个工作日,你先看看文档估个时间,如果时间太紧我来协调。
lake: 好的,我先看看,今天下班前给你回复。
于是,看文档,定时间:
1)讨论涉及好几个Team,这个花的时间比较多,定5天;
2)开始Design,如果第一步讨论没问题,2天搞定;
3)Design的文档和所有Team开会Review,包括QA Team。一般两小时,考虑到还有人会提些需要找PM才能解决的问题,加上和PM的确认时间,1.5天;
4)Coding花5天;
5)Unit Test花2天,Integrated Test花1天;
6)QA测试改BUG可能要5天;
这样算算21.5天,还好不算超过太久,看来PM对时间也是评估过的。可是还不能把这个时间预算发给PM,如果发了,其他Team说这个时间不够,到 时候就是自己对PM的承诺过头了。应该给PM回信说明客观情况: 有些Team的时间自己估计不出来,需要开会讨论,让各Team的任务负责人自己估时间。下班前给PM一个最迟的答复期限。
PM在和lake定开发计划的前期,是让lake自己估时间,如果项目中发生一些延期之类的事情,只有硬着头皮,牺牲这20天中的双休来加班 了。但如果时间是没有商量的PM自己定的20天,最后不能按期交付,lake也只能把估计错误的责任丢给PM了。其实就是用了一个人性的优点,遵守诺言。
2. 不要所有的事情都反映到PM那里,要先弄清楚情况
这是风险控制的一个策略,做的过程中有些是可以通过沟通来控制的。比如合作的Team安排是新手做这个,做的质量和进度落后计划,这个就要自己 去和合作的Team协调了,让他们腾出资源来保障。PM不喜欢动不动就去找他解决问题的人,PM这个时候就是老板的心态:只要结果,过程中他参与的越少越 好。但有些不可控的事情是一定要尽早找PM解决的,比如说有人跑路了。
3. 记得感谢别人
当任务按时完成后,做的好的PM会发信给所有参与的人感谢大家的努力。但我们国内的公司好像很少有这种氛围的,感谢别人的话好像总是难说出口。 老板都一个观点,给你钱你就应该做事情,天经地义,难道还要我感谢你?
但很多外企的文化就有这一部分,我还记得第一次因为一个小的功能添加,不到十行代码搞定的事情,做完后PM发信感谢我的努力时的感觉。所以有机 会就感谢帮助过你的人,当面说也许有时候不太好意思,发个邮件总是可以的。QQ聊天的时候对MM需要厚脸皮才能说出来的话都一溜打出来了,发个邮件应该是 非常Easy的事情。
知道这些方法的人是很多的,就算以前不知道看过这个也知道了,如果被别人用这种方式驱动,那就积极配合,毕竟解决问题才是最好的结果,助人为快 乐之本嘛!