管理圈子老程序出错怎么办

㈠ 程序员怎样才能走上管理岗位

想接受挑战首先要认识自己，看自己是否适合做管理不防考虑以下几点：对待问题是否公平公正，是否能够牺牲自我的利益顾全大局，是否有洞察力，是否能够了解组员的想法，是否能够做出正确的决策在没有条件许可的前提下……另外在该职责里面有两个重要的事情要做，一件事情是帮着老板干活，另一件事是替组员说话帮助他们争取相应的权益，所以夹心层的处理方式是处理好承担与托付，即责任的承担和信任的建立。

技术管理者的技术不是最资深的，但应该具备专业的能力，并且是某个领域的技术和业务专家，因为一个人的能力是有限的，管理上有所建树便注定了技术道路上深度有限，但他有自己的技术见解并能够在需求把控、产品设计、架构设计中给予建设性意见并作出正确的决策，也只有这样才不会变成空中楼阁的大领导，拥有良好的技术基础是赢得你的团队信任的前提，也是自己能够建设一个可信任的团队的前提。作为管理者只有得到大家的认可，大家的信任，才能进而营造一个可信任的团队，使得各个部门之间互信，协调一致。而得到大家的信任作为管理者必须要有一定技术基础，也只有基于该基础才能做出正确的判断力，才能够确保团队整体方向的正确性。

建议每个技术人员能够经历项目经理的角色，尝试一下管理团队，看一下有哪些问题要解决，换一种角度思考你所参与的项目，培养自己的大局观，大局观重要性在于能够让个体将一个事物分析的更清晰，只有站得高才能看得远，大局观对个人而言很重要，拥有大局观会使个体在把握处理事情上更公正清晰，并更有利于作出正确的决策使得工作向良性方向发展。对于技术学习本身也需要融会贯通、举一反三，这也是一种意义上的大局观，所以思考角度决定着自己在其发展方向前进的远近，不要只是将自己局限于技术细节当中。

认识自己很重要，因为只有自己做了擅长的事情才能够事半功倍，游刃有余，改变一个人太难，与其效果甚微的改掉缺点不如发挥自己的优势。国外有一种创新的思维，认为缺点和优势其实是相辅相成的，你的缺点正好反映出了你拥有它对应的优点，换一个角度扬长避短，真的就事半功倍了。想一想对于组员又何尝不是呢，与其说服改变一个人不如知人善用，扬长避短。

㈡ 产品经理和程序员,如何避免矛盾

产品汪和程序猿

一、产品经理和程序员最讨厌的三句话

产品经理和程序员,就像一对情人，若即若离，有时还会撕逼，和谐的时候一切都好，撕逼的时候两败俱伤。

你知道程序员最讨厌的三句话是什么吗？

1、这个需求很简单，改一下就好了

2、你先大概弄一个，我看看再说

3、我先下班了，加油啊

我想任何一个程序员听到这样的话都会气炸了，不撕逼才怪，你作为程序员会如何回答这三句话？

1、这个需求很简单？你行你来啊！

2、大概先弄一个？请问先生（女士），什么叫大概？

3、你大爷的

你知道产品经理最讨厌的三句话是什么吗？

1、这个需求做不了

2、这个需求工作量太大了，估计要搞3个月

3、这个变更没时间做，往后排吧

产品经理在前端，有用户、有老板、有销售，版本发布的压力很大，听到这样的话估计心情也好不了哪去？

1、这个需求做不了？又不是我提的，还不是那个2B用户提的

2、要做这么长时间？养你们有什么用，还不如我自己来

3、变更没时间搞？随便，等老板来拍你吧。

二、产品经理和程序员本质上的差异是什么

奶爸干过程序员，也干过项产品经理，深知这两类工作的差异，各有各的不易。

总体上来看，做产品更侧重于创造和方案能力，不需要精密的逻辑，所以试错成本相对比较低，大不了改改原型，改改方案，这个成本是可承受的。

程序员的工作是非常精密的逻辑，一个看似很小的变更有可能对代码产生很大的影响，所以试错成本非常高，弄不好可能会因为需求的变化导致系统的重构，这时候程序员的挫败感是可想而知的。

三、产品经理和程序员友好相处的清单

1、产品经理收集需求后，在需求分析阶段，需要把一些不合理的需求尽量和用户沟通去掉，避免不合理需求造成产品发布时间延迟和没有必要的成本浪费，当然这需要产品经理去说服用户，不能只做用户的传声筒。

2、需求分析时，产品经理应该根据经验，敏锐的发现一些在技术层面实现有困难的需求，及时让研发介入，评估技术可行性，避免后续出现需求定下来，研发说做不了的情况。

当然这需要我们的产品经理对软件技术架构有一定了解和预判能力，你不能所有的需求都要在需求分析阶段让研发介入，这个成本也是极高的，所以要把握好这个度也是一项能力。

3、原型还是需求沟通的最好方式，这样是避免产品和研发在需求理解上有差异的最好手段，只靠写一些文字的需求说明书很难达到好的效果。

但这里面要注意一点，产品经理绘制出来的原型一般是非高保真原型，是为了更好的沟通需要，所以不能完全按照原型做，需要基于我们自己的前台架构进行定制。

4、需求评审的时候，研发可能会有一些不一样的意见，他们做了很多年的开发，会有很多好的经验，好的经验要虚心接受，不能觉得自己是产品就是老大，就是要按我说的做，这样很容易造成矛盾，求同存异，目标一致，这个是最好的结果。

5、研发说这个需求做不了的时候，有两种情况，一个是觉得这个需求实现起来比较麻烦，故意骗你；另外一种情况就是他的知识盲区，他可能确实不知道这个事能做。

产品经理需要有能力和研发进行谈判，比如采用类比法（类似的需求在其它项目上咱们就做过），比如去找架构师探讨技术可行性。

6、研发有时候评估的工作量会比较大，整个上线计划拉的比较长，产品经理可以要求研发出详细的资源配置清单，这样能清楚的看到一个需求被分解成了多少个研发任务，每个任务的起止时间，由谁负责完成。这样产品经理大概能看出任务的前后置关系是否合理？工作量是否合理等。

产品经理绝不能说，这么简单怎么要搞这么长时间，类似的话一出，绝对会激怒对方，还是要有理有据进行谈判。

如果实在无法压缩工作量，如果增加人力能解决问题的话，可以考虑找领导申请资源。如果还是不行就要砍需求或者改方案了。

7、在版本计划定好的情况，尽量不加需求，这样很容易打乱开发的节奏，如果一定要加进来，一定要和研发说清楚，这个是用户领导或者老板的强制要求，转移矛盾。如果可以的话，增加了需求尽量推迟上线计划。

8、开发过程中如果需求有改动，需要及时更新需求文档，同时发给我们的研发同学，否则只是靠嘴说一下，很可能研发的同事就不做了，所以一定要落到纸面上。

9、上线的时候要坚持和研发同事一起加班，这样大家才是一个团队，赢了一起狂，输了一起扛。

10、最后一点，就是要多交流，没有什么问题是一顿火锅解决不了的，大家关系好了，很多事情沟通起来自然容易，而且也会更信任对方，这样就万事OK了。

㈢ 程序员被老板发现从网上抄代码，后果是怎么样

老板会怎么样

if(老板对程序开发有了解){ //有了解，一点点的了解即可

认同，见怪不怪;

}else if(老板很开明){ //一无所知，但是开明

信任，尊重程序员的做法;

}else{ //不仅一无所知，还要胡乱猜想

可能需要一个合理的解释;

}

程序员为什么会从网上抄代码

我们程序员不把这个叫做抄，一般称之为“代码复用”。

当程序员需要使用到一个新的框架、类或者方法的时候，一定会做到有迹可循、有理可依，也就是不要乱用。

例如我们一个Spring Boot的项目，现在想用到Rabbit MQ，但是之前没有用过，怎么办？程序员一般会通过这么几种方式：

一些建议

我建议，先试试方案1和3，自己解决不了的话，再去请教其他的同事。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

抄代码分为三种。

一，整个项目抄过来，不做丝毫改动地把别人的代码照搬过来。这种情况很罕见，一是涉及版权问题，二是网上的代码都是烂大街的，抄过来也没什么意义，也获得不了什么收益。

二，抄框架，这点是比较常见的。拿盖楼来举例，就是把别人打好的地基，搭好的脚手架直接拿来用，省去了基础设施搭建的工作。盖房子就直接开始砌砖，编代码就直接开始写业务逻辑。好处是显而易见的，减少了项目前期的重复工作，节省大量的人力物力。老板家里要没有矿的话，一般不会反对用别人的框架。

三，抄算法。简单的算法可以自己写，比如求2个数的和，很简单，一行代码就搞定了。复杂的，人脸识别算法，没有几百万也有几十万行代码，倾注全公司资源都未必搞的出来， 科技 含量非常之高。这种时候，往往会寻求与专业的算法公司进行合作，通过付费的方式获取到相关的代码。

程序员被老板发现旁逗芹从网上抄代码，后果是怎么样？这样的事情被老板发现了，至少从现在来看一点儿事情也没有，如果能够抄得让项目进度大大提前还不出问题不出Bug，不引起纠纷老板还大大的高兴。给他节约了大把大把的钱，他不高兴还咋的。

当然从网上抄代码并不是说整个项目给拿过来，特别是有知识产权的那种，这样一旦被原版权人发现会引起纠纷。大部分程序员抄代码都是一小段一小段代码实现某种小功能、或者对某些方法、类等等用法的抄，以便于在自己的项目中去实现自己所需要的功能，融合到自己的项目中去，而不是盲目的去抄原封不动的搬运过来，程序员一般很少会做那样的事情的。

程序员很少有不上网去了解查询相关的知识的。而现在很多老板本来就是从搞软件项目出身的，或程序员出身的，早就知道这些招数甚至自己也用过，根本不值得大惊小怪，基本上都会鼓励程序员如果有什么不懂就去网络就去找网上相关的解决方法。

尽快寻找解决指巧方法，才可以尽可能的减少一个问题就被卡死在那里花费掉太多的时间，大部分老板不是让你去当钻研代码的开拓者，而是去当能实现项目功能的技术能手，你用什么方式方法去得到那些技术，大部分老板不会关心的。运毕

所以抄不抄代码基本没人管你，最重要的是抄来的代码是不是能解决项目的问题、加快项目的进度、节约项目的成本，只要能解决问题为项目带来效益，总监或者老板还会夸奖你是高手，是能人。

更多分享及互动，欢迎点击右上角关注【东风高扬】。

如果你能抄代码，请选择正确的抄代码的方式，来推荐几个我认为好的网站。

如果有一个网站的提问，可以涵盖你基本90%以上的日常开发问题，那就是这个网站。这里什么方面的代码都有，如果你是一个好的程序员，建议你可以来这里抄代码。

如果你还没有自己的github账户，那你得赶紧来注册一个。GitHub上有好多好的开源项目，Vue，React等等，如果你想看一想好的项目，建议来GitHub看看

如果你善于使用搜索引擎，那你已经比一般人好太多啦。学会使用一些搜索的技巧，能提升你快速找到问题。

所以，我觉得抄代码没什么，我觉得正确的方式，是如何去抄好的代码，去看别人的优点，然后可以使用到自己的项目，这完全没有问题。

拿着高薪的程序员，最熟练的两个快捷键就是ctrl+c 和 ctrl+v。

看到这里你是不是觉得：

哇，做程序员太轻松了吧，了解相关的知识，每天复制黏贴就可以了，还拿那么高的工资，还有没有天理了？

首先“代码复用”这个情况是很普遍的，从 社会 学和经济学来看，复用这个行为是值得肯定的，因为它能够避免浪费有限的 社会 资源。

如果合理地利用开源代码，可以避免“重复造轮子”的动作，从而解放大量的程序员去进行更有价值的开发工作，加快开发效率，以达到资源价值的最大化。

想要把开源代码做成适合公司项目的功能，本来就要求这个程序员的基础扎实，如果没有相关的项目经验，又如何对代码进行维护？

知其然，更要知其所以然。

这就是高薪程序员的高明之处：他们用开源代码来解决自己的问题，把架构、思路融会贯通再变成自己的逻辑表达出来。

程序员主要是实现功能需求，至于怎么实现的，是不是从网上抄袭得又有多少关系，现实中又有多少程序员不是从网上直接复制代码然后应用在自己模块中，把优秀的代码看明白然后灵活应用写在实际代码编写过程中特别常见，现在的开源社区不就是典型嘛，拿到源码然后搞明白，进行各种定制，很多公司都会正大光明的这么去做，在当今的技术领域特别正常。

如果真是老板发现了代码和网络上接近，但是功能用起来没有啥问题，如果因此找到程序员说事，那这老板才是有问题，正常来讲代码的审核主要还是在于直接的技术主管，老板都操心到代码是不是从网上找的了，方向估计该处问题了，老板正常来讲关心的是结果有没有达成，如果进一步拓展自己的业务圈子，把产值最大化。

希望能帮到你。

老板的态度无非是要么是置之不理，要么是批评开除。从老板的态度上可以折射出很多东西来。

置之不理：老板要么不懂程序要么懂程序，老板不懂程序置之不理也正常，如果老板懂程序，那他应该明白这是正常现象。这种态度属于明智之举。

批评或者开除：那老板肯定是不懂程序的，既然不懂程序，就不要在那瞎指挥。团队里自然会有总兼把关恒量。老板的职责是统筹大局，如果这些细小之事也要插手的话，不要留恋立即走人。这里绝对会限制你的发展。

项目本来就是以结果为导向的，任务急，工期短，尤其在创业型公司里，从头到尾从零开发，要耗费多少精力多少人力？我们就要学会“拿来主义”啊，去除糟粕，取精华！

作为码农，将别的功能代码拷过来稍作修改，完成了自己的工作，这样的方式简单快捷，好用，bug少。

能抄到代码，还能知道到哪里抄代码，知道应该抄什么代码，哪段代码，抄完之后怎么融入进去，并且还能解决问题，结果代码还真跑起来了！这也是本事!这也是励练自己的一个方式！

所以自己要对抄代码也要保持清醒的认识，我能故我抄！

俗话说的好，“天下文章一大抄”。我们在工作时，新闻稿、会议纪要等等也是有一定的模板，我们只需要比着葫芦画瓢就行了。那么，程序员从网上抄代码这件事情，如果被发现，会面临什么样的处置结果呢？

实际上，编写代码时最重要的一条，就是学会怎样利用其他程序员的代码和思路来解决问题。程序员写程序抄代码这件事情，也可以视情况分为三种：抄算法、抄框架、抄整个项目。

其实，简单的算法可以自己写，复杂的，比如一个大型 游戏 ，代码多到足以让全公司的程序员怀疑人生。而且一般这种复杂的代码需要和大型的算法公司合作，也不是简单的在网上随便抄一抄就能抄到的。

抄一个应用或者是功能的的框架这件事情，好处也是显而易见，减少了自身这个项目前期的重复工作，节省大量的人力物力，同事还能在现有的而基础上做一些自己需求上的改进，何乐而不为呢？而且应该很少有程序员去真的从最基础的时候一个字母一个字母的敲一整个程序的代码吧。

但是！整个项目不做丝毫改动地把别人的代码抄过来，这就涉及到一个版权和隐私的问题，严重的话是要负法律责任的。

所以说针对程序员从网上抄代码这件事情，要面临的结果无非下面两种，要么老板置之不理，要么被批评开除。

程序员要做的是在能抄到代码的情况下，还能知道到哪里抄代码，知道应该抄什么代码，哪段代码抄完之后能融入进去，并且还能解决问题，才是最重要的。

第一，一般公司老板从来不懂技术，也根本看不懂你是不是在搜资料还是。第二，就算发现你抄，那也是正常，初级程序员抄代码已是常态。关注一下再看下面的精彩哈。

文| 科技 黑洞宇文笑

本人是在某世界五百强企业，公司的老板肯定是见不到的，部门总经理也几乎从来不会在我们这些普通程序员这边逛 ，而且不懂技术。至于所谓的老板，应该是那些技术总监，可惜技术总监一般情况也不会碰你的答案。而技术总监下面一般是技术经理，普通程序员就归技术经理管管，跟着做项目，即使他发现你抄代码，也不会说什么，只要你能完成自己手头上的任务，无论你用什么方法实现。甚至他会教你“抄”哪的，其实这是叫你借鉴代码，这样你才能完成你的左右。

现在程序员抄代码，是比较普遍的，抄网上的，或者复制同事的。复制同事的函数直接不改，就有些无脑，而复用别人的代码，反而是正确值称赞的，这往往能提高代码的整洁度。如果你抄网上的，一般是没有现成可以用的代码，只能借鉴其思路，然后结合自己的业务，写一套自己的代码，这种做法往往还需要程序员有不错的基础，不然你连别人的代码都不懂利用。

程序员宇文笑一句话:

善“抄”代码，反而是一种编程美学，不过请你优雅。觉得说的好赏个关注呗。

产品功能产出流程：

一、产品经理：需求调研、产品需求文档、原型图的产出。

二、商讨需求可行性(移动端、前端、后端、UI、测试、产品)。

三、根据各个职能岗位意见以及需求产出时间成本等等条件因素，修改需求。

四、需求文档、原型图交由UI、后端、测试

1.UI根据需求文档、原型图设计效果图、标注图、切图。

2.后端根据需求文档、原型图设计数据库表结构、接口数据结构、接口文档；

3.测试根据需求文档、原型图写测试用例;

五、如上所产出(计效果图、标注图、切图)(接口文档)交由移动端和前端开发人员开发。

六、开发人员开发完成自测之后交由测试人员进行功能测试以及性能测试。

1.测试人员根据《测试用例》进行功能测试形成报告反馈(移动端、前端、后端、UI、测试、产品)进行BUG修复，需求完善，交互优化等。

2.性能测试包括后端压力测试，移动端的内存等等。

七、最后进行灰度测试或者内部众测。

八、最终产品更新上线。

如上表述，程序员在一个功能开发过程中，最重要的是保证产品功能稳定性、扩展性。至于怎么实现如果没有意外。领导不会关心你怎么实现。而且在程序员这个行业工作要的是思路具体怎么实现复制粘贴代码是很经常的事情。so。。。你这个问题其实并不是问题。