构建之法 项目经理

软件团队里除了能写代码、测试代码和画图做设计的成员,还有一类角色,不做上面这些事情但也很重要,我们叫他们项目经理--PM。

PM 的M 就是 Manager;

P有这几种: Product Manager, Project Manager, Program Manager   在不同的行业和公司它们的作用不一样。

Product Manager: 产品经理----正确地做产品。

Project Manager:  项目经理----正确地做流程。

Program Manager:  微软的职位名称。

成为一个团队的PM, 需要哪些能力?

1、学习能力:

在一个新领域中能很快上手。

2、观察理解能力:

能理解用户,站在用户的角度上考虑问题,观察发现用户不善于表达的需求,观察团队成员的言外之意,老板/客户/利益相关人的弦外之音。

3、分析管理能力:

每天项目中发生的事情千头万绪,能够分析出重点,找到优先级,做决定…

在一个项目中, PM 的具体任务是什么呢?

1、带领团队形成团队的目标/远景,把抽象的目标转化为可执行的、具体的、优美的设计。

2、管理软件的具体功能的生命周期 (需求/设想/设计/实现/测试/修改/发布/升级/迁移/淘汰)。

3、创建并维护软件的功能说明书 (specification),让它成为开发/测试的及时准确的指导,而不是障碍。

4、代表客户和用户的利益,主动收集用户反馈,预期用户新的需求,协调并决定各种需求的优先级。

5、分析并带领其他成员形成对缺陷/变更需求的一致意见,并确保实施。

6、带领其他成员确保项目保持功能/时间/资源 的合理平衡,跟踪项目进展,确保团队发布让客户满意的软件。

7、收集团队项目管理和软件工程的各种数据,客观地分析项目实施过程中的优缺点,推动项目成员持续改进,从而提振士气。

时间: 2024-10-26 03:40:12

构建之法 项目经理的相关文章

四渎《构建之法》——计划估计、敏捷流程、项目经理和用户场景

本周再次打开<构建之法>,这次我阅读时重点在于学习敏捷流程.项目经理和用户场景等相对较为宏观的内容. 第六章开篇即简单地介绍了敏捷开发的流程:Product Backlog->Sprint Backlog->Sprint->软件的增量发布.同时提出了一些敏捷开发的特色之处:团队成员自己主导任务的估计和分配,使其能动性得到较大的发挥:通过每日"例"会进行面对面的交流,报告工作进度.今日要工作的内容.遇见的问题:通过燃尽图或看版图展现项目进度.这是一种和我们之

构建之法——需求分析+项目经理+典型用户和场景

第八章(需求分析) 需求分析是一个非常重要的过程,它完成的好坏直接影响后续软件开发的质量.一般情况下,用户并不熟悉计算机的相关知识,而软件开发人员对相关的业务领域也不甚了解,用户与开发人员之间对同一问题理解的差异和习惯用语的不同往往会为需求分析带来很大的困难.所以,开发人员和用户之间充分和有效的沟通在需求分析的过程中至关重要. 那么,构建一个软件系统最困难的工作是什么呢?答案无疑是要—确定要构建什么.其他任何工作都不会像这部分工作那样,在出错之后会如此严重地影响随后实现的系统,并且在以后修补竟会

构建之法 第九章 项目经理

PM是在前几章中反复提到过的而我本身对此比较陌生的一种团队角色.我觉得"manager"(中文翻译为经理)其实是个很广泛的概念:不过大多数情况下指的是具有"复合型功能"的人物 1.PM是什么 product manager:产品经理.正确地做产品[也就是说,产品经理是以产品为中心展开工作,包括产品的定位.运营.优化等等] project manager:项目经理.正确地做流程:保证一个项目顺利按照计划结项. program manager:微软独有的PM,与项目经理

构建之法---初识篇(项目经理和典型用户)

这周主要是项目经理和典型用户场景这两章的内容的学习,了解一个项目经理的责任和义务,了解一个项目经理应该具备的能力是什么,了解什么是典型用户,能够真正挖掘用户的需求,然后进行典型用户的练习. 关于项目经理这一章,其实首先他要是多变的,要懂得从不同的角度去看问题,要了解作为一个用户对软件的需求是什么,要了解作为一个程序员要以什么样的形式将用户的需求完美的表现出来,综合来说就是有观察,理解和快速学习的能力,我个人认为自己这方面的能力还是可以的.再有一个就是让人很头疼的能力,分析管理的能力,一个项目经理

《构建之法》读后感和团队项目杂谈

<构建之法>将软件工程的各个组件分门别类,横向地介绍了软件工程这一体系.然后又在每个类别中纵向地由浅入深,逐步递进, 较为完整地让我们这些菜鸟初识软件工程. 经过一个学期的学习,<软件工程>搭配着<构建之法>进行学习,我也对软件工程有着一定的了解.软件=程序+软件工程,个 人认为,如果说程序意味着实现,那么软件工程更加侧重“方法”和“规则”.似乎软件工程是一个新兴的学科,它的方法论是一群富 有经验的大牛从他们丰富的编程经历中提炼的精华和吸取的教训(我个人的臆想),没有特

《构建之法》阅读笔记06-项目经理PM

软件团队里除了能写代码.测试代码和画图做设计的成员,还有一类角色,不做上面这些事情但也很重要,我们叫他们项目经理--PM. PM 的M 就是 Manager: P有这几种: Product Manager, Project Manager, Program Manager   在不同的行业和公司它们的作用不一样. Product Manager: 产品经理----正确地做产品. Project Manager:  项目经理----正确地做流程. Program Manager:  微软的职位名称

关于 《构建之法》

1.关于<构建之法>: 看了第一章,关于<构建之法>的概述,通过一定的软件流程,在预计的时间内发布好的软件,软件工程对于开发一个好的软件很重要,在开发中,程序很重要,软件开发流程也很重要. 软件具有:复杂性,不可见性,易变性,服从性,非连续性.还有其他特性. 软件工程的目标:创造“足够好”的软件. 构建之法的目标: 研发出符合用户需求的软件: 通过一定的软件流程,在预计的时间内发布“足够好”的软件: 能证明所开发的软件是可以维护和继续发展的. 可行性分析->项目立项->

读构建之法8、9、10章有感

第八章.需求分析 书中介绍了一些获取需求的常用方法.流程.及分析框架,看了后才发现原来需求分析还有着者这么多的学问. 以前听人说,需求分析在实际项目开发中所占分量很重,甚至往往需要花的精力比敲代码要多.我听到时不以为然 ,认为需求分析不就是看一下软件要什么功能,要做成什么样而已吗.再后来,我真的接手了一个小商业项目的需 求分析任务,才明白需求分析是一件多么让人崩溃的事情,客户对软件编程一无所知,只是含糊地给我一些文档, 而我又不清楚他们的业内流程.业内术语等,不知道如何去获取对需求,只能像只无头

《构建之法》读后感

<构建之法>给我的第一映像是“终于有一本我可以看的下去的关于软件的书了╥﹏╥...”.<构建之法>与其他的软件工程的书不同,没有密密麻麻的字,没有晦涩难懂的词汇,没有让人看不下去的感受.邹欣老师用一种特殊的方式告诉我什么是软件工程. <构建之法>最大的特点是那些虚拟人物的对话,他们之间的对话就是现实中许多工程师在工作中会遇到的问题.在书中邹欣老师通过阿超.国栋.小飞.小李等虚拟人物的对话以及他们答辩.讨论形象生动得说出了工程师们在遇到问题时的困惑,以及思维方式,并对他们