管理初入门感想

    由于业务发展及部门规划的变动，本人所处的IT部分为A、B两个开发组及一个公共支撑组，本人为A组的组长，现在简单写下近期的一段心得。

    简单说下，小组内的成员分配：一个初级前端+一个高级全栈+一个实习开发+一个初级JAVA开发以及本人，其中的测试及设计是属于公共支撑的，

    由于之前也有带过开发小团队，且带的也是培训出来的，首先本人并不是对培训的有任何歧视的行为，而是在我接触的好几个培训刚出来的同事或者前同事中，给我的感觉确实是动手能力和理解能力还是稍微欠缺的，也导致在分配任何时，必须先详细讲需求，再讲设计方案，再讲如何开发，之后在他们开发过程中，也要时不时得看下他们的代码实现怎样，是否规范，逻辑是否合理，总之是各种心力憔悴。

    举个例子，有个实例，刚开始有个项目是某个同事负责带领小团队开发的，但是由于进度比较慢，上面的觉得将我调过去掌控和梳理进度，在我介入的过程中，首先是先梳理下这个项目的原始需求，撸了几遍并且确定了几遍需求，并且梳理了目前的开发进度，实现功能，并且安排开发人员的内部会，重新排期，但是由于这时候我只是在需求上介入并且帮忙开发某些功能，并未涉及到去对他们代码实现的review,所以第一次排期出现了延期，此后，在我决定要去过下他们代码时，暴露了一个严重的问题：某个端的设计逻辑需要大改动，而且是在项目收尾期，才暴露出来的，也是在我介入代码时才暴露出来的，当即，召集开发内部会，先对目前的问题梳理，已经解决方案的讨论，之后反思和总结，而后就需要花成本去做改动，通过这次，个人总结出以下几点：

1. 接到需求后，需要完全了解需求后再设计

2. 写代码前，要先认真的了解需求，确定百分百了解需求后再开发，而不要按自己想当然的去做，这样可以减少后期返工成本

3. 团队开发人员需要多沟通，减少一些代码的重复

4. 开发人员需要多主动，主动汇报当前的进度，这样利于负责人对于项目的掌控进度

    同时，我也自己的要求时，拿到需求后，先自己过一遍，在开内部需求会，进行需求的讲解、分解和分配，同时也会讲下自己的实现方案供参考，本人一直坚持生活和工作是分开的原则，觉得工作时间内提高效率，把工作做好做完，之后可以利用下班时间，进行自我提升也好，休息也好，因为休息也是为了更好的工作，而不是为了加班而加班，加那些无谓的班。