误区
之前我没有项目经验，在上一家公司的项目管理上，我只是照葫芦画瓢。
产品发起，整个项目没有项目经理这一说。或者说有，但却真的感受不到，一丁点也感受不到。
产品发起会议，或者开发发起会议。无论谁来发起会议，一般都会针对于某一具体需求或者某一具体实现方式。
没有具体的任务规划，任务拆得不够细致。这个和开发自身有关系。当然那时的公司确实没有一些指导性质的模板和导师。
任务分得不够细致，就会导致工期评估差距比较大。
各种O们的临时紧急需求，很多O没有技术背景和项目管理背景。很多时候提出的需求都是发生在项目开始过程中。
都是很急的需求，不得不重新估算时间和排期。开发为了避免延期风险，就是让产品排优先级，然后我们根据优先级估时。
直到有必要的需求都在这个迭代中计划上。
没人全局把控，产品从产品角度，开发从开发角度，业务从业务角度。始终没有一个最终的协调人。
产品在对各种O的对话中，气场和身份不足，导致需求基本是提出就会安排。即便是请出青岛总负责人出面沟通，最终的结果一般就是接受。
之前我们是青岛为开发，北京为产品、UI、前端、测试。异地沟通。电话会议是常有的事情，私下的临时沟通电话更是家常便饭。
信息同步、开会、理解程度 都会造成沟通上的成本增加。
紧急需求上线后，三个月没人反馈。问了才知道，财务提的需求他们没用过。
开会一般都会临时决定，发起人会准备资料，但是其他人提前看资料准备问题的情况极少。导致会议冗长效率低。
解决
现在来看，无论如何，我们在知道这些问题，但是为什么不去处理呢？应该还是习惯了，即便是整个项目非常挣扎，依然是按老规矩走。大家都是困在了这个围墙中。
我现在也有了一年的项目管理经验，初入门道。只是对自己的过往进行一下分析解决。
以上的误区和问题，我觉得需要一个有经验并且有点能力的人来带领这个项目团队。
1. 确认项目经理
但是按照我上家公司的情况，一般会立经验丰富的主管直接管理这个项目。
当时的情况是，项目主管在项目上的精力完全不够，甚至说项目管理在项目主管心中的优先级比较低。
根本原因，青岛作为研发中心，技术基因强大。很多技术管理人员，没有意识到项目管理的重要性。
组织架构主要是垂直单线架构，技术-主管-经理-总监-CTO。无非是自己下面的人多，按照业务或者大项目分了组而已。
如果让开发作为项目经理，
首先这个开发是否愿意承担项目经理职责？
是否真的能够赋给项目经理一些实权？
是否有鼓励机制，比如晋升优先或者奖金等？
建议：
加强项目管理意识；
加强项目管理能力；
必要的话可以作为量化指标来看；
加入一些激励机制；2. 培养主动性
因为技术基因影响。主管或者经理出于“好心”考虑。
他可能会考虑到，如果把项目管理中的某些事情分配给组员，会不会引起反感？会不会影响在组员中的美好形象？
也算是确实分下来一些，比如项目规划和估时以及排期。但是我没经验的，是不是可以稍微引导一下？
领导总想为老好人，但是这样自己手头的任务分不下去。
下面的人也得不到成长。
建议
对组员有一定的规划和成长要求，而不是放任其随意生长（有一定风险）
领导应该提高自身的管理能力，管理技巧。而不是凭经验论。
定时关切Review分下去的任务，从结果或者过程提出建议和优化。3. 确认好需求边界
产品经理和负责人，确认好需求边界。飘忽不定的需求给项目的打击是很大的。
开发在摇摇坠坠重估时，此时的估时肯定会有达量的冗余，因为之前需求的变动，上线时间一改再改。
在加上，主管、经理偶尔砍几刀。所以开发在估工时都会冗余很多。为了被砍，为了需求不定。
建议：
确认好需求，可将项目周期缩短，小版本迭代。
强化项目上线时间约定，锲约精神。不仅仅是开发要遵守。其他人员最好也能严格遵守。（当初这个做起来真的比较困难）
信心是做出来的，几次项目的延期和需求的变更会严重打击大家的信心和士气。所以按时上线很重要。
规划得有，但是是不是可以考删掉远在4个月以后的需求。4. 紧急需求
比如财务的一些紧急需求，其实确实紧急，但是使用频率很低。
是不是可以有另一种解决方案？不一定非要按照财务提出的那种设想。
我们达到并满足了他们的目标，后期再去做页面更加直观。
比如要一个订单查看页面。那我使用程序定时拉取新订单推送到企业微信或者钉钉。结果也是非常满意的。
不一定非要做一个页面，很多时候做成一个页面，大家会发挥自己的产品意识，增加一些不必要的按钮、功能和逻辑。
建议
深入了解需求，而不仅仅是一句话，也不是根据用户提出的需求来做，用户到底想要什么？--他就想要有订单能及时知道。
紧急需求是否真紧急，也得看使用频率。使用频率低，是否有其他方式实现。
能搁置的暂且搁置一下，之前就我一个人开发，很多原本紧急的需求因为开发不够，搁置了也就搁置了。然后甚至有的都自己消失了。5. 高效开会
会议开始前，大家几乎么有预习的习惯，会上很多时候没有主持人，大家就问题会讨论很深，导致时间不可控。
有的会能一个电话解决的就没必要拉这个拉那个来开会。这种仪式感不重要，开会也不是拉家常。
为了让领导知道这次会议的重要性，这个项目的重要性。拉着领导一起开：
但是领导的事情多，很多时候在会上他们是一直回复信息，其实当时是比较尴尬的，领导不能专心处理问题。我们看着领导没用心听，不了解的同事还以为领导漠不关心呢。
建议：
发起人拉群，提前@人提醒大家关注和看会议内容。
发起人做会议：主题、流程、最终结论
确认会议主持人，随时控制会议进度。有些细节会后沟通。
领导可以不必参加需求讨论会，把会上讨论的疑难问题，会后单独和领导会报，再拉一个小会议电话沟通确认即可。
重要项目启动会、项目上线等会议尽量简短，领导全身心参加。保证大家的斗志，统一思想达成一致。有些形式必须要有的。6. 相关方
开发与客户沟通少，因为两地沟通，基本是产品作为翻译官将业务转成需求转达给开发。
开发没有感知用户的存在。
建议
多听听用户怎么说。
大家达成一致，每月电话会议或者视频会议沟通一次。会议可以控制在1小时以内，氛围可以轻松，主要是手机需求以及反馈问题。
如果有多个业务部门都是相关方，那么主要思想就是设置定期沟通（规律的定期沟通）
7. 转变
优胜劣汰的企业付薪给我们，我们就要服务于这个企业用户。甚至说服务好用户。
我们开发也要主动从自身求变。好好说话，真心替我们的用户思考过问题。
从产品和业务角度认可业务优先级，而不是紧紧盯着开发重构、新技术的应用。
建议
转变意识：我想为你们服务；
我能力不行，但是我能主动学习项目管理知识和经验，并在项目中实践，反思，再实践。
我要为我开发的产品负责，它的迭代，扔给它的需求，和它相关方，它的应变能力。
主动一点，也许事情看起来并没有那么难。现在的我，我们
新的公司，给了我很多的机会，纠正了我很多认知，我也从实践中反思了很多，收获了很多。
公司的组织架构是矩形架构：横向职能，垂直项目
项目首先会有项目经理，项目经理有一定的项目经理奖金。当然项目经理要履行项目经理的职责。都会有绩效。
项目经理，开发，产品，测试，DBA，运维，PMO 这些会组成一个项目组。
整个项目组会在项目经理的引导下，开发项目直到上线。然后迭代下一版本。
现在项目中，有使用瀑布开发，有使用敏捷开发。
我所认知的一点是，各个职能团队人员虽然属于职能。但是基本会长期泡在各个项目中。
项目中学习到的东西，在项目中的成长也是很重要的。所以项目经理有一定的敏捷角色中PM的角色：引导大家，赋能给大家。
我们正在尝试的敏捷（尝试）
其他团队物理面板：我们团队的面板：非常简单项目并行和项目特殊性，我们采用周交付，不确定哪一天交付什么（特殊需求除外）。
因为项目为运维性质的项目，有开发，紧急需求，客户答疑问题较多。时间不太可控。
并且大家积极性都很高，没必要要求必须排满周开发任务。
自己开发完直接到需求池，领取最优先级的需求，或者帮助其他组员分解开发任务。
业务需求 + 技术需求 双向需求驱动，占比5：1。
周最高优先级占比 1：4
这样大家不会因为具体时间的冲突导致交付的压力。周交付的任务为必须交付的最小单元（本周必须交付）。
没必要的会议去掉，我们基本都坐在一起，不去会议室。工位周边就可以开会。电脑操作随时记录，会后发出来。
周五：计划会（15：00 ~ 15：30）10分钟，材料都是平时积累，会前整理完
地点：工位
目的：回顾上版本迭代精进结果。分析过程问题原因，总结问题。认知好与不足，下版本迭代重点要解决的问题。；讨论新需求优先级；达成一致周最小目标。
周五会后 + 周一开会前 这段时间，是大家缓一缓，总结自己规划下周的时间。
磨刀不误砍柴工，想好怎么做，才能预知困难和风险。
对新需求进行任务拆分，需求理解，任务具体估时。
周一：迭代会（10:00 ~ 10:15）15~30分钟，微调任务；统一思想；确认周迭代目标；
地点：工位
周三：如果需要可以开一个简短沟通会我们自己维护的计划和交付，简单高效。团队协作，互相可看。
我们的产品是刚毕业的新人，我们互相指导学习。
他最近也在研究用户故事如何写好。他打算下周先打印出来，大家看看自己感受一下。
最近我看完了一本敏捷开发相关的书籍，同时推荐给了他。我们想单独摘出好的或者值得讨论的地方，大家围在一起拿出半小时讨论一下也未尝不可。
还有一本我正在看，可能我实践经验不足。总是感觉一般般的感觉。思路不是很清晰。
有读过的朋友可以发表一下看法。
总结
敏捷我们在路上。不为敏捷而敏捷。
我们互相提高，互相帮助，能力提升，升职加薪。生活质量更好。
大街上敏捷一大堆，根据实际情况摸索敏捷之道。发挥大家的能力，提升大家的能力。为大家带来点实际的东西。为企业带来点实际的东西。
项目管理根本目标是把项目管好，项目管好，大家更加自信，互相也都信任。所以项目管好是项目组良性循环的根本。项目经理要多花大力气去关注，去学习。
谢谢关注公众号