↓↓↓
今天，我们就这个话题，一起来做个讨论。
这里有没有曾经待过小公司或者现在正窝在小公司的程序员？如果有，这个问题相信你是最有发言权的。
一个软件产品从前期的调研到中途的开发直至最后的发布环节，不知道整个链路跟踪下来，你是否感觉这中间的每一步步骤你们都做的足够规范？哪些环节是你忍不住想吐槽的？欢迎大家在评论区，展开讨论。
我觉得在小公司编程，最大的优势当然是灵活了，你要做一件事情，不用受太多条条框框的束缚，想干就干。开发同学的技术选型，也基本都是开发同学自己说了算，比较自由。
但缺点也比较明显：没有统一规范作为制约与指引，每个人基本都是按照自己的喜好来做事，本着怎么方便怎么来的原则。所以容易出现信息不对称、沟通效率低下，最终也及其容易引发诸多安全事故，给公司造成不可估量的经济损失。
这里所谓的“规范”一词，我认为一般涉及如下三个方面：需求阶段、设计阶段、发布阶段。
接下来，让我们一一来拆解一下。
如果需求内容本身比较简单、清晰明了，一般一轮会议就能敲定。开发理解了需求后，就可以进入下一个阶段，比如详细设计。(遇到比较复杂的业务需求，可能需要经历多轮讨论，经过多次修订后，这个需求的内容才能真正确定下来)。
注意，上述一切都是在比较规范的前提下展开的。但往往很多小公司，是做不到按部就班按这个流程来走的。
有些小公司或许也有产品经理一岗，有的产品经理，前期也会简单的整一份需求文档。在文档中，简单的用纯文字描述一下，本次待开发的需求内容。至于拉会评审这一环节，是没有的，他会选择直接把整理好的文档，丢给开发同学，然后附言一句：如果有问题，可以随时找他沟通。
开发同学，拿到文档，在还没看之前，其实是很懵逼的，完全不清楚要干什么，里面有多少内容。怀揣着忐忑的心情，只能硬着头皮打开文档。(我们固然希望里面的内容越少越好，至少看下来，不要让我们有猜测的成本)
事实证明还是我们一厢情愿了，那一段一段密密麻麻的文案，看的真心想吐，很多时候真的要多看几遍，才能明白，文案想表达的意思。
整个文档，肯定会有几处地方，是不得电话或当面沟通，才能明白它的意图的。
如果你说这很糟糕啊，那我想跟你说的是，还有比这更甚的。有些需求压根你就看不到文档。产品同学就直接在聊天工具里面，密密麻麻、啰啰嗦嗦的把他想要的需求内容，输出给你，当然最后也会附上那句熟悉的话：如果有不明白的地方，随时可以找他沟通，24小时在线。
还有就是关于需求的迭代或功能变动(最可怕的是，完全推翻重做)，小公司基本都是某些人一两句话的事情，然后就要开发评估工作量，并要求用最快速度上线。
当然我相信，很多小公司，其实压根就不存在这个环节。等整理完要开发的需求内容之后，一般直接就开始撸代码了，如果真的遇到问题，他们会停下脚步，做一番思考，实在搞不定，再找人寻求帮助。
这里有什么问题？大家不妨先思考一下。我觉得对于一些简单的功能需求(工作量在3天以内的)，直接撸代码，也没多大问题。为什么？因为这本身就说明，此次待开发的需求事项，内容比较清楚、明确，产品本身确实只需要用一两句话，就能描述清楚，开发同学，看了需求后，也胸有成竹，知道自己具体要干什么。
但，对于复杂的需求，比如工作量在1周甚至两周以上的那种，不写详细设计文档，我认为可能会是个灾难。因为直接编码，那么注定前期你根本没时间经过深思熟虑的思考，很多细节难免会有遗漏，没考虑进去的情况。一些方案选型，在没有充分调研、预演的情况下，说用就用，后期做着做着又发现满足不了，只能返工，推到重来。
而所有的这一切，如果前期，你都能在文档中体现出来，然后在评审会议上一一与大家做介绍。那我相信，一些问题，一定能提前曝光出来，然后团队内部，就可以提前做一番讨论，最终，把相关方案给敲定下来，这样后期的开发，就会顺利很多，不会出现时不时卡顿、返工的情况。
大公司一般对于发布这件事会比较谨慎，比如会有同学，需要撰写相应的发布计划：上面需要详细罗列清楚此次发布的内容；发布的注意事项；同时也要做好回滚计划，万一新功能上线，影响了原有的功能，那需要立即代码回滚。
发布也需要提交相关申请单，等相关审批人员审批通过后，然后在具体时间段，正式进行发布。(根据自己公司的业务情况，避免在高峰期发布，影响业务稳定性)
但一些小公司，这一块就比较随便了，发布是随时随地、一句话的事情。而且开发同学一般都有较大的自主权。
他们可谓超级管理员的存在，数据库表结构可以自己随意新增、修改；线上数据也可以自己随意订正；想要发布，一个命令的事情，也完全不管什么业务高峰、低峰期，想发就发。
有时候，还蹭别人不注意，偷偷的发，当不经意发现自己写的某个线上bug，做到神不知鬼不觉。
~END
本文内容摘自公众号：「陶朱公Boy」一文，欢迎关注与转载，转载请保留出处。
