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

8、西蒙,保持简单

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

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

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

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

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

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

9、你并不是非比寻常的

不要重复造轮子。

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

10、随时间滚动

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

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

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

 

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

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

1、尽早让用户参与

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

2、避免打地鼠式的开发

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

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

3、一词不慎坏大事

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5、要简单,不要复杂

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

需要随时反思这个问题。

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

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

6、偿还你的技术债

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

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

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

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

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

嗯,是种思路。