每日工作报告的遗憾

手边的一个项目将要发布一个alpha版本，所以去检查程序的状况.
之前根据之前客户的回馈，我已经将报告的错误交给手下的一个程序员去修正了.
公司有每日工作报告，我一般都是每天看一下报告，大致了解情况就可以，这是一个十分便捷的方法.
然而我似乎太高估了我的手下，虽然这段时间他的报告基本都很详细并且今天说解决这个问题明天说解决另一个问题，于是我还是很看好进度的.
测试了一下新的版本，结果大失所望，很多错误依然未能修正，只修正很少部分的错误.他的解释总是这里有问题那里有问题，所以某些错误只解决特殊情况下的状况，某些干脆说之前没有看仔细所以要拖迟，但所有的这些在报告上都未能反映. 说实话，听完这些我真的很想狠狠地骂他一顿.

每日工作报告的原意是用来让管理者了解下属的工作状况，一则可以降低管理成本，二则对于管理者可以更有效的管理更多的人.
然而从这件事情来说，这个程序员并没有认真地反映状况，而我也没有及时去确认报告的正确性，最终在一段时间后去确认的时候已经发现问题变得很严重了.
如果说每日我都要去核实的话，那么这个报告的作用就变很小了，不如我一个个问过来后自己写个记录备案.
我想可能更多的问题还是出在其他的管理手段的欠缺，因为目前公司没有详细的考核，所以报告的真伪对个人没有太大影响. 单独的这种报告只能是流于形式，如果说有多少实效，那么完全要看写报告的人的人品了.同样对于另几个比较认真的下属，他们的报告都是很属实.

不知道你在这个项目中是什么角色, 如果是项目经理, 出现这种情况， 似乎自己也有不可推卸的责任

想要凭借简单的项目管理方法就搞定一切，未免想得太简单了。
看看《人月神话》，“掀开地毯看看地板是否肮脏”，需要看看代码的质量，手下的做事方式，品行，长期观察他们是否做事有准、稳健，听取报告只是一个方面，双管齐下，比较准确些。

这需要你对项目组的人比较熟悉，才能决定你在多大程度上放手。

新组建的团队，或者有很多刚毕业的成员，都是需要你去培训做事方式的。成熟而健康的团队，就不需要你更多的关注，只要做好外围的、必要的支持就可以了。

这些我都是做到的，对于这个手下，我还是很关照的，因为招进来时能力还不错，但后来发现其实问题很多，为此不知道找他谈了多少次，指出他的不足和优点，希望他能够更好的发展，可惜每次在保证后都依然保持着光荣传统

有种状况叫做无奈
虽然是一个项目经理，但是在选人上几乎没有权力
而且对方又是个熟手（只能说工作时间长），管教往往不起作用，而制度的欠缺是我也无法拿出些有效的方法

问题可能出在这上面
找个人(不行就自己来)
与他一起干活
但是多监督一下(如果是自己咬咬牙...)
工作效率会比他高....
之后你再作工作就好作了
如果是熟手就要作出个熟手的样子
不光技术,心态,职业精神也都要像个熟手的样子.....

报告只是一个手段而已，只是告诉你他做了什么，并不能告诉你做的怎么样，这个报告再怎么写，也无法完全描述他做倒一个什么程度。

所以，往往还需要监督和检查才能保证项目的进度，一味只看报告是不行的。

其实，遇到这种情况，建议先从自身找问题，为什么他会这样做，是不是我某些地方没有考虑周到或者做的不好，你站的是管理者的角度，他出在执行者的角度，有时候还需要互换一下角度，如果我在他的角度是个什么情况。


PS：建议不要把你的团队成员当成手下看，他是你的团队中一员，不是什么手下，大家仅仅分工不同而已，要是一味的认为自己在上，别人在下，管理和沟通都是很麻烦的。

百样米，养千样人。你这些方法是君子方法，遇到些非君子的人员，就完全行不通了。要管理上要有错必究，如果搞出事情来了，还是一样和没事一样。稍微滑头的人就会知道接下来应该怎么做了。

而且也并非是立场的问题。在项目团队中那里来的立场问题，都是为了把项目做好做完为第一要务。只要有人妨碍了这个目标，就是错，就是需要改正。公司请你来不是为了和你玩君子游戏的。

项目管理的内容涉及很多东西，如果很多科目不匹配，那么可能一个管理方法再好也不能发挥其作用.
人的变数太大，晓之以理动之以情对某些人是不起作用的，特别是一些有很多工作经历并且表现的比较自我的人.
我是比较崇尚制度管理的，在我看来，工作不是结交朋友，无制度无以推动项目的执行，在制度的框架下在加上人情那么才是最好的管理.
当然实事总不会如人愿吧...