项目制作随感

一、核心事情

 

1.责任到人

 

2.可量化工作量

 

二、知已，知彼

 

1.知已：知自己团队的战斗力是多少

 

2.知彼：要做的项目难度是多大

 

三、做之前，要做的事 （分责，量化）

在此时，能把要做的技术活，变为纯粹的体力活，就是本事

 

1.两会

 

需求会 开完会后，回去思考4小时

 

再开前后台对接会

 

两会之后，再估时间

 

2.量化工作量的三大类

 

（1）脑力劳动

 

S A B C 只是工作难度

C 无脑铺板子，交互也只是跳转

B 有一些交互，后台的数据简单处理，与后台数据发生简单交互等

A 有一些复杂的算法，但是网上能找到一些例子，比如电影选座位，处理一些后台的复杂数据

S 复杂算法，且网上找不到什么参考例子，如用原生JS编写个分层气泡图，拓扑图的企业祖谱，用到红黑树，四叉树遍历等，写个智能AI，AlphaGo

关心的点：做的这个功能的人，之前有没有做过类似的，有就可以认为时间和风险可控，没有就认为不可控，需要重点观注一下

 

（2）体力劳动

 

直接灌数据，虽然是体力活，但要是数据多，细节多，肯定也要花不少时间，还要比格外细心

 

（3）对接后台劳动

 

前后台人员的沟通成本，两人联调时，前台传参是否正确，后台数据过来是否正确，发现问题时的修改时间

 

3.估时间的尺子

 

（1）C级：1小时，B级：4小时，A级：8小时，S级：看个人能力了，有可能就无穷个小时了

 

（2）6条变化显示的数据，1小时

 

（3）一个接口，3小时

 

4.要批判的思想

 

我在网上看过，按人/天，来算项目时间的方法，这个算法最大的问题是忽视了每人具体人的工作能力差异

 

如：毛科做一个项目，他需要30个工作日做完，也就是30人天，但不能简单的认为，6个人一起做，就可以在5个工作日完成，要看这5个人的个人能力是不是和毛科一样强，还有人多后的沟通成本也要计算在内，所以肯定5天完不成

 

5.难点

 

（1）不真正做时，没感觉，也不知道哪里会出现问题，俗称“馅”

 

（2）技术经验不足，是新手，或是粗心大意，在写代码过程中一些不是问题的问题，也成了问题，一不留神自己写的代码就是坑，掉进坑里，没几个小时，爬不出来

 

（3）在最开始，前后台，也交流不出来什么，都是摸着石头过河

 

四、三性、三期

 

三性

 

稳定性，流畅性，可配置性

项目，必须是稳定的，BUG少的

再有就是，与用户交互不卡，渲染不慢，是流畅的

编写的代码，关键部分的设置，都是可以通过外部来设置的

 

三期

 

定型期

 

1.打包处理

2.配置的常量

3.从后台得数据，到把数据渲染到前台的套路流程，一般是用建父类的方法

（不是告诉大家，什么能做什么不能做，而是告诉大家只可以做什么）

4.大家共用的常用方法，如：日期格式转换，存取COOKIE等

5.后台接口返回值的结构，约定好一些事情，如：有个状态值，如果后台运行有错时，前台如何显示，在前台基类中统一处理

6.路由，模块的英文名字

7.所有的常量，如数据，文案，都应该在一个常量文件之中,避免在逻辑代码中，有文案直接出现

重在：定套路

 

扩张期

 

根据已经形成的套路，一个页面一个页面的去做

直到都做完，准备提测

重在：按套路狂写代码，遇到问题解决问题

 

 

冲刺期

 

1.bug

2.产品对需求的改变

3.濱习上线过程，模拟上线环境，遇到问题解决问题

重在：沟通每个人得到结论，修改代码

 

五、自己做项目时的感受

 

理想很丰满，现实很骨感

知易行难，落地困难

 

团队优势：每个人的主观能动性都很强

团队加强：整体流程，预做之事的事前沟通，同事之间的配合,尤其是跨部门做事之前的沟通

做项目时：

最大的痛：警惕在项目中，做无用功

小痛：天天平地摔，还有晕头晕脑掉坑里，要好几个小时才能爬出来

提高工作效率就是句虚话，能落地的是把你手里的技术活，变为纯粹的体力活(干的活，都变为死套路时)，就方便量化工作量，并且可以对项目进行掌控了

团队一起开发，人员搭配，最好是一对一，（如：一个前台对接一个后台）或是一对一对一（如： 一个前台对接一个后台，此后台又对接一个数据库人员），都是一条一条的线，最忌，多对多的形式，又乱又容易出错，还要不停切换思维，导致效率很低

领导层的宏观注意力应该放在哪里，一是提升每个员工的战斗力，二是提升整个团队的凝聚力和战斗力，不断优化配比与流程