范围好广啊 偶只能随便说说偶的感受~ 因为没体验过别的公司管理方式 偶们系软件开发 1. 首先和大环境很有关系,取得上级甚至是公司级别的认可和支持,否则有可能到后期只能唱独角戏,还落不到好处。 2. 得到上级的首肯和确认了,接着才是客户。客户是很重要的,但没有强大的后备军支持,有可能你里外不是人啊~~ 3. 说到客户需求,相信大家都有同样的感触,不是每位客户都知道他想要的是什么,能具体描述出,换句话说,就是需要把客户的想法与语言转换为技术性文章还需要沟通这个重磅武器。诱导、总结、评审、反馈、确认。BA分析由此产出其Spec,功能描述,等等。(当然啦,也有好些客户技术出身,这个时候沟通也许对 BA来说较轻松,有时BA和PM是同一人。) 4. 这时候项目计划可以和接下来的步骤同时进行。当然项目计划要求要准,要细(物质准备什么的,但不一定完善,后期补进),还有就是风险计划(后面再述)。 项目计划完毕了,QA and DM Plan就开始进行啦。 好些东东和阶段是可以并行的,而且因项目类型不同有可能不同,举例瀑布型,渐进型等等。 5. SA接手,根据BA的客户需求再分析框架设计,DFD等。这时候才理解为客户需求转换为技术语言。 6. 再下去RD开始介入,先是系统,然后模块划分设计文档等等。 ······ 总体感觉,项目经验很重要,很多东西是慢慢累积的。中间的风险有些公司会累积成风险库,这比较好。(偶继续学习中~) 什么需求变更CR,CCB meeting等等都是为了更好的跟踪确实客户需求到位,好些同事都已提及。 激励成员是其中一项必要措施,话又说回来,这也同公司的文化背景有关,但总之“画个大饼先”。另外,一个部门里几个项目管理人员,若他所争取的资源最多,所带的team当然比较有face (呵呵,开个玩笑) 相信大多数人积极主动还是有限的(呵呵,偶也会偷懒),所以规范制度与奖惩机制凸现出来。感觉是越细越好,执行有章,但效率有时显得有相矛盾,所以尺度还需要PM掌握。 好些PM非技术出身,可能有时候技术人员强势,PM说不上话,这时候引导内部相互牵制,验证有必要。沟通也有许多方法,刚开始时多问个为什么,有凭有据说话的分量才会重。 有些个任务周期较长,不提倡任其完成,到点给我的想法。周会是个蛮不错的管理方式,虽然偶也蛮不喜欢开会的。有时明明就隔道办公桌也发个mail不明挑了说。但还是需强调效率,有问题积极解决,无事散朝。PM总结,也善于诱导发现问题。 另外,我会要求在设计和开发阶段,RD每周至少缴一份报告给我,心得也可以,重大issue也可以,目的在于给予同事不断总结自己的经验,一根烂笔头抵过好记性。这对项目后期总结也很重要。 开发中期,可以根据需要设立demo阶段,有时候一群RD明明知道coding不符合设计要求啦也埋头做下去,也没人站出来指正,这时候PM和同级人员相互稽查中间的工作质量,也可以起到唬人的作用嘛,^_^ 开个玩笑。 QA和RD的矛盾本身就是对立的,无可厚非,甚至bug review的时候拍桌子叫板子都有可能。PM这时候就要起到调节作用,第三方仲裁委员会也许是个点子。 往往一个项目的进行,好复杂啊,还有可能多个项目并行资源共享的时候,人员资历项目经验也不同,甚至关系到性格不同,沟通的方式也不同······ 想到哪就说到哪啦~~ 抛砖引玉~~~偶也是新手,学习中ing~~ 呵呵 :)
|