论坛首页 综合技术论坛

总结一点项目管理知识,虽然自己还只是一个代码工人

浏览 14866 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2009-08-17  
hotjava 写道
zhanjia 写道

工作中学到的一点知识:

  1. 细分各模块。将项目的各个模块进行细分,细分为子任务,子任务可以根据实际情况进行再细分。
  2. 每周一开会。讨论本周或接下来两周的整体工作,具体要达到怎样的一个目标。
  3. 每周五开会总结。最好在下班前0.5-1小时时开会,不要占用项目成员的下班时间。总结本周所完成的工作,查看实际效果,将成果与预计的做一番比较,为项目进度做出更好的评估。(对下班后再开会总结感到反感)
  4. 控制项目进度。工作细分到1-2天,效率比较高。
  5. 对项目成员成果的确认。每当项目成员完成某个功能,无论大或小,都要进行确认。最后是在做完以后,项目成员主动发出通知,大家一起审阅一番,同时给出意见。这样能确保功能更加完善,减少后期积少成多各种不完善的修改。
  6. 让项目成员们更主动些。有下面几种情况经常会延误项目进度,使项目大大超出原有的预算:1)、遇到风险(代码实现上的)没向上级汇报  2)、开发过程中发现实际工作量超出原有的评估,未及时向上级汇报  3)、没完全清楚需求,就盲目的进行编码,等发现问题以后为时已晚。 看来许多都还是沟通问题
  7. 给项目成员一定的承诺。为了提高项目成员的工作激情,工作劳累的同时,要给予更多的鼓励,给予一定的承诺,前提是这个承诺一定要能够实现,不要让成员们认为你是在忽悠。

 

1.各个模块的细分是在概要设计和详细设计中体现的。 属于设计范畴。任务划分不仅仅是功能点同步。 比如搭建数据库环境, 同步数据, 接口讨论等,都不是功能点,因此要创建WBS进行管理, 任务划分粒度与你的资源有关, 资源就是干活的人, 对于能力强的人,那么任务粒度就可以粗一些, 对于能力较弱的或者责任心不强的人, 任务粒度就要细一些。 这个需要磨合。 没有能一概而论的。

 

2、3周一开会, 周五开会, 或者,上午开晨会,下午开晚会。 都不是我喜欢的做法。 开会最浪费时间, 要集齐那么多人, 要打算人家手里的活,思维。要等人。要找会议室。会上一堆人事不关己。 总之, 我向往的沟通方式是随时沟通, 精确沟通, 没有固定的时间和形式。 大多数时间不需要会议记录。 除非重要的。你需要整天沟通, 而不是会上那一点点时间进行沟通。

 

4.控制项目进度, 控制进度的最好办法是进行良好的设计和准确预测风险。在业务讨论不清的情况下,开发时间无法控制,也许你完成了,但是要返工。这种情况最难把握。工作原则上,我喜欢控制到半天, 一上午或者一下午。这样至少一天会有两次正式沟通。便于掌握项目情况。

 

5。这个最麻烦,有时候感觉项目经理就是个测试人员。

 

6、7 我唯一能给组员的激励性的承诺就是,咱们上班的时候好好干,下班就不用加班了。。。。仅此而已。

 

 

 

1、现在基本都是几十万的项目,其实大多数需求都是经理们自己在提,自己做Demo给客户看,引导出客户的新需求,总感觉是为了赚钱而在忽悠,但如果不是这样的话恐怕又没什么项目做了...。有些需求很虚,有些比较实在

 

2、开会一般周一还是会开,会提一提本周大概要完成哪些工作,上周完成了哪些工作。其他时间的开会就比较灵活了,看具体情况。如果这块工作需要两个人来做,那么会找那两个人到小的会议室友聊一下,分配一下任务。如果工作需要所有人参与,那么会叫大家一起去开会,其实也就那么四五人,不多。

 

3、任务的分配与工作完成情况的确认,经理喜欢采取半天、一天、两天的形式进行,这样给我们开发人员有一定的压力,效率可能会高点,不好偷懒。不定时的加班,项目开发过程中,偶尔都会有一些加班,时间长短看项目需要,一会儿、半个小时、两个小时、周末一/两天。

 

4、承诺倒没咋的,反正看部门的目标,如果达不到预定的金额,奖金就很少。如果超出了,纯利越多,奖金就会多一些。如此而已

0 请登录后投票
   发表时间:2009-08-17  
寒江雪 写道
luck_donkey 写道
1.任务划分好,容易弄清楚难点和控制进度
2.确认项目的分阶段的目标很重要

管理者主动去同开发人员了解项目情况最好是在会议上,不管单独还是和捎带上其他人一起都行。开发人员也可以主动报告,当面或者用邮件都可以。



不完全认同“管理者主动去同开发人员了解项目情况最好是在会议上”,我认为管理者应该定期+随时去通开发人员了解项目情况,非正式的与开发人员沟通,会避免将大量时间和精力浪费在会议上---这是一种官僚。并且,也能毕竟全面深入的掌握项目情况,开会时间短,你就无法确切了解项目实际情况,而开会时间长?我说了,那是一种官僚。



1、现在项目基本就是采取“定期+随时”,随时的多,定期的应该是说该开会的时候,就会每个人问一下,上周或前些天都做了什么,计划接下来做什么等

2、其实感觉逼得太紧也不是太好,总感觉经理可能过会儿又要过来问你什么了,自己是不是已经完成了一些什么可以交待的东西,如果没完成又会怎么样...

3、个人认识跟开发人员了解项目情况,应该以一种比较平和的语气,制造宽松的气氛
0 请登录后投票
   发表时间:2009-08-17  
tuti 写道
把自己看做是代码工人的人,也只能看到这些东西。


1、我没有很刻意的去说代码工人,只是想委婉的说明自己不是项目经理,如此而已,并没有你想得那么深,别误会。

2、看到这些,是因为我自己想进步,把自己学到的一些知识记下来。我还没当过项目经理,没做过项目管理,你说我真能看到你想的那些的话,那我就是你了。呵,开个玩笑

3、个人感觉做开发工作这么久要慢慢学会从更高一层来思考、对待一个问题

谢谢指教!
0 请登录后投票
   发表时间:2009-08-18  
与楼主相同,也是工作两年,我很支持楼主有这样的想法,把自己平日里所学到的,或者所想的项目管理知识总结起来。只有不断的总结和思考才能进步。

在工作安排上,我趋向于用WBS进行工作分解,便于规范管理,同样也可以使用一些软件如jira或者urtracker等。

在与程序员沟通方面,我觉得这是比较重要的一块,项目经理需要以认真、负责的态度去与程序员进行沟通,不能抱着自己是领导无视下属感受的态度去进行沟通,不然只会越沟越不通。

另外项目经理不单单只是要与开发团队进行沟通,更总要的是要与客户进行沟通,客户满意了,才会有助于推动项目,不会在开发和实施的时候遇到太大的阻碍。项目经理是要保证项目的顺利完成,除了开发,测试、实施也是要关心的事情。

0 请登录后投票
   发表时间:2009-08-27   最后修改:2009-08-27
mock1234 写道
那些简单的,靠人头堆砌就能“成功”的项目,仅仅强调如何开会这种行政得东西就行了。

对于复杂的系统,靠的是设计师,靠的是在主管以行政手法把任务分解和推卸底下的人之外直到如果准时地调配人员工作,而不是仅仅靠没有多少技术含量的开会督促法。

说道每天开多长时间的会议,这能说清楚任何解决技术问题之道吗?不过是从未当过领导的程序员这次过把领导瘾罢了,不要借口说成是软件工程开发之道。

我感觉楼主的总结对于2年的工作经验的人来说还是可以的了,他的重点显然也不在开会上.我理解楼主所谓的开会就是team中的一种集体沟通方式而已.

不论是开会督促或者所谓的"随时沟通",都是项目经理不称职的表现.必要的时候是需要督促的,但是如果这种方式成为了项目经理的管理方式之一的话,我只能说他混不了多长时间的.
项目进度质量成本都是项目经理需要考虑的,不是只简单的以行政手段分解就行了,这样可行的话,项目经理还有必要懂技术么?
我觉得无论是通过什么手段,是技术手段,行政手段,人格魅力,个人能力,最美好的管理方式就是让团队中的每个人可以具有团队目标概念,项目责任感以及达到自我目标驱动,自我管理的目标. 这个方式同样适用于项目中的各个角色.

最后一句话,一定要目标驱动,我们都是打工者,不同的职位只是不同的,大家的目标都应该是一致的,千万不要为了管理别人而学习管理,管理的最高境界就是不管,哈哈.
0 请登录后投票
   发表时间:2009-09-02  
使用恰当人做恰当的事,让员工既感到不累,又感觉做了很多有意义的事,这才是项目经理个人魅力,见笑。
0 请登录后投票
   发表时间:2009-09-08  
1、wbs的使用是必须的,为的是有一个整体的计划,整体的时间点,但是可以随时调整,达到计划敏捷;
2、需求分析、架构设计等一定要成文档、评审、讲演;
3、周报、日报必须写,项目经理通过这些文档来把控具体项目进度,可以让QA做具体的监督;
4、代码的review可以交给架构或者高程来做,定时反馈代码中的问题;
5、良好的项目经理除了掌握一些项目管理技巧方法外,我认为最好能有一些职业规划方面的知识,可以用到组员中,给每个组员做一个贴切的职业规划,这样你给他安排的活他也就愿意做!
0 请登录后投票
   发表时间:2009-09-10  
zhanjia 写道
hotjava 写道
zhanjia 写道

工作中学到的一点知识:

  1. 细分各模块。将项目的各个模块进行细分,细分为子任务,子任务可以根据实际情况进行再细分。
  2. 每周一开会。讨论本周或接下来两周的整体工作,具体要达到怎样的一个目标。
  3. 每周五开会总结。最好在下班前0.5-1小时时开会,不要占用项目成员的下班时间。总结本周所完成的工作,查看实际效果,将成果与预计的做一番比较,为项目进度做出更好的评估。(对下班后再开会总结感到反感)
  4. 控制项目进度。工作细分到1-2天,效率比较高。
  5. 对项目成员成果的确认。每当项目成员完成某个功能,无论大或小,都要进行确认。最后是在做完以后,项目成员主动发出通知,大家一起审阅一番,同时给出意见。这样能确保功能更加完善,减少后期积少成多各种不完善的修改。
  6. 让项目成员们更主动些。有下面几种情况经常会延误项目进度,使项目大大超出原有的预算:1)、遇到风险(代码实现上的)没向上级汇报  2)、开发过程中发现实际工作量超出原有的评估,未及时向上级汇报  3)、没完全清楚需求,就盲目的进行编码,等发现问题以后为时已晚。 看来许多都还是沟通问题
  7. 给项目成员一定的承诺。为了提高项目成员的工作激情,工作劳累的同时,要给予更多的鼓励,给予一定的承诺,前提是这个承诺一定要能够实现,不要让成员们认为你是在忽悠。

 

1.各个模块的细分是在概要设计和详细设计中体现的。 属于设计范畴。任务划分不仅仅是功能点同步。 比如搭建数据库环境, 同步数据, 接口讨论等,都不是功能点,因此要创建WBS进行管理, 任务划分粒度与你的资源有关, 资源就是干活的人, 对于能力强的人,那么任务粒度就可以粗一些, 对于能力较弱的或者责任心不强的人, 任务粒度就要细一些。 这个需要磨合。 没有能一概而论的。

 

2、3周一开会, 周五开会, 或者,上午开晨会,下午开晚会。 都不是我喜欢的做法。 开会最浪费时间, 要集齐那么多人, 要打算人家手里的活,思维。要等人。要找会议室。会上一堆人事不关己。 总之, 我向往的沟通方式是随时沟通, 精确沟通, 没有固定的时间和形式。 大多数时间不需要会议记录。 除非重要的。你需要整天沟通, 而不是会上那一点点时间进行沟通。

 

4.控制项目进度, 控制进度的最好办法是进行良好的设计和准确预测风险。在业务讨论不清的情况下,开发时间无法控制,也许你完成了,但是要返工。这种情况最难把握。工作原则上,我喜欢控制到半天, 一上午或者一下午。这样至少一天会有两次正式沟通。便于掌握项目情况。

 

5。这个最麻烦,有时候感觉项目经理就是个测试人员。

 

6、7 我唯一能给组员的激励性的承诺就是,咱们上班的时候好好干,下班就不用加班了。。。。仅此而已。

 

 

 

1、现在基本都是几十万的项目,其实大多数需求都是经理们自己在提,自己做Demo给客户看,引导出客户的新需求,总感觉是为了赚钱而在忽悠,但如果不是这样的话恐怕又没什么项目做了...。有些需求很虚,有些比较实在

 

2、开会一般周一还是会开,会提一提本周大概要完成哪些工作,上周完成了哪些工作。其他时间的开会就比较灵活了,看具体情况。如果这块工作需要两个人来做,那么会找那两个人到小的会议室友聊一下,分配一下任务。如果工作需要所有人参与,那么会叫大家一起去开会,其实也就那么四五人,不多。

 

3、任务的分配与工作完成情况的确认,经理喜欢采取半天、一天、两天的形式进行,这样给我们开发人员有一定的压力,效率可能会高点,不好偷懒。不定时的加班,项目开发过程中,偶尔都会有一些加班,时间长短看项目需要,一会儿、半个小时、两个小时、周末一/两天。

 

4、承诺倒没咋的,反正看部门的目标,如果达不到预定的金额,奖金就很少。如果超出了,纯利越多,奖金就会多一些。如此而已


1.你最好先看看合同, 看看技术方案建议书,看看客户的建设目标是什么,别做了一大堆看起来很像样的东西, 结果客户的根本问题没解决。几十万的项目不过是小项目。满足其建设目标就好了, 乱七八糟的不做。

 

2.周会看个人爱好,有的有官瘾的人天天开我也没意见。 不过,不要浪费别人太多时间。 设计的东西,找张纸,弄个小黑板就OK了, 别再借什么投影仪。我做为一个组员根本不关心别人干了什么。 我只关心我的任务和工作。 别人演讲的时候我一般都睡觉。 我做项目经理的时候, 别人不用向我汇报, 我就知道他们干了什么, 你说这周会有必要开么?除非你的项目特别大, 组织机构复杂, 你下面还有组长, 还有项目经理。这时候才必要。

 

3.水平低的分到一小时, 水平高的分到一周。 因人而异。 对于水平高的人, 设计讨论清楚了, 代码随便写去吧。 我是不管的。

 

4.利益分配不是你我这个层次的人能够决定的。

 

 

 

0 请登录后投票
   发表时间:2009-09-20  
hiwzg 写道
同RE。可以多看看软件项目管理方面的知识,在日常工作中多体会。
ybbkd2 写道
zhanjia 写道

工作中学到的一点知识:

  1. 细分各模块。将项目的各个模块进行细分,细分为子任务,子任务可以根据实际情况进行再细分。
  2. 每周一开会。讨论本周或接下来两周的整体工作,具体要达到怎样的一个目标。
  3. 每周五开会总结。最好在下班前0.5-1小时时开会,不要占用项目成员的下班时间。总结本周所完成的工作,查看实际效果,将成果与预计的做一番比较,为项目进度做出更好的评估。(对下班后再开会总结感到反感)
  4. 控制项目进度。工作细分到1-2天,效率比较高。
  5. 对项目成员成果的确认。每当项目成员完成某个功能,无论大或小,都要进行确认。最后是在做完以后,项目成员主动发出通知,大家一起审阅一番,同时给出意见。这样能确保功能更加完善,减少后期积少成多各种不完善的修改。
  6. 让项目成员们更主动些。有下面几种情况经常会延误项目进度,使项目大大超出原有的预算:1)、遇到风险(代码实现上的)没向上级汇报  2)、开发过程中发现实际工作量超出原有的评估,未及时向上级汇报  3)、没完全清楚需求,就盲目的进行编码,等发现问题以后为时已晚。 看来许多都还是沟通问题
  7. 给项目成员一定的承诺。为了提高项目成员的工作激情,工作劳累的同时,要给予更多的鼓励,给予一定的承诺,前提是这个承诺一定要能够实现,不要让成员们认为你是在忽悠。


建议楼主系统的去学习一下项目管理知识,有很多培训班,即学习知识又能混个证书,如果运气好的话:)

 

 

 

 

项目研发的最佳实践就是:在实际项目中的发现,反思,改进和总结!

楼主是个善于总结的人。

0 请登录后投票
   发表时间:2009-09-20  
tuti 写道
把自己看做是代码工人的人,也只能看到这些东西。


楼主只是很谦虚罢了。
0 请登录后投票
论坛首页 综合技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics