【3022】初创团队项目管理的一些实践

这次说说产品技术、团队、项目管理相关的话题。

今年初,我玩了一把最简 & 异地的团队,一位兼职设计师(做视觉+交互+前端)、一位兼职技术(服务端+Web)、一位iOS客户端开发,他们在北京,剩下的角色全是我,在杭州。

 

当时的体会,人少确实减少了沟通协调的损耗,但,异地不在一起办公的阻隔、兼职导致的“时差”问题(部分人晚上、周末才可以干活),更麻烦。而且,这样的团队有个前提——必须是成熟度很高、很职业的选手。你很难在本地一下子找齐,全职开干。

 

这两个月,又玩起另外一种,团队角色略多,集中办公,但大家的经验都不太丰富,多为1~3年,没经过专业训练的新手。一上来,花了很多时间跟大家一起定规矩,规矩一定要求,但一定不能复杂,下面分享一下这个简化的产品流程与项目管理方式,如图。

简化版的项目管理流程
简化版的项目管理流程

 

角色的简化

根据事情、团队的现状,做合理的简化,这个还是挺考验经验的,必须见过分工很细的团队,然后理解每个角色是怎么一步步分化出来,设置的目的,才能做好。比如现状对于“小得(项目名称)”,我们的做法是:不区分交互和视觉,无专职测试而全民测试,无运维DBA等细分全部开发承担,前端还是单列出来,所以一共是四个角色:产品、设计、前端、开发。当然,对于最简团队,还可以再去掉一个,产品、设计、开发这三个角色是不可或缺的,注意,是三个角色,不一定是三个自然人。

 

流程的简化

同样,需要见过更复杂的流程,知道每一步是为了防止出什么状况的,才能合理的简化。最低要求,四个关键节点,这些节点是除了产品技术团队、市场运营的关键人也要参与的,我觉得是没法再砍了。

立项会议:确定目的,为什么,做什么;

需求评审:确定怎么做(对于小于2周的小项目,可以和立项会议合并,总体时间控制在2小时以内);

功能评审:简单的讲,就是在测试环境下演示一下产品,确定做出来的是不是团队要的(1小时左右搞定);

发布上线:确定是不是用户要的,用户还要什么……获取反馈,形成闭环。

 

两个分支流程:

变更:一开始可以简化成某个人拍板决定,是否接受变更。

日常:即零散的小需求,只掌握一点,所有需求必须经过产品,不能运营直接找开发,确保产品经理知道所有的需求信息。

 

文档的简化:

几乎可以只有PRD、设计稿、代码三件套。其他都用看板与立会解决。然后,特别强调一个,沟通计划,绝大多数问题都是沟通问题。大家要约定好,是每天开会?线上选一个协作工具?写周报?……这个问题不解决,后面补课一定补得你不要不要的。

 

看板与立会的实际应用

 

研发项目过程中,我们发现还是最原始的看板和立会好用,先说看板里用到的基本元素——任务卡片,也就是一张便签。

任务卡片
任务卡片

 

任务描述:一个词+一句话(如果一个词可以讲清楚,可以不用一句话),比如前端同学写的一张“Detail页面制作”;产品同学的一张“后台订单管理需求细化”。

工时评估:对于2~4周的项目,精确到1~4小时的粒度比较合理,如果一张便签的工作量超过8小时,则需要分拆,这个评估,一开始不准确没关系,每天都会回顾,好好做肯定越来越准。

Deadline据说Deadline是第一生产力,写明日期即可。

优先级:实际操作过程中,并没有写,当任务越多的时候,越需要。

 

三个角标算是个小创新:

左上表示延期,少量延期是正常的,也是允许的,但要监控。如果发现多数人出现大量延期,则说明计划制定不合理,需要调整,如果发现少量人出现大量延期,则更可能是个人问题,需要延期人自己加班赶上进度。此点团队要达成共识,让别人等、浪费别人的时间是可耻的。

右上表示突发任务,少量的突发是正常且允许的,但如果有大量突发,则说明计划不足,没有经验,或者有『外力』经常干扰项目进程。

左下表示持续任务,可以一直贴在Doing里,比如对产品人员来说的『处理用户反馈』,非持续任务都应该每天从Doing到Done。

右下角标备用,敏捷的基本思想就是方法论边做边优化,团队一起来。

多种颜色的卡片也可以灵活应用,比如我们现在只有4个角色,正好4种颜色——产品、设计、前端、开发。

 

有了便签,然后我们来制作看板。

看板
看板

    

横轴Todo、Doing、Done

Todo里的是本项目内需要做还没做的事情,只需要明确便签的部分信息:

任务描述:可以概括,比如『手机版的设计』,特别是比较久以后要做的事情,在便签从Todo进Doing时拆分即刻,并废弃掉旧的便签。

优先级:结合工时评估一起,判断每天应该拿哪些便签进Doing。

工时评估和Deadline可以在便签从Todo拿进Doing的时候同步确定。

如果Todo里便签过少,则说明对未来要做什么没有计划,或者,说明当前项目进入尾声。

 

Doing里表示当天要做的事情,如果便签过少,或者工时加起来远远小于8小时,则说明工作安排出问题了,当然,通常一天平均算5~6小时是合理的。做得好的话,每天贴3~5张便签,有一些是必须要完成的,有一些是可以冲击一下的bonus。

 

Done里是已经完成的事情,随着项目的进行,越来越多,记得最后收集起来归档。

 

纵轴分角色,每个角色里再分不同人,在Todo阶段的便签,有些是只确定角色,不确定谁来做的,比如开发的任务『搭建测试环境』。

 

每日立会(叫立会,就是一起站着开会的意思)

每天固定时间,可以是早上一来,或者每天下班前,每周换人召集、主持。

今天做了什么,一边说一边把Doing里的拿到Done;明天要做什么,一边说一边把Todo里的拿到Doing。

会议时,每个人要特别关注需要互相配合,有前置依赖的任务。

 

还有些信息也可以写在看板上,比如当前项目的几个关键节点的日期(功能评审、发布上线),本周立会的主持人是谁(每周轮换),当前看板信息已经更新到哪一天等。

 

每个项目完成,也是会做一下回顾的,看看管理方法上有哪些“好的需要保持的;不好的需要改进的”。

 

Over,可能你也看出来了,里面有大量Scrum的本地化。

 

PS:此实践中提到的项目,是一个知识经验相关的企业服务,有兴趣的可以通过如下二维码关注。

小得订阅号二维码
—————————–

iamsujie,前阿里产品经理,写过《人人都是产品经理》、《淘宝十年产品事》,现在做创业者服务,『良仓孵化器』创始合伙人,『小得』平台创始人,『好产品平台』创始人。更多信息可以扫码关注。

iamsujie的公众号二维码
iamsujie的公众号二维码

【8044】敏捷开发方法

一句话评论:复习一下敏捷的12条原则,然后看看,Marty如何理解产品经理在“敏捷团队”里的角色定位。

Marty Cagan 发表于2009年6月1日,原文地址,译者:蒋彬 / 审校:周舜莉 徐定翔

许多产品开发机构都尝试过所谓的“敏捷软件开发”方法,其中最为流行的是“极限编程”(XP),此外还有其它一些敏捷方法,比如Crystal、Adaptive、Scrum和Pragmatic Programming等。
在使用这些敏捷方法时,产品经理常常弄不清自己的角色定位。有些产品经理甚至担心采用敏捷方法会影响产品质量。

我打算首先总结敏捷开发的核心原则,然后以极限编程(XP)​为例,指出极限编程的难点,以及如何更好地发挥它的作用。

敏捷方法一览

各种敏捷方法的要求千差万别,但是它们都遵循以下12条原则。​

1、最重要的是通过尽早地、频繁地交付有价值的软件来满足客户——尽早交付有价值的软件。

2、​频繁地交付可运行的软件,数周或者数月交付一次——频繁发布新版本。

3、可运行的软件是衡量进展的主要标准——软件比文档更重要

4、接受​需求变更,即便是在开发最后阶段——倾听,并快速学习

5、项目期间业务人员与开发者共同工作——紧密协作​

6、找积极主动的人来开发项目——为他们提供所需的环境和支持,相信他们能做好自己的工作

7、开发团队里最节省时间最有效的信息传递方式是面对面的交流

8、​自发组织的团队才能做出最好的架构、和设计——架构要敏捷,好主意无处不在

9、​持续关注先进的技术和优秀的设计能促进敏捷性——频繁地重构

10、​敏捷过程促进可持续的开发——此举应能维持相对稳健的节奏——而不是​导致失败

​11、简洁是一切的基础——少即是多

12、​团队定期反思如何提高效率,并调整​工作流程——事后反思​

极限编程概览​

要阐述​遵循敏捷方法到底意味着什么,​不妨看看敏捷方法中最为流行的极限编程的详细规范。该方法的发明者强调,极限编程并非万能,应该有选择性地加以使用。其主要原则如下。

-结对编程——两位程序员使用同一台电脑开发同一款软件

-简单设计——只设计和开发你现在就需要的东西,不考虑将来的潜在需求

-现场客户——客户代表入驻开发团队,他代表了所有产品的需求,在开发过程中不断的说明需求并帮助决策

-增量开发——频敏小规模发布产品​,快速推动产品​进入理想状态

-做好规划——工程师只做评估,客户决定​每次发布的功能和时间

-持续评审代码——基于结对编程的模式,两位开发者相互评审对方的工作

-持续测试——开发者在编码时就撰写单元测试,客户则撰写用例中规定的功能测试,​这些测试均是自动、持续地进行

-持续构建——持续开发和整合软件,这样能及早发现问题,系统也一直处于可构建的状态

-持续重构——软件开发人员不懈努力,通过重构代码来简化和改进工作,同时保证所有测试正常运行​

-代码共有——与每个开发人员“独享”​自己的代码这一模式不同的是,极限编辑模式中每个开发人员只要认为有机会有必要,就可以优化系统中任意处的任意代码​

-开放的工作场所——指整个团队都在一个在房间里共同工作,其中开发人员坐在中间

-每周工作40小时——限制加班以提高工作质量​

-代码即文档——最有用的文档就是软件本身,整个团队应该遵循编码规范

当然了,这种方法是从软件开发人员的角度提出来的。在他们看来,除了程序员和用户(客户),就不需要其他工作人员了。这正是让产品经理感受担忧的地方。​

产品经理的工作至少包含以下三个方面。​

定义产品

首先弄清楚要开发什么产品。极限编程方法是针对定制化软件项目提出来的,目的是满足特定客户的特定需求(比如内部员工薪资系统),它并不适用于通用产品。事实上,在描述极限编程方法的图书和文章里,几乎很少提及产品管理或是界面设计。

最让人担忧的通常产品经理能否代替现场客户的作用。只有在深入研究目标用户、理解用户需求、使用环境以及竞争格局,产品经理才能发挥最大的作用。

更让人担心的是产品设计(界面设计)角色的缺失。对于产品来说(不同于那些签署合同后开发的定制软件),用户界面和用户体验至关重要,需要专业设计师运用其专业技能进行设计,因此在工作流程中引入这一重要职位非常重要。

只要把最初的迭代作为持续演进的原型并不断检验,以确保开发团队能开发出正确的产品,然后再在接下来的迭代中实施产品执行,就能更好地利用极限编程方 法。关键是确保你开发的产品是客户想要购买的,而且客户能搞清楚该如何使用。只有一个客户或是产品经理理解这个产品并不足够,它应该为目标市场的广大群体 所检验。

开发产品

其次要考虑的是,​​这些用来开发可扩展、​高性能、可靠、易维护产品的技术会带来什么样的后果。这些担忧使人马上陷入一种近乎宗教狂热的争论,争论的重 点是,什么才是开发和测试软件的最佳方法,而这完全在产品管理职责之外。​产品经理​只需要清晰地确定需求,然后让技术团队按自己认为最合适的方式来控制 风险。​

极限编程过程依靠客户来定义用例(又被称为用户故事)​,以此作为功能测试的基础。这用在小型项目上或许还不错​,但如果是大型、通用产品的话,有必要请 专人来负责设计必要的测试用例,以确保可扩展性、功能、性能、容错性和本地化特性等。这些通常都是QA的职责,极限编程的方法完全也可以借鉴。关键是让开 发人员负责单元测试,QA人员负责其它测试(比如系统、集成和功能测试等)​。​

部署产品

最后一个为人们所关注的,是产品的发布。人们长期以来一直认为随着时间的推移,做出改变的成本也越来越高,但极限编程挑战了这一看法。换言之,只要遵循极 限编程实践,你可以降低开发中系统需要变更带来的影响。这对于定制化软件来说这没错,但对于许多商业软件产品来说,变更带来的影响仍然很大,尤其是对于拥 有大量活跃用户群体的互联网服务来说。

我曾经探讨过“平滑部署”的​策略,这些方法有助于降低极限编程项目所提倡的频繁发布和更新策略所带来的负面影响。

​总结

大到敏捷开发,小到极限编程方法,都是为了解决传统软件开发方法中的实际问题而创造的,尤其是致力于增强开发人员与客户的沟通,节省时间及早弄清楚你所开发的产品是否正是客户需要的,并减少增量开发过程中的风险,同时优先开发高优化级的功能。此外还有另外一些颇有价值的技术,尤其是结对编程、增量开发、持 续集成与自动化测试等。​

​然而,对于提供商用产品及服务的公司来说,更重要的是将这些方法与产品管理、产品设计、质量保证结合起来,确保你开发的产品能为广大用户和消费者使用。这样的话才能覆盖较广的消费者群体。

本文节选自《启示录:打造用户喜爱的产品》作者Marty Cagan的博客。该书从人员、流程、产品三个角度介绍了现代软件(互联网)产品管理的实践经验和理念。特此感谢Marty Cagan先生授权。