2017年,在杭州做scrum master+开发,当时由于开发任务不是特别重、公司组织架构规范,流程把控较好。
2018一年,在成都某创业型公司做开发+负责团队的时候,常常由于开发任务比较繁重,团队组织架构较小,同一人身兼数职的情况下,导致在思考流程,如何把控进度、质量上做的并不是特别充分。
2018.12.01正式算是从团队负责人+主程的身份转变成为project manage。
目前主要的任务:
1、系统学习project manage,希望能在新的公司站稳脚跟。
2、心态及做事方式的转变,从以前的从开发角度去思考甚至抱怨很多事情,转变到现在从整体大局观去考虑,去思考解决办法。
3、了解成熟的项目管理框架,方式,及前辈的经验。因此拜读了此书《网易一千零一夜》
项目紧张、工期不足
1、加班
加班是解决工期不足的首要解决办法,但是加班也会导致士气、及效率较低的状态。
需要合理去调动项目组员的情绪、士气。
2、加人
加入熟悉项目的人会大大提高效率;加入不熟悉项目的人,由此带来的沟通、管理成本也会大大提高。
3、需求调整
需求的优先级、重要级调整;项目成功的关键因素、需求首要完成,作为重点;非重要、迫切的需求可以做适当调整。
4、小迭代开发
避免由于测试不充分、产品质量不过关。3个月以上的项目可以分2~3次提交让QA提前介入。规避风险。
5、关键路径法
关键路径:项目中所需时间最长的一条路径。
优先集中力量解决该路径。
6、合理的bug管理
若时间不足时,可以适当降低Bug的修复标准。
周期长、版本大
1、建立团队:共同朝着一个目标努力
2、项目目标尽早确立:
a、关注用户体验
b、满足互动需求
3、尽早做好计划,但是计划不等于承诺;需要提前看到风险;安排项目日常,不求完整,但求实用。
4、逐步推进措施:
a、小步推进、频繁沟通
b、技术预研
c、底层接口整理
d、可行性分析
e、项目配置系统设置
5、短周期,多迭代,预留出更多机会检查项目中间状态
6、重视每个迭代计划,评审。让团队设立具体目标,让团队审核目标完成情况。
7、迭代过程的回顾、持续改进。
Scrum迭代
长期优化、集成的长期项目迭代;结合以前的scrum master经验及学习归纳总结。
1、例如迭代周期设置为每两周一次;设置每个发布日期在每两周的周四;每个月与产品沟通下1~3个月的整体需求结构。
2、迭代后周五:进行迭代回顾,阐述上一个迭代周期中遇到的问题;下一个迭代需求讲解,庞大、逻辑复杂的需求需开发人员在前一天先看需求文档,以达到在会议上能及时提出问题讨论,尽量减少开发过程中造成问题、反工;与测试人员沟通测试时间,提测时间点,所需测试方面、效果;与开发人员沟通开发完成时间;在为期两周的迭代中,可以将需求分为几个部分,分批测试。
3、除非常紧急的需求外,原则上一个迭代周期内禁止增加新的需求。
4、每日站会,通过白板的形式,同步各组员问题,并及时将问题提出。
5、需与外部协调需求,需要在需求确定下来时就及时与外部沟通,避免由于此带来的需求延迟等。
心态的转变
这部分主要针对自己及曾经项目的总结,并且以现在的思考角度,当初如果换一个做法,应该能做得更好。
在8月份,我在前一家创业公司接受“ww”项目。该项目要求在两个月内仿造另外一个网站做一套类似的系统。在开始做该系统时,领导A告诉我,我主管理,副编程;如果能将所有事情都合理安排好,也可以只管理,不编程。听起来很心动,但是后来发现事实并不是这样。
在进入到该项目中,该项目两个月期限已经过了一个月。当时项目的现状:
1、主体流程尚未走通
2、项目代码中能用的大块没有一个走通、代码逻辑混论
3、项目成员:后端我、后端开发B、后端开发C、前端开发D、前端开发E
4、当时甲方来了一个人,作为项目负责人,我当时直接与甲方沟通,沟通后的结果发现,除了我们需要仿的站点之外,另外还有很多很多重要但是前期并未良好沟通的需求需要去处理。因此,在沟通后,项目延期半个月。
5、在几次开发过程中,发现开发B理解能力比较低,同一个需求需要讲解很多遍,并且无法做出实际的效果,漏洞百出。无法独立完成功能。在项目后期,开发B退出该项目组,开发C进入项目组。
6、项目缺乏需求及测试人员。
综上,在该项目中,由于以上种种原因,并不能像是听起来很美好那样,主管理,负编程。因此在加入项目后,紧张的加班加班加班,整个项目整体流程、主题结构、采用框架基本全部修改,最终凑合着上线。
当然,这样上线的项目在后来实际运营中,确实出了很多问题。
1、甲方对项目报表一块、实时性,准确性要求非常高,但是这一块逻辑较为复杂,在很长一段时间没有满足甲方要求。
2、项目设计较大金额,但是却没有针对此处做较为严密的测试,导致项目直接产生经济损失。
3、在项目设计、开发、以及没有测试的情况下,并没有对系统性能做了较好的考虑,在有限的时间下,为了完成功能而完成功能,导致在高并发的情况造成数据错误。
4、由于1、2、3的情况,以及沟通的原因,在项目结束后至今,仍然投入部分资源在该项目中,且未收到维护费用。
该ww项目现在仍在运行中,并在最近也出现过问题。当然没有一个系统是不会出问题的,但是以现在的角度来说,从不得不主开发,到现在可以抽身出来以pm的角度回顾整个项目,觉得还是有很多值得改善的地方。
1、有效的向上沟通:项目最初,并没有意识到该项目会在开发完善后,由于甲方对我们的信任等原因然后即刻投入使用,因此,在项目初期,明知道没有产品及测试的情况下,对该项目没有良好的把控质量。
2、项目成员能力参差不齐,WBS分配不合理,急于赶项目,很多关键的地方都由我一个人完成,现在觉得这样特别不好。应该做的是在项目中将技能教于开发C然后由C进行开发处理。因为教不会手下的话,就会永远累死自己;并且会导致没有足够的时间从大局出发思考。
3、项目初期,抱着觉得自己能力很强的情况下,并未及时提出进度、质量等问题。
4、与甲方的沟通,并未出具测试报告。一方面甲方并没有要求我们这么做,并且在过程中甲方也参与测试;一方面是没有足够的人员时间来做此报告。然而在甲乙方交互中,不管从今以后作为甲方,还是乙方。在讨论初期,应定下甲方期望效果,TPS\QPS等数据,期望达到的目标,并在项目结束后出具相应测试报告,报告包含功能测试、性能测试、并发测试等。
5、需求的管理不完善,项目最初需求:“仿造XXX站点”;项目进行到1个月后;甲方提出更多其它方面的各种各样的需求,导致项目直接由可控,变为不可控;很多已开发由于甲方的需求转变需要重新开发。而在此正确的做法应该是:即使客户的要求是”仿站“,也应该提前跟客户确认,客户端的界面一致,但是其内部仍有许多关键功能不一致。在初期可以先梳理关键流程予以甲方确认,避免返工的现象。
6、由于缺乏测试,可以开会组织全部项目成员进行Bug Brash 初步先消灭部分重要、影响大的bug。
7、借助甲方测试,小迭代开发,定期提交成功,及时让甲方介入,让问题较早的爆发出来。
8、做良好的风险管理,项目后期的效果表面
该ww项目,整体来说,项目时间紧张,人员极度不足,需求变更较大,并且在项目中期才介入。因此导致问题较多。但其实很多部分可以做的更好。希望能在今后的项目中,做的更好,收获该项目的总结成果。