工作总结2019-10

Posted 2020-12-01 gds-1202b

国庆假期后的第一周：

总体回想起来，没有什么值得念叨的。唯一可以记录下的估计也就是周五看到的新项目的流程问题。

那是一个小程序项目，原型是一个业务上的非技术人员画的，很是难看且漏洞和逻辑上错误不少。可笑的是，领导在给我们开发人员讲完新项目情况或者说需求的时候，效果图已经快设计完了？所以说我们在听完需求，开始了解已有原型和效果图的时候，是有多么的不爽和气愤，对流程错误的不爽，对白费设计人员工作成果的不爽，因为效果图再好，也肯定是基于原型来画的，原型就漏洞百出，效果图再好也得重做。

另外还得再说一次，原型出来后，必须由后端人员审查确定、前端人员确定、领导审阅、客户审阅通过后，再交给界面设计人员进行效果图设计，效果图出来后直接给客户确定就好了，客户说OK后，API、后台管理、前端的就可以开始了，其中后台管理可以更早的开始。

第二周：
总体来说，这周就干了一件正事，那就是按照自己的理解画了个项目原型，虽然不一定采用但起码能进行多人沟通的起点，以及反映出一些问题，以便后续进行改进优化。大伙一起明确需求只是口头或者脑袋里交换意见达成一致，但太抽象，将这些抽象反映到实实在在的原型上，这样大家就能更清晰的认识到需求到底是啥样，或者跟自己想象的有什么不一样的地方，或者发现自己或者别人有漏洞的地方。进而促进团队之间达成更进一步的统一。
另外这周还和一个运营的同事交流一个之前项目后台系统的优化问题，感触颇深。他根据自己的使用感受想要技术人员新增一个功能，但是这个功能他说的又很笼统，大致一听会觉得实现不了，因为他没有让我想象或者感知到他想要的是个什么东西。这就好比一个人想要自己的画师好友帮忙画一个水怪，因为她喜欢，但是画师又没见过听闻过水怪，所以很无语，但为了稳住对方，只能往尽量引导他尽量描述自己想要的东西的细节并反复询问确认，这个过程可能不太愉快，但要有耐心，不管能不能画，起码要了解他想要的是个啥，这是对对方的尊重。
经过这件事，感觉自己挺有耐心的，渐渐有了个心态：即尊重程序使用者的任何意见和感受，起码要耐心听完他们讲完，不打断、不批评。

第三周：

这周主要是自己搞一个公众号网页的相关工作， 从数据库设计到页面接口的编写，以及后面的静态页面的事件绑定和测试。虽然只有三个页面，但还是有用到很多东西的。这个过程中，感觉自己做的最有价值的部分，是对一些微信生态常用的方法的封装，这个感觉以后复用的情况会很多，所以在写这些方法时很有成就感。

第四周：

这周在公司的工作情况，总体来看，没有什么有价值的地方，一直把时间放在无效的沟通上面，我自己来看，真正工作的顶多也就三天，一天是对上一项目的收尾（测试优化），一天是设计数据库，一天是写部分接口。那么问题很明显了，在无效沟通上面花的时间的确太多了，造成这个情况的原因，我进行了以下思考：

1、公司的人员构成或项目涉及人员，以及其目前的日常工作：

懂点技术、对项目有自己想法、有最高决定权的老板；

和客户沟通、老板沟通、项目经理沟通，不懂技术的产品新手；

和老板沟通、产品沟通、手下技术人员沟通的项目经理新手；

主要和项目经理沟通，并对应用的数据库数据、API、后台系统、前端页面交互提供支持的后端基层开发人员；

和产品沟通、项目经理沟通、前端人员沟通的界面设计人员；

和界面设计沟通、项目经理沟通、偶尔和后端基层人员的沟通；

=》以上就是当前所在公司的各职位人员的工作现状，现在造成的一个问题是：后端基层开发人员每周有甚至两天的时间花在无效沟通或做无用功的情况，（还有由于需求不定导致界面设计人员做大量无用功的情况）

那么造成这个问题点在哪？我思考后有了以下认识或者说观点：

1、产品当前是生涯初期，对一些界面设计、交互设计的经验有待提高，从进入系统到退出再到二次进来的流程逻辑把控不到位也可以理解，毕竟专业性有待提高，不提用户体验，基本需求或功能逻辑能走通就行。

2、如果基层技术人员对项目原型没有决定权，那么请不要让基层技术接触这个方面，即基层技术可以完全不操心产品相关的事比如原型设计。原型确定后，让项目经理通知到即可。

3、项目原型就是对系统或应用的一个约束或者说它是应用的框架，限定了应用能做什么、不做什么，显示什么、不显示什么，具体某一功能上的交互逻辑或顺序；而且他是多人共同探讨的基础，有了他会发现沟通更方便，而不是“思想上的交流”。而界面设计，就是在这个原型框架的基础上打造用户视觉体验，如背景色，按钮大小形状，文字大小颜色等，即在“显示什么，不显示什么”的限制内发功发热。

4、如果基层开发人员对项目原型没有决定权，不是自己画原型，那么基层开发人员应该不用在项目原型确定过程中参与过多，甚至需求原型第一次确定后由项目经理告知一下结果就行。得知结果并用心了解一遍后，提出不理解或者逻辑（数据层面）待完善、走不通的地方统一反馈给项目经理，而后开始后端工作（数据库、接口、后台、技术实现整理等），如果原型不能导致后端工作开展，那产品和项目经理之前的沟通需要质疑。

项目经理就是基层人员的代言人，也对应用的原型确定、项目开发周期、迭代计划，人员分工等方面起到“指挥官”作用。项目经理的存在就是减少基层开发人员和项目决策者（产品和老板和客户）之间的沟通成本，把控项目进度。

产品经理（可能是客户和我方沟通的唯一入口），应该尽快整理需求文档，并给项目经理，让项目经理有个大致预期或了解，同时自己开始对项目即应用的框架层设计，即弄出项目原型1.0。这个过程应尽量少的和项目经理沟通（这是发挥自己才华，所知所学的阶段，完全是产品人的战场，不用考虑后端怎么实现，可不可以实现），完成后先直接和项目经理沟通，项目经理提出意见或通过，产品根据项目经理意见作出原型迭代，直至项目经理通过。然后产品把原型通知下老板和客户，项目经理给老板和产品该项目的任务大致周期预算，同时项目经理整理底层人员可能需要了解的技术点，并通知他们先了解相关技术，或者说直接基于原型开始部分开发工作。

老板对项目根据产品提供的需求文档、原型，或者项目经理提供的工作预期，技术点进行自己的评估，如果对原型有意见、技术实现有意见，直接前者联系产品后者联系项目经理。

》如果基层技术人员对项目原型没有决定权，那么重点是：隔离、下一阶段工作开始时，必须上一阶段工作结束。这样减少无效或者低效率沟通。