精华内容
下载资源
问答
  • 经过两月的实践,随着项目的进展及环境的变化,这项实践并未持续下去,现这段失败的经历进行总结如下: 、项目背景 原有项目管理状况为: 项目成员6人,其中测试人员1名;项目经理根据公司业务要求,...

           年初参与到研发团队,决定使用敏捷的方法进行项目管理。经过两个月的实践,随着项目的进展及环境的变化,这项实践并未持续下去,现对这段失败的经历进行总结如下:

            一、项目背景

           原有项目管理状况为:

           项目成员6人,其中测试人员1名;项目经理根据公司业务要求,估算工期,指定开发计划、分配任务给相关开发人员进行开发,开发完成后,开始测试,修改Bug。没有例会,所有人员有问题直接找项目经理,每个人只负责自己的模块,所有的问题的决策都由项目经理一人决定。

            二、实施过程

           1、目标:希望建立一个自组织的团队

           2、实施方法:先建立敏捷的形式,逐步完善敏捷中的实践,通过不断学习和积累逐步使团队敏捷。

                 (1)最初的实践:召开每日站会,基本按照站会中的三个问题进行。

                 (2)增加的实践:通过白板和TAPD管理用户故事和迭代,收集产品需求,根据优先级纳入到迭代计划中,控制迭代周期和工作量

                 (3)完善实施过程:通过GoCD进行每日构建

                 (4)召开迭代回顾会议:总结问题与不足、完善敏捷过程

            三、失败因素

           1、敏捷流程和知识准备不足,敏捷实施流程不完整。

                  没有进行正式的迭代启动会议、没有进行功能演示

           2、结对、TDD、重构未能在团队中实施

                  对单元测试进行简单培训,但未强制实施

                  结对编程未能得到团队认可,每个人仍习惯单兵作战

                  开发人员不具备重构技能,没有重构意识,只关注当前任务的完成

           3、实施过程未进行项目度量

                  没有让燃尽图发挥作用

                  没有衡量团队的生产率

            4、团队能力的培养

                 只注重业务功能的开发,加班加点工作但未能让团队抽出时间学习

                 对于项目中需要的重构技术、TDD技术没有经验丰富的人员进行培训

            5、管理层的压力及团队变化

                  因创业公司压力大,领导层对研发团队的产出不满意,加班加点仍不能满足新功能的需要。

                  增加人员、更换项目经理,敏捷实践未能继续完善。

            四、收获

            1、星星之火,可以燎原。传播了敏捷知识,部分人员在后续工作中开始接受结对、接受TDD。

            2、对Scrum和XP的过程和价值有了更深的认识,更加坚定了对这种方法和实践的信心,如有机会仍然继续探索

     

      

    展开全文
  • Shekhar Gulati 给我们分享了微服务失败的 11 原因,这些原因还算比较常见,我们相信,他总结的心得对于想要尝试转型微服务的公司是大有裨益的,因此,我们翻译并分享了这篇文章,以飨读者。 在过去的几年里,我...

    微服务是当前流行的架构。简单地说,微服务就是一种面向服务的软件架构,在这种架构中,服务器端应用程序是通过组合许多单用途、小容量的网络服务来构建的。微服务架构让边界设计良好的服务的失效互不影响成为可能。但是,微服务和所有的分布式系统一样,也会存各种各样的问题。Shekhar Gulati 给我们分享了微服务失败的 11 个原因,这些原因还算比较常见,我们相信,他总结的心得对于想要尝试转型微服务的公司是大有裨益的,因此,我们翻译并分享了这篇文章,以飨读者。

    在过去的几年里,我对进行数字化转型的多家产品团队进行了架构审查。大多数团队都是遵循微服务架构来构建产品。他们完全有理由使用基于微服务的架构:更快的开发、更好的可扩展性、更小的独立团队、独立的部署、使用正确的技术来完成工作,等等。但是,我经常发现,团队在微服务方面举步维艰。他们未能充分利用微服务的优势。在本文中,我将分享我的观点,阐述团队在微服务方面为何举步维艰的原因。

    对于刚接触微服务的新手来说,我推荐阅读 Martin Fowler 关于微服务的文章。我很喜欢这篇文章中提到的微服务架构定义。

    微服务架构风格就是一种将单个应用程序开发成一套小型服务的方法,每个应用程序都在自己的进程中运行,并与轻量级机制(通常是 HTTP 资源 API)进行通信。这些服务是围绕业务功能而构建的,并且可以由完全自动化的部署机制来独立部署。这些服务只有最低限度的集中管理,可以用不同的编程语言编写,并使用不同的数据存储技术。

    原因 1:管理层低估了开发微服务的复杂性

    我曾与许多非常看好微服务的客户一起合作过。对他们来说,微服务就是解决他们所有问题的灵丹妙药。在与我讨论中,我发现大多数团队及其管理层低估了微服务开发的复杂性。

    要开发微服务,开发人员需要一个高效的本地环境设置。

    随着系统中的服务数量开始增加,在一台机器上运行应用程序的子集变得越来越困难。特别是当你使用消耗较多内存的语言(如 Java)构建应用程序时,更是如此。

    下面是与本地开发设置相关的要点。

    1. 本地开发的第一个重要方面是要有一个好的开发机器。我发现,大多数组织想要使用所有最新的、最先进的技术,但却不想替换掉糟糕的 Windows 开发机器。开发人员受限于他们的开发机器。我曾见过开发人员使用 VDI 映像或配置交叉的机器来构建基于微服务的系统。这降低了他们的工作效率,使他们无法完全投入工作。使用糟糕的开发机器带来的副作用就是,开发人员无法得到快速的反馈。如果你知道必须等待数分钟才能运行集成测试套件,那么你就不会编写更多的集成测试套件,免得给你带来痛苦。糟糕的开发机器将会导致糟糕的开发实践。
    2. 一旦你为开发人员配备了合适的开发机器,那么下一步就是确保所有服务都使用构建工具。你应该能够在一台新机器上构建整个应用程序,而不需要进行太多配置。根据我在微服务方面的经验,使用能够构建整个应用程序的根构建脚本也会有所帮助。
    3. 下一个要点就是要让开发人员能够轻松地在他们的系统上运行应用程序的各个部分。在配置了所有端口和卷的情况下,你应该使用多个 docker-compose 文件来提供不同的服务。
    4. 接下来,如果你使用的是类似于 Kubernetes 的容器编排工具,那么你应该投资类似于 Telepresence 这样的工具,以便轻松调试 Kubernetes 集群中的应用程序。

    如果组织对微服务开发的复杂性缺乏理解,那么团队的速度将会随着时间的推移而下降。

    原因 2:未将库和工具更新到最新版本

    在我看来,我发现一个新的平台已经成为一种遗产。团队没有确保依赖项是最新的版本,或者将像数据库这样的工具升级到最新版本。因此,两年前开始的现代化改造,如今已经背负了长达数月的技术债务。

    几年前,许多团队开始将 Spring Cloud Netflix OSS 项目用于微服务。他们使用像 Kubernetes 这样的容器编排工具,但是因为他们是从 Netflix OSS 开始的,所以他们没有使用 Kubernetes 提供的所有功能。当 Kubernetes 内置了服务发现时,他们仍然使用 Eureka 作为服务发现。此外,通过类似 Lstio 这样的服务网格,你就可以摆脱 Netflix OSS 提供的大部分服务。这有助于降低复杂性,并将许多“横向关注点”(cross cutting concerns)转移到平台上。

    需要记住的另一点是,要使所有服务的依赖项版本保持同步。我最近在帮助一个客户,他使用 Spring Boot 来构建微服务。在过去两年中,他们已经构建了 20 多个 Spring Boot 服务。在他们的环境中,他们使用的 Spring Boot 版本从 1.5 到 2.1 不等。这意味着当有人设置他们的机器时,他们必须下载多个版本的 Spring Boot。此外,他们还缺乏自版本 1.5 以来在 Spring Boot 中所做的许多改进。

    我们的建议是,组织应该在其积压中为这些升级创建技术债务项。这些技术债务项应作为架构委员会会议的一部分加以讨论,并定期予以解决。在我的上一个项目中,我们每三个月设置为期一周的 sprint,将所有依赖项更新到最新版本。

    原因 3:利用共享服务促进本地开发

    由于本地开发状况不佳,大多数团队开始依赖于共享环境来获得关键服务。开发人员机器中的第一件事就是数据库。大多数年轻的开发人员并没有意识到基于共享数据库的开发是“邪恶的”。下面,是我在共享数据库中看到的主要问题:

    1. 团队成员必须建立一个工作的社会契约,以避免最后写入者胜出(Last write wins,LWW)问题。一个开发人员可以删除其他开发人员为他们的工作编写的数据。这种工作方式既痛苦又容易失败,迟早会影响整个团队。
    2. 开发人员害怕实验,因为他们的工作会影响其他团队成员。我们都知道,更好的学习方法是实验和快速反馈。有了共享数据库,就可以进行实验了。我们需要进行实验,以提出数据库模式,并执行任务,如性能调优之类。
    3. 另一个副作用就是,很难单独测试更改。你的集成测试将变得不可靠,从而进一步降低了开发速度。
    4. 共享数据库必须像宠物一样对待,因为你不希望它出现不一致和不可预测的状态。你可能会遇到这样一种场景,开发人员希望在表是空的时候测试边缘情况,但其他开发人员需要一个表来记录。
    5. 只有共享数据库拥有系统工作所需的所有数据。随着时间的推移,团队成员失去了更改的可追溯性,因此没有人知道,他们该如何在他们的机器上复制相同的设置。唯一的方法是获取完整的数据库转储并使用它。
    6. 如果未连接到网络,就很难开展工作。这种情况通常发生在你通勤时间过长或乘飞机的时候。

    数据库只是共享服务的一个示例,但它也可以是消息队列、集中缓存(如 Redis)或任何其他服务可以发生改变的服务。

    解决这一问题的最好方法是,让开发人员可以轻松地在他们的机器上运行数据库(作为 Docker 容器),并投资创建 SQL 脚本来设置模式和初始主数据。这些 SQL 脚本应该保存在版本控制中,并像维护任何其他代码一样进行维护。

    原因 4:版本控制托管平台缺乏可见性

    我曾与一个客户进行合作,当时,他们的版本控制系统中有 1000 多个仓库。他们使用的是 Gitlab 版本控制平台。他们有 5 个产品,每个产品都由多个微服务组成。我问他们的第一个问题是帮助我们了解哪些服务及其各自代码库是产品 A 的一部分。他们的首席架构师不得不花一天时间弄清楚所有产品 A 的仓库。一天过去了,她还是不能确定是否弄清楚了所有的服务。

    解决这个问题的最好方法是,从一开始就以某种方式对你的微服务进行分组,这样,你就可以随时了解产品的生态系统。Gitlab 提供了一种方法来创建一个组,然后在其中创建项目仓库。Github 并没有组功能,因此你可以使用主题或命名约定来实现它。

    我个人更喜欢 mono repos,因为我发现他们真的很方便。我遇到的大多数开发人员都认为它是一种反模式。我同意 Dan Lua 的观点,他提到了 mono repo 的以下好处:

    简化的组织简化的依赖关系工具跨项目变更

    原因 5:服务没有明确的定义

    大多数团队并不知道什么应该被视为服务。关于究竟是什么构成一个单一的微服务,人们对此存在很多混淆的认识和困惑的概念。让我们举一个例子,假设你的应用程序具有类似插件的架构,在这个架构中,你集成了多个第三方服务。每个集成应该是一个微服务吗?我看到很多团队,都在为每个集成创建一个微服务。随着集成数量的增加,这种情况很快就会失控,以至于无法管理。这些服务通常太小,以至于将它们作为单独的进程运行,会增加更多的开销。

    我认为,哪怕只拥有少量的大型服务,总比提供太多的小型服务要好得多。我将从创建一个服务开始,该服务对业务组织中的整个部门进行建模。这也符合 DDD(领域驱动设计, Domain Driven Design)。我将一个域分为子域和有界上下文。有界上下文表示公司内部的一个部门,如财务部门和营销部门。你可能认为,这会导致大型服务的出现,你是对的。但是,以我的经验来看,将整体重构为微服务总之比反之更容易。随着你的知识经验越来越多,你可以转向代表更小问题的细粒度微服务。你可以应用单一责任原则(Single Responsibility Principle)来了解你的微服务是否变得过大,做的事情是否过多。然后,你可以将它分解成更小的独立服务。任何服务都不应该直接与其他服务的数据库通信。他们应该只通过已发布的合同进行沟通。你可以在 Microservices.io 网站上阅读更多关于按子域模式分解 的内容。

    我也遵循了 Backendlore 文档中提到的建议。这个建议可以帮助将服务限制在服务通信上,而服务通信是微服务系统性能低下的首要原因。如果两条信息相互依赖,那么它们应该属于同一个服务器。换句话说,服务的自然边界应该是其数据的自然边界。

    原因 6:代码重用策略不明确

    我曾经和一个客户合作,该客户在他们所有基于 Java 的微服务复制了四个与特定问题相关的 Java 文件。因此,如果在该代码中发现 bug 的话,就需要将其修复应用到所有地方。我们都知道,在时间紧迫的情况下,我们会错过将更改应用于一个或多个服务。这样会浪费更多的时间,增加挫败感。

    这并非说开发团队不懂正确的事情。但是,按照组织结构,人们总是默认采用简单且容易出错的做事方式。

    正确的方法是,使用像 Bintray 或 Nexus 这样的工件管理器,并在那里发布依赖项。然后,每个微服务都应该依赖于这个库。你需要构建工具,以便在发布新版本的库时,所有的微服务都应该进行更新和重新部署。

    使用微服务并不意味着你不应该使用迄今为止对我们有用的最佳实践。你需要对工具进行投资,使微服务的升级变得更容易,这样人们就不必这样做了。

    在没有适合的工具和自动化的情况下,使用微服务会导致灾难。

    原因 7:多语言编程设计

    我发现团队使用多种编程语言、多种数据库、多种缓存,并以最佳工具的名义进行工作。所有这些都在项目的初始阶段起作用,但随着你的产品投入生产,这些选择开始显露出它们的本色。原因就像我们在构建 JavaSpringBoot 应用程序,但是我们意识到 Java 占用了更多的内存,且性能也很差,所以我们决定改用 Node.js。在我上一次任务中,我向团队解释说他们的推理能力很弱。

    1. Note.js 比 Java 性能更好。 如果你的工作负载是基于 I/O 的,Node.js 通常会表现的更好。但在任何计算密集型的工作负载上,Java 都胜过 Node.js。通过响应式范式(reactive paradigm),你可以使用 Java 为 I/O 工作负载提供更好的性能。在 I/O 工作负载方面,Spring Boot Reactor 的性能相当于 Node.js。
    2. Node.js 比 Java 消耗更少的内存。 这在一定程度上是正确的说法。Java Spring Boot 应用程序并不像大多数想象的那么糟糕。我在一个 Spring Boot Java 微服务上运行了负载测试,内存消耗仍然没超过 1 GB。你可以通过 OpenJ9 JVN,限制对类路径的依赖,并通过调优默认的 JVM 参数来优化 Java 内存利用率。此外,在 Java 中还有 Spring Boot 的新替代品,如 Micronaut 和 Quarkus,它们消耗的内存相当于 Node.js。
    3. Node.js 比 Java 效率更高。 这取决于编写代码的开发人员。使用静态类型和静态分析工具的 Java 可以帮助在开发生命周期的早期发现问题。

    大多数情况下,这完全取决于上下文。如果你的开发人员还不够成熟的话,那么无论你使用什么编程语言,你开发的都将是糟糕的产品。

    我建议一家组织要发布一个团队可以使用的语言列表。我认为 2~3 就是个很不错的数字。另外,要列出一种语言比另一种语言更适合的理由。

    在选择一门语言之前,你应该考虑以下一些问题:

    1. 找到成熟的企业软件开发人员有多容易?
    2. 重新培训开发人员掌握新技术有多容易?我们发现 Java 开发人员可以相对容易地学习 Golang。
    3. 初始团队之外的开发人员贡献、转移和维护其他人编写的代码有多容易?
    4. 就工具和库的方面而言,生态系统有多成熟?

    这不仅仅局限于编程语言,也适用于数据库领域。如果你的系统中已经有了 MongoDB,那么你为什么要在生态系统中使用 ArangoDB 呢?它们都主要是文档数据库。

    要始终考虑使用多种技术的维护和操作方面。

    原因 8:人员的依赖性

    这并非微服务特有的现象,但在微服务生态系统中却变得更加普遍。原因是,大多数团队专注于他们的特定服务,因此他们并不了解完整的生态系统。在我与不同客户的工作中,我发现,只有一群架构师了解整体情况。但是,这些架构师的问题在于,他们并不积极参与日常活动,因此他们对开发的影响力是有限的。

    我认为最好的办法是,确保所有团队都有一个架构团队的代表,这样他们就可以使他们的团队与整个架构团队的路线图和目标保持一致了。要成为一个成熟的组织,你需要投资于建立一个轻量级的治理。

    原因 9:文档的缺乏

    在过去几年里,我们接触过的大多数组织都在文档方面遇到了困难。大多数开发人员和架构师要么不去编写文档,要么编写的文档毫无用处。即使他们想写,他们也不知道应该如何记录他们的架构。

    我们至少应该记录以下内容:

    1. 设计文档。
    2. C4 模型中的上下文和容器图。
    3. 以架构决策记录的形式跟踪关键架构决策。
    4. 开发人员入门指南。

    我建议在版本控制系统中维护所有的文档。

    原因 10:功能超过平台成熟度

    我已经在其他观点中简要地提到了这个原因,但我认为,它值得作为一个顶级原因来提及。微服务要比传统的单体式应用(monolithic application)更为复杂,因为你正在构建一个包含许多活动部件的分布式系统。大多数开发人员还不了解系统的不同故障模式。大多数微服务在构建时都考虑了令人快乐的路径。因此,如果你的管理层只想仅仅关注功能,那么你注定会失败。因为在薄弱平台上构建的功能是无法提供价值的。

    组织需要有平台思维。平台思维可不仅仅意味着使用容器和 Kubernetes。它们是解决方案的一部分,但本身并非完整的解决方案。你还需要考虑分布式跟踪、可观察性、混沌测试、函数调用与网络调用、服务间通信的安全服务、可调试性等等。这需要在构建正确的平台和工具团队方面付出认真的努力和投资。

    如果你是一家资源有限的初创公司,我的建议是,你要重新考虑微服务战略。了解你所面临的问题是什么。

    原因 11:缺乏自动化测试

    大多数团队都知道自动化测试对产品的整体质量有多重要,但是他们仍然没有做到。微服务架构为测试地点和测试方式提供了更多的选择。如果你不进行彻底的自动化测试,那么你将会失败得很惨。关于这一点,我不会再赘述,因为网上很多人都写过这方面的内容了。下图是我从微服务测试的文章找到的,这篇文章来自 Martin Fowler 的网站,讨论了基于微服务的系统的测试金字塔。

    微服务失败的 11 个原因

    微服务测试金字塔

    展开全文
  • 失败的项目总结经验

    千次阅读 2017-11-24 08:04:48
    在知乎这个码农占了半壁江山地方,说一个苦哈哈制造业失败项目不知道有多少人喜欢听。不过我来说,认真反思这个耗时近两年却没有任何结果项目,这事儿早该做了。前事不忘,后事之师,希望自己以后能更成熟。...

    在知乎这个码农占了半壁江山的地方,说一个苦哈哈的制造业失败项目不知道有多少人喜欢听。不过对我来说,认真反思这个耗时近两年却没有任何结果的项目,这事儿早该做了。前事不忘,后事之师,希望自己以后能更成熟。 


     电子纸项目,我只是团队一员,算比较重要的一员吧。电子纸就是几年前火得一塌糊涂的电纸书屏幕,电纸书就是外观有点像iPad但实际完全不一样的东西,kindle的模仿品。  可能会有一些人知道的Bambook就是我们的最终成品之一(注意我只是指硬件这部分,而且2010年Bambook刚出来的时候使用的仍然是E-ink的电子纸,后来到2011年才开始使用我们的电子纸, Bambook的软件部分应该是盛大自己做的,可以去咨询一下 @贺师俊 ,前Bambook开发团队成员)。如果将Bambook的制作全流程分为上中下游的话,上游负责生产电子墨水,中游负责用墨水和其他膜类材料生产电子纸屏幕,下游负责屏幕和其他元器件组装成电纸书。我是负责中游的,也算是核心技术了。因为除了配方和电子纸屏幕的批量生产外,其他工序都是电子行业标准化流程化的东西,可以外包的。换句话说,电纸书的新技术都在屏幕上,其他技术相对成熟了。  当然到现在为止,这个项目仍在继续,不能说已经完全失败,只是离当初的期望,已经去了不只十万八千里了。  


     1、背景 


     缘起于当时答主所在公司A和创业公司B的合作。  麻省理工学院下属E-ink公司(后来被台湾元太科技收购了)是电纸书的始作俑者,其所研发的电子纸,与普通纸张十分相似,代表了业内最高水准:超长待机(20天以上)、低功耗不伤眼、全视角、无辐射。E-ink公司前高层B-1回国创立了公司B,并得到了软银、富士康(背后的鸿海)的投资,进行核心技术(电子纸配方)开发,并与我所在A公司达成了加工合作协议,我们帮他从配方转换为产品。  当时是2011年中,我毕业一年,毕业两年半之后我离开转行。还记得汉王吗?今年过节不收礼,收礼只收电纸书。依靠这个噱头,2010年年底,汉王股票价格超过150元。刚刚顺手查了一下,现在是20.71,向2010年买汉王股票的同志默哀。 


     2、任务 


     整个项目的任务是:生产出性能达到并超过E-ink电子纸的屏幕。性能的一些关键指标是屏幕尺寸,厚度,反应时间,对比度,白度等。  


     3、项目运作方式 

    由B公司主导,B公司进行实验室配方合成,并提出实验和生产需求;我A公司进行工艺实验、批量生产屏幕及屏幕裁剪和检测,并将屏幕成品送回B公司。B公司将屏幕外发与其他模块进行组装成为电纸书。   


     我被赋予的任务是:在我公司内部协调生产时间、调度生产人员、改进生产工艺、品质监控、后期还包括采购生产原材料、改进并购置生产仪器(有一个仪器工程师一起负责,我提要求他负责采购),给生产线制定操作规程、作业标准(后期补充了一个新来的品质工程师负责,不过没几个月我就离职了)、计算加工费(开始我们是合作,后来随着高层策略改变,成为我们帮他们加工,所以我们要向B公司收加工费,卧槽这™是人干事?)  我的职位是:工艺工程师兼项目工程师(本来是负责我们部门自己产品的工艺改进的,但负责电子纸项目后实际上承担的是项目经理的职责了) 

     

     4、当时面临的问题  

    市场突然遭遇寒冬:实际上从2011年5月开始,坐拥电纸书行业第一把交椅的汉王科技遭遇销量和价格同时的“滑铁卢”:销量我拿不到准确的数据;电纸书在2010年价格是3000多元,低端产品也要接近2000,到2011年新一代bambook出来,定价是499。个中缘由到现在也没有人真正搞清楚,有人说是iPad影响,可是iPad卖得最火的米国kindle销量一样高歌猛进;有人说是汉王前几年的礼品宣传透支了市场;有人说是中国人就是不爱读书;有人说是国内书城体验太烂内容品味太low;总之众说纷纭莫衷一是。当然参与者没有那么悲观,觉得也许只是暂时的冲击,觉得也许可以“剩者为王”,所以我们还是在坚持。  


     B公司的问题:  


     --战略目标模糊不清: B公司作为项目的领导者和规划者,本应该给出一个清晰可见的目标或者努力方向。但其老板描绘的前景却美好而不一致(要不然也忽悠不到那么多人投资)。一会儿说要搞彩色电子书,一会儿说要拓展在教育行业的用途,一会儿又说要开发欧洲市场,总之就是画大饼。当然创业公司画饼在所难免,但一会儿画个五仁,一会儿画个粽子,过一会儿又说这是个包子,执行层面多少有些无所适从和心生疑虑。B公司作为一个新创公司,地点也很偏僻,但由于技术的先进性其实吸引力不少高质量人才,但因为上述原因,人员流动率相当高。

       

     --内部的派系之争:窃以为一个小公司还有政治斗争的话简直就是致命伤(叹口气,唉~人和人坦诚相处怎么那么难),出走了一个也是国外回来的工程技术专家和几个经理,留下来甚至上升的人也不乏尸位素餐者。 高层领导互相排挤,中层领导要琢磨怎么排队,花在正经事上的精力当然要打折扣。   


     --技术瓶颈:技术目标就是kindle所使用的E-ink电子纸,一直在追赶,总是有差距,比如白度、反应时间。白度差异可以这么理解:看A4纸的感受和看报纸的感受——当然我们是接近报纸的那个;反应速度体现在翻页时,电纸书在静止页面是不会像LED屏幕一样刷新的,但翻页时需要通电移动墨水中的黑白粒子重新排列,0.3s和0.5s感受起来差别是很大的。总之电子墨水研发进度严重不达预期。  


     我们公司的问题: 

     --同样对项目定位不清楚:B公司当然是将重要性放在第一位,但我们公司就不一样了,因为这只是我们的一个小项目而已,还是特别事儿的一个小项目。但是由于总经理对这个项目比较支持,大家更多是表面上认真配合的。B公司认为我们是拿他们钱替他们干事,但我们觉得我们也投入并亏了好多老本我们应该是对等合作——所以不知道该以什么样的态度对B公司的各种合理及不合理要求。举个我自己的栗子,因为B公司安插实验导致我们自己的常规产品生产经常被打乱,所以有段时间我被自己部门老大忽悠要对B公司强硬点,我就给他们提了一大堆要求,说如果你们不怎样怎样我们很难协调生产时间,以后能不能按照我们的生产计划来,毕竟我们部门还有常规生产,不能老是被你们打乱Blabla…然后这封邮件被转发给我们总经理,总经理亲自给我发邮件让我尽量配合之类(好吧我承认我现在想来觉得当时自己蛮2的)。

       

     --部门经理对项目支持态度不一:有一段时间公司董事办的一名经理觉得我们部门不够关心这个项目,让我直接向他汇报情况,可我们部门老大很不高兴啊,然后各种向总经理表忠心说自己如何如何支持这个项目。再后来部门老大换掉,新老大丝毫不掩饰自己不喜欢这个项目,连表面功夫都不想做了,直接跟我说我觉得这个项目前景不好,要不我把你调回来你帮我们搞常规产品工艺你觉得怎么样…结果后来总经理又在高层会议上跟他强调哎呀电纸书这个项目还是很有前景的你要好好支持啊,所以他又不敢有所行动。

       

     --批量生产屏幕时质量不稳定: 这个有多方面原因,配方的、生产工艺的、设备的、品控的。比如配方经常变动导致生产工艺需要跟着变动;核心设备是一条被我们公司淘汰了的生产线很不稳定;一周大概只有两天生产,其他时间员工被分流导致没有熟练生产人员;品质监控不到位等等等等。主要导致的就是屏幕质量不一致,不良率高,切割困难。经常出现的情况是屏幕合格率只有30%。  


     5、我离开之后的情况 

     --电子纸销量继续维持要死不活的状态。B公司掌控着销售渠道,在德国有代理商,所以很大部分(其实也不大)销往欧洲。2013年这个德国的代理商被E-ink起诉侵犯专利权,然后各种反起诉扯皮,到现在似乎也没扯出结果来。   

    --B公司也在继续进行各种类生产试验提高产品性能。但和我的前公司合作已经处于互不信任的状态(好吧,我离开之前就互不信任了)。产品质量进展据我估计应该是蛮缓慢了。  

     --今年B公司又和江西的一个下游制造企业C公司签订了战略合作协议,说要把客户全部转给C公司,由C公司负责销售渠道,B公司专心致志搞研发。据我不客观的估计,又是忽悠了C公司一笔钱吧。  


    6、我的反省

    展开全文
  • 团队拓展训练活动总结 团队拓展训练活动总结 上周末我有幸参加了为期两天的团队拓展培训——场智慧与体能培训。听到过你会忘记,看到过你会渐渐淡忘,只有亲身体验过才会铭记在心,两天训练不...
  • 从缺乏产品与市场的相配到团队成员的不和,通过分析101创业失败案例,我们总结了创业失败的前20大原因。 在我们列出创业失败案例清单后,我们收到最频繁的请求之是我们能否从这些失败案例中提取出他们创业失败的...


    0?wx_fmt=jpeg


    从缺乏产品与市场的相配到团队成员的不和,通过分析101个创业失败案例,我们总结了创业失败的前20大原因。

    在我们列出创业失败案例清单后,我们收到最频繁的请求之一是我们能否从这些失败案例中提取出他们创业失败的原因。创业者、投资者、经济发展人员、学者和企业都希望对这个问题有所了解:


    有没有一些主要原因导致创业失败呢?

    所以我们给那些创业失败公司进行CB Insights(CB Insights是一家风险投资数据公司,会定期发布如按需经济之类的经济发展趋势以及独角兽公司的名单。)的数据分析,来看看我们是否可以回答这个问题。同时,在我们逐个分析这101个初创失败的案例后,我们了解到两点。第一、一个创业公司因单个原因而失败的情况很少;第二、在这些案例中,失败的原因多种多样。

    经过从中筛选,我们得出他们失败的20个最主要原因。

    因为很多创业公司有着多个失败原因,你会发现这突出的20大创业失败原因比例加起来不是100%(远超过100%)。下面的图表是对相关案例和每个原因的说明。

    这里当然没有幸存者偏见(一种认知偏差。其逻辑谬误表现为过分关注于目前人或物“幸存了某些经历”然而往往忽略了不在视界内或无法幸存这些事件的人或物。其谬论形式为:幸存过程B的个体A有特性C,因此任何个体幸存过程B需要有特性C。有特性C但无法幸存过程B的个体被忽略不加以讨论。)。但对于创业生态系统中的任何人来说,这里提供了很多相关的经验教训。

    值得注意的是,如果那些创始人没有足够的勇气分享他们创业失败的故事, 就不会有这次的数据分析。所以非常感激他们。


    0?wx_fmt=png


    第20名:必要时没有成功转型

    不能从一个坏产品、糟糕的雇佣或者糟糕的决定中足够快转型或者改变,被这些公司里的7%选为失败的一个原因。倾注在一个不好的点子上,不仅会消耗资源和金钱,也会使员工因没有进展而感到沮丧。正如Keith Nowak在Imercive的案例中写道:

    “我们被困在转型的半途中——在一个我们知道不会起作用的战略和一个我们相信会成功但难以被积极追求到的目标的中间。。这是一个对公司和个人而言都非常困难的地方。我们极度的沮丧,因为不能正确地执行我们的新战略,一天天过去却没有取得有意义的进展,这是接近我们公司失败的第一步。即使我们已经将我们所有的一切投入来度过这个时期,但是我们最终还是没有跨过这个坎。”


    第19名:劳累过度

    创业者常常不能做到工作生活相平衡,所以劳累过度的风险很高。劳累过度占了8%。在必要  时候减少损失 以及 当你看到一个死胡同  时重新调整精力投入的方向并且避免过度疲劳  被认为是获得成功的一种重要能力。 同样的,有一个坚实的,多样化的和奋发图强的团队也很重要,这样的责任可以被分担 。 对Blurtt案例的分析,让我们看到疲劳对初创公司发展势头的影响。


    第18名:不能够利用好自己的关系网和社交圈子

    我们时常听到创业者抱怨他们缺少网络或者投资者的联系,而我们去惊讶地发现创业失败的一个原因却是初创者没有适当利用好他们的人际圈子。正如Kiko写的那样:“让你的投资者参与进来。你的投资者随时准备帮助你。一开始就让他们加入,不要害怕向他们寻求帮助。我觉得我们一开始就犯了什么事都自己干的错误,可能是出于对商业世界如此陌生而感到不安全所致。但是这是错误的。


    第17名:法律的挑战

    有时候初创企业可以从一个简单个体发展到一个充满法律复杂性问题的公司,这可能被证明是创业失败的一个核心原因。正如Decide.com在他的案例分析中写道那样,“我们接到通知,他们说我们是不合法,除非删除它,否则他们将暂停我们的子公司帐户。我们没有赚很多钱,但那个账户可能占了公司超过80%的利润。”

    一些音乐类初创公司会有因为处理唱片公司问题和法律难题而产生的高昂成本,而这是初创公司失败的一个原因。高调创业的Turntable.fm写道,“基本上,我没有吸取很多音乐创业失败的教训。音乐类创业是一个极度昂贵的投机行为,音乐工业本身也是很难从事的行业。。我们把超过四分之一的钱都花在了律师费、版税以及和音乐支持相关的服务上。这对我们是限制性的。我们不得不停止我们的成长,因为我们无法国际化。”


    第16名:没有融资或者感兴趣的投资者

    许多创业者明确地指出,在种子跟进阶段或者整个过程里缺少投资者的兴趣,是与一个更常见的失败原因——没钱——相联系的。


    第15名:地理位置

    地点是一个问题,体现在几个不同方面。首先,你的初创公司的概念和位置必须有一致性。Meetro写道,“我们推出了我们的产品,并且动员了我们在芝加哥的所有朋友。。然后,该地区最大的几份报纸都为我们做了漂亮和细致的报道。事情进行得很顺利……但我们很快就发现了问题:在芝加哥有数百个活跃的用户不意味着你在不到一百英里的密尔沃基有两个活跃用户,更不用说在纽约或者旧金山了。软件和概念并没有扩展到它的物理边界之外。”

    位置在远程团队的失败上也扮演了重要角色。关键是,如果你的团队是远程工作,那你要确保找到有效的沟通方法;否则缺乏团队合作和规划可能导致失败。就像Devver写道的,“远程团队的一个最显著劣势就是管理的困难。在一个州,管理工资、失业、保险等是一种痛苦。对于一个小团队来说,这是主要的烦恼和分心。”


    第14名:缺乏热情和领域专长

    世界上有很多很好的想法,但是有9%的失败了的初创公司创始人发现,对一个领域缺乏热情和专业知识是创业失败中很重要的原因,无论你的想法多么好。他们当中,NewsTilt 坦白地说,他们对自己选择的领域缺乏兴趣。他写道:

    “说我们没有真正的关心新闻学,我觉得是很公正的。我期望有一个完美的博客评论系统,出于这一点我们便开始创建一款评论产品。这变成了设计有史以来最好的评论系统,而这又让我们琢磨出一个理想的客户:报纸。虽然我认为他们永远不会购买,我们还是想出了一个产品,如果它存在的话人们会渴望使用。

    但我们并不是真的关心新闻学,甚至不是热心的新闻读者。如果我们每天做的第一件事是跑去news.bbc.co.uk看看,我们应该已经做出这个产品了。但是甚至当我们有了NewsTilt的时候,那也不是让我感到开心的去处,我浏览的依然是黑客新闻和Reddit。所以我们怎么可能创建出一个只从商业角度感兴趣的产品呢?”


    第13名:转型后变得更糟

    像Burbn转向Instagram,或者The Point转向Groupon那样的转型可以走得非常顺利。亦或这些转型是通向一条错误的道路的开始。正如Flowtab在他的失败案例中解释的那样,“为转型而转型是毫无价值的。它应该是一件被计算的事:商业模式改变的制定,假设的验证,以及结果的测量。否则,你什么也学不到。”


    第12名:与投资者或者合伙人不和

    对初创失败的公司来说,与合伙人不和是一个致命的问题。但这种尖锐的矛盾不只限于创办公司的团队,当与投资者闹起来,事情会很快变糟,就如同在ArsDigital案例中证实的那样。Phillip Greenspun写道:

    “在约一年的时间里Peter Bloom,Chip Hazard以及Allen Shaheen(CEO)在ArsDigita公司里面握有绝对权力。在这一年期间,他们

    1. 花费两千万美元使公司重返与我担任CEO时一样的利润

    2. 拒绝微软提出的(2000年夏)成为第一家拥有.NET产品的软件公司的建议(一个微软员工和Allen从一个后续会议回来说:“他让我想起来很多我们曾经合作过的公司CEO……他们已经破产了。”

    3. 在完成新产品(ACS 4.x)之前废弃了旧的但功能完整的产品(ACS 3.4);要知道这是一个在软件产品经验丰富的人中众所周知的杀死一个公司的方法;Informix自毁,因为人们不清楚是运行版本7还是新的花哨的版本9,所以人们转而去使用Oracle了

    4. 设计了一个成本高得多的结构; 我有80个员工的基本工资低于10万美元,并为我带来每年高达2000万美元的利润。Greylock,General Atlantic和Allen的ArsDigita有近200个新的经理职位,每个职位的年薪在20万美元以上,另外程序员的基本工资是125,000美元等等。这种高成本结构是由周一到周五朝九晚五的新工作文化造成的。Allen, Greylock, 和General Atlantic在周末不会走进公司的大楼,员工当然也不会。

    5.  放弃了市场领导和思想领导”


    第11名:失去焦点

    失败案例的百分之十三都可以归因于被令人分心的项目、个人问题,或者其他分散注意力的事情影响。 正如MyFavorites在他们的创业经验的结尾写道的,“最终当我们从SXSW回来,我们都开始失去兴趣,团队都在想,这最终会走向何方,并且我在想,我到底要不要运营一家有投资人、对雇员负责,并向投资人董事会报告的初创公司。


    第10名:在错误的时间发布产品

    如果你太早地发布你的产品,用户的评语可能会写得不够好,并且如果他们对你的第一印象是消极的,让他们回来是很难的。如果你发布产品太迟了,你可能错过了在市场上的机会。正如一名Calxeda员工所说:“在[Calxeda]的案例中,我们技术的更新速度超过了客户的适应速度。我们对技术的革新并非真正为了满足客户需要而准备的- 即,当他们想要64位的时候,我们提供32位。–我们在操作系统环境还在被完善的时候继续前行着— [Ubuntu Linux制造商] Canonical是正确的,但红帽在哪里?我们还是太早发布产品了。(译者注Red Hat(红帽)公司(NYSE:RHT)是一家开源解决方案供应商,也是标准普尔500指数成员。红帽公司为诸多重要IT技术如操作系统、存储、中间件、虚拟化和云计算提供关键任务的软件与服务。)


    第9名:不灵活,不积极寻求客户反馈

    对用户的忽视确实会导致失败。目光短浅和不收集用户反馈是大多数初创公司的致命错误。例如,eCrowds——一家网络内容管理系统公司——说:“我们花费了太多时间为自己构建,而没有从潜在客户那里搜集反馈 – 这很容易导致视野狭隘。我会建议从开始到掌握真正的目标客户所用时间不要超过二或三个月。

    类似地,VoterTide写道,“我们没有花足够的时间与客户交谈,并推出了我认为是很棒的功能,但我们没有收集足够的客户信息。当我们意识到的时候已经为时已晚 。人们总是很容易被骗,认为自己的产品很棒 。你必须关注你的客户并适应他们的需求。


    第8名:不良的营销

    成功企业最重要的技能之一是了解目标顾客,知道如何获得他们的关注,并将他们转化为潜在客户和最终客户。产品能否被推向市场和公司创建人有紧密的关系。喜欢写代码或创造产品,但对产品推广不感兴趣的公司创建人,往往导致营销的无力。营销无力作为创业失败的原因在这些案例中占了14%。

    正如Overto所写,“决定互联网服务生死的决定因素是用户的数量。对于最初的一段时间,用户数量会系统性地增长。然后我们会触碰到我们可以达到的最高限度。到了该做市场营销的时候了。不幸的是,我们中没有一个人在这方面擅长。更糟糕的是,没有人有足够的时间来弥补差距。如果我们处理上述问题,这将是另一个需要我们克服的阻碍。


    第7名:有了产品,现在我只需商业模式

    失败的创始人似乎都同意商业模式是重要的——固执于一个单一的渠道或者无法找到赚大钱的方法,会使投资者变得犹豫,使得创始人无法利用获得的每个机会。正如Tutorspree写道:“虽然Tutorspree实现了很多,但是我们没能创建一个可扩展的业务......Tutorspree没有扩展,因为我们依赖单一渠道,而那渠道又迅速和突然地从我们这儿转移了。 SEO从一开始就融入我们的模型,随着我们的成长和发展,它对业务变得越来越重要。在我们的早期,在Y Combinator期间,我们没有钱收购。 SEO是免费的,所以我们专注于它,并熟练使用。(译者注SEO是由英文Search Engine Optimization缩写而来,中文意译为“搜索引擎优化)(译者注Y Combinator成立于2005年,是美国著名创业孵化器,Y Combinator扶持初创企业并为其提供创业指南。)


    第6名:“用户不友好”产品

    无论是有意还是无意,当你忽略用户需求时坏事就会发生。关于他们的产品UI,Game Layers这样写道:“归根到底,我相信PMOG(Passively Multiplayer Online Game)缺少太多核心的游戏冲动去驱使狂热的大规模的采用。 ‘ 留下有趣的网络注释的痕迹 ’的概念对于大多数人来说太深奥以至于无法接受。回头看,我相信我们需要准备好自己,放下身段,做一些让玩家在最初接触到游戏的时候觉得更容易玩的东西。(译者注UI即User Interface(用户界面)的简称。泛指用户的操作界面,UI设计主要指界面的样式,美观程度。)


    第5名:定价/成本问题

    定价是一种黑暗艺术,当谈到创业的成败时,更突显了在一个公司特定成本的背景下通过对产品适当定价来赚钱的难度。 Delight IO 从几个方面看到了这种挣扎,他们写道:

    “我们最昂贵的月套餐是300美元。流失的客户没有抱怨过价格。我们只是没有达到他们的期望。我们原来按照记录量来定价。由于我们的客户无法控制视频记录的数量,大多数用户在使用记录量时非常谨慎。订阅量显示,依据视频记录总长度来定价对我们更有意义。(Delight IO帮助软件开发人员采集用户的iOS app使用数据。反馈记录会以手机屏幕视频的形式保存,方便开发者更加直观地了解用户使用软件的方式,从而有针对性地改进他们的软件。)


    第4 名:被竞争出局

    尽管过去的老生常谈告诉初创企业不应该把注意力放在竞争上,但现实是,一旦一个想法变火或被市场认可,可能很快会有新企业加入进来。虽然痴迷于竞争是不明智的, 但忽视竞争也是我们案例中19%的初创企业失败的原因。Wesabe的Mark Hedland在事后的分析中谈到了这一点:

    “在更差的数据聚合方法和Wesabe让你做更多的工作量之间,使用Mint会更容易获得好的体验,并且这个获得过程会更快。我提到的一切 —— 不依赖于单一的资源提供商,保护用户的隐私,帮助用户在金融生活做出积极改变  —— 所有这些都是我们追求我们想要的的合理理由。但是如果产品不好用,上面提到的这些都是白搭。


    第3名:不合适的团队

    拥有一个具有不同技能的多样化团队常被认为对创业公司的成功至关重要。失败的企业经常哀叹,“我希望我们从一开始就有一个首席技术官,或者希望创业公司有一个“喜爱研究商业的创始人”。Standout Jobs在他们的事后分析中写道:“...创始团队无法独立开发自己的最小化可行产品(MVP: Minimum Viable Product,开发产品时先做出一个简单的原型来快速检验你的产品或方向是否可行。如果可行,快速迭代,不断修正产品,最终适应市场的需求。)。这是一个错误的认识。如果创始团队不能自己(或利用少量来自自由职业者的外部帮助)推出产品,就不应该创办一家初创公司。我们本来可以让更多的联合创始人加入,这部分人的薪酬可以以股权的方式支付,但我们却没有这么做。

    在一些案例中,创始团队希望他们有更多的制衡。正如Nouncers创始人写道的,“这把我带回到一个根本问题面前,就是我没有一个伙伴来制衡我,并为业务和技术决策提供健全的检查。”


    第2名:耗空财政

    有限的金钱和时间需要被合理分配 。如何使用你手头的钱是一个被经常问起的难题,也是初创公司失败的一个原因(29%)。正如Flud的团队所言,耗尽现金往往与其他原因一起导致初创公司在产品市场匹配和企业转型上的失败 ,“事实上,最终杀死Flud的是它无法筹集这笔额外的资金。尽管在追求永远难以捉摸的产品市场匹配(和货币化)的过程中有多种方法,Flud最终还是耗光了资金,败亡了。


    第1名:构建问题解决方案,不都是瞄准需求

    解决有趣的问题而不是能服务市场需求的问题,被42%的案例列为失败的首要原因。正如Patient Communicator写道:“我意识到,基本上,我们没有客户,因为没有人真的对我们搭建的模型感兴趣。医生想要更多的病人,而不是高效的诊所。” Treehouse Logic在他们的分析报告中展开来谈这个概念, “当初创公司没有解决市场问题时,他们就失败了。我们没有解决一个足够大的可以普遍服务于一个可扩展的解决方案的问题。我们有很好的技术,有关于购物行为的很棒的数据,有作为领导者的声望,有专业知识,有好的顾问等等,但我们没有的是能以一种可延伸的方式解决一个痛点的技术或商业模型。

    原文发布时间为:2017-04-16

    本文来自云栖社区合作伙伴“大数据文摘”,了解相关信息可以关注“BigDataDigest”微信公众号

    展开全文
  • 团队拓展训练总结.doc

    2021-01-15 17:22:22
    记得最开始体验这个项目时候我们用时接近7秒,当我们完成了5秒目标之后,教练问我们下一个目标是多少,我们意见出现了分歧,有人说3秒有人说4秒。当时我支持是4秒,觉得3秒钟不可能、想都不敢想。可在我们一...
  • 团队拓展培训总结.doc

    2020-12-27 11:55:43
     一、信任队友,相互协作 勇攀天梯这个项目一个人而言,心态比技能更重要,另外,二个人高空合作体验是一种真正意义上信任——把自己(身体重心)完全交给对方!惟有如此,才能找到整体平衡点。同时,两...
  • 这些失败的根源可以追溯到项目组织与项目目标、项目任务、高层管理部门以及更大的环境之间的不适当的"配合".它们包括使用对于项目目标和项目环境来说不正确的项目管理方法或模型,以及缺乏高层管理部门项目的支持等...
  • 版本发布失败总结

    2012-07-04 16:36:00
    1.团队对版本发布成功/失败的定义 1.1. 成功发布的依赖因素 1.1.1.明确的交付(范围)定义 对于每一个迭代Iteration,团队的每一位成员都需要清晰的知道,我们这一次迭代的目标是什么,即我们的Iteration Goal,...
  • 方法【把目标变为现实所要采取的措施】赠送格言句:如果你的眼前浮现失败的影子,成功变不会向你微笑。只有相信自己会成功,明确成功会带给我们哪些想要的东西,想尽一切办法克服一切困难一往无前的向前冲! ...
  • 团队Team人数超过7人,在经历Sprint过程发现团队人数最佳人数是5-6人,一旦到达7个人就有些臃肿和拖沓,机动性降低,PlanningMeeting 和ScrumReview就会时间过长,每天立会也是时间过长,并且对团队的积极...
  • 幼儿园十一月份教学工作总结 十一月份工作已经结束,回顾这一个工作,感受很多,欣喜更多,现个人工作总结报告如下: 一、同事间和谐相处,注重团队精神 班内教师之间配合是否和谐直接关系到班级管理...
  • 2015年第季度总结

    2015-05-19 16:04:26
    先扇自己一个耳光。 2015年第一季度我来说,只有两个字:失败。 整整3个月,自己工作状态尤其差。客观环境的确自己影响很大,新加入环境,新同事,新的团队。尤其是我们属于创业型团队,大家都在摸...
  • 学生会活动后的总结报告 学生会开展活动过程中出现了很多新的问题,如何提高高校学生会的活动质量,是高校建设过程中要解决的一个重要问题。学生会活动如何更加丰富多彩,今天小编给大家整理了学生会活动后的总结...
  • 电话销售工作总结怎么写 服务队最高境地就是顾客不断主动转介绍。... 一直以来,电话营销都是我所坚持在做,记得年初所有人都已经搬到庆春路营业部了,唯有我们团队还在青春坊奋斗,经过一个寒冷冬天,...
  • 经过教练的总结和引导,以前一些模糊的概念有了清晰的认识。通过素质拓展培训,不论是在团队意识还是团队工作能力都取得了一定的进步,为自己今后的工作和学习打下了良好的基础。 团队精神 团队精神的概念在...
  • 关于技校社会实践部工作总结...所以在工作中,我学会了与别人进行合作,相互配合去完成,在学生会社会实践部里我学到了很多东西这我来说也是一个很大收获. 现在此将本学期工作中收获与不足总结如下: ...
  • 为什么谈这个 ...该节目是一个团队竞争的节目,失败的团队要进行反思,往往也是会陷入上述氛围中,但是其中有一期马云作为观察员,失败团队的反思进行点评,但是他并没有就失利的细节做指导,只说了
  • 销售转正工作总结5篇精选2020 在此,我深刻体会到了汇瑞这个团队从老板到同事踏实认真工作态度,共同以颗积极向上心态来迎接每挑战,也正是这个时刻提醒着我自己,要把每工作做好。今天小编就给...
  •  再从细节体验收获,岗位体验——淘宝商城编辑与美工,本来是一个零经验应届生,现在 于店铺装修、广告图、宝贝页面等等制作都有了一定经验,但是进步空间还很大,仍需继续 努力!我是属于完美主义型,...
  • 团队获奖感言范文4篇 *目录... 在这个充满凝聚力的团队里,有认真负责晶晶,她总是给人一种力量存在,是我们团队的主心骨,每月都会制定一个合理销售计划,然后分阶段分析总结,如何努力在实际工作中完成...
  • 在这个充满凝聚力的团队里,有认真负责晶晶,她总是给人一种力量存在,是我们团队的主心骨,每月都会制定一个合理销售计划,然后分阶段分析总结,如何努力在实际工作中完成这一目标,寻找最好方法;...
  •  在这个充满凝聚力的团队里,有认真负责晶晶,她总是给人一种力量存在,是我们团队的主心骨,每月都会制定一个合理销售计划,然后分阶段分析总结,如何努力在实际工作中完成这一目标,寻找最好方法;...
  • 作为以老版本为模子重做解耦版本...架构审视,选型和设计反思,不仅仅要在产品初创时期,更要在产品发展整个过程中进行,团队做同类型产品能力就是这样在不断总结和自我批评中成熟。以下为个人观点,难
  • 服装营业员年底工作总结模板 自从进入公司,不知不觉中,半年时间一晃就过去了,在这段时间里,我从一个对该行业产品知识一无所知新人开始慢慢熟悉,完成了角色转换,同时也开始慢慢融入到了这一个集体,...
  • 来到一个工作环境,最能发现自身不足,这几个月,抱着虚心学习态度,学习公司开发流程,熟悉公司企业文化,了解公司产品框架,主要技术,主动和同事沟通、学习经验,希望能更快融入公司、融入开发团队...
  • 来到一个工作环境,最能发现自身不足,这几个月,抱着虚心学习态度,学习公司开发流程,熟悉公司企业文化,了解公司产品框架,主要技术,主动和同事沟通、学习经验,希望能更快融入公司、融入开发团队...

空空如也

空空如也

1 2 3 4 5 ... 7
收藏数 133
精华内容 53
关键字:

对一个团队失败的总结