你的产品开发流程, 断送了你的产品的竞争力与团队的生存发展

2017.3.20, 深圳, Ken Fang

最近和许多朋友们聚聚；有件事, 一直让我很没法理解：

我今年已 52 岁了。 我却发现许多现在 30 多岁的年轻人, 还在用我 30 多岁时候的方法在设计软件, 开发软件。

我所没法理解的是，用我在 30 多岁时候的方法在设计软件, 开发软件, 所会发生的问题, 应该是非常显而易见的⋯ ＠ 认为软件开发就只是写只代码; 其实只是一直在无知的状态下, 进行软件产品的开发。 @ 产生一堆笨重又没法指导开发、测试的设计文档。 @ 笨重的设计文档, 根本就没法与代码匹配。 @ 毫无意义的评审设计文档；最终, 只是一堆所谓的专家, 在评审设计模板写的完不完整。一堆所谓的专家, 其实是没人知道, 软件设计的本质与目的为何？更没人关注, 产品真正所需的架构设计上的决策为何？ @ 折腾了一堆文档, 评审，充其量只是证明自己没做错事；但，就是因为没人做错事, 所以, 开发效率才那么差, 产品质量才那么烂。 @ 市场都已经发生变化了, 团队内部还在跑项目起动流程；以瀑布的思维, 评审团队有没有需求文档？有没有设计文档？

对这些会断送产品竞争力、会断送团队生存发展的问题, 大家为何都视而不见？ 却还自认为自己很专业？

2017 年了, 为何大家还是分不清楚： @ 瀑布 @ 迭代

2017 年了, 为何大家还是不明白： @ 产品开发、敏捷与软件工程间的关系

我们其实真正需要的不是去搞一些表面看起来很专业, 高深的流程、模板、审计。

我们更不应该是在无知的状态下, 开发软件产品。

产品级敏捷、微服务产品级敏捷, 结合了敏捷与软件工程, 提供了: **@ 对团队在产品有价值、可先行开发的业务场景识别 @ 软件架构持续设计 @ 软件架构风险管理 @ Story 的设计与开发代码的无缝结合 @ Story 开发完成的定义 @ Story 的开发每日风险管理**

产品级敏捷、微服务产品级敏捷经由可视化、轻量级的工程实践, 使得团队各不同角色的成员, 可共同的协作, 高效, 简单却不简化的完成上述与产品开发至关重要的工作 (活动)。

我们其实真正需要的只是：简单却不简化, 实实在在的在做 “产品” 罢了。