项目开发工作方法(需求调研角度)

本文描述项目开发的工作方法,侧重于如何在项目各个阶段,正确获取需求,保证需求不失控。

项目可按照如下阶段进行。

项目立项

前景分析、商务分析、需求概况获取、初步沟通等

  • 确认项目意向
  • 确认项目范围

调研

调研可分为两个阶段:

  • 业务调研:了解用户自身的情况,想解决的问题
  • 需求调研:了解项目的需求,确认我们的解决方案

两个阶段的目标可能互相有重叠,时间上也可能重复,不是先做一个阶段再做另一个阶段。只是侧重点不同,所以做了区分。

调研的主要形式是访谈、分析、记录。

业务调研

侧重了解用户的工作,想解决的目标。

目标:了解业务直到我们能承担项目范围内任何一个岗位的职责

对用户工作的了解,没有固定模板,需要具体项目具体分析。可重点根据以下几项内容进行调研:

  • 组织结构
  • 工作流程
  • 考核报表
  • 岗位职责

(参考文档《走出软件作坊》“文档知多少——设计文档编写方法”章节)

需要交付以下内容:

  • 访谈记录

时间、地点、人员、主题、结论

  • 用户一手资料

保留搜集到的,对项目有帮助的资料,要保持原样。

需要记录来源、名称、搜集时间、用途等内容。

以上内容,根据访谈会议、主题进行分组保存。一次会议应当解决一个或一组相关主题的内容。

需求调研

主要形式为:方案讲解、原型沟通

初期可能会有高端视角的方案讲解,后期大部分的时间都应该是做原型沟通。

原则:

  • 必须接触一手用户
  • 必须让一手用户获得实际的用户体验感觉

原型构建时技术选型的原则:要让用户有真实使用系统的感觉。所以:

  • 逐页翻ppt的方式不合适,因为用户感受不到页面跳转。

交付物:

  • 以会议或者主题为单位的方案、讨论结果、原型的迭代记录

需求分析

将调研阶段的成果系统化。

交付物:需求文档

需求文档的内容:

  • 项目背景
  • 需求概述(范围、功能分析、用户分析等)
  • 项目建模(这个名字有点故弄玄虚,我理解就是提供详略得当的抽象角度,让人几分钟就能大致了解项目要干什么)(核心流程图、核心用例、实体设计等)
  • 功能性需求(功能点拆分、各功能点描述、跨功能点流程描述)
  • 非功能性需求(质量要求、项目约束等)

关于上一章节调研阶段的方法是否掺杂了过多设计元素(比如原型图)的疑问:

那些只是与用户沟通的手段,目的是获取用户的全部想法。掺杂了设计元素带来的不利因素,可在需求分析阶段予以去除。

例如:

没有高保真原型的时候,用户会说,太难看了我不跟你们聊天,所以必须提供一个美观的样式,但是实际项目开发中,采用什么UI方案一定不会在这个阶段就确定下来。

在需求调研阶段,可以先“迎合”用户的想法,提供高保真原型,在需求分析阶段,根据获得的全部信息(用户提供的需求+用户对这个高保真原型UI的感觉+我们自身的技术评估),重新确认技术方案。

需求评估

每个功能点,除了要做什么内容的描述外,还应对其它因素做评估。现在想到的如下:

  • 可信度:某项目有些需求是完全由我们内部人员发挥出来的,标注一下可信度更有利于后续的工作。其余项目视情况决定是否需要
  • 优先级:紧急、一般、可选等。优先级会决定:项目历次迭代先做哪个需求、出现变动或者时间不够时会放弃哪个需求
  • 事务数:估算开发工作量,一个简单Action视作一个事务。或者采用其它基准评估也可以。不必要特别准确,不必要定义严格规则,在一个项目需求内标准统一即可。比如事务数为2的,不代表工作2人天,只是代表工作量大致上是事务数为1的功能点的2倍。

可参考之前的文章( http://nonesuccess.me/?p=379

技术评估

调研阶段、需求分析阶段,都或多或少的需要项目架构师参与。最晚到需求分析阶段结束时,需要得出明确的结论,当前的需求方案是在技术上是可实现的。

架构设计

由项目架构师负责。

需要总结项目所有的技术要求,技术方案。

可参考公司项目架构模板。

开发、测试、发布、维护

按照正常流程工作即可。

不再明确区分设计、开发两个流程,项目管理的最小个体是独立开发人员,此人员应该具备拿到需求后,直到上线的所有环节的工作技能。

需求、设计阶段需要确认的各项内容,如果因为各种原因,不能提供,则至晚到功能交付时,提供以下内容:

  • 核心用例
  • 功能点
  • 实体模型设计
  • 流程图
  • 实体状态转化图

在此过程中:

敏捷开发

能确定敏捷开发一定是正确的方法论,但是1、细节我还没想太清楚 2、必须是传统开发流程训练得十分流畅的工作人员才能更好的接受敏捷,直接采用敏捷方法一般不会顺利完成工作。

所以只列举几个我能想到的要点:

  • 不必等上一个流程完全完成,就可以把已经成熟的部分进入下一个流程。比如某一组模块进行了需求分析,比较完善之后,就可以进入开发阶段
  • 尽一切可能,让实际用户早日使用系统,每天检讨:今天的成果让用户体验了吗
  • “用户而不是客户”:找使用系统的人,而不是付款的人
  • 欢迎需求变化
  • 验收测试驱动:做事之前先想好怎么验收,以验收标准驱动工作。比如做功能之前,先想验收过程是,古林街孟姐用系统成功发证,那么任意一次迭代中都要评估,我就是孟姐,我发证试试,成功了吗,有助于发现很多问题

需求变动

项目开发过程中,会因为我们想法变化、客户情况变化,发生需求变动。

变动时需要交付:

  • 新一版的需求文档(用各种形式标注或者备注发生了什么变动)
  • 需求变动文档:记录本次变动的内容,以及变动原因等其它需要说明的事

交付后,本次需求变动的内容可进入开发流程。

《项目经理应该知道的97件事》笔记(3)

11. 你们的问题,我不买单

在甲乙双方的合作中,想清楚不应该为甲方的问题买单不是个容易的事。但想清楚之后,怎样不落入另一个极端其实也不是个容易的事。

说了甲方的问题我不买单之后呢,把一切问题都推给甲方吗?那只好等着项目崩盘了。

谁的问题谁买单,但“明确到底是谁的问题”,应该明确这是乙方的责任。实现明确了,双方认可了,真正出现时才是甲方的责任;除此之外的一切情况,都应由乙方承担。

12. 如何发现优秀的IT开发人员

招聘是玄学,也是科学。

掌握正确的理论知识、熟悉业务领域、能应用、有沟通和社交能力,这些都是老生常谈。最打动我的一条是关于正确工作态度的理解:

  • 既有创造高端产品的热情,又接收项目的限制条件

成熟的必要条件总是少不了中庸二字。

13. 优秀与普通的天壤之别

用五倍的工资招一个人,让他干十个人的活,成本降下来,这是其一。

如无必要勿增实体,如有必要努力减少实体,少一个错的人,就少一个错的人给你挖坑,这是其二。

有没有魄力去分析一下到底谁优秀谁普通,万一你的项目就是个体力活,五倍的工资也只能出一倍的效率呢?这是其三。

其实说到底还是个问题域分解的问题,只有把问题域等价的拆分下来,才能知道什么是你需要的技能,谁是你需要的优秀人才。

14. 规模决定一切

一切的一切都源自于人类太笨,如果脑容量大到你能掌握每一行代码细节,什么问题都没了。

也不好说,毕竟还有机会成本在,还要在脑容量无限大上面加一条效率无穷高。

既然做不到,那就拆分吧,分而治之的核心在于,把项目拆分成规模足够小以至于能完全理解的模块,并且,这些模块怎样组合成整体也是个规模足够小的问题。

石猴是怎么当的美猴王?前面是水帘洞,你要“钻进去”、“寻个源头”、“出来”、“不伤身体”。

基本功还是在抽象能力的基础上能做等价的问题域拆分与合并吧,越来越发现,一支笔等于笔杆+笔芯+笔帽这件事,不是谁都能理解。

15. 记录工作流程,然后严格执行

有多少项目,连记录工作流程都做不到?

哪怕有份工作日志呢?

16. 剔除多余的工作流程

用添加检查流程的方式保证正确性,那谁去保证检查流程的正确性?

你以为你以为的就一定是你以为的吗?

你以为他以为的就一定是他以为的吗?

你以为他以为的就一定是你以为他以为的吗?

软件团队仍应该是核心+n个助理的模式。只对极为简单的、极为少量的信息共享并苛责每个人的理解是否到位。不想让其他人知道的信息,一定要保证其他人完全不知道。

 

 

项目开发进度管理方法论——功能点

功能点

功能点作为需求调研的主要成果产物,用于说明项目的所有功能性要求

功能点的整理形式为逐级拆分形式,采用恰当的文档形式,对应项目需求。最高层的结点即为项目名称,对应项目的全部需求。其余结点逐层拆分,每一个结点的所有子节点的内容相加,应等价于该结点

根据以上形式,功能点的形式应为一棵,其叶子节点是任务安排的最小单位。一般来讲,每个叶子节点的开发工作量预期不应超过4人时。同时,应同构任务的拆分,逐步明确技术方案。至叶子节点处,应做到实现方案明确,即通过项目架构下的成熟方案的简单组合,可实现该节点对应的功能。

在文档形式选择上,应利于形成以上的树结构,并且利于修改。在实践中,我们采用xmind软件,用思维导图的形式体现功能点。

功能点估算模型

优先级

  • 未定(?):是否实现该功能点,由于某些原因尚未确定。
  • 核心级(零级):该产品之所以为该产品的核心特性对应的功能点。例如学生管理系统中的添加学生功能。
  • 重要级(一级):保证该产品能够成功运行的功能点,换言之,该功能点没有完成时,该产品整体处于不能使用状态。例如Web项目中的大部分框架功能(如用户登录),学生管理系统中的学生列表显示。
    以上两级,都属于产品发布时必须实现的功能。区别在于,核心级的需要更多考虑优化问题。
  • 亮点级(二级):完成后,可以使产品增加亮点,从而增加客户的满意程度。
  • 期望级(三级):用户期望拥有的功能。
    以上两级应争取实现。如果项目发布周期紧而放弃,应评价该项目完成情况较差。
  • 非重要级(四级):实现后有好处,但不实现,也不存在太大的坏处。
    项目周期紧时,优先放弃此级。
  • 反向级(九级):功能点的实现目标,与其它功能点(特别是前四级的功能点)有冲突。开发此类功能点的任务,必须在通盘考虑所有功能点,并且有对冲突有明确结论的情况下才能开展。

复杂度

  • 0:未定义,还未能做到有明确用例。此级的功能点倾向于暂不实现,必须先确定用例后划定复杂度,再进行实现。
  • 1:简单级,包含2个以下正常用例和3个以下异常用例。或用常识即可取得一致理解。
  • 2:复杂级,包含3~5个正常用例或4~8个异常用例。
  • 3~5:根据用例数类推。一般不超过5级。
  • 9:待定级,没有明确用例。此类功能点归入9级而不是0级的原因是,由于某些原因,无法明确用例,因此需要特殊的方案处理,例如先随意实现一版做思维引导。此级别的功能点的开发方案,需要特殊处理。

技术风险

  • 0:无任何技术风险,由1个项目架构中的成熟方案即可实现,或者由不超过3个项目架构中的成熟方案组合实现,且组合方式也有明确方案或丰富经验。项目组任何一个人对其进行独立实现时,选择的技术方案不会与项目技术负责人的想法有差别,且最终完成时间与项目负责人的预估不会有明显偏差。
  • 1:一般,由项目架构中的成熟方案即可实现,接近于无风险。
  • 2:有风险:由项目架构中的成熟方案+高度内聚的特定技术方案可实现,例如某流程中包含微信支付功能。定义为此级别的功能点,需明确指出其技术风险点,如“微信支付”。实现此级别功能点时,需要有特定技术方案的详细参考资料和解决方案。
  • 3:有较大风险:对现有架构方案中的通用性约定作调整,如之前的架构方案是简单页面,而新功能点中需要大量使用iframe。
  • 3:有较大风险:需对现有架构方案中的内容做结构性调整,如之前的架构方案是直连数据库,某功能点则要求提供缓存。
  • 9:极大风险:与现有架构方案完全不兼容,如之前的架构方案是Java Web,但此功能点要求开发iOs app。

 

 

《项目经理应该知道的97件事》笔记(2)

8、西蒙,保持简单

项目的利益相关者往往使事情变得过分复杂

原因时他们只对商务目标负责,不对实现过程负责;只负责提需求,不负责考虑需求是否现实、是否有矛盾、是否可以实现。所谓屁股决定脑袋,他们的位置决定了他们中的大部分人天然的会把事情搞复杂。

所以作为项目经理,把事情回转到正确的道路上来,是要持续做的事。在这一点上,既没有方法论上的银弹,更没有某个具体事务上的银弹。

把需求拆分成足够简单的小的部分,再逐一实现。需求足够小,所以不容易出错。足够简单,所以能过快速的得到用户的反馈。

但是拆开了之后,项目管理难度会加大,要防止并行的线索过多,项目失控。拆分需求的成果物要“可持久化”,可以用某个恰当的方式保存起来,放在任务队列中慢慢做。要做到这一点,我一直以来的看法是要有统一的方法指导这个过程,而不能仅仅依赖于把任务信息详细的记录下来。

话说回来,并不是拆分使项目管理难度加大,而是拆分让项目的难度都暴露出来。不拆分的话,你根本不知道有难度的部分在哪。

9、你并不是非比寻常的

不要重复造轮子。

项目开发是创造性的工作,要搞清楚你要创造什么。大部分情况下,要创造的都是业务领域内的东西。

10、随时间滚动

用户并不知道自己的准确需求,开发人员要注意区分,找出真实需求。

找出之后,用文档准确记录,并与最终用户而不是中间人沟通这些记录。

敏捷开发方法通过让用户参与开发过程,来缓解这些问题。

 

《项目经理应该知道的97件事》笔记

书还算挺接地气,以案例的方式讲解了一些项目管理过程中的注意事项。不是系统性的讲解某个知识体系,所以读起来压力不大,可以放在床头每天看两页。

1、尽早让用户参与

这个之前写过一篇让用户尽早参与,不是让客户尽早参与。隔了一年多再看,这期间用户探讨会没少开,但形式上注重了让不同意见的用户分别发表意见,而没有重视最终的排版,所以很多时间都浪费了。总而言之,这就是一句多年前就知道是真理,但是每每回想往事都觉得做得不到位的地方的原则。

2、避免打地鼠式的开发

要重视软件质量,重视架构,重视重构,要可持续的开发软件。不要在初期就用开发效率衡量程序员的工作,做得慢的人可能把更多的精力放在了软件质量上,做得快的人可能把程序拖到打地鼠的状态,不知道下一个bug在哪发生。

现在兼任项目管理者和技术核心,团队规模小,项目规模大,所有的细节我都了解,所以应该更多的从架构师的角色而不是管理者的角色去避免这个问题。当前状态是,可持续的目标完成得还不错,更应该注意的是避免走到另一个极端,即过度设计。

3、一词不慎坏大事

主要讲的是本地化的问题,任何一个翻译不当都会严重影响项目质量,从而导致项目的重新开发、测试,耗费大量的成本。

短期内都不会接离岸外包性质的活,所以本地化问题应当不会遇到。但这一篇提到,应该把翻译文本放到一个单独的电子表格中,把翻译质量和软件质量分别测试,这是一个很好的思路。

软件质量包含方方面面,重要性不同,测试方法和代价不同,导致测试的时机也不同。怎样合理的分割执行,很能考验项目经理的做事分寸。

4、让项目发起人自己写需求

做项目的时候总有个疑惑,技术已然如此成熟,开发效率虽然不高但也在合理范围之内,测试质量虽然不高但项目都不是由于有bug才失败的,那问题到底在哪。后来慢慢想明白,核心的还是需求,需求,需求。当年教UML的老师提过一句,需求分析是软件工程中唯一还没有形式化描述的领域,此言得之。

凡是有关于需求的问题,都是一样的感觉:早就知道它重要,但每每觉得它其实应该更重要。

并不需要太形而上的考虑让谁去真正完成需求文档编写工作,重要的是一定要保证所有的相关方都参与了这个环节,提出了自己的想法。我总是习惯于把简单的项目开发搞成产品设计,从这个角度,搜集所有用户的意见是设计出良好产品的必要保证。抛开这一点,只说项目进程管理,那么让所有人提出想法之后,还有个非常重要的步骤是要有最终结论,并且让所有人都认可最终结论,这样才能避免最终的扯皮。

之前总是不知道文档怎么写,需求写着写着就变成了设计,设计写着写着又会掺杂不少需求,看了很多参考资料也总有不明觉厉的感觉。现在想想还是那句话:需求是我们要干什么,设计是我们要怎么干

又一句真理!不过问题解决了吗?

如果一句话多年前就已经如雷贯耳,那重新说一遍肯定没什么意义,我们又不是宗教工作者。总要想明白,之前的问题出在哪,哪里没有理解,才能进步。

终于想明白了,项目管理水平和分工水平的底下导致我根本没有精力维护两份核心文档,在做需求的时候总有”把设计一起做了好赶快去赶工不然来不及了“的需求,在做设计的时候又往往“这里添加这样一个功能会好一些”,所以写来写去还是都码在一个文档里面最方便。

近一年来终于有把项目做得规矩一点的可能了,按照软件工程规范写文档的需要也就应运而生。毕竟,能流程的把需求写明白,不犯过度设计的毛病还是跟得上讨论节奏的必要保障。现在的经验是,用一份单独的文档收拢需求,不要牵扯设计细节,只写要做什么。因此可以保证篇幅足够简单,也能保证在需求发生变化的时候快速响应。

这样做了之后,有会逐渐在项目管理上反应好处。之前是全环节一手抓,又当爹又当妈,从需求整理管到函数命名和大括号缩进。后来架构逐渐稳定了,代码可以放开让大家发挥了,主抓设计。现在团队磨合水平逐渐提高,项目工具代码页逐步完善,需求一旦做好,设计其实也不是个太需要天天盯着的事。

总而言之,都是简陋的项目管理方法惹的祸。

5、要简单,不要复杂

软件通常要解决复杂的问题。现在的问题是,那种固有的复杂问题中有多少是你强加给最终用户的?

需要随时反思这个问题。

复杂往往意味着混乱,简单才是个要一直追求的东西。

项目实践中我的做法是:不论这个任务你要做一个小时还是两周,你没办法在一句话内说明白的,就是你没想明白

6、偿还你的技术债

临时修改、文档不足、依赖关系不恰当、快捷方式以及偏离预期设计上的问题,这些都是技术债务。发现一个就处理一个,可以让软件质量一直很高。攒了一堆还不处理,可能你就再也不想处理了。所以,要积极偿还你的技术债务。

对我来说,这又是一段需要落地的理想化真理。偿还技术债务这种谁来了都会说正确的话(当然要放在项目管理世界观下,这会儿考虑成本利益的都是耍流氓),只有考虑清楚当时为什么不干,才有价值。

翻了翻这一篇,找到了一句有价值的:“最好的方法就是评估在每个迭代结束前发生的所有债务”。嗯,关键还是要有清晰的迭代关系,连个里程碑都没有的,就别谈什么项目管理了。对,说的就是当年的我。

7、为团队添加人才而非技能

与招聘有关。招人的时候,考虑这个人的工作能力。一个有能力的人,培养技能是很方便的事。

嗯,是种思路。

为什么不能贸然采用新技术

常在论坛里见到这种说法,比如struts2和springmvc之争,在开发范式的合理性和先进性上认同后者都强于前者,但就是由于项目组里面没有熟练用户,最终弃用后者等等。

这种看似真理实际上也是真理的说法,没有一定的实践很难说明白。今天恰好碰到一个恰当的例子。项目一直采用struts2,文档中说,写Action可以继承ActionSupport也可以实现接口Action,减轻框架代码污染而选择实现接口,没问题。struts2带防止重复提交的机制,写了个demo调试成功然后配置使用,也没问题。运行过程中,用户总报一个异常页面,经过排查和询问,发现是由于重复提交导致的,但直接给出的是500页面,而不是我们配置好的重复提交错误页面。

项目此时规模已经不小,配置文件的清理问题一直没有妥善解决,所以怀疑是因为某些原因,配置未生效。再者重复提交问题确实拦住了,只是错误提示信息不对,也不属于严重问题,所以一直搁置没有解决。到某天觉得确实应该解决的时候,翻遍文档资料也想不明白原因。乱试之下发现,必须继承ActionSupport,未继承的情况下,struts拦截器链到某一步的时候会抛出空指针异常,原因不明。

修改继承结构后,问题解决。

bug级别几乎可以归入“可选“,但谁知道问题都会出在哪。所以项目技术选型最没有风险的方法就是”所以需要用的东西我都用过“。

选用新技术是必要的,但是在做项目规划的时候,要计算这些未知成本。即便是”可选“级别的bug,积累多了,也足以让用户的体验下降一个档次。

 

帮调一个奇怪的jsp显示数据的bug

struts2项目中,同事这样描述了一个bug:

在后台action中执行了一段逻辑A,再调用函数B,该函数为Action中的对象C赋值。在Action中打印C的各字段值正常,jsp页面中,使用el表达式显示C各字段的值,其中字段1有值,字段2无值。

另外一段Action函数中,无逻辑A,后续调用函数B等部分完全一致,返回同一个jsp页面,在前端可以正确显示所有字段的值。

经过大量调试无果后,我介入。过程如下:

  • 将页面上的字段值作各种替换,如输出字段1的部分改为输出字段2,或相反。此步骤是为了排除那种由于视线盲点死活都无法发现的拼写错误。无果。
  • 去掉逻辑A,运行,可以正常显示。恢复逻辑A,又变成异常情况。

至此基本确定错误范围是逻辑A,但逻辑A只是简单的新建变量、赋值等操作,看上去并不像会导致莫名其妙异常的那种代码。

又仔细看了看前端代码,发现其使用方式是用一个struts的iterator标签嵌套了一堆el表达式,el表达式使用的是struts iterator标签中定义的循环变量。再查后发现,该循环变量与逻辑A中的操作的某个变量重名了。所以页面上显示的是逻辑A中操作变量的值。

窗户纸捅破了,其实也没什么太高的技术含量。但调试代码中暴露的问题确实也挺让人头疼。

分而治之的思路如果掌握了,知道先把无关代码都注释了再调能减少很多猜测分支,调bug的思路会大大清晰。

所谓的相同逻辑在两段函数中运行的结果一个正确一个不正确,实际上这两种情况下jsp页面中根本就是访问了两组变量,但debug一下午,测试数据都是完全相同的那一种情况,姓名全叫张三……

不知道给变量规律化起名字的意义,起码循环变量都加个temp前缀,单数复数一个加s一个不加。变量名的起名规则就是,在定义变量的代码处向上数10行,找一个眼熟的名字,这……

一篇充满怨念的记录,项目规模上去之后,事事掌控的模式已经不可行了,分工之后,满眼都是这种无聊的问题。团队建设,看来还任重道远。

===

最近总是精神焦虑,无法集中精力想问题,效率有了很大的降低。生活中的杂事很多,还是要努力克服。黎明不远,加油!

战术服从与战略,执行很重要

对B项目N模块作第二次迭代开发,第一次迭代中的代码基本上废弃不能用了,至少是6人月的损失。

当初需求不定,做这部分开发的战略目标是用模拟的需求确定架构,保证后续的可扩展性和可维护性。但执行过程中失控,开发的中心逐步转向了拉锯模拟需求的各种细节,而代码架构没有得到足够的重视。最终的结果是,得到了一个满足我们想象中需求的可运行版本,但可维护性很差。

在任务执行过程中,每个阶段都回顾是否符合战略目标是必做的事。一旦发生偏离,不要怕推导重来,不要怕承认错误。无论在任何情况下,对人月的浪费都是不可接收的。

以其昏昏,使人昭昭

标题语出《孟子》。

整理出一封安排工作的邮件。

背景

安排人总结与上级系统对接中出现的问题,其中之一是由于数据模型设计的不一致,某张表的对接工作完全没有开始,需要我拿具体方案。

我的re大意:

放弃之前数据模型设计的xx原则,表结构的改动包括xx,字段约束变更为xx。在此新方案下,代表用例xx。其余细节你补充,有需要的话找我讨论。

其实相比之前,这次还算有挺大的进步,起码说明了要让对方的职责范围(其余细节你补充),但细想仍然不算是一个良好的工作安排,至少缺乏以下方面的内容:

  • 要让对方具体做什么事,如“开发完成xx功能和xx功能”或“整理完成方案细节”
  • 完成过程中的关键节点,如“补充方案细节后,整理邮件并讨论,无意见后继续”
  • 要求的完成时间,如“两日内完成”
  • 完成标准,如“xx功能开发完成,测试用例完成,达到xx发布标准”

另外,不管是通过邮件也好,任务管理平台也好,之前工作的一个重大欠缺是,只有零散的任务安排,没有项目完成路线图。完成这个任务之后,项目整体进展前进了多少,又有什么任务可以开始进行了;如果这个任务没有按时完成,应该怎样调整,项目是否会延期,这些都应该是项目经理想清楚的事。

开发项目的特点就是工作任务及其繁杂,而且无法保证所有任务分解都在同一个层次上,所以日常工作安排会非常混乱,甚至无法找到一个足够完善的范式去表现项目进展过程。至今找到的比较好的模式包括:功能点清单、用例、依照用例的测试记录、零散的专题性说明。

技术出身的项目经理还要避免不断尝试新工具的癖好,牢记没有可以让你一劳永逸的银弹,工具的重要性远比不上日常不断的整理和调整。

 

 

收和放

从最开始工作的时候就有个朴素的愿望,我要做的不是赚钞票,而是造印钞机。构建一个工作系统,观察运转过程,不断调整,看着它不停的产出。但其实很长时间以来我都忽略了一个问题,如果你的最终目标的副作用之一是节省你的体力,那你在日常工作中就一定要特别克制你的懒惰。

之前定过几条规则,所谓的业务层应该怎么写,放下去让人执行,在一段时期内运转良好。但总归没有银弹,不可能有什么工作规范、最佳实践之类的东西能一劳永逸的解决所有问题,初期越是顺利,越容易导致意识上的麻痹。有推而广之作用的工作规范中,存在的任何瑕疵都会被数倍的放大,最终遵守墨菲定律,可能会出问题的地方,就一定会出问题。今天翻了翻别人写的代码,发现超过100行的代码就已经很难驾驭了。这也怪不得别人,放下去的东西,总要有个收的过程,才能发现不足,调整之后,才能再次的放出去。有了决策就要跟进,要总结反馈,切记。