关于项目管理的一些感悟

最近一个需求来的时候，我为了锻炼新人，将这次开发的工作交给了他。
新人吭哧吭哧写了一个礼拜代码，边写边调试，却总有种在写bug的感觉，我非常不安。
不知道为什么，跟他讲过很多次，写代码之前要尽可能考虑清楚所有的情况，然后再动手写代码。
但是新人总喜欢边调试，边修补。在他提交了代码后，我一眼就能看出其中的bug。
照着我写的测试case进行测试，在他认为已经可以出版本的代码中，他前前后后修了有十几个bug。
当我发愁是继续修补呢，还是给他进行大手术的时候，也反思了下自己需要改进的 地方。

问清楚需求

说实话，这次的需求并不是很明确。虽说这种小系统，没必要每次需求都搞个数据字典，每个数据之间的关系什么的。但是如果这些最基本的要素都缺失，那代码怎么写下去？
最起码基本的大框架逻辑要有。

主要流程心中有数

一个功能，交给新人。他会一步一步摸着黑往前走，然后摔倒了，爬起来，换个方向——他喜欢在黑暗中摸爬滚打。这并非坏事，但是可能这样拼拼凑凑写出来的东西，后面的维护成本，测试代价，都非常之高。而且也降低了他自己 的工作效率。作为leader，我能做的是，首先搞清楚这个功能主要是什么流程，有几个主要的部分。
和团队成员一起讨论，大家集思广益，得出这个流程有哪些基本的部分。大家讨论比自己一个人思考，不管是效率方面还是完善程度，都要好很多。确定框架后，其他的事情会清晰明朗很多。

部署任务尽量细化

将一个大的任务，分成一些小的“零件”，让他先去造这些零件，最后再让他把这些零件组装起来就行了。告诉他每个小零件有什么样的入参，需要完成什么样的功能, 我希望的输出是什么格式等等。至少我把握了大的逻辑没有低级bug。至于他的零件造的好不好用，因为是小零件，发现bug，调试也会相对容易。

好愁，这次的代码review要受苦了。