《妥协的完美主义:优秀产品经理的实践指南(卷二)》一2.2 项目管理方法

本节书摘来自异步社区《妥协的完美主义:优秀产品经理的实践指南(卷二)》一书中的第2章,第2.2节,作者 陈洁,更多章节内容可以访问云栖社区“异步社区”公众号查看

2.2 项目管理方法

由于项目进度紧张的安排,要求项目经理必须具备紧迫感,善于捕捉工作中的问题和难点,思路清晰,掌握并灵活运用数据说话。在会议效率低下毫无建设性意见的沟通中,清楚要解决哪些问题,清楚难点在哪里。优秀的项目经理善于安排时间和项目计划,能够掌握数据并灵活运用,善于沟通协调各方面资源,果断做出判断和决定。

除了不断提高自身素养,在实践中身经百战外,使用项目管理工具也是必不可少的。一般说的项目管理工具是现成的软件工具,常见的项目管理工具有Sciforma公司的ProjectScheduler、Primavera 公司的SureTrak、Microsoft 公司的Project、IMSI 公司的TurboProject等软件。但这些软件适合大型的工程类项目,对于软件开发项目有时候并不太实用,因此国内也有人根据具体情况自己开发小工具来使用。项目管理是对人员(People)、产品(Product)、过程(Process)和项目(Project)进行分析和管理,但项目具体还是由人来执行的,说白了记录管理的还是人的工作,解决协调的还是人的问题,就算是没有工具,只是利用文档进行管理,只要方式方法正确,也能够做好项目管理的工作,因此产品经理如果掌握一定的项目管理办法有助于管理能力的提升,对于非专业从事项目管理工作的产品设计人员来说,掌握一定的项目管理方法,对于版本迭代、文档管理、项目进度也有一定的帮助。下面就对三种项目管理方法进行论述。

2.2.1 分阶段

1.项目、版本和产品的关系
在移动互联网行业,产品就是可以满足外部用户需求的软件、硬件或者系统平台,对于外部用户产品是可使用并获得感知的。对于普通手机用户来说,某个公司提供的客户端软件安装包和服务就是一个产品。

版本是产品在不同时间段的特性集合,包括产品的交付物、后续升级的交付物,一个产品可以有多个版本,版本是在产品的生命周期中,依据特性对产品做出的细分。

而项目是产品或版本的实现过程,反过来说,版本和产品是项目的输出。例如,新浪公司推出的手机微博客户端就是一个产品,它包括了客户端软件,以及软件内的内容服务。这个产品又分为V1.0版本和V2.0版本。为了实现和V1.0不同的功能需求,V2.0版本作为另外一个独立的项目展开,在实现新功能完成上线后,发现一些缺陷,每个月再升级补丁版本发布V2.1、V2.2等新的版本。分为不同的版本是为了满足不断变化的需求。

2.项目周期
和产品有一定生命周期一样,项目也是有周期的,但产品生命周期和项目周期是两个不同的概念,产品生命周期是从产品概念产生到产品停止维护使用的过程,项目周期是产品生命周期的一部分,指项目从开始到收尾。产品生命周期开始于一个想法或者概念,结束于产品停止运维和使用。例如,市场部门在拜访某运营商时,发现了一个新需求,市场部的客户经理把这个需求反馈给产品部,这个产品就算开始了;经过市场分析和产品分析,如果证明是有价值的,可以进行开发,完成后交付给运营商客户使用,最后这个产品逐渐过时,公司决定不再支持这个产品,就表示这个产品的生命周期结束了。

有时候项目周期已经结束,但产品依然在被使用或维护,只能说项目周期结束了,但产品生命还继续存在,可见产品周期一般都长于项目周期。

3.项目阶段
根据项目周期,将项目管理分为7个阶段,如图2.3所示。


《妥协的完美主义:优秀产品经理的实践指南(卷二)》一2.2 项目管理方法

(1)项目组织准备阶段:从资源、技术和组织等多个方面进行评估和准备,完成项目立项计划书。

(2)项目概念阶段:制订初步的项目计划,完成设计需求和备选需求。

(3)项目计划阶段:制订详细的项目计划,完成架构设计和概要设计。

(4)项目开发计划:执行项目计划,完成模型demo开发。

(5)项目验证阶段:执行项目计划,完成可用性评估和beta测试。

(6)项目发布阶段:执行项目计划,完成交付和维护支持。

(7)项目关闭阶段:完成项目,总结项目,关闭项目。

在本书后续的章节中,大家可以看到产品设计团队的项目流程,虽然和开发人员的工作内容不同,但项目流程也是7个阶段,并正好和项目开发计划一一对应。

2.2.2 文档化

项目的管理执行是否顺利,取决于产品设计团队的专业素养能力高低,也取决于团队总体的工作方法,相比国内的团队,国外的团队做设计,非常注意方法和目标:输入是什么?输出是什么?采用什么模型?相关影响分析?

输入是什么?输入是要获取各方面的资料,做到信息全面,收集整理来自市场部、客户、用户、开发团队以及其他相关团队的资料,这种资料有文档、照片、产品的应用场景记录、开发技术评估等,获取资料的过程,实际上是一个理解需求的过程,只有先理解需求,产品设计人员才能根据确定的需求一步一步地进行需求整理、功能分解、模块划分、建立逻辑流程、模型验证等。

设计输出是设计团队的设计成果,不仅仅是线框图、设计图稿、开发文档、需求记录等交付物,还应该包括设计团队对会议、思维过程、信息流的记录、共享、传达,输出的不仅仅是文档,还应该有设计思路、理由,只有充分输出,才能给相关团队成员足够多的信息。同时,通过暴露设计思想,团队成员之间才能发现问题,共享成果,及时纠正设计偏差。

文档化包括文档的归类整理、上传、更新、共享、作废等,为了减少返工,防止全盘推倒重来,前一步的输入是后一步输出的基础,也就是进行下一阶段工作之前,要求必须完成前一阶段的工作并为下一阶段工作提供高质量的输入,以保证每一阶段的工作都是连续的、正确的,才能保证一次性把设计工作做好。一般来说,通过运营专业的管理工具,或者最简单地建立共享网络空间等方式,做到输出的充分共享,才能在项目变更,或者被摒弃的需求又重提时,回忆一下,当时为什么我们不做这个功能,当时的理由和原因是什么,帮助产品团队结合现有情况重新评估需求。

要做到项目管理的文档化并不简单。首先项目成员日常工作繁忙,“手懒”不愿意占用时间写;其次很多急性子不耐于写那些他们称为形式化的东西。但事实是,文档化正在潜移默化地改变我们的工作方式,并从一个侧面优化产品的设计构造,使之不偏离最初的设计初衷,防止走歪路走冤枉路。

再者,要解决文档细化程度的问题。有的公司对产品文档怎么记录,有自己的一套规定,比如对设计团队的输出,可见部分的长宽高都做了严格的设计,代码设计上更是细化到方法体。团队成员可以在公司内部的管理工具上查到记录,当然首先得根据团队和项目的具体情况,确定符合项目的细化程度,然后作为制度和规范规定下来,团队成员统一执行。

最后,项目的文档化在改善人际关系方面有很好的作用。项目文档无记录、文档记录混乱,导致团队成员在接手时不容易看懂,或对某个需求理解不一致,出现争执等,在项目中非常常见,小则影响心情,大则影响工作,影响团队合作。

因此项目管理工作中,项目输出中代码管理、设计输出、需求纪要等的文档化非常重要。

2.2.3 规范化

在文档化的过程中文档如何记录、记录的格式是否统一,如果没有明文规定,容易造成查无对证的隐患,造成的设计理解出现偏差、责任不明确,更是诸多问题的根源。被“冤假错案”搞得一头雾水的项目成员,可能会产生恐惧或排斥的心理,这种心理对于项目是不利的。那么问题是谁造成的呢?都归结为文档输出者,或者项目经理吗?具体地说是项目管理策略的不严谨、不规范造成的。

在设计输出中有一大堆的开发文档、需求列表等,其中需求列表主要是用于审查系统的高层设计,比如系统设计上是否应该采取什么措施或设计操作,满足产品目标用户中哪一类人的需求就算达标了呢?虽然目前设计行业没有严格的标准,但至少各个系统平台发布的开发设计功能实现应该作为基础的标准,如果连这个基础标准也无法满足,那么再好的设计也是不规范的。

虽然网络上流传着很多指导书和规范,但很多初级的项目执行人员没有看规范要求再工作的习惯,而是通过自己的经验或者模仿他人设计作品完成工作任务。作为产品设计人员,不论项目大小,都应该遵循设计指南,为自己的App产品制定GUI规范、设计开发标准。越详细标准的开发规范越利于项目,一方面有利于养成良好的工作习惯,对自身素养提高有帮助;另一方面,将来产品团队扩大,项目规模扩大时,标准的开发和设计规范也有利于项目的延续性和规范化。

上一篇:归并排序


下一篇:tensorflow杂项