1. Lack of resources
Discussion background:
It is impossible for any company or department to have sufficient resources, and managers must adapt to the lack of resources. Therefore, the following issues were discussed:
- There are too many demands, and you want everything?
- The construction period is tight, and it is time to set a flag card?
- The staff is limited, and there are HCs who can't recruit people?
- Too many dependencies, various situations, various delays?
1.1 Too many demands - prioritization
| product | Make sure the main flow takes precedence |
| C-end user experience priority | |
| Discuss alternative alternatives (see through the essence of demand, the product needs to cross the river, not necessarily a boat/bridge) | |
| Product compromise and downgrade (go online first, then iterate) | |
| prd demand quality (resonance at the same frequency, consistent understanding between production and research) | |
| technical aspect | Reuse existing components/services |
| Code standardization, styles can coexist appropriately | |
| Scalability (reserved for 2 phases, 3 phases) | |
| Architecture is not over-engineered | |
| Combine two into one (technical optimization can be combined with product requirements, one-time development, testing, and launch) | |
| Plug-in type (before some services are not modified, substitute services are used first, and then partially upgraded) |
1.2 Tight time limit -- improve efficiency
- Compromise of the architecture scheme (there is no perfect architecture, first realize the requirements, and then iteratively optimize)
- Division of labor (experienced and more skilled personnel do the fastest)
- Tighten before loosening (the construction period is rushed forward, leaving buffer)
- centralized closure
- Sub-module parallel testing
- Detailed task disassembly (the finer the granularity, the more precise the control)
- Coordination of external dependencies (high-quality solutions to external issues, clear what needs to be done by the other party, and time points)
- Do it synchronously (service, permission, database, development and online application together)
- Make plan B
- Organize and launch todoList
- Secondment Support
- Regular check (stand-up meeting, morning meeting, weekly meeting)
- Ask for advice from an expert (technical difficulties, ask more questions and communicate more)
- Ask for advice face to face (not limited to IM communication, telephone, face to face)
1.3 Unable to recruit people -- pay attention to daily accumulation
- Rely on introductions (proactively find friends, colleagues, former colleagues)
- Go to the platform to find it yourself (BOSS, Lagou, Maimai)
- Advertising (moments, social platform promotion)
- External influence (official account, community, technical Q&A and drainage)
- Referral Rewards
- Enhance existing staff capacity
- Improve R&D efficiency
- Job core competitiveness, job highlights
- Appropriately relax the threshold
- Appropriately increase benefits
- network accumulation
1.4 Too much dependence-- learn to adapt to others
- Early node communication (project establishment, development, joint debugging, testing, online)
- Active communication (if necessary, the communication method can be upgraded: telephone, face-to-face)
- Make plan B
- Risk warning, problems escalated upwards
- maintaining relationships
- Think from the perspective of others (solve his troubles, eg: accompany with overtime work and drive home, etc.)
- Thank you letter after launch
- Please stand on the platform
- My own people (good friends who have advantages in different departments, and then promote through friends)
- Read the document first, and ask for help with the conclusion of the problem (service entry, exit, etc.)
The above is the exchange experience. In summary, the core three elements: MVP (minimum feasible analysis ) iteration, improve efficiency/ability, and focus on daily accumulation.
2. Emotional restraint
Key words: poor communication, dissatisfied leaders, emotional disturbance of employees
A very important function of the project manager is communication and coordination. Most project managers lack the ability to predict risks, and when faced with risks and problems, they cannot give good feedback to all parties in the project, let alone propose good solutions.
For example, when faced with unreasonable needs, most technical transformation project managers dare not and will not give feedback to customers, let alone express to the company leaders. After the task is forced on team members, they cannot appease the emotions of employees. The result can be imagined . The problem for project managers who do not understand technology is that they do not analyze the problem (especially the technical problem) in depth. Often the mantra is that they don’t understand this part, they didn’t expect or didn’t understand this part. For XXX, I can’t wait to hold a meeting Can pull the whole team. Assigning tasks later is either giving orders or being a sounding board, which gradually loses prestige.
As a front-line basic management personnel, the project manager has customers, Party A, users, and supervisors externally, leaders externally, and internal project team members. They need reasonable planning, overall arrangement, and effective communication to truly complete the project.
2.1 Leaders are dissatisfied
| question | Analysis & Solution |
| distorted information delivery | more discussion |
| Back to confirm | |
| quick feedback | |
| Insufficient risk identification | teaching methodology |
| take it personally | |
| Understand upstream and downstream | |
| understand everyone's troubles | |
| Go deeper into the front line | |
| Not proactive enough | not enough rights |
| The value is not clear | |
| guide praise encourage | |
| enhance vision, awareness | |
| Mr. Key | |
| Relationship maintenance | |
| subordinate problem troublemaker | Moisturize things silently, not against him, everyone is the same |
| equipped with back up, make up for him | |
| Standardize the process and clarify the system requirements | |
| Poor ability - improve technical ability | |
| Careless - ordered to improve | |
| Get used to it with him | |
| make full preparations | |
| The flag of the military order changes back and forth | Insufficient research and insufficient information for decision-making |
| team disagreement | |
| Not communicating enough | |
| Coarse grain size, not fine enough | |
| Turn crisis into opportunity and find a better solution |
2.2 Employees get emotional
| question | Analysis & Solution |
| Unreasonable work distribution | 了解每个人职业诉求，尽量满足 |
| 是否愿意 | |
| 工作量太多 | |
| 长期固定 | |
| 公众场合被批评 | 私底下沟通 |
| 被甩锅、委屈 | 帮他澄清 |
| 边界划清楚 | |
| 适当安抚 | |
| 风险提前周知(事实) | |
| 对结果保证(先于别人之前发现问题) | |
| 边缘业务，没价值没成长 | 轮换制度 |
| 提高要求 | |
| 技术赋能 | |
| 关停下线(说服大家) | |
| 真诚沟通 | |
| 放任务池，等主动认领 | |
| 做得越多、错越多 | |
| 队友不给力 | 摆正心态 |
| 互助提高 | |
| 宽容、别较真 | |
| 待遇被倒挂 | 所做事情要证明价值 |
| 成长性，放权给他 | |
| 主动给予 | |
| 荣誉奖励不公 | 尽量公平 |
| 考核标准要明确 | |
| 透明、公信力 | |
| 其它方面补偿 | |
| 给最需要的人 | |
| 性格孤僻、与团队不和 | |
| 被领导画大饼 | 不要期待太多 |
| 领导尽量言行一致 | |
| 被领导PUA | 量力而行 |
| 容忍性 | |
| 听一听就行 | |
| 情绪低落 | 团队关怀 |
| 自我调节 | |
| 情绪宣泄 | |
| 团队荣誉感 |
以上是交流心得，综上面对项目团队负面情绪，作为项目经理要及时感知并调整。最重要的是：把事情做正确。
三、全局迷失
关键词：没有全局规划能力，资源调配失衡，目标不清晰
比较典型是水来土掩兵来将挡型，一事一议，全然没有计划型，结果导致资源调配失衡，不是资源浪费就是资源短缺。往往需求来了，不加以深入分析和设计，就急急忙忙向公司申请一大批开发人员介入，后期又过早把人员释放，导致测试阶段和上线后问题不断，没有人员及时修复系统缺陷。
项目管理人员从接触需求开始，就要全面分析需求、任务拆解、阶段划分、人员配置等一系列工作，建立项目整体计划并按计划推进和资源调配。
3.1 为什么要分期
| 为什么要分期 | 项目定位 |
| 创新试点类型--最小MVP，敏捷迭代 | |
| 稳定正常类型--固定跟版制、班车制 | |
| 专项聚焦类型--集中资源，快速完结 | |
| 资源短缺被迫拆解 | 外部依赖不可控 |
| 迭代开发，目标清晰 | |
| 阶段性验证结果 | |
| 规模小，可控制 | |
| 最快看到收益 | |
| 缓解大项目压力 |
3.2 没有规划
| 问题 | 分析&解决 |
| 紧急需求插入，节奏被打乱 | 尽量减少需求插入--提前预知，未来2个版本要做啥 |
| 留buffer--积少成多，会导致大时间轴被拉长 | |
| 政策不可控--长期关注行业政策，提前准备 | |
| 线上业务逻辑不合理 | |
| 体验优化类 | |
| 老板需求--敢于挑战老板(虽然最后还是乖乖做) | |
| 人员变动 | 留出熟悉/交接时间 |
| 平时培养backup | |
| 文档沉淀--前人栽树后人乘凉，衡量文档写得好不好，看第二个人能不能比第一个人时间更短，更快。 | |
| 局部模块明确--把业务需求翻译为技术需求，直接开发 | |
| 需求不明确 | 目标不够明确 |
| 战略决策调整 | |
| 逻辑不明确--不同产品顾此失彼，缺乏全盘熟悉，整个项目团队都梳理维护，技术补位 | |
| 测试用例，分支不够全 | |
| 边界不清晰 | |
| 理解不一致，没达成共识 | |
| 对上下游了解不够 |
3.3 资源调配
- 项目拆解粒度不够细
- 需求理解不一致，不透彻--没考虑问题根本，而是表象
- 调研不够充分
- 联调阶段，阻塞block
- 外部依赖风险评估--可参考已接入案例，上期迭代等
- 大量工单走流程、审批--提前了解，提前申请
- 永远要有plain B
- 对项目里每个人能力有准确了解
- 人员规模过大，沟通成本--项目团队规模控制10人以内闭环。
四、角色固化
关键词：忙于细节，忽视角色变化：从拉马车到赶马车
从技术岗转型到管理岗的项目经理人员通病，多数就是因为技术和业务能力比较强，被领导重视和认可，逐渐过渡到带团队，进而转型到项目管理工作。可是角色没有及时调整和转换，更多精力在于技术和业务细节上，忽视了整个项目的协调工作。项目成员不能放手去做，依赖性强，项目经理本身还有一堆文档要写、协调事儿要处理示，结果就是项目经理四处救火，忙得要死，且团队成员也很难独撑一面。
项目经理的作用：正确定义目标、制定项目计划、推动执行、进行团队建设及跨部门协调、保证质量、保证沟通、控制成本、密切监控过程并纠偏等，这样才能保证项目最终的成功。
交流心得：
| 目标 | 分析&解决 |
| 去中心化 | 提前全局规划、分配 |
| 所有人对项目全局了解(这期功能点，目前进度，哪天测试，哪天上线) | |
| 提前培养 backup | |
| 文档沉淀，“错题本”积累 | |
| 责任边界，所有人清晰谁负责哪些模块 | |
| 敢于充分授权，只负责跟进 | |
| 同角色内部多分享，所有人都快速接手 | |
| 项目组内部信息广播，传递(开大会，全员周知，不限于微信群，邮件) | |
| 流程规范 | 之前做得好的，列出来借鉴 |
| 兼职pmo，不能只关注自己开发任务 | |
| 整理项目管理清单，每日一问 | |
| 随时把控关键角色 | |
| 关键节点check，有明确各方配合方案 | |
| 达成共识，不同阶段该做什么 | |
| 至少组织3次全员会，需求评审，排期，联调提测 | |
| 到处救火 | 提前评估难度、风险，并做准备 |
| 子模块业务可以独当一面 | |
| 正确的行动计划(重要&紧急) | |
| 留出buffer时间 | |
| 做好复盘 | |
| 通过之前案例找到解决方案 | |
| 做事方法论的沉淀 | |
| 提升大家解决问题思路和能力 | |
| 做些通用demo可参考，只负责难点攻坚 |
五、利益分配
关键词：部门不同，目标不同，利益不同，利益分配的合理性
人们奋斗所争取的一切，都同他们的利益有关，这是马克思的至理名言。人们为团队工作，总要获得利益，或物质的，或精神的。利益的分配，代表着一个人的贡献和成就。必须公平合理，同工同酬，论功行赏，这样才可以调动职工的积极性，提高团队士气；反之，就会引起职工的不满，挫伤职工的积极性，降低团队的士气。
交流心得：
| 状况 | 分析&解决 |
| 多劳多得 (前提是要让所有人认可规则，否则依然不公平) |
项目角色(核心参与者) |
| 简单配合支持方要感谢(上线邮件、复盘会、当他领导面感谢) | |
| 目标把控者 | |
| 过程中表现(平时收集细节) | |
| 项目攻关人物 | |
| 核心价值 | 满足用户核心需求(成就感) |
| 增进不同部门协作 | |
| 项目实际收益 | |
| 独有性(为什么是我们做) | |
| 关键先生，较大突破 | |
| 平衡未来 | 动态看不同角色权重 |
| 提前考虑未来依赖部门 | |
| 平时注重挖掘潜力人员 | |
| 分配不合理(负面) | 不愿意配合(外部门) |
| 消极、应付(项目内成员) | |
| onwer威望值下降 | |
| 得不到认同感，人才流失 | |
| 提前与各方领导申请资源，方便协调 |