软件过程前奏

社会的巨大变革，历史前进的滚滚源泉，都源自民众的不懈努力，软件亦是攻城狮们最好的归宿。

软件过程，每一步都是见树又见林的艺术，但过程中夹杂着很多动态性变化因素，需求变更、营销策略、资源协调等，磨炼产品经理乃至所有人员的意志，我们如何改善或者如何彻底改变这种格局？

1.需求变化是肯定的，人本身是发散性的、联想性的，需要忍受这种不确定的状态，混沌中制造秩序最重要、也是解决问题的快捷途径。从需求背景&目标着手考虑，警惕柔弱的需求，收集相似的环境，找出问题的杠杆点；另外弱化的需求管控，将会带来毁灭性打击，不是核威慑，而是白蚁一般，慢慢腐蚀着整个产品

需求是产品的源泉，引领产品的有机组织有秩序的前进，过程中常常也会因为各种糖衣炮弹的诱惑，轻轻一转方向舵，便是产品开始坠落痛苦深渊的时候，建议对需求的把控原则是若无必要，“勿增实体"（奥卡姆的剃刀）,可以提前做好市场调查或与客户深度汇谈。对需求的把握好比建造房子，光是搬运泥土是造不出健壮的房子，要不停的夯实基础，内部碰撞，捣腾出一个舒适、健壮的外壁，也就是说想要掌握或者精通一块知识，光是吸收是不行的，需要修炼和锻造。

2.设计是灵魂之躯，贯穿产品的整个存活周期，如何更好的孕育，非常值得探究。作者比较喜欢UNIX的设计原则，比如

1）可移植性高于效率

2）使用纯文本文件存储数据

3）让每一个程序成为过滤器等

细细的品味，会发现好像真是这样，不久，确实是这样，而且这么做了，代码保质期也长了不少。为什么会这样？

早期，软件尚未流行甚至还未出现时，建筑、护理等行业盛行，人们在建造和医疗上积累了大量的实践经验，从精细的手术到宏伟的地标建筑，这过程中涵盖了方方面面的工程、规范，或者早期的德雷福斯模型（德雷福斯模型是一种衡量人们工作方法和能力，反省并提高专业技能的层级模型），这些历史的积累碰撞技术的变革，自然散出今天的火花。

软件设计遵守前人的经验会少走不少弯路，对于越创新的产品，越需要坚硬的功底，当然也需要合适的技巧，比如small，small是好事，越小的东西越简单、越尖锐、越能刺激痛点，无论业务还是技术，哪怕是一个小小的demo，越是专一的demo越能拿到客户的订单；今天的设计更多的考虑微服务、模块化，以便区分职责，把所有的水管接在一起，一处损坏了，水也就全部喷涌了；设计中，对待细节，需要不停收敛，细化出一根针，穿插在内部服务之间，明明白白的写出一个个职责；对待全局，需要不停放大，画出一张宏伟的蓝图，对外承托出共同愿景。

3.设计少不了编码，编码不可小觑，也是个脑力活，有人说编码就是是码农、搬运工，但酣畅淋漓的书写代码和写诗歌一个道理，写出的代码，简单、优雅、高效甚至妇孺皆知，和写出来的代码漏洞一堆、晦涩难懂、一测就挂相比，损失的不仅是项目延期，亦是大家最宝贵的时间；编码中不乏闭门造车的同学，建议放下代码，多走走同事座位间，多看看编程思想书籍，你会发现码农如此美好，高效的作业，带来的不仅是逻辑质朴而健壮的数据，亦是更多的时间、更多的知识。

诸多时候，繁杂的开发项目和需求讨论，让早已疲惫的开发同学苦不堪言，甚至离职，其实

当你对任何事件作出度量的时候，总有这样或那样的度量方法比选择干脆放弃要强（吉尔伯定律）；反过来整理手上的问题，是产品设计问题？还是产品编码问题？亦是技术能力问题？

千万不要当破窗效应的领导者，当一面窗户破损，如果不及时修复，会给他人起到模范效果，以致于最终所有窗户全部破损，同样代码也有保质期效果，如出现bug，不及时修复或寻求替代方法，也会容易给他人造成破窗效应。及时沟通很重要，50%的编码，50%的沟通。

我们一直不缺处理复杂事物的能力或工具，但却很多时候逃脱不了不合逻辑的“竞赛”，舍本逐末的现象比比皆是，是否追求进度代码胡写一通？为了绩效伪造数据？为了症状牺牲关键指标等等？尽一切可能坚持某些关键性标准极为重要，对出现的微弱症状敏感、预知性忧虑也并非坏事，复杂的问题没有绝对的答案，合适的，能解决问题也不失一种有效的方案。