项目管理好坏,决定了项目的成败。无论做什么工作,项目地企划、执行、效果评估、复盘,总是必不可少的。

我们可能遇到过如下场景:

  1. 业务方提出需求,扑哧扑哧做个几周后,却发现并不是他们想要的。这样的后果就是:
    • 项目结果被搁置

    • 几周的开发时间浪费

  2. 业务和开发其乐融融,第一版也顺利交付,而后由于老板或者更高一级负责人的要求,要做的功能点越来越多,以至于现有功能延误。

需求的企划,项目的推进、以及团队的建设,对于结果的影响,是强相关的。做好以上三点,有两个好处。一来,可以减缓项目的失败风险,二来,也有助于团队更高效地产出。


以下内容,框架节选自书籍《程序员修炼之道》,根据理解有部分删改。《程序员修炼之道》,是软件开发的经典之作。对于软件行业的原则性问题,进行了详细而又到位的探讨,出版二十余年。第二版添加了最新的潮流趋势,由云风翻译,质量上乘,值得推荐给大家。

一般做阅读,都是带着问题来的,为了解决对应问题。项目管理方面,也有经典之作 PMBOK,不过那本书蛮厚的,还没消化完全。以下内容,解答了我对于需求、项目以及团队建设的部分迷思。大部分摘录自《程序员修炼之道》,穿插工作中的心得体会。希望给读者朋友带来帮助。也希望自己,能常读常新,在工作中实践、反馈、进步。

项目启动前

需求——没有人知道自己想要什么

在每个项目启动前,往往是需求的对接。

业务部门想要的是什么?是大老板拍脑袋的需求,还是确切有利于业务问题的解决?

之前的职业经历中,遇到的很多需求,都是大老板拍脑袋,然后层层传递下来。到了执行层,基本无法判断其真实的目的。最后只能和末端的需求人员对接,成了单一的传声筒。

这种情况,十分危险。

根据乔老爷定律:没有人能确切描述自己的需求,直到你把产品摆在他面前。

这样的后果就是,为了缓解高层的焦虑,做了很多脱离实际的功能。而一线,最熟悉用户的人,许多业务中的改进点,却只能搁置。

灯塔——开发人员的职责

作为开发人员,尤其是作为数据开发、数据挖掘人员,我们的职责之一,便是帮助他人了解想要什么。因为,产品数据、模型效果等最直观的感受者,还是我们。只有我们才知道:什么能做、能做到的程度。这也是区分初级和高级工程师的因素之一。

在帮助他人澄清需求时,常见的错误,便是照单全收。这往往会为后续开发,埋下隐患。人们的日常沟通,尚存在许多误解,更别说涉及开发建模的活。

正确的做法,是复述一遍,将自己理解的程度反馈出去,并明确问题的边界。如果,刚好对业务领域了解不深,则更应该通过沉浸体验业务、复述需求等方式,寻求反馈。

什么需求是好需求

与此同时,在需求澄清过程中,应当区分需求与策略。需求,是指功能上的开发,以期望实现某种功能。策略,则是一连串的活动,保证达到某种效果。一般而言,策略抽象自需求。关注更高层面的抽象,为底层需求做好准备,DRY(Do Not Repeat Yourself)。

抽象的,且能简单直接反应业务需求的,才是好需求。

另外,做好需求的文档化。需求文档化,不是说要去交付它;而是说,将其作为开发过程的记录。这种方式,能较为清晰的记录,软件开发过程中的 Eureka 高光。这些点子,兴许是下个需求来源,或是创新的突破口。

为什么项目会失败

查理·芒格说过:如果知道,我会死在哪里,那我就永远不会去那里。

一般而言,项目失败有两个因素导致。一个是:功能的不断膨胀。也许一开始,只是添加了一个小功能,最后却成了臃肿的庞然大物。

另一方面,则是需求的变化。昨天需要的事物,在今天可能就没那么适用。

如何破解该难题:其核心便还是,持续的反馈。

项目进行时

项目难点的处理

项目中的直接阻碍,来源于项目本身需解决的问题。除了自然界的熵增,可自发的进行。逆熵行为,无一例外都会遇到困难。所以,问题并不可怕,特别是当你知道,如何处理时。

那么,如何处理项目中的难点呢?

第一,先检查约束条件。约束条件是指,项目的边界。诸如:时间、资源配给,期望的效果等。审视,项目一开始的条件,和当下条件的差异。时刻检查,条件是否发生了改变。

第二,反问自己。为什么需要解决这个问题,为什么你需要解决这个问题。问题的收益和付出,在不同层面,是都成正比的吗?如果是边界的问题,你能消除边界吗?最后,再问问自己,类似的问题,其解决方案是什么。

处理难题过程中,值得推荐的是:新建一个文档,记录思考和开发的过程。现实生活中,不同于考试做题,没有明确的对与错。记录开发过程,有助于养成主动思考的习惯。

用户共建,敏捷开发

在项目进行时,很重要的一点是:不能脱离用户,而是和用户共建。与直接的用户,形成良好的互动关系。不断提问,不断澄清。决策、实施、演示、反馈。

传统的工作模式,是瀑布流式的工作方式。一切都规划好,然后按部就班实施。瀑布流的好处是,能看到一个大的愿景。但其坏处,也很明显:不够灵活,容易需求延期、特性膨胀。

敏捷方式,则克服了瀑布流的缺点。整个是一个三步走流程。首先,评估当前的处境。然后,朝着预期的方向,做一次最小化的改进。最后,明确事情的边界,让事情先运转起来。敏捷也有其缺点:变更频繁;难以全局最优,常常陷入局部最优。

最后,在项目进行时,不要一个人埋头进去代码。参加代码评审等活动,了解和学习别人的代码优点,也能让自己的代码更鲁棒。同时,也别忘了,遇到问题,求助他人,也是一个解决问题的中上之道。

项目交付

项目的最终目标

项目交付,不是一锤子买卖。这项活动,是类服务业:其最终目的,是解决用户的需求,让用户愉悦。

要记住,用户需求的并不是代码,而是代码逻辑后的解决方案。

所以,过程可能并非那么重要。如何挖掘用户的期望,让用户满意,才更为重要。

以终为始,挖掘期望

如何挖掘期望,不如看看《高效能人士的七个习惯》之二——以终为始。让我们从项目结束的角度,思考和评判如何叫做成功。

一旦我们记住了从期望出发,项目交付就会容易很多。以期望出发,需要确保项目中的每个人都清楚该期望。在做决策时,也尽量选择靠近该期望的路径。根据现有期望,去分析用户的需求。如果有更好的方案,能满足用户期望,则大胆的提出需求变更。最后,随着项目的进行,不断地审视期望。

在项目交付时,签上你的名字。程序创造是一门艺术,留下签名,不仅是责任,同样也是自豪感的体现。

团队建设

以上活动,离不开团队。一个好的的团队,会让事情做起来事半功倍。如何打造优秀团队,使其成为项目的牢固支撑,也是项目推进的重要一环。

优秀团队的定义

首先看,优秀团队的画像。对内,成员及时沟通。DRY 不做重复的工作。对外交流,团队成员是个性独特、心情愉悦的。外界听到的声音,是一致的。这要求团队氛围活跃,同时也要求项目文档清晰、准确、一致。且在会晤前进行了充分的准备。

曳光弹开发

项目采用曳光弹的开发模式。

曳光弹,和敏捷的概念类似。在夜晚作战时,先打出一发曳光弹,照亮目标区域,以期后续能精准命中目标。曳光弹开发,要求:个体互动高于流程工具;软件支撑高于详细文档;客户合作高于合同谈判;响应变化高于遵循计划。

建设务实的团队

另外,建设一个务实的团队,也十分重要。务实不务虚。Talk is cheap, show me your code.

时刻评估变化

务实的团队,会时时刻刻留意周遭环境的变化。无论是项目范围的扩大、还是项目时间的缩短、抑或是增加了额外特性,都需要对变化进行度量。不顾大环境的改变,蒙头做自己的开发,乃大忌。

修补破窗,是每个人的责任

同时,项目内部也要提防破窗的蔓延。破窗效应,在软件开发和团队文化中的负面效应,都影响巨大。修复破窗,不是某个人单独的责任,QA兴许能发现功能的异常,但是编码风格的懒散、可读性的下降,是无法察觉的。

慎重选型,全面评估

在技术选型上,谨慎考虑最新技术。新技术,有它的优点,但也存在踩坑的可能。慎重考察,小规模测试,再考虑将其铺开,是较为稳妥的做法。不能因为道听途说,就在核心项目上大动干戈。

这对于新成员进入新团队,也类似道理。新成员会带来新视角和新技术。但改变现有体系,风险重重。最好的办法,也是在小项目上,进行实验。

记住,技术选型,其目标仍然是:交付起作用的东西。当然,极端保守也不行。一味守旧,迟早也会因为生产力低下、不适应市场变化,而被市场淘汰。

在管理上,也是类似道理。万万不可,因为对特定公司的盲目崇拜,就照搬其模式。

合理评估当下环境。市场相同吗,机会和挑战相同吗,组织规模相同吗,管理和文化相同吗,用户规模和需求相近吗?

问完这些,再针对问题进行改善,做局部的吸收,是更好的做法。

务实的团队支持

最后,在支持上,务实的团队,一方面会提供自动化工具,帮助完成自动化测试、部署以及交付;另一方面,也会给项目设定合理的边界,让项目在合适的时机停下,进行交付。