程序猿日记--项目风控

背景

天气晴朗，昨晚刚下完雨。大周末的没事干来公司闲逛。恰好遇到了大神与小星星在聊最近的项目，于是就跑进去一起掰扯了一下。
就随感写了一下自己的感触，可能逻辑有点混乱，废话有点多。

内容

这次主要聊的风控有两点

人员
需求

人员

项目是离不开小伙伴的，有时候项目负责人真的像一个保姆一样；得时时刻刻关注着小伙伴；对于小伙伴我们来掰扯掰扯。

小星星的这个项目有一半的小伙伴是从别的team拉过来之前没有一起合作过的，这就出现了一些问题：熟悉度不够哇、做事风格不一样呀。这人吧，一旦不熟悉防备心理就比较重，所以给后续开发带来了不小的阻碍。
如果发生在我身上我不知道会不会比小星星做的好？稍微的想了一下。

在确定人员的时候召集这群小伙伴开一到两次茶话会：在公司找个小黑屋，上好的龙井泡上、买两包瓜子、买点薯片，（像这种第一次合作的甚至可以一起撸个串串嘛）这时候什么都不谈，就聊情怀，只聊人生，以至大家都比较熟悉了。
在项目进入需求分析之前再聊一波。聊大家的习惯：梳理原型的习惯、需求分析的习惯、代码编写的习惯、编写代码时身体的习惯。
如果大家习惯不同，项目负责人就需要进行调和了；如果项目有硬性要求，大家都向这个要求靠拢；如果没有硬性要求，就得整个大家都能接受的方案（一般就是折中嘛）

在开发过程中呢也得时时关注小伙伴的状态。大致提现在三个方面：通过看脸色、通过看每日工作计划、通过看项目进度
大家都有心情不美丽的时候，效率底下，感觉人生了无乐趣，但是有些话题又不怎么该怎么跟人说，这时候知心老大爷（老大妈）就要就位了。

需求

需求分析和系统设计都是项目中重要的一环，时间大约要占项目周期的三分之一；是指导项目代码编写的基石。

之前我负责的项目中这一块呢其实做的还是比较渣的，导致了做到后面的时候出了问题大家都比较难受。
需求分析的具体步骤在这里就不详说了；主要强调一点：对于每个节点一定要设置一个里程碑，要有具体的时间节点和验证方法。
这时候重点就来了，也是项目负责人重要的提现部分：做好project

做project真的是件费神的事，划分的纬度太广、考虑的因素太多了。
首先要对整个项目了如指掌、对项目的主流程能够刻骨铭心、对team每个小伙伴的能力和他们适合干什么模块能一清二楚。
常规功能我们就不说了，对于一些在不同项目中重要度不一样的模块必须要沟通好（以统计为例），跟产品沟通好这类模块要做成什么样，到达什么程度，粗细粒度不一样 ，工期和做法完全不一样，不能一看是统计功能就立马排版：一个星期？两个星期？NO！！！

project在确定时间节点的时候会牵扯到系统设计的节点，如果里面出现没用过的技术难点，那么就要注意了，预算的时间节点必须要X3， 或者把这个问题直接抛给架构师，因为这牵扯到公司平时技术积累的问题。
project中工作量对应的时间节点评估：按页面数量来算，页面上交互超过三个或者子节点超过三个的，要特别对待。
个人认为一份完美的project应该能看出每个小伙伴每个小时在干什么
一般做完project之后领导是会驳回的，嫌时间周期过长了；这时候如果project做得好的话。我们就可以跟他理论了，因为已经可以精确到小时了...哇哦

这次聊呢还牵扯到一个经典的场景：新旧系统的数据库转数据；这件事情远没有想象中的简单，不仅要对数据库的属性要一一对应上，对新老系统非常了解，要知道每个属性的具体运行场景。

系统

跳出人员和需求，从整个项目来看；有些事情也是非常需要注意的

小伙伴遇到难题，解决时间不宜超过半个小时；如果他自己半个小时还没解决的，赶紧寻求帮助吧...

还有一个就是项目的加班问题
一说到这，我就想起了一位领导界的扛把子--阿拉X；当我们也带着一群小伙伴的时候，难道非得每天过三点一线的生活了？人生已是如此的艰难；我记得当初跟着阿拉X的时候可是过得很潇洒滴。

加班的时间过长是没有任何产出的，还搞得小伙伴们没精神、没基情、没动力。so，项目team内部的团建非常重要。在没有加班费的日子里，比如周一周二加班，周三打死也不能加；周六需要加班的话，周五下班就立马滚。周末组织大家出去happy一番，主流程走通的时候到外面点个菜小小的庆祝一下。

这些基本上就是 team leader要干的事了，做好合理的安排。在保质保量完成的提前下，让小伙伴们代码敲得没有压力，不用担心哪个模块的逻辑梳理不清、哪块业务的代码不会写；让小伙伴在跟着做项目的日子里能够工作、生活、情感都很愉快。

转载于:https://www.cnblogs.com/nikeodong/p/7137123.html