创业团队

亲历，创业公司如何死掉的虽然目前尚未离职，但期限迫在眉睫。失望过后还得整顿自己再出发，新开始之前老感觉缺点东西，还是回顾一下东家是如何在这条创业路上死掉的，顺便记录下，已警示后来的自己。1. 目标宏达，出发点错误大Boss目标太过宏大，短时间内无法开发，项目周期太长， 项目落地时出发点偏离，导致刚开始就造重复的轮子。 2. 技术团队人员分布不合理领导在寻求技术团队领导太过感性（后来才知道谈了一个就确定了），技术领导招人的方向出现偏差（以前端全栈为标准），导致出现5个前端没有后端，迫不得已才招1个后端，技术选型也很不友好（用到的技术实践的公司很少）。 3. 缺少专业产品经理和懂市场人员后来才知道产品经理是UI零时转型，产品开发没有切合市场需求， 想当然。 4. 领导不懂技术，缺少团队赋能大boss传统企业出身，不懂互联网技术，作为创业公司很少和团队见面，也不去主导产品的方向。 5. 工资迟发，影响氛围工资长期迟发， 导致员工情绪很大程度受到了影响，人员变动也频繁。 ...我得到了什么学习领导的的一些理念。看清楚创业公司不应搞犯的错误。主导从0到1的项目过程，尝试做了小团队的管理者。发现自己对产品经理非常感兴趣，除了coding，产品将是我的第二职业，非要排出的第三的话，不想做厨师的coder不是好PM。对于如何生活，有了新的认识，当然也是受领导的感染。创业不是有钱就能干的，很大可能是一帮志同道合的人没钱给干成了， 所以初 期的创业公司招人这个路数风险很大， 找人才是上策。见识了当下融资的困境和面临的问题， 必须要有的硬核担当，总的来说，当下的经济形势，资本已将对待A轮公司的标准移到了种子轮或者天使轮， 所以创业更需要硬核产品，砸地必须有坑的产品，这也资本才可能青睐。责任心和正道必须是创业者必须有的基本素质。选择前要慎重， 选择后要要极力证明自己选择的正确性，而不是盲目草率的重新选择。领导看过后觉得写得很好， 欣慰之至，还点赞了， 期望新的开始能让自己变得更好更强大，也希望能给新东家贡献自己的力量。

公众号与个人博客：Java猫说 & 猫叔的博客 | MySelf，转载请申明出处。0、前言最近有点忙，周遭一些事情，当然也是罪有应得，自己做错的事，说什么都要自己扛着…..之所以写这篇文章是刚好最近换了部门，新部门大佬很喜欢和我聊这些，所有我也就适当的记录与分享一下。1、地区与环境的把控我们先不说非客观因素的问题，比如靠关系、靠社会地位等的，我们说刚需而且想要靠自己的产品来生存下去，在完全清楚自己的全部实力的情况下，请选择适合自己且有未来发展空间的地区。2、目标人群设定小年轻、中年人、老年人3、做什么？以下举几个例子吧。3.1、餐饮——新餐饮品牌及运营方法论3.1.1、消费升级上一代人有钱没时间也不敢消费，对未来没有安全感；这一代人没钱有时间借贷消费，对未来更乐观3.1.2、商业本质商业的本质是时间的交换，价值的交换。商业模式的本质一定是建立在一方花费了时间，替你节省了时间。而商业模式的迭代更替，一定是商业效率的提升，商业效率，可以理解为信息流、资金流与物流效率的提升。用数据赋能，提升场的效率用效率革命，提升人的效率用短路经济，提升货的效率3.1.3、餐饮的本质吃饱（食品）、解馋（瘾品）、社交（毒品）例子：1、用【遇见小面】代表吃饱2、用【小飞生煎】代表解馋3、用【太二酸菜鱼】代表社交3.2、社交——新社交社交：用户（消费者）——内容（商品）——内容提供者（生产者）自由交流：遇到合适内容，用户之间可以自由交流，没有人为障碍有效互动：及时得到对方的回应，且回应的内容，与用户本身相关人在一定场景和需求下，与综合或部分价值相匹配的他人，基于价值交换，而产生的行为；为了可能的价值交换，人平时需要维护关系链和新增关系链。3.3、共享经济离不开衣、食、住、行。3.4、电商——是否已晚3.4.1、和传统零售一样，在电商领域，真正赚钱的是少数人在目前的电商行业，只有20%的商家在赚钱，大多数都是苦苦支撑或者亏损状态，这其中包含一些非常有实力的品牌和工厂。3.4.2、同质化产品厮杀惨烈在电商平台——同质化产品的用户对店铺毫无忠诚度，永远有比你销售价格更低的卖家，买家抛弃你的时候连个影子都不会留给你。3.4.3、商城卖家和集市卖家各有优势先把自己做好，再去靠平台3.4.4、最笨的路才是“捷径”一定要明确自己的定位，“品质电商”，才能紧跟时代变化3.4.5、商家之间的竞争不是运营层面的竞争，而是供应链的竞争电商的竞争不是你多会推广，而是供应链，很多问题都是出在供应链，库存最占用资金，产品售馨率太低扣库存很可能就亏损了。4、创业建议遵从增长数据在你给一个新员工发offer之前，想一想，你是否愿意在公司里增加10个像TA这样的员工。公司宁愿留着空缺，也别找个傻缺进来。有两种决定，一种是单向门，不能撤销的；一种是双向门，是可以逆转的。前者需要慎重决定，后者其实不需要花同等精力。辞退员工的时候，给足补偿在每次员工会议上，都要重申公司的使命。不要把过多的精力去对标竞争对手。相信自己的直觉，并时时刻刻的参与项目大部分建议失去了上下文，就不再有价值，所以大部分建议都不值得听。5、结语以上3、4点大多是整合了很多 人人都是产品经理 多篇文章的缩减版，本文并不针对哪个行业来说，就大致的聊一下。关于创业，说说你的心得与想法吧。公众号：Java猫说现架构设计（码农）兼创业技术顾问，不羁平庸，热爱开源，杂谈程序人生与不定期干货。

原文转载自 John Lafleur ： goo.gl/fqfN8h很多文章都提到如何当好一个技术组组长或者技术部经理。常见的话题一般都是如何提高团队的效率。但当你试图提高程序员的效率时，首先要搞清楚效率是怎么变慢的，清楚原因后再来提团队效率。虽然 Peopleware 在 30 年前就发表了，但很多团队依旧会出现精力浪费和效率低下的问题。没人会期待程序员不用电脑就能编好程序，但却有很多公司在不了解程序员的思维方式下就期待他们能把程序编好，这肯定是不现实的。我总结了拖慢程序员创造力和效率的 12 件事，从影响最大到影响最小进行排序。如果有疑问欢迎给我留言！如果你在想是否应该继续看下去的话，想想付给程序员的高工资，所以哪怕提高 10% 的效率也是值得的！1.打断&会议我认为「打断」可以排在破坏程序员创造力的第一位。程序员在被打断后一般不能做到立刻重新开始编程。被打断之后继续编程的话，通常程序员需要重新看一遍代码，再次逐渐进入到编程的思维环境中，才能想起来被打断之前的思维逻辑，再从被打断的点重新开始。这个过程大概要花 30 分钟以上。「打断」越多，烦心越多，工作质量也会降低，Bug 也会随之增加—成为恶性循环。「如果你在我准备开始编程的时候打断我，次数越多- 我重新进入状态耗费的时间就越长。如果你在早晨就安排了一堆会打断我工作的会议，就别怪我这一天什么程序也没编出来」出自 Reddit 上的一个程序员。那么「会议」呢？「会议」和「打断」的唯一区别在于会议是计划好的打断，这比非计划的打断还闹心。程序员无法在被打断的时候还能专心做其他任务。比如你跟程序员开 1-2 小时的会议，基本上不会有什么进展，因为一般技术性的任务 1-2 小时以内是无法完成的。保尔·格雷厄姆(Paul Graham)说过，「一个下午如果被分成两个小会议是最糟糕的情况，因为这两个会议都太短了，什么都做不了。」那么，如何避免这两种情况呢？以下请记笔记：工作会议可以安排在一天开始的时候或者午饭前，并尽量简短，避免不必要的「打断」。2.微管理在所有管理者类型里面，微管理经理对程序员的效率影响最大。这很容易理解，因为微管理经理的会议和临时打断会更多一些，而这些会议和打断会显示出来他们对程序员不信任，程序员也会觉得他们的能力被低估。导致程序员编程的动力在每次被打断的时候就跟浇了冷水一样。这样的影响不止效率，还会使程序员离职或者更换团队。3.编程要求模糊编程要求很模糊有很多种表现方式。比如，故障报告（Bug report）中像「这个不运行，重做！」并不能有效告诉开发人员如何解决问题。用统一的故障报告模版就能解决很多问题。如果某项功能要求很模糊，在这个情况下，开发人员只能靠自己的感觉来编程。最好是能够把某项功能的要求细节化，再递交给开发人员。再有，不清楚的优先级也算需求模糊。这些不必要的时间本来是可以避免的，程序员却要花时间搞清楚自己是否在完成正确的任务。想象一下如果经理来问程序员为什么在做这个任务（在任务优先级没有细节化之前）。你能想象之后的各种解释和误解…4.海鸥管理你听说过「海鸥管理」么？「海鸥管理」是指管理者完全不管工作，像海鸥一样在高空飞，但….他们时不时的会跳出来捣乱。「这个做的不对，这个，这个还有这个做的不行」等，然后再继续飞走。我必须得说，这个场景虽然听起来很可笑，但却很常见。这种情况对开发人员来说非常的烦心，他们可能在之后的几个小时，甚至几天都无法专心。5.被「占便宜」你有过上层或者其他的程序员把你工作成果拿去当成自己成果的情况吗？在程序员心中，能力被认可是摆在第一位的。别人把自己的成果拿去当成是他们的成果，等于剥夺了其他人对自己认可的机会。这一点非常非常重要，如果这种情况发生了，程序员在很长一段时间之内都不会有动力工作。6.环境-噪音，走动，工作环境等等这些对非程序员来说可能比较奇怪，但对程序员工作的效率影响却非常大。比如一些白噪音，像空调噪音，汽车卡车行驶的这些声音，反而可以帮助他们更好的集中注意力。这就是为什么我们总是戴着耳机的原因。顺便推荐最近刚发现的 RainyMood 。相似的，如果工作空间的设计会有很多人走来走去，这也会让程序员无法专心。或者他们坐的位置很容易被管理者看到等等，这些因素都会让程序员压力增大而无法专心。7. 范畴蠕动范畴蠕动（也称为焦点蠕动，需求蠕动，功能蠕动，有时候也称为厨房水槽现象）在项目管理中意思为无法控制的变数。这种情况在项目范畴没有被确定之前会发生。范畴蠕动会让简单的请求变成复杂，超级花费时间的怪兽。一般都在开发过程中发生。比如，一个简单的功能：版本 1（发布前）：功能是在地图中显示一个定位。版本 2 （当版本 1 几乎开发完毕时）：功能变为「在 3D 地图上展示一个坐标」。版本 3 （当版本 2 几乎开发完毕时）：功能又变成「在 3D 地图上展示一个用户能在上空飞过的坐标」。8.产品定义过程这一点可能第一眼看上去有点怪，但是其实非常好理解。如果一个产品团队在没有仔细考察功能是否有需求就定义了产品优先级（通过客户反馈或者其他渠道），程序员很可能会开发出很多用不到的功能。这会让他们觉得自己做的东西没有利用价值，开发的热情也会大大降低。我们都想创造更多的影响力，开发人员更是如此。9.没有考虑技术负债技术负债是为了更快上线产品而使用非最佳解决方案或编写不是最好的代码。这些决定有时候是不可避免的，因为可以在短期内提高软件开发的速度。但是，长远来看，这会让系统复杂程度提高，并且会降低开发速度。非程序员总是想尽快推进项目而低估了生产力的浪费，这就成了一个问题。如果代码重构永远排不上优先级，这不仅会影响效率，还会影响产品质量。10. 工具多样性和硬件开发人员可能会用很多工具来编程，每天都要运行和合并代码很多次。自动化越多越好。这就好比用非常老的没有任何自动化工具来编程肯定会拖慢编程效率一样。大显示屏和笔记本等硬件的区别也是如此。因此，在开发人员的软件工具和硬件上投资是肯定不会错的！让你的开发团队选择他们喜欢的工具和硬件（为单人买硬件，为整个团队买软件工具）。11.如何注释当我们学习编程的时候，知道要尽早开始为代码写注释，越多注释越好。不幸的是，很多程序员把这概念理解错了，导致他们在每一行代码都有注释，如以下这种常见的代码（摘自杰夫安特乌茨（Jeff Atwood）的「不写注释的代码」）：r = n / 2; // 赋值 r 给 n 除以 2// 迭代直到 r – (n/r) 大于 twhile ( abs( r – (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // 赋值 r 给(r + (n/r))/2}你知道这段代码想干嘛么？我也不知道。这就是注释太多会带来的问题，虽然有注释，但这并没有解释为什么要这么写这段代码。如果你在程序调试的时候看到这段代码，对排除报错（debug）并没有帮助。12.不可能实现的项目截止日期管理者总是要求开发人员预估项目完成时间，然后再推动他们缩短预估时间，并以此为截止日期。很多管理者甚至认为，既然这是开发人员自己估计的时间，他们就应该在这个截止日期之前完成，所以这个截止日期是可以正式向上级汇报的。然而，开发人员会认为这个截止日是没有办法完成的，这就导致了开发人员与管理者之间紧张的关系。以上这些事情为什么只针对程序员？如果你看完这 12 件事，你会发现，这 12 件事其实在项目管理过程中经常发生。只是这些事情对程序员的影响更多一些，他们在工作中更需要全神贯注。如果你在公司里看到了以上所提的 12 件事，不妨和大家探讨一下。沟通后，搞清楚这些问题是否真实存在并且如何解决。不管他们怎么说，关键是在于信任他们的反馈和意见。现今的科技和 30 年前比已经很不一样了，但即使如此，人性并没有变。你在考虑公司生产效率的同时必须要考虑人的因素。反复推敲你团队的工作流程，工作环境和工作习惯，让你的团队来指引你达到你想要的最高效率。LeanCloud，领先的 BaaS 提供商，为移动开发提供强有力的后端支持。 了解更多： www.leancloud.cn ...