|
己的工作业绩，甚至在写自己的工作汇报时都可做为参考。那其它的规范呢?例会是很有必要的，那例会的议题和例会的周期确定了么?确定的合适么?曾经有个项目是以天为单位的例会，主要内容就是工作汇报，我个人觉得意义不大，因为划分工作任务的最小完成周期也是三天以上，基本上每天的例会都在重复昨天的内容，连说的都一样，浪费大家的时间。但为什么不去考虑改变呢?或者换种方式来进行。
再次，规范是帮助团队的，这个帮助主要是体现在：提高团队沟通有效性、增强团队协作性、规范团队工作行为、规范工作边界，杜绝隐患发生，提前暴露风险等等，但绝对不是增加团队工作量的，增加团队工作复杂度的，搞个工作流程出来要简单有效，划分责任边界，加强沟通，提升效率，不是搞个流程出来把大家搞晕了，如果用几句话都讲不明白的规范制度，不要也罢。
最后，也最为重要，规范推行一定要慎重，可行可不行的就应该放弃，既然规范制定了就一定要执行下去，不能半途而废，这样极不利于后期的工作。即使规范不多，但有效，大家都可以执行就是好的，要知道规范是双刃剑，毕竟是有弊处的。
在此总结了一些常见的内容，因为做了尽可能的拆解，所以彼此没有太多的关联，仅供参考，希望对大家有所帮助。
1)、计划管理：可要可不要需要针对项目的具体情况来具体分析。但不需要计划管理，并不意味着不要计划了，明确这一点。如果采用工具，首推MS Project。
2)、工作日志：必要。无论项目大小都很重要。并且一定要将工作日志的内容与工作任务进行结合，以实现进度跟踪。针对突发性、临时性的任务，也可由工作日志提交，PM汇总从而得到最终的项目进度。如果采用工具，则还是建议使用projectserver来完成。工作日志一定要看，发现其中的问题，很多时候程序员都会通过工作日志来反映问题及风险，认真对待，不要马虎，你马虎，就代表了团队也会马虎的，也不要让你自己的不经意行为打击了团队的积极性。 上一页 [1] [2]
|
