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

发布时间 2023-09-26 10:54:21作者: 公众号_陶朱公Boy

前言

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

↓↓↓

今天,我们就这个话题,一起来做个讨论。
这里有没有曾经待过小公司或者现在正窝在小公司的程序员?如果有,这个问题相信你是最有发言权的。
一个软件产品从前期的调研到中途的开发直至最后的发布环节,不知道整个链路跟踪下来,你是否感觉这中间的每一步步骤你们都做的足够规范?哪些环节是你忍不住想吐槽的?欢迎大家在评论区,展开讨论。

我的回答

我自己曾经经历过人数在0-50的小公司多年,后面也经历过人数超过10000的大公司,结合我自己的背景,来尝试着回答一下这个问题。
我觉得在小公司编程,最大的优势当然是灵活了,你要做一件事情,不用受太多条条框框的束缚,想干就干。开发同学的技术选型,也基本都是开发同学自己说了算,比较自由。
但缺点也比较明显:没有统一规范作为制约与指引,每个人基本都是按照自己的喜好来做事,本着怎么方便怎么来的原则。所以容易出现信息不对称、沟通效率低下,最终也及其容易引发诸多安全事故,给公司造成不可估量的经济损失。
这里所谓的“规范”一词,我认为一般涉及如下三个阶段:需求阶段、设计阶段、发布阶段。
接下来,让我们一一来拆解一下。

 需求阶段

正常来说,产品经理在调研完相关需求后,经过自己的整理,最终会形成一份完备的需求文档。然后他会组织相关人等(开发、测试等)进行第一轮的需求评审会议,目的也是想和大家对其一下本次需求的内容事项。
如果需求内容本身比较简单、清晰明了,一般一轮会议就能敲定。开发理解了需求后,就可以进入下一个阶段,比如详细设计。(遇到比较复杂的业务需求,可能需要经历多轮讨论,经过多次修订后,这个需求的内容才能真正确定下来)。
注意,上述一切都是在比较规范的前提下展开的。但往往很多小公司,是做不到按部就班按这个流程来走的。
有些小公司或许也有产品经理一岗,有的产品经理,前期也会简单的整一份需求文档。在文档中,简单的用纯文字描述一下,本次待开发的需求内容。至于拉会评审这一环节,是没有的,他会选择直接把整理好的文档,丢给开发同学,然后附言一句:如果有问题,可以随时找他沟通。
开发同学,拿到文档,在还没看之前,其实是很懵逼的,完全不清楚要干什么,里面有多少内容。怀揣着忐忑的心情,只能硬着头皮打开文档。(我们固然希望里面的内容越少越好,至少看下来,不要让我们有猜测的成本)
事实证明还是我们一厢情愿了,那一段一段密密麻麻的文案,看的真心想吐,很多时候真的要多看几遍,才能明白,文案想表达的意思。
整个文档,肯定会有几处地方,是不得电话或当面沟通,才能明白它的意图的。
如果你说这很糟糕啊,那我想跟你说的是,还有比这更甚的。有些需求压根你就看不到文档。产品同学就直接在聊天工具里面,密密麻麻、啰啰嗦嗦的把他想要的需求内容,输出给你,当然最后也会附上那句熟悉的话:如果有不明白的地方,随时可以找他沟通,24小时在线。
还有就是关于需求的迭代或功能变动(最可怕的是,完全推翻重做),小公司基本都是某些人一两句话的事情,然后就要开发评估工作量,并要求用最快速度上线。

 编码设计

在座的各位,不知道有没有在编码之前,有做详细设计的习惯。大公司一般团队内部都有规范,在编码之前,要求先撰写详细设计文档,等你写完后,需要组织相关人等,进行设计评审。评审过后,你才能进入编码工作。
当然我相信,很多小公司,其实压根就不存在这个环节。等整理完要开发的需求内容之后,一般直接就开始撸代码了,如果真的遇到问题,他们会停下脚步,做一番思考,实在搞不定,再找人寻求帮助。
这里有什么问题?大家不妨先思考一下。我觉得对于一些简单的功能需求(工作量在3天以内的),直接撸代码,也没多大问题。为什么?因为这本身就说明,此次待开发的需求事项,内容比较清楚、明确,产品本身确实只需要用一两句话,就能描述清楚,开发同学,看了需求后,也胸有成竹,知道自己具体要干什么。
但,对于复杂的需求,比如工作量在1周甚至两周以上的那种,不写详细设计文档,我认为可能会是个灾难。因为直接编码,那么注定前期你根本没时间经过深思熟虑的思考,很多细节难免会有遗漏,没考虑进去的情况。一些方案选型,在没有充分调研、预演的情况下,说用就用,后期做着做着又发现满足不了,只能返工,推到重来。
而所有的这一切,如果前期,你都能在文档中体现出来,然后在评审会议上一一与大家做介绍。那我相信,一些问题,一定能提前曝光出来,然后团队内部,就可以提前做一番讨论,最终,把相关方案给敲定下来,这样后期的开发,就会顺利很多,不会出现时不时卡顿、返工的情况。

 发布阶段

开发同学完成代码编写后,就进入了提测阶段。等测试同学按照他们的用例测试、验证完后,最后项目就进入了发布阶段。
大公司一般对于发布这件事会比较谨慎,比如会有同学,需要撰写相应的发布计划:上面需要详细罗列清楚此次发布的内容;发布的注意事项;同时也要做好回滚计划,万一新功能上线,影响了原有的功能,那需要立即代码回滚。
发布也需要提交相关申请单,等相关审批人员审批通过后,然后在具体时间段,正式进行发布。(根据自己公司的业务情况,避免在高峰期发布,影响业务稳定性)
但一些小公司,这一块就比较随便了,发布是随时随地、一句话的事情。而且开发同学一般都有较大的自主权。
他们可谓超级管理员的存在,数据库表结构可以自己随意新增、修改;线上数据也可以自己随意订正;想要发布,一个命令的事情,也完全不管什么业务高峰、低峰期,想发就发。
有时候,还蹭别人不注意,偷偷的发,当不经意发现自己写的某个线上bug,做到神不知鬼不觉。
~END

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