我对项目管理的一些思考
一,项目管理的模型
从传统瀑布流到现在的基于快速迭代的各种灵活的模型和管理框架,发展非常迅速,而且也逐步被引入到各个非软件开发领域里去.新的企业也在尝试着比较新的敏捷开发的实践.比如减少冗余繁杂的文档,项目估时,站立会议等.
有些成功了,有些也失败了.失败的几乎都是因为团队本身的成长限制了执行的力度,或者与团队现有的管理模型有所冲突,导致各种不适应,最终放弃.我们自己也在这方面做着很多的整合尝试,却最终因为缺少比较接地气的工具而受了不少挫.
也有不少实际的问题,比如:
1,每个人互相不太知道对方做了什么,所以到了涉及到其它人相关的模块时,无法确定自己是否应该继续还是停下来.
2,我的代码写完了,测试总是迟迟不能得到通知.
3,如果总是在需要跟别人交互的时候打扰别人,又会让整体的效率降低.
4,TM,PM也缺乏对项目的整体的直观的管控.
…
这样的类似的问题很多,各自也有各自的解决方案.我们采用了一种比较安静的做法,整个过程不希望总是打断别人.并且可以实时的监控所有人的行为,比如正在做什么,哪些是做完了的,哪些是正在做的,哪些还没有开始.是不是有任务被移交到了我这里(比如需要测试的部分).
我自己也能一目了然的知道我所有的工作,并且能以非常直观的形式看到我每天的工作.管理者也要能非常清楚的看到整个团队的工作.
二,工具的用户体验和工具的实际效果.
如果没有更合手的工具,大家往往不愿意使用.
比如画软件原型,有很多原型软件如Axure,但是很多人还是更喜欢用笔在纸上画.只有真正某个软件足够便利而且节约很多时间,大家才会转到这个上面来
在一直以来的项目管理里,也一直在调研不同的项目管理工具,最开始的Project,TFS,很多开源的软件,网站等各种应用.却一直没有找到一个很适合我理想中的工具,我的需求也很简单:
1,一个自由公开的白板,
2,一个直观查看所做任务的日历
3,一个燃尽图,知道项目是否延迟还是提前
4,跟其它组或者公司进行协同.
另外一个需求是:我的个人倡导,我希望建立一个共平自由的合作环境.
我大致说一下传统的软件的做法和我的冲突:
1,在我调研过的系统中部分是有白板的,但是操作上比较麻烦一些,我希望能直接拖动就能达到目的的.
2,普通认为表格是最好的表达形式,比如所有的任务列表,bug列表,可以通过搜索,排序等方式进行管理.每次要分析今天哪些人做了哪些事,需要一次一次的筛,一次一次的分类看.我是觉得挺累的.
3,软件项目往往会产生的情况是前期松,后期紧,甚至超期,我希望知道是什么原因导致了这种情况的发生,当前项目进展是否是健康并且正常的.我只需要一个燃尽图.而现在的往往做得比较复杂.
4,跟其它组或公司的配合,这个组和公司并不一定是软件开发团队.比如客户公司的营销团队,设计部,开发部等.需要整体协作起来.
5,我希望所有团队成员都是平等的.没有等级关系,没有项目经理,组长,组员的层级关系,没有谁对谁负责.因为一个项目是大家共同努力的结果,每个人都应该对最终的结果负责,每个人都应该有自我协调能力.
我的需求不太多,但是我希望足够好用,而且直接有效.
三,团队协作和软件
从一个游戏来看团队协作
我以前曾经玩过一个游戏,相信也有很多同行也玩过,游戏很简单.在一个空房子里,摆满很多凳子,然后由一个人被蒙上眼睛,由另一个人在旁边指挥,什么地方应该转弯,什么地方应该往前走,最后到达目的地,再一次,摘掉眼罩,由他自己决定.两次的速度相关是非常大的,结果也是显而易见的. 所以细节的实现更应该去相信员工自己,让员工自己来解决,而不是事无巨细的管理.
从版本管理软件的发展来看团队协作
大家在工作中肯定有用过很多版本管理软件,比如有名的有: vss,svn,git每一个都有各自鲜明的特点.
Vss: 它有这样比较明显的特点,整个过程基于锁定和解锁,如果你想修改某个文件,需要先锁定签出,然后修改完后再提交,提交结束后便解锁.这时如果有其它人需要修改这些文件,需要等别人提交后才能解锁,签出,然后修改完成后再提交.他对版本的管理是依赖于同时只有一个人使用一个文件,当然你可以选择vss支持的另一种更开发的模式,但是这个已经放弃了vss本身的优点,利用版本管理软件来建立起一个有序的开发的流程.以消除文件编辑的冲突. 同时带来的负作用就是大家往往一半时间在等待其它人提交释放锁,而且在修改完成后,时刻要记得去提交.签出时也小心翼翼.
Svn:从vss过渡到svn,是一个自我解放的过程.每个人可以自由奔放的修改然后提交,如果提交的文件里没有别人修改的文件,就只管提交,如果有,更新下再提交.在实际工作中,因为大家实现的是不同的模块,90%左右的冲突都由svn本身的合并功能解决了.只有极少部分需要手动合并,这要归功于svn的强大的合并功能还有忽略文件的配置等.它把可能的冲突转给的团队线下自身来解决,事实上,人的可调控性远远好于软件的强制性,很快采用这个版本管理软件的团队,制定出了一套协作的方案,使每个人的工作独立,相互没有影响,当然也同时促进了团队的架构水平和管理水平.
Git:从vss过渡到git,则是一种更大的自我释放,它的历史版本管理,不再完全依整服务器,文件提交也不再完全依赖网络,他可以仅仅只是先提交到本地,在本地积累到一定程度后,再一起提交到服务器.可以说一个本地副本在提交到服务器前就是一个svn,一个分支,你可以自由的回滚,可以最终提交你的决定.更多的工作交由线下自身来解决.
他们也呈现出了一种从封闭到开放,从软件限制转到人为管理转化的过程.很可喜的是每一次转化都极大的提高了生产率.也同时提高了团队的管理水平.
再回顾企业管理,总监下有经理,经理有部门,部门有组长,组长有成员.一级一级管控.如果有个办公室需要买一本书,可能需要给组长申请,组长再提交部门审批.一级一级.从想买到实际买到可能已经过了一周了.一周后,可能这本书就没必要买了.当然在大的企业管理里,这样没什么问题. 但是我想如果把这种层级关系放开,由扁平化的组织结构来管理,再制定一定的机制让人员自我管理.这个效率会高很多.当然可能也会非常混乱.
对于小的团队来说,如果所有成员扁平化,每个成员都是团队里重要的一员,每个人都有权力做所有的事情.我想这一定会是一个更高效的团队.我举几个例子:
1,如果团队成员因为有病不能来,但是项目又要求他这方面的工作完成,我可以直接拿过来他的任务然后完成它.
2,如果我有一个模块开发完成,我可以直接拖到测试员,测试员直接接手测试.
3,测试员完成测试,反应出一些问题,可以直接递回我做修改.
我想权力越大,操作就会越谨慎,我们不应该总是把大家绑得死死的.大家有了灵活性,反而不会去做一些实际上会逾越自己权力的事情.只在必要时去做.这个必要性,线下大家讨论制定出一个协议,然后执行即可.就好像我们制造了一把斧头,但是我们不规定别人如何去使用他,线下我可以帮他们推荐一种比较好的挥斧方式,但是如果他喜欢,他也可以用别的方式来挥斧达到更好的效果.
还想说点什么
如果你是一个程序员,你是不是很想分享你的一个惊天的发现,可能是一个js的游戏开发框架,可能是你写的一个无比牛比的demo,有可能是你找出一个许久没有解决的程序的bug.也许是你花了两天时间最终配置起来的nodejs成套的开发环境.你是不想希望得到别人的关注,领导的关注,希望有一些成就感.那么你肯定也希望有一个能写点什么的地方.所以也希望有一个知识库,可以展现自己.
