那些你不知道的项目管理细节(四)—需求阶段的意识

第三期我们讲的是最后一个需要沟通的主要团队—研发团队。

研发团队沟通后,就代表我们的最后一个沟通任务结束了,那么我们现在开始正式进入了一个项目的生产阶段了,如果说前面准备工作,很多童鞋没有接触过,那么从今天开始我们讲的内容,我相信大家都不会陌生。那么就让我们来复习一下项目的生命周期。

启动→需求→设计→开发→测试→上线→推广。

我之前讲的都是围绕启动这个阶段的,那么启动阶段在这里要做一个收尾,启动阶段最后一个任务就是启动会。启动会的形式可以多种多样,有些事大家在一起开个会认识一下,有些是大家来个宣誓会,有些是大家在一起聚个餐唱个歌。情况多种多样,这个要根据所在公司的的风气、习惯来。

启动阶段结束后,我们就要立即投入到需求阶段,在这个阶段的参与者主要为业务方领导、业务方、产品经理、研发经理、架构师以及项目经理,但并不是说整个需求阶段必须要所有的人参与进来。那么这些人我们怎么来分别呢,他们主要分三个团队和一个主导。

1、业务团队:业务方领导、业务方

2、产品团队/翻译团队:产品经理

3、研发团队:研发经理、架构师

这里我把产品经理叫做“翻译团队”大家会不会觉得有点奇怪?其实这个产品经理的角色在不同的公司有着截然不同的作用,即便他们做的事儿可能是一样的。

大概互联网公司会分以下几种类型:

1、技术驱动业务团队:产品经理规划公司业务,通过产品经理来驱动业务方和研发团队。

2、业务驱动技术团队:业务方提出需求,产品经理翻译成研发团队容易理解的语言,并交由研发团队实现。

自己的公司属于哪种,就看看你们的产品经理是处于哪种模式下吧。

有点扯远了,话说回来,这三个团队是PM主要需要联系接触的团队,这三方都有着微妙的关系和利益,如何平衡好,我之前已经提到过一些,这里就不再继续讲了。我想说的是,如何看待这三个团队。

1、确保老板的利益

说白了,一个项目的成功失败,最直接的影响人并不是业务方或者产品经理,而就是老板。一定要搞清楚老板想要什么,老板要达成什么目的,一味的唯命是从,被产品经理和业务方牵着鼻子走,只能让事情朝着不可控的方向发展。所以,搞清了老板的目的,哪怕是出现一些小的错误,老板一定不会在意的。

2、谁地位高,我们以谁为核心去推动

即便是同样的组织架构的两家公司,也会因为成员的组成而造成工作流程的天差地别。好比A公司的研发团队的领导是公司的元老,在公司极有话语权。那么在这个公司想产出一个产品你肯定要过他这关,即便你所有的工作做得完美,搞不定这个元老,也只会功亏一篑。这里,会不会有童鞋质疑我,“之前你不是说过要走的那些流程,跟你现在说的不一样吗?”是的,确实不一样,前面我是讲一个万金油,应对各种各样的场合,那么做起码不会错。但你看看我的标题?如果都讲那些流程式的东西就没意思了。

3、确保产品经理与业务方交好

业务方和产品经理的关系,在很多公司都是个问题,如果二者关系闹僵,无论你有再优秀的研发团队,也是无力回天。这个一定是重中之重,如何处理好二者关系,我们以后再说。

4、与研发团队一起加班

说来说去,最核心的工作其实就在研发这,而最辛苦的团队当然就是研发团队了,他们经常会没日没夜的加班赶工。这是PM亲近研发团队的最好时机,一定要经常陪研发团队在一起加班,与他们讨论需求、功能。这样你才是一个身体力行的项目经理,而不会被扣上一个“耍嘴皮子的销售”的帽子。

以上就是在PM在需求阶段需要具备的一些意识,下次我会继续讲需求阶段的具体行动。

那些你不知道的项目管理细节(四)—需求阶段的意识

时间: 2024-10-08 06:49:36

那些你不知道的项目管理细节(四)—需求阶段的意识的相关文章

那些你不知道的项目管理细节(三)

好久没来了,最近这几天项目比较忙,回家只剩学英语那么一点点时间了,所以一直都没写,今儿继续我们的项目管理细节. 第二期谈的是如何与业务方打交道,那我们今天继续往后说,把业务方的工作做完后,下面就该是研发团队的沟通工作了,在第二期的结尾我说过,研发团队是最好打交道的团队,他们就好比机器人,只要输入指令,就可以执行动作.那么一个PM唯一要做的就是输入正确的"指令". 什么是正确的"指令",我们在谈这个名词前,有做过研发leader的童鞋可以回忆一下,项目初期你们都在做些

项目管理(四)- 风险管理

本文主要介绍在项目启动前怎么样分步骤的去识别风险,才去什么方式去识别风险. 有需要做风险识别的朋友可以按照下面的步骤简单的走上一遍,或者可以提高项目的成功率      注意:本文章只是你做风险识别的chekcLists ,上面提到的一些分析方法都只是简单的介绍 一.识别风险 1.决定识别风险的责任人 项目经理应该跟踪风险并且为已经识别的风险编制相应的应对计划 2.进行识别风险的时间 项目启动过程就应该进行风险识别      3.风险识别的方式 (1).研究项目说明说和项目交付成果的规格要求 ->

不该被忽视的CoreJava细节(四)

令人纳闷的数组初始化细节 这个细节问题我很久以前就想深入研究一下,但是一直没有能够抽出时间,借这系列文章的东风,尽量解决掉这个"心头病". 下面以一维int数组为例,对数组初始化方式进行分类. 1) int[] a = new int[2]; a[0] = 1; a[1] = 2; 2) int[] a = new int[]{1, 2}; 3) int[] a; a = new int[]{1, 2}; 4) int[] a = {1, 2}; 这四种初始化方式都是合理的. 但有的时

敏捷项目管理—敏捷四宣言

一.敏捷的七个领域 敏捷准则和理念 价值驱动的交付 干系人参与 团队绩效 适应性计划 问题发现与解决 持续改进(产品.过程.人员) 二.敏捷宣言: 我们正在通过亲身实践以及帮助他们实践,揭示更好的软件开发方法,通过这项工作,我们认为: 个体和交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划 右项虽然也有价值,但是我们认为 左项 具有更大价值 三.敏捷宣言的分类: 一般看敏捷宣言核心是4句话,其实敏捷宣言是3句话,即可以把敏捷宣言内部

软件过程与项目管理第四次作业

教材103页第6题: 6.有人说软件开发过程分为四个阶段: 和PM吵→和设计吵→和测试吵→和用户吵: 你觉得应该如如何避免吵架? 答:(1)软件开发应该按照一定的模型来约束开发的过程,例如说,以瀑布模型来开发一个软件系统,就必须按照以下的步骤来进行软件的开发:系统需求→软件需求→分析→程序设计→编码→测试→运行,最后交付给用户使用. (2)这每一个环节中,都要做好与相关涉众的沟通,比如说进行系统的需求分析时,就应该与用户进行深入的交流,以了解该系统应该实现的功能以及日后可能要扩展的功能,从而能尽

浅谈项目管理中的四要素

项目管理一直是一个老生常谈的问题,我们身边项目时时刻刻发生,大到火箭上天,小到家庭装修.老K作为技术出身,大大小小也做了不下50个项目,这里老K从IT的角度,带领大家用理论的知识分享如何做好一个项目. 项目管理有四个要素:工作范围.时间.质量.成本. 对一个项目来说当然最理想的情况就是“多.快.好.省”.“多”指工作范围大,“快”指时间短.“好”指质量高,“省”指成本低.但是,这4者之间是相互关联的,提高一个指标的同时会降低另一个指标,所以实际上这种理想的情况很难达到. 项目管理的目的 在谈项目

Servlet的学习(四)

在本篇的Servlet的学习中,主要来学习由使用MyEclipse来开发Servlet的一些小细节. 细节一:在web.xml中可以对同一个Servlet配置多个对外访问路径,并如果在web.xml中配置的信息服务器会自动加载部署,而如果是在Servlet中进行程序代码的修改,则每次都要重新部署. 首先,在使用MyEclipse创建Servlet后,会根据所创建的Servlet进行到web.xml文件的映射,如下图所示: 经过这个映射之后,在web.xml文件中就自动生成了这个Servlet的配

项目管理学习笔记之八.课程总结

项目管理的九个知识领域 一.项目管理的四个层次 首先,把复杂问题简单化,做项目的分解.第二,简单事情量化第三,找这个事情解决的关键第四,找专业化的规律和方法. 二.九个知识领域 范围,时间,成本,质量,共四个核心的:人力资源.沟通,干系人管理,风险,采购,最后加一个整合管理 三.项目管理生命周期 规划,启动,执行,监控和收尾

十个心理细节

细节一: 在<从零开始学攻心术>中告诉你,男人擅长用攻心术征服自己想要的女人. 很多男人都明白这个道理:想获得一个原本不怎么爱他的女人的爱,也是分时间分场合的. 在这几个时刻里,女人对爱的抵抗力,是最低的. 比如,幽闭的环境里.日落黄昏时.约会结束后.等等. …… 很多男人在掌握了这些科学真相之后,开始有步骤有准备的击破女人心了. 作为女人,实在有必要比男人先一步掌握这些信息.如果,你真的没有想好要跟一个男人开始一段恋情,那么最好不要把约会定在这几个时间. 细节二: 心理学上有专门的两套受人欢