Archive For The “软件开发” Category
现在铺天盖地的购物广告动不动就告诉你立省多少多少，但实际上你可能根本就不需要那个破玩意儿，只是为了省多少而去购物了，灯你买回来那个玩意儿后，先不说你后期为了处理哪个玩意儿的投入，你到底是赚了还是赔了呢？那又不能一招被蛇咬，十年怕井绳，玩意儿还真有一次捞着了呢？ 记得看某个战争片的时候有个龙套（貌似还是个知识分子）跟里面说，下次在阵地上遇到敌人轰炸，就躲到以前的弹坑里好了，因为有数据显示炮弹落到同一个弹坑的概率极低，如果真落到你这个，那你也不用躲了。低到什么程度倒是没说。 这里就说到了数据，有理论依据了。 同样的工作中用某某方法你是性能高了，未来可扩展性也好了，但针对某个场景压根就不用考虑性能，人压根也不需要扩展，你费那个劲儿干嘛哦。那反过来说，现在某个功能上缝缝补补的勉强完成需求了，可能从现在时候是节约时间了，也提高“工作”的效率了，出来混迟早要还的，狗皮膏药总有无不住窟窿的时候，一旦被别人戳破，那真是自找的。这个角度到底是省时间了还是浪费了呢？ 类似的问题实际上还有不少，比如修改完用户密码后是应该保持客户登录还是应该跳转强制重新登录？那现在软件质量不好，到底不好到什么程度呢？那基于现在这个Team到底有多大的产能呢？ 诸如此类的问题，针对同一个项目中，可能不同工作经验的人给出的答案都不一样，很大程度上基于个体主观的感受来回答。你说改就改啊？凭啥要强制登录呢？你说我这东西不好就不好啊，微软还天天打补丁呢？有种你做的比我快。这类的声音此起彼伏。 那怎么说服各方都理解甚至认同你的想法呢？摆数据哦，针对不同的问题，设计几个大家认同的指标，各个指标都有详细的数据支持。 凡是是不是好，怀又坏到什么程度，在没有数据支撑的时候都是个体的吐槽，摆数据看5分钟，比你没事儿就觉得、认为半个小时要直观的多。当然数据只是结果，解读数据、分析数据背后的原因最后让大家达成一致才是关键。 这里只是说要达成一致，这个一致很有可能还是不对，但是至少team的理解是一致的，即使有难那也是同担啊。一个坑里刨食还互相掐架，累死！ P.S.刚刚给一哥们扎啤烧烤庆生，然后被叫去跟boss聊工作，忍不住想吐槽几句。吐槽，纯属吐槽！
If anything can go wrong, it will. 墨菲定律（英文名：Murphy’s Law），亦称莫非定律、莫非定理、或摩菲定理，是西方世界常用的俚语。墨菲定律主要内容是：事情如果有变坏的可能，不管这种可能性有多小，它总会发生。 项目实施很不顺利，小小总结+记录下想到的解决方法。 项目实施过程中总是试图说服客户将一些问题放到上线后来调整，为此会去做很多工作，虽然当时能让客户认同自己的观点，但是只要系统中有一些不愉快的插曲发生，客户随时会将前一秒的的应承推翻，黑下脸来，给我改完先。 这就是风险，根据 墨菲定律，这还是高风险呢，这时候就是考验PM的时候了。总结下这段时间的工作如果能做到以下几点应该能较好的控制这只风险怪兽。 1、内外部信息透明，别藏着掖着，让客户知晓现在的进度、大家的难点； 2、给客户的承诺一定要及时甚至超前兑现； 3、从业务角度跟客户沟通，试图说服客户能放到上线后调整的一定不会影响他业务； 4、管理好客户期望值，房子装修好了客厅是加不了水龙头的，但是要放个鱼缸还是有希望的； 5、及时反馈，对于客户提出来的要求快速给予反馈，反馈不等同于立即给出解决方案，及时客户知道提出问题现在处在哪个阶段； 6、积极主动，客户提出一个需求，发现系统中有类似其他的他可能会要求的地方，主动告知客户； 7、一份简明而清晰的需求汇总及完成表，客户也需要向领导汇报； 8、所谓信则灵，这个阶段是否能顺利推进很大程度取决于客户对PM(沟通人)的信赖，所以前面做的事情都是在给客户信心。 暂时就这么多想法了，实施完了再补充好。
2011-05-17 16:14:42秒，实现了Pre-Zero-Bug。那一刻我很兴奋，缓缓松了一口气，这口憋了18个月，请大家不要吝啬自己的掌声给自己一些掌声。（张继科）源代码行数：349249，表：147，视图：137，存储过程141，1 77，2 932 ，3 1565，4 164。 我这有一些关于咱们这个项目的故事、数据要跟大家分享，关于咱们这个项目的前世今生。