程序和产品之间的故事,android开发,ios开发,wp开发必备攻略

本文深入探讨了程序员与产品经理之间的合作与冲突,揭示了他们在功能实现、产品设计和团队协作中遇到的问题。通过角色扮演和实际案例,展示了双方在沟通、责任分配和专业领域的界限上的不同看法。文章强调了专业分工的重要性,指出双方需要相互尊重各自的专业领域,以实现高效的合作。

近来看了一首MV《产品经理是条狗》,感觉产品经理好无辜啊,“产品狗”这个帽子怕是摘不掉了,没关系,不是还有“程序猿”陪你么,嫌少还有“工程狮”~

 

DevStore办公室,程序员小李又被叫产品经理叫去修电脑了,由此引发了一场鲜为人知的血案......(请留意结尾彩蛋)

 

好了,进入今天的主题——你怎么看程序员与产品经理的关系,不共戴天还是唇齿相依?

 

程序员小李(化名)

热火朝天的办公室,一精壮青年小李一边啃着馒头,一边看着眼前产品,愁眉紧锁的他陷入了沉思:产品下一步应该怎么走?如何保证代码质量?如何缩短项目时间?如何控制项目成本?一个个难题需要他思索,抉择。此时,传来产品经理的吆喝:“小李,先别敲代码了!给我修下电脑……”

小李心想:要不是家里穷,老子就是美国麻省理工的高材生,尼玛你居然让我去给你修电脑,太不尊重我的工作了吧,居然这样无情践踏我的尊严!

因为明白你们不懂计算机组成原理,所以容忍去帮你们修几次电脑;因为明白你们不懂操作系统,所以容忍去帮你们重装几次系统;因为明白你们不懂计算机病毒原理,所以容忍去帮你们杀几次毒…… 但是,给你修电脑不是我的义务与责任!产品狗,侮辱之仇不共戴天~

 

产品小美(化名)

产品经理,就应该对产品的功能有决定权,但是如果产品失败了,也要负直接责任。我考虑产品的功能特色、性能,还要考虑老板提的要求,还要考虑市场定位、用户需求,还要为产品市场效果负责,我容易么,所以我是产品的核心,程序员你只管安心实现功能就行了,不需要操心产品上的东东。

 

某资深产品

程序员总是想尽量精简并按照自己的想法来完成一些功能设计,有时候为了完成功能,并不会完全按照最初的产品设计来执行,那么未来就有可能进行返工,产品会指责程序员没有按照设计执行,程序则会以各种功能无法实现为借口进行反驳,“无法做,无法实现”是最佳的刁难理由。

 

做产品的时候,总是想一开始就做一个大而全的东西,别人有的我要有,别人没有的我也要有,总是先模仿同类的其他网站,这样很难有自己的特色。程序员做的不是自己想做的,所以他们总是消极怠工,或者是代码考虑不周全,留下了未来的一大堆隐患,或者是本来可以很快完成的任务,他说是很复杂,这个需要做很久,以此来表达自己的不满和抱怨。

 

双方交恶的更本质的原因一般不在改需求本身,专业程序员不会反对改需求,一般的原因在于不相信程序员的专业性,举个例子,你要改动一个登录页面的流程,程序员告诉你,这个功能要两周才能做完,你说不行,一周必须做完。这样就没办法沟通了,不写程序的人决定一个程序多少时间写完(注意我说的是决定),这是很荒唐的一件事。一般的结果是闹到老大那里去,最后加班(加班从来也不是一种专业的表现)。

专业的产品经理不应该用功能的产生原因来说服程序员,这不是程序员应该关心的事,如果程序员关心这事,很好。但这不能起决定作用。同理,程序员认为产品经理需要懂写程序也是算流氓。

 

某资深程序

程序员有产品意识,这点是很好的,你可以提意见,但是不重要。程序员只该关心实现这个功能的成本,并给出这个功能的成本,能不能带来好的体验,和程序员的工作没有关系。当然你可以提意见,但是不起决定作用。

 

如果程序员以不能带来更好的体验去反驳产品经理,这就是不专业的体现。

我们需要专业分工,你可以懂别人领域,提出意见,但是你不能以此来说服对方,因为对方在这个领域才是专业人才,如果搞砸了,是别人要承担责任,不是你。

 

产品的体验好与否,和程序员无关。(记住,这里说无关并不是鼓励你不去关心这个问题,事实上一个程序员去了解点产品的知识总是有好处的,但是这个不能拿去当论据,这不是你的工作职责)

程序员拒绝一个功能的理由有且只有一个:这个功能程序上无法实现,我说的是绝对无法实现。

源码链接: https://pan.quark.cn/s/7b9e1590db2e 在本计划中,我们聚焦于一个基于数字逻辑的药片装瓶系统的构建,这构成了北京邮电大学(北邮)在小学期内向学生提供的一次课程设计课题。该系统致力于模拟实际药品包装的操作流程,借助电子操控自动化技术达成药片的高效且精准的装瓶目标。以下是对该系统设计所涉及的关键知识领域的详尽阐述: 1. **数字逻辑**:数字逻辑是电子工程领域的核心学科,主要探究如何运用二进制数字进行信息的表征与处理。在此项目中,数字逻辑用于构建实现系统的控制机制,诸如计数器、编码器、解码器、触发器等,旨在保障药片装瓶过程的精确调控。 2. **硬件电路构建**:系统可能整合微控制器、传感器、执行机构等硬件单元。例如,微控制器作为系统的心脏,负责接收输入信号,处理数据,并指挥执行机构执行药片装填。传感器负责监测药片的数量瓶装进度,而执行机构如电机则负责实际完成装瓶动作。 3. **计数器**:在药片装瓶的操作过程中,计数器用于追踪已装入瓶子的药片总数,确保达到预设的剂量标准。这可能需要设计同步计数器或异步计数器,以实现精确计数并触发装瓶操作。 4. **编码与解码**:编码器将特定的信息(例如药片种类或剂量)转化为二进制编码,便于硬件设备进行处理;解码器则将这些编码解读为可执行的操作,如切换装瓶路径或启动封盖流程。 5. **触发器**:在系统中,触发器可用于在特定条件达成时启动或中止某个操作,例如当瓶子达到满载时关闭装填机制。 6. **传感器技术**:可能包含重量传感器、光电传感器或机械触碰开关,用于识别瓶子的存在、位置以及药片的数量。这些传感器的精确度直接关联到整个系统的性能水平。 7. **控制算法**...
内容概要:本文针对孤岛微电网在遭受拒绝服务(DoS)攻击下的安全与稳定运行问题,提出了一种基于混合系统理论的弹性二次控制策略,创新性地将动态事件触发机制与DoS攻击防御进行协同设计。该方法在保障微电网电压、频率恢复及有功功率精确均分的同时,有效应对通信链路被恶意阻塞的安全威胁,实现了控制性能与通信资源利用效率的双重优化。通过Simulink仿真平台与Matlab代码实现,验证了所提策略在复杂网络攻击场景下的鲁棒性与有效性,深入分析了系统稳定性条件及攻击容忍边界,为电力信息物理系统(CPS)在面临网络安全挑战时的可靠控制提供了理论依据技术路径。; 适合人群:具备电力系统自动化、分布式控制或网络安全等相关专业背景,熟悉Matlab/Simulink仿真环境,从事微电网控制、信息物理系统安全或弹性控制研究的研究生、科研人员及工程技术人员。; 使用场景及目标:① 提升高比例分布式能源接入背景下孤岛微电网在通信受限与网络攻击耦合场景下的运行可靠性与弹性恢复能力;② 实现低通信开销下的分布式协同控制,优化资源利用并增强系统抗干扰性能;③ 为电力系统中安全-控制联合设计提供可复现的仿真模型与技术方案,推动安全防护从被动响应向主动容忍转变。; 阅读建议:读者应结合文中提供的Matlab代码与Simulink模型开展仿真实验,重点理解动态事件触发机制的设计原理及其与混合系统稳定性分析的融合方法,建议延伸学习DoS攻击建模、弹性控制理论及相关安全性证明技术,以全面掌握该协同设计框架的核心思想与实现细节。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值