产品、研发团队，需求变更、交付延迟、研发质量、研发效率这些使我们日常评估和考量团队时，经常会提到的几个点，但这几方面是结论和结果，真正优化和解决问题是在过程。
今天团队进行了一次迭代总结会，自己也挺有收获的，因为有几个比较意外的点：
- 报喜不报忧，多任务并行，时间从评估角度已经不够了，但不会主动向上沟通，希望能够东西兼顾。 这种问题在参与同事越多的功能开发中越明显，一个人的delay或者被依赖，导致一条线没有办法完成。 参与的同事越多，出问题的点可能就越多，n*m的等待时间就被大大拉长。
2.Leader的任性，经常晨会后leader把相关同事拉走讨论问题，研发成员之间约定 的milestone(例如联调、配置、部署等）不断被打乱。
3.对事过于温和。前后端团队在对于约定时间、输出质量的容忍度有点过分高了，在迭代会上才听到有时为了联调，仅仅Coding完成就开始联调。这明显是应该自测的阶段，把其他同事拉上一起时间浪费的更严重。 这个问题对于刚参加工作的童鞋时长会有这样的问题，以为自己开发完就基本不会有太多问题，但对于有2年以上经验的人来说，是不是真的是too young，too simple了。
4.做的功能很简单，不需要规范或好的方式来驱动。联调效率低，代码的完善和定位方式有所提高，这种能够内驱的程序员能力，往往因为很多外部的干扰而没有真正去做。仿佛就像我在一个脏的环境，所以我没必要把自己整理的很干净，这种事情在项目中累积的后果超级严重。举个我们的列子，我们的前后端接口把错误码给舍弃了，只有0和-1，也就是成功和失败...
5.产品和技术底层架构的模型和世界观（国际化产品，维度多了很多，又不是简单的分割，有空再聊），前期的简单分割，到不断的特殊融合，导致产品和技术的原则不明确。这块需要真的明确清晰的界限，不能随意跟着特例需求不断做特殊的调整。以前看到过一篇饿了么的文章，有个例子很合适，跨地域点餐厅、骑手、送餐是不允许的，从而在设计系统时，餐厅、骑手的固定地域属性，用户选择的区域属性，就很明确。 不适配万分之一的特殊情况，从而让整个产品和系统清晰。 本身不是说这个适配由多难，而是这万分之一的特殊情况，永远会带在你的系统里面，一旦涉及相关需求，就会有一大波问题
本来想写点程序员基础修炼的东西，结果来了一波感受。等下要带娃，先给标题加个（一），后面再接着写吧。
网友评论