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项目，整体来说，项目时间紧张，人员极度不足，需求变更较大，并且在项目中期才介入。因此导致问题较多。但其实很多部分可以做的更好。希望能在今后的项目中，做的更好，收获该项目的总结成果。