- 浏览: 400432 次
- 性别:
- 来自: 广州
文章分类
最新评论
-
xxbb77:
说的有点道理
保持好奇心,把时间花在刀刃上 -
JavaAiHaoZhezh:
有时候需要学会放手,别让自己太劳累 -
1011729483:
你好:楼主我想请问一下刚开始你访问项目进去login.jsp页 ...
菜鸟-手把手教你把Acegi应用到实际项目中(2) -
zhglance:
很赞,胜过好多出版物
程序员必备:Linux日常维护命令 -
zizhi9999:
为什么我的总是说timeout呢 很急 啊
利用SNMP获取、走访节点值
工作中学到的一点知识:
- 细分各模块。将项目的各个模块进行细分,细分为子任务,子任务可以根据实际情况进行再细分。
- 每周一开会。讨论本周或接下来两周的整体工作,具体要达到怎样的一个目标。
- 每周五开会总结。最好在下班前0.5-1小时时开会,不要占用项目成员的下班时间。总结本周所完成的工作,查看实际效果,将成果与预计的做一番比较,为项目进度做出更好的评估。(对下班后再开会总结感到反感)
- 控制项目进度。工作细分到1-2天,效率比较高。
- 对项目成员成果的确认。每当项目成员完成某个功能,无论大或小,都要进行确认。最后是在做完以后,项目成员主动发出通知,大家一起审阅一番,同时给出意见。这样能确保功能更加完善,减少后期积少成多各种不完善的修改。
- 让项目成员们更主动些。有下面几种情况经常会延误项目进度,使项目大大超出原有的预算:1)、遇到风险(代码实现上的)没向上级汇报 2)、开发过程中发现实际工作量超出原有的评估,未及时向上级汇报 3)、没完全清楚需求,就盲目的进行编码,等发现问题以后为时已晚。 看来许多都还是沟通问题
- 给项目成员一定的承诺。为了提高项目成员的工作激情,工作劳累的同时,要给予更多的鼓励,给予一定的承诺,前提是这个承诺一定要能够实现,不要让成员们认为你是在忽悠。
评论
26 楼
抛出异常的爱
2010-04-20
这个模型我用过
1.沟通成本过高(五人)
我个人一天几乎没有省余时间
我希望在个人技术比较成熟后
可以把模块分割大一点
达到自管理项目
但TEAM散了
2.周一讨论,周五总结是为免费加班准备的很不道德(很遗憾我也使用这个方式)。
5.现场演示一下
多找几个人十五分钟的演示
能找到QA 80%的问题
想实践冒烟测试代替这个东西没成功(有点太复杂了而且技术力量不够)
6.每周延个一天二天的延期不重要。
对外我都是忽悠过去的。
对内一般第二天早上都能找到问题核心,
找不到或作不到的问题挂起。
先完成主要大方向
(大方向这种东西一般不会出问题,出问题的都是特别情况,比如权限,生命周期过长等)
7.没有任何承诺。
我想要是人数大于8个跟本实践不了这些东西。
1.沟通成本过高(五人)
我个人一天几乎没有省余时间
我希望在个人技术比较成熟后
可以把模块分割大一点
达到自管理项目
但TEAM散了
2.周一讨论,周五总结是为免费加班准备的很不道德(很遗憾我也使用这个方式)。
5.现场演示一下
多找几个人十五分钟的演示
能找到QA 80%的问题
想实践冒烟测试代替这个东西没成功(有点太复杂了而且技术力量不够)
6.每周延个一天二天的延期不重要。
对外我都是忽悠过去的。
对内一般第二天早上都能找到问题核心,
找不到或作不到的问题挂起。
先完成主要大方向
(大方向这种东西一般不会出问题,出问题的都是特别情况,比如权限,生命周期过长等)
7.没有任何承诺。
我想要是人数大于8个跟本实践不了这些东西。
25 楼
shake822
2010-04-20
樓主的7點基本同意,不過有幾點有異議:
2.不用每天都要開會,如果項目大了,分的模塊也很多,有可以一個模塊不了解另一模塊,這樣大家在一起開會就沒有意義了,建議每天開發小組做工作回報.
5.沒有必要讓大家夠過來測試吧,大家都有自己的碼要編.而且對於我們編碼的來說,要嚴格按照文檔走,文檔上沒有的是不能做的,做了就是Bug,所以我們只能是修正bug,而不能完善功能
6.這點要教會組員拋出問題,如果是需求或是技術無法實現的問題,一定要拋出來,如果不拋出來你就要負責了.
7.激勵員工,可以把任務表每天都發給大家,並且把完成的任務標注下,給大家建立幾個里程碑,完成了就可以去吃飯了.這個效果挺好.
2.不用每天都要開會,如果項目大了,分的模塊也很多,有可以一個模塊不了解另一模塊,這樣大家在一起開會就沒有意義了,建議每天開發小組做工作回報.
5.沒有必要讓大家夠過來測試吧,大家都有自己的碼要編.而且對於我們編碼的來說,要嚴格按照文檔走,文檔上沒有的是不能做的,做了就是Bug,所以我們只能是修正bug,而不能完善功能
6.這點要教會組員拋出問題,如果是需求或是技術無法實現的問題,一定要拋出來,如果不拋出來你就要負責了.
7.激勵員工,可以把任務表每天都發給大家,並且把完成的任務標注下,給大家建立幾個里程碑,完成了就可以去吃飯了.這個效果挺好.
24 楼
sun_in_china
2009-12-16
mock1234 写道
你所说的项目管理,是一种没有项目蓝图的项目管理,是没有架构师知识背景下的项目管理。就好象一个包工头找一帮民工来盖楼,之前只是从废品堆中扒拉出一张设计草图。
其实架构和设计还是设计的关键点,只不过核心人物也许不会给你看。
设计者的作用占系统成败的70%以上,如果认为知道点功能点然后分工大家去分解就能代替系统设计,那么往往只能在小软件作坊里做赝品。实际上,如果设计文档可以注定其成功,那么才真正应该敢于继续去投资开发软件。现在有那么多搞软件的人失业,因此不缺抢着干空洞的功能分解工作的小程序员了,则更显出缺乏“先知先觉”的产品负责人了。
敏捷不是不做设计,只是换了一种看问题的角度而已,只不过把过去用教条方式说出来的“计划”现在用测试代码来写,写不出测试代码说明对应的设计也不现实。因此推动了注重扩展性、注重实用性的风格。
学敏捷的人也容易犯一个毛病:回避一个软件真正的技术问题而仅仅抓住一些行政问题,对设计问题张口闭口总是“到时候我会分工给手下人加班加点”来代替提出真正令人信服的系统设计文档,这过于急功近利过于对流行东西现学现卖。尽管知道做任务计划要细分到1、2天,尽管知道布置任务要说的清清楚楚,但是其实是加大了技术难度而不是减少了技术难度!所以既要做细又要做对,就只有更少的真正有经验的PM才能做好,一般人是做不好的。
如果没有掌握很深入很过硬的设计和测试技术(头脑中有独特的理论方法、手中有自己开发的工具),那么单纯去模仿敏捷就会变得很虚伪——其实单纯模仿敏捷跟鼠目寸光有什么区别?时间长了人品也变得虚伪了,所以敏捷绝对是有害的东西,只有真正的架构师、产品设计师才能偷偷研习。
敏捷原理只要知道就可以了,好好研究它技术的一面吧!
其实架构和设计还是设计的关键点,只不过核心人物也许不会给你看。
设计者的作用占系统成败的70%以上,如果认为知道点功能点然后分工大家去分解就能代替系统设计,那么往往只能在小软件作坊里做赝品。实际上,如果设计文档可以注定其成功,那么才真正应该敢于继续去投资开发软件。现在有那么多搞软件的人失业,因此不缺抢着干空洞的功能分解工作的小程序员了,则更显出缺乏“先知先觉”的产品负责人了。
敏捷不是不做设计,只是换了一种看问题的角度而已,只不过把过去用教条方式说出来的“计划”现在用测试代码来写,写不出测试代码说明对应的设计也不现实。因此推动了注重扩展性、注重实用性的风格。
学敏捷的人也容易犯一个毛病:回避一个软件真正的技术问题而仅仅抓住一些行政问题,对设计问题张口闭口总是“到时候我会分工给手下人加班加点”来代替提出真正令人信服的系统设计文档,这过于急功近利过于对流行东西现学现卖。尽管知道做任务计划要细分到1、2天,尽管知道布置任务要说的清清楚楚,但是其实是加大了技术难度而不是减少了技术难度!所以既要做细又要做对,就只有更少的真正有经验的PM才能做好,一般人是做不好的。
如果没有掌握很深入很过硬的设计和测试技术(头脑中有独特的理论方法、手中有自己开发的工具),那么单纯去模仿敏捷就会变得很虚伪——其实单纯模仿敏捷跟鼠目寸光有什么区别?时间长了人品也变得虚伪了,所以敏捷绝对是有害的东西,只有真正的架构师、产品设计师才能偷偷研习。
敏捷原理只要知道就可以了,好好研究它技术的一面吧!
PM 和 架构设计师 不是一个概念。
搞混了吧?!
23 楼
phoenix1100
2009-12-06
<div class="quote_title">hotjava 写道</div>
<div class="quote_div">
<div class="quote_title">zhanjia 写道</div>
<div class="quote_div">
<p>工作中学到的一点知识:</p>
<ol>
<li>细分各模块。将项目的各个模块进行细分,细分为子任务,子任务可以根据实际情况进行再细分。<br>
</li>
<li>每周一开会。讨论本周或接下来两周的整体工作,具体要达到怎样的一个目标。</li>
<li>每周五开会总结。最好在下班前0.5-1小时时开会,不要占用项目成员的下班时间。总结本周所完成的工作,查看实际效果,将成果与预计的做一番比较,为项目进度做出更好的评估。(对下班后再开会总结感到反感)<br>
</li>
<li>控制项目进度。工作细分到1-2天,效率比较高。</li>
<li>对项目成员成果的确认。每当项目成员完成某个功能,无论大或小,都要进行确认。最后是在做完以后,项目成员主动发出通知,大家一起审阅一番,同时给出意见。这样能确保功能更加完善,减少后期积少成多各种不完善的修改。</li>
<li>让项目成员们更主动些。有下面几种情况经常会延误项目进度,使项目大大超出原有的预算:1)、遇到风险(代码实现上的)没向上级汇报 2)、开发过程中发现实际工作量超出原有的评估,未及时向上级汇报 3)、没完全清楚需求,就盲目的进行编码,等发现问题以后为时已晚。 看来许多都还是沟通问题<br>
</li>
<li>给项目成员一定的承诺。为了提高项目成员的工作激情,工作劳累的同时,要给予更多的鼓励,给予一定的承诺,前提是这个承诺一定要能够实现,不要让成员们认为你是在忽悠。</li>
</ol>
</div>
<p> </p>
<p>1.各个模块的细分是在概要设计和详细设计中体现的。 属于设计范畴。任务划分不仅仅是功能点同步。 比如搭建数据库环境, 同步数据, 接口讨论等,都不是功能点,因此要创建WBS进行管理, 任务划分粒度与你的资源有关, 资源就是干活的人, 对于能力强的人,那么任务粒度就可以粗一些, 对于能力较弱的或者责任心不强的人, 任务粒度就要细一些。 这个需要磨合。 没有能一概而论的。</p>
<p> </p>
<p>2、3周一开会, 周五开会, 或者,上午开晨会,下午开晚会。 都不是我喜欢的做法。 开会最浪费时间, 要集齐那么多人, 要打算人家手里的活,思维。要等人。要找会议室。会上一堆人事不关己。 总之, 我向往的沟通方式是随时沟通, 精确沟通, 没有固定的时间和形式。 大多数时间不需要会议记录。 除非重要的。你需要整天沟通, 而不是会上那一点点时间进行沟通。 </p>
<p> </p>
<p>4.控制项目进度, 控制进度的最好办法是进行良好的设计和准确预测风险。在业务讨论不清的情况下,开发时间无法控制,也许你完成了,但是要返工。这种情况最难把握。工作原则上,我喜欢控制到半天, 一上午或者一下午。这样至少一天会有两次正式沟通。便于掌握项目情况。</p>
<p> </p>
<p>5。这个最麻烦,有时候感觉项目经理就是个测试人员。</p>
<p> </p>
<p>6、7 我唯一能给组员的激励性的承诺就是,咱们上班的时候好好干,下班就不用加班了。。。。仅此而已。</p>
<p> </p>
<p> </p>
</div>
<p>5.是不是说项目经理需要review全部的source啊。那么项目经理还有时间去做管理方面的事情吗?</p>
<div class="quote_div">
<div class="quote_title">zhanjia 写道</div>
<div class="quote_div">
<p>工作中学到的一点知识:</p>
<ol>
<li>细分各模块。将项目的各个模块进行细分,细分为子任务,子任务可以根据实际情况进行再细分。<br>
</li>
<li>每周一开会。讨论本周或接下来两周的整体工作,具体要达到怎样的一个目标。</li>
<li>每周五开会总结。最好在下班前0.5-1小时时开会,不要占用项目成员的下班时间。总结本周所完成的工作,查看实际效果,将成果与预计的做一番比较,为项目进度做出更好的评估。(对下班后再开会总结感到反感)<br>
</li>
<li>控制项目进度。工作细分到1-2天,效率比较高。</li>
<li>对项目成员成果的确认。每当项目成员完成某个功能,无论大或小,都要进行确认。最后是在做完以后,项目成员主动发出通知,大家一起审阅一番,同时给出意见。这样能确保功能更加完善,减少后期积少成多各种不完善的修改。</li>
<li>让项目成员们更主动些。有下面几种情况经常会延误项目进度,使项目大大超出原有的预算:1)、遇到风险(代码实现上的)没向上级汇报 2)、开发过程中发现实际工作量超出原有的评估,未及时向上级汇报 3)、没完全清楚需求,就盲目的进行编码,等发现问题以后为时已晚。 看来许多都还是沟通问题<br>
</li>
<li>给项目成员一定的承诺。为了提高项目成员的工作激情,工作劳累的同时,要给予更多的鼓励,给予一定的承诺,前提是这个承诺一定要能够实现,不要让成员们认为你是在忽悠。</li>
</ol>
</div>
<p> </p>
<p>1.各个模块的细分是在概要设计和详细设计中体现的。 属于设计范畴。任务划分不仅仅是功能点同步。 比如搭建数据库环境, 同步数据, 接口讨论等,都不是功能点,因此要创建WBS进行管理, 任务划分粒度与你的资源有关, 资源就是干活的人, 对于能力强的人,那么任务粒度就可以粗一些, 对于能力较弱的或者责任心不强的人, 任务粒度就要细一些。 这个需要磨合。 没有能一概而论的。</p>
<p> </p>
<p>2、3周一开会, 周五开会, 或者,上午开晨会,下午开晚会。 都不是我喜欢的做法。 开会最浪费时间, 要集齐那么多人, 要打算人家手里的活,思维。要等人。要找会议室。会上一堆人事不关己。 总之, 我向往的沟通方式是随时沟通, 精确沟通, 没有固定的时间和形式。 大多数时间不需要会议记录。 除非重要的。你需要整天沟通, 而不是会上那一点点时间进行沟通。 </p>
<p> </p>
<p>4.控制项目进度, 控制进度的最好办法是进行良好的设计和准确预测风险。在业务讨论不清的情况下,开发时间无法控制,也许你完成了,但是要返工。这种情况最难把握。工作原则上,我喜欢控制到半天, 一上午或者一下午。这样至少一天会有两次正式沟通。便于掌握项目情况。</p>
<p> </p>
<p>5。这个最麻烦,有时候感觉项目经理就是个测试人员。</p>
<p> </p>
<p>6、7 我唯一能给组员的激励性的承诺就是,咱们上班的时候好好干,下班就不用加班了。。。。仅此而已。</p>
<p> </p>
<p> </p>
</div>
<p>5.是不是说项目经理需要review全部的source啊。那么项目经理还有时间去做管理方面的事情吗?</p>
22 楼
yiding_he
2009-12-01
项目是由人组成的,对项目的管理是对人的管理的一个子集。所以任何对项目的管理方式绝不能违背对人的管理的原则。时常提醒自己这点,才能避免失败。
21 楼
terryh
2009-11-29
tuti 写道
把自己看做是代码工人的人,也只能看到这些东西。
说别人的同时请拿出自己的东西,否则只会被大家鄙视。
20 楼
aishangtao
2009-09-20
不错, 学习了。实际项目开发就应该这样
19 楼
star022
2009-09-20
tuti 写道
把自己看做是代码工人的人,也只能看到这些东西。
楼主只是很谦虚罢了。
18 楼
star022
2009-09-20
<div class="quote_title">hiwzg 写道</div>
<div class="quote_div">
<div class="quote_title">同RE。可以多看看软件项目管理方面的知识,在日常工作中多体会。</div>
<div class="quote_title">ybbkd2 写道</div>
<div class="quote_div">
<div class="quote_title">zhanjia 写道</div>
<div class="quote_div">
<p>工作中学到的一点知识:</p>
<ol>
<li>细分各模块。将项目的各个模块进行细分,细分为子任务,子任务可以根据实际情况进行再细分。<br>
</li>
<li>每周一开会。讨论本周或接下来两周的整体工作,具体要达到怎样的一个目标。</li>
<li>每周五开会总结。最好在下班前0.5-1小时时开会,不要占用项目成员的下班时间。总结本周所完成的工作,查看实际效果,将成果与预计的做一番比较,为项目进度做出更好的评估。(对下班后再开会总结感到反感)<br>
</li>
<li>控制项目进度。工作细分到1-2天,效率比较高。</li>
<li>对项目成员成果的确认。每当项目成员完成某个功能,无论大或小,都要进行确认。最后是在做完以后,项目成员主动发出通知,大家一起审阅一番,同时给出意见。这样能确保功能更加完善,减少后期积少成多各种不完善的修改。</li>
<li>让项目成员们更主动些。有下面几种情况经常会延误项目进度,使项目大大超出原有的预算:1)、遇到风险(代码实现上的)没向上级汇报 2)、开发过程中发现实际工作量超出原有的评估,未及时向上级汇报 3)、没完全清楚需求,就盲目的进行编码,等发现问题以后为时已晚。 看来许多都还是沟通问题<br>
</li>
<li>给项目成员一定的承诺。为了提高项目成员的工作激情,工作劳累的同时,要给予更多的鼓励,给予一定的承诺,前提是这个承诺一定要能够实现,不要让成员们认为你是在忽悠。</li>
</ol>
</div>
<p><br>建议楼主系统的去学习一下项目管理知识,有很多培训班,即学习知识又能混个证书,如果运气好的话:)</p>
<p> </p>
<p> </p>
<p> </p>
</div>
<p> </p>
</div>
<p>项目研发的最佳实践就是:在实际项目中的发现,反思,改进和总结!</p>
<p>楼主是个善于总结的人。</p>
<div class="quote_div">
<div class="quote_title">同RE。可以多看看软件项目管理方面的知识,在日常工作中多体会。</div>
<div class="quote_title">ybbkd2 写道</div>
<div class="quote_div">
<div class="quote_title">zhanjia 写道</div>
<div class="quote_div">
<p>工作中学到的一点知识:</p>
<ol>
<li>细分各模块。将项目的各个模块进行细分,细分为子任务,子任务可以根据实际情况进行再细分。<br>
</li>
<li>每周一开会。讨论本周或接下来两周的整体工作,具体要达到怎样的一个目标。</li>
<li>每周五开会总结。最好在下班前0.5-1小时时开会,不要占用项目成员的下班时间。总结本周所完成的工作,查看实际效果,将成果与预计的做一番比较,为项目进度做出更好的评估。(对下班后再开会总结感到反感)<br>
</li>
<li>控制项目进度。工作细分到1-2天,效率比较高。</li>
<li>对项目成员成果的确认。每当项目成员完成某个功能,无论大或小,都要进行确认。最后是在做完以后,项目成员主动发出通知,大家一起审阅一番,同时给出意见。这样能确保功能更加完善,减少后期积少成多各种不完善的修改。</li>
<li>让项目成员们更主动些。有下面几种情况经常会延误项目进度,使项目大大超出原有的预算:1)、遇到风险(代码实现上的)没向上级汇报 2)、开发过程中发现实际工作量超出原有的评估,未及时向上级汇报 3)、没完全清楚需求,就盲目的进行编码,等发现问题以后为时已晚。 看来许多都还是沟通问题<br>
</li>
<li>给项目成员一定的承诺。为了提高项目成员的工作激情,工作劳累的同时,要给予更多的鼓励,给予一定的承诺,前提是这个承诺一定要能够实现,不要让成员们认为你是在忽悠。</li>
</ol>
</div>
<p><br>建议楼主系统的去学习一下项目管理知识,有很多培训班,即学习知识又能混个证书,如果运气好的话:)</p>
<p> </p>
<p> </p>
<p> </p>
</div>
<p> </p>
</div>
<p>项目研发的最佳实践就是:在实际项目中的发现,反思,改进和总结!</p>
<p>楼主是个善于总结的人。</p>
17 楼
hotjava
2009-09-10
<div class="quote_title">zhanjia 写道</div>
<div class="quote_div">
<div class="quote_title">hotjava 写道</div>
<div class="quote_div">
<div class="quote_title">zhanjia 写道</div>
<div class="quote_div">
<p>工作中学到的一点知识:</p>
<ol>
<li>细分各模块。将项目的各个模块进行细分,细分为子任务,子任务可以根据实际情况进行再细分。<br>
</li>
<li>每周一开会。讨论本周或接下来两周的整体工作,具体要达到怎样的一个目标。</li>
<li>每周五开会总结。最好在下班前0.5-1小时时开会,不要占用项目成员的下班时间。总结本周所完成的工作,查看实际效果,将成果与预计的做一番比较,为项目进度做出更好的评估。(对下班后再开会总结感到反感)<br>
</li>
<li>控制项目进度。工作细分到1-2天,效率比较高。</li>
<li>对项目成员成果的确认。每当项目成员完成某个功能,无论大或小,都要进行确认。最后是在做完以后,项目成员主动发出通知,大家一起审阅一番,同时给出意见。这样能确保功能更加完善,减少后期积少成多各种不完善的修改。</li>
<li>让项目成员们更主动些。有下面几种情况经常会延误项目进度,使项目大大超出原有的预算:1)、遇到风险(代码实现上的)没向上级汇报 2)、开发过程中发现实际工作量超出原有的评估,未及时向上级汇报 3)、没完全清楚需求,就盲目的进行编码,等发现问题以后为时已晚。 看来许多都还是沟通问题<br>
</li>
<li>给项目成员一定的承诺。为了提高项目成员的工作激情,工作劳累的同时,要给予更多的鼓励,给予一定的承诺,前提是这个承诺一定要能够实现,不要让成员们认为你是在忽悠。</li>
</ol>
</div>
<p> </p>
<p>1.各个模块的细分是在概要设计和详细设计中体现的。 属于设计范畴。任务划分不仅仅是功能点同步。 比如搭建数据库环境, 同步数据, 接口讨论等,都不是功能点,因此要创建WBS进行管理, 任务划分粒度与你的资源有关, 资源就是干活的人, 对于能力强的人,那么任务粒度就可以粗一些, 对于能力较弱的或者责任心不强的人, 任务粒度就要细一些。 这个需要磨合。 没有能一概而论的。</p>
<p> </p>
<p>2、3周一开会, 周五开会, 或者,上午开晨会,下午开晚会。 都不是我喜欢的做法。 开会最浪费时间, 要集齐那么多人, 要打算人家手里的活,思维。要等人。要找会议室。会上一堆人事不关己。 总之, 我向往的沟通方式是随时沟通, 精确沟通, 没有固定的时间和形式。 大多数时间不需要会议记录。 除非重要的。你需要整天沟通, 而不是会上那一点点时间进行沟通。 </p>
<p> </p>
<p>4.控制项目进度, 控制进度的最好办法是进行良好的设计和准确预测风险。在业务讨论不清的情况下,开发时间无法控制,也许你完成了,但是要返工。这种情况最难把握。工作原则上,我喜欢控制到半天, 一上午或者一下午。这样至少一天会有两次正式沟通。便于掌握项目情况。</p>
<p> </p>
<p>5。这个最麻烦,有时候感觉项目经理就是个测试人员。</p>
<p> </p>
<p>6、7 我唯一能给组员的激励性的承诺就是,咱们上班的时候好好干,下班就不用加班了。。。。仅此而已。</p>
<p> </p>
<p> </p>
</div>
<p> </p>
<p>1、现在基本都是几十万的项目,其实大多数需求都是经理们自己在提,自己做Demo给客户看,引导出客户的新需求,总感觉是为了赚钱而在忽悠,但如果不是这样的话恐怕又没什么项目做了...。有些需求很虚,有些比较实在</p>
<p> </p>
<p>2、开会一般周一还是会开,会提一提本周大概要完成哪些工作,上周完成了哪些工作。其他时间的开会就比较灵活了,看具体情况。如果这块工作需要两个人来做,那么会找那两个人到小的会议室友聊一下,分配一下任务。如果工作需要所有人参与,那么会叫大家一起去开会,其实也就那么四五人,不多。</p>
<p> </p>
<p>3、任务的分配与工作完成情况的确认,经理喜欢采取半天、一天、两天的形式进行,这样给我们开发人员有一定的压力,效率可能会高点,不好偷懒。不定时的加班,项目开发过程中,偶尔都会有一些加班,时间长短看项目需要,一会儿、半个小时、两个小时、周末一/两天。</p>
<p> </p>
<p>4、承诺倒没咋的,反正看部门的目标,如果达不到预定的金额,奖金就很少。如果超出了,纯利越多,奖金就会多一些。如此而已</p>
</div>
<p><br>1.你最好先看看合同, 看看技术方案建议书,看看客户的建设目标是什么,别做了一大堆看起来很像样的东西, 结果客户的根本问题没解决。几十万的项目不过是小项目。满足其建设目标就好了, 乱七八糟的不做。 </p>
<p> </p>
<p>2.周会看个人爱好,有的有官瘾的人天天开我也没意见。 不过,不要浪费别人太多时间。 设计的东西,找张纸,弄个小黑板就OK了, 别再借什么投影仪。我做为一个组员根本不关心别人干了什么。 我只关心我的任务和工作。 别人演讲的时候我一般都睡觉。 我做项目经理的时候, 别人不用向我汇报, 我就知道他们干了什么, 你说这周会有必要开么?除非你的项目特别大, 组织机构复杂, 你下面还有组长, 还有项目经理。这时候才必要。</p>
<p> </p>
<p>3.水平低的分到一小时, 水平高的分到一周。 因人而异。 对于水平高的人, 设计讨论清楚了, 代码随便写去吧。 我是不管的。</p>
<p> </p>
<p>4.利益分配不是你我这个层次的人能够决定的。</p>
<p> </p>
<p> </p>
<p> </p>
<div class="quote_div">
<div class="quote_title">hotjava 写道</div>
<div class="quote_div">
<div class="quote_title">zhanjia 写道</div>
<div class="quote_div">
<p>工作中学到的一点知识:</p>
<ol>
<li>细分各模块。将项目的各个模块进行细分,细分为子任务,子任务可以根据实际情况进行再细分。<br>
</li>
<li>每周一开会。讨论本周或接下来两周的整体工作,具体要达到怎样的一个目标。</li>
<li>每周五开会总结。最好在下班前0.5-1小时时开会,不要占用项目成员的下班时间。总结本周所完成的工作,查看实际效果,将成果与预计的做一番比较,为项目进度做出更好的评估。(对下班后再开会总结感到反感)<br>
</li>
<li>控制项目进度。工作细分到1-2天,效率比较高。</li>
<li>对项目成员成果的确认。每当项目成员完成某个功能,无论大或小,都要进行确认。最后是在做完以后,项目成员主动发出通知,大家一起审阅一番,同时给出意见。这样能确保功能更加完善,减少后期积少成多各种不完善的修改。</li>
<li>让项目成员们更主动些。有下面几种情况经常会延误项目进度,使项目大大超出原有的预算:1)、遇到风险(代码实现上的)没向上级汇报 2)、开发过程中发现实际工作量超出原有的评估,未及时向上级汇报 3)、没完全清楚需求,就盲目的进行编码,等发现问题以后为时已晚。 看来许多都还是沟通问题<br>
</li>
<li>给项目成员一定的承诺。为了提高项目成员的工作激情,工作劳累的同时,要给予更多的鼓励,给予一定的承诺,前提是这个承诺一定要能够实现,不要让成员们认为你是在忽悠。</li>
</ol>
</div>
<p> </p>
<p>1.各个模块的细分是在概要设计和详细设计中体现的。 属于设计范畴。任务划分不仅仅是功能点同步。 比如搭建数据库环境, 同步数据, 接口讨论等,都不是功能点,因此要创建WBS进行管理, 任务划分粒度与你的资源有关, 资源就是干活的人, 对于能力强的人,那么任务粒度就可以粗一些, 对于能力较弱的或者责任心不强的人, 任务粒度就要细一些。 这个需要磨合。 没有能一概而论的。</p>
<p> </p>
<p>2、3周一开会, 周五开会, 或者,上午开晨会,下午开晚会。 都不是我喜欢的做法。 开会最浪费时间, 要集齐那么多人, 要打算人家手里的活,思维。要等人。要找会议室。会上一堆人事不关己。 总之, 我向往的沟通方式是随时沟通, 精确沟通, 没有固定的时间和形式。 大多数时间不需要会议记录。 除非重要的。你需要整天沟通, 而不是会上那一点点时间进行沟通。 </p>
<p> </p>
<p>4.控制项目进度, 控制进度的最好办法是进行良好的设计和准确预测风险。在业务讨论不清的情况下,开发时间无法控制,也许你完成了,但是要返工。这种情况最难把握。工作原则上,我喜欢控制到半天, 一上午或者一下午。这样至少一天会有两次正式沟通。便于掌握项目情况。</p>
<p> </p>
<p>5。这个最麻烦,有时候感觉项目经理就是个测试人员。</p>
<p> </p>
<p>6、7 我唯一能给组员的激励性的承诺就是,咱们上班的时候好好干,下班就不用加班了。。。。仅此而已。</p>
<p> </p>
<p> </p>
</div>
<p> </p>
<p>1、现在基本都是几十万的项目,其实大多数需求都是经理们自己在提,自己做Demo给客户看,引导出客户的新需求,总感觉是为了赚钱而在忽悠,但如果不是这样的话恐怕又没什么项目做了...。有些需求很虚,有些比较实在</p>
<p> </p>
<p>2、开会一般周一还是会开,会提一提本周大概要完成哪些工作,上周完成了哪些工作。其他时间的开会就比较灵活了,看具体情况。如果这块工作需要两个人来做,那么会找那两个人到小的会议室友聊一下,分配一下任务。如果工作需要所有人参与,那么会叫大家一起去开会,其实也就那么四五人,不多。</p>
<p> </p>
<p>3、任务的分配与工作完成情况的确认,经理喜欢采取半天、一天、两天的形式进行,这样给我们开发人员有一定的压力,效率可能会高点,不好偷懒。不定时的加班,项目开发过程中,偶尔都会有一些加班,时间长短看项目需要,一会儿、半个小时、两个小时、周末一/两天。</p>
<p> </p>
<p>4、承诺倒没咋的,反正看部门的目标,如果达不到预定的金额,奖金就很少。如果超出了,纯利越多,奖金就会多一些。如此而已</p>
</div>
<p><br>1.你最好先看看合同, 看看技术方案建议书,看看客户的建设目标是什么,别做了一大堆看起来很像样的东西, 结果客户的根本问题没解决。几十万的项目不过是小项目。满足其建设目标就好了, 乱七八糟的不做。 </p>
<p> </p>
<p>2.周会看个人爱好,有的有官瘾的人天天开我也没意见。 不过,不要浪费别人太多时间。 设计的东西,找张纸,弄个小黑板就OK了, 别再借什么投影仪。我做为一个组员根本不关心别人干了什么。 我只关心我的任务和工作。 别人演讲的时候我一般都睡觉。 我做项目经理的时候, 别人不用向我汇报, 我就知道他们干了什么, 你说这周会有必要开么?除非你的项目特别大, 组织机构复杂, 你下面还有组长, 还有项目经理。这时候才必要。</p>
<p> </p>
<p>3.水平低的分到一小时, 水平高的分到一周。 因人而异。 对于水平高的人, 设计讨论清楚了, 代码随便写去吧。 我是不管的。</p>
<p> </p>
<p>4.利益分配不是你我这个层次的人能够决定的。</p>
<p> </p>
<p> </p>
<p> </p>
16 楼
gloryfuture_taiyuan
2009-09-08
1、wbs的使用是必须的,为的是有一个整体的计划,整体的时间点,但是可以随时调整,达到计划敏捷;
2、需求分析、架构设计等一定要成文档、评审、讲演;
3、周报、日报必须写,项目经理通过这些文档来把控具体项目进度,可以让QA做具体的监督;
4、代码的review可以交给架构或者高程来做,定时反馈代码中的问题;
5、良好的项目经理除了掌握一些项目管理技巧方法外,我认为最好能有一些职业规划方面的知识,可以用到组员中,给每个组员做一个贴切的职业规划,这样你给他安排的活他也就愿意做!
2、需求分析、架构设计等一定要成文档、评审、讲演;
3、周报、日报必须写,项目经理通过这些文档来把控具体项目进度,可以让QA做具体的监督;
4、代码的review可以交给架构或者高程来做,定时反馈代码中的问题;
5、良好的项目经理除了掌握一些项目管理技巧方法外,我认为最好能有一些职业规划方面的知识,可以用到组员中,给每个组员做一个贴切的职业规划,这样你给他安排的活他也就愿意做!
15 楼
earthsky
2009-09-02
使用恰当人做恰当的事,让员工既感到不累,又感觉做了很多有意义的事,这才是项目经理个人魅力,见笑。
14 楼
orpheus
2009-08-27
mock1234 写道
那些简单的,靠人头堆砌就能“成功”的项目,仅仅强调如何开会这种行政得东西就行了。
对于复杂的系统,靠的是设计师,靠的是在主管以行政手法把任务分解和推卸底下的人之外直到如果准时地调配人员工作,而不是仅仅靠没有多少技术含量的开会督促法。
说道每天开多长时间的会议,这能说清楚任何解决技术问题之道吗?不过是从未当过领导的程序员这次过把领导瘾罢了,不要借口说成是软件工程开发之道。
对于复杂的系统,靠的是设计师,靠的是在主管以行政手法把任务分解和推卸底下的人之外直到如果准时地调配人员工作,而不是仅仅靠没有多少技术含量的开会督促法。
说道每天开多长时间的会议,这能说清楚任何解决技术问题之道吗?不过是从未当过领导的程序员这次过把领导瘾罢了,不要借口说成是软件工程开发之道。
我感觉楼主的总结对于2年的工作经验的人来说还是可以的了,他的重点显然也不在开会上.我理解楼主所谓的开会就是team中的一种集体沟通方式而已.
不论是开会督促或者所谓的"随时沟通",都是项目经理不称职的表现.必要的时候是需要督促的,但是如果这种方式成为了项目经理的管理方式之一的话,我只能说他混不了多长时间的.
项目进度质量成本都是项目经理需要考虑的,不是只简单的以行政手段分解就行了,这样可行的话,项目经理还有必要懂技术么?
我觉得无论是通过什么手段,是技术手段,行政手段,人格魅力,个人能力,最美好的管理方式就是让团队中的每个人可以具有团队目标概念,项目责任感以及达到自我目标驱动,自我管理的目标. 这个方式同样适用于项目中的各个角色.
最后一句话,一定要目标驱动,我们都是打工者,不同的职位只是不同的,大家的目标都应该是一致的,千万不要为了管理别人而学习管理,管理的最高境界就是不管,哈哈.
13 楼
Rush_2008
2009-08-18
与楼主相同,也是工作两年,我很支持楼主有这样的想法,把自己平日里所学到的,或者所想的项目管理知识总结起来。只有不断的总结和思考才能进步。
在工作安排上,我趋向于用WBS进行工作分解,便于规范管理,同样也可以使用一些软件如jira或者urtracker等。
在与程序员沟通方面,我觉得这是比较重要的一块,项目经理需要以认真、负责的态度去与程序员进行沟通,不能抱着自己是领导无视下属感受的态度去进行沟通,不然只会越沟越不通。
另外项目经理不单单只是要与开发团队进行沟通,更总要的是要与客户进行沟通,客户满意了,才会有助于推动项目,不会在开发和实施的时候遇到太大的阻碍。项目经理是要保证项目的顺利完成,除了开发,测试、实施也是要关心的事情。
在工作安排上,我趋向于用WBS进行工作分解,便于规范管理,同样也可以使用一些软件如jira或者urtracker等。
在与程序员沟通方面,我觉得这是比较重要的一块,项目经理需要以认真、负责的态度去与程序员进行沟通,不能抱着自己是领导无视下属感受的态度去进行沟通,不然只会越沟越不通。
另外项目经理不单单只是要与开发团队进行沟通,更总要的是要与客户进行沟通,客户满意了,才会有助于推动项目,不会在开发和实施的时候遇到太大的阻碍。项目经理是要保证项目的顺利完成,除了开发,测试、实施也是要关心的事情。
12 楼
zhanjia
2009-08-17
tuti 写道
把自己看做是代码工人的人,也只能看到这些东西。
1、我没有很刻意的去说代码工人,只是想委婉的说明自己不是项目经理,如此而已,并没有你想得那么深,别误会。
2、看到这些,是因为我自己想进步,把自己学到的一些知识记下来。我还没当过项目经理,没做过项目管理,你说我真能看到你想的那些的话,那我就是你了。呵,开个玩笑
3、个人感觉做开发工作这么久要慢慢学会从更高一层来思考、对待一个问题
谢谢指教!
11 楼
zhanjia
2009-08-17
寒江雪 写道
luck_donkey 写道
1.任务划分好,容易弄清楚难点和控制进度
2.确认项目的分阶段的目标很重要
管理者主动去同开发人员了解项目情况最好是在会议上,不管单独还是和捎带上其他人一起都行。开发人员也可以主动报告,当面或者用邮件都可以。
2.确认项目的分阶段的目标很重要
管理者主动去同开发人员了解项目情况最好是在会议上,不管单独还是和捎带上其他人一起都行。开发人员也可以主动报告,当面或者用邮件都可以。
不完全认同“管理者主动去同开发人员了解项目情况最好是在会议上”,我认为管理者应该定期+随时去通开发人员了解项目情况,非正式的与开发人员沟通,会避免将大量时间和精力浪费在会议上---这是一种官僚。并且,也能毕竟全面深入的掌握项目情况,开会时间短,你就无法确切了解项目实际情况,而开会时间长?我说了,那是一种官僚。
1、现在项目基本就是采取“定期+随时”,随时的多,定期的应该是说该开会的时候,就会每个人问一下,上周或前些天都做了什么,计划接下来做什么等
2、其实感觉逼得太紧也不是太好,总感觉经理可能过会儿又要过来问你什么了,自己是不是已经完成了一些什么可以交待的东西,如果没完成又会怎么样...
3、个人认识跟开发人员了解项目情况,应该以一种比较平和的语气,制造宽松的气氛
10 楼
zhanjia
2009-08-17
<div class="quote_title">hotjava 写道</div>
<div class="quote_div">
<div class="quote_title">zhanjia 写道</div>
<div class="quote_div">
<p>工作中学到的一点知识:</p>
<ol>
<li>细分各模块。将项目的各个模块进行细分,细分为子任务,子任务可以根据实际情况进行再细分。<br>
</li>
<li>每周一开会。讨论本周或接下来两周的整体工作,具体要达到怎样的一个目标。</li>
<li>每周五开会总结。最好在下班前0.5-1小时时开会,不要占用项目成员的下班时间。总结本周所完成的工作,查看实际效果,将成果与预计的做一番比较,为项目进度做出更好的评估。(对下班后再开会总结感到反感)<br>
</li>
<li>控制项目进度。工作细分到1-2天,效率比较高。</li>
<li>对项目成员成果的确认。每当项目成员完成某个功能,无论大或小,都要进行确认。最后是在做完以后,项目成员主动发出通知,大家一起审阅一番,同时给出意见。这样能确保功能更加完善,减少后期积少成多各种不完善的修改。</li>
<li>让项目成员们更主动些。有下面几种情况经常会延误项目进度,使项目大大超出原有的预算:1)、遇到风险(代码实现上的)没向上级汇报 2)、开发过程中发现实际工作量超出原有的评估,未及时向上级汇报 3)、没完全清楚需求,就盲目的进行编码,等发现问题以后为时已晚。 看来许多都还是沟通问题<br>
</li>
<li>给项目成员一定的承诺。为了提高项目成员的工作激情,工作劳累的同时,要给予更多的鼓励,给予一定的承诺,前提是这个承诺一定要能够实现,不要让成员们认为你是在忽悠。</li>
</ol>
</div>
<p> </p>
<p>1.各个模块的细分是在概要设计和详细设计中体现的。 属于设计范畴。任务划分不仅仅是功能点同步。 比如搭建数据库环境, 同步数据, 接口讨论等,都不是功能点,因此要创建WBS进行管理, 任务划分粒度与你的资源有关, 资源就是干活的人, 对于能力强的人,那么任务粒度就可以粗一些, 对于能力较弱的或者责任心不强的人, 任务粒度就要细一些。 这个需要磨合。 没有能一概而论的。</p>
<p> </p>
<p>2、3周一开会, 周五开会, 或者,上午开晨会,下午开晚会。 都不是我喜欢的做法。 开会最浪费时间, 要集齐那么多人, 要打算人家手里的活,思维。要等人。要找会议室。会上一堆人事不关己。 总之, 我向往的沟通方式是随时沟通, 精确沟通, 没有固定的时间和形式。 大多数时间不需要会议记录。 除非重要的。你需要整天沟通, 而不是会上那一点点时间进行沟通。 </p>
<p> </p>
<p>4.控制项目进度, 控制进度的最好办法是进行良好的设计和准确预测风险。在业务讨论不清的情况下,开发时间无法控制,也许你完成了,但是要返工。这种情况最难把握。工作原则上,我喜欢控制到半天, 一上午或者一下午。这样至少一天会有两次正式沟通。便于掌握项目情况。</p>
<p> </p>
<p>5。这个最麻烦,有时候感觉项目经理就是个测试人员。</p>
<p> </p>
<p>6、7 我唯一能给组员的激励性的承诺就是,咱们上班的时候好好干,下班就不用加班了。。。。仅此而已。</p>
<p> </p>
<p> </p>
</div>
<p> </p>
<p>1、现在基本都是几十万的项目,其实大多数需求都是经理们自己在提,自己做Demo给客户看,引导出客户的新需求,总感觉是为了赚钱而在忽悠,但如果不是这样的话恐怕又没什么项目做了...。有些需求很虚,有些比较实在</p>
<p> </p>
<p>2、开会一般周一还是会开,会提一提本周大概要完成哪些工作,上周完成了哪些工作。其他时间的开会就比较灵活了,看具体情况。如果这块工作需要两个人来做,那么会找那两个人到小的会议室友聊一下,分配一下任务。如果工作需要所有人参与,那么会叫大家一起去开会,其实也就那么四五人,不多。</p>
<p> </p>
<p>3、任务的分配与工作完成情况的确认,经理喜欢采取半天、一天、两天的形式进行,这样给我们开发人员有一定的压力,效率可能会高点,不好偷懒。不定时的加班,项目开发过程中,偶尔都会有一些加班,时间长短看项目需要,一会儿、半个小时、两个小时、周末一/两天。</p>
<p> </p>
<p>4、承诺倒没咋的,反正看部门的目标,如果达不到预定的金额,奖金就很少。如果超出了,纯利越多,奖金就会多一些。如此而已</p>
<div class="quote_div">
<div class="quote_title">zhanjia 写道</div>
<div class="quote_div">
<p>工作中学到的一点知识:</p>
<ol>
<li>细分各模块。将项目的各个模块进行细分,细分为子任务,子任务可以根据实际情况进行再细分。<br>
</li>
<li>每周一开会。讨论本周或接下来两周的整体工作,具体要达到怎样的一个目标。</li>
<li>每周五开会总结。最好在下班前0.5-1小时时开会,不要占用项目成员的下班时间。总结本周所完成的工作,查看实际效果,将成果与预计的做一番比较,为项目进度做出更好的评估。(对下班后再开会总结感到反感)<br>
</li>
<li>控制项目进度。工作细分到1-2天,效率比较高。</li>
<li>对项目成员成果的确认。每当项目成员完成某个功能,无论大或小,都要进行确认。最后是在做完以后,项目成员主动发出通知,大家一起审阅一番,同时给出意见。这样能确保功能更加完善,减少后期积少成多各种不完善的修改。</li>
<li>让项目成员们更主动些。有下面几种情况经常会延误项目进度,使项目大大超出原有的预算:1)、遇到风险(代码实现上的)没向上级汇报 2)、开发过程中发现实际工作量超出原有的评估,未及时向上级汇报 3)、没完全清楚需求,就盲目的进行编码,等发现问题以后为时已晚。 看来许多都还是沟通问题<br>
</li>
<li>给项目成员一定的承诺。为了提高项目成员的工作激情,工作劳累的同时,要给予更多的鼓励,给予一定的承诺,前提是这个承诺一定要能够实现,不要让成员们认为你是在忽悠。</li>
</ol>
</div>
<p> </p>
<p>1.各个模块的细分是在概要设计和详细设计中体现的。 属于设计范畴。任务划分不仅仅是功能点同步。 比如搭建数据库环境, 同步数据, 接口讨论等,都不是功能点,因此要创建WBS进行管理, 任务划分粒度与你的资源有关, 资源就是干活的人, 对于能力强的人,那么任务粒度就可以粗一些, 对于能力较弱的或者责任心不强的人, 任务粒度就要细一些。 这个需要磨合。 没有能一概而论的。</p>
<p> </p>
<p>2、3周一开会, 周五开会, 或者,上午开晨会,下午开晚会。 都不是我喜欢的做法。 开会最浪费时间, 要集齐那么多人, 要打算人家手里的活,思维。要等人。要找会议室。会上一堆人事不关己。 总之, 我向往的沟通方式是随时沟通, 精确沟通, 没有固定的时间和形式。 大多数时间不需要会议记录。 除非重要的。你需要整天沟通, 而不是会上那一点点时间进行沟通。 </p>
<p> </p>
<p>4.控制项目进度, 控制进度的最好办法是进行良好的设计和准确预测风险。在业务讨论不清的情况下,开发时间无法控制,也许你完成了,但是要返工。这种情况最难把握。工作原则上,我喜欢控制到半天, 一上午或者一下午。这样至少一天会有两次正式沟通。便于掌握项目情况。</p>
<p> </p>
<p>5。这个最麻烦,有时候感觉项目经理就是个测试人员。</p>
<p> </p>
<p>6、7 我唯一能给组员的激励性的承诺就是,咱们上班的时候好好干,下班就不用加班了。。。。仅此而已。</p>
<p> </p>
<p> </p>
</div>
<p> </p>
<p>1、现在基本都是几十万的项目,其实大多数需求都是经理们自己在提,自己做Demo给客户看,引导出客户的新需求,总感觉是为了赚钱而在忽悠,但如果不是这样的话恐怕又没什么项目做了...。有些需求很虚,有些比较实在</p>
<p> </p>
<p>2、开会一般周一还是会开,会提一提本周大概要完成哪些工作,上周完成了哪些工作。其他时间的开会就比较灵活了,看具体情况。如果这块工作需要两个人来做,那么会找那两个人到小的会议室友聊一下,分配一下任务。如果工作需要所有人参与,那么会叫大家一起去开会,其实也就那么四五人,不多。</p>
<p> </p>
<p>3、任务的分配与工作完成情况的确认,经理喜欢采取半天、一天、两天的形式进行,这样给我们开发人员有一定的压力,效率可能会高点,不好偷懒。不定时的加班,项目开发过程中,偶尔都会有一些加班,时间长短看项目需要,一会儿、半个小时、两个小时、周末一/两天。</p>
<p> </p>
<p>4、承诺倒没咋的,反正看部门的目标,如果达不到预定的金额,奖金就很少。如果超出了,纯利越多,奖金就会多一些。如此而已</p>
9 楼
寒江雪
2009-08-17
luck_donkey 写道
1.任务划分好,容易弄清楚难点和控制进度
2.确认项目的分阶段的目标很重要
管理者主动去同开发人员了解项目情况最好是在会议上,不管单独还是和捎带上其他人一起都行。开发人员也可以主动报告,当面或者用邮件都可以。
2.确认项目的分阶段的目标很重要
管理者主动去同开发人员了解项目情况最好是在会议上,不管单独还是和捎带上其他人一起都行。开发人员也可以主动报告,当面或者用邮件都可以。
不完全认同“管理者主动去同开发人员了解项目情况最好是在会议上”,我认为管理者应该定期+随时去通开发人员了解项目情况,非正式的与开发人员沟通,会避免将大量时间和精力浪费在会议上---这是一种官僚。并且,也能毕竟全面深入的掌握项目情况,开会时间短,你就无法确切了解项目实际情况,而开会时间长?我说了,那是一种官僚。
8 楼
luck_donkey
2009-08-17
1.任务划分好,容易弄清楚难点和控制进度
2.确认项目的分阶段的目标很重要
管理者主动去同开发人员了解项目情况最好是在会议上,不管单独还是和捎带上其他人一起都行。开发人员也可以主动报告,当面或者用邮件都可以。
2.确认项目的分阶段的目标很重要
管理者主动去同开发人员了解项目情况最好是在会议上,不管单独还是和捎带上其他人一起都行。开发人员也可以主动报告,当面或者用邮件都可以。
7 楼
hotjava
2009-08-16
<div class="quote_title">zhanjia 写道</div>
<div class="quote_div">
<p>工作中学到的一点知识:</p>
<ol>
<li>细分各模块。将项目的各个模块进行细分,细分为子任务,子任务可以根据实际情况进行再细分。<br>
</li>
<li>每周一开会。讨论本周或接下来两周的整体工作,具体要达到怎样的一个目标。</li>
<li>每周五开会总结。最好在下班前0.5-1小时时开会,不要占用项目成员的下班时间。总结本周所完成的工作,查看实际效果,将成果与预计的做一番比较,为项目进度做出更好的评估。(对下班后再开会总结感到反感)<br>
</li>
<li>控制项目进度。工作细分到1-2天,效率比较高。</li>
<li>对项目成员成果的确认。每当项目成员完成某个功能,无论大或小,都要进行确认。最后是在做完以后,项目成员主动发出通知,大家一起审阅一番,同时给出意见。这样能确保功能更加完善,减少后期积少成多各种不完善的修改。</li>
<li>让项目成员们更主动些。有下面几种情况经常会延误项目进度,使项目大大超出原有的预算:1)、遇到风险(代码实现上的)没向上级汇报 2)、开发过程中发现实际工作量超出原有的评估,未及时向上级汇报 3)、没完全清楚需求,就盲目的进行编码,等发现问题以后为时已晚。 看来许多都还是沟通问题<br>
</li>
<li>给项目成员一定的承诺。为了提高项目成员的工作激情,工作劳累的同时,要给予更多的鼓励,给予一定的承诺,前提是这个承诺一定要能够实现,不要让成员们认为你是在忽悠。</li>
</ol>
</div>
<p> </p>
<p>1.各个模块的细分是在概要设计和详细设计中体现的。 属于设计范畴。任务划分不仅仅是功能点同步。 比如搭建数据库环境, 同步数据, 接口讨论等,都不是功能点,因此要创建WBS进行管理, 任务划分粒度与你的资源有关, 资源就是干活的人, 对于能力强的人,那么任务粒度就可以粗一些, 对于能力较弱的或者责任心不强的人, 任务粒度就要细一些。 这个需要磨合。 没有能一概而论的。</p>
<p> </p>
<p>2、3周一开会, 周五开会, 或者,上午开晨会,下午开晚会。 都不是我喜欢的做法。 开会最浪费时间, 要集齐那么多人, 要打算人家手里的活,思维。要等人。要找会议室。会上一堆人事不关己。 总之, 我向往的沟通方式是随时沟通, 精确沟通, 没有固定的时间和形式。 大多数时间不需要会议记录。 除非重要的。你需要整天沟通, 而不是会上那一点点时间进行沟通。 </p>
<p> </p>
<p>4.控制项目进度, 控制进度的最好办法是进行良好的设计和准确预测风险。在业务讨论不清的情况下,开发时间无法控制,也许你完成了,但是要返工。这种情况最难把握。工作原则上,我喜欢控制到半天, 一上午或者一下午。这样至少一天会有两次正式沟通。便于掌握项目情况。</p>
<p> </p>
<p>5。这个最麻烦,有时候感觉项目经理就是个测试人员。</p>
<p> </p>
<p>6、7 我唯一能给组员的激励性的承诺就是,咱们上班的时候好好干,下班就不用加班了。。。。仅此而已。</p>
<p> </p>
<p> </p>
<div class="quote_div">
<p>工作中学到的一点知识:</p>
<ol>
<li>细分各模块。将项目的各个模块进行细分,细分为子任务,子任务可以根据实际情况进行再细分。<br>
</li>
<li>每周一开会。讨论本周或接下来两周的整体工作,具体要达到怎样的一个目标。</li>
<li>每周五开会总结。最好在下班前0.5-1小时时开会,不要占用项目成员的下班时间。总结本周所完成的工作,查看实际效果,将成果与预计的做一番比较,为项目进度做出更好的评估。(对下班后再开会总结感到反感)<br>
</li>
<li>控制项目进度。工作细分到1-2天,效率比较高。</li>
<li>对项目成员成果的确认。每当项目成员完成某个功能,无论大或小,都要进行确认。最后是在做完以后,项目成员主动发出通知,大家一起审阅一番,同时给出意见。这样能确保功能更加完善,减少后期积少成多各种不完善的修改。</li>
<li>让项目成员们更主动些。有下面几种情况经常会延误项目进度,使项目大大超出原有的预算:1)、遇到风险(代码实现上的)没向上级汇报 2)、开发过程中发现实际工作量超出原有的评估,未及时向上级汇报 3)、没完全清楚需求,就盲目的进行编码,等发现问题以后为时已晚。 看来许多都还是沟通问题<br>
</li>
<li>给项目成员一定的承诺。为了提高项目成员的工作激情,工作劳累的同时,要给予更多的鼓励,给予一定的承诺,前提是这个承诺一定要能够实现,不要让成员们认为你是在忽悠。</li>
</ol>
</div>
<p> </p>
<p>1.各个模块的细分是在概要设计和详细设计中体现的。 属于设计范畴。任务划分不仅仅是功能点同步。 比如搭建数据库环境, 同步数据, 接口讨论等,都不是功能点,因此要创建WBS进行管理, 任务划分粒度与你的资源有关, 资源就是干活的人, 对于能力强的人,那么任务粒度就可以粗一些, 对于能力较弱的或者责任心不强的人, 任务粒度就要细一些。 这个需要磨合。 没有能一概而论的。</p>
<p> </p>
<p>2、3周一开会, 周五开会, 或者,上午开晨会,下午开晚会。 都不是我喜欢的做法。 开会最浪费时间, 要集齐那么多人, 要打算人家手里的活,思维。要等人。要找会议室。会上一堆人事不关己。 总之, 我向往的沟通方式是随时沟通, 精确沟通, 没有固定的时间和形式。 大多数时间不需要会议记录。 除非重要的。你需要整天沟通, 而不是会上那一点点时间进行沟通。 </p>
<p> </p>
<p>4.控制项目进度, 控制进度的最好办法是进行良好的设计和准确预测风险。在业务讨论不清的情况下,开发时间无法控制,也许你完成了,但是要返工。这种情况最难把握。工作原则上,我喜欢控制到半天, 一上午或者一下午。这样至少一天会有两次正式沟通。便于掌握项目情况。</p>
<p> </p>
<p>5。这个最麻烦,有时候感觉项目经理就是个测试人员。</p>
<p> </p>
<p>6、7 我唯一能给组员的激励性的承诺就是,咱们上班的时候好好干,下班就不用加班了。。。。仅此而已。</p>
<p> </p>
<p> </p>
发表评论
-
基于WordPress花4天搭了个独立博客
2020-09-08 00:19 407博客地址:https://binarylife.icu/ ... -
保持好奇心,把时间花在刀刃上
2018-11-15 12:41 1505保持好奇心 如果你自己或身边有小孩,你会发现,小孩对未曾 ... -
有时候需要学会放手,别让自己太劳累
2013-12-11 00:11 2326工作当中,无论自已处于哪个位置,总喜欢去看看项目的代码,动手 ... -
从土八路到正规军?
2013-10-03 01:09 3356这段时间特别忙,公事私事特别多,很累,几乎连看书的时 ... -
关于项目管理、软件开发的一些思考
2013-05-26 19:09 3708有时候在脑海里会浮现一些观点或问题,有些经常遇到,有 ... -
程序员的一些人生感悟
2013-03-19 00:00 4336每一个人,经历多了,或多或少都会有些人生感悟 ... -
项目中使用过的数据同步方式与业务流程
2013-03-01 01:03 3420项目开发中,经常会用到不同系统之间的数据同步,同步 ... -
Share my experience of recruit software developers
2013-02-15 21:53 3824想写这篇文章已经很久了,一直没写主要是为了能够更全面 ... -
五年程序员人生的点点滴滴
2012-05-17 01:34 21838和大家一样, ... -
如何做一个好的技术型领导
2009-12-03 22:27 1763对于程序员来说,大部分公司都提供了多条职业发展方向: 1 ...
相关推荐
为初学者解惑什么才是正真的程序员而不是仅仅只是为了"打字"而敲代码的代码工人。
同时,这也为项目经理和安全管理人员提供了一个评估工人安全知识水平的标准,有助于完善工地的安全培训体系。 总结起来,这份《建筑工人安全知识考试试题——答案》文档是建筑业安全教育的重要参考资料,旨在提升...
【标题】中的“一个简单的工人工资管理系统”指的是一个用于管理企业员工工资的软件应用,它可以帮助企业管理者记录、计算和处理与员工薪资相关的各种事务。这个系统通常包含员工的基本信息,如姓名、部门、入职日期...
描述中的“维修工人年终总结.doc”进一步确认了文件的性质,即一个年度工作总结的文档,通常会包含个人的工作成就、挑战、改进点以及对未来工作的展望。 在标签“范文”中,我们可以理解这可能是作为一种示范或模板...
本文将深入探讨一个特别的管理系统——工人信息管理系统,它采用C++编程语言进行开发,旨在提高企业对工人信息管理的效率和准确性。 一、系统概述 工人信息管理系统是一个针对工厂或建筑等劳动密集型企业设计的...
由于提供的文件信息内容不完整,无法直接提供详细的工人工资分账制管理的知识点。不过,根据文件的标题“深圳市建设领域工人工资分账制管理办法.pdf”,我们可以推测该文件涉及的主要内容和相关的知识点。 首先,...
总结来说,Unity工地工人模型提供了一个现成的、带有动画的3D角色,可以便捷地应用于各种游戏或虚拟现实场景。利用Unity的动画系统和 Animator Controller,开发者能够创造出栩栩如生的工人角色,通过说话、手势等...
这篇工作总结是环卫工人对自己工作的回顾与总结,体现了他们对于环卫工作的热爱与敬业精神。在文档中,作者以一名普通环卫工人的身份,表达了对党和政府关怀的感激,以及对环卫工人这个职业的自豪感。以下是文档中...
综上所述,工人信息管理系统的数据库设计是一个涉及多方面知识的过程,包括需求分析、模型设计、逻辑和物理结构设计、安全性管理以及性能优化。通过精心设计,我们可以构建一个高效、可靠的数据库系统,满足工人信息...
总结来看,这份“车间工人年终总结”涵盖了以下几个关键知识点: 1. **工作回顾与自我评估**:员工需全面总结过去一年的工作,包括取得的成绩和存在的问题。 2. **团队协作与支持**:强调团队合作的重要性,个人...
总结来说,“cn.rar_工人管理”系统是一个综合性的工人信息管理系统,它结合了数据库技术、编程语言、安全策略等多个IT领域的知识,旨在提升学校对学生和工人信息的管理水平,优化人力资源分配,提高工作效率。...
【本文概要】这篇文档是2020年一名煤矿工人的个人年度工作总结,涵盖了他在过去一年中的工作学习经历、专业技能提升、职责执行情况,以及在雨季三防工作中的贡献和个人荣誉。 【煤矿工人年度工作总结】 作为一名...
这篇文档实际上是一名环卫工人进行个人工作总结的报告,虽然标题和描述都指向“环卫工人个人总结”,但文档内容涉及的却是与工程相关的工作,包括项目管理和设备安装。因此,我们可以从以下几个方面提取IT相关知识点...
在本项目中,我们主要探讨的是使用HTML、JavaScript(JS)和CSS这三种核心技术来实现一个工人信息管理系统,特别强调了前端部分的功能实现,不涉及与数据库的交互。以下是这个项目涉及的关键知识点: 1. HTML基础:...
由于描述中提到这只是第一关,我们可以推测这个代码实现可能是一个初步的版本,只包含了游戏的基础功能,比如玩家移动、箱子移动规则以及第一关的布局。 推箱子游戏的基本规则如下: 1. **工人可以向上下左右四个...
在年终总结时,作者诚实地面对自己的不足,认识到在行业学习上还有待加强,这是自我提升的积极态度。他对于新的一年充满信心,期待在学习和工作中取得更大的突破。这种积极进取的心态,是个人职业发展的重要驱动力。...
2021年的工厂工人个人工作总结强调了以下几点关键知识: 1. **工作态度与耐心**:在枯燥重复的工作环境中,保持良好的工作态度至关重要。耐心是做好工作的基础,没有耐心,难以持久专注。工人需学会在日常工作中...
该项目是一个基于React-Native框架的建筑工人管理系统,用于毕业设计。React-Native是Facebook开发的开源库,它允许开发者使用JavaScript编写原生移动应用程序。这个系统可能是为了帮助建筑工地更有效地管理和跟踪...
以项目模块为例,它包含了项目基本信息、项目参建单位、项目班组、项目人员、项目人员进退场、项目人员合同、项目人员考勤、项目人员工资和项目培训等多个方面。这一模块的接口允许第三方服务商根据需要上传相关信息...
虽然文件主要聚焦安全生产,但提到了“重大传染病防制基础知识”,这暗示了在工地上除了常规的安全管理,还需要关注员工的健康状况,特别是预防和应对重大传染病。预防传染病通常遵循“预防为主”的方针,包括早期...