心酸研发路 - 杨志平
- 大版本发布周期过长（原因：团队专业有限，探索前进，频繁修改），导致没有什么机会思考、设计，人也拖的身心疲惫
- 引入架构思想，软件质量提高。后期频繁加入改动，冲淡架构
- 老板干涉过多 导致：压力过大 质量无法保证
- 老板高度重视UI
研发路上的那些事儿 - 张超耀
- 没有专业的移动端团队人员
- 产品研发没有系统流程，走一步算一步
- 需求人人可以改
- 忙的时候忙的要死，闲的时候闲的蛋疼
研发之路上的坑 - 潘君
盲目相信自己,不合理的压缩周期
在开发周期过程中,过分相信努力的作用,以为团队只要努努力,可以爆发一个超越平时的战斗力.
在预估周期的过程中,过分考虑老板的感受,不合理的压缩周期,不断的向需求妥协,导致后期死的非常难看.
一方面自己的预估承诺没有兑现.另一方面团队本身也精疲力尽.
好事多磨,鸡血不能多打
一个好的项目不是短期可以做出来的,是必须慢慢打磨,而过分相信一个突击开发周期能够做出一个好产品是过于乐观的.
好事多磨,好的东西需要一个相对合理的周期.这个周期可能比较长,所以在较长的一段时间内要做的是保证团队的舒适度,而不是一味的打鸡血鼓励.
鸡血是一种需要正向循环的方式.如果没有一个好的反馈,鸡血的功效性就会越来越弱,最后反而会有逆效果.
高层强插改需求 - 吴明
- 背景
- 原公司移动开发中，在一项目层层过滤确定产品后，开发人员并已经开发了一段时间后，公司老板或者其他高层介入修改需求，延长开发时间。
- 缺点：
- 开发时间浪费，花费时间做无用功
- 高层施压不利于下层产品开发，及产品迭代
- 项目延期打击开发团队人员士气和积极性
- 项目接近上线更改需求，严重影响开发人员心情，及代码编写质量
- 后期流程改进
- 从项目入口抓起：所有指定项目必须经该项目需求方，产品，开发等直接最高领导确定，并且不更改需求下，开发人员才开发项目。
- 项目分阶段给高层领导汇报，把控项目质量。
- 高层需要项目后期改需求，只能下个版本迭代，本项目不予以改需求。
参与创业的辛酸史 - 郁兵生
- 初创团队，没日没夜加班搞项目
- 初创团队，不了解情况，项目周期把握不清。赶时间攒代码。
大众【设计占整个研发的重头】- 顾鹏凌
- 完善的管理体
- 细控的研发流程
- 设计阶段作为重头，精雕细琢，避免后期遇到问题需要大改动
杂乱的管理 - 吴强
- 初创团队，相关人员不完备
- 产品经理只做了原型的工作，没有把控住需求的变更
- 一人多职，多项目参与
- 空降产品经理，做事一意孤行，跟团队不和
51offer的原始状态 - 庄丰洲
- 没有移动端团队人员和移动端研发规范流程
- 是个人都可以提需求
工作感悟－李仙鹏
团队结构：
崇尚扁平化的互联网公司，员工之间没有非常明县的上下级关系。
需求把控：
需求不明确、中途变更、压榨开发都TMD是耍流氓
一个好的项目需求，应该在kick off前全面规划产品，产品和设计明确需求并且画押签字，中途不得变更。当临时提出需求变更时，技术应该敢于把画押字据拿出来并且提出拒绝——把变更需求留在下一版本迭代。
不应该为了迎合进度而倒推时间压榨开发，这样做出来的东西很可能会是漏洞百出的
Better 的一路走来 - 王胜
第一个版本历时4个月的天天加班
- 评估开发时间时，仅有原型；设计稿一出，开发人员瞬间觉得工作量要直线上升。
- 按照一个有经验的工程师估出时间，然后上面说再调一个人，时间周期按照除以2来算。掉入《人月计划》中所说的坑。
- 新组建的团队，缺少默契，需要磨合。【包括客户端之间，客户端与API之间，客户端与UI之间】
- 临近上线，上面对体验要求无止境，导致细节调整没完没了
一起努力，挺过4个月
- 打过鸡血
- 慢慢地团队之间有了默契
- 制定上线体验阀值，不能无止境提出体验调整的需求
后续版本的研发
- 严格按照Scrum流程迭代开发版本，目前2周一迭代
- Sprint确定需求后，不能强制加入新的需求
- 特例的需求要插入Sprint，那么就顺延Sprint的周期
工作经历的一些片段 - 曾铭
文化
- （敏感信息）略
好的
- 工程师主导的开发流程：产品做调研，提目标，开发参与设计 feature 包揽实现、测试、验证
- 牛人不少：一流的人招一流的人，二流的人招三流的人
- 优秀工具的使用 （工具绝非一蹴而就， svn -> git，）
- 对代码的极致追求 （代码行数、朝歌->镐京、Hackathon：一夜实现客户端聊天）
- 相对优秀的办公环境 （畅通的网络等）
不好的
- 目标不明确 (对商家态度的摇摆)
- 不接地气（商业化不成功）
- 理想主义者的碰撞, 无妥协
- 急躁（寻求改变的高期望）
- 压力大