首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 软件管理 > 软件开发 >

调查一上有多少人喜欢/反对写日报周报月报(写过项目代码的人才可以参与) 结束评语

2013-01-02 
调查一下有多少人喜欢/反对写日报周报月报(写过项目代码的人才可以参与)结束评语http://community.csdn.ne

调查一下有多少人喜欢/反对写日报周报月报(写过项目代码的人才可以参与) 结束评语
http://community.csdn.net/Games/GamePawn.aspx?id=113
这项调查持续了大约六个月之久(具体时间忘记了,不好意思,呵呵)。
结果如下:
A: 愿意并心甘情愿的写日报周报月报    7.78   4790 / 54 / 详细    
B: 不愿意/不想/根本不/强烈抵制写日报周报月报 1.11 38193 / 206 / 详细  
游戏说明:调查一下有多少人喜欢/反对写日报周报月报。写过项目代码的人才可以参与,其他人员我将设定另一个游戏供大家参与。
本调查时间比较长,可能会调整提前结束。希望能有足够多得人来参与,没人不用多,1分足够表示!

也就是说,B选项的选择人数几乎是A选项的4倍之多。
为了表示大家的心意和对分数的漠视,这次将分数送给了输掉选择的54位朋友。相信胜利者是不会有什么意见的。

这个选择项在我同样进行撰写的CSDN的年度调查报告中也有类似选项的表现,都说明了不合理的报告制度本身的问题。
如果想要评论,欢迎大家来评述,评论内容足够优秀的和参与过调查并且光荣的把分数送给了非正确答案的朋友可以得到本帖的得分——但是也需要您有自己的观点和看法的回复才好。

本贴非水贴,请大家不要大量灌水,欢迎关注。谢谢!
[解决办法]
我们是做外包的,好像大家对日报的态度还可以。但是没有月报,似乎有些官僚了。

我们的日报是保持项目高度透明的一种机制。比如,如果某天你只工作了4个小时,那就写4个小时,客户会觉得你值得信任。但是如果你写的是8小时而实际你只工作了6小时,一旦被客户发现,合作就很可能Over了。所以,诚实的日报可以增进信任,促进合作,反之则坏事。
[解决办法]
澄清一下,我是说写月报似乎有些官僚了。
[解决办法]
不只是记录时间,其实主要还是记录内容。

日报,周报,月报,那么多报真的有人看吗?
[解决办法]
大家之所以不愿意写,我觉得主要还是没有看到谁以及怎么用它,价值在哪里。开发人员大多数是不喜欢官僚作风的。
[解决办法]
并不是很情愿写周报,哪怕很简单的。
但是还是想实行周报,做过将做和问题三项。
[解决办法]

引用:
我们是做外包的,好像大家对日报的态度还可以。但是没有月报,似乎有些官僚了。 

我们的日报是保持项目高度透明的一种机制。比如,如果某天你只工作了4个小时,那就写4个小时,客户会觉得你值得信任。但是如果你写的是8小时而实际你只工作了6小时,一旦被客户发现,合作就很可能Over了。所以,诚实的日报可以增进信任,促进合作,反之则坏事。


我比较“讨厌”日报的原因就是因为如果规定每天工作8小时,那么程序员就要绞尽脑汁写足8小时中都干了什么,实际上这是非常无人性并且不得要领的。

我比较“喜欢”的风格是:程序员首先写明产品经理是如何说明任务规格的,以及计划用多少小时,而当天自己有多少小时才完成它(或者尚未完成)。也就是说,如果产品经理没有给出任务说明,那么程序员就可以做任何事,而如果有人认为浪费了时间这个责任应该在pm经理而不在程序员。我觉得这类日报写法才是以人为本的。
[解决办法]
那么程序员就可以做任何事  -->  那么程序员就可以做任何事而仅仅在日报中写明此时间段没有任务所以自己支配无需汇报
[解决办法]
引用:
引用:
我们是做外包的,好像大家对日报的态度还可以。但是没有月报,似乎有些官僚了。 

我们的日报是保持项目高度透明的一种机制。比如,如果某天你只工作了4个小时,那就写4个小时,客户会觉得你值得信任。但是如果你写的是8小时而实际你只工作了6小时,一旦被客户发现,合作就很可能Over了。所以,诚实的日报可以增进信任,促进合作,反之则坏事。 
 

我比较“讨厌”日报的原因就是因为如果…


就要看日报的内容和管理者的水平了


[解决办法]
其实开发人员的有效工作时间,一天能够达到6小时就相当优秀了
我开始要求组员的有效工作时间是4小时,后面才增加到5.5小时
[解决办法]
写周报月报还是比较有用的,能够对一段时间内的工作做个比较好的总结,以后也是评估项目的一个重要参考资料。

日报则无太大的必要,会增加不少工作量,而且会比较大的降低人的积极性。


[解决办法]
引用:
那么程序员就可以做任何事  -->  那么程序员就可以做任何事而仅仅在日报中写明此时间段没有任务所以自己支配无需汇报


从实际来看,如果一个开发人员因为没有可做的事情而在等待,我们会建议大家把等待的时间也做为一项写到工作报告中。这样的好处是客户知道他那里出问题了,而不是团队这边。大部分客户是接受这种方式的。而且,因为我们敢于暴露这些问题,所以客户对我们更加信任了。
[解决办法]
引用:
引用:
那么程序员就可以做任何事  -->  那么程序员就可以做任何事而仅仅在日报中写明此时间段没有任务所以自己支配无需汇报 
 

从实际来看,如果一个开发人员因为没有可做的事情而在等待,我们会建议大家把等待的时间也做为一项写到工作报告中。这样的好处是客户知道他那里出问题了,而不是团队这边。大部分客户是接受这种方式的。而且,因为我们敢于暴露这些问题,所以客户对我们更加信任了。


经理干什么去了。难道給了程序员任务什么就不管了?写日报只会整累程序员。有时候2天才搞定一个问题,那么两天在做同样一件事情。那经理搞什么去了。我只同意写周报,
[解决办法]
我的着重要点是:程序员只需要写“产品经理给我分配了什么任务,并且我完成了百分之多少,可以通过哪几个测试用例”,只要这样简单地写就可以了。而不应该让程序员自己去替经理来想具体任务规格说明。经理给程序员的任务定义应该尽量细致,只要没有明确地说明,程序员无需做也不应该做多余的事,多余的时间程序员干自己的事情应该被认为是程序员的权利。报告应该非常简单,其实程序员的报告的好坏责任在于是否有明确的任务说明,而不在程序员。在下达任务的时候就说明自己将如何测试产品质量,然后程序员的任务就是通过这些测试,而那种拿来程序员写出的报告之后才开始挑刺的做法是非常愚蠢的。
[解决办法]
写日报通常只需要5分钟就够了。
[解决办法]
在下达任务的时候就说明自己将如何测试产品质量  -->  在下达任务的时候就应该尽量完整地说明自己将如何测试产品质量
[解决办法]
引用:
写日报通常只需要5分钟就够了。


这是我们当初开发日报系统的一项需求
开发人员强烈要求的需求。很合理
[解决办法]
引用:
引用:
引用: 
那么程序员就可以做任何事  -->  那么程序员就可以做任何事而仅仅在日报中写明此时间段没有任务所以自己支配无需汇报 


从实际来看,如果一个开发人员因为没有可做的事情而在等待,我们会建议大家把等待的时间也做为一项写到工作报告中。这样的好处是客户知道他那里出问题了,而不是团队这边。大部分客户是接受这种方式的。而且,因为我们敢于暴露这些问题,…


在我们公司,经理没有权利强迫程序员做任何事情。程序员的工作都是自己从backlog中选出来的。团队里成员之间没有谁高谁低,谁上级谁下级之类的官僚体系,一切都是合作。程序员有权选择与某个项目经理合作,项目经理也有权选择与某个程序员而不与某个程序员合作。关系是松散的。大家只是角色不同,也就是职责不同。
[解决办法]
引用:
在我们公司,经理没有权利强迫程序员做任何事情。程序员的工作都是自己从backlog中选出来的。团队里成员之间没有谁高谁低,谁上级谁下级之类的官僚体系,一切都是合作。程序员有权选择与某个项目经理合作,项目经理也有权选择与某个程序员而不与某个程序员合作。关系是松散的。大家只是角色不同,也就是职责不同。


问题的关键就在于所谓backlog是否足够细致到通常只有1、2小时的程度,程序员是否可以直接知道测试标准,可以避免做多余的事。许多公司对产品特性的描述停留在官僚文档上,什么时髦的软件开发管理术语都用过,但是往往不能真正做到位,例如就是不懂如何写日报而只能写月报。
[解决办法]
不要把程序员的工作效率看的很绝对。我在一个有50人以上的开发团队中,客户的已经成熟的大系统需要改造升级,我发现,即使是非常明确地描述了编程逻辑的、一个程序员使用1、2小时进行开发的任务对用户通常要评估为3、4天才能测试完成,开发流程中有太多需要考虑(如果你没有细致地划分工作内容可能会以为这3天一直用于在编程,实际情况不是),这就是现实。可想而知,那些不够细致、没有可操作性的产品规格说明,很容易困扰程序员,或者让程序员看经理的笑话。

许多公司对产品特性的描述停留在官僚文档上,什么时髦的软件开发管理术语都用过,但是往往不能真正做到位,例如总是先编码然后才去制定测试标准(于是就马后炮地批评程序员的工作内容),这时候所谓日报自然就不敢写出来了。
[解决办法]
日报通常最多5分钟就可以写完了,这是很关键的指标。
[解决办法]
进度报告我想还是要有的。
对于管理者或者执行者来说,
养成良好的主动进度报告的习惯是很有帮助的。

[解决办法]
引用:
引用:
在我们公司,经理没有权利强迫程序员做任何事情。程序员的工作都是自己从backlog中选出来的。团队里成员之间没有谁高谁低,谁上级谁下级之类的官僚体系,一切都是合作。程序员有权选择与某个项目经理合作,项目经理也有权选择与某个程序员而不与某个程序员合作。关系是松散的。大家只是角色不同,也就是职责不同。 

问题的关键就在于所谓backlog是否足够细致到通常只有1、2小时的程度,程…


实际来看,产品经理或者说分析师能把工作能划分到8小时的粒度就很不错了。进一步的划分需要开发人员自己来完成。开发人员把自己划分出来的每一项填写到另一个列表上。这样就是每个开发人员都有自己的计划,项目经理有整体的计划。

[解决办法]
引用:
实际来看,产品经理或者说分析师能把工作能划分到8小时的粒度就很不错了。进一步的划分需要开发人员自己来完成。开发人员把自己划分出来的每一项填写到另一个列表上。这样就是每个开发人员都有自己的计划,项目经理有整体的计划。 


这中理论其实正是造成难以管理项目的所在。一个产品经理或者说分析师描述的的1、2小时的任务,往往需要3天才能确认通过,其中的猫腻是需要承认(需要有拖延)但是应该看清其机制的。看不清机制或者毫不关心,就难以管理项目,而跟任何代码工人都一样了。

很有趣,我主张让开发人员把自己划分出来的每一项填写到另一个列表上是极端成问题的,看看我上面的话,我的重点就是批评这种做法。开发人员可以不择手段地、随便地实现,只要可以通过任务验收测试。而任务验收测试是产品经理的工作范围,产品经理不是简单地发号施令就完了。
[解决办法]
为什么开发人员觉得日报愚蠢,我在10楼第一次回复时就说了,那种让开发人员来代替自己工作的产品经理或者说分析师,所作所为是不人性和不得要领的。


[解决办法]
含混的理论可以在学校中作为软件专业的研究生论文,但是用到实践中则可能连一个中专生都不如。日报之所以不能实行,就是因为产品经理或者说分析师的工作不是敏捷的而是妄图把责任分解给程序员。
[解决办法]

引用:
引用:
实际来看,产品经理或者说分析师能把工作能划分到8小时的粒度就很不错了。进一步的划分需要开发人员自己来完成。开发人员把自己划分出来的每一项填写到另一个列表上。这样就是每个开发人员都有自己的计划,项目经理有整体的计划。  

这中理论其实正是造成难以管理项目的所在。一个产品经理或者说分析师描述的的1、2小时的任务,往往需要3天才能确认通过,其中的猫腻是需要承认(需要有拖延…


那你的开发人员就都是机器零件了。
[解决办法]
其实,首先要确保产品经理或者分析师不是开发人员冒充的,而是名副其实的,这是最关键的。

我在另一个帖子中回复过:如果你做某些对日外包,很多人都清楚这种软件民工的地位确实是非常低的,那么讨论软件工程似乎没有必要,你变成一个日本人才涉及软件工程。

这个意思就是,在真正的比较主动的项目管理背景下(而不是那种比较低的下游环节的所谓管理背景下)的项目管理方法往往才是最为以人为本的。
[解决办法]
引用:
其实,首先要确保产品经理或者分析师不是开发人员冒充的,而是名副其实的,这是最关键的。 

我在另一个帖子中回复过:如果你做某些对日外包,很多人都清楚这种软件民工的地位确实是非常低的,那么讨论软件工程似乎没有必要,你变成一个日本人才涉及软件工程。 

这个意思就是,在真正的比较主动的项目管理背景下(而不是那种比较低的下游环节的所谓管理背景下)的项目管理方法往往才是最为以人为本的。


编码也是软件工程中很关键的一环,单纯只做编码的人为什么讨论软件工程没有必要呢?

软件民工地位不高,做编码的都是民工,这是不是有点歧视民工的意思啊,我们的高楼大厦没有民工光靠设计师能起来吗?
,编码的工作是相对处于底层,但却是最基础的工作,而且我们都是从民工做起来难道不是吗,何必要嘲笑自己的过去呢?

[解决办法]
写周报真累

老是忙的忘记写了

草草几句 感觉在记流水账
[解决办法]
引用:
写周报真累 

老是忙的忘记写了 

草草几句 感觉在记流水账


[解决办法]
我们现在是周报加月报,说实话有点不愿意写,但是老板要看,每个人基本都是捡好的说喽。
[解决办法]
传说中的weekly report啊

还是有点用的吧
[解决办法]
写不写,应不应该写日报,要似乎工作而定,有时候不能一概而论。

而且不应流于形式,如果流于形式的话,改成两天一报,周报也是没用。其实每天结束后,我们都应该总结一下一天的工作任务,整理一下思路,调整一下计划是必要的,而且在每一天开始工作时也需要静静地思考一下昨天的工作及遗留问题,以及今天计划上是否需要作出相应的调整,并有侧重点地去安排工作的优先顺序。

对于有人说,一两天才解决一个问题(编程上,或系统故障上的),做日报简直是浪费时间,这种看法更加不可取。一天到晚对着一个问题都搞不出一个所以然,更应该在一天工作结束时,做一个短暂的总结,整理一下这一天以来是否有不合理的地方,需要改进的地方,明天首要的工作任务是什么?这不需要花费多少时间。但这是否需要以规范的报告形式提交,这就需要经理们看如何把握了。究竟我们是以什么为单位进行日报?是以人为单位,还是以项目中分组为单位,还是以问题为单位,还是任务为单位......。报告的时间间隔上也需要进行考量,有些任务周期比较长,变化比较慢,如果天天做报告,别说做的人累,听的人也累。但有些变化快,周期短,需要有很强的监控措施的,日报是相对必要的手段。

就算以项目来说,不同的阶段也有不同的报告间隔,如果在测试阶段,问题比较多的时候,就需要日报,每天定时收集问题,进行分析并与前一天进行比较......。如果在维护阶段,可能只需要周报+紧急报告就可以了;而运营管理的则需要日报,每天输出运营报告......。

日报好,周报好,月报好,一定要清楚要报告什么.不要太官僚而流于形式。其实不同的报告汇报对象也不尽相同,如何用好报告不但是经理们的事情,也是下属必需掌握的技能。就如同如何使用Email一样,是有技巧的。收件人放谁?抄送人放谁?密送人放谁?是单独回复,还是全部回复?使用转发,还是使用回复,还是把邮件以附件方式发出?什么样的邮件应该使用什么的措辞?如何利用邮件进行关注度升级?回复的邮件是带原来内容,还是不带原有内容?......。

这是我个人经验之谈。
[解决办法]
其实写周报比日报好,基本没有什么东西一天能做完的,非要分出来百分之几,有够无聊的,也增加心理的压力
基础员工往往都是为了写日报而写日报,瞎编,或者对当前进度存在幻想,用他们认为的进度来标示实际进度,这是很不可取的,个人认为员工就用周报,让他们写日报是扯淡,两个人做一样工作都能写出两份进度来,项目经理可以做个人日报,然后根据日报总结周报,这样防止遗漏,粒度又不那么细,实际上,很少有公司能做到对日期粒度的追溯管理的,小的里程碑和周报就足够了吧。


[解决办法]
应该写一写,这样也有助于自己的开发:)

[解决办法]
引用:
写不写,应不应该写日报,要似乎工作而定,有时候不能一概而论。 

而且不应流于形式,如果流于形式的话,改成两天一报,周报也是没用。其实每天结束后,我们都应该总结一下一天的工作任务,整理一下思路,调整一下计划是必要的,而且在每一天开始工作时也需要静静地思考一下昨天的工作及遗留问题,以及今天计划上是否需要作出相应的调整,并有侧重点地去安排工作的优先顺序。 



对于有人说,一两天才解决一个问题(编程上,…



标记

学习~~
[解决办法]
日报就工作日记,把一些要素说清楚,如内容、完成情况、明天计划、经验与教训、学习心得等等。老板需要了解员工在干什么。
[解决办法]
记流水账..............
[解决办法]
日报对于考量各阶段的工作量,为后续项目开展提供经验数据很有帮助。
周报可以合在周例会中,对当前工作做一个总结:本周任务、完成度、存在问题、经验教训、下周任务。
[解决办法]
我是强烈反对写什么"Rerort".但老板就是喜欢"Rerort",要求每个员工都要写,但是每个人都觉得没有什么可写的,有时候一个星期只解决一、二个问题,"Rerort"就只把这几个问题写上,老板就会很不满,开会的时候就会批人,说有些员工啊"Rerort"都不会写, 小学生写的都比他好之类的话.
总之一句话,我老板喜欢"Rerort"写的漂亮的员工,这类员工的工资也升的比较快。
注:"Rerort"为老板语,他不喜欢说周报、月报之类的中文词汇。
[解决办法]
引用:
我是强烈反对写什么"Rerort".但老板就是喜欢"Rerort",要求每个员工都要写,但是每个人都觉得没有什么可写的,有时候一个星期只解决一、二个问题,"Rerort"就只把这几个问题写上,老板就会很不满,开会的时候就会批人,说有些员工啊"Rerort"都不会写, 小学生写的都比他好之类的话. 
总之一句话,我老板喜欢"Rerort"写的漂亮的员工,这类员工的工资也升的比较快。 
注:"Rerort"为老板语,他不喜欢说周报、月报之类的中文词汇。


哥们有时间也要想想为什么很多公司都要求这些报告,为什么他能成为领导,

如果真的都没有用,是不是这些公司的领导都是草包傻蛋,是不是这些公司都该倒闭了~~


[解决办法]
讨厌写周报,因为不会表现自己
[解决办法]
虽然现在没有团队,不需要向谁汇报,我还是保留着每天记录和总结,并为第二天工作做一个简单的计划

我觉得周报也是很重要的,周末两天肯定有人还在继续工作……比如你的Leader,尤其是创业型团队
所以每周5把自己的工作总结一下,方便别人在你不在的情况下继续工作

以前写月报通常都是为了算绩效用的,写的好奖金就多。。。通常每个月我都绩效都是1.1以上 :D
[解决办法]
自己开发了一个供部门使用的周报平台。
感觉周报这个东西还有点用,起码可以督促自己。另外等写的多了以后回头来看挺有意思的;非常有成就感。
[解决办法]
日报和月报就免了,周报还有点用。
[解决办法]
引用:
不要把程序员的工作效率看的很绝对。我在一个有50人以上的开发团队中,客户的已经成熟的大系统需要改造升级,我发现,即使是非常明确地描述了编程逻辑的、一个程序员使用1、2小时进行开发的任务对用户通常要评估为3、4天才能测试完成,开发流程中有太多需要考虑(如果你没有细致地划分工作内容可能会以为这3天一直用于在编程,实际情况不是),这就是现实。可想而知,那些不够细致、没有可操作性的产品规格说明,很容易困扰程序员…


在你提到的50个人的团队中,有多少是实现人员?有多少是设计人员?有多少是产品经理?是一个产品经理就把工作划分到2个小时以内的粒度了吗?
[解决办法]
我们要写日报.
不记录时间.就写一下今天都干吗了.
但是大家都不是很喜欢写.
有时候QA过来一个BUG两天才能改好.
项目快结束的时候可能一两天都没什么事情.
有时候真不知道该怎么写.
[解决办法]
为什么开发人员觉得日报愚蠢,我在10楼第一次回复时就说了,那种让开发人员来代替自己工作的产品经理或者说分析师,所作所为是不人性和不得要领的。
[解决办法]
日报应该这么写的。


。。。。。。。。。。
。。。。。。。。。。
。。。。。。。。。。
。。。。。。。。。。
(上面是日报内弄)
4:30-4:40 在想这一天做了什么。
4:40-4:50 整理了一下工作内容的顺序。
4:50-5:00 开始写日报。
5:00-以后 要门下班,要么加班。



后面4句话可以拷贝的每天的日报里了!


我呸。1天30分钟(0.5小时)   1年(356)   365*0.5大约183小时     183/24大约8天    
也就是一年的日报  你如果连续写的话就要写大概7天7夜,这不叫让费时间叫什么? 
[解决办法]
我反对
[解决办法]
我也写过,觉得很重要!!!每年可以了解自己到底做了什么!算是对自己负责把

[解决办法]
我觉得些日报没有必要,周报和月报可以简单的写一下,反应下自己做了些什么,遇到了些什么问题,有什么需要公司帮助的
------解决方案--------------------


B: 不愿意/不想/根本不/强烈抵制写日报周报月报 1.11 38193 / 206 / 详细  

我判断管理菜鸟的两个标准:
1,抓考勤
2,写日报

这是没本事的人干的,因为他实在没有别的招数了.

我鄙视之
[解决办法]
周报还可以,总结上周工作,计划下周工作;

日报就太扯了,

月报只有项目经理做.
[解决办法]
年报和月报可以接受
周报日报?我有时候一周都没写出1行代码,拿什么来报呢?
[解决办法]
我最不愿意干的就是写日报,项目都安排好了,写那个东西有什么用
[解决办法]

引用:
日报和月报就免了,周报还有点用。

up
[解决办法]
什么报都不用的。。。
[解决办法]
不过每天写写工作日志还能整理一下思路,也花不了几分钟,每周写的话,要想前几天都干了啥了,又舍不得漏了什么,反而更浪费时间精力。
[解决办法]
写周报,已经习惯了
[解决办法]
支持写日报,不然老板不知道你在做事。
[解决办法]
写日志的路过
[解决办法]
我是国家机关工作人员,只写年度总 结
[解决办法]
我很讨厌日报这个东西……流于形式而已!
[解决办法]
为什么不写, 明确目标, 反思过程, 每天不过5分钟, 给你带来绝对不止5分钟
[解决办法]
15.世界500强中没有几家要求员工写日志的,只是一些学院派的人指定制度让员工写日志 

不知道写这句话的仁兄是在哪家公司?500强中哪家不写日报,我很想知道,因为我还真不太清楚哪家不写?

而且说的话也矛盾,学院派指定制度写日志,到底这些公司有没有要求写日志?

500强的公司一般都有日报系统,规模小一点的公司也用excel管理,我不是太理解,为什么那么多家公司要写日报或者周报,难到这些公司的领导都疯了没事干,拿员工整着玩?这些人能成为领导也是有原因,不全都是靠PMP(拍马屁)上去的,这是管理的一部分,
当然我也从程序员做起当时也不希望被管理,但是坚持下来之后确实很有收获(为此我很感谢我的第一任项目经理,她正规的管理让我学到了很多东西),后来我自己管理项目的时候也意识到日报的重要,我分配一项任务给组员,事前有专家估算的计划工时,组员自己估计的工时,如果组员认为这项任务我12个小时做不完,可以提前与领导商议,是派人支援还是调整任务,总不至于到任务要交付的时候突然跑过来跟我说:“老大这个程序我搞不定了”,一般任务还ok,万一是关键任务,我的整个项目进度都要受影响(有些新人确实不知道这个程序能多长时间搞定,这是风险,肯定不会把关键任务给新手,等到他们写日报,估计工时稍微有点谱的时候再说,但怎么证明他开始估计的靠谱了,是需要日报记录的)。
尽管这些是可以通过standing meeting说一下,但是没有记录,也无法积累数据,你作为项目经理能挨个汇总每个组员的任务实际工时,计划工时?能做精确的EV分析?能对比实际和计划?

软件项目变换很快,以日为单位管理还是很必要的,当然仁者见仁智者见智,有项目经理不喜欢也能把项目管理的很好,我相信肯定有,但是在CMMI L5的组织中,数据很重要,这些数据的收集,必须有相应的机制或者系统支撑,而且如果你不统计这些,QA肯定会PPQA审计你,会招来一堆额外的工作量,我不是太理解大家所在公司的QA在审计的时候没有发现这些NC项,提出纠正措施吗?

一家之言仅供参考

[解决办法]
不喜欢

[解决办法]
引用:
我很讨厌日报这个东西……流于形式而已!


up ,up 
[解决办法]
我写日报就是总结今天干了什么,计划明天要干什么。
[解决办法]
我喜欢有计划做事。
[解决办法]
我公司写日报,而且由我带队开发公司的复杂日报系统,主要是为了提醒大家注意自己每天都做了什么,规划好个人工作。
不写月报和年报。
[解决办法]
引用:
我公司写日报,而且由我带队开发公司的复杂日报系统,主要是为了提醒大家注意自己每天都做了什么,规划好个人工作。 
不写月报和年报。


一般都有日报系统,没有的也用excel在管理
------解决方案--------------------


我是高软件的,没有日报周报月报,每做完一个案子自己都会总结,然后和小组人一起讨论分享其中的优与缺
[解决办法]
我是搞软件的,没有日报周报月报,每做完一个案子自己都会总结,然后和小组人一起讨论分享其中的优与缺
[解决办法]
一般都有日报系统,没有的也用excel在管理
同上
[解决办法]
我不要求部下写日报,因为我会及时跟进检查,而且我们有工作平台,什么时候都可以知道进度.
还有最重要的是,我和团队融为一体,他们都很努力工作,我随时看在眼里.
激励工作没做好,或者任务描述不清晰才是领导最大的失误,如果没本事领导,就只能挖空心思在日报考勤上做文章了.

公司要求大家写日报,日报只针对一些混混起作用,我分给混混的工作都是可以量化的,有区别对待.
一年来我努力开掉了9个混混,月薪5万的中层领导有5个.3个挽救不了的,还有几个没开,已经挽救的差不多了.
他们愿意跟着我工作.现在状态不错.
招聘的时候眼光很重要,混混都是老板招的,我又花了很大力气开掉,我招的人性价比都很高,没有混混.
[解决办法]
大家讨论了这么多,看得有点不想看了。每次遇到这种问题,都没有最终结论。

在这里讨论的,有的是纯粹的技术人员,有的是项目管理者,有的是软件工程的专家,也许还有其他的。各自的知识背景和职责不一样,所以大家对同一个事情的认同很难达到一致。其实在一个公司内都难以达到一致。还是不要讨论了。大家准备回家过年吧。

祝各位春节愉快,来年多加薪!
[解决办法]
coding的至少要写周报,便于本人记录工作和心得,以利于自己成长和提高。另外,项目经理拿到周报也有利于掌握项目进度情况。
[解决办法]
有感而发,有同感
[解决办法]
日报则无太大的必要,会增加不少工作量
[解决办法]
写日报是个好的习惯,但我讨厌这个习惯。
[解决办法]

引用:
我不要求部下写日报,因为我会及时跟进检查,而且我们有工作平台,什么时候都可以知道进度. 
还有最重要的是,我和团队融为一体,他们都很努力工作,我随时看在眼里. 
激励工作没做好,或者任务描述不清晰才是领导最大的失误,如果没本事领导,就只能挖空心思在日报考勤上做文章了. 

公司要求大家写日报,日报只针对一些混混起作用,我分给混混的工作都是可以量化的,有区别对待. 
一年来我努力开掉了9个混混,月薪5万的中层领导有5个.3…


工作平台中的进度是谁填写的,还应该是基层填写的吧?

这就是日报系统,只不过是你们工作平台中的一小部分而已

你们公司要求大家写日报,你这个领导不要求部下写(真是有power),还是你只给你的领导写日报?

你们公司的QA不会找你的麻烦吧

另外你的下属的工时effort是怎么统计的呢?不会不统计吧?
[解决办法]
引用:
我们要写日报. 
不记录时间.就写一下今天都干吗了. 
但是大家都不是很喜欢写. 
有时候QA过来一个BUG两天才能改好. 
项目快结束的时候可能一两天都没什么事情. 
有时候真不知道该怎么写.


一两天改好也有修改的进度可以报告啊

一两天没有事情,那你就把工作时间是怎么分配的写上去,你是学习了什么还是做了其他的


[解决办法]
CMM2CMMI
看你的名字就知道你是形式主义分子.
四个大字:软件工程想必也是纸上谈兵.
我年轻的时候也和你一样

QA归我管,嘿嘿,日报是我签字,但是我还是不提倡日报.
[解决办法]
我自己不写日报,因为下班的时候签字还忙不来呢.
日报我基本不看,但是每个不了解进度的人我都要过问一下.我不会等到日报的时候才发现问题.
过程更重要.有了好的过程不必担心结果.

热点排行