我以前看过一个投票,盘点程序员不喜欢的事,有两条和文档相关:
不喜欢写文档;
不喜欢项目文档太少。
说到风险,很多人都模模糊糊有一些了解,然而在软件项目中,有风险意识的却不多。比如说:
早些年我在做项目管理工作的时候,除了制订计划外,还要花不少时间去跟踪计划的执行情况。
项目管理上出了问题,管理者总是喜欢从流程规范的角度去想办法,于是为此设定了不少流程规范,例如每天要写日报,根据日报更新项目进度,每周要开周例会,看看项目有没有执行上的问题。
对任务进度的量化也是个很困扰项目经理的事情,需要频繁的去问程序员:“你这个任务进展如何,大概完成比例多少?”,从程序员那得到的答复通常都是个很乐观的数字,例如80%。第二天以为他能做完,结果一问是90%,就这样要持续好多天才真的算做完。
说到开会,是很多人心中的痛,每天白天忙于参加各种会议,压缩了本来就少的可怜的工作时间。最可气的,有的人开完会工作就算完成了,而像我们写程序的,还得下班后加班加点赶进度!
所以一说到开会,程序员们往往如遇洪水猛兽一般,避之不及。
开会是有价值的
不知道你所在的软件项目中是不是也有各种流程规范,例如:
若干年前,我接手一个陷入困境的项目,当时的项目经理刚从技术高手转型项目管理,还是没有摆脱技术思维,项目没有什么计划。
他把关键模块分给了自己开发,同时还要兼顾项目管理,导致自己的工作遇到瓶颈,其他人的进度也受影响,大家加班加点也没什么进展,士气低落。
我接手后,第一件事是重新制定项目计划,在排任务时,避免了对某个人的过度依赖,设置了几个关键里程碑。我还特地把第一个里程碑设置的相对容易一点,只需要运行核心功能。
技术转管理,是很多技术人员的梦想,所以经常有人问我,怎么样才能转型管理?
项目管理,是最基础的管理,既要管理一个项目,又要协调整个团队一起,完成共同的目标。
我的管理转型就是从项目管理开始的,在从技术转型项目管理的过程中,让我从以前专注于局部技术实现,逐步转向关注项目整体;从个人的单打独斗,到借助整个团队的力量一起完成一个项目。
如果你随手拿起本软件工程教材翻翻,第一章一般都是讲“可行性研究”的,呈现顺序仅次于“绪论”,可见其重要性。
“可行性研究”通常讲的是如何科学地论证项目的可行性,以及这个项目是不是值得做。这个知识点比较简单,落实到期末考试的题目上,一般只是一道像这样的选择题或填空题:
“可行性研究主要从哪几个方面进行?”