Oracle神谕

  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  284 随笔 :: 9 文章 :: 106 评论 :: 0 Trackbacks

#

独断:单个利益实体的考量
共谋:多个利益实体的考量
posted @ 2008-01-26 13:30 java世界畅谈 阅读(153) | 评论 (0)编辑 收藏

一般人认为回答问题是体现一个能力的重要表现,其实作为提问也是一个非常重要的能力体现。主要表现在以下几个方面:
(1)提问题之前,是不是自己对这个答案已经有更好的了解。如果这个问题已经有答案,是不是一定要问。
(2)合适的时间对合适的人问合适的问题。对你的老板、客户、供应商、同事等等。
(3)你提问题的目的是什么?是要解疑释惑,还是另有他用?
(4)三思而后问
(5)一般来说问题,不适合太长,否则你的问题究竟是什么?
(6)问题,你究竟想问什么问题,是否有效的传递给对方。
(7)注意语是
提问题的内容:
(1)你的担心点。
(2)如何做?哪一种方案更好
posted @ 2008-01-23 11:00 java世界畅谈 阅读(152) | 评论 (0)编辑 收藏

遇到这种情况如何办?你的顶头上司找到你的下属咨询一个事情,发送邮件,结果下属也回复这个邮件给上司。后来,这个邮件又发送到你这里,要我来看看。该如何做?

  第一,你的顶头上司找你的下属的目的是什么?是想参考一下他的意见还是想把这个事情交给他做?如果是参考一下他的意见,那没有关系,可能结合着一下看看,是不是又补充或者完善的地方。如果是想交给他处理,可能任务这个事情比较小一些,应该他可以单独处理好的,但是这个你就不适合去主动做这个事情,而是需要辅助指导这个事情完成。
  第二,后来交给你后,如何协调你与下属之间的关系,如何进行应对?其实关键大家还是沟通好,也不要不清不楚的,这样反而很是别扭。
   最后,其实对公司来说,只要Case能够真正有效的执行下去就OK,大家有这样的想法就可以很容易解决。
  其实一个公司的扁平化的管理也是很常见的现象。
posted @ 2008-01-21 14:12 java世界畅谈 阅读(130) | 评论 (0)编辑 收藏

功能是否完成?
测试结果如何?
文档编写是否完整?
遗留问题如何解决?
用户的接受情况如何?
项目的后续总结分析情况?
需要交付的还有什么遗漏?
开始事后项目分析。

posted @ 2008-01-21 10:32 java世界畅谈 阅读(163) | 评论 (0)编辑 收藏

  这两天为一个电子邮件的事情花了近一天的时间,其实也不是什么特别复杂的事情。感觉自己的手感确实没有以前好了,以前写代码那确实感觉真的是代码再写代码。
posted @ 2008-01-19 13:37 java世界畅谈 阅读(145) | 评论 (0)编辑 收藏

在我们日常的开发过程中,总是希望能够一夜建成大厦。但是冰冻三尺非一日之寒,很多东西是需要一点点的积累才能做好的。更多的是我们要去做,只有你做了,大楼才能接近完工。设计阶段很重要,但是在实际的操作过程中,还是需要有很多细节需要注意的。
如果进行改造原有的系统,特别是烂尾楼的处理,有很好的想法,但是如何在最短的时间内,将其进行改造成具有竞争力的产品。

posted @ 2008-01-14 15:09 java世界畅谈 阅读(157) | 评论 (0)编辑 收藏

PM,主要项目的管理人员,主要负责的是项目的交付、进度、风险、团队的管理工作等;但是一线的软件研发公司,不写代码,团队成员很难对你信服,因为技术是实现的关键。每日坚持半天左右的代码编写,也可用使自己保持对程序的敏感性,更了解我们程序员要什么,如何做得更好。

posted @ 2008-01-10 09:42 java世界畅谈 阅读(177) | 评论 (0)编辑 收藏

  为什么提出这样的问题?主要针对用户不知道自己需要的是什么东西。或者知道自己要的是什么东西,甚至对具体的功能也提出要求。一种是说,你看着办吧,你们做过的应该是什么样子的就什么样子?结果到最后的时候,这个东西要修改那个东西要修改;另外一种说,你就按照我说的做就可以了,我们的实际用户一定会用的不错的,另外我们设计了这么多的亮点和新特性,结果这个东西花了很大的代价形成,结果愣是实际用户迷茫,这么智能,可惜功能太冗余了,一点也不人性化。你真的对实际用户负责了么?
  出现这样的问题,大多是因为我们站在实际用户的角度进行深层次思考,不能仅仅站在软件功能的强大上,更不能只是针对用户IT负责人的功能进行盲从。我们对实际的应用负责,我们对用户负责。
  我们要真正从实际使用的具体情况出发,从用的角度出发,从用户的实际操作水平出发,你是实际的用户,你会怎样操作?可用、易用确实需要付出很大的代价。在有限的资源、时间、成本的情况下,如何能相对理想的方式解决确实一种艺术。
posted @ 2008-01-09 17:41 java世界畅谈 阅读(121) | 评论 (0)编辑 收藏

保持饥饿的状态
Hungry--------------------Do it!

posted @ 2008-01-09 13:29 java世界畅谈 阅读(155) | 评论 (0)编辑 收藏

失败:
(1)没有客户实践,盲目开发。
(2)技术路线调整,例如数据库迁移后放弃。
(3)对行业的把握不够。
新版本的升级如何做来做:
(1)清晰地知道自己在做什么,对项目进行清晰化、明确化。其中设计到业务的操作流程调整、功能新增。
(2)数据的串通,将单个业务功能点和整个业务流程进行全面串联。
(3)以客户为导向,以解决实际业务问题为导向。

posted @ 2008-01-07 15:26 java世界畅谈 阅读(161) | 评论 (0)编辑 收藏

仅列出标题
共29页: First 上一页 10 11 12 13 14 15 16 17 18 下一页 Last