项目管理

记录发生的问题并总结

风险

随时留意可能发生的风险, 记录并探寻解决办法.

1. 人员变动

2. 需求变动

3. 多个项目排期冲突/穿插进行

项目组结构

1. 职能划分明确

2. 寻找擅长做并且愿意做这件事的人

3. 一定要形成3-5人的小组(甄选组长和甄选的方式是重点)

项目流程

0. 需求的产生(业务方提出, 需求挖掘等)

1. 产品调研, 设计, 需求, 交付基础版需求(需要从最终结果->整体的方向->关键细节进行说明)

2. 需求评审, 讨论需求可行性, 开始规划项目里程碑节点

3. 技术: 根据项目需求进行技术选型, 构建项目脚手架, 划分技术职能团队; 测试: 根据项目需求评估风险, 划分职能团队; 产品: 完成项目需求的阶段规划, 给到最小可行性需求计划, 交付基础版需求.

4. 敏捷开发迭代(产品交付需求->技术开发->测试->产品验收->产品交付需求)

5. 针对项目进行阶段性封板迭代

6. 业务方验收

项目管理软件的重要

1. 技术人员的进度不好跟踪, 需要有软件来跟踪任务, 任何一个小的任务都要有软件能跟踪到, 否则技术人员会有惰性.

技术管理

技术管理, 技术架构是很多中小企业所缺失的, 要专注于解决这方面的问题.

任务分配不能随便

现实场景:

一大块需求或功能任务下发之后, 由leader拆解分配并设计数据表, 再组织会议讲解需求, 随即开工.

结果:

由于各开发人员大多只关心自身任务, 而程序设计与关键逻辑以及各个功能之间的关联性都一知半解(由开发的技术水平, 业务水平所影响), 导致最终交付的程序千疮百孔, 需要花成倍的时间与精力去修修补补(并且代码的健壮性, 可维护性都不佳).

解决方案:

1. 设计填空题

项目开发实际上可以分解为多道填空题, 上级leader要对分配的任务设计填空题(填空题需要给予完整的业务设计思路, 程序设计代码), 同时根据任务难度分配对应人员, 有的人做基础题, 有的人做拓展题. 而做拓展题的可能是一个小组, 那小组leader按照同样思路去设计填空题; 如此递归下去, 所有的任务都有明确的业务和代码设计思路, 并且具体细节都被上级leader所熟知. 如遇到程序问题, 容易定位到具体责任人, 以便尽快修复.(还一定程度上能满足leader的虚荣心)

任务时间节点要把控到位

现实场景

结果

系统设计时由于需求条件复杂, 建议增加分类来统筹不同条件的分类.

现实场景

可维护性差

结果

版本管理上会存在影响效率的情况, 很多时候还很严重

有无必要安排专人来维护管理代码版本