时间真快, 一眨眼又到秋天了。 随着comunion的深入, 经常觉得有种无所适从的感觉, 感觉comunion 哪哪都有问题, 但是在没有更好的实践方案前, 现阶段这种模式又是最好的一种解决方案。
v4 相比较与v3, 表象的进步, 一度让我觉得很心虚:
- 是否是功能需求的简单 和工作量相对的少一些,
- 任务滚动的模式的助力
引用paul 哥的总结中: "网链组织架构下期望每个人自发做好自己的任务并且互相协同高效,这是非常难又不现实的", 前三个迭代中, 确实是血的教训, 我们都希望期待与每个人都能是一个完美的个体能达成高效的协同, 导致v1和v2的错觉-"我们的组织协调很不错", 可是一旦遇到V3这样的硬茬子, 整个团队的冲击力就不断拉跨。
在V1-3 的教训后, 从V4 不断开始强调组织内的建设, 从委员会的角度,去帮助开发者去更好的在团队完成协同。 这个转变过后, V4 才进入了稳定期。 但是问题还是存在:
开发者对整个需求的理解还是有偏差;
基本任务单元的拆分还是有些模糊;
引用前尘的一段:“组织成员天生是消极被动的工具”,所以组织成员的加入不是请神,不能依赖于一个人能解决所有问题, 也不能期待开发者自身能与我们协同, 而是由委员会帮助开发者来与comunion达成协同。委员会成员和mentor的主动性成了我们能否帮助开发者更好的融入comunion最关键的品质, 同时也是委员会考察委员很关键的因素。
掌握的技能决定了工作结果的下限, 而沟通能力决定了工作能力的上限。 信息同步是我们能保证任务滚动最关键的因素, v4 的进步,高兴还为时过早, 根本上而言:
任务的相对简单
引入的 任务-时间-人-客观真实记录 模式
短时高频的会议同步信息
我们的模式还需要在后续的任务中验证有效,在遇到V3这类任务的时候还能坚挺如铁, 那时候才能松口气。
从具体的开发任务上看, 前端后端合约都过于依赖与个人。 个人依赖于团队, 才是铁打的营盘, 但是倒置为团队依赖个人,这无疑是个定时炸弹, 从我们的这种模式上看, 有时候值致命的, 而且在我们的过往开发中, 也遇到这种情况。 引用二锅的: “流程push, 多人协调, 时间不一致”,也会造成强大的开发阻力。而这对于我们的委员也有了更高的要求:
- 任务协调管理
- 技术人员解决不了的问题, 能及时解决
- 自我驱动
大浪淘沙, 经过多个迭代沉淀后的委员会, 肯定会成为comunion 最坚实的地基。
由于本次加入了测试环节, 而且全部voice担任主力测试团队, 以前的问题, 都在这次暴露了, 这并不是一件坏事, 测试是保证产品质量的最后一道屏障。 测试团队的建设, 也是我们要重点关注的事情。
产品层面, UI 和交互需要做更多的升级优化,大超的建议很好:
增加交互设计师
好用、好看、好评
用户画像以及体验地图
V4 中最宝贵的积累:
引入的 任务-时间-人-客观真实记录 模式 - 保证任务滚动
短时高频的会议 - 同步信息