闲谈工作之工作效率课件

1、发达国家和不发达国家的区别在于生产效率 经济学开发计划和执行沟通其他开 发分析和设计开发测试开发分析和设计产品需求讲解会之后B：小D，啥时候作需求评审？D：刚才讲的很多，没听明白，还得回去好好琢磨琢磨三天后如何？B：哦需要这么长时间吗？D：嗯，刚才都没听懂，应该要这么久B：好吧（无可奈何）小D在经过三天的苦闷纠结之后，终于在第三天晚上开始动笔并完成了概要设计评审中D：B: 嗯，不错。不过这还是一个大的、笼统的架构，后续的呢？D：#$% 漫长的一周就这样过去了历经磨难之后，小D终于开始了梦寐以求的编码开发工作。 D：其实我还是比较模糊，只想到了大的模块，但是具体如何实现，还是不清楚。哎！闷着头做

2、吧，车到山前必有路。 越往后开发，越发现之前写的那个架构满足不了现在的需要。现在已经把之前的架构改了不少，而且还在不断的增加新方法，总是意外的发现一个新问题，这个解决了，另一个地方又出了问题。最后基本上，已经进入混战的状态。 原本计划两周完成，但三周都已经快过去了，还没进入可测状态。 还是在历经磨难之后，第一版终于上线了，欢呼一下。虽然实现的架构比之前改了很多，但形还在，勉勉强强能接受吧。一周之后，要扩展新的功能。B：小D，评估一下，给我个时间D：妈的，之前的架构没考虑到这种扩展，实现不了。领导，能不能给我一周，让我把架构改一下，要不然很难实现。要不三天吧？B： #$%小D花了一周的时间把之前

3、的架构重写了一下边写边骂：当初怎么就没想到以后可能要做这种类型的扩展，白浪费了一周时间。问题较大项目：缺少分析理论和方法不能快速的设计一个好的架构各类型项目：扩展性很差分析不够清晰不够细如何解决？缺少分析设计理论和方法对参与的每一个项目多总结，从中找出好的分析设计思路可以学习一下面向对象和UML，从中找到更为通用系统的分析设计理论和方法如何解决？扩展性较差逻辑层的扩展：从产品处了解近期可能的扩展，为这些做好准备实现层的扩展：从代码设计本身做好可扩展的准备如何解决？分析不够清晰不够细开始想不明白想绕过的事儿，你放心，它一定会在一个地方等着你，到时候会给你一个更大的“惊喜”理想的程度应该是能够画出

4、类以及类的方法、属性和事件。在小项目中这是必须的，在大项目中，可以在每个黑盒模块的开始阶段落实到这个程度。开 发B：这个需要多长时间？D：小case，有些功能库中已经有些包支持了，两天时间搞定B：good news一天之后D：shit 这包没法用呀，这接口名称，使用方式，输入输出太不通用了，想扩展也难。完蛋了，看来两天搞不定了。咋办呢？D：boss 两天有点困难，之前的包不能重用，再给我三天时间？B：草，不行，都跟Y定好了，多给你一天！结果：三天之后还是一个不能通用的包问题功能没有通用性，不能提高之后的开发效率技术债务会形成恶性循环技术债务：可有效实现到理想状态，而没有实现到理想状态的技术产品

5、。如何解决？做事要本着一个思路，要让做过的每一件事成为以后前进的阶梯多发现共性，多实现共性尽量提高组件和功能的可重用度，既可以提高自己的结构设计能力，又可以提高以后的开发效率，形成一个良性循环，而不是不断地生成技术债务D和E一些协作完成某项目，D负责实现底层D：嘿！XXX方法写好了，我提交了E：太好了，正等着用呢诶？不行呀，36行报错D：不可能，我感觉我写的没问题，我看看哦，还真是，我改改D：好了，我改好了，提交了E：我试试39行报错 #$%问题没有做好充分的测试。每个人要对自己的实现负责，要自己做好测试测 试Z：什么时候可测？D：我们快做好了，5点吧Z：好，那我叫交互、产品5点测试5点测试开

6、始了E：这是啥呀，这功能都跑不通，让我测试啥？D：哦，我们正在改呢，你先看看别的E：好吧这个也不行呀？C：这有个问题，我正在改呢E： #$%问题误把联调当成了测试广义的测试应该分为联调和测试两部分联调应该仅有前后端开发参与，保证不影响更多人的工作狭义测试的时候应该是一个功能无误的产品，保证所有参与测试人员的工作效率计划和执行C和D分别参与两个项目，周一开始了开发，都要在周四上线。到周三了C：诶，缺少页面！M，今天给我做页面吧？M：哦，好D：诶，缺少页面！M，今天给我做页面吧？M：！不行，时间已经安排给C了D：boss M时间安排不开，周四上线不了了B：为啥早没找M协调时间？D：E：哎，M，今天

7、给我作页面吧？问题没有计划会影响整个项目的进展，并浪费更多人的时间计划应该包括哪天开始，持续多长时间哪天开始取决于前置任务的计划，会帮助前置任务制定计划我们定一个好的计划，有可能会影响整个项目的参与人员形成一个可执行的计划；好的话，还会间接地影响到别的项目，形成一个计划。但是需要坚持和时间。2:00：D开始思考X这件事2:30：E通过msn说，发现一个bug，过来看看2:50：D和E一起看完了bug，重新开始思考X吧。刚才思考到什么地方了？想了半天想起来了，继续吧3:20：F发过了一封邮件，说看了一下，回了一下邮件。然后接着想X，还得重新开始想4:10：H过来说，帮我看个问题吧4:50：从H那

8、儿回来，X这事儿还得重新开始想半天马上就要过来了，X没有任何进展问题频繁的任务切换会严重降低效率尽量半天只做一件事儿每半天或者一天，专门安排一个时间处理零碎的小事儿，比如处理bug，答复疑问等等拒绝打扰需要一个安静的环境来完成任务你不希望那个别人打扰你，那就也不要去打扰别人D原本计划本周参与X，周四上线。周二时P：小D，一会儿我们开个会，讨论一下Y开了两个小时的会，会尾：P：小D，评估一下，多长时间可以做完D：半天可以做完P：好吧，那就抓紧时间，这周上线吧D：啊？我还要做X呢？P：这个比较着急D：好吧，半天还不算多R：小D，一会儿开个会，讨论一下ZD： #$%问题如何应对临时任务不要独自应承临

9、时任务，因为在详细分工的团队中，临时任务将绝不仅仅依赖于你一个人应该把临时任务抛给上层领导，让他们在宏观来考虑临时任务与当前任务的冲突，设定优先级沟 通思考点过多过频繁的沟通过少沟通形成信息不对称定时沟通过多过频繁的沟通应该出现在设计阶段、开发准备阶段和联调阶段设计阶段需要有集体智慧或者头脑风暴开发准备阶段需要密集沟通准备工作和讨论确定相互衔接的工作联调阶段需要密集发现和处理各种问题过多过频繁的沟通不应该出现在开发阶段和狭义测试阶段开发阶段，由于有之前的约定，因此不需要再进行过多的沟通。如果在这个阶段还在进行过多的沟通，那很有可能在设计和准备阶段，做的不全或者不够细致，这是危险的狭义测试阶段，

10、理论上问题不会多，对于问题的追踪是更重要的各阶段沟通形式分析设计阶段建议采用会议、邮件开发准备阶段建议采用Wiki、邮件、会议开发阶段建议采用Wiki、邮件联调阶段建议采用onenote测试阶段建议采用Bug系统过少沟通形成信息不对称主要体现在不同分工的人之间沟通过少，以及沟通的面不全不同分工的人之间沟通过少，主要存在于开发人员和产品人员之间，开发人员没有从产品人员处充分了解和追问需求开发人员和交互人员之间，开发人员没有详细了解交互开发人员和设计、交互人员之间，没有协定好协作计划和时间过少沟通形成信息不对称沟通的面不全，主要表现为，本来信息应该让A、B、C三个人知晓，但是现在只在A和B上传开了，C完全不了解。出现的原因是什么？很多时候是因为主要参与人员进行了单向的沟通，而且没有传递给所有参与人员定时沟通在开发阶段和测试阶段，是需要少进行沟通的，因为这时候会把时间单位划分的比较大（比如半天做一件事），但难免会有一些别的事，这时候可以采用定时沟通，每天设定固定的时间进行沟通，其他时候谢绝沟通，保证高效和高响应。在需要频繁沟通的时候，有时也可以采用这样的方式。其 它应该有个自己的详细计划计划要有优先级授人以鱼，不如授人以渔多想能为以后留下什么拒绝形式化自上而下和自下而上多发现，多总结后 记以上这些能够解决你的问