程序员怎样提高自己-学会提问

程序员怎样提高自己-学会提问

　　大家一定有体会，在一个新项目开始时和客户交流或和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的事情。

　　知道这些方法的人是很多的，就算以前不知道看过这个也知道了，如果被别人用这种方式驱动，那就积极配合，毕竟解决问题才是最好的结果，助人为快 乐之本嘛！