在小公司编程是一种什么样的体验？

标签：需求同学编程什么样发布开发文档体验公司

前言

知乎上有一个提问：在小公司编程是一种什么样的体验？

↓↓↓

今天，我们就这个话题，一起来做个讨论。

这里有没有曾经待过小公司或者现在正窝在小公司的程序员？如果有，这个问题相信你是最有发言权的。

一个软件产品从前期的调研到中途的开发直至最后的发布环节，不知道整个链路跟踪下来，你是否感觉这中间的每一步步骤你们都做的足够规范？哪些环节是你忍不住想吐槽的？欢迎大家在评论区，展开讨论。

我自己曾经经历过人数在0-50的小公司多年，后面也经历过人数超过10000的大公司，结合我自己的背景，来尝试着回答一下这个问题。

我觉得在小公司编程，最大的优势当然是灵活了，你要做一件事情，不用受太多条条框框的束缚，想干就干。开发同学的技术选型，也基本都是开发同学自己说了算，比较自由。

但缺点也比较明显：没有统一规范作为制约与指引，每个人基本都是按照自己的喜好来做事，本着怎么方便怎么来的原则。所以容易出现信息不对称、沟通效率低下，最终也及其容易引发诸多安全事故，给公司造成不可估量的经济损失。

这里所谓的“规范”一词，我认为一般涉及如下三个阶段：需求阶段、设计阶段、发布阶段。

接下来，让我们一一来拆解一下。

正常来说，产品经理在调研完相关需求后，经过自己的整理，最终会形成一份完备的需求文档。然后他会组织相关人等(开发、测试等)进行第一轮的需求评审会议，目的也是想和大家对其一下本次需求的内容事项。

如果需求内容本身比较简单、清晰明了，一般一轮会议就能敲定。开发理解了需求后，就可以进入下一个阶段，比如详细设计。(遇到比较复杂的业务需求，可能需要经历多轮讨论，经过多次修订后，这个需求的内容才能真正确定下来)。

注意，上述一切都是在比较规范的前提下展开的。但往往很多小公司，是做不到按部就班按这个流程来走的。

有些小公司或许也有产品经理一岗，有的产品经理，前期也会简单的整一份需求文档。在文档中，简单的用纯文字描述一下，本次待开发的需求内容。至于拉会评审这一环节，是没有的，他会选择直接把整理好的文档，丢给开发同学，然后附言一句：如果有问题，可以随时找他沟通。

开发同学，拿到文档，在还没看之前，其实是很懵逼的，完全不清楚要干什么，里面有多少内容。怀揣着忐忑的心情，只能硬着头皮打开文档。(我们固然希望里面的内容越少越好，至少看下来，不要让我们有猜测的成本)

事实证明还是我们一厢情愿了，那一段一段密密麻麻的文案，看的真心想吐，很多时候真的要多看几遍，才能明白，文案想表达的意思。

整个文档，肯定会有几处地方，是不得电话或当面沟通，才能明白它的意图的。

如果你说这很糟糕啊，那我想跟你说的是，还有比这更甚的。有些需求压根你就看不到文档。产品同学就直接在聊天工具里面，密密麻麻、啰啰嗦嗦的把他想要的需求内容，输出给你，当然最后也会附上那句熟悉的话：如果有不明白的地方，随时可以找他沟通，24小时在线。

还有就是关于需求的迭代或功能变动(最可怕的是，完全推翻重做)，小公司基本都是某些人一两句话的事情，然后就要开发评估工作量，并要求用最快速度上线。

在座的各位，不知道有没有在编码之前，有做详细设计的习惯。大公司一般团队内部都有规范，在编码之前，要求先撰写详细设计文档，等你写完后，需要组织相关人等，进行设计评审。评审过后，你才能进入编码工作。

当然我相信，很多小公司，其实压根就不存在这个环节。等整理完要开发的需求内容之后，一般直接就开始撸代码了，如果真的遇到问题，他们会停下脚步，做一番思考，实在搞不定，再找人寻求帮助。

这里有什么问题？大家不妨先思考一下。我觉得对于一些简单的功能需求(工作量在3天以内的)，直接撸代码，也没多大问题。为什么？因为这本身就说明，此次待开发的需求事项，内容比较清楚、明确，产品本身确实只需要用一两句话，就能描述清楚，开发同学，看了需求后，也胸有成竹，知道自己具体要干什么。

但，对于复杂的需求，比如工作量在1周甚至两周以上的那种，不写详细设计文档，我认为可能会是个灾难。因为直接编码，那么注定前期你根本没时间经过深思熟虑的思考，很多细节难免会有遗漏，没考虑进去的情况。一些方案选型，在没有充分调研、预演的情况下，说用就用，后期做着做着又发现满足不了，只能返工，推到重来。

而所有的这一切，如果前期，你都能在文档中体现出来，然后在评审会议上一一与大家做介绍。那我相信，一些问题，一定能提前曝光出来，然后团队内部，就可以提前做一番讨论，最终，把相关方案给敲定下来，这样后期的开发，就会顺利很多，不会出现时不时卡顿、返工的情况。

开发同学完成代码编写后，就进入了提测阶段。等测试同学按照他们的用例测试、验证完后，最后项目就进入了发布阶段。

大公司一般对于发布这件事会比较谨慎，比如会有同学，需要撰写相应的发布计划：上面需要详细罗列清楚此次发布的内容；发布的注意事项；同时也要做好回滚计划，万一新功能上线，影响了原有的功能，那需要立即代码回滚。

发布也需要提交相关申请单，等相关审批人员审批通过后，然后在具体时间段，正式进行发布。(根据自己公司的业务情况，避免在高峰期发布，影响业务稳定性)

但一些小公司，这一块就比较随便了，发布是随时随地、一句话的事情。而且开发同学一般都有较大的自主权。

他们可谓超级管理员的存在，数据库表结构可以自己随意新增、修改；线上数据也可以自己随意订正；想要发布，一个命令的事情，也完全不管什么业务高峰、低峰期，想发就发。

有时候，还蹭别人不注意，偷偷的发，当不经意发现自己写的某个线上bug，做到神不知鬼不觉。

~END

本文内容摘自作者原创公众号：「陶朱公Boy」一文，欢迎关注与转载，转载请保留出处。

标签：需求,同学,编程,什么样,发布,开发,文档,体验,公司
From： https://www.cnblogs.com/StarbucksBoy/p/17729628.html