BAT的真的适合创业团队吗?

本文探讨了创业公司在快速发展过程中面临的技术与管理挑战,特别是项目管理、需求沟通、开发流程等方面的问题,以及如何通过改进管理和采用敏捷开发等方式来应对。

平时在公司扮演一个逗比得角色和亲爱的们友好相处的我根本不愿意去思考这么深入的课题。本来在上一家公司就涉及的太深,心爱的一条小产品线被咔掉后心疼不已。只想深入研究技术不问世事了。怎奈何突然有一天说要招一个项目管理职位的人进来,专门做的事情就是更新和管理项目进度。我当时十分疑惑后,就开始了找个思考的历程。

大公司病?

“难道不是产品经理需要管理这个事儿吗”?小创业公司里,不是产品经理需要把从老板、市场和运营的人的一堆破事儿都收集整理了,然后去其糟粕、留其精华,转化为需求文档和原型交给开发,然后管理开发的进度?但是我们的产品经理怎么要把这件事儿推出去呢?这个哥们过来之后干的事情就是更新EXCEL:谁做了点啥,今天做了点啥,任务进度是百分之多少等等吧。

和赚钱没有直接关系的人变多就是大公司病了。这个哥们和直接赚钱有关系吗?这个时候我们家的真汉子喊人了:“XXX你的bug改得怎么样了?”。说他真汉子是因为他是个“她”。气势逼人,对于真汉子的任何问题我们都不敢说半个不字。

但是有的时候会出现一个很奇怪的问题,很多时候测试并不清楚开发们又开发了什么新的功能。很长一段时间都持续出现这个问题。每次到最后要发布的晚上,测试们以为可以上线了但是又爆出说其实还开发了新的功能需要测试。最后的结果直接就是发布延期。对于测试的不重视直接导致的结果是延期的发布和无数多的质量问题。

其实,最清楚项目的进度的人非测试莫属。我们都知道每次开发的时候测试是要有测试用例的。那么项目进行到什么程度,直接看测试的测试用例测完了多少就可以了。非常清楚。总比你问一个开发说,哎这个某某功能的进度怎么样了啊?然后他说,我想想啊,大概百分之三十了。这几乎就是猜了。

完完全全的瀑布流

前面说到的需求问题。产品们辛辛苦苦的整理各方面的需求,每天都忙到半夜。真让人敬佩。然后等他们的需求都整理好放到文档,做成原型(原型从来没有见过,除了粘到文档里的那几页以外)就正式的交给开发了。

开发完全不了解这个大需求的前因和后果,以及这之间的来龙去脉。这些在开发之前都是需要弄得清清楚楚的,至少是各个功能块之间的关联尤其是数据的流向这方面需要弄清楚的。要完全的搞清楚这些需求所花费的时间也是相当的多的。

产品团队在这之前完全没有从连接开发和运营的角度给予运营和市场等需求提供方给予专业的建议:把需求拆分,并纳入敏捷开发以快速的迭代。相反的,产品团队在整理好全部的需求之后,一股脑的抛给开发。并由开发团队来给需求提供方提出需求的不合理的地方和实现的不可行的地方。之后再次陷入需求的大讨论中。

但是这个时候一个小创业公司的老板早就已经等的不耐烦了。人人都在讲快,老板还在大把大把烧钱,哪有那么多时间等一堆人为了一个小需求点讨论个没完没了的?老板就说这个也不用做,那个也可以手工做。是的,谁都理解他想早点试试这个大的功能点到底是不是适合市场的。但是,产品和开发们谁也不敢跟老板说半个不字。老板要砍掉的几乎都是运营在实际操作的过程中需要的配置项等。砍掉了运营就只能手动配置,或者你在创业公司待过得话就会知道,找开发在产品库里配置。

其实玩过Scrum的都知道,Scrum最适合的就是全新的概念扔出去试水的情况。当然我们不去深入探讨Scrum。但是,一个全新的需求概念(没有现成的可以抄的)是需要不断放一个优化版的到线上去看用户的反馈的。就比如上面提到的一个例子。老板想了一个全新的概念要做,运营的和市场的做了完善。不管他们表现出来的信心有多大,有一点是肯定的:他们也不知道这到底是他们认为的用户需求还是真真正正的用户需求。就算是真的用户需求,能解决用户的问题,那么这其中有没有什么大的逻辑疏漏导致用户体验功能的时候遇到问题,他们也不清楚。这种情形怎么能不用Scrum呢?

创业公司的浑水

创业公司人少好沟通。是的,你说的很对,但是这是在很早期的时候。当开发团队在50人以上的时候就不再是这样的了。至少在这个人数界限的时候事情就开始走样了。沟通不再是那么的轻松和直接。公司的整体的方向是什么,公司的具体的安排是什么,产品的优化都包括什么作为一个底层的开发已经不太可能有什么了解了。除了直接领导的安排,一个版开发人员并没有其他的正式渠道了解以上说的公司目标,或者说公司的开发相关的目标。Google的OKR据说有这么一个效果,但是没有经历过也没有亚就过不敢说确实有这个功效。

但是,一个实际的情况是BAT等专业化程度已经很高的公司出来的人在这方面的表现也是零。即使是Google的。这些在产品线上一颗钉式的人物对于开发团队的管理可以说是自生自灭式的。普通的开发人员自然乐得多一事不如少一事。于是,大家每天都忙活到很晚。早晨也很有理由的来的很晚。

不想说的技术

日活没几千,点赞都会延时。。。业务驱动技术我是完全赞同的。但是一开始就不能读写分离吗?读写分离了就不能一主多从吗?

以上所说的都是BAT挖过来的。但是在产品、开发、技术、流程和管理上真的没看到他们有什么建树!




欧姆龙FINS(工厂集成网络系统)协议是专为该公司自动化设备间数据交互而设计的网络通信标准。该协议构建于TCP/IP基础之上,允许用户借助常规网络接口执行远程监控、程序编写及信息传输任务。本文档所附的“欧ronFins.zip”压缩包提供了基于C与C++语言开发的FINS协议实现代码库,旨在协助开发人员便捷地建立与欧姆龙可编程逻辑控制器的通信连接。 FINS协议的消息框架由指令头部、地址字段、操作代码及数据区段构成。指令头部用于声明消息类别与长度信息;地址字段明确目标设备所处的网络位置与节点标识;操作代码定义了具体的通信行为,例如数据读取、写入或控制器指令执行;数据区段则承载实际交互的信息内容。 在采用C或C++语言实施FINS协议时,需重点关注以下技术环节: 1. **网络参数设置**:建立与欧姆龙可编程逻辑控制器的通信前,必须获取控制器的网络地址、子网划分参数及路由网关地址,这些配置信息通常记载于设备技术手册或系统设置界面。 2. **通信链路建立**:通过套接字编程技术创建TCP连接至控制器。该过程涉及初始化套接字实例、绑定本地通信端口,并向控制器网络地址发起连接请求。 3. **协议报文构建**:依据操作代码与目标功能构造符合规范的FINS协议数据单元。例如执行输入寄存器读取操作时,需准确配置对应的操作代码与存储器地址参数。 4. **数据格式转换**:协议通信过程中需进行二进制数据的编码与解码处理,包括将控制器的位状态信息或数值参数转换为字节序列进行传输,并在接收端执行逆向解析。 5. **异常状况处理**:完善应对通信过程中可能出现的各类异常情况,包括连接建立失败、响应超时及错误状态码返回等问题的处理机制。 6. **数据传输管理**:运用数据发送与接收函数完成信息交换。需注意FINS协议可能涉及数据包的分割传输与重组机制,因单个协议报文可能被拆分为多个TCP数据段进行传送。 7. **响应信息解析**:接收到控制器返回的数据后,需对FINS响应报文进行结构化解析,以确认操作执行状态并提取有效返回数据。 在代码资源包中,通常包含以下组成部分:展示连接建立与数据读写操作的示范程序;实现协议报文构建、传输接收及解析功能的源代码文件;说明库函数调用方式与接口规范的指导文档;用于验证功能完整性的测试案例。开发人员可通过研究这些材料掌握如何将FINS协议集成至实际项目中,从而实现与欧姆龙可编程逻辑控制器的高效可靠通信。在工程实践中,还需综合考虑网络环境稳定性、通信速率优化及故障恢复机制等要素,以确保整个控制系统的持续可靠运行。 资源来源于网络分享,仅用于学习交流使用,请勿用于商业,如有侵权请联系我删除!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值