CMDN第二十一阶段于10月11日在拉福特大厦酒店举行，活动将集中于移动客户外包项目管理。Atotel技术总监黄志浩将应邀提交项目管理、测试标准流程和相关工具、APP的连续集成以及来自先前APP需求研究和报价原则的多通道提交、APP UEUI设计过程、APP dev开发过程规划和项目实施管理，APP测试标准过程和相关工具，APP持续集成和多通道提交。与您分享Atom开发团队在产品跟踪方面的移动APP标准化生产过程实践迭代。
黄志豪：今天我想和大家分享一下我们公司在外包方面的管理经验。任何项目管理经验都与每个公司的背景有关。每个公司都有自己的背景，所以在管理方法上有些不同。首先，我想介绍一下我们公司的背景，以便您了解我们为什么要这样做。
我们公司致力于移动互联网的外包。该应用开发平台包括iphone、Android、WP7以及从实现过程、从设计、到UE、UI设计、到开发和测试、到在线迭代、以及后续的维护。
首先，第一点是为什么需要项目管理，这个话题很空洞，我们也想到这个问题，当然，这里的答案是众所周知的，非常明显。
自古以来做任何项目的第一件也是更重要的事就是监督，起到了监督作用，人们起初，懒惰的性质，有点悲观，但事实上它是。没有监督，其实每个人都有惰性，作为一个开发商，头三天是不要着急，认为还有时间，前几天开始赶时间，肯定是结果不令人满意。所以从这个角度来看，我想我们必须避免一个问题，那就是，上司不能做人，所以这个责任应该分开。给自己鞭子的人很难找到。
第二点是，检查者不是检查者。因为不知道庐山真相的人，他们只在山里。包括测试，如果测试一个项目很长时间他就看不见问题，所以我们经常有很多公共用户说，看到直接看一下产品，可能会发现一些问题，觉得产品很糟糕。其实并不是，为什么需要大量的用户进行测试，是因为大家一眼就能发现更多的问题，所以它需要这个过程。接受团队测试，而不是一个人的测试。这是为了确保项目的质量，所以我们需要做检查。
第三是制定计划。像我刚才讨论的计划一样，我认为必须从我的角度来完成。也许在项目开始阶段，包括计划阶段，必须有需求分析，根据业务价值做优先考虑，像李宁所说的项目是落后的项目，他崩溃的时间点不能移动，我们应该根据以前的优先级要求在1.0版或1.1版中不能替换，这就定义了功能需求，哪些功能需求应该在任何时间点确定，所以规划是确定的。如果马拉松比赛看不见，他将效率较低。
沟通是非常重要的一点，在做项目的过程中，这种需求的变化，设计的变化，我们公司已经实施了数百个客户，其中大多数已经改变，基本上没有改变。从这个角度来看，沟通是非常重要的一点。有一个项目经理做沟通，依靠程序员进行沟通，程序员比较宅，整天面对二元，他的沟通能力还是值得考虑的，所以应该有一个专门的项目经理来沟通。
而且我们需要及时地沟通，比如依赖我们对界面的依赖和设计的依赖。沟通的过程加快了项目的进度。与上司沟通是项目经理经常被忽视的一点，你不想与上司沟通，当有问题要找他时，他通常不知道，此时你在乎他需要什么资源，他会很努力的。很高兴给你这肯定是有问题的，但通常情况下，当项目进展顺利时，你会和他沟通。他认为你真的需要帮助，当他认为你以前见过进步，所以他认为你努力工作。这是一个真正的问题。他会伸出援助之手，所以他永远不会和老板沟通，这是可以忽略的。
如果一个开发工程师既负责通信和计划，也负责开发和测试，包括各种在线测试，那么他就要么非常昂贵，要么很难找到。补充，可以降低职位的门槛，降低人员流动的风险。
我想强调的是时间永远不够，资源永远不够。我想谈谈心理问题，因为很多项目经理都愿意抱怨时间不够，人员不够。通过这样做，你可以充分反映你的管理价值，你可以协调各种资源，而不仅仅是抱怨，你可以通过以下方式降低成本管理解决方案。
这是我们公司的组织结构。这个结构没有什么特别的，只要展示一下就可以了，但是其中的每个公司可能不会有太大的不同。我们公司的结构由智力划分，比如IOS团队、Android团队、测试团队、设计团队和专业技术顾问。项目经理是一个池概念，池是一群项目经理，具有项目经理的能力，到一个新的项目，从这个池中找到合适的项目经理来做，下面的人就像高级IOS开发工程师，一旦他合作互相沟通。如果你能达到项目经理的水平，你就可以晋升到项目经理。作为项目经理或助理项目经理，有属于绩效的职位津贴，不在今天讨论的范围内。Reject Manager资源，项目经理可以并行管理项目多一点。
建筑群，像这一个，有一个建筑师的分支的程序员的开发线。建筑师主要是解决一些难题，然后从分散到集中。然后，有必要集中一个人对项目的总体把握，以便他能够做出更有效的决策。
下一步就是实现过程，首先是需求与报价，然后是设计，然后是开发、测试、持续集成、更新迭代，这是传统的瀑布式开发过程。
首先，在这个阶段的需求调研中，作为承包商的需求得到完美的程度是不一样的，有时只是得到一个基本的想法，比如客户的领导总是说我们想做彩票的客户已经走了，所以剩下的就想了。这是一个需求。更详细的是，您可能给出一个功能框架，可能以脑图的形式给出，或者在TST之前给出一个基本模块的一些名称，并且可能涉及更详细的描述，例如风险、集合，它们将为您计划。下一步是UE和UN设计，这是真正投入开发的。
在需求沟通的这个阶段，我们需要挖掘客户的真实想法。有时我认为我们应该在日常生活中有这样的经历。有时顾客无法表达他真正想要的东西。你们中的许多人能够理解他的真实想法并通过不断的沟通来引导他。
只给出一个IDEA或一个功能框架的产品解决方案需要产品经理的参与来精炼产品。虽然我们公司不生产产品，但是也有自己的产品经理，就是做这个项目。一个非常详细的功能，相当于帮助客户免费完成产品。如果你非常重视客户，会给他一些免费的UE、UI设计，然后还有一些款式草稿。
需求契合，无论是从用户的角度还是从客户的角度，精神上讲，50：50%每半，这样既能满足实际用户的更终需求，又能接近该客户。
你提出的解决方案需要再次沟通，引导他依靠你的想法，倾听他的意见，调整并优先考虑相反的方法。相关的工具在下面列出，每个人都可以使用，比如脑图，这个产品的原始设计工具，设计师的PS等等。
需求完成，然后报价开始。报价是根据工作量来评估的。对公司来说应该是一样的。报价应通过人日报价。尤其要重视设计，更终将设计者的能力转化为自己的产品，在市场上具有竞争力，如何将外包设计者的能力转化为实际收入你越需要设计和创造力，你就越需要增加。你不能简单地计算工作量。
沟通是一块你重视客户的短期或长期，给多少折扣，有没有风险，如果客户给的时间太短，你需要看到需求，否则你不能杀，然后不能说。
这个工具没有什么特别之处。这篇文章强调我们公司有一个特别有趣的Excel脚本。它里面有一些红色。你可以通过计算工作量来计算成本。成本包括人员、设计、租金等，EXCEL在报价过程中可以减少大量的工作，因此非常有用。
报价结束了，如果你收到项目。恭喜你，你进入了设计阶段。有些项目可能由客户完成，UI设计会跳过这一步，我们公司一般都有设计步骤，设计过程是这样的，需求沟通，到交互式设计，到样式表、UI设计，要完成，公司原有的设计是没有UE交互设计的，所以会产生一些问题，如果你想直接分工，比如，一些问题返工这个工作量很大，所以UE的交互方式通信。
UE的分工很重要，UE也需要更好的产品经理来介入，设计师做产品时更注重美观、优化和过程，产品经理注重功能表现，海业界面的要素，注重主次关系，使用户一眼就能看出您更重要的功能，而不是一眼就看出您凌乱、糟糕、不多，并且用户不知道点对点，因此有一个更好的产品经理可以输入产品并从产品中进行控制。
花样草稿很重要。样式草案是固定的。以后的工作做得更好。这只是工作量的问题。风格手稿要做一页、两页、三页，或者一个版本、两个版本、三个版本，根据资源情况和客户要求来确定。每个阶段都需要沟通，这个沟通很重要，每个阶段都应该与客户沟通，使问题尽早发现，调整，修改风格。
设计完成后，我们进入开发过程，就像这是我们的发展计划。这个开发计划是粗略的、更全面的计划，因为我们公司已经从今年开始的新项目转移到了敏捷地管理它们，所以今天有更详细的计划，但是很粗略。当你把它发送给用户和客户时，给他们一个粗略的计划，看看项目要去哪里，哪里有时间，哪里有工作，每周更新已经完成的工作，然后如果不能按时完成，写个便条，为什么没有完成。还有补救方案。
在做这个计划时，我们必须注意它的实施和全面性，比如第一个，项目启动，完整的需求沟通，对接，这是做项目的时候，我们不考虑很多项目，第一个是做UI开发，所以这些工作还是这样做，更终会遇到延迟，缺乏可执行性。
还有一个国庆节假期也在计划中，这个缺少一些管理经验的项目经理往往忘记了度假的事情，其实像一个星期很长，如果忘记了，顾客不会为此耽误你的时间，然后他问你然后那次。T，你然后一周休假，开发商抱怨周末加班，以弥补。
相关的工具还有EXCEL、PROIECTS、EVEMOTE、JIRA，为什么使用EVEMOTE，就是程序员可以看到自己的变化。此图是一个带有EVEMOTE的标签，通过该标签可以快速筛选，您可以看到负责哪个项目的项目经理，可以直接看到项目，包括-行，在开发中，暂停，测试每个状态可以快速筛选，我认为这是非常有用的。您可以使用其他共享工具，但现在我发现这是更好的。
另外，在开发过程中，技术部分，首先，技术积累，做外包的过程，一定有一些类似的事情，这块肯定是你积累了自己的基本框架，常用的控件和功能。好处是显而易见的。如果除去底层框架，框架维护人员非常有经验，并且未来项目实现的实际业务代码非常简单，因此增加了人员流动的风险。D过好，因为真正的基础设施将解决真正的适应性和稳定性80%。
代码规范也是为此准备的，也就是说，大家协同开发，如果现在项目不见了，需要填写，时间压缩，如果有相同的代码规范，大家都很擅长，我们公司现在的开发人员都是在项目中随便看看由于代码的统一框架和统一的代码规范，代码可以很快地启动。
本组专家在解决问题的过程中，做一些代码评审，维护公司框架，维护代码规范。我们还有技术共享程序来解决问题，并在每周的项目中共同改进经验。博客作者共享代码避免重复的名字。一些公司有小的技能和小的方法。没有必要太小心。
当我们进入测试块时，我们应该首先区分几个测试阶段。测试的不同阶段代表您现在还剩下多少BUG。这个产品能在多大程度上被完善我们计划了AIPHA、BETA、RC、RELEASE四个阶段，测试类型具有功能、界面、体验、性能、容错、兼容性，尤其是做客户端开发项目，兼容性非常重要，尤其是iPhone 5的问世，这一点非常重要。测试之前的ASE，还有一些不需要编写用例的项目。写一个用例的大纲，保证在不到一百篇文章中给出一个模块，并且指导你不要错过一个模块的测试。
涉及的工具有EXCEL管理BUG，更好的放在管理系统中，比如我们公司使用的MANTISBT，还有很多其他的工具我们可以尝试使用。
另一点是，应用程序的持续集成可以通过多个渠道提交。持续集成不知道其他公司正在使用多少应用程序，因此我们公司使用它是非常必要的，这样可以大大降低开发部署打包的成本。这段Jenkins以Android和iPhone而闻名，可以同步代码，可以定期打包，可以每天凌晨3点打包，这样第二天测试人员过来，不必向开发人员索要包，可以直接浏览。ht来部署产品。经理要看直接拿包，老板要看直接拿包，不需要无聊的沟通到什么包，开发人员要经常打包，这是不必要的。
另一个是提交这篇文章，iPhone还行，更多加上一个91，Android有很多市场渠道，我们之前已经提交了数百个渠道，基本上一两天软件包一直在打字，又发生了变化，这几乎是一个变态的任务。这是一个连续的集成解决方案，根本不需要考虑。当我们进行小的更改时，单击一个按钮，所有的包可能具有不同的通道标志，这些标志通过脚本自动更改。更改之后，只剩下一个包裹，然后直接发送出去。它不花那么多钱，人力。
在产品上线之后，它涉及到后续的迭代，并且这个需求肯定会改变。除了正常的产品规划要求之外，竞争产品也带来一些压力，比如竞争产品上有什么新特性，如果你不认为有可能降低竞争力，这是很常见的。您想要的功能，以及必须添加到迭代过程中的领导思想。添加这么多需求需要版本规划和管理，并且每个版本需要几个版本，例如1.1、1.2和1.3，这些版本都有清晰的文档。
另外在外包行业，有一个特点是新增需求不直接做，需要评估它，一般我们公司有六个月的免费维护期，在这个期间改变任何bug是没有问题的，但是新的需求需要考虑是否帮助您免费O这是外包商需要考虑的问题。
以下是关于敏捷开发、敏捷开发的，我昨天听说过一个SCRUM，敏捷这块现在用的SCRUM比较多，关于SCRM模型不多说SCRUM，SCRUM模型还有一些局限性，包括我们继续探索在实际中遇到的一些问题工作如何才能更好地理解决定，主要来自SCRUM的提议者是日本人，日本人做事情在早期需要时间考虑的更加清楚，光需要做半年到一年，在这个过程中，他想想得非常清楚。一个要求通常是做半年，基本上可以看到伪代码，他们做的是切断大块的功能，改变情况很少，但在中国的这种环境下，这是很常见的。一辈子，所以人才的流动性比中国的环境不一样，比这幅要好得多。所以他的局限性一部分来自于他的历史，当然也有很多局限性。当然，现在人们提出了各种敏捷优化的概念来解决它的局限性。我们不能说它有我们不需要的局限性，它有很多优点，我们公司提出了一些核心思想，它认为更好去实施，一些边缘思想可能不会继续下去。我认为更好的办法是找到一个适合你的敏捷方法。这并不是说哪一个更好，哪一个对你更好。我们介绍的核心思想是功能细化和需求通信。在传统的开发中，也许更早的是做一个详细的PRD这个需求文档，以便给你一个清晰的描述，事实上，在agile更加强调您的面对面交流，因此在这一点上，我们非常同意，就像程序员一样，在开始时，应该实际如此。直到后来，一些功能是错误的，然后改变，那么为时已晚。
第二点是根据迭代来计划项目。如果它像功能细化，那么SCRUM模型中就有STORY，如果存在STORY，则可以计划每天要做的工作量。这种努力已被细化到日常水平。他强调每天站立会议，报告每天的进展情况和随后的计划，并在当天提出问题。
第三种是在开发迭代中添加测试链接。测试通常在传统瀑布模型的然后阶段完成，因此在开发期间，您可能暴露了未及时更改的问题，然后在然后进行返工，这有点晚，所以测试通常为建议开发时间非常短，基本一周或两周，比如Android和iPhone，每次迭代一周，每次迭代都完成以测试一周的工作，在敏捷中有一个模块，每个迭代是对于模块的功能，这个测试是一个相对完整的模块测试。如果这个模块太大，你可以毫无问题地将其细分为较小的部分，但是你总是可以找到适合这个迭代的适当大小的模块。
第四点就是主动促进项目进度。有些项目在实施过程中，客户还不知道进度的状况，这种情况不利于沟通，直到你更终发现问题，才为时已晚，所以有必要有主动每周向客户汇报，汇报当天的情况，并将实际合同发送给客户。把真实的东西拿在手里，看看它，玩弄它，客户就会知道你到底要走多远。
第五点就是先做一些简单的功能，然后快速地看到结果。可以快速地看到界面，有的可以从底部开始，说底部已经做得很好，客户看什么都没做，其实应该从我们公司首先从UI开始，首先从皮肤开始，亲情首先美好，内部来补充，这样客户就能清楚地看到你的进步，并且从直觉上感觉你进步很快，感觉非常好。
其他的用途，如配对开发，配对开发，因为开发人员比较孤独做自己的项目，遇到问题他可能会遇到问题，觉得很难解决，他有时可能会放回去，休息一下，喝杯咖啡，去开心网，玩一会儿。这很难，但是经理们看不见，所以如果他们能互相支持和互相监督，那就太好了。当他们这样做的时候，他们可以看到对方的进步，他们很难被超载。
另一个好处是，一个人在这个项目上下班是很常见的。在开发人员的家庭中，有一些事情正在发生，谁生病了，谁生病了，需要休息几天到一周，但是因为敏捷强调每天的进步，独自走路是一个影响比率。过去几天，因为上面提到的技术框架和代码规范从技术的角度来看对他来说是合适的，并且从业务的角度来看，因为它是成对的开发，并且其他人非常熟悉业务，所以他可以带这个人去fa基本上在业务的两个小时内就立即完成业务，所以好处是显而易见的。
二是在整个项目实施过程中，不断沟通，敏捷或强调沟通的重要性，以人为本，强调沟通，所以在实施内部如果不一般在客户中，这主要是通过邮件、电话实现的。沟通。
第三点是项目完成后的项目总结，项目完成后，你通常有一些经验可以和大家分享，避免其他项目出现同样的问题，或者有一些好的地方可以分享。
这个看板和演化图基本上是Scrum的工具。我不知道你是否已经接触过这个。看板非常简单，它是把任务分成几个阶段，有做，有做，有完成，每个标签都有一个函数，这个函数是在标签上完成的，这样直观的就可以看到所有函数在什么进程中，这是对这个迭代的把握。很显然。如果今天星期三，看到前面还有很多问题，一定有问题，你需要调整资源来弥补。像绿色这样的线代表了更完美的发展状态，它是一条直线下降，随着时间的推移，工作量已经做了非常均匀的下降，到头来是零发展状态，已经发展了。这条曲线的实际发展状况有曲折，如果你看到一两天是一条平线，这个项目一定有问题，你必须注意它，及时调整。
这种进化图对于一个公司的管理来说，通常不太关心项目，更适合看进化图，通常一目了然是一个问题，一个项目是没有问题的，可以及时解决。
项目实施中的风险规划和变更、功能要求、设计增加、删除和改变的原则；影响计划的功能要求是的。立即更改。没有下一个迭代或下一个版本。
二是压缩项目时间，当项目进行到一半时，客户老板突然下令压缩两周的时间，压缩三周的时间，这时经常会遇到，所以此时实际上我们没有任何好的解决方案，这块资源基本分配。一些需求删除，注意这个删除对版本管理的要求，配合时间，由于时间已经压缩了这么多，做主要功能，其他功能放在版本1.1中，根据时间点，w。E立即做这些功能，这是一个可以讨论的通信过程。
开发依赖项也有延迟，比如当我们开发客户端和接口链时，尽可能避免并行性，当首先完成依赖项时，当UI设计完成时，当接口完成时，当基本接受没有问题时，然后客户端开发问题是可以避免的。因为如果我们自己的员工时间延长，这是额外的投资成本，但是当然对于生产产品的公司来说，我仍然建议并行，不要把依赖的内容放在前面做，可以并行，这可以加速。修补外包。
然后，开发人员变更（可能在每个公司中都是常见的）就是我刚才提到的那些变更，它们基本上需要一个统一的代码规划框架来解决这个问题。
开发难度是由专家组并行完成的，还有一点是验收的强度，可能后来发现有一个问题是客户接受的时候老板是安卓，他的房间是一个项目下的一个房间的论坛，自己的短信怎么写要做的，但他不得不要求你去适应，在这种情况下，是非常被动的，所以我们必须从适配器模型和系统入手，以及分辨率，如前所述，那个房间真的经过调查后就被抛弃了，即使他们不想要那个版本，在这种情况下也要共用。和他一起吃饭，这个房间的用户容量非常小，不需要安装。
然后，项目经理的更终职责，管理方法其实就是虽然从未实现，但是要无限接近，团队总会有开发人员抱怨各种各样的问题，这是不可避免的，无论开发管理方法有何把握。有这样的问题，在这种情况下，团队文化，激励。竞争制度很重要，我们克服了这些问题。当团队真正陷入困境时，项目经理和管理层应该站出来，并真正采取每个人来解决问题。然后，引用一些话谁曾经说过一段作为总结，战争打得一团糟，高级将领的作用是什么在黑暗中把你的心掏出来，用你自己的光照亮后代，这是你然后的责任。
