给老大的项目的思考和建议

从我视角看来,最近的项目,存在些问题,感觉效率很低下:

---

CMCC:

• 问题一: 刚开始,温设计就做,从网上找模板,发现最后iphone不匹配,基本耗时一天去改适配;

• 问题二: 刚开始做的时候,不是单页的,后来改结构,耗时一下午;

• 方 法: 她实际是入门前端,偏重设计,但是结构上很有问题.所以,项目开始,我觉得涉及项目的人,应该简短的开个会,不需长,30分钟,你给我们说明项目大概什么需求,然后我们该做什么,然后,我们就可以就问题而讨论,交流下如何合作,合作中遇到的问题如何解决,然后,我觉得项目的构架,应该我给他们做个架构,然后他们再写,这种磨刀不误砍柴功,就不会出现按照pc端去写而不适配的问题,而且,这种他们也才能进步

• 成 本: 问题中出现的情况耗时一天;但是开会,构架,至多只需要2h

• 问题三: 关于代码,温的结构实际很不良,合作时候,我要重耗费时间去改良结构,万才代码结构也有一定不良,代码传来传去,乱的很;

• 方 法: 觉得项目前,或者抽空开个会,讲一下代码规范的问题很有必要,规范一下编辑器,我觉得sublime很适合,前端,php,js完全很足够

• 成 本: 开个会落实,规范,2h,不然是长时间持续的问题

• 问题四: 项目缓急度:像昨天折线的地图这种,我觉得不应该改,因为功能可用,不难看,因为过度的注重界面,而延缓项目整体成型的进度,实际昨天那个折线图,只是我们主观的想法觉得不好看,毕竟看起来也很有层次,这种东西应该最后在优化,毕竟不是功能问题,是个性化的问题.这么来影响了整体的进度

• 方 法: 这种客户没有明确需求的就是快速原型法,先整个流程完备了,在慢慢维护,这种也是最把稳,没有风险的,不至于某个流程过缓或者过于急迫,可以保证质量
  和功能,而且就算改了,我们觉得好看了,给客户,他们也不一定会不改.毕竟这种时候不是功能的问题了,可以先放一下,而是个性化的问题,我们开发时候应该先保证功能.问题全部完善了,在思考个性化的问题,这个问题做楚雄青年网时候我觉得就存在

• 问题五: 像投票的展示,今天我看了下,我觉得不该用echart,它上面字很小,动态效果不佳,引入的库又多,个性化可维护性极不好

• 方 法: 可以改成一张楚雄州图片,在上面做点一样的,简单的js也可实现统计图,然后用js交互做酷炫的动画,同时,开始我觉得做之前就应该得到讨论

---

花芊溪:

• 问题一: 帮曹部署小程序,是1月24,到今天是2月3日,很长时间了,这个是亏本的流程了,我自己预计是4天搞定界面的,之后可以写逻辑,曹的代码是生成的,就小程序首页而言,花芊溪之前我尝试写过一个,很完备,代码很清晰,费时2h,他做一个首页生成代码再去改,之后在去完善代码,需要时间半天多,而且每次都要修改都要重新生成,生成后重新修改,看起来方便,实则很慢,而且生成的很乱.交给他做没得问题,问题在没有限制好做的方式,需要构架,不然野蛮生长,那么就不专业了,他成长也不大.如果是让他自己写,时间上来说,最坏也差不多,但是代码结构清晰,便于合作,他自己成长也很大
• 方 法: 开会,交流彼此认知内的问题,制定方法,研究开发流程和方法,像这次,我写好个页面构架,让他在其中拓展就很好,很清晰.毕竟很多时候郭总你安排下去,你站在高处,细节,局部的地方你是看不到的,需要开研究会,交流,研讨,才能做出更好的把控和安排.因为细节是由我们执行,工作是郭总单方面的安排,细节处可能你是盲区的,这样就会有问题,所以,每个项目前,召集项目成员就项目开会讨论问题,思路,是非常合算的一件事情,而且我觉的每天可以开个早会,简短说说昨日的问题,然后,出现问题及时纠正,也不错的.

虽说是快速迭代,但是有的过程我觉得还是应该重视,有时候越想快,越快不了