├── .gitbook.yaml ├── .gitignore ├── LICENSE ├── README.md ├── SUMMARY.md ├── Translate └── README_EN.md ├── book.json ├── chapter-01 └── ch01_Overview.md ├── chapter-02 └── ch02_Lifecycle-of-a-ML-Project.md ├── chapter-03 └── ch03_ML-Teams.md ├── chapter-04 └── ch04_Product-Manager-Challenge.md ├── chapter-05 └── ch05_Project-Consulting-and-Solutions.md ├── chapter-06 └── ch06_Project-or-Product-Setup.md ├── chapter-07 └── ch07_Data-Collection-Labeling-and-Management.md ├── chapter-08 └── ch08_Training-and-Debugging.md ├── chapter-09 └── ch09_Deployment-and-Testing.md ├── chapter-10 └── ch10_ML-DevOps.md ├── chapter-11 └── ch11_Project-Delivery.md └── res ├── ch01 └── ch01-01.jpg ├── ch02 └── ch02-01.jpeg ├── ch03 ├── ch03-01.jpg ├── ch03-02.jpg ├── ch03-03.jpg └── ch03-04.jpeg ├── ch04 ├── ch04-01.jpeg ├── ch04-02.jpg └── ch04-03.jpg ├── ch05 └── ch05-01.jpg └── ch06 ├── ch06-01.jpg ├── ch06-02.jpg ├── ch06-03.jpg ├── ch06-04.jpg ├── ch06-05.jpg ├── ch06-06.jpg ├── ch06-07.jpg ├── ch06-08.jpg └── ch06-09.jpg /.gitbook.yaml: -------------------------------------------------------------------------------- 1 | root: ./ 2 | 3 | structure: 4 | readme: README.md 5 | summary: SUMMARY.md -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .vscode/* 2 | !.vscode/settings.json 3 | !.vscode/tasks.json 4 | !.vscode/launch.json 5 | !.vscode/extensions.json 6 | 7 | .history/ -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Attribution-ShareAlike 4.0 International 2 | 3 | ======================================================================= 4 | 5 | Creative Commons Corporation ("Creative Commons") is not a law firm and 6 | does not provide legal services or legal advice. Distribution of 7 | Creative Commons public licenses does not create a lawyer-client or 8 | other relationship. Creative Commons makes its licenses and related 9 | information available on an "as-is" basis. Creative Commons gives no 10 | warranties regarding its licenses, any material licensed under their 11 | terms and conditions, or any related information. Creative Commons 12 | disclaims all liability for damages resulting from their use to the 13 | fullest extent possible. 14 | 15 | Using Creative Commons Public Licenses 16 | 17 | Creative Commons public licenses provide a standard set of terms and 18 | conditions that creators and other rights holders may use to share 19 | original works of authorship and other material subject to copyright 20 | and certain other rights specified in the public license below. The 21 | following considerations are for informational purposes only, are not 22 | exhaustive, and do not form part of our licenses. 23 | 24 | Considerations for licensors: Our public licenses are 25 | intended for use by those authorized to give the public 26 | permission to use material in ways otherwise restricted by 27 | copyright and certain other rights. Our licenses are 28 | irrevocable. Licensors should read and understand the terms 29 | and conditions of the license they choose before applying it. 30 | Licensors should also secure all rights necessary before 31 | applying our licenses so that the public can reuse the 32 | material as expected. Licensors should clearly mark any 33 | material not subject to the license. This includes other CC- 34 | licensed material, or material used under an exception or 35 | limitation to copyright. More considerations for licensors: 36 | wiki.creativecommons.org/Considerations_for_licensors 37 | 38 | Considerations for the public: By using one of our public 39 | licenses, a licensor grants the public permission to use the 40 | licensed material under specified terms and conditions. If 41 | the licensor's permission is not necessary for any reason--for 42 | example, because of any applicable exception or limitation to 43 | copyright--then that use is not regulated by the license. Our 44 | licenses grant only permissions under copyright and certain 45 | other rights that a licensor has authority to grant. Use of 46 | the licensed material may still be restricted for other 47 | reasons, including because others have copyright or other 48 | rights in the material. A licensor may make special requests, 49 | such as asking that all changes be marked or described. 50 | Although not required by our licenses, you are encouraged to 51 | respect those requests where reasonable. More_considerations 52 | for the public: 53 | wiki.creativecommons.org/Considerations_for_licensees 54 | 55 | ======================================================================= 56 | 57 | Creative Commons Attribution-ShareAlike 4.0 International Public 58 | License 59 | 60 | By exercising the Licensed Rights (defined below), You accept and agree 61 | to be bound by the terms and conditions of this Creative Commons 62 | Attribution-ShareAlike 4.0 International Public License ("Public 63 | License"). To the extent this Public License may be interpreted as a 64 | contract, You are granted the Licensed Rights in consideration of Your 65 | acceptance of these terms and conditions, and the Licensor grants You 66 | such rights in consideration of benefits the Licensor receives from 67 | making the Licensed Material available under these terms and 68 | conditions. 69 | 70 | 71 | Section 1 -- Definitions. 72 | 73 | a. Adapted Material means material subject to Copyright and Similar 74 | Rights that is derived from or based upon the Licensed Material 75 | and in which the Licensed Material is translated, altered, 76 | arranged, transformed, or otherwise modified in a manner requiring 77 | permission under the Copyright and Similar Rights held by the 78 | Licensor. For purposes of this Public License, where the Licensed 79 | Material is a musical work, performance, or sound recording, 80 | Adapted Material is always produced where the Licensed Material is 81 | synched in timed relation with a moving image. 82 | 83 | b. Adapter's License means the license You apply to Your Copyright 84 | and Similar Rights in Your contributions to Adapted Material in 85 | accordance with the terms and conditions of this Public License. 86 | 87 | c. BY-SA Compatible License means a license listed at 88 | creativecommons.org/compatiblelicenses, approved by Creative 89 | Commons as essentially the equivalent of this Public License. 90 | 91 | d. Copyright and Similar Rights means copyright and/or similar rights 92 | closely related to copyright including, without limitation, 93 | performance, broadcast, sound recording, and Sui Generis Database 94 | Rights, without regard to how the rights are labeled or 95 | categorized. For purposes of this Public License, the rights 96 | specified in Section 2(b)(1)-(2) are not Copyright and Similar 97 | Rights. 98 | 99 | e. Effective Technological Measures means those measures that, in the 100 | absence of proper authority, may not be circumvented under laws 101 | fulfilling obligations under Article 11 of the WIPO Copyright 102 | Treaty adopted on December 20, 1996, and/or similar international 103 | agreements. 104 | 105 | f. Exceptions and Limitations means fair use, fair dealing, and/or 106 | any other exception or limitation to Copyright and Similar Rights 107 | that applies to Your use of the Licensed Material. 108 | 109 | g. License Elements means the license attributes listed in the name 110 | of a Creative Commons Public License. The License Elements of this 111 | Public License are Attribution and ShareAlike. 112 | 113 | h. Licensed Material means the artistic or literary work, database, 114 | or other material to which the Licensor applied this Public 115 | License. 116 | 117 | i. Licensed Rights means the rights granted to You subject to the 118 | terms and conditions of this Public License, which are limited to 119 | all Copyright and Similar Rights that apply to Your use of the 120 | Licensed Material and that the Licensor has authority to license. 121 | 122 | j. Licensor means the individual(s) or entity(ies) granting rights 123 | under this Public License. 124 | 125 | k. Share means to provide material to the public by any means or 126 | process that requires permission under the Licensed Rights, such 127 | as reproduction, public display, public performance, distribution, 128 | dissemination, communication, or importation, and to make material 129 | available to the public including in ways that members of the 130 | public may access the material from a place and at a time 131 | individually chosen by them. 132 | 133 | l. Sui Generis Database Rights means rights other than copyright 134 | resulting from Directive 96/9/EC of the European Parliament and of 135 | the Council of 11 March 1996 on the legal protection of databases, 136 | as amended and/or succeeded, as well as other essentially 137 | equivalent rights anywhere in the world. 138 | 139 | m. You means the individual or entity exercising the Licensed Rights 140 | under this Public License. Your has a corresponding meaning. 141 | 142 | 143 | Section 2 -- Scope. 144 | 145 | a. License grant. 146 | 147 | 1. Subject to the terms and conditions of this Public License, 148 | the Licensor hereby grants You a worldwide, royalty-free, 149 | non-sublicensable, non-exclusive, irrevocable license to 150 | exercise the Licensed Rights in the Licensed Material to: 151 | 152 | a. reproduce and Share the Licensed Material, in whole or 153 | in part; and 154 | 155 | b. produce, reproduce, and Share Adapted Material. 156 | 157 | 2. Exceptions and Limitations. For the avoidance of doubt, where 158 | Exceptions and Limitations apply to Your use, this Public 159 | License does not apply, and You do not need to comply with 160 | its terms and conditions. 161 | 162 | 3. Term. The term of this Public License is specified in Section 163 | 6(a). 164 | 165 | 4. Media and formats; technical modifications allowed. The 166 | Licensor authorizes You to exercise the Licensed Rights in 167 | all media and formats whether now known or hereafter created, 168 | and to make technical modifications necessary to do so. The 169 | Licensor waives and/or agrees not to assert any right or 170 | authority to forbid You from making technical modifications 171 | necessary to exercise the Licensed Rights, including 172 | technical modifications necessary to circumvent Effective 173 | Technological Measures. For purposes of this Public License, 174 | simply making modifications authorized by this Section 2(a) 175 | (4) never produces Adapted Material. 176 | 177 | 5. Downstream recipients. 178 | 179 | a. Offer from the Licensor -- Licensed Material. Every 180 | recipient of the Licensed Material automatically 181 | receives an offer from the Licensor to exercise the 182 | Licensed Rights under the terms and conditions of this 183 | Public License. 184 | 185 | b. Additional offer from the Licensor -- Adapted Material. 186 | Every recipient of Adapted Material from You 187 | automatically receives an offer from the Licensor to 188 | exercise the Licensed Rights in the Adapted Material 189 | under the conditions of the Adapter's License You apply. 190 | 191 | c. No downstream restrictions. You may not offer or impose 192 | any additional or different terms or conditions on, or 193 | apply any Effective Technological Measures to, the 194 | Licensed Material if doing so restricts exercise of the 195 | Licensed Rights by any recipient of the Licensed 196 | Material. 197 | 198 | 6. No endorsement. Nothing in this Public License constitutes or 199 | may be construed as permission to assert or imply that You 200 | are, or that Your use of the Licensed Material is, connected 201 | with, or sponsored, endorsed, or granted official status by, 202 | the Licensor or others designated to receive attribution as 203 | provided in Section 3(a)(1)(A)(i). 204 | 205 | b. Other rights. 206 | 207 | 1. Moral rights, such as the right of integrity, are not 208 | licensed under this Public License, nor are publicity, 209 | privacy, and/or other similar personality rights; however, to 210 | the extent possible, the Licensor waives and/or agrees not to 211 | assert any such rights held by the Licensor to the limited 212 | extent necessary to allow You to exercise the Licensed 213 | Rights, but not otherwise. 214 | 215 | 2. Patent and trademark rights are not licensed under this 216 | Public License. 217 | 218 | 3. To the extent possible, the Licensor waives any right to 219 | collect royalties from You for the exercise of the Licensed 220 | Rights, whether directly or through a collecting society 221 | under any voluntary or waivable statutory or compulsory 222 | licensing scheme. In all other cases the Licensor expressly 223 | reserves any right to collect such royalties. 224 | 225 | 226 | Section 3 -- License Conditions. 227 | 228 | Your exercise of the Licensed Rights is expressly made subject to the 229 | following conditions. 230 | 231 | a. Attribution. 232 | 233 | 1. If You Share the Licensed Material (including in modified 234 | form), You must: 235 | 236 | a. retain the following if it is supplied by the Licensor 237 | with the Licensed Material: 238 | 239 | i. identification of the creator(s) of the Licensed 240 | Material and any others designated to receive 241 | attribution, in any reasonable manner requested by 242 | the Licensor (including by pseudonym if 243 | designated); 244 | 245 | ii. a copyright notice; 246 | 247 | iii. a notice that refers to this Public License; 248 | 249 | iv. a notice that refers to the disclaimer of 250 | warranties; 251 | 252 | v. a URI or hyperlink to the Licensed Material to the 253 | extent reasonably practicable; 254 | 255 | b. indicate if You modified the Licensed Material and 256 | retain an indication of any previous modifications; and 257 | 258 | c. indicate the Licensed Material is licensed under this 259 | Public License, and include the text of, or the URI or 260 | hyperlink to, this Public License. 261 | 262 | 2. You may satisfy the conditions in Section 3(a)(1) in any 263 | reasonable manner based on the medium, means, and context in 264 | which You Share the Licensed Material. For example, it may be 265 | reasonable to satisfy the conditions by providing a URI or 266 | hyperlink to a resource that includes the required 267 | information. 268 | 269 | 3. If requested by the Licensor, You must remove any of the 270 | information required by Section 3(a)(1)(A) to the extent 271 | reasonably practicable. 272 | 273 | b. ShareAlike. 274 | 275 | In addition to the conditions in Section 3(a), if You Share 276 | Adapted Material You produce, the following conditions also apply. 277 | 278 | 1. The Adapter's License You apply must be a Creative Commons 279 | license with the same License Elements, this version or 280 | later, or a BY-SA Compatible License. 281 | 282 | 2. You must include the text of, or the URI or hyperlink to, the 283 | Adapter's License You apply. You may satisfy this condition 284 | in any reasonable manner based on the medium, means, and 285 | context in which You Share Adapted Material. 286 | 287 | 3. You may not offer or impose any additional or different terms 288 | or conditions on, or apply any Effective Technological 289 | Measures to, Adapted Material that restrict exercise of the 290 | rights granted under the Adapter's License You apply. 291 | 292 | 293 | Section 4 -- Sui Generis Database Rights. 294 | 295 | Where the Licensed Rights include Sui Generis Database Rights that 296 | apply to Your use of the Licensed Material: 297 | 298 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right 299 | to extract, reuse, reproduce, and Share all or a substantial 300 | portion of the contents of the database; 301 | 302 | b. if You include all or a substantial portion of the database 303 | contents in a database in which You have Sui Generis Database 304 | Rights, then the database in which You have Sui Generis Database 305 | Rights (but not its individual contents) is Adapted Material, 306 | 307 | including for purposes of Section 3(b); and 308 | c. You must comply with the conditions in Section 3(a) if You Share 309 | all or a substantial portion of the contents of the database. 310 | 311 | For the avoidance of doubt, this Section 4 supplements and does not 312 | replace Your obligations under this Public License where the Licensed 313 | Rights include other Copyright and Similar Rights. 314 | 315 | 316 | Section 5 -- Disclaimer of Warranties and Limitation of Liability. 317 | 318 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE 319 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS 320 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF 321 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, 322 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, 323 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR 324 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, 325 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT 326 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT 327 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. 328 | 329 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE 330 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, 331 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, 332 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, 333 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR 334 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN 335 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR 336 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR 337 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. 338 | 339 | c. The disclaimer of warranties and limitation of liability provided 340 | above shall be interpreted in a manner that, to the extent 341 | possible, most closely approximates an absolute disclaimer and 342 | waiver of all liability. 343 | 344 | 345 | Section 6 -- Term and Termination. 346 | 347 | a. This Public License applies for the term of the Copyright and 348 | Similar Rights licensed here. However, if You fail to comply with 349 | this Public License, then Your rights under this Public License 350 | terminate automatically. 351 | 352 | b. Where Your right to use the Licensed Material has terminated under 353 | Section 6(a), it reinstates: 354 | 355 | 1. automatically as of the date the violation is cured, provided 356 | it is cured within 30 days of Your discovery of the 357 | violation; or 358 | 359 | 2. upon express reinstatement by the Licensor. 360 | 361 | For the avoidance of doubt, this Section 6(b) does not affect any 362 | right the Licensor may have to seek remedies for Your violations 363 | of this Public License. 364 | 365 | c. For the avoidance of doubt, the Licensor may also offer the 366 | Licensed Material under separate terms or conditions or stop 367 | distributing the Licensed Material at any time; however, doing so 368 | will not terminate this Public License. 369 | 370 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public 371 | License. 372 | 373 | 374 | Section 7 -- Other Terms and Conditions. 375 | 376 | a. The Licensor shall not be bound by any additional or different 377 | terms or conditions communicated by You unless expressly agreed. 378 | 379 | b. Any arrangements, understandings, or agreements regarding the 380 | Licensed Material not stated herein are separate from and 381 | independent of the terms and conditions of this Public License. 382 | 383 | 384 | Section 8 -- Interpretation. 385 | 386 | a. For the avoidance of doubt, this Public License does not, and 387 | shall not be interpreted to, reduce, limit, restrict, or impose 388 | conditions on any use of the Licensed Material that could lawfully 389 | be made without permission under this Public License. 390 | 391 | b. To the extent possible, if any provision of this Public License is 392 | deemed unenforceable, it shall be automatically reformed to the 393 | minimum extent necessary to make it enforceable. If the provision 394 | cannot be reformed, it shall be severed from this Public License 395 | without affecting the enforceability of the remaining terms and 396 | conditions. 397 | 398 | c. No term or condition of this Public License will be waived and no 399 | failure to comply consented to unless expressly agreed to by the 400 | Licensor. 401 | 402 | d. Nothing in this Public License constitutes or may be interpreted 403 | as a limitation upon, or waiver of, any privileges and immunities 404 | that apply to the Licensor or You, including from the legal 405 | processes of any jurisdiction or authority. 406 | 407 | 408 | ======================================================================= 409 | 410 | Creative Commons is not a party to its public 411 | licenses. Notwithstanding, Creative Commons may elect to apply one of 412 | its public licenses to material it publishes and in those instances 413 | will be considered the “Licensor.” The text of the Creative Commons 414 | public licenses is dedicated to the public domain under the CC0 Public 415 | Domain Dedication. Except for the limited purpose of indicating that 416 | material is shared under a Creative Commons public license or as 417 | otherwise permitted by the Creative Commons policies published at 418 | creativecommons.org/policies, Creative Commons does not authorize the 419 | use of the trademark "Creative Commons" or any other trademark or logo 420 | of Creative Commons without its prior written consent including, 421 | without limitation, in connection with any unauthorized modifications 422 | to any of its public licenses or any other arrangements, 423 | understandings, or agreements concerning use of licensed material. For 424 | the avoidance of doubt, this paragraph does not form part of the 425 | public licenses. 426 | 427 | Creative Commons may be contacted at creativecommons.org. 428 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Shift AI models to real world products 2 | 3 | ![Ver 0.6](https://img.shields.io/badge/Version-0.6-orange) [![Gitbook](https://img.shields.io/badge/GitBook-0.6-brightgreen)](https://lonelygo.gitbook.io/shift-ai-models-to-real-world-products/) 4 | 5 | In this repository, I will share some useful guides and references about how to shift AI models to real world products or projects. 6 | 7 | Readme [中文](/README.md) | [English](/Translate/README_EN.md) 8 | 9 | > 欢迎协助完成英文版翻译工作。 10 | 11 | > [GitBook](https://lonelygo.gitbook.io/shift-ai-models-to-real-world-products/)提供了更好的阅读体验。 12 | 13 | > 在[知乎专栏](https://zhuanlan.zhihu.com/c_137954846)同步更新。 14 | 15 | ## 前言 16 | 17 | 离开老东家快一年了，在半休息半工作的轻量负荷下，终于可以系统的做一点事情：1、把快给管理荒废了的撸码捡起来；2、补补 DeVOps 这条 Pipeline 各种工具生态发展；3、看看 React，VUE，Flutter 这些之前根本没有精力去看的东西；4、从数学到理论系统性的看看 DL 的东西；5、看心情，瞎琢磨。 18 | 19 | 同时，在各路猎头的热情对接下，和一些国内 AI 领域的公司有过工作岗位的沟通与面试，基本上分为以下几类： 20 | 21 | > - 头部独角兽 AI 公司 22 | > - 中小 AI 公司 23 | > - 国外 AI 创业，准备回国内落地 24 | > - 准备进入 AI 领域（毕竟是风口）的 IT 领域公司 25 | 26 | 也算聊了不少家，皆无果。究其因，无非就是`人家看不上我`，`我看不上人家`这两种。 27 | 28 | 一方面年龄 40+，在当下这个环境，这是最大的竞争劣势；另一方面多年的工作重心在产品、架构、项目以及技术管理上，写代码这件事基本给废了；再一方面，虽然 16 年开始上手 AI，Demo 也一手做出来了，项目也交付了，但不是科班，显然没有扎实的 DL 基础；最后，怎么说呢，也许就是个靠嘴干活的渣渣。 29 | 30 | 所以我关注的机会，更多的是需要技术支撑的高综合技能要求的方向，而不是“计算机视觉研究员”、“高级程序员”这种明显力不从心的岗位。实际的无果原因基本是：`大多数沟通或者面试，聊着聊着要么“跑偏了”，要么实在是无法继续下去了，继续下去只能是互相浪费时间，只能想办法快速结束`，具体有以下几种情形： 31 | 32 | > - JD 方向是诸如“工程化落地与交付”、“AI 应用示范”、“产品技术经理”等的，基本都是聊 1 到 2 个小时，但真正与 JD 关键词相关的问题好像没有超过 10 分钟的，实在不知道 JD 的要求面试官是否清楚； 33 | > - 最奇葩的一家，目标是找“有 B/G 领域项目交付经验的 CTO”，技术面第一个问题：`Python的 tuple 和 list 什么区别`；然后是 React、MongoDB、Redis、Docker 等；近一个小时，没有一个 DL 问题，没有一个产品、交付的问题；问到 Flask 如何在生产环境部署，真的抓狂了，这是面 3 年以内 Python 开发还是拿我闹着玩呢？答：Python Web 就是写 Demo，生产都是 Java， C#， .NET Core 这些，演示就是 laptop 开发环境把 http 拉起来，没部署过生产环境。只求赶快能让人家判断我不行，面试结束。 34 | > - 遇到过很有“追求”的问题：`你来规划我们的AI产品，如何能确保在2年后落地还是属于领先的技术水平`，我的天，在 2 个月不看新闻，不读 Paper 的就要落伍的 AI 时代，要做到 2 年后落地还要技术领先，我不知道谁能做到，反正我肯定做不到。 35 | > - 遇到过极其“好学”的 CTO 来面试，3 个多小时，简直就是一场 AI 基本概念讲座，我问了一个问题，就后悔前面 3 个多小时的“科普”了：“贵公司的‘人工智能应用总监’目标是解决哪些场景的 DL 问题？”。答案基本是：还没想好，有做 AI 的需求，但是具体做什么需要入职后再讨论。 36 | > - 某团队有个细分的算法，产品化的程度基本比 Demo 强不了多少，准备做 B/G 市场项目，听了好多人家的设想，抛出去灵魂三连问：`1、一个算法其实就是看起来能解决某个领域问题的一个功能点，但是对于B/G市场，用户需要的解决方案和完整的产品，咱们这方面有什么规划？2、以我的理解（非常巧，一个以前带过的产品经理在做的产品和他们的方向很相似，正好这哥们儿之前找我聊过不少，要我给点建议）要做这方面的项目，还需要有……，这些算法和产品规划，有没有时间和成本的考虑？3、B/G项目是一个长周期的事情，尤其是这种新兴事物，用户教育和市场培育需要投入和耐心，这方面公司有没有做好长期作战的储备？`。人家思考后，没有回答，给我了一个问题：“`那你觉得我们的商业模式应该是什么呢？`”。面试互怼，好欢乐。 37 | > - 头部 AI 公司 CTO，分管的研发中心是要做工程、产品化落地的，终面算是捞到一次和大佬对话的机会，但没有问一个工程、产品与交付的问题。 38 | 39 | 其实，所有的面试，我都是做好准备“**挂**”在 DL 的算法、框架、超参和手写代码的问题上。但，很不幸，这些问题真不多，只有一次，Caffe 大概看了看，没实际用过，问题确实不知怎么回答；没有一家对我之前落地的项目感兴趣，详细追问一些工程、产品和算法实现（调参、backbone network 的选择依据，这些还是有人问到的）以及对项目的复盘与反思等。对此，略感惊讶。 40 | 41 | 五年前，不提**Big Data**、**Hadoop**出门都不好意思跟人打招呼，这两年公司不想办法往**AI**、**Block Chain**方向靠，都不好意思更新网站，在这个热闹非凡，热点轮转的时代，以上种种意想不到的情况，在一定程度上来说，也是必然。 42 | 43 | 之前 2、3 年基本少有人对 AI 落地非常关心，“**豪华团队 + Paper + 比赛刷榜**”就是一个团队最好对背书，不管是谁的钱，投资总是需要考虑回报这件事的，在大方向都转向比拼落地能力的 2019 年，为什么没有感觉到这个行业对于落地的急迫，依然有对豪华团队的迷之自信，可看看知乎的这个问题：[清华 AI 四大公司 PonyAI、RealAI、Face++、商汤未来能否达到 Google、微软的高度？](https://www.zhihu.com/question/334397581/answer/748974753)。必须要说，对于这些横跨学术与产业的顶尖人才的贡献，我是无比敬佩，IT 领域也算混了二十年，从来没见过哪个方向有如此强大的开源与分享动力，框架、论文、实现代码、权重与参数（预训练模型）大家你争我抢，毫无保留的都给社区随便用，Google 的推动更是不可忽视（从开源协议来说，大多都是没法商用的，比如 ImageNet 下载申请协议的第一条就是`Researcher shall use the Database only for non-commercial research and educational purposes`，做 CV 的有几家能全部避免使用 ImageNet 的相关产物？为了下数据集，找在学校任教的同学、朋友借 edu 邮箱，前几年估计很多产业界的人都干过这样的事情）。用半年业余加班时间就能从 0 开始做出检测算法，跑出来 Demo，活着爬出销售挖的坑，没有这些开源分享，就算有“飘柔”般的自信和“梁静茹”给的勇气，这事情也是想都不敢想的。 44 | 45 | 其实，对于非 AI 领域的公司积极拥抱 AI，出现的各种理解与认识偏差，是能理解的（毕竟，我就是摸着石头一步一步往前走的），但是对于**Scientists**坐镇的 AI 公司，现阶段也不缺钱，工程化、产品化落地情况依然不乐观，这件事我是有点困惑的。 46 | 47 | 对于 AI 的落地，我相信，一定会有：“**训练几个 model 搭几个 inference 的 APIs，业务去调用不就好了么？**”这样的简单想法存在。我的理解是：对于 AI 这个“边缘”技术领域，如何从解决一个特定问题的构想到最终的工程化落地的产品、项目，虽然看起来都是写代码，但是和我们传统的软件开发过程、产品思考、交付能力要求相比，还是有较大差异的。 48 | 49 | 基于自己的理解，结合近期与微信群、知乎上的一些“陌生人”聊天过程中的收获，以及工作以来对售前、产品、研发、咨询、交付与技术管理的认识与实践，入门 DL 后的学习探索与项目落地交付实战，还有近一年来较为深入的阅读、学习与思考，把我对于如何实现`Shift AI models to real world products`的一孔之见与相关实践经验组织为一个较为系统的知识体系回馈给社区，同时，我相信写作过程也是对相关知识领域的认知程度的梳理与再学习过程。 50 | 51 | 考虑到我的知识背景局限性（熟悉 B/G 项目和产品，略懂 CV 和监督学习），所以内容和其中的一些建议与案例，更倾向监督学习、CV 在 B/G 端的产品与项目落地，对于机器学习的 NLP、RL 等领域以及像推荐算法这些在线学习的互联网方向的应用，争取也能做一些建议。 52 | 53 | 最后，笔者才疏学浅，文中难免有错误、偏差与疏漏之处，望不吝指正与补充。 54 | 55 | ## 目录 56 | 57 | ### [一、概述](/chapter-01/ch01_Overview.md) - _Draft completed_ 58 | 59 | ### [二、机器学习项目过程](/chapter-02/ch02_Lifecycle-of-a-ML-Project.md) - _Draft completed_ 60 | 61 | ### [三、机器学习项目团队组成](/chapter-03/ch03_ML-Teams.md) - _Draft completed_ 62 | 63 | ### [四、产品经理的工作挑战](/chapter-04/ch04_Product-Manager-Challenge.md) - _Draft completed_ 64 | 65 | ### [五、项目售前与解决方案](/chapter-05/ch05_Project-Consulting-and-Solutions.md) - _Draft completed_ 66 | 67 | ### [六、产品/项目启动](/chapter-06/ch06_Project-or-Product-Setup.md) 68 | 69 | ### [七、数据采集、标注与管理](/chapter-07/ch07_Data-Collection-Labeling-and-Management.md) 70 | 71 | ### [八、训练与调试](/chapter-08/ch08_Training-and-Debugging.md) 72 | 73 | ### [九、模型部署与测试](/chapter-09/ch09_Deployment-and-Testing.md) 74 | 75 | ### [十、机器学习的 DevOps](/chapter-10/ch10_ML-DevOps.md) 76 | 77 | ### [十一、项目交付](/chapter-11/ch11_Project-Delivery.md) 78 | 79 | ## Authors 80 | 81 | - **Kevin Di** 82 | 83 | [![Twitter URL](https://img.shields.io/twitter/url/https/twitter.com/lonelygo?style=social)](https://twitter.com/lonelygo) 84 | 85 | ## License 86 | 87 | [![CC-BY-SA-4.0](https://img.shields.io/badge/license-CC--BY--SA--4.0-brightgreen)](/LICENSE) 88 | 89 | ## Acknowledgments 90 | -------------------------------------------------------------------------------- /SUMMARY.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | 3 | --- 4 | 5 | * [Introduction](README.md) 6 | 7 | --- 8 | 9 | ## 正文 10 | 11 | * [一、概述](/chapter-01/ch01_Overview.md) 12 | 13 | * [二、机器学习项目过程](/chapter-02/ch02_Lifecycle-of-a-ML-Project.md) 14 | 15 | * [三、机器学习项目团队组成](/chapter-03/ch03_ML-Teams.md) 16 | 17 | * [四、产品经理的工作挑战](/chapter-04/ch04_Product-Manager-Challenge.md) 18 | 19 | * [五、项目售前与解决方案](/chapter-05/ch05_Project-Consulting-and-Solutions.md) 20 | 21 | * [六、产品/项目启动](/chapter-06/ch06_Project-or-Product-Setup.md) 22 | 23 | * [七、数据采集、标注与管理](/chapter-07/ch07_Data-Collection-Labeling-and-Management.md) 24 | 25 | * [八、训练与调试](/chapter-08/ch08_Training-and-Debugging.md) 26 | 27 | * [九、模型部署与测试](/chapter-09/ch09_Deployment-and-Testing.md) 28 | 29 | * [十、机器学习的 DevOps](/chapter-10/ch10_ML-DevOps.md) 30 | 31 | * [十一、项目交付](/chapter-11/ch11_Project-Delivery.md) 32 | -------------------------------------------------------------------------------- /Translate/README_EN.md: -------------------------------------------------------------------------------- 1 | # Shift AI models to real world products 2 | 3 | ## 前言 4 | 5 | 离开老东家快一年了，在半休息半工作的轻量负荷下，可以系统的做一些事情：1、把快给管理荒废了的撸码捡起来，补补DeVOps这条Pipline各种工具的功课，看看React，VUE，Flutter这些新东西；2、从数学到理论系统性的看看DL的东西；3、瞎琢磨。同时，在各路猎头的对接下，和一些国内AI领域的公司有过工作岗位的沟通与面试，基本上分为以下几类： 6 | 7 | > - AI头部创业公司 8 | > - AI中小创业公司 9 | > - 国外AI创业，准备回国内落地 10 | > - 准备进入AI领域（毕竟是风口） 11 | 12 | 聊了也算不少家，皆无果。究其因，无非就是`人家看不上我`，`我看不上人家`这两种。一方面年龄40+，在当下这个环境，这是最大的竞争劣势；另一方面多年的工作重心在产品、架构、项目以及技术管理上，写代码这件事基本给废了；再一方面，虽然16年开始上手AI，做的项目也交付了，但不是科班，显然没有扎实的DL基础；最后，怎么说呢，也许就是个靠嘴干活的渣渣。 13 | 所以我关注的机会，更多的是偏向需要技术支撑的综合技能要求偏高的方向，而不是“计算机视觉研究员”、“高级程序员”这种明显力不从心的岗位，实际的无果原因基本是`大多数沟通或者面试，聊着聊着要么“跑偏了”，要么实在是无法继续下去了，只能想办法快速结束，继续下去只能是互相浪费时间`，具体有以下几种情形： 14 | 15 | > - JD方向是诸如“工程化落地与交付”、“AI应用示范”等的，基本都是聊1到2个小时，但真正与JD关键词相关的问题好像没有超过10分钟的，实在不知道JD的要求，面试官是否清楚； 16 | > - 最奇葩的一家，目标是找“有B/G领域项目交付经验的CTO”，技术面第一个问题：`Python的tuple和list什么区别`；然后是React、MongoDB、Redis、Docker等；近一个小时，没有一个DL问题，没有一个产品、交付的问题；问到Flask如何在生产环境部署，真的抓狂了，这是面3年以内Python开发还是拿我闹着玩呢？答：Python Web就是写Demo，生产都是 Java， C#， .NET Core这些，演示就是laptop开发环境把 http 拉起来，没部署过生产环境。只求赶快能让人家判断我不行，面试结束。 17 | > - 遇到过很有“追求”的问题：`你来规划我们的AI产品，如何能确保在2年后落地还是属于领先的技术水平`，我的天，在2个月不看新闻，不读Paper的就要落伍的AI时代，要做到2年后落地还要技术领先，我不知道谁能做到，反正我肯定做不到。 18 | > - 遇到过极其“好学”的CTO来面试，3个多小时，简直就是一场AI基本概念讲座，我问了一个问题，就后悔前面3个多小时的“科普”了：“贵公司的‘人工智能应用总监’目标是解决哪些场景的DL问题？”。答案基本是：还没想好，有做AI的需求，但是具体做什么需要入职后再讨论。 19 | > - 某团队有个细分的算法，产品化的程度基本比Demo强不了多少，准备做B/G市场项目，听了好多人家的设想，抛出去灵魂三连问：`1、一个算法其实就是看起来能解决某个领域问题的一个功能点，但是对于B/G市场，用户需要的解决方案和完整的产品，咱们这方面有什么规划？2、以我的理解（非常巧，一个以前带过的产品经理在做的产品和他们的方向很相似，正好这哥们儿之前找我聊过不少，要我给点建议）要做这方面的项目，还需要有……，这些算法和产品规划，有没有时间和成本的考虑？3、B/G项目是一个长周期的事情，尤其是这种新兴事物，用户教育和市场培育需要投入和耐心，这方面公司有没有做好长期作战的储备？`。人家思考后，没有回答，给我了一个问题：“`那你觉得我们的商业模式应该是什么呢？`”。面试互怼，好欢乐。 20 | > - AI头部公司CTO，分管的异地研发中心是要做工程、产品化落地的，亲自面试没有一个工程、产品与交付的问题。 21 | 22 | 其实，所有的面试，我都是做好准备“**挂**”在DL的算法、框架或者各种参数的问题上，但，很不幸，这些问题真不多，只有一次，Caffe没用过，问题没法回答；没有一家对我之前落地的项目感兴趣，去追问一些工程、产品和算法实现细节以及对项目的反思，对此，略感惊讶。 23 | 24 | 五年前，不提**Big Data**、**Hadoop**出门都不好意思跟人打招呼，这两年公司不想办法往**AI**、**Block Chain**方向靠，都不好意思更新网站，在这个热闹非凡，热点轮转的时代，以上种种意想不到的情况，在一定程度上来说，也是必然。 25 | 26 | 2、3年前基本少有人对 AI 落地非常关心，“**豪华团队 + Paper + 比赛刷榜**”就是一个团队最好对背书，不管是谁的钱，投资总是需要考虑回报这个问题的，在大方向都转向比拼落地能力的2019年，为什么没有感觉到这个行业对于落地的急迫，依然有对豪华团队的迷之自信，可看看知乎的这个问题：[清华AI四大公司PonyAI、RealAI、Face++、商汤未来能否达到Google、微软的高度？]( 27 | https://www.zhihu.com/question/334397581/answer/748974753)。必须要说，对于这些横跨学术与产业的技术大牛的贡献，我是无比敬佩，IT领域也算混了二十年，从来没见过哪个方向有如此强大的开源与分享动力，框架、论文、实现代码、权重与参数（预训练模型）大家你争我抢，毫无保留的都给社区随便用（当然从开源协议来说，大多都是没法商用的，比如ImageNet下载协议的第一条就是`Researcher shall use the Database only for non-commercial research and educational purposes`，做CV的有几家能全部避免使用ImageNet的相关产物？为了下数据集，找在学校任教的同学、朋友借edu邮箱，前几年估计很多产业界的人都干过这样的事情）。用半年业余加班时间就能从0开始做出检测算法Demo，活着爬出销售挖的坑，没有这些开源分享，就算有“飘柔”般的自信和“梁静茹”给的勇气，这事情也是想都不敢想的。 28 | 29 | 其实，对于非AI领域的公司积极拥抱AI，出现的各种理解与认识偏差，是能理解的（毕竟，我就是摸着石头一步一步往前走的），但是对于**Scientists**坐镇的AI公司，现阶段也不缺钱，工程化、产品化落地情况依然不乐观，这件事我是有点困惑的。 30 | 31 | 对于AI的落地，我相信，一定会有：“**训练几个 model 搭几个 inference 的 APIs，业务去调用不就好了么？**”这样的简单想法存在。我的理解是：对于AI这个“边缘”技术领域，如何从解决一个特定问题的构想到最终的工程化落地的产品、项目，虽然看起来都是写代码，但是和我们传统的软件开发过程、产品思考、交付能力要求相比，还是有较大差异的。 32 | 33 | 基于这种理解，结合工作近二十年对售前、产品、研发、咨询、交付与技术管理的认识与实践，入门DL后的学习探索与项目落地交付实践，还有近一年来较为深入的阅读、学习与思考，把我对于如何实现`Shift AI models to real world products`的一孔之见与相关实践回馈给社区。 34 | 35 | 考虑到我的知识局限性（熟悉B/G项目和产品，略懂CV和监督学习），所以内容和其中的一些建议与举例，更倾向监督学习、CV在B/G端的产品与项目落地，对于机器学习的NLP、RL等领域以及像推荐算法这些在线学习的互联网方向的应用，争取也能做一些建议。 36 | 37 | ## 目录 38 | 39 | ### [一、概述](/ch01_Overview.md) 40 | 41 | ### [二、机器学习项目基本过程](/ch02_Lifecycle-of-a-ML-Project.md) 42 | 43 | ### [三、机器学习项目团队组成](/ch03_ML-Teams.md) 44 | 45 | ### [四、产品经理的工作挑战](/ch04_Product-Manager's-Challenge.md) 46 | 47 | ### [五、产品/项目启动](/ch05_Project-or-Product-Setup.md) 48 | 49 | ### [六、数据采集、标注与管理](/ch06_Data-Collection-Labeling-and-Management.md) 50 | 51 | ### [七、训练与调试](/ch07_Training-and-Debugging.md) 52 | 53 | ### [八、模型部署与测试](/ch08_Deployment-and-Testing.md) 54 | ### [九、机器学习的DevOps](/ch09_ML-DevOps.md) 55 | ### [十、项目售前与解决方案](/ch10_Project-Consulting-and-Solutions.md) 56 | ### [十一、项目交付](/ch11_Project-Delivery.md) 57 | 58 | 59 | ## Authors 60 | 61 | * **Kevin Di** 62 | 63 | [![Twitter URL](https://img.shields.io/twitter/url/https/twitter.com/lonelygo?style=social)](https://twitter.com/lonelygo) 64 | 65 | 66 | 67 | ## License 68 | 69 | [![CC-BY-SA-4.0](https://img.shields.io/badge/license-CC--BY--SA--4.0-brightgreen)](/LICENSE.md) 70 | 71 | ## Acknowledgments 72 | -------------------------------------------------------------------------------- /book.json: -------------------------------------------------------------------------------- 1 | { 2 | "title": "Shift AI models to real-world products", 3 | "description": "In this book, I will share some useful guides and references about how to shift AI models to real world products or projects.", 4 | "author": "Kevin Di", 5 | "output.name": "site", 6 | "language": "zh-hans", 7 | "gitbook": "3.2.3", 8 | "root": ".", 9 | "structure": { 10 | "readme": "README.md" 11 | }, 12 | "links": { 13 | "sidebar": { 14 | "Home": "https://lonelygo.github.io/" 15 | } 16 | }, 17 | "plugins": [ 18 | "back-to-top-button", 19 | "code", 20 | "splitter", 21 | "pageview-count", 22 | "chapter-fold" 23 | ] 24 | } -------------------------------------------------------------------------------- /chapter-01/ch01_Overview.md: -------------------------------------------------------------------------------- 1 | # 一、概述 2 | 3 | [前言 <--](/README.md) | [--> 2.机器学习项目过程](/chapter-02/ch02_Lifecycle-of-a-ML-Project.md) 4 | 5 | 写此文的出发点，一部分如README所述。 6 | 7 | 另一部分，随着数据规模的增大和计算能力的大幅提升，深度学习的爆发带动了机器学习这个领域的大踏步发展，再加上Google、Fackebook等众多公司的“争先恐后”的花式开源动作，大大降低了机器学习这个领域的门槛，使像我一样的毫无相关背景的人，也能很快入门，并在自己的业务领域内,快速完成了特定任务的模型训练与项目交付工作。 8 | 9 | ## 工程落地我们需要面对的问题 10 | 11 | 学习新知识的过程，基本上都是：“以为懂了 --> 知道不懂了 --> 开始懂了 --> 还是很多不懂” 这样一个我们称之为“螺旋上升”的过程。对于深度学习这个“边缘”技术领域，尤其是在项目落地的过程中，随着理解的加深，越来越觉得这种交叉领域的技术转移到“软件应用”层面时，对每个参与个体、团队的综合要求是非常高的，表现在： 12 | 13 | - **难以解释性** 14 | 15 | 深度学习的不可解释性，如何向“普通人”“通俗易懂”的解释算法不准确、以及为什么会导致不准确问题，是一件比较困难的工作（比如图像分类的修改像素后的分类错误）。因为其内在机理的不透明性，很难用“别人听得懂”的语言给出令人信服的解释，在一定程度上会带来一些沟通的困惑与障碍。 16 | 17 | - **概率问题** 18 | 19 | 传统软件层面的算法，输出对输入的结果始终一致，所以可以放心将算法嵌入“业务流程”，作为业务流程的一部分，甚至是关键业务流程的判断依据。而机器学习的结果是一种“预测概率”，这种情况下，如何和业务流程结合，同时又能“规避”错误导致的问题，即使只有0.1%的错误率，在关键业务环节应用，也是高风险的。 20 | 21 | - **怎么落地、在哪落地** 22 | 23 | 现阶段用户对于机器学习可以解决什么问题，以及对于机器学习有哪些“明确”的“应用需求”，这件事还是不明确或者说不乐观的；而“炼丹师”、产品经理也非用户业务领域的专家，对于如何才能用最合理、安全、准确的方式将机器学习引入用户业务流程这样的问题，更是很难给出准确的方案，这中间的“认知鸿沟”目前看还是不小的，这应该是“落地难”的一个重要原因。 24 | 25 | - **期望落差** 26 | 27 | 阿尔法狗围棋大胜、图像识别领域的准确率超越人类表现水平、AI玩游戏也大胜等等，诸如此类的新闻稿、标题党，通过各种APP推送到每个人的手机，大幅度的提高了“用户”对于机器学习的“**认知期望**”。当特定任务的算法落地使用后，对于“炼丹师”来说，出现错误在所难免，业内对于“错误”是有容忍度的。 28 | 29 | 但是对于无限拔高了期望的用户来说，`你都超越人类表现水平了，我一眼都能看出来这不对，你这就是“人工智障”`。更不幸的是，媒体怎么会错过这种博眼球的新闻？ 30 | 31 | - **过拟合问题** 32 | 33 | 针对特定的数据集，在训练过程中，已经有了非常多的“技巧”去平衡方差和偏差的问题，最终在测试集取得“**State-Of-The-Art**”的效果。不论我们的training set，test set数量多巨大，也符合我们直觉上的正态分布，但是，有一点是不可忽视的：相对于现实世界的各种场景，我们的training set始终都是一个子集，理论上是难以覆盖所有现实世界场景的。 34 | 35 | 换句话说，在理论层面没有巨大突破的情况下，我们的训练过程**实际上**相对**现实世界**的多样性，是Overfitting了training set+ test set的，那么自然会出现模型在**现实世界**使用的时候大概率的会出现“**高方差**”的问题。 36 | 37 | - **工程/项目经验** 38 | 39 | [PMBOK](https://www.pmi.org/pmbok-guide-standards/foundational/pmbok)(`Project Management Body Of Knowledge`，`项目管理知识体系`),是世界项目管理领域公认的关于涉及项目管理的知识要点的系统性集成，提供了完善的项目知识体系，再结合企业/团队在项目实践中总结出的方法论去执行，结果是可预期的。 40 | 41 | 对于不成熟的软件产品项目，失败或者延期的风险是相当大的，有一本对我思维方法有非常重要的影响书，推荐给大家读一下：[死亡之旅](https://www.amazon.cn/dp/B0067SMWR8)。在“传统”软件行业，有一句话人人皆知：“**三分软件，七分实施**”，没听过这句话的，可以自行琢磨下含义。当我们在ML项目交付过程中，又新引入了“ML模型”这个“**X因素**”，可想而知，这样的项目实施交付难度必然会更高的。 42 | 43 | 难在哪里呢？拿应用最广的人脸识别项目举两个例子。 44 | 45 | 例1：不是像高铁站的“人脸闸机”一样，约束检测目标主动对着摄像机直到识别完成，才会开闸放你通过，而项目需要在高点架设监控摄像机（比方说写字楼大厅、车站码头机场接站口），然后在视频流里做人脸识别。做“人脸”的同学们，应该会想到几个问题吧：大倾角、遮挡、可能的逆光、还要考虑去重等。 46 | 47 | 例2:宁波行人闯红灯的“人工智障”新闻估计大家都看过吧，不知道的可以Google下，或者看看下面这张图。 48 | 49 | ![ch01-01](/res/ch01/ch01-01.jpg) 50 | 51 | 把公交车的车身广告的“董小姐”识别为了闯红灯行人，然后现场还有大屏展示，于是，这个错误就“火了”。那么，这种“误报”的“锅”该甩给谁呢？ 52 | 53 | - 算法团队：产品没有提“活体”检测的需求，这是“非约束”场景，视频流有人脸，我检测到了，锅不是我的； 54 | 55 | - 产品团队：用户需求是检测行人闯红灯，我哪里知道还有车身广告这档子事，你们算法团队就不能检测下这个人脸是不是“活体”的人脸么，要不加个目标检测，协同过滤下公交车这种情况呢？ 56 | 57 | - 项目交付团队：产品说的对。 58 | 59 | - 领导：对什么对？你们在现场测试的时候，为什么没有发现这个问题，你们的测试用例完备么，你们的边界条件定义合理么？测试的，不要在旁边笑，也有你们的份。 60 | 61 | - 大领导：说了半天，有解决方案么，是让你们做“**产品**”，不是做“**玩具**”，给你们三天时间搞定。 62 | 63 | 希望你能会心一笑，这个例子，后面还会继续说，暂时到此为止。 64 | 65 | 上面这六个问题，正如上面的这个例子一样，项目团队的每个人都可以找到合情合理的理由，把自己“摘”出来，但是，我们的目标如果是“***推进AI项目的工程落地，并实现客户预期的目标***”，那么这些问题就不是某个个体的，而是整个团队需要思考解决与应对的。个体遇到困难，干不下去了，可以辞职，可以请假；团队呢？公司呢？所以，有些事情，我们选择去做了，就要当做没有退路的去做。 66 | 67 | 当然，我们需要面对的问题显然不止上述几个，下决心写此文的目的就是想把个人对这些内容的一些思考分享给ML社区。 68 | 69 | ## 内容概述 70 | 71 | 在构思本文大框架的过程中，有过不少挣扎，但比较明确的两点是： 72 | 73 | 1 - 这不会是一个深度学习框架、训练、调参等技巧的最佳实践介绍文章； 74 | 75 | 2 - 这不会是一个深度学习所涉及的理论、论文、数学知识等方向的解读、介绍文章。 76 | 77 | 为什么这两点是明确的？原因是令人沮丧的：我并不认为我具有这样的知识储备，可以在整体层面介绍深度学习的方方面面。 78 | 79 | 所以，我只能从我擅长的方向着手。 80 | 81 | 对于想学习这两个方向内容的阅读者，第一个问题可以去看看Andrew Ng的：[Machine Learning Yearning](https://www.deeplearning.ai/machine-learning-yearning/)，短小精悍的一本书，所有内容都是“炼丹”干货。第二个问题，建议去找找各种 MOOC 资源，免费的太多太多了，不怕没得学，就怕时间不够。另外，对于英语不好的同学还有个温馨提示，如果 MOOC 资源没有中文字幕，可以看看视频资源是否存储在 YouTube上。Google 的语音转文字和机器翻译水平已经是State-Of-The-Art了，而且此类视频资源估计是提了权重，我看过的，到目前为止还没有发现没有完成字幕机翻的。 82 | 83 | 所以，我的初始目标或者说努力的目标就是，能够尽量覆盖深度学习项目/产品在 to B/G 领域，工程化落地过程中的除了上述 2 条的方方面面。比如：项目的生命周期，团队成员之间的分工与协作，产品经理需要考虑的事情，数据准备，部署的一些建议及项目交付的项目管理等等。 84 | 85 | 具体参见下面的章节介绍。 86 | 87 | ## 章节介绍 88 | 89 | 除本节概述外，初步的想法是通过十个章节的内容，能够较全面覆盖深度学习项目落地的方方面面，但不排除在过程中突发奇想的调整。 90 | 91 | ### [一、概述](/chapter-01/ch01_Overview.md) 92 | 93 | 您正在看的就是这一章。 94 | 95 | ### [二、机器学习项目过程](/chapter-02/ch02_Lifecycle-of-a-ML-Project.md) 96 | 97 | 本章会重点关注引入了机器学习这个“X因子”之后的项目，与传统的软件项目存在的差异，以及我们如何去定义自己的项目过程是比较合理的。 98 | 99 | ### [三、机器学习项目团队组成](/chapter-03/ch03_ML-Teams.md) 100 | 101 | 本章会对团队中的角色，分工以及如何合理的协作，做一些说明。由于协作这个过程应该是事件驱动的，所以在后续章节，对于需要协作的部分还会给出建议。 102 | 103 | ### [四、产品经理的工作挑战](/chapter-04/ch04_Product-Manager-Challenge.md) 104 | 105 | 产品经理是一个非常难做的工作岗位，好的产品经理对于综合能力的要求近乎于是无上限的，不是千里挑一也是大几百里挑一。因为一本书，好多同学进了选了个方向，做的大多都是“原型绘制经理”的工作，独立思考和思辨能力不足，只能去像素级抄友商或者听领导“指示”，然后熟练的用“原型工具”画出来原型图提交讨论，所以是“原型绘制经理”。 106 | 107 | 当在引入“X因子”后，对于产品经理新增的挑战又有哪些呢？这是本章会重点探讨的问题。 108 | 109 | ### [五、项目售前与解决方案](/chapter-05/ch05_Project-Consulting-and-Solutions.md) 110 | 111 | “售前”与“解决方案”这是to B/G 软件领域内的通识用语，很有可能有些同学没有听过这两个词，所以先简单解释下。 112 | 113 | “售前”全称应该是“售前咨询”或“售前顾问”，要说来源，我的理解是从“管理咨询”这个领域延伸过来的。 114 | 115 | 那么“售前”要做什么事情呢？当销售了解到客户有采用某软件或者某方案的需求，而这种软件或者需求恰好你所在的公司现有产品可以基本覆盖，或者绝大多数覆盖。那么销售会先和客户接触，了解更具体明确的软件需求或者方案要求，当然还有预算、项目周期等等，这些和技术体系关系不大，就不展开说了。 116 | 117 | 了解到需求后，销售会和产品经理或者售前咨询顾问（不一定每个公司都有这个岗位，但不管具体岗位什么名字，只要销售找到你了，基本售前这件事就要找你解决了。）去说明客户的需求，并会共同讨论：公司产品的契合度，以及缺什么，然后讨论确定一个初步的针对客户的售前阶段的售前咨询方案。老销售或者由顾问转到销售的，由于经验丰富，对公司产品也熟悉，可能就会直接说结果，提要求了。 118 | 119 | 之后，接了这个任务的同学，会根据商量的结果，先做PPT，然后销售会安排去给客户做售前介绍，如果产品成熟度高，还会同步做产品演示。依据客户的不同喜好及销售的水平和关系建立的情况，这个过程可能会多次，也有可能只有一次。 120 | 121 | 所以，去介绍的时候，一定要嘴巴，脑袋，耳朵，记性，一样不少的都带上。 122 | 123 | 然后会按照“售前咨询”阶段方案介绍收集到的信息，出一个Word版本的文档，这个文档就是针对客户需求的“解决方案”。如果一切顺利，那么下面就是投标、中标、签合同，然后项目就要正式启动了。 124 | 125 | ### [六、产品/项目启动](/chapter-06/ch06_Project-or-Product-Setup.md) 126 | 127 | **_好的开始是成功的一半_**。本篇预估篇幅较大，能想到的方方面面的问题，都会给出一些行动建议。在项目启动阶段，最重要的几件事情是： 128 | 129 | 1 - 厘清项目需求，梳理出来最关键的：功能需求、性能需求和ML需求，以及ML需求和功能需求的关系（是否强关联，耦合度很高）； 130 | 131 | 2 - 确定基准。对于ML需求，如果有可参考的“State-of-the-art”则最好，如果没有，则找类似任务的当前最优，了解关键指标； 132 | 133 | 4 - 了解部署要求，现在一般B/G企业早都完成了私有云或者信息中心建设，部署都是在人家分配给你的机器上进行，裸机还是虚机，允许Docker部署不，CPU还是GPU，CPU什么型号，能给你推理用的最多核数等； 134 | 135 | 5 - 已经了解的关键ML指标，判断用户提出的性能需求，是否可以满足，如果不能，差多少，团队头脑风暴下是否有解决希望； 136 | 137 | 6 - 部署的要求一定要问清楚！！！千万不要乐观的认为弄了个ResNet-152满足准确性指标，就万事大吉。推理服务器GPU给你就那么多（或许只有CPU），内存也不多，准是准了，但是慢了好多，怎么办？ 138 | 139 | 7 - 数据集收集之前一定要派有经验的人去看看，部署上线后的实际场景（尤其是 CV 项目）什么样，千万不要在起跑线就摔一跤； 140 | 141 | 8 - 我们都知道为了平衡准确度和召回，一般都用“F1 score”评价算法整体表现。但是，千万不要教条主义，理解清楚真实需求的精度指标是：“查准优先”还是“查全优先”。 142 | 143 | 9 - 最最最重要的是：先弄明白一件事“**如果算法出错了，后果是什么**”、“**如果算法出错了，后果是什么**”、“**如果算法出错了，后果是什么**”，这个必须强调三遍。 144 | 145 | 如果，结合这个事情，能想明白为什么会扎堆的用“人脸”创业，为什么现阶段落地最好的也是“人脸”相关的应用。那么，恭喜你，起码你已经明白了如何去规避项目风险，以及技术成功和商业成功的基本关系。 146 | 147 | ### [七、数据采集、标注与管理](/chapter-07/ch07_Data-Collection-Labeling-and-Management.md) 148 | 149 | 对于ML，有一个概念比较基本但很重要，也容易被忽视，那就是：“**训练数据，权重，超参**”实际上是一体的。 150 | 151 | 所以，我们不但要关注训练数据采集的正态分布和与生产环境的一致性，还要做好数据版本管理，以及后续训练的权重、超参的一体化版本管理。只有这样，当我们在生产环境做测试后，发现整体性能指标还不如test set的话，那就要把错误数据拿回去好好分析了，分析什么、怎么分析不知道的话，罚抄[Machine Learning Yearning](https://www.deeplearning.ai/machine-learning-yearning/)三遍！ 152 | 153 | 我是不会告诉你我就遇到过test指标看起来最好的，放在生产环境测试让人意外，然后丢了一个test第三好的model 到生产环境测试，结果比test第一的准确率还高这种事。 154 | 155 | ### [八、训练与调试](/chapter-08/ch08_Training-and-Debugging.md) 156 | 157 | 接上一章，建议是要做好**训练数据，权重，超参**一体化的版本管理工作，多轮“炼丹”之后，可以放在一起横向比较。另外就是，如果迫不得已必须人工合成数据，给数据集扩容，千万要保护好原始数据。硬盘真的不贵，哪怕就是放云上OSS也不贵，raw数据集脏了，真的哭都来不及了。 158 | 159 | 另外，如果训练数据收集的数量比较大，刚开始主要是做大方向验证，不要一下子上全量数据开始训练，小数据集来一轮浪费的时间少，小数据集能优化的不错了，偏差接近甚至超越基准了，全量数据上去，这个时候才是看计算资源的时候，资源多就能多尝试超参组合。 160 | 161 | 至于这个阶段的DL框架选择，如果熟悉Keras，那就Keras+TensorFlow；如果人手紧张，每个人任务都很重，还要赶进度，还是建议Keras+TensorFlow 。 162 | 163 | 如果对PyTorch熟悉，那就fastai+PyTorch，个人感觉，现阶段在“快速炼丹”，或者搞点突发奇想、稀奇古怪的东西去尝试，这套组合是最方便、也是代码量最少的，TF2.0还没用过，但愿正式版发布后，能比现在开发友好大进一步。 164 | 165 | 考虑到部署与生产环境的支持，至少在现阶段还是要选TensorFlow，在生产环境完备性上，PyTorch还有一段距离要追赶，不是很理解的同学可以看看[TensorFlow Extended (TFX)](https://www.tensorflow.org/tfx) 这一整套的轮子用起来起嘛不会踩坑太多。 166 | 167 | ### [九、模型部署与测试](/chapter-09/ch09_Deployment-and-Testing.md) 168 | 169 | 由于 ONNX Runtime 的出现，使得Model Serving这件事有了更多选项，此外，CPU推理的话，Intel 也提供了预编译的TensorFlow等多种部署模式选择，真是一个丰俭由己的好时代啊！ 170 | 171 | 另外，如果不是用分布式的GPU推理的，个人不太建议选择TensorFlow Serving这个方案，略重了。 172 | 173 | 生产环境的测试，如果可能用户也愿意把数据给你，那在开发环境下能做连续测试，是最理想的情况，在去交付客户前，以及对系统整体表现有了基本判断。如果必须要在现场做部署后的验证测试，那么就给自己留足缓冲时间，不要憋到最后都憋出内伤了，才去现场部署，部署后发现ML效果不尽如人意，项目经理哭都来不及啊！ 174 | 175 | ### [十、机器学习的DevOps](/chapter-10/ch10_ML-DevOps.md) 176 | 177 | 前面章节已经说了，我们需要考虑**训练数据，权重，超参**一体化的问题，那么是需要考虑一个针对机器学习领域功能完备的版本管理的方案与平台。 178 | 179 | 另外还要考虑的事情就是，如果我们的业务应用已经实现了DevOps 的全套自动化的 Pipeline ，那么我们的 Model Serving 如何能实现与之匹配的Pipeline？ 毕竟，没有哪个运维人员能接受业务全自动，推理全手动的更新迭代。 180 | 181 | ### [十一、项目交付](/chapter-11/ch11_Project-Delivery.md) 182 | 183 | 在前面的问题中已经说了“**三分软件，七分实施**”这个问题，所以，本章会详细介绍一下项目管理的相关知识与交付的一些通用策略（套路）。 184 | 185 | 对于项目交付，我过去在不同场合做项目管理培训的时候，说的最多的一句话是：“**项目管理，就是一个先找怎么死，才能有机会比较舒服活着的过程**”。 186 | 187 | “找*怎么死*”：就是把项目的所有风险点尽可能早的“识别”出来，千万别忘了“干系人”也是一种风险哦，然后做好“风险管理”，逐步释放风险、解决风险和有技巧的规避风险，最差的情况下，也要能做到：给关键风险陆陆续续的降级。思考一下： 188 | 189 | 在项目早期，发现之前有一个“不当”的“非关键承诺”，在理论层面都很难实现，做为项目经理，你准备怎么办，怎么应对这个风险？ 190 | 191 | 我会在本章节的正文中来解释具体的处理思路。 192 | 193 | “项目管理”单独就是一个很大的题目，PMBOK V6 700多页，十个知识领域，五个过程组，共49个项目管理过程。这么多的内容，写出来一个篇幅规模不小于本文的文章也不是什么难事。所以，项目交付这一篇，也会着墨较多，目前考虑会在PMBOK中选一些我认为最重要的东西拿出来解释下，另外就是结合个人的项目经验，说一些你在“正统”项目管理书籍中很难看到的“技巧”。 194 | 195 | 如果恰好你对项目管理感兴趣，看目前进度规划，等到写完这章估计就是一个半月以后的事情了，怎么办？没关系，给你推荐两篇2007年我在一个论坛的连载文章，论坛不声不响的下线了，用了“网络时光机”找回来放在了知乎上。 196 | 197 | [项目管理实战——基于真实项目案例的项目管理策略](https://zhuanlan.zhihu.com/p/57985309) 198 | 199 | [PM成长之路——文中的内容都能做到，你就是好PM！](https://zhuanlan.zhihu.com/p/57985267) 200 | 201 | ## 进度安排 202 | 203 | 当我把目录列出来之后，把自己也吓了一大跳。 204 | 205 | 原估计就是一到两周，写个三章就能完成的事情，现在看来，这件事变成一件大工程，但是既然决定开始了，我还是会尽全力去完成的。 206 | 207 | 初步计划是：花一到一个半月的时间，完成Draft版本，然后再花一到两个月的时间去修改、润色、调整以及改错别字。 208 | 209 | 所以暂定每4天左右更新一章，如果有关注的同学，可以按这个节奏过来刷新看看。 210 | 211 | PS：目前已经严重延期，具体原因就不提了，争取尽快完成。 212 | 213 | [前言 <--](/README.md) | [--> 2.机器学习项目过程](/chapter-02/ch02_Lifecycle-of-a-ML-Project.md) 214 | -------------------------------------------------------------------------------- /chapter-02/ch02_Lifecycle-of-a-ML-Project.md: -------------------------------------------------------------------------------- 1 | # 二、机器学习项目过程 2 | 3 | [1.概述 <--](/chapter-01/ch01_Overview.md) | [--> 3.机器学习项目团队组成](/chapter-03/ch03_ML-Teams.md) 4 | 5 | ## 项目的基本概念 6 | 7 | 本文的整体目标是偏向于ML的项目落地应用和交付，所以在正文的开篇，我觉得有必要先解释下“项目”和“项目管理”等知识点的基本概念，这样方便后续在一个语境内理解相关内容。 8 | 9 | ### 什么是项目 10 | 11 | 国际项目管理学（PMI，PMP考试就是PMI的认证）对项目的定义：***项目是为创造独特的产品、服务或成果而进行的临时性工作***。 12 | 13 | 简短一句话，有几个重要的概念一定需要理解，否则很难理解项目管理的一些东西为什么那么要求。 14 | 15 | > **独特性**：正如没有两个片雪花是一样的，也没有两个项目是完全一样的，最直观的就是：客户、需求的不同。项目是需要交付特定的成果或者服务的，也就是说，项目是必须有目标的。 16 | > **临时性**：一定具有明确的“开始时间”和“结束时间”是项目的重要属性，所以项目**不是**一项持续不断的工作。当项目的目标实现，或者项目的目标已经明显无法实现，或者项目需求已经不复存在时，就意味着项目的结束。所以项目一定是三个结果：完成，失败，取消。需要注意的是，虽然项目是临时性工作，但项目但交付成果可以在项目结束后存在。 17 | > **渐进性**：因为项目需要交付的成果或者服务事先是不可见的，即使在项目前期“明确了项目目标”，但对于具体细节、成果、计划等内容的定义依然是“依靠经验粗略定义”，随着项目的推进，这些细节才能逐渐完善和明确。这一点对于项目的重要意义就是：项目过程中的变更是一定存在的。 18 | 19 | ### 什么是项目管理 20 | 21 | PMI对于项目管理的定义：**将知识、技能、工具与技术应用于项目活动，以满足项目的要求。项目管理通过合理运用与整合特定项目所需的项目管理过程得以实现。项目管理使组织能够有效且高效地开展项目。** 22 | 23 | 简单的理解就是：运用合理的资源，确保项目能够在规定时间内完成，并交付规定的可交付成果的过程。 24 | 25 | 所以，一般认为项目管理三要素是：***时间、成本、质量*** ，也可以增加 ***范围*** 变为四要素。 26 | 27 | ### 项目管理过程组 28 | 29 | PMI的定义：**启动过程组、规划过程组、执行过程组、监控过程组、收尾过程组**。 30 | 31 | 项目经理进行项目管理的过程，就是依据 PMBOK 定义的五个过程组，并运用十个知识领域的49个知识点进行管理的过程。 32 | 33 | PMI 的 PMBOK 经过多年的修订改版，目前为第六版。五个过程组没有变化，知识领域增加“**项目相关方管理**”从九个变为十个，“相关方”在过去的版本里称之为“干系人”；对应的知识点也从经历了44个到47个到目前的49个变更过程。 34 | 35 | ### 项目生命周期 36 | 37 | 对项目过程一般通识定义为：项目前期 --> 项目开始 --> 项目组织与准备 --> 项目执行 --> 项目完成 。 38 | 39 | 由于“项目前期”的主要工作是项目需求评估与论证，评估的结果有可能是项目不予立项，那么就没有后续的工作内容了，所以一般的对**项目生命周期**的定义为：项目开始 --> 项目组织与准备 --> 项目执行 --> 项目完成 。 40 | 41 | 可能细心的朋友会发现：项目管理过程组有五个，而项目生命周期为何只有四个环节？原因其实非常简单，因为“监控过程组”是贯穿项目整个生命周期的。 42 | 43 | 基于上述对“项目”的基本概念的介绍，下面我们来看看机器学习的项目生命周期。 44 | 45 | ## Lifecycle Of a ML Project 46 | 47 | ### 约定 48 | 49 | 本文探讨的是机器学习项目的落地过程，在继续之前需要做如下约定： 50 | 51 | > - 对项目的目标设定为：算法与软件集成的整体软件产品交付，而非仅交付model(s)或者APIs。 52 | > - 软件项目的交付，相关知识与方法已经非常成熟，本文仅对ML与软件的关键集成相关内容进行说明，不会过多涉及其他软件部分相关的项目过程； 53 | > - 同样，对于DevOps相关内容,如非必须也不会过多涉及； 54 | 55 | ### 项目过程综述 56 | 57 | 如下图所示，黑虚线框中部分为项目中软件部分，如约定所述，此部分仅包含对关键内容的概括；红色虚线框中部分为项目中机器学习部分，也是本文关注的部分。 58 | 59 | ![ch02-01](/res/ch02/ch02-01.jpeg) 60 | 61 | 可以看到，项目过程分为四个阶段，分别是：项目启动、数据收集、模型训练与调试、交付部署。 62 | 63 | 事实上，在项目启动前还有“项目前期”这个阶段，依据不同的项目类型，具体内容会稍有不同。如果是内部应用项目，那么项目前期一般需要做需求可行性论证、效益分析、商业论证等项目立项准备工作；如果是向 B/G 客户交付的项目，那么项目前期一般是项目售前咨询、招投标等工作。 64 | 65 | 对于内部应用项目，各企业的管理风格、资金储备、商业模式等的不同，项目立项的准备工作会相差比较大。对于内控严、合规性要求高的公司，一般会有严谨的流程去遵照执行；大多数公司可能会做一些讨论以及头脑风暴，再了解下同业公司的情况之后，做出决定；而对于有些公司，可能就是某个领导的“要求”，就会有部分精于企业生存之道的投机者去组织执行。所以，对于此类项目前期工作，本文不做讨论。 66 | 67 | 对于需要向客户（最终用户）交付的项目，前期阶段的相关工作内容，如：项目售前咨询一般的过程、一些通用的方法、需要注意及规避问题、售前PPT的制作、演讲技巧，以及解决方案的如何编写等内容，会在本文[第五章](/ch05_Project-Consulting-and-Solutions.md)中详细介绍。 68 | 69 | #### 1.项目启动 70 | 71 | 一般来说，在项目启动后，企业内部需要做的第一件工作是：“**确定项目经理**”，因为项目启动后所有的工作都需要由项目经理去牵头、协调完成。对于“**大（金额大、意义重大）项目**”，一般还会同步成立PMO（Project Management Office）并设立“项目领导小组”。 72 | 73 | > 特别的，对于一些B/G项目，尤其是 G 类的项目，一般在“投标阶段”就需要在投标文件中明确投标人选定的“项目经理”及“技术经理”人员及资质（简历）。中标后，也会将此项内容写入合同或技术协议文本中，并会对乙方（“投标人”、“乙方”这些属于标准名词：在投标阶段是投标人，中标签署合同后是乙方。）更换项目经理、技术经理的流程进行约定，一般原则都是可以“向上”更换。意思就是，乙方要换人可以，但是你要换的人必须是比合同中确定的人员资质、能力更高才行。为什么这么规定呢？这都是政企客户用“血泪教训”买来的经验：投标把公司最牛的人列为项目经理，以证明公司技术实力，中标后，项目经理甚至连项目启动会都没开，就换人了。 74 | 75 | 考虑到人工智能领域的公司，大多为初创公司，处于产品孵化阶段的居多，也未成立专职的项目交付团队，由产品经理兼任或者转岗项目经理是比较合理的。所以，对于项目经理的工作内容一部分介绍会在本文[第四章](/ch04_Product-Manager's-Challenge.md)中与产品经理的工作内容共同说明。 76 | 77 | > 产品经理去做项目经理这种安排，并无什么不妥，希望广大产品经理看见后不要有什么意外，也不要担心，做好相关知识储备就好。 78 | > 79 | > 说说我个人的经历吧：上午还在客户现场改PLC的代码逻辑和调试，中午接到电话让我立即回公司另有工作安排；回到公司后变成产品经理，去参与公司准备自主开发的软件产品的需求工作；产品需求完成后，开始配合研发完成产品测试；产品具备销售条件后，按公司新安排去做售前顾问，配合销售去“拿”项目；项目中标后，公司第一个自主产品的软件项目，产品我最熟悉，毫不意外我又变成了项目经理；然后在项目现场，借客户的会议室组织公司内部培训，培训销售经理、售前顾问、项目经理，中间还要溜出去带着“徒弟”去做售前；中标的项目多了，多个项目并行展开之后，我就“升职”为PMO，同时兼顾多个项目了。 80 | 81 | 总体来说，在项目启动阶段，在完成项目经理遴选后，主要的任务有如下五项。 82 | 83 | ##### 1.1 - 定义项目目标 84 | 85 | 按照“项目”定义，项目是必须有目标的。所以，在项目启动之后，我们的第一个任务就是确定项目目标。对于政企（就是 to B/G 的项目，以下会依据上下文的语境，两种描述方式选择使用）类项目，项目目标其实说出来挺无聊的，那就是：合同内容。 86 | 87 | 一般的，合同及技术协议文本都是非常严谨的，大到模块，小到功能点的描述，细到具体的技术指标，都会写的清清楚楚。估计会有人有这样的迷惑：“**白纸黑字的合同都签了，照着做就是了，还定义什么目标？**”，对于这样的疑惑，我只能说：***小同学，还是太年轻了，把事情想简单了***。一般而言，为了中标签合同（没有合同就没有收入，没有收入哪里有钱发工资，VC的钱总有烧完的那一天！）从售前到合同签定过程中，多少都会有一些内容是“不当承诺”，大白话就是“吹牛B”。在合同执行阶段，对于项目经理来说，这些“不当承诺”都属于风险管理中要严防死守的内容。 88 | 89 | “项目”的定义中，另一个重要的属性就是有明确的开始时间和结束时间。所以，不要奢望“等我做出来再交付”，时不我待只争朝夕，从项目开始第一天，就要有紧迫感。一方面，有上述的“不当承诺”的可能，另一方面，合同中要求的功能，公司内部不可能一点没有（啥都没有，正常操作，别想中标！非正常操作，也能中标，我什么都不知道，别问我为什么又能中标了），但是也不会全部都有。 90 | 91 | 所以，定义项目目标的工作，就要从梳理合同、技术协议，厘清需求，定义优先级开始。 92 | 93 | ##### 1.2 - 评估基线 94 | 95 | 在明确了机器学习任务后，首要需要考虑的应该就是“baseline”的问题。如果恰好有同类任务，那么这个任务的State-of-the-art就是基线，如果没有，那么就找类似的任务，让我们的技术专家，确定一个基线。 96 | 97 | ##### 1.3- 定义指标 98 | 99 | 在对ML任务的基线有了认识后，建议结合合同中的条款“**理智**”的定义项目指标。 100 | 101 | 为什么要“理智”？一方面State-of-the-art就是这样，你要超越，需要付出多少代价？另一方面，即便我们的metrics不是要超越State-of-the-art，为了多一个“9”需要付出多少代价？而且，这种代价显然不是线性的。 102 | 103 | 而且，考虑到先阶段ML的特定领域的迭代速度是以月为单位的，也许运气好，我们定义的指标虽然“保守”，但是在后续训练过程中，来了一篇神论文，就帮了大忙。 104 | 105 | 另外，对于生产部署，一定会有inference相关的技术指标，比如并发、速度，如果是实时视频的推理，还会有FPS的要求等。如果合同内明确了部署环境的说明，那么这些指标的可实现性就有明确的测算依据。如果，对于部署、推理环境没有明确说明，那么一定要提前沟通，不一定一次沟通就能定下来，但是大方向要清晰。GPU还是CPU还是FPGA，具体型号，配置。如果是实时视频的推理，还要明确是1080还是720或者更高，结合并发要求，测算一下网络环境的上行带宽够不够。不要等到交付部署了，前期测试也一切正常，正式使用了，发现网络给你一个小水管，还要你大并发。 106 | 107 | 温习一下项目成功的四要素：***范围、时间、成本、质量***，所以，请时刻保持成本意识。杠精们也不需要抬杠，有没有不计成本的项目？肯定有，比如“Project Apollo”，这种国家意志驱动的项目，咱们不好比。记住，咱们是企业，企业就是要赚钱的，特殊项目，可以不赚钱，可以小赔本，但是总体上要赚钱这个事情天经地义，对于合理利润，没有什么不好意思说出来的。 108 | 109 | ##### 1.4- 项目计划 110 | 111 | 项目内容和优先级明确了，关键指标也明确了，项目的时间合同上就已经明确了，是时候做项目计划了。如果计划出来后，发现“难度大，时间紧，任务重”，怎么办？ 112 | 113 | 成本允许范围内，多上人呗，能并行的就并行。 114 | 115 | 刚从产品经理转到项目经理，不会排项目计划或者怕排的计划不科学怎么办？好办啊，做计划最简单的办法就是“倒推法”。一个团队中总有在不同领域“经验丰富”的选手，按照合同约定的项目交付时间，按照项目阶段，从后往前排就是了。每个阶段的持续时间怎么定？请教“经验丰富”的同事后，合理的“拍脑袋”呗。 116 | 117 | 反复“拍脑袋”讨论之后，相信制定的项目计划已经具备很大的可执行性了。有些任务是可以并行的，有些任务是必须串行的，那么依据每个阶段的任务，尤其是串行任务容易变成“卡脖子”节点，那么就需要合理安排资源，是时候成立项目组了。 118 | 119 | ##### 1.5- 成立项目组 120 | 121 | 项目组成立后，任务明确，计划明确，合理分工，责任到人，该睡地板就睡地板，该996就996，项目就是这样，**Deadline**就在那里默默的看着你。你选择无视他，他就会让你后悔；你选择重视他，他也许会“隐身”。 122 | 123 | 有关项目团队成员组成的更详细的说明，在[第三章](/chapter-03/ch03_ML-Teams.md)做进一步解释。 124 | 125 | 有关**项目启动**先到这里，部分更详细的介绍在[第六章](/chapter-06/ch06_Project-or-Product-Setup.md) 126 | 127 | #### 2.数据收集 128 | 129 | 事实上，现阶段的深度学习还是在比拼数据集规模的阶段。这一点，AI创业公司是能够理解的，但是对于转做深度学习的软件公司来说，可能有一个误区：“下一个开源数据集不就好了么？干嘛还要自己去准备数据集，费时、费力还费钱”。 130 | 131 | 一方面，对于政企领域的特定任务来说，大概率是没有特定的开源数据集的，恰好有，那也非常小，可以拿来搞搞研究玩玩，但是想做到“生产就绪”，数据量是远远不够的。举个例子，给你一个中文语音到文字的NLP任务，去找找中文语料库看看够用不。 132 | 133 | 另一方面，恰好有比较大的开源数据集，比方说“人脸”这么热闹，数据集不少，还有FaceNet、DeepFace、DeepID，是不是找两个程序员就可以做出来和“独角兽们”一样的“人脸”了？嗯，我也尝试过（匿了，匿了，说出来好丢人）。但是，“独角兽们”不会告诉你，他们用的数据集，比开源数据集，高一个数量级起步。再比如，人脸特征点，Dlib好啊，68点看起来不错把，唬唬行外人妥妥没问题，也有个小哥做了一个81点的放出来，你以为这就是State-of-the-art了？现在人脸特征点是96点起步，做到128点出门才好意思跟人打招呼，196点才能算是现阶段“比较领先的水平”。嗯，196点是有个**Helen dataset**，training + test 一共2330个数据，研究可以，商用想都别想。 134 | 135 | **开源一代，自用一代，研究一代**，这句话真的没有错。在这里建议从各个领域拥抱AI转向DL项目的的兄弟们，一定要给Boos说清楚数据集这件事。 136 | 137 | ##### 2.1 指标验证 138 | 139 | 为什么还没有正式收集数据集，就要先验证？ 140 | 141 | 实际上，这个工作，在我们在评估基线和定义项目指标的时候，就可以同步开始去做了。毕竟项目不是莫名其妙从天上掉下来，在项目前期准备过程中，对于这个特定任务显然已经明确，一方面用户方会提供一些数据供验证与Poc测试，另一方面我们也会准备一些数据做可行性验证与制作演示Demo。 142 | 143 | 这个阶段做的验证工作，真正要解决的问题是： 144 | 145 | > - 用小数据集，利用经验去评估指标实现的可能性和代价； 146 | > - 通过误差分析（再建议一遍，不知道误差分析怎么做的，去看 Andrew Ng 的 Machine Learning Yearning）明确数据采集的策略和要求； 147 | > - 基于误差分析，“炼丹师”仔细评估数据集，看看有没有可能在数据质量，标注上做点工作； 148 | > - 基于小数据表现、经验、任务难度以及数据集采集难度，估算数据集规模； 149 | 150 | ##### 2.2 数据策略 151 | 152 | 上一步已经基于指标验证工作，对数据集的规模、采集要求、标注有了初步结论。那么就需要对所有的数据可能性，给出足够范例，然后项目经理明确对外包团队的数据要求、标准。当然，好多AI公司现在都有自己的数据标注团队了，这个事情做起来会相对靠谱的多。 153 | 154 | 另外还有一点需要注意的就是，对于CV类的图片数据采集，一定要和生产环境使用的场景基本一致，不要为了凑数据数量而忽视了质量。 155 | 156 | ##### 2.3 数据采集 157 | 158 | 这个暂时不多说，按照给出的范例去采集就好。 159 | 160 | ##### 2.4 数据标注 161 | 162 | 这就是个体力活，主要就是做好培训，然后就是早期多检查“Turk”的工作，确保标注准确性和符合要求。 163 | 164 | ##### 2.5 数据管理 165 | 166 | 此外，还有一个重要的事情是做好数据集的管理工作。一方面是保证数据安全，不能丢，更不能莫名其妙就泄漏出去。另一方面要有一个比较好的数据集管理策略，raw数据怎么管，标注后的怎么管，怎么做数据增强，数据集和训练数据怎么关联，毕竟“炼丹”遇到大麻烦，还是要回来看看数据集的。 167 | 168 | 有关数据收集更多的内容会在[第七章](/chapter-07/ch07_Data-Collection-Labeling-and-Management.md)做更详细的解释。 169 | 170 | #### 3.训练与调试 171 | 172 | 训练与调试，这是做深度学习的基本功，这些做不好还谈什么项目落地，本文的定位是介绍项目落地相关的工作，这部分内容按理来说可以不关注。但是考虑到作为一个项目整体的一部分，训练与调试的目标是项目交付，而不是搞科研、发Paper，过程中关注的侧重点与思考方向会有所差异。 173 | 174 | ##### 3.1 模型的MVP 175 | 176 | MVP(Minimum Viable Product)是产品经理非常熟悉的一个概念，为什么在已经做了指标验证的情况下，还要提出用Simplest model 去做 model 的 MVP 呢？ 177 | 178 | 如果项目的任务是我们非常熟悉的领域，对于数据集、model选择、超参的经验值等这些都非常熟悉，那么可以忽略这一步工作，但是如果是一个从未做过的全新任务，那么“强烈建议”从这一步开始做起。选一个较小的数据集开始验证想法，一般把这种数据集叫做“Eyeball 开发集”，起步用一个“AlexNet like”的模型就可以，主要的任务就是能方便我们验证想法、思路，并做好误差分析，最终目标是确定一个可以Work的思路。 179 | 180 | ##### 3.2 验证模型 181 | 182 | 在上一步，我们通过Eyeball 开发集，完成了误差分析，也确定了model的方向，从我们的training set中取一部分数据出来，用小一点的数据集做模型验证工作。具体这个数量是多少，因该按照具体任务确定，如果是简单的CV任务，我们要做的是fine-tuning工作，一个分类有100～200个样本应该就够了。这个阶段在关注精度的同时，也要同时考虑部署后的推理性能问题，避免解决了精度的指标而导致推理指标大幅超过目标值。 183 | 184 | 用较小数据集做验证还有一个好处，可以用较短的时间完成一轮训练，那么就可以晚上让机器干活，白天我们根据结果进行调整，既不耽误时间也不会过多抢占GPU算力。 185 | 186 | 验证阶段，解决了偏差问题，那么可以用全量training set开始训练了。 187 | 188 | ##### 3.3 模型训练 189 | 190 | 在之前提到过，对于model来说，是**训练数据，权重，超参**一体化的，为了更好的调参、优化，在训练阶段我们需要有适当的工具做好相关内容的管理与记录。 191 | 192 | ##### 3.4 模型优化 193 | 194 | 在优化方向的选择上，一方面我们要做好误差分析工作，另一方面要对误差的优化难度和优先级做好评估工作，其实就是一句话：在误差占比高的方向选择“成本、难度、时间”综合最经济的，先做优化。 195 | 196 | 另外，对于模型精度的选择。查准和查全，不同的任务，不同的应用场景实际上要求是有区别的，不能用固化的思维去看待这个问题，只看F1 score来确定模型是否使用。还是拿“人脸”举个例子。 197 | 198 | 假设我们训练完成后，排前两名的model在F1 score上相差不多，但是恰好A查准精度高，B查全精度高，如何选择呢？安全的选择肯定是F1 score那个高用那个，用理论支撑的工具做的选择，出了问题没责任。但这不一定是最优但选择，切记，一定要看场景但业务需求。如果是做“人证合一”的验证，业务的核心需求是“准确验证”，那么选择A是比较合适的；如果是做“人脸布控”，那么查全就非常重要了，所以选择B更合理，误报没关系，但是漏报就麻烦了。同理，大家可以思考下，在“张学友的演唱会”要做人脸布控追逃的话，又该怎么选？ 199 | 200 | ##### 3.5 软件集成 201 | 202 | 到这个阶段，业务相关的软件开发工作也基本完成了，是时候将ML与软件进行开发集成了测试了，Postman虽能解决集成测试问题，但是早投入模拟生产的集成测试，总是没有坏处的。 203 | 204 | 有关训练与调试的更多内容，在[第八章](/chapter-08/ch08_Training-and-Debugging.md)会做更多的说明。 205 | 206 | 有关机器学习开发过程中，与软件开发DevOps的配合，以及一些专用工具或者软件平台的简单介绍，在[第十章](/chapter-10/ch10_ML-DevOps.md)。 207 | 208 | #### 4. 部署 209 | 210 | 如果一切顺利，按照项目计划，到部署的时间节点就该去做生产试点部署了。当然了，就算有点不顺利，到了时间还是要去部署。而且，正常情况下，试点部署的时间只会比计划提前，很少会有推后的。你想啊，你小时候过年买了新衣服，是不是也想在年三十之前就穿啊？ 211 | 212 | ##### 4.1 开发环境测试 213 | 214 | “谋定而后动，知止而有得”，所以我们要制订完备的项目计划，做好风险管理，知进退才能有期望中的收获。 215 | 216 | “不打无准备之仗，不打无把握之仗”，所以，在正式去客户现场部署之前，我们要在内部尽量去模仿一个最终部署形态的“env”环境。有条件、不缺钱计算资源多的公司，建议在开始关注政企市场的项目机会后，在“研发环境”、“测试环境”、“生产环境”之外，从基础设施平台中再独立出一个“交付部署测试环境”。 217 | 218 | 有人可能会想，在开发过程中，已经做了软件集成及相关测试，为什么要增加工作量，不做这一步可以不？答案是：可以。为什么可以呢？因为只有吃过足够的苦头之后，就会长记性了，就知道这一步的重要性了。 219 | 220 | 技术从业者是一个奇特的“物种”，讲起理论、概念、方法都可以做到滔滔不绝，各种新颖名词脱口而出，你要想全听懂，要么是专家，要么是全才，要么随时准备好Google。但是，干起活来，各种意想不到的Bug，奇葩的错误，诡异的意外，技术储备的欠缺等等情况，都有可能出现，你脑洞再大，也有出你意料之外的“惊喜”： 221 | 222 | - 内网部署，无互联网，依赖拉不下来，没法部署下去； 223 | 224 | - 家里测试没问题，到了现场跑不起来，各路高手轮番上阵排错，最后发现是有个对自家“基础环境”的小依赖忘了部署； 225 | 226 | - Nginx负载均衡玩的溜的很，结果用户有硬件负载均衡，还分链路和服务，要求不用Nginx用他们硬件实现LB，前期没问清楚，不会配置，傻眼了； 227 | 228 | - 客户指着地上放的纸箱子说“这是给你们准备的全新服务器，你们自己上架，自己做系统吧……”。什么是bond，什么是虚拟化，什么是SAN网络，我在哪？我要干什么？ 229 | 230 | 在家千日好，出门半朝难。充分演练，充分准备，没有任何坏处。 231 | 232 | ##### 4.2 生产试点 233 | 234 | 先试点，再扩大，最后全面推广，这基本是标准规则。所有要动生产环境的事情，就是：小心，小心，再小心。 235 | 236 | ##### 4.3 测试 237 | 238 | 最理想的情况是，客户恰好有生产测试环境，那么在生产测试环境做试点部署和测试，是最稳妥的，也是客户肯定会要求的。但是，如果没有生产测试环境呢？那么就一定要做好测试的准备工作，从用例到回滚到风险应对等的全套方案。而且，极其不建议在生产试点阶段的测试做回滚操作，这是增加风险的动作。最好的方式是，先单独测试ML部分，不和业务数据联动，ML部分验证没问题后，再做对接业务的测试，但对数据库是非CUD数据测试。 239 | 240 | ##### 4.4 正式部署 241 | 242 | 项目走到这个阶段，大家都可以松一口气了。恭喜，恭喜。 243 | 244 | ##### 4.5 监控 245 | 246 | 虽然可以松一个口起了，但是项目刚上线，还没有验收，千万不可大意，做好监控工作，定好Oncall的排班计划。谁都不希望出事，但是哪里有那么多心想事成但好事啊，做好预案，有了问题能快速解决更重要。 247 | 248 | 有关部署的内容，在[第九章](/chapter-09/ch09_Deployment-and-Testing.md)会进一步说明一些注意事项和风险预防与规避策略。 249 | 250 | 一般而言，对于政企项目，在部署环节开始后，就进入了正式的“交付实施过程”，项目经理在这个阶段压力是非常大的。当然，也有部分to G 的项目，要求合同签订项目正式启动后，就要项目组进场，“驻场”开发，这种项目对项目经理的能力要求是指数级上升的。 251 | 252 | 由于国内软件行业传统的认识和人员的选用安排，项目经理、项目交付人员，无论从待遇上还是能力要求上，还是在内部的话语权上，都是相对同级别程序员较低的。事实上，大多公司都存在类似这样的认识：“实施，不就是去现场装个系统，教会客户使用么，有什么难的，干嘛要用那么“贵”的人？”。 253 | 254 | 但是，实际情况是这样么？我们来看看ML的项目经理应该具备哪些能力： 255 | 256 | - 情商高。会和人打交道，而且还要具有快速和陌生人建立信任关系的能力； 257 | 258 | - 头脑灵活反应快，会说话，敢说话。给领导汇报，能三言两语说清楚；和项目相关方沟通，知道怎么说，能“听懂话”； 259 | 260 | - 快速判断能力。很多时候就是要在分钟级的时间单位内对一件事的难度、风险，是否答应，该不该答应等做出综合判断，并给出回复，而且还要不怕承担风险；否则用户就会觉得这个项目经理“不行”，什么事情都磨磨唧唧，什么事情都定不下来，失去信任感。项目经理一旦让客户失去信任感，基本这个项目做“砸”就是高概率了； 261 | 262 | - 快速学习能力。面对新进入的陌生领域，要能快速学习客户方业务知识，在需求沟通过程中才会收放自如； 263 | 264 | - 硬件、网络等IT综合知识。项目经理要在现场协调、沟通方方面面的工作内容，即使这些工作都有专业工程师配合完成，但是项目经理要都懂才能做好沟通、协调工作； 265 | 266 | - 对于CV类的项目，还要懂视频相关知识，以及工程施工的相关知识，否则人家摄像头给你配个H.265，你可能取流就要傻眼，摄像头怎么安装位置选择要清楚，POE是什么总要明白吧……； 267 | 268 | - 要有架构、写代码的能力。在客户现场，讨论需求、沟通变更或者和第三方集成，做技术沟通，没有这些基本功，怎么沟通，怎么初步判断工作量的量级？能不能判断出来别人是帮你还是害你？ 269 | 270 | - 对于ML项目来说，还要有基本的深度学习技术相关知识。否则，客户问，速度这么慢，为什么你们不给我们上GPU？GPU不是能成倍的加速么。项目经理起码要知道训练和推理的计算量的区别吧，要知道反向传播吧，这样才能balabala的解释下吧。 271 | 272 | - 要有出众的语言组织能力。机器学习怎么能用“大白话”解释给客户；推理出了错，怎么和客户沟通才能让对方理解“这不是人工智障”；为了项目推进，需要想客户提要求的时候，怎么说才比较委婉、合情合理？ 273 | 274 | - 风险意识和风险管理能力。 275 | 276 | **三分软件，七分实施**绝对不是说着玩的，项目有一个好的项目经理带队，基本就已经成功一半了。所以，考虑到深度学习的技术难度和理解难度，建议在项目经理选派这件事上，真不要随意，更不要为了控成本，从这个方向开始下手。 277 | 278 | 项目经理代表公司在客户现场做交付，项目做的好，用户满意，就是“活广告”；做不好，客户不会认为是项目经理能力不行，而会说“这个公司不行”，这里面的机会成本，各位决策者衡量衡量。 279 | 280 | 有关项目经理和项目交付的更多内容，在[第十一章](/chapter-11/ch11_Project-Delivery.md)会做进一步详细介绍。 281 | 282 | [1.概述 <--](/chapter-01/ch01_Overview.md) | [--> 3.机器学习项目团队组成](/chapter-03/ch03_ML-Teams.md) 283 | -------------------------------------------------------------------------------- /chapter-03/ch03_ML-Teams.md: -------------------------------------------------------------------------------- 1 | # 三、机器学习项目团队组成 2 | 3 | [2.机器学习项目过程 <--](/chapter-02/ch02_Lifecycle-of-a-ML-Project.md) | [--> 4.产品经理的工作挑战](/chapter-04/ch04_Product-Manager-Challenge.md) 4 | 5 | ## 为什么需要讨论这个问题 6 | 7 | 机器学习已成为下一波技术红利的基础，这一点已有很大的共识。机器学习领域创业团队随着时间的推移与发展，已经逐步表现出对于现金流和利润的渴望，有强烈参与到政企领域市场项目的动力与意愿，但或许会乐观的认为：只需要再配备“产品经理、前端开发、后端开发和销售”就可以完成软件产品开发，参与到政企市场的项目竞争。 8 | 9 | 机器学习由“**Technical**”向“**System**”转化过程中软件工程与技术层面存在的潜在问题，在 NIPS 2014 的《Machine Learning: The High Interest Credit Card of Technical Debt》文章中做了论述： 10 | 11 | >“Machine learning offers a fantastically powerful toolkit for building complex systems quickly. This paper argues that it is dangerous to think of these quick wins as coming for free. Using the framework of technical debt, we note that it is remarkably easy to incur massive ongoing maintenance costs at the system level when applying machine learning. The goal of this paper is highlight several machine learning specific risk factors and design patterns to be avoided or refactored where possible. These include boundary erosion, entanglement, hidden feedback loops, undeclared consumers, data dependencies, changes in the external world, and a variety of system-level anti-patterns.” 12 | 13 | >-- （Reference：Machine Learning: The High Interest Credit Card of Technical Debt） 14 | 15 | ![ch03-01](/res/ch03/ch03-01.jpg) 16 | 17 | 在 NIPS 2015 的《Hidden Technical Debt in Machine Learning Systems》论文中，对此问题进行了进一步讨论。 18 | 19 | ![ch03-02](/res/ch03/ch03-02.jpg) 20 | 21 | 在上述文章中有一张配图，能更直观的让我们感受到**Technical**与**System**之间的巨大差异。 22 | 23 | ![ch03-01](/res/ch03/ch03-03.jpg) 24 | 25 | 在上图中可以看到：“Only a small fraction of real-world ML systems is composed of the ML code, as shown by the small black box in the middle. The required surrounding infrastructure is vast and complex”。（-- Reference：Hidden Technical Debt in Machine Learning Systems） 26 | 27 | 除“Technical Debt”之外，考虑到政企领域项目的特点，市场“新玩家”对于行业的认知、业务解决方案的理解与设计，以及项目管理、交付能力等非技术的“软实力”的欠缺与“短板”可能更难以意识到。 28 | 29 | 所以，在机器学习团队的组建过程中，我们需要具有系统的工程化思考方式与角色设定，以尽可能的避免“技术债务”与“软实力欠缺”引起的潜在的“技术灾难”与“交付灾难”。 30 | 31 | ## 机器学习团队基本角色 32 | 33 | 考虑到本文主要探讨的是机器学习项目，所以对于**Traditional Software Engineering**部分所涉及的不同角色，如：架构师、UI、UED、前端、后端、移动端及功能测试、自动化测试等，全部合并为“Software Develop Engineer”（SDE）进行指代。 34 | 35 | 基于上述前提，机器学习团队的角色划分建议如下表。 36 | 37 | ![ch03-04](/res/ch03/ch03-04.jpeg) 38 | 39 | ### 1. Product Manager 40 | 41 | 机器学习算法由一项“技术成果”转变为可落地交付应用的“产品”，实现满足客户功能需求的同时，在可接受的指标范围（精度、速度等）内稳定交付运行这一商用目标。产品经理是这个过程中极其重要、不可或缺的一个角色。 42 | 43 | 首先，抛开机器学习领域相关的内容，简单分析下产品经理要高质量完成产品需求定义工作，需要关注哪些内容： 44 | 45 | - **需求挖掘**：如何发现“潜在”需求，很多时候“隐性需求”或更有价值。 46 | 47 | - **需求判断**：如何识别“伪需求”，驱动需求产生的“本质”是什么。 48 | 49 | - **需求分析**：需求背后的“动机”是什么，需求的“场景”是什么，需求的“因果链”是什么。 50 | 51 | - **用户识别**：是否找准了“真实”用户，“典型用户”需求是否具有“普适”性。 52 | 53 | - **价值分析**：需求实现对用户、产品的价值，产品实现后对用户的价值。 54 | 55 | - **风险分析**：需求实现的代价、周期及需求消退周期。 56 | 57 | **洞察力**对于产品经理来说，是一项非常重要的能力与软实力。如何去考察一个产品经理**洞察力**？似乎没有比较科学的“先验知识”，大多只能通过产品结果去做后验，所以产品经理的招聘工作并不容易。产品经理又该如何去提高**洞察力**呢？似乎是没有捷径的，只有对目标领域做深度认知，不断思考、深度思考，反复推演。 58 | 59 | 特别的，对于深度学习的产品经理，还需要对一个 **_非常重要_** 的问题进行思考：**模型预测错误的后果是什么？** 60 | 61 | #### 1.1 主要工作内容 62 | 63 | - 需求调研，需求分析，产品设计 64 | - 产品解决方案定义 65 | - 项目解决方案定义 66 | - 产品开发过程管理 67 | 68 | #### 1.2 主要工作产出物 69 | 70 | - PRD 71 | - 产品白皮书 72 | - 项目解决方案 73 | - 产品开发交付 74 | 75 | 有关产品经理的工作难度与挑战，在[第四章](/chapter-04/ch04_Product-Manager-Challenge.md)进一步详细说明。 76 | 77 | ### 2. Project Manager 78 | 79 | 当我们完成产品开发（有可能产品还是半成品或者仅仅是 MVP）向政企客户成功销售后，那么项目就需要正式启动了。如前一章所述，项目经理需要完成：管理、协调、控制、交付等项目生命周期内的工作。事实上，在实际操作层面，大量存在“**_以项目养产品_**”的情况：，大致解释一下。 80 | 81 | 公司在某些技术领域，比如“人脸识别”、“车辆识别”、“语音转文字”、“目标检测”等技术方向取得了比较好的精度，基本达到或者超过了 SOTA（State-of-the-art）水平，具有商业化落地应用的可能，也会有一些行业客户咨询相关技术的应用情况，更坚定了商业化信心。那么如果去实现商业化的产品？而做为技术驱动的公司，大概率是没有相关完备产品与行业解决方案储备的，所以需要在政企客户市场小步快跑，走“捷径”，快速形成产品、解决方案与产品矩阵。基本过程（套路）如下： 82 | 83 | 1 - 对照客户需求，在行业对标寻找竞争对手现有产品与方案内容组成、产品架构以及核心功能； 84 | 85 | 2 - 解决方案团队与产品经理团队共同“定义”针对用户需求的，具备足够竞争力的解决方案思路； 86 | 87 | 3 - 将上述解决方案思路，转化为高水准的产品或解决方案 PPT； 88 | 89 | 4 - 基于公司技术积累、现有产品，结合用户核心需求，快速完成 Demo 和 MVP 的开发； 90 | 91 | 5 - 如一切顺利，拿下项目后，组建项目团队，在项目团队中会特别安排产品经理与解决方案团队成员组成“需求团队”； 92 | 93 | 6 - 结合合同内容要求，现场用户需求调研获取的一手需求，行业竞争对手的产品功能，项目经理带领“需求团队”，完成既能满足项目交付，又足够具有行业通用性的“产品需求”（这是理想状态，在实际操作中各中痛苦，冷暖自知）； 94 | 95 | 7 - 需求团队与架构团队共同讨论确定三件大事：产品基础/通用/支撑功能，产品特性功能，项目功能，基于这种认识开始架构层面设计与技术路线选择（强调一下，项目是有时间限制的，不能为了追求“理想”忽略了进度。）； 96 | 97 | 8 - 研发团队快速完成在 master（Dev）分支完成第一部分基础和通用功能开发；然后分支出“pd-xx”进行项目所需的产品特性功能开发，测试合并入 master 后；分支出“pj-xx”进行项目功能的开发。在项目开发未完成前，产品分支的开发依然是服务于项目的，以便快速合并； 98 | 99 | 9 - 事实上，单一客户的需求必然有一定片面性与局限性，在做项目开发同时，需求团队需要进一步研究行业需求，快速对产品部分的需求做出更新与完善； 100 | 101 | 10 - 理想状态下，项目交付后，在我们的版本控制系统里就有一个完整的项目版本和一个基本成熟的产品版本，这样就实现了 **_以项目养产品_**，同时最大限度的降低了研发周期与成本。 102 | 103 | 不要以为下周回国的贾老板是 PPT 造车高手，政企领域大玩家都是 PPT 做产品高手。看到没有，“先有鸡还是先有蛋”的问题，可以解决为“鸡和蛋”一起有。 104 | 105 | 产品经理和项目经理分别做为产品和项目的“总经理”，是实现技术到产品到落地交付的最核心的中坚力量。这两个岗位的职责一部分是清晰可区分的，一部分又是重叠和需要共同协作完成的。 106 | 107 | 我相信，在深度学习这个领域做政企市场落地的公司，大都存在这种**以项目养产品**的实际操作。所以，对项目经理除了要求项目管理能力外，还需具备产品经理的“产品感”与“洞察力”，这也是为什么在本文中我会把项目经理的相关工作内容与产品经理合并在一起去说明的重要理由之一。 108 | 109 | #### 2.1 主要工作内容 110 | 111 | - 项目解决方案 112 | - 项目实施计划、项目交付（实施）方案 113 | - 需求调研 114 | - 项目管理 115 | - 平衡好项目管理“铁三角” 116 | 117 | #### 2.2 主要工作产出物 118 | 119 | - 项目文档 120 | - 项目交付 121 | 122 | 有关项目经理的工作内容与产品相关的，在[第四章](/chapter-04/ch04_Product-Manager-Challenge.md)进一步详细说明；与项目管理相关的在[第十一章](/chapter-11/ch11_Project-Delivery.md)说明。 123 | 124 | ### 3. Business Consultant 125 | 126 | 业务咨询顾问更多的是一种“角色”概念，并非所有公司都会设置专职岗位。一般情况下，业务咨询顾问角色由两类人员担任。第一类是在目标行业领域具有丰富工作经验，做为业务专家参与业务咨询工作；第二类是社会新人，有志于成为业务咨询顾问，一般从熟悉模块功能、参与业务需求调研开始培养，视个人发展意愿，后期会向产品经理、项目经理或者销售方向转岗。 127 | 128 | 业务咨询顾问的工作主要由三部分构成： 129 | 130 | - 配合产品经理/项目经理完成产品/项目的需求调研，并形成对应的需求文档； 131 | 132 | - 配合销售经理完成项目的售前咨询与产品/方案介绍，并形成售前咨询方案/PPT； 133 | 134 | - 行业/竞品分析，了解发展趋势与动态，给出产品方向性建议； 135 | 136 | #### 3.1 主要工作内容 137 | 138 | - 需求调研 139 | - 解决方案 140 | - 业务分析 141 | 142 | #### 3.2 主要工作产出物 143 | 144 | - 需求调研报告/PRD 145 | - 相关文档 146 | 147 | ### 4. Software Develop Engineer 148 | 149 | 如前述，本文主要探讨的是机器学习方法的任务，所以对于**Traditional Software Engineering**部分所涉及的不同角色，比如：架构师、UI、UE、前端、后端、移动端及功能测试、自动化测试等，全部合并为“Software Develop Engineer（SDE）”统一指代。 150 | 151 | ![ch03-01](/res/ch03/ch03-03.jpg) 152 | 153 | 同样的图，再来看一遍。实际上，做为一个产品或者项目交付的系统来说，深度学习的 models 部分所占比重并不高，其余的工作内容更多的是偏向于传统软件工程的架构、工具、数据、代码等内容，而这部分内容是 SDE 团队更加擅长和熟悉的。 154 | 155 | 对于 SDE 部分的工作内容，不做过多介绍，大家都非常清楚分工、工作内容与交付物，对于涉及到深度学习的部分，有如下建议： 156 | 157 | - APIs、MQ、JSON 等规约内容提前约定、设计； 158 | 159 | - 对于 CV 类的项目有可能 Web 页面需要展示实时视频流与标注框，提前约定好：A：传坐标前端绘制；B：推理平台 OpenCV 绘制标注框，以及是否需要转码为视频流；还需评估抽帧后的前端展示效果，是否满足需求； 160 | 161 | - 业务端对 DL Servin端的调用需求、任务等接口设计； 162 | 163 | ### 5. Data Scientist 164 | 165 | 数据科学家是进几年新兴的一个工作岗位，不同的公司、行业领域对于“Data Scientist”这个角色的定义可能不尽相同，但做为一个跨学科的职位，总体来说具有以下工作内容：独立的数据处理能力，进行复杂的建模并从中发现数据的商业价值与意义，并拥有良好的书面、口头沟通、汇报能力，能对发掘价值进行总结与宣讲。 166 | 167 | #### 5.1 主要工作内容 168 | 169 | - 数据价值挖掘 170 | - 参与、指导团队建模与模型训练工作 171 | - 商业价值分析与汇报 172 | 173 | #### 5.2 主要工作产出物 174 | 175 | - 模型 176 | - 分析报告与汇报 177 | 178 | ### 6. ML Researcher 179 | 180 | 研究员的主要任务更偏向于前瞻性的探索与研究，跟踪行业技术趋势，解决新场景下的建模问题，进行算法的精度与性能调优以及思考、推动算法的应用与落地。 181 | 182 | #### 6.1 主要工作内容 183 | 184 | - 模型训练、算法调优 185 | - 前瞻性研究与跟踪技术趋势 186 | - 算法落地应用可行性论证 187 | - 推理系统架构与设计 188 | 189 | #### 6.2 主要工作产出物 190 | 191 | - 模型、Paper 192 | - 分析/评估报告 193 | 194 | ### 7. ML Engineer 195 | 196 | 机器学习工程师一般在数据科学家和研究员的工作基础上，进一步进行模型的训练与调优，以匹配项目/产品设定的技术指标，并完成推理系统与模型的部署以及与业务软件系统的集成。对于机器学习工程师来说，具备一定的代码实现能力以及掌握一种主流的后端开发语言（Java、C#、.NET Core、C++、Go 等）是有必要的。 197 | 198 | #### 7.1 主要工作内容 199 | 200 | - 模型训练、算法调优 201 | - 推理系统部署与模型部署 202 | - 推理系统接口开发 203 | - 软件系统集成 204 | 205 | #### 7.2 主要工作产出物 206 | 207 | - 模型 208 | - 推理系统 209 | - 软件集成 210 | 211 | ### 8. Data Engineer 212 | 213 | 数据工程师的主要任务是完成 data management pipeline 的数据抽取、聚合、清洗、存储以及自动化流水线的监控工作，确保后续 ML 工作的数据可用性。 214 | 215 | #### 8.1 主要工作内容 216 | 217 | - 数据入库 218 | - 系统监控 219 | 220 | #### 8.2 主要工作产出物 221 | 222 | - 数据库/数据仓库 223 | 224 | ### 9. DevOps Engineer 225 | 226 | DevOps 的理念已经得到了广泛的认同与实践，相关工具链从开源免费到闭源商用、从私有化部署到 SaaS 服务，极为丰富与完善，当选项太多后，如何选择与应用成了一个新问题。DevOps 其中涉及的知识点与技能栈的要求相对较高，所以 DevOps Engineer 这样一个岗位/角色的出现也是合理的。 227 | 228 | #### 9.1 主要工作内容 229 | 230 | - 在组织中建立合适的 DevOps 流程，并分析、优化 DevOps 实践 231 | - 选择适当的工具实现过程自动化 232 | - 建立持续的 CI/CD 环境加速软件开发和部署过程，规避风险 233 | - DevOps pipeline 工具链的选型、部署、维护与监控 234 | 235 | #### 9.2 主要工作产出物 236 | 237 | - DevOps 基础设施 238 | - DevOps 文化引导 239 | - 用户私有化环境的产品部署 240 | 241 | ### 10. Delivery Engineer 242 | 243 | 如之前所述，在传统的软件交付领域有**三分软件，七分实施**这种“共识”，交付环节对于软件项目来说，是非常、非常、非常重要的，千万不可轻视。这项工作，绝非**_安排一个项目经理，带上几个刚毕业愿意出差、能吃苦的小孩_**就可以顺利完成的，再考虑到深度学习部分带来的项目技术概念复杂性、结果不可预测性、不可解释性，会使得项目交付工作更加艰难，更需要有专业化的团队去完成交付工作。 244 | 245 | 机器学习项目的落地交付环节，是在项目经理的带领下，由一批具有各种不同技能与能力的交付工程师组成团队，完成项目交付与实施工作。有关项目交付的更详细的说明，在[第十一章](/chapter-11/ch11_Project-Delivery.md)。在这里先简单说明一下交付团队集体所需要具备的专业知识与技能组合： 246 | 247 | - 沟通、协调与项目管理能力与情商 248 | - 行业理解、流程认知与行业专属名词熟知程度 249 | - 需求沟通与需求判断能力 250 | - 公文写作与汇报能力 251 | - 系统架构评估与代码实现评估能力 252 | - 主机、网络、存储等系统集成的工程与技术能力 253 | - 综合布线、施工管理及与工人沟通能力 254 | - 问题定位与排查能力 255 | - 变通能力与处事灵活性 256 | - 开会能力、风险管理能力 257 | - 抗压能力与心里素质 258 | 259 | #### 10.1 主要工作内容 260 | 261 | - 制订项目交付计划、策略 262 | - 项目需求调研 263 | - 系统部署与现场测试 264 | - 培训用户使用 265 | - 上线后监控 266 | 267 | #### 10.2 主要工作产出物 268 | 269 | - 项目计划、实施方案 270 | - 项目过程文档 271 | - 项目需求调研报告 272 | - 项目交付、验收 273 | 274 | [2.机器学习项目过程 <--](/chapter-02/ch02_Lifecycle-of-a-ML-Project.md) | [--> 4.产品经理的工作挑战](/chapter-04/ch04_Product-Manager-Challenge.md) 275 | -------------------------------------------------------------------------------- /chapter-04/ch04_Product-Manager-Challenge.md: -------------------------------------------------------------------------------- 1 | # 四、产品经理的工作挑战 2 | 3 | [3.机器学习项目团队组成 <--](/chapter-03/ch03_ML-Teams.md) | [--> 5.项目售前与解决方案](/chapter-05/ch05_Project-Consulting-and-Solutions.md) 4 | 5 | 正如`There are a thousand Hamlets in a thousand people's eyes.`一样，对于“产品经理”的职责与定义存在有多种版本的解释，我们来看一下： 6 | 7 | > 在[英文wikipedia](https://en.wikipedia.org/wiki/Product_manager) 中： 8 | > A product manager is a professional role which is responsible for the development of products for an organization, known as the practice of product management. Product managers own the business strategy behind a product (both physical and digital products), specify its functional requirements and generally manage the launch of features. They coordinate work done by many other functions (like software engineers, data scientists and product designers) and are ultimately responsible for the business success of the product. 9 | > **Definition**：A product manager considers numerous factors such as intended customer or user of a product, the products offered by the competition, and how well the product fits with the company's business model. The scope of a product manager varies greatly, some may manage one or more product lines and others (especially in large companies) may manage small components or features of a product. 10 | 11 | > 在[中文wikipedia](https://zh.wikipedia.org/wiki/%E7%94%A2%E5%93%81%E7%B6%93%E7%90%86)中： 12 | > 产品经理（英文：Product manager，缩写：PM）也称产品企划，是指在公司中针对某一项或是某一类的产品进行规划和管理的人员，主要负责产品的研发、制造、营销、渠道等工作。产品经理是很难定义的一个角色，如果非要一句话定义，那么产品经理是为终端用户服务，负责产品整个生命周期的人。 13 | > 产品经理需要考虑目标用户特征、竞争产品、产品是否符合公司的业务模式等等诸多因素。一般而言，产品经理管理的是一个或者多个有形产品。但是，产品经理也可以用于描述管理无形产品如音乐、信息和服务的人。有形产品行业产品经理的角色与服务业中项目总监类似。 14 | > 产品经理的职责描述目前仍然分歧很多，因人、因公司而异。即使是在相对较为一致的高科技行业，不同公司中的职位描述也是很不同的。但通常认为产品经理的职责主要包括：产品经理负责调查并根据用户的需求,确定开发何种产品, 选择何种技术、商业模式等。并推动相应产品的开发组织, 她或他还要根据产品的生命周期,协调研发、营销、运营等,确定和组织实施相应的产品策略,以及其他⼀系列相关的产品管理活动。 15 | 16 | > 在[百度百科](https://baike.baidu.com/item/%E4%BA%A7%E5%93%81%E7%BB%8F%E7%90%86)中： 17 | > 产品经理（Product Owner）是企业中专门负责产品管理的职位，产品经理负责市场调查并根据产品、市场及用户等的需求，确定开发何种产品，选择何种业务模式、商业模式等。并推动相应产品的开发组织，他还要根据产品的生命周期，协调研发、营销、运营等，确定和组织实施相应的产品策略，以及其他一系列相关的产品管理活动。 18 | 19 | 定义的百家争鸣与无法取得共识也从侧面印证了产品经理是一个极具挑战的岗位，虽然“人人都是产品经理”，但优秀的产品经理实际上凤毛麟角。本文并不打算全面的讨论产品经理工作内容与职责，仅从**AI产品落地**这个视角来探讨产品经理的工作难度与需要面临的挑战。此外，对以下两种产品经理对工作模式，也不在本文讨论范围内： 20 | 21 | - “对标”友商产品，做像素级功能“复制设计原型”的产品经理 22 | 23 | - “老大”提要求，就按要求做产品设计；老大没要求就不知道怎么做产品设计的产品经理 24 | 25 | `注：构思本章的内容安排，卡了两天。一方面觉得有关产品经理的工作内容和思考方法可以说的太多，很难在较短篇幅内做取舍；另一方面，“产品思维”是一个很大的话题，从逻辑思辨到人性把握到商业伦理这些“高深”的知识都与产品经理的思想高度与产品思维体系建立相关，很难用简单的文字体系化的说清楚到底什么是“产品思维”；第三，事实上大多数公司对于“产品经理”的认识与要求还是较“低”的，而建立成熟培训体系的则更少。所以，纠结于写的太深，会引起“故弄玄虚”的效果，写的太浅，于事无益，对于大家可能并不会有多大帮助。最后的决定是：为了整体进度，先阐述本人的关键认识完成本章，根据反馈（如果有的话）后期再重构本章的内容。` 26 | 27 | ## 开胃菜 28 | 29 | 在正式开始之前，我们来看两个简单的DL产品的例子。 30 | 31 | > 用户现有系统是在居民身份证数据库中检索某人的身份证信息： 32 | > query('姓名')，高概率有重名，结果不唯一； 33 | > 可以query('姓名'&'身份证号')，有小概率结果不唯一； 34 | > 进一步query('姓名'&'身份证号'&'户籍地')，那么只有极小概率结果不唯一; 35 | 36 | 上述的这种结果不唯一，可以通过增加查询条件过滤，实现精准查询，且结果不唯一的原因是“可解释”的，如果出现查询返回结果错误，那么我们可以很快定位其原因：查询条件输入错误还是数据库信息错误。 37 | 38 | 用户提出需求，录入查询信息太麻烦了，你们不是有人脸识别么，用人脸来查询多方便。 39 | 作为产品经理，评估这个需求，需要考虑哪些问题？ 40 | 41 | 1. 返回的结果在Top5，但不是Top1，如何解释比较合理，交互和页面如何设计比较友好、直观； 42 | 2. 与“底图”年龄跨度大之后的精度是否满足； 43 | 3. 小孩的人脸识别准确度是否满足； 44 | 4. 现场摄像头怎么安装，光照条件有没有干扰； 45 | 5. 是不是可不去做“为了AI而AI”的事情，建议用户装一个“二代身份证读卡器”解决输入问题； 46 | 47 | 48 | >上述“人脸”这个场景，算法出错的导致的“后果”可能没有太强的“感觉”，因为结果即使出错也没有较大“副作用”。那么我们把场景换一下，换到医疗的X光片或者CT的“AI肿瘤识别”产品场景。 49 | 50 | 51 | 首先需要明确的是：这个场景下，DL出错是要“死人的”，产品经理需要考虑什么？ 52 | 53 | 1 - 理解算法指标的“查准”与“查全”； 54 | 55 | 2 - 理解“漏报”的代价； 56 | 57 | 3 - 理解这种“小负样本”数据集对于模型训练精度的影响； 58 | 59 | 或许有“机灵”的产品经理会说，我们的“AI肿瘤识别”仅仅是辅助手段，还是建议专业医生对结果进行复核，这样就能规避算法错误后的法律风险。但是，如果算法不能做到“**判断没有肯定没有，判断有不一定有**”这个结果，不能协助医生筛选出一部分“肯定可以”不需要人工复核的数据，AI的意义何在？ 60 | 61 | 所以，这也是目前“人脸”能大规模落地“医疗”很少有听到落地的最核心的原因所在：对于误判“会死人”的场景，大家都是极其慎重的。所以某独角兽曾经有段时间在拿到一轮投资后高举AI医疗方向的大旗，然后落地做的还是智慧城市的事情就比较好理解了。 62 | 63 | 希望开胃菜有助于各位理解在产品层面引入了DL之后，给产品经理工作带来的挑战性这个话题。 64 | 65 | ## 挑战一：理解技术 66 | 67 | 一直在反复说这句话：AI或者机器学习技术，是一门综合的边缘技术领域，涉及到多种技术的交叉，做为参与者如果对于相关技术基础没有概念，那会很难去顺利、准确的开展工作。一般情况下，对于产品经理的技术背景并没有“强烈”的要求，没有技术背景并不会是“硬伤”。当引入了深度学习之后，需要产品经理理解深度学习技术基本原理、了解不同任务领域的发展现状及SOTA、理解制约深度学习发展的因素、理解数据集对于深度学习的重要性等。 68 | 69 | 过去产品经理设计产品functions只需要明确输入/输出/交互/UI的要求，代码实现只要没Bug，那么一个function在同样的输入情况下，运行多少遍，结果都是应该可预测和一致的（可以用“[函数式编程](https://en.wikipedia.org/wiki/Functional_programming)”的思想来类比理解下），但是当输入/输出之间是DL算法时，严肃的新问题就来了：结果是一定概率下的准确，且对于结果的错误难以预估与解释。当然[Grad-CAM](http://gradcam.cloudcv.org/)、[Grad-CAM++](https://arxiv.org/abs/1710.11063)给我们提供了更好的CNN模型预测的视觉解释性，但是我们依然无法解释“为什么会是这个结果”。 70 | 71 | 正是这样一个结果“不确定性”的因素的引入，就需要产品经理能够去在一定程度上去理解深度学习，最好能去动手做一些简单的分类任务，去理解机器学习、深度学习、CNN、RNN、LSTM、GAN等常用的基础知识。只有在理解的基础上，才能对“不确定性”有一定的“定性”的理解，而这些理解，才能更有助于产品经理去判断需求的可实现性、对错误的容忍度以及如何去理解场景（尤其是CV类）与边界条件等等。接着“开胃菜”的“AI肿瘤识别”产品来说，产品经理如何去理解这句话：“**判断没有肯定没有，判断有不一定有**”。 72 | 73 | 这句话的表达的意思是：如果模型判断没有恶性肿瘤，那么判断的准确性是100%；如果模型判断有肿瘤，则不一定真的有。如果还觉得理解有困难，用大白话翻译就是：“宁可错杀一百，不可放过一个”。懂了么，要想深度学习“可信”的参与医疗领域落地，对模型的技术指标要求之一就是“可以错判，但不能漏判”。要理解这句话背后“隐藏”深度技术知识，就要从最基本分类评估的混淆矩阵开始。 74 | 75 | ![ch04-01](/res/ch04/ch04-01.jpeg) 76 | 77 | “炼丹师”、“调参侠”对这个混淆矩阵的含义是非常清楚的，以防产品经理有不清楚的，简单解释下基本术语。假设我们的分类目标只有两类，计为正例（positive）和负例（negative）分别是： 78 | 79 | 1. True positives(TP): 真正例。被正确地划分为正例的个数，即实际为正例且被分类器划分为正例； 80 | 2. False positives(FP): 假正例。被错误地划分为正例的个数，即实际为负例但被分类器划分为正例； 81 | 3. False negatives(FN): 假负例。被错误地划分为负例的个数，即实际为正例但被分类器划分为负例； 82 | 4. True negatives(TN): 真负例。被正确地划分为负例的个数，即实际为负例且被分类器划分为负例。 83 | 84 | 对于分类准确性的度量指标常用的有以下几种： 85 | 86 | 1. 正确率（accuracy） 87 | 最常用的评价指标，正确率是被分对的样本数在所有样本数中的占比，通常来说，正确率越高，分类器越好。accuracy = (TP+TN)/(P+N)， 88 | 2. 错误率（error rate) 89 | 错误率则与正确率相反，描述被分类器错分的比例。error rate = (FP+FN)/(P+N)，分对与分错是互斥事件，所以：accuracy = 1 - error rate。 90 | 3. True灵敏度（sensitivity） 91 | sensitivity = TP/P，表示的是所有正例中被分对的比例，衡量了分类器对正例的识别能力。 92 | 4. 特异性（specificity) 93 | specificity = TN/N，表示的是所有负例中被分对的比例，衡量了分类器对负例的识别能力。 94 | 5. 精度（precision） 95 | precision=TP/(TP+FP)，精度是精确性的度量，表示被分为正例的样本中实际为正例的比例。 96 | 6. 召回率（recall） 97 | 召回率是度量有多个正例被分为正例，recall=TP/(TP+FN)=TP/P=sensitivity，可以看到召回率与灵敏度是一样的。 98 | 7. F1-score 99 | 也称为综合分类率，综合考虑查准率与查全率： 100 | $F1=\frac{2 \times precision \times recall}{precision + recall}$。 101 | 102 | 我比较喜欢用“话糙理不糙”的比较接近“人类”语言的方法去解释一些东西，上面这几个指标的含义可以这么理解。accuracy：预测和实际一致的水准；precision：预测是正例中真的是正例的水准；recall：实际的正例被准确预测出的水准，所以，precision一般称之为“查准率”，recall一般称之为“查全率”。如果还不理解，那么建议你去看看[Google机器学习速成课程](https://developers.google.com/machine-learning/crash-course/classification/true-false-positive-negative?hl=zh-cn)，有中文版，而且图文并茂解释的通俗易懂，确实是入门好课程。 103 | 104 | 说了这么多，就为一件事，假设我们有三个models，其查准与查全指标如下表。 105 | 106 | | Models | Precision | Recall | 107 | |:------:|:---------:|:------:| 108 | | Model 1 | 0.89 | 0.57 | 109 | | Model 2 | 0.81 | 0.72 | 110 | | Model 3 | 0.58 | 0.92 | 111 | 112 | 怎么选？“科学”的建议肯定是算F1-score，哪个高用哪个,如果真是这样，我费力码字是为什么？回头再来看看之前提到的“AI肿瘤识别”例子中的一句话“**判断没有肯定没有，判断有不一定有**”。如果我们把“有恶性肿瘤”定义为正例（Positive），那么这句话就可以翻译成：对FN的期望为`0`的基础上Precision越高越好，FN如果为0，那么Recall=1。所以在这个场景下，我们选择模型的思路是Recall最高的情况下选择Precision高的，而不是去用F1-score求综合最佳。 113 | 114 | | Models | Precision | Recall | F1-score | 115 | |:------:|:---------:|:------:|:--------:| 116 | | Model 1 | 0.89 | 0.57 | 0.69 | 117 | | Model 2 | 0.81 | 0.72 | 0.76 | 118 | | Model 3 | 0.68 | 0.92 | 0.71 | 119 | 120 | 理解了么？再用大白话解释一下。这个场景的分类任务，模型一旦预测错误，结果可能会“死人的”，所以，“漏报”是不可接受的，“漏报”在上面的混淆矩阵中就是出现了`FN（假负例）`，所以我们希望FN越小越好，理想值为0 。所以在上面的三个模型中，显然我们应该考虑使用Model 3，而不是F1-score最高的 Model 2。而且，后期我们优化方向应该是优先解决FN下降的问题。 121 | 122 | 一句话总结：**_F1-score是学术界为了综合评估模型的一个指标，在我们实际业务场景中，产品经理一定要能判断对模型的需求是查准还是查全，千万不要教条主义_**。 123 | 124 | 有人可能会有疑惑，这些内容不应该是ML Researcher、ML Engineer去考虑的么，为什么需要产品经理去理解这些技术细节？ 125 | 126 | 从工作分工来说，产品经理要确定业务场景以及对模型指标要求的大致范围，所以产品经理至少需要明白： 127 | 128 | - 错误预测带来的风险有多大； 129 | 130 | - 业务场景的需求是“准”还是“全”，其中哪一个是关键指标，可接受下限是多少； 131 | 132 | - 如何去和用户沟通“准”和“全”之间的“跷跷板”关系，让用户理解这种“不完美”的结果已经是现阶段最佳； 133 | 134 | - 模型训练阶段，通过误差分析，定位到数据集的问题，是否能够理解并与用户沟通“脏数据”的问题； 135 | 136 | - 产品立项阶段，能否客观的预估出一个合理、可实现、可接受的性能指标； 137 | 138 | 顺着这个思路，做智慧城市、公安图侦的产品经理，琢磨下ReID（行人重识别）这个刚需和不同场景的人脸呗。 139 | 140 | 如果产品经理对于机器学习的技术难度、原理与SOTA没有一定认识，那么对于和ML结合的需求评估和分析，如何才能保证准确、无偏差并且没有“不当承诺”？ 141 | 142 | 比如，你是“人脸独角兽”之一的产品经理，去做用户需求调研，用户说“你们公司人脸那么厉害，给我们做个ReID吧。”你一听这东西公司有小组在做啊，肯定没问题，果断答复没问题，可以做。用户说，人脸你们准确度都99%不止了，这个准确度做到98%没问题吧。怎么回答？ 143 | 144 | 说，没问题。那你就是“真傻”，不当承诺的后果，就是回公司之后，给“科学家”们一顿“怒怼”。 145 | 146 | 说，不知道能做到多少，让客户等下，你出去打个电话问问。 147 | 148 | 说，估计98%有点悬，目前主流的ReID数据集是DukeMTMC-reID和清华大学的Market-1501数据集，数据集都不算太大，而且也没有实战中需要考虑的“换衣重识别”等场景，在这个上面先在最好的mAP是……，top1是……，top5是……，这已经是实验室的最佳水平了，我理解的ReID这个事情比人脸识别难度大在于以下几个方面“……”，考虑到实际现场场景肯定比校园校园复杂，指标肯定会下降，但是具体能到多少我也说不好，要回去请教科学家们，要不给我拷点咱们的视频，我回去安排做个测试，结果出来给您个准确数字。 149 | 150 | 哪一个答复最好？显然是最后一个，一方面体现了专业性，一方面体现了严谨性，运气好还能给公司带回去一批数据，即使你给不出用户想要的数据，用户也是会相信你不是在“忽悠”。有关此部分需求沟通对内容，会在[第五章](/chapter-05/ch05_Project-Consulting-and-Solutions.md)再补充。 151 | 152 | 软件部分对需求，不管多离谱，理论上都是时间和成本对问题，不能实现的可能性并不高；但是机器学习领域的需求，在现阶段，确实还存在“给多少钱也搞不定”的情况。所以，产品经理要能够比较得心应手的做好需求管理工作，一定要有一些相关技术背景知识。 153 | 154 | 有关为什么需要ML产品经理具有一定的技术的背景的原因，暂且到此，不再继续展开。 155 | 156 | ## 挑战二：场景理解、业务抽象 157 | 158 | 在讨论场景理解之前，先说一个工程领域的**[Fail-Safe](https://en.wikipedia.org/wiki/Fail-safe)**机制。Wikipedia的解释为：` 159 | In engineering, a fail-safe is a design feature or practice that in the event of a specific type of failure, inherently responds in a way that will cause no or minimal harm to other equipment, the environment or to people.`简单来说就是：**故障不可避免，重要的是故障之后保证安全**。Fail-Safe的机制放在机器学习的落地应用设计中，应该会这样考虑：**预测错误不可避免，重要的是预测错误后代价可接受**。 160 | 161 | 考虑到ML领域大多都是计算机、CS、自动化等专业技术背景居多，对于工程的概念可能不多，举一个可能天天都在接触的场景的例子来加强理解。大多数公司的玻璃大门都用的“电磁锁”，可以很方便的和刷卡、指纹等门禁系统集成。有没有人考虑过一个问题：如果停电了，这个电磁锁是什么状态，开锁还是锁止？按照消防要求，这种电磁锁一般都是失电开启。你想啊，大楼有火警、同时也停电了，你公司的大门打不开了……这多可怕，所以“Fail-Safe”机制一定是失电开启才安全。那么对于非火灾等意外状态下的失电情况下，这种锁岂不是就没有安全性了？所以“Fail-Safe“机制是，在安装的时候配一个小UPS电源来应对意外的停电情况，保证门是锁止的。如果长时间停电，UPS还是会没电的，这种情况怎么办？答案很简单：“铁将军”上场，回忆下是不是每次放长假的时候，行政小姐姐是不是都会最后走，给大门挂上“铁将军”（或者给加班的小哥哥卖个萌，让他走的时候一定帮忙锁好门）。 162 | 163 | 这种设计，就是典型的Fail-Safe机制：失电 --> UPS后备供电 --> UPS失效 --> 门锁开启。 164 | 165 | 正是因为这种Fail-Safe机制的设定，考虑的是故障后门可以打开保证人身安全，所以不能考虑财产安全，这种门锁也只能应用于写字楼的办公场所，因为写字楼有物业和保安，故障失效后的安全保证还有这一道防护。 166 | 167 | 现在是不是对于工程领域的Fail-Safe机制有点概念了？有人或许会疑惑，难道没有机器学习的时候，软件系统就不需要关注这个问题么？当然需要，但是没有深度学习的时候，Bug除外，程序本身的运行是鲜有故障的（比如内存泄露，爆掉了，所以C/C++难啊）。故障一般都出现在操作系统、网络、服务器、存储层面，所以我们会有负载均衡、主从、集群、高可用、故障自动转移、RAID、多链路、冗余、两地三中心等等这些耳熟能详的“容灾”策略。当然，这些都不在本文的讨论范围内，本文仅关注“机器学习推理错误”之后的处理策略。 168 | 169 | 回到“开胃菜”的两个简单应用场景讨论，来分析下“理解场景”有哪些难度。 170 | 171 | 对于“人脸识别”技术来说，不论是SDK还是Serving系统提供APIs，对于业务系统来说“看起来”就是一个需求确定之后的调用问题，并没有什么特别之处。回顾下在[第一章](/chapter-01/ch01_Overview.md)中引用的一张图片。 172 | 173 | ![ch01-01](/res/ch01/ch01-01.jpg) 174 | 175 | 这个场景的需求，可以用一句话描述：行人闯红灯抓拍后，通过人脸图片查询身份信息，分别推送人脸图片、全景图片与身份信息（部分隐藏）到大屏显示，起到警示教育作用。 176 | 177 | 图片的“人工智障”效果就是“按照需求”设计产品，并没有对场景进行分析与推敲，更没有对边界条件与推理错误的后果进行评估与处理。从结果看，技术没问题：要人脸检测，检测到并且推送了；错在产品对场景理解不足，事后诸葛亮的详细分析下。 178 | 179 | 1. 指标选择。这个场景就是人脸检测任务，SOTA精度足以满足这种场景使用，检测结果也不需要做为输入去触发其余业务系统，所以在算法层面，选择F1-score最高的检测算法足矣。 180 | 181 | 2. Fail-Safe机制。由于此系统的使用是公众场合，产品经理“应该”预计到误报之后的结果有可能变成新闻热点，进而影响公司技术形象。为了避免“误报”，应该要求后端业务系统设置一个较高的“置信阈值”。 182 | 183 | 3. 异常分析。场景需求是对“行人在斑马线闯红灯”抓拍，那么检测区域是“斑马线”，检测目标是“闯红灯行人”。检测区域可以通过代码来控制，能够规避异常状况。如图，公交车身广告的“人脸”在红灯时段出现在“检测区域”，所以检测到后做了展示推送，这属于一种异常，产品经理首先要预估到这种异常可能，另外要给出这种异常的处理方案。同理，可以“预测”某人拿一个有人脸广告易拉宝之类的东西闯红灯，显然也是会误报一张人脸的。去研究这些肯能存在的“误报”情况，可以提取出一个共性：非活体人脸的误报。 184 | 185 | 4. 边界分析。基于对异常对分析，那么似乎把检测边界设定为：斑马线、闯红灯、活体、人脸更为合理。 186 | 187 | 5. 技术方案。在这种非约束场景下，如何做活体验证？支付宝之类的眨眨眼、扭扭头，显然不可能了。那么加一个目标检测呢？如果检测到有汽车，然后人脸坐标落在汽车对Box，则认为是异常。这样是可以屏蔽上图的错误，但，如果恰好有人闯红灯，身后通过一辆公交车，这就要漏报了。有没有更好但方案呢？应该有。行人闯红灯过马路，这是一个连续的动作，而非静态动作，而且这个时间长度是几秒以上，我们可以从这里下手。一是可以考虑增加“姿态估计”的联合判断，找到“人体”，通过姿态估计判断是在行走，再去检测人脸；二是可以考虑“轨迹”，检测到第一张人脸后不做推送，而是继续检测，如果连续检测到同一张脸（1:1的识别，计算量也不大，边缘设备也能搞定），而且，计算坐标后可以判断是“过马路”行为，那么再去推送（公交车是横向移动，并非纵向移动），但这种处理，是无法解决“易拉宝上但人脸问题”，所以最优解应该还是考虑姿态估计。还有一种可考虑的方案就是引入深度信息，进行多模态方向的人脸识别。 188 | 189 | 6. 考虑到还需要检索身份信息，这个1:N的人脸任务并不难，但是产品经理需要明确的是底库的库容多大，是百万级还是千万级还是亿级。另外就是要和用户约定好查询返回为空的时候，显示的占位信息是什么。这种小细节最容易忽视，都不提，程序猿小哥哥顺手给你返回个“未检索到记录”怎么办？ 190 | 191 | 所以，通过场景分析，对于这个“行人闯红灯抓拍”项目，我更倾向于将这个项目需求定义为一个“姿态估计+人脸检测/多模态人脸识别”任务。 192 | 193 | 讨论完这个“马后炮”的场景分析，再来说一个“构想中产品”的场景分析思路。 194 | 195 | 先简单交代下背景：前一段时间有个欧洲团队想回国内做算法落地的项目，有工作机会，所以就对接了。核心算法就一个：微表情识别，准备落地的场景是：公检法、教育、风控等方向的情绪识别，产品没看到，只看到Demo，基本和我们做目标检测的Demo差不多的效果。由于在国内的合伙人有一些公检法的资源，所以准备先在这个行业找场景落地。怎么落地，情绪识别之前玩过看了看效果，也没有做深入研究，假设我去规划这个产品落地的事情，我会怎么做？ 196 | 197 | 1. 情绪识别也就是微表情识别，开源数据集也有不少，少则5种多则7种分类，通过微表情判断情绪。通过情绪判断是否说谎，这个事情在理论上有[争议](https://journals.sagepub.com/eprint/SAUES8UM69EN8TSMUGF9/full)，但认为可行的更多，欧盟(希腊、匈牙利、拉脱维亚)在[边检试点](https://www.linkresearcher.com/information/d9493afc-e15f-4317-896b-a07db5415087)基于情绪识别的“虚拟警察”。所以，这个需求可以认为是“刚需”，落地也有案例与场景，可以初步认定产品可以立项。 198 | 199 | 2. 表情（情绪）+ 是否说谎 + 公检法，这几个关键词组合在一起，很自然可以想到“审讯”过程的“测谎”场景。传统的基于ECG、EEG的测谎仪由于是“接触式”相对并不“友好”，如果可以通过摄像头来解决同样的问题，那么在录制审讯视频的同时让嫌疑人“无感”的完成了“测谎”，这样的产品还是有生命力和竞争力的。所以，落地场景可以先确定在“审讯”环节的“测谎”。 200 | 201 | 3. 如果将产品定义为“辅助测谎工具”，这个应用场景怎么分析呢？我是良民一枚，没去喝过茶也没给审讯过，我也没有机会去做调研，但是做为一个“自我感觉良好”的“优秀全干型工程师”，做这种小产品的设计，不需要调研，闭门造车就行了，毕竟，谁还没看过电影、电视剧啊，这种场景肯定看到过么。 202 | 203 | - 一般情况，都是一人问，一人记录，同时全程录像 204 | - 按照Demo的效果，可以拿实时视频流做推理，然后分析情绪，给出置信度 205 | 206 | 4. 最简单的方案（这也大概就是欧洲团队目前准备卖出去的方案）：增加一个摄像头近距离对着嫌疑人的脸拍摄，审讯人员桌前放一个电脑屏幕，实时推理后，做个展示界面，把分析的的情绪展示出来。这样做和“行人闯红灯抓拍”有什么差异？做出来的东西是没有生命力和竞争力的，纯属闹着玩、做玩具。 207 | 208 | 5. 我准备这样规划这个产品： 209 | 210 | * 既然要全程录像、归档，那么就有备查和检索的需求，而且如果增加表情识别的摄像机，这一路视频理论上也需要录像、归档。 211 | 212 | * 同步记录一方面需要对方签字确认，做为案件卷宗形成证据，另一方面就是备查，那么这个文本和视频应该需要有一定的关联性； 213 | 214 | * 为了视频存储后方便查看与检索，这个视频是需要“结构化”的，否则要检索视频只能“快进”太没有科技含量，且浪费时间； 215 | 216 | * 在案情分析的时候，可能会对嫌疑人的某几个问题的回答存疑，需要集体分析，找卷宗询问记录比较快，但是文字是冰冷的，只有配合情绪、表情与肢体动作后，语言才会鲜活起来，经验丰富的专家才会更好的作出判断。所以，能够方便的检索视频，应该是一个系统使用过程中的“次生”需求，那么这个检索方式就应该是“视频结构化”的时候需要考虑到的； 217 | 218 | * 可以考虑，语音转文字，配合视频时间戳，就可以实现通过文字检索到对应视频位置； 219 | 220 | * 通过情绪识别，现场可以看到在回答问题过程中的情绪波动，同样可以把“情绪”做为视频结构化的一个维度，通过时间戳与视频关联； 221 | 222 | * 稍微有点常识并对这个领域做点研究，就会发现其实，视线(Gaze Tracking)、肢体语言(Pose Estimation)及语音情绪识别(Speech Emotion Recognition)与面部表情进行联合判定，似乎更有说服力，所以，系统应该预留此类推理功能，及多个视频结构化的维度； 223 | 224 | * 考虑到存储越来越便宜，摄像头也不贵，可以在工程方案中设定3或者5路摄像机，分别从不同角度拍摄并录像； 225 | 226 | * 审问现场的监控屏幕显示正对脸的近景和全景画面，并给出情绪波动提示； 227 | 228 | * 在算力闲时，进行整体结构化、语音转文字分析和打标签； 229 | 230 | 这样做下来，整合了视频存储、结构化检索、情绪分析、测谎以及语音转文字，是不是像个有竞争力，且具备完整功能的产品了？ 231 | 232 | **_特别提示：上述产品设计已申请专利，如有厂商准备采用此方案做产品，请与本人联系！！！_** 233 | 234 | 通过两个场景分析的例子，是不是对于理解场景有点感觉了？DL的产品难就难在：任何产品化的尝试，都是创造一个全新的应用方向，用户很难给出明确的需求，要求我们的DL产品经理**依据对用户场景的理解，用最合理的方式将DL嵌入用户业务，同时还要考虑清楚推理错误之后的代价**。 235 | 236 | 对于有一定行业经验或者工程经验的产品经理，理解用户场景这项工作并不是非常困难，但是在增加了DL模型推理后，使场景理解这件事变得困难了。在行业内做传统的业务系统的产品经理，大多缺乏深度学习的技术背景，具有深度学习背景的产品经理，大多都是近几年才有的，也鲜有行业背景与经验，甚至对于 to B/G 领域的软件产品设计都没有相关经验。 237 | 238 | 机器学习这样一个边缘、前沿的技术领域为to B/G 产品经理带来的场景理解的难度，估计在很长一段时间都会存在的。解决方案只能是用群体智慧解决单体知识的欠缺，让“懂机器学习”和“懂行业”的两组产品经理**协同工作、知识互补**。这一点，对于AI领域创业公司的HR部门来说，在招聘过程的简历筛选过程中一定要意识到：虽软传统软件行业的产品经理、咨询顾问、项目经理可能不是985/211，也没有“大厂”背景，甚至年龄也过35，但是这批人具有的能力、知识点和技能，恰好是可以和DLer互补的。 239 | 240 | ## 挑战三：需求判断 241 | 242 | 需求判断实际上与场景理解、业务抽象属于孪生任务：要更好的理解需求以及需求会引发的潜在、次生需求，就应该先理解需求发生的业务场景；要更好的分析场景，进一步去抽象业务，那么最好先厘清在这个业务场景中有哪些具体需求，通过需求抽象业务。 243 | 244 | 嗯，绕来绕去，看起来变成鸡和蛋的“死循环”问题了，不要觉得这是“故弄玄虚”，对于理解“场景分析”的重要性，来解释下。实际上，在准备做个产品或者项目的时候，对于这个“工作场景”，一般的输入有两种可能： 245 | 246 | ### Case1: 准备针对某个场景做一个落地产品 247 | 248 | 在启动阶段，产品经理得到的输入是：场景。基于这个场景去做产品落地，那么在产品启动初期，产品经理需要在充分理解场景的基础下，在场景中“挖掘”需求。 249 | 250 | 这种产品开发的场景，产品经理的第一步就是先做**业务场景认知**。 251 | 252 | ### Case2: 拿到一组需求准备做一个落地产品 253 | 254 | 在启动阶段，产品经理得到的输入是：一个或一组需求。基于这组需求去做产品落地，产品经理就需要结合用户行业，去梳理这些需求在什么业务场景发生的，基于需求去找到“场景”。这种情况大多都是项目开发的居多，产品经理/项目经理的第一步工作就是去做**找到需求的业务场景**。 255 | 256 | 脱离场景谈需求，那是耍流氓。 257 | 258 | 明白了吧，因为产品立项的出发点不同，所以产品经理的需求梳理工作还是有所差异的。我们戏虐AI创业公司的行业落地是“**拿着锤子找钉子，看什么都是钉子**”，为什么会这样呢？依据“炼丹师”做出来的算法能解决的问题，似乎是能解决一部分“需求”的，但是这个“需求”没有“落入具体场景”，就只能把算法当锤子，看着差不多像“需求”的钉子，都去敲一下，运气好落地一个项目。但是大多数时候都是不理解行业，又要行业落地，只能是“创新业务VP”去找“钉子”。 259 | 260 | ### 如何去理解需求 261 | 262 | >估计看此文章的，做过B/G产品需求的产品经理比例不会太高，做过“后台”的产品经理估计会稍微多一点，但也不会太多。对于B/G领域的产品，尤其是和用户业务相关的产品都是比较复杂的，要理解业务需求、流程、权限、SSO，做的深入要和原有系统做集成的，还要在需求中明确兼容性要求（没错，尤其是To G 的产品，外网运行的还好点，尤其是涉及到内网运行的产品，在需求阶段就要明确兼容性需求，否则等到现场交付的时候就傻眼了，Win8不让用，Win10政府版还未普及，Win7是主流，XP很常见，没有到SP3的XP也不是稀罕事，所以老老实实向下兼容到IE8，告诉前端小伙伴，jQuery大法好，潮技术都用不上。） 263 | 264 | 对于产品经理来说，一方面年纪都不大，部分刚走入社会1、2年，对于B/G的基本业务流程、组织机构以及一些“通识”的概念没有认识，另一方面对于具体的行业知识、业务知识基本一片空白，这种情况下怎么去做“业务场景认知”。 265 | 266 | 一般对于To B/G 的产品，谈到使用场景的时候，不能忽略一件事：**一切业务、流程，都是和管理相关的，而管理都是有“目的”的**。 267 | 268 | 往下看之前，建议细细品味以下这句话，这句话并非笔者创造的，是我入行的时候我的师傅说的，他让我仔细琢磨这句话，能想明白了，就能“开窍”了。这一章到这里估计要有九千字了，估计都看累了，休息下，带大家回顾一个老段子，来品味下上面这句话的味道。 269 | 270 | >深圳有家奇葩的网络公司，下午五点半下班，六点半有班车，八点有东来顺的工作餐，十点以后打车报销。 271 | 272 | 还记得鹅厂的这个段子么？这种安排，真的是为了实现“**管理的目的**”。大多数互联网公司都是免打卡的弹性工作制度，那么下班就安排班车，意味着会有部分人实际工时不足的，那么延后一小时会解决很大的工时不足问题；如何能在“不官宣、不强制”的情况下让码农们多干几个小时呢？那就8点给管饭吧，反正光棍回去也没地方吃饭；如何让不要吃饱了就跑，再多干点活呢？那就10点报销打车吧。看见没，“巧妙的制度安排”是能悄悄从员工手里“偷出来4个多小时的”。除去吃饭、休息、聊天时间，就算加了2个小时班，也不计较加班2倍工资的事情了，各位鹅厂码农，请心理默默算一下你的日薪的1/4是多少，这就是“管理的艺术”。管理的“目的”显然是降成本，提高人均产值，要实现这个目的，最简单直接的办法就是招技术好的，然后加加班，这样人效比最高。如何才能避免加班导致的员工不满情绪呢？提供看起来诱人的福利（这种套路，我在管理的时候也用……Emmm我也是坏人）再打打鸡血、聊聊福报，这个福利成本对比应支付工资，那是太划算了。 273 | 274 | 提鹅厂的段子，仅仅是为了用身边的小故事来说明白复杂一点的东西而已，望鹅厂海涵，不要人肉我啊。 275 | 276 | 现在是不是对当年我师傅教给我的“哲理”有点理解了。所以，我们理解需求的时候，一定要在场景中去理解；我们去理解场景的时候，一定要去研究场景中的业务流程、业务需求对应的管理目标是什么，这个管理的真实目的是什么。当年我师傅手里同时有3个人，我只是其中之一，别人怎么理解这话的我不知道，但是以我的自身认识来看，通过不断的自我训练，当能做到：**快速熟悉一个行业，看到需求就去琢磨需求的业务场景，琢磨需求的管理意义，琢磨需求的管理目的**的时候，基本上是可以“本能”的去判断需求的实际意义、价值和背后隐藏的真实需求。死不要脸的吹个牛：不止一个人（包括曾经的一位“打工皇帝”）问过我基本类似的问题：你怎么什么都知道，你都没做过的事情，上手干不犯错，结果不比有经验的人做的差，你是怎么做到的？ 277 | 278 | 分享一些我过去使用的、也教过不少入门产品经理使用的方法。 279 | 280 | - 保持好奇心。只要没事干，就看点东西，看什么无所谓，不求甚解，看懂多少无所谓，能多留点印象就好； 281 | 282 | - 养成“类比”的习惯。新知识、新东西可能学习理解比较吃力，但是能在过去的知识中找到“类比”可能理解起来就快很多（我是用了PID控制中的“反馈控制理论”（还好自动化专业没全忘了）去类比了“反向传播”，才算把BP想明白了。），而且这个习惯会帮助你用对方听得懂的“简单”语言，把复杂的事说明白（这个能力对咨询顾问非常重要）； 283 | 284 | - 善用工具，勤于知识体系整理。Google的技巧，合理的目录组织，各种离线阅读工具，笔记工具等，能在日常去做一些系统的整理、收集工作，哪怕稍后阅读变成“再也不读”也没关系，在整理过程中，至少意识到了“资料的重要性”才会去收集（这也是收获），真有用到的哪一天，对这个知识点多少有印象，再去检索也目标清晰； 285 | 286 | - 日常的点点滴滴的收获，在进入新行业的时候，也许就是“快速学习新行业知识”的`N`把入门钥匙； 287 | 288 | - B/G领域只要涉及到流程与管理，那么如“作业指导书”、“岗位说明”、“国标/行标/企业标准”这些类似的文档肯定是有的，对于门外汉来说，看起来很枯燥还很多看不懂，但是一定要“津津有味”的去读，因为所有的流程、场景、管理要求都在里面，所有的需求都是这些“规则”的执行需要而已；而且，做工业企业的项目（比如瑕疵检测、巡检机器人）如果精力允许对于生产流程、工艺流程这些东西，能了解多少也去了解多少，因为这些都是“管理的目的”。我做电力项目的时候，学了整个发电工艺流程，看了锅炉、汽机、电气、热控、化学水、燃料各专业的东西，就为了和人家做流程的需求调研的时候明白人家在说什么；做石化项目，愣是抱着人家的几大本立项说明书看完了炼化厂的工艺流程；做烟草项目，看完作业指导书，让人带着我从烟叶拆包到最后装箱，车间里面跑一圈都看看……自动化专业的优势在这里很明显，理解这些真的快。 289 | 290 | - 有机会去做用户现场需求调研的时候，一个需求涉及多个岗位之间的流程的，一定要每个岗位都问到，而且最好再去这帮人的**领导**那里去调研下，不一定要详细调研流程，但是要问清楚管理目标和意义（不要问为什么，照着做就是了，屁股决定脑袋，这里面的血泪教训能随便写几千字。），这叫：交叉验证； 291 | 292 | - 需求调研的时候，不要胆子太小，多看多问，看看人家桌子上要处理的工作是什么，条件允许，对于需求涉及到的场景去实地看看，对于需求涉及到的工作流程，跟着流程去跑几圈，看看人家日常怎么做的； 293 | 294 | - 刚开始很可能吃不准需求背后的管理诉求与管理目的，没关系反正人家也知道你不懂，大胆问“这个需求的目的是解决什么问题。”，问错了怎么办，说了外行话怎么办，丢人呗。没有里子就没有面子，不怕丢人才学的快啊。 295 | 296 | - 在对需求开始理解的基础上，多反问自己，这个需求不这样做行不行（相信我只要你坚持在B/G做下去，总有一天你能听到这句话：你就按照我这需求做，做出来就是行业标准，你们公司就能拿到别的地方去卖了。）； 297 | 298 | - 理解了工艺流程，业务流程，作业指导书的作业要求，也去业务场景实际看过了，也做过需求调研了，需求明确了之后，开始“幻想”：用思想做需求实现后的用户场景的沙盘推演，判断需求合理性，以及交互是否友好。刚开始做不到一个人的“思想推演”，那就喊小伙伴们一起做沙盘推演。这个环节非常重要，因为做为ITer很多我们以为是“常识”、“合理”的东西，在用户场景下就不一定了，有些需求实现看起来很“完美”，但是实际推演会发现“根本没法用”。我的产品经理的需求评审和原型评审环节，被我骂的最多的就是：你自己把你当用户，你每天都要用，这就是你的工作任务，你这个系统拿过去是添乱还是添堵还是帮人降低劳动强度？细节是魔鬼！ 299 | 300 | - 需求确定，也基本明确了怎么实现是合理之后，去研究这个需求的“管理意义”。比方说8点管晚餐的管理意义就是“主动加班”。只有去研究需求背后的管理意义，那么就会去琢磨这个需求的产生背景，管理要实现的目标，那么就会大概率发现这个管理目标实现后，会潜在“诱发”的新需求以及这个需求是否能满足管理目标。这样就能解决需求管理的最容易出现的两个问题：需求不全面，有漏项；隐性需求在上线后才会出现，要实现系统需要大改动。说个“鬼故事”：在某个公司辞职大概两年后，接到老同事的电话，问我一个需求文档的事情。大致意思是，产品需要升级改版，调研后采集了一些需求，在公司文档服务器上找参考资料的时候发现了一个旧需求文档，内容基本覆盖了目前的需求，因为这些事情当年是我负责，问我这个文档谁写的，当年为什么没有用。答案很简单：五、六年前写的隐性需求，用户就没有提，增加工作量的事情，评审的时候给毙了呗。 301 | 302 | - 基于业务场景，对需求的分析能做到这一步的时候，基本上如果是“伪需求”就自然而然的会给识别出来。 303 | 304 | ## 挑战四：锚定价值 305 | 306 | **锚定效应**（[Anchoring](https://en.wikipedia.org/wiki/Anchoring) effect）[智库百科](https://wiki.mbalib.com/wiki/%E9%94%9A%E5%AE%9A%E6%95%88%E5%BA%94)的定义是：指当人们需要对某个事件做定量估测时，会将某些特定数值作为起始值，起始值像锚一样制约着估测值。在做决策的时候，会不自觉地给予最初获得的信息过多的重视。 307 | 308 | 产品[**Slogan**](https://en.wikipedia.org/wiki/Slogan)是用简短、浓缩且具有冲击力的文字，表达品牌主张或产品的特性、优点及**价值**的商业用语。产品经理在定义产品目标时，实际上就是在构思Slogan雏形与方向。 309 | 310 | 通过产品的**Slogan**，我们试图准确的向用户传递产品的价值，以**锚定**用户对产品的认识与期望。当产品经理在产品中导入机器学习技术的时候，首先需要思考的问题就是：如何向用户传递机器学习技术在产品中的价值。只有锚定机器学习技术导入后对传统技术的指标提升或者具有传统技术的不可替代性，且这种指标提升和不可替代性具有可直观感知的价值，产品才更“说服力”或“接受度”。否则产品形态很可能是“为了AI而AI”，无法让用户“买单”，所以落地困难。 311 | 312 | 换句话说，**_任何机器学习技术无法锚定到产品价值，就是“玩具”_**。当然，这句话删除“机器学习”四个字，依然是成立的。 313 | 314 | 理解了价值锚定这件事，就可以理解为什么当下AI的落地是“人脸”、“推荐”、“机器翻译”、“风控”、“目标检测”、“OCR”等方向是最好的。在这些场景中，机器学习的价值可以很“显性”的在场景中的业务中体现。而“自动驾驶”为何看起来非常热闹，初创公司拿钱毫不手软，真批量落地的只有特斯拉一家呢（你要说蔚来也算批量落地，也行，咱讨论的是“自动驾驶”部分不是“电动汽车”部分，不杠）？用我的逻辑来分析下： 315 | 316 | - 抛开中美之间的车辆密度、驾驶习惯等前提，避免进入意识形态、崇洋媚外的讨论； 317 | 318 | - 不管“吹”到`L几`、路测视频如何看起来不错，但是实际上ACC、车道保持、自动刹车这种L3级别的事情，也到不了99%； 319 | 320 | - 某小*的广告也好，发布会也好，总体在强调“自动泊车”，国内大城市现在的停车环境如此恶劣，好不容易找到个狭窄车位，R档一挂，12个雷达一半都开始报警了，这种场景“老司机”都要靠手艺“多揉几把”才能停进去，“自动泊车”揉一个试试，典型的看起来很美，到哪里找满足条件的停车位呢？实际没啥用的“玩具”功能； 321 | 322 | - 百度无人车是在某些园区运行了，体验过的都清楚是什么状况（不知道的自己Google吧）； 323 | 324 | - 伦理和立法问题没有解决，特斯拉事故出了之后，都是系统无责任，那么用户花钱买了你的“辅助驾驶”，意义是什么； 325 | 326 | 当然，自动驾驶也不是现阶段就没法落地，在“非开放场景”中自动驾驶实际上已经挺好用了，比如：无人码头、自动化仓库等。只不过，在“开放场景”中，我是短期内不看好L3以上可真实落地应用的。 327 | 328 | 说实话“锚定价值”这件事，并不容易，要准确的在各种场景中发现技术的可用性并确定技术的“价值”对于产品经理来说，就是一个修炼与成长的过程。如何去修炼呢？建议从“创造性思维”开始。 329 | 330 | ## 挑战五：创造性思维 331 | 332 | 任何事情，第一个“吃螃蟹”的人，都是伟大的。比如我们中学学习的“几何”，基本还是是公元前300年欧几里得的《几何原本》中的东西，这个创造性思维有多恐怖？ 333 | 334 | 机器学习技术本来已经是一个多学科交叉的边缘学科，当我们试图将其取得的成果导入到现实世界中去应用，实际上都在在做一件“创造性”的事情。在 B/G 领域试图将深度学习技术的成果导入时，以下几个问题必须要解决： 335 | 336 | 1. 理解深度学习技术可以解决的问题“边界”； 337 | 338 | 2. 意识到这些“边界”是和 B/G 某些业务场景有“契合度”的； 339 | 340 | 3. 可以准确判断出算法错误后在这些场景中的“代价”； 341 | 342 | 4. 能够基于场景设计出Fail-Safe完备的机器学习技术导入模型； 343 | 344 | 5. 能够将上述模型在不增加（最好是降低）业务复杂度、成本可控的基础上，抽象、整合入用户现有业务场景； 345 | 346 | 6. 对于新增机器学习技术的业务场景，可以明确其“价值”与“意义”； 347 | 348 | 7. 提供功能完备的完整解决方案而非“功能点”； 349 | 350 | 说到创造性思维，必须要表扬下字节跳动的AI Lab、产品和美术团队，真的是把“人脸”、“分割”、“OpenCV”有关的技术在抖音上“榨”的淋漓尽致。 351 | 352 | 上述7个问题对于产品经理来说，每一项任务都是挑战，做好、做对都不容易，尤其是“价值”与“意义”的抽象与提炼，这个工作的效果，将会直接决定产品“能否卖得出去”。这些问题要很好的解决，需要的综合能力，而综合能力的养成，绝非一日、一时之功。一方面产品经理的综合能力需要时间去磨练，一方面AI创业公司需要抢时间去落地，这件事似乎是个“悖论”，也许这就是当前“AI落地难”的最核心问题：产品力不足以匹配机器学习技术力。 353 | 354 | 这个事情是比较难解决，也不是无解。只要以“科学家”为主的创始人、高管团队能够意识到“传统IT行业”人才的价值，去发现一批在B/G行业摸爬滚打多年做项目的候选人，不拘一格降人才，用他们的行业理解加速深度学习技术的导入，除此之外，只能“赌命”期望几个“产品天才”了。 355 | 356 | ## 案例分析 357 | 358 | `计划结合上述五个挑战，找一个产品来具体说明下产品经理具体该如何思考、工作，确保设计的产品具备可交付、可落地的要求，但是时间有限，准备将这个案例先放一放，后期再补，先开始下一篇。` 359 | 360 | [3.机器学习项目团队组成 <--](/chapter-03/ch03_ML-Teams.md) | [--> 5.项目售前与解决方案](/chapter-05/ch05_Project-Consulting-and-Solutions.md) 361 | -------------------------------------------------------------------------------- /chapter-05/ch05_Project-Consulting-and-Solutions.md: -------------------------------------------------------------------------------- 1 | # 五、项目售前与解决方案 2 | 3 | [4.产品经理的工作挑战 <--](/chapter-04/ch04_Product-Manager-Challenge.md) | [--> 6.产品/项目启动](/chapter-06/ch06_Project-or-Product-Setup.md) 4 | 5 | 在To B/G 领域，项目售前阶段的工作效果、售前团队的工作能力与解决方案编制的“艺术”对获得项目的重要程度是不言而喻的，恰好前几天旷视发布了招股书，引用“量子位”的[姚班系AI独角兽旷视招股书详解：9轮融资95.98亿，去年营收14亿盈利3千万，研发年薪43万](https://zhuanlan.zhihu.com/p/79760944)一文中结尾部分的一段话： 6 | 7 | `有意思的是，旷视招股书中，提及最多次数的关键词，并不是“人工智能”。` 8 | 9 | `而是技术、价值和解决方案。` 10 | 11 | `其中，技术被提及451次，价值被提及475次，而解决方案高达773次。` 12 | 13 | `人工智能有268次，物联网有405次。` 14 | 15 | `所以，全新的AI时代里，“解决方案”会比“人工智能”本身受到更多关注。` 16 | 17 | `Talk is cheap,show me the Solution.` 18 | 19 | ![ch05-01](/res/ch05/ch05-01.jpg) 20 | 21 | （图片来源见图片水印） 22 | 23 | Talk is cheap, show me the Solution. 说的真好。 24 | 25 | ## 项目的生命周期 26 | 27 | 先大致的介绍下一个项目从获取到销售线索开始的生命周期中经历的主要环节，以便没有参与过一个“完整”项目过程的同学们对这件事有整体的认识。前半部分属于销售管理中“销售漏斗”比较通用的几个环节，后半部分是项目管理的基本过程。 28 | 29 | 1. 销售线索阶段。 30 | 31 | 一般是通过各种渠道，包括不限于：Call in，销售经理客户拜访获取，各种展会获取，各种关系推荐等，了解到特定客户对某方面对产品有潜在需求，具体需求细节还需进一步接触后确认。 32 | 33 | 2. 商机确认阶段。 34 | 35 | 对上一阶段的销售线索跟进了解项目基本情况与用户需求后，经过综合判断（各公司有各自的判断逻辑、方法和流程）认为此项目机会值得跟踪，即确认为一个商机。 36 | 37 | 3. 需求挖掘阶段。 38 | 39 | 商机确认后，销售经理会进一步接触、拜访客户相关方，了解项目的详细的需求，以及参与的竞争对手情况，用户决策链，预算，招标安排及交付周期计划等商务相关信息。依据项目的“大小”、“价值”以及用户需求的内容，这个阶段销售经理会期望调动内部售前资源参与需求挖掘与方案引导，但大多管理成熟度高的公司，为了避免在此阶段过多消耗人力资源与成本，会尽量“培训”销售经理，使其能够独立完成这个阶段的需求挖掘工作。销售都不是省油的灯，大多数会在这个阶段适当“夸大”项目情况，以协调、调动内部资源给予支持。 40 | 41 | 当然，这个阶段就有可能有“[PoC（Proof of Concept）](https://en.wikipedia.org/wiki/Proof_of_concept)”的需求，那么就需要售前团队、技术团队、交付团队给予支持了。一般而言，在软件项目售前阶段的PoC主要是：向客户展示其核心关注的需求的产品实现效果以及核心技术参数的满足程度（相信做人脸的这几年PoC阶段测试拼性能和指标的项目没少参与）。 42 | 43 | “全能型”销售在B/G领域，其实是具有很大优势的，所以，才会有“技术转销售”、“售前转销售”这样的职业转变发生。 44 | 45 | 4. 方案推荐阶段。 46 | 47 | 基于上阶段获取的较为详细、准确的需求，结合现有产品、过往类似项目经验，以及行业内同类型客户相似需求的“State-of-the-art”的解决方案标准，编制针对本项目客户需求的“解决方案”，基本套路是：不输于潜在竞争对手的方案“高度”，紧贴、满足并超过用户需求的方案内容。方案整体内容是“高于”客户初始需求的（这样才有可能帮销售把项目“做大”），方案采纳后的“效果”可期，应用“绩效”可观、可测、可量化。 48 | 49 | 这个阶段的解决方案制定工作，有可能需要经过多轮才能让客户满意，对于方案团队“揣摩”用户需求的能力、对行业的熟悉程度、方案编制的水平及演讲能力要求是很高的。大多数情况下，这个阶段客户都会要求“PoC”，看看是不是真的有对应的产品和系统，以避免是“卖PPT”。对于技术复杂、应用面广或者涉及[BPR(企业流程再造)](https://en.wikipedia.org/wiki/Business_process_re-engineering)的项目，用户大多会要求提供相关“案例”、“业绩”并会安排“现场考察”。 50 | 51 | 优秀咨询顾问的方案+演讲能力，具备“让商机起死回生可能”的神奇效果。 52 | 53 | 优秀项目经理的项目管理+客户管理能力，做完一个项目后，项目效果会让各方都满意，用户方对于配合接待“考察”的请求一般都会支持和配合，而且，高概率会帮助“说好话”。 54 | 55 | 5. 项目赢取阶段。 56 | 57 | 这个阶段就是正常的招投标流程了，招投标就意味着“价格战”。设计出优秀的解决方案，让销售经理有机会把项目运作成“单一来源”，无疑是最优的效果了（不得不服阿里，舍得给钱，各行各业的高人都能挖过去，各种玩法都是驾轻就熟，海口4.55亿城市大脑单一来源，余杭区570万的智慧党建也可以单一来源，真是高），或者“竞争性谈判”也是比较好的选项。 58 | 59 | 有关“单一来源”、“竞争性谈判”的具体含义，在《中华人民共和国招标投标法》中有明确定义，怎么在“合法”、“合规”、“合理”的前提下，提高项目赢单几率，并在能赢单的前提下使项目报价最优，这个事情，关键的几个点吃透了，说简单也简单，说复杂也极其复杂，本文不再展开说明。 60 | 61 | 6. 合同签署。 62 | 63 | 这个没什么好说的，投标结束，拿到“中标通知书”后，开始合同谈判，然后签署合同。 64 | 65 | 不中标就是“丢标”回去开总结会，反思为什么吧。 66 | 67 | 7. 项目启动。 68 | 69 | 合同签署后，公司内部自然要成立项目组，任命项目经理、技术经理等，启动项目。对于合同中有要求的，则按合同要求的内容执行即可。 70 | 71 | 8. 需求调研。 72 | 73 | 项目启动后，会按照项目合同约定的交付内容，进行全面、认真的需求调研，以确保充分理解用户需求。基于需求调研成果，会分阶段或者总体对需求调研对成果以及项目解决方案进行沟通、汇报，取得用户认同。 74 | 75 | 需要注意的是，在这个阶段的“解决方案”是要最终交付的解决方案，切记不可像售前阶段一样“吹牛B”，这个阶段还“醉心”于挖坑，那项目八成是要搞砸。 76 | 77 | 项目启动后的“项目解决方案”的内容，看似平淡，就是需求调研，然后参考售前阶段的解决方案，修改修改就能交差。实际上，这件事情非常考验项目经理的“功力”： 78 | 79 | * 不能一味的为了“规避交付风险”，把售前阶段“吹的牛”全部都忽略； 80 | * 通过需求调研了解的信息，对部分内容需要深挖、做实、做细，部分售前阶段觉得重要的需求，可能要降级； 81 | * 依据需求调研过程中对“相关方”（PMBOK第六版之前称为“干系人”）的识别与判断，评估出“一定要实现”的需求； 82 | * 对于售前阶段承诺，但实际交付可能性（指标不满足、功能不能全部满足等）不高的，通过需求调研摸底后，尝试更换新的描述方式，以便项目验收时“好收场”； 83 | 84 | 9. 方案确认。 85 | 86 | 基于需求调研结果、解决方案，会形成最终的“项目需求报告”、“项目解决方案”之类的文档（看具体合同的文档清单要求），一般客户方会有一个评审流程，签字确认后，这份文档就是合同的“关键附件”，将来项目验收最大的依据来源就是这个（套）文档。 87 | 88 | 10. 定制开发。 89 | 90 | 方案确认了，就是开发工作。有高概率合同中是要求“驻场开发”的。现场技术管理如何做，代码怎么管理，是先文档后代码还是老老实实按软件工程过程来；时间短还好说，项目战线拉长，大家都心身俱疲之后，项目经理怎么“忽悠”大家的情绪……等等问题，都需要项目经理和技术经理共同面对，共同解决。 91 | 92 | 11. 系统部署。 93 | 94 | 开发完成，或者基本完成，就要开始部署工作。私有云、共有云、裸机、虚拟机，内网、外网、DMZ、VPN、链路均衡、服务均衡，各种环境都可能遇到，需求调研的时候一定要问清楚部署环境的情况。比如，说好了是Linux部署，要干活的时候才知道要求用“中标麒麟”，之前没有做过测试，怎么办？ 95 | 96 | 12. 用户培训及问题解决。 97 | 98 | 系统上线后，就是测试运行阶段，有问题解决问题，有新需求，就看项目经理的本事（一般而言，基本都拒绝不了），是走变更流程还是增加工作量还是就“认了”。然后就是写各种文档，培训。 99 | 100 | 13. 项目验收。 101 | 102 | 一切顺利，按计划验收，项目经理在职业履历中多了一个项目经验，做的好，过了几年客户还有可能喝酒的时候聊到你，给你打个电话过来聊聊。 103 | 104 | ## 项目售前 105 | 106 | “项目售前”既可以当作名词理解，也可以当作动词理解。一般而言，项目售前的工作大多是由“业务咨询顾问（Business Consultant）”完成的，在[第三章](/chapter-03/ch03_ML-Teams.md)中对Business Consultant的基本工作内容做了简单介绍。 107 | 108 | 咨询顾问在项目售前的工作过程，其实也是遵循“管理咨询”的基本方法、过程和目标的。管理咨询的具体定义在[zh.wikipedia.org](https://zh.wikipedia.org/wiki/%E7%AE%A1%E7%90%86%E5%92%A8%E8%AF%A2)和[en.wikipedia.org](https://en.wikipedia.org/wiki/Management_consulting)还是略有区别，建议可以两边都看看，对比理解。个人觉得英文wikipedia中的这句话：As a result of their exposure to, and relationships with numerous organizations, consulting firms are typically aware of industry ["best practices"（最佳实践）](https://en.wikipedia.org/wiki/Best_practice)，对于咨询顾问理解售前阶段的工作任务的核心非常有帮助。 109 | 110 | 如果一定要对“项目售前”给出一个定义的话，我认为可以是：利用一定的资源，以不同方式向客户阐述“我们是谁”，具有什么样的“技术水平”，基于客户需求、结合“行业理解”及类似项目的“最佳实践”提出针对性的“解决方案”是什么，最后提及“业绩与案例”有哪些。 111 | 112 | ### 销售道具 113 | 114 | 一般来说，项目售前阶段使用的“销售道具”中最重要的资源就是“PPT”，Keynote虽好，但是还是考虑到兼容性建议还是用PPT。当然，PPT也不是全部资源，PPT也不是仅有一套。正常情况下，随着业务的发展和项目经验的积累，售前可用的资源会有以下几类。 115 | 116 | #### 产品白皮书 117 | 118 | 实际上，在产品PRD定稿之后，产品经理和咨询顾问团队就应该着手准备产品白皮书的编写。有关产品白皮书的内容及如何编写，网上相关资料很多，Google下就好。 119 | 120 | 需要注意的是，产品白皮书属于公开资料，内容既要全面、完备，又要能体现产品的技术价值与技术亮点，还要有明显能与友商同类产品产生“竞争优势”的特点与亮点。否则，产品白皮书只能属于“大路货”，无法让受众“记住”。 121 | 122 | 一般的，基于产品白皮书，还需要“浓缩”出一份A4纸大小，正反面印刷的“产品单页”，用于展会发放和销售的陌生拜访递送。 123 | 124 | #### XX解决方案 125 | 126 | 产品白皮书和解决方案的最大区别就是：白皮书仅针对单一产品来说明，而解决方案一般会针对一个或多个业务场景、或者特定的问题、或者某个行业领域，基于多个产品形成对“场景”或“问题”或“领域”的“解决方案”。简单说来就是，如果我们都说不清楚一个产品能帮用户解决什么问题，那么就不可能拿出让用户信服的“解决方案”。 127 | 128 | 还是拿“人脸”来举例。 129 | 130 | 对于“人脸识别”类的白皮书，我们可能会倾向于说明精度、FPS、模型大小、边缘部署、特征点数量、性别/年龄等属性，以及SDK/API/推理等多种调用方式等内容。 131 | 132 | 而具体到不同行业、业务领域的解决方案，需要基于“人脸识别”技术，演化出：公安图侦的人脸识别解决方案，人证合一的人脸识别解决方案，海关打击水客的人脸识别解决方案，人脸卡口解决方案，智慧零售的人脸解决方案等等不同的版本，以应对不同的客户需求。 133 | 134 | 一般情况下，解决方案会有：产品解决方案，行业解决方案，（行业）领域解决方案等不同类型。 135 | 136 | 解决方案矩阵的形成，非一日一时之功，也不是说“挖几个人过来”就能解决的，完全是靠“泡”在一个行业里，日积月累，逐渐形成。挖人可以加速，但绝非挖来的人都是“孙大圣”，说变就能变出来全套的解决方案。如果，真变出来了，一般情况下，可能就要去解决“竞业协议”的法律纠纷了。 137 | 138 | 对于各类解决方案，大多数会使用PPT来制作，少部分情况下会配套编写文本文档。而且，解决方案大多都会由售前顾问、销售经理给客户去讲解，那么为了公司知识产权的保护，风控或者其他具备类似职能的部门，就应该对此类文件的编制、命名、内部分发、外部分发定义好规则和制度，以避免文档的不当外泄。 139 | 140 | #### 产品/方案介绍视频 141 | 142 | 快速向目标受众推广一个新东西，让对方自主阅读长篇大论的文档是最“艰难”的选项，其次是阅读、听取PPT的汇报，最高效、便捷的方法应该是，通过一个3～5分钟的短视频，去完成“核心价值”的“传递”。 143 | 144 | 时间过短，就需要内容非常紧凑，而且在内容组织上也会存在顾此失彼的可能；时间过长，很难确保受众有“足够的耐心”去看完，而且即使看完，也有可能很难“抓住重点”。个人认为3～5分钟是个比较合适的时间范围，即使以压制为720P的视频，文件大小基本在60M左右，以目前手机4G的网络发送也很快。 145 | 146 | 需要注意的是，为了实现效果，我们制作的视频大多会用“动画+实际系统”的模式，但是一定要控制“动画”的比重，否则会给观众“太假”的感觉，另外，整个视频的“台本”、“解说词”一定要精心推敲之后再去制作，毕竟不管是自己UI团队去做还是外包，做一个视频的成本还是很高的。不过话说回来，少开一次意义不大的“发布会”省下来的资金，能做很多销售工具了，钱还是要花在刀刃上。 147 | 148 | ### 方案宣讲 149 | 150 | 我们知道，[**沟通**](https://wiki.mbalib.com/wiki/%E6%B2%9F%E9%80%9A)是不同的行为主体，通过各种载体实现信息的双向流动，形成行为主体的感知，以达到特定目标的行为过程。沟通一般分为“正式沟通”与“非正式沟通”，事实上，方案宣讲也属于沟通的一种形态，也可以有“正式”与“非正式”两种形式。 151 | 152 | #### 方案宣讲的形式 153 | 154 | 最常见的，我们会和目标客户协商，在特定的时间、特定的场合，以一种比较“正式”的方式，通过宣讲方案的形式，向客户介绍相关产品与解决方案。 155 | 156 | 另一种常见的方式是举行发布会或者参加各种展会，通过赞助的形式获得方案宣讲的机会。 157 | 158 | 以上两种都属于比较“正式”的方式，一次性覆盖的目标受众较多。此外，方案宣讲还会有一些“非正式”的形式展开。 159 | 160 | **一对一讲解：** 有可能特定用户对某个方案或者产品感兴趣，但由于各种因素，无法组织“正式”的方案宣讲，则会考虑在办公室，对着电脑屏幕，进行一对一或者一对多的方案宣讲。由于这种场景下，用户不会给你足够的时间去“长篇大论”，也很难配合手势等身体动作辅助演讲，所以，对于讲解者“抓重点”的能力要求更高，要能在讲解过程中快捕捉到用户真实关注的内容，知道如何“跳着讲”，在最有限的时间打动用户。 161 | 162 | **3分钟以内的讲解：** 高级别领导日理万机，有幸约到拜访机会，给你的时间也许就是几分钟，如何能在2、3分钟内没有废话的把事情说清楚，能3、5句话说明白就是到了另一个境界，让领导听明白：你是谁，你能干嘛，你能帮企业干嘛，能有什么效果（绩效），周期多长，代价多大。让领导能快速判断、决策。最优效果就是，能进一步深聊。 163 | 164 | **快速介绍：** 最直观好理解的场景就是“电梯偶遇”，在极短时间内拿到了一对一沟通的机会，抓住重点，说清楚事情。 165 | 166 | #### 有关演讲的一些建议 167 | 168 | 要做好项目售前工作或者做好咨询顾问的工作，至少需要两个能力超越平均水平，才有机会脱颖而出，第一个是演讲能力，第二个是方案组织能力。下面先对演讲方面给出一些我认为有点用的建议。 169 | 170 | ##### 0. 反复试讲 171 | 172 | 看过《史蒂夫·乔布斯传》的朋友，应该知道其中有较大篇幅去写乔布斯在演讲前的准备过程，如果进一步去做一些检索会找到有关乔布斯对于发布会前的准备工作的重视程度和准备过程的更多的文章。有“两个事实”是很多文章都会引用的： 173 | 174 | `撰写演讲稿甚至去找了编剧寻求灵感，在毕业典礼的前几天，一直在背诵文稿，有几次乔布斯在晚饭时向家人朗读演讲稿。` 175 | 176 | `提前两个月写稿，十几个人来对他进行头脑风暴，无数次的演练后，提早两周租下正式演讲的会场，打磨细节。` 177 | 178 | 为什么编号以“0”开始呢？是因为在本章后半部分中有关解决方案的内容中，会有一些PPT制作的建议，其中最后一条依然是“反复试讲”，内容制作的终点就是演讲准备的起点。通过反复试讲，我们可以发现很多潜在的问题： 179 | 180 | * 文档前后逻辑不严密、不严谨，需要优化完善； 181 | 182 | * 行文有瑕疵，看起来没问题，讲出来有歧义或者不够严谨； 183 | 184 | * 上下文之间的衔接过于“生硬”，需要有“桥段”自然衔接（参考下面第三条：准备一个故事脉络）； 185 | 186 | * 部分内容，行文前后不一致，有逻辑硬伤； 187 | 188 | * 对于部分内容理解不足，无法深入展开描述，需要“补课”； 189 | 190 | * 记忆整个PPT的内容顺序和各章节重点，规划每一页的演讲核心，避免正式宣讲出现尴尬（相信大家都遇到或者见过这种情况：对PPT某一页讲了很多，翻到后面几页后，发现其中的内容在前面已经讲完了，只能尴尬的快速翻页）； 191 | 192 | * 依据每次不同的演讲受众和目标，设计针对性的演讲思路； 193 | 194 | * 发现错别字（这一点很神奇，编辑模式下发现不了的，在演讲模式下一眼就能看到）； 195 | 196 | 只有通过大量、反复的试讲练习后，对内容才能游刃有余，对其中涉及到的技术、知识点等做好充分的准备和学习，在演讲过程才能做到收放自如。最关键的，反复练习，能够帮我们克服紧张，并逐渐形成自己的演讲风格。 197 | 198 | ##### 1. 给予而不是索取 199 | 200 | 大多数情况下，我们的演讲就是为了推销某个产品或者服务。即使，演讲的“目的”是如此显而易见，我们仍然应该将演讲的目的、主题和方式转向“给予”。即，演讲的主题的目的并不是希望向听众“索取”订单，而是“给予”听众一些新的知识、思路（最佳实践），以及可以向听众提供哪些价值。 201 | 202 | 即使，演讲的目的就是为了某个产品的成交可能，演讲的过程依然要围绕“提供的价值”展开。在“开放”市场，能够打动用户的，一定是你们的专业性、技术能力以及可以带来的“价值”。 203 | 204 | 恰好，这两天上海2019世界人工智能大会中马斯克和马云的关于AI的对话相关的话题正在发酵，有关双方的视野、情怀等讨论很多。在我看来，一场对话会引发如此“壮观”的讨论，其实就在于两个演讲者的“立意”不同，马斯克全程都是一种“给予”的心态，勾引他说“自动驾驶”的机会都避而不谈，而马云开口就是“Alibaba Intelligence”，真没法理解他这么说的出发点是什么（上海政府搞的AI大会，定位世界，开幕式的压轴大戏，结果Artificial变成了Alibaba，考虑过领导的感受么，不怕过几个月爆点负面么），将自己限定在了“索取”，引发各种吐槽真的很好理解。 205 | 206 | ##### 2. 讲而不是读 207 | 208 | 不要说新手，很多老鸟准备不充分仓促上场，都会犯这个错误。我是真见过对着PPT一字不差、全程念下来的产品介绍。那种感觉，怎么说呢，形同嚼蜡吧。 209 | 210 | PPT只是一个辅助工具，甚至就是一个“提词器”，关键是如何去“讲故事”。优秀的售前，同样一套PPT在不同的场合，面对不同的受众，是完全可以讲出多种版本的“故事”的。 211 | 212 | 切记、切记、切记：不要对着PPT朗读。 213 | 214 | ##### 3. 准备一个故事脉络 215 | 216 | 所有有关技术内容的讲解，除了对于专业听众外，对于大多数人都是很枯燥无味的。如何将一个“解决方案”的讲解，变成“讲故事”般的娓娓道来，是很考验咨询顾问功力的。一个好的故事主题和演讲脉络，在故事中讲解产品与技术，通过故事的场景，让听众有“代入”感，觉得在听的是一件他们能听懂切感兴趣的事情，这个售前活动可能就已经成功了一半。 217 | 218 | 故事怎么准备呢？结合用户的业务场景、需求、产品与技术以及“应用效果”、“应用价值”，在用户的业务场景中去寻找可以突出“效果”与“价值”的故事灵感，让用户感受到真实可信的“价值”。 219 | 220 | ##### 4. 使用通俗易懂的语言 221 | 222 | 很多Consultant在讲PPT的时候，喜欢“中英文混排”，而且夹杂这各种专业术语与英文首字母缩写词，感觉是“高大上、洋味十足”，但是除此之外，似乎并没有特别的价值。 223 | 224 | 如何用浅显的语言和叙述方式把专有技术、专有名词解释清楚，让没有任何专业背景的受众能够理解，这是非常重要的。举个简单的例子：我们去介绍机器学习的算法性能一般都会用Precision和Recall这两个基础指标，对于没有接触过机器学习的“普通人”来说，很有可能听过之后的感觉就是：“这两个单词什么意思，我知道，但是在这个语境中是什么意思，我不知道”。 225 | 226 | 所以，我们在演讲的准备过程中，一定要清楚受众的组成和知识背景，否则就是讲的热热闹闹，听的一头雾水。直白的来说，就是“说人话”的能力和艺术。 227 | 228 | 一般我们介绍存储的时候自然而然会说64GB、128GB、256GB，而Steve Jobs在2001年介绍 iPod 的存储空间大小的时候是这么说的： 229 | 230 | `...this amazing little device holds a thousand songs it goes right in my pocket...` 231 | 232 | 一句话，没有任何专业术语，让所有观众接收到了产品的两个重要信息：容量非常大，体积非常小（2001年，Sony 的 Walkman 还非常流行，磁带还没有退役，CD是主流，MP3流行没多久。所以，在Walkman的体积大到只能挂在皮带上，一个CD只能存储十几首歌的时代背景下，脑补下这句话的冲击力）。 233 | 234 | ##### 5. 善用停顿 235 | 236 | 不论是展会中的站台演讲，还是会议室中的演讲，善用停顿，效果会出其不意的好。比如，通过一个提问，引出下一个话题的时候，通过小小的停顿，给受众思考的时间；比如，发现大家似乎开始走神了，听的兴致不高，突然的停顿，造成“空气凝固”的效果，让受众的思维回归到你的演讲。 237 | 238 | ##### 6. 与听众互动 239 | 240 | 这属于“险招”，没有强大的应变能力和场控能力支持，和听众的互动很有可能会“搞砸”。但是，如果能够适当的通过“问答”等形式，让观众参与进来与演讲者互动，那么能够充分的调动听众的情绪与“认真听”的热情，对于演讲的效果是很有帮助的。 241 | 242 | 另外，在演讲过程中，千万不要紧张，不但不要怕与观众的目光接触，而且应该去主动和观众做目光接触。成熟的演讲者，在演讲过程中通过走动可以和不同方向的观众进行目光接触，进而判断观众的情绪，进一步适时调整自己的演讲策略：是提高音量让大家注意，还是停顿制造突然的安静，还是这一部分大家不感兴趣可以加快，或者这一部分多讲一点，再讲透彻一些。 243 | 244 | ##### 7. 站着演讲 245 | 246 | 因为大多数情况下，售前的演讲都是在会议室中，而如果没有“老司机”指引，很有可能有些人就习惯坐着对着自己的电脑屏幕去“演讲”。见过一个公司的售前来给我们推销产品，看面相也不年轻了，但是全程对着自己的电脑屏幕在“念”PPT，全程与听众没有互动，声音还越来越小。 247 | 248 | 站着讲，一方面可以通过走动、调节呼吸降低紧张感，另一方面可以更好的观察观众的情绪，进一步做场控与后续演讲策略调整。 249 | 250 | ## 解决方案 251 | 252 | 如果要回答：解决方案和白皮书的差异是什么，我觉得应该是：白皮书偏重于“技术细节”而解决方案偏重于“解决问题”。 253 | 254 | 一般情况下，考虑应用场景，解决方案首先都是用PPT来制作，之后才会考虑去编制对应的文本文档。其原因，一方面是PPT相对Word的迭代成本更低，且速度更快，PPT比较是要“讲”的，一页PPT落到Word可能就是几十页的文字；另一方面，PPT的文字内容一般都是提纲，在不同场合下的“可解释性”自由度较大，而落到文字之后，是什么意思就是什么意思，要换一个场景，那就一定要大范围的去修订。 255 | 256 | 对于解决方案这个话题，牵涉到PPT的制作技巧、解决方案的思路设计、同一主题不同版本的区别、常用的叙事结构等等，涉及的主题非常多，如果展开来说，篇幅会很大，为了不拉长本文的“战线”，有关解决方案的内容选择一些我觉得相对重要的关键点进行说明，主要是针对常用的PPT版本进行说明，Word的文字版本的基本思路是一致的，区别就在于Word版本的要写全部出来，难度会更大。 257 | 258 | ### 解决方案的分类 259 | 260 | 考虑到解决方案的实际应用场景和受众目标，一般情况下，只要人手够用，精力跟得上，同样一个主题，会衍生出几个不同的版本。 261 | 262 | **内部版本：** 此版本内容最全面、详实。一般会更多的对技术优势（先进性）、细节进行说明；对竞对的类似产品/解决方案也会深入剖析，找出其优势与软肋，以便突出我放竞争优势；对不用应用模式，不同行业的定位分析等也会比较深入去探讨。换句话来说，此版本是更偏重于内部培训与内部知识积累，一般不可能对外开放，可以将其理解为其余衍生版本的“母版”。 263 | 264 | **售前版本：** 这是最常用的版本，一般此版本都是会提供给客户的，所以，内容全面但会有一定但保留，涉及到细节的东西往往只会有只言片语，具体的解释说明，会在宣讲时展开。 265 | 266 | **阅览版本：** 我们知道，一般做PPT的基础原则是“多图少字”，此版本和售前版本最大的区别就是，更强调文字内容的完整性和完备性。此版本一般不用于售前的演讲环节，而是转为PDF文件，发送给客户去“阅读”。 267 | 268 | **精简版本：** 正如顾问需要具备“三、五分钟”讲清楚一件事的能力一样，精简版本也是用小篇幅去说清楚一个解决方案的核心价值和意图，一般而言，大多数“外发”版本的解决方案，都是此版本。一方面避免客户索取资料，而受限于“保密规定”不能提供的尴尬，另一方面，这种实质性“含金量”不高的版本，大量的扩散出去，也是一种很有效的“市场行为”。 269 | 270 | ### 解决方案的基本结构 271 | 272 | 在B/G领域，要学习解决方案PPT怎么做才能具备一定水准，最佳的参考标准就是找Accenture（埃森哲）的解决方案来PPT来学习，不论是内容组织、内容结构还是PPT的制作水准Accenture 的 PPT 基本都是行业标杆般的存在。 273 | 274 | #### 公司简介 275 | 276 | 这个属于标准操作，可以放在前面，也可以放在最后。要说建议么，有一条在朋友圈看见的“吐槽”： 277 | 278 | 某AI独角兽来做产品介绍，不到二十页的PPT，有多一半在说团队多牛逼，比赛拿了多少名次，说到最后也不知道他们能干嘛。 279 | 280 | 不可思议吧，我看见也觉得不可思议，但是真有人这么“操作”，那还是作为一个建议写出来吧：篇幅不易过多，3页足矣：公司的基本情况、成长情况，有什么资质与产品，做过哪些典型项目。 281 | 282 | #### 背景/现状分析 283 | 284 | 基本就是交代下产品/解决方案设计初衷是什么，想要解决什么问题，这些问题怎么产生的，或者是有了新的法规要求等等，基本就是“格式化”写作。需要提示的就是，问题一定要和产品/方案的“亮点”、“特性”有前后呼应。 285 | 286 | #### 主要目标 287 | 288 | 如果背景和现状分析，不能做到“长篇大论”，单独用一个章节来说的显得较“空”的，可以将目标与其合并。实际上，背景、现状、目标三部分内容放在一页PPT中去说明都是可以的。 289 | 290 | 通过背景交代，现状分析以及主要目标的介绍，一下子就交代清楚了这个解决方案是“干什么”的。 291 | 292 | #### 需求分析 293 | 294 | 如果是针对某个客户的需求做的解决方案，那么这个需求就是用户的需求分析；如果是针对行业、领域做的解决方案，那么这个需求就是背景分析和现状分析中发现的问题。 295 | 296 | 一般情况下，需求分析的整体内容，占全部内容的10%～20%之间足矣，没有必要将大量内容聚焦与这部分，一方面是“解决方案”主要还是说“怎么解决”；另一方面，听解决方案汇报的客户都是这个行业、领域的专家为主，具体有哪些问题，人家比你还清楚，不用班门弄斧，弄不好还要搬起石头砸自己脚。 297 | 298 | 遇到想要帮助竞争对手的，可能在你说问题的时候，就会开始和你“讨论”，最后人家会利用专业知识和行业知识帮你得出结论：“你们认为的问题，在人家眼里根本不是问题。”，那么，你这个解决方案瞬间就没有意义了。 299 | 300 | 商场如战场，各种套路深似海，处处都是学问，要想做成一个项目，机器学习本身，在其中真只有很小的一部分，当大家技术指标差不多的时候，这个技术本身就可以“忽略不计”了，这时候比拼的是其他“实力”。 301 | 302 | #### 方案本体 303 | 304 | 这一部分，是整个解决方案的核心部分，也是最“值钱”的部分，一般的内容组织“套路”如以下几个部分。 305 | 306 | ##### 1. 整体规划 307 | 308 | 先说明整个方案的总体是什么样的，让受众有一个整体的、全局的认识。 309 | 310 | 对于整体规划来说，最重要的就是“**方案高度**”！这个**高度**如何理解呢，简答来说，就是有没有抽象、提炼成“XXXX、XXXX、XXXX、XXXX”这样具有足够“气势”句式；到不了这个标准，起码也要能形成一个排比句。这一类文字，没有概念，不知道怎么提炼？简单啊，多看看“公文”、“红头文件”，看多了，就有感觉了。 311 | 312 | ##### 2. 具体设计与技术 313 | 314 | 这一部分就是对整体规划的详细说明，具体每一部分怎么思考的，为什么这么思考，思考后设计出来是什么样子的，具体用到了哪些“高深”技术等等。这些真没有太标准的模式去“套用”，产品不同、行业不同、需求不同、做方案的人的水平不同，做出来的样子会各式各样。 315 | 316 | 不管怎么组织内容，其核心思想都是一致的：架构清晰、流程合理、技术先进、方便扩展。 317 | 318 | ##### 3. 应用/预期效果 319 | 320 | 此处可按照各种“理想”条件都满足都情况下，最佳都使用效果来“吹牛B”。看不到效果，效果不是超越别人期望值的，谁会买单？ 321 | 322 | ##### 4. 实施方案 323 | 324 | 实施方案部分其实就是要说明一个问题：按照这个整体规划，要取得上述的效果，应该怎么做。 325 | 326 | #### 5. 案例与业绩 327 | 328 | 在方案本体中，把这个事情“吹的”这么玄乎，效果这么好，怎么证明“这不是吹牛B”，这一切都是真实可信的呢？那就罗列出本产品/方案有哪些用户，这些用户都有哪些应用效果。 329 | 330 | 当然，这些案例也不是随便就放上去的。一般的顺序，效果最好的，放第一个重点说明；和目标用户行业一致、需求类似的，能放第一个就放第一个，由于效果一般不适合放第一个的，那就放第二个；而且，用户同行业的案例越多越好。不一定每个项目都要具体说，选几个典型的就好，最后附一张表即可。 331 | 332 | 为什么B/G领域落地很难？这里面其实有一个“鸡和蛋”的问题，没有业绩，谁都不敢做小白鼠；没人做小白鼠，怎么能有业绩。所以，第一个破冰项目都是来之不易的，不要考虑赚钱还是亏本的问题，竭尽全力做好吧。 333 | 334 | ### PPT制作的建议 335 | 336 | 有关如何制作具备一定水准的商务PPT相关的资料、课程，网上是在是太多、太多了，免费的、收费的，一搜一大把，考虑到本章又差不多过万字了，所以这一部分不打算具体展开。之前做内部培训的时候，有一个差不多200页讲了3个多小时的PPT制作的培训课件，有空了单独整理出来，这里仅对我觉得几个重要的内容给点提示。 337 | 338 | #### 1. 注意版权 339 | 340 | 寻找各种资源的时候，一定要注意版权问题，另外，微软雅黑也有版权问题，这都是“老生常谈”的问题了。 341 | 342 | #### 2. 多图少字 343 | 344 | 除了“阅览版本”的意外，尽量不要让PPT页面中密密麻麻都是文字，一方面字多就会小，字号小了之后可读性不佳；另一方面，讲的人照着念也不好，不去解释这些文字的内容也不好；最关键的是“字多必失”，一旦有不严谨的表述，非要有人抓住这个问题开始争论，演讲就可能很难顺利进行。 345 | 346 | 记住，PPT就是“提词器”。 347 | 348 | #### 3. 少用动画 349 | 350 | 见过太多的复杂到不可思议动画效果的PPT，有些人恨不得每一个元素都做出来动画，花里胡哨的出现，轨迹奇异的动作，按一下鼠标出来一个元素啊等等，这种“炫技”，在纯商务的PPT中，偶尔使用可以，而且一定是没有更好的表现形式的情况下才会采用，绝对不要大面积的使用。 351 | 352 | 切记！切记！切记！ 353 | 354 | 如果你们“有幸”见到某人做了一个动画非常复杂的PPT，然后演讲准备工作又做的不充分，讲到后一页之后，又觉得需要切回前几页中的一页中的去阐述，然后开始回退，结果因为动画太多，拼命按鼠标的尴尬，然后，着急啊，按多了之后又过头了，只能切回编辑模式，定位到某一页，然后，这一折腾紧张了，忘了切回演讲模式，就这么开始傻傻的往下讲了……这样一个场景的时候，就知道动画多了之后是多么“可怕”。 355 | 356 | #### 4. 排版一致 357 | 358 | 一套PPT从头到尾，遵循基本一致的排版原则，比如对比类的，始终都是左右形式；强调文字都用色块做背景等等。 359 | 360 | #### 5. 控制色彩 361 | 362 | 最佳的方案是公司UI出一套PPT的色彩标准，做在模版中。在做PPT的过程中，一定要控制对于色彩的使用“欲望”，否则做出来就是花里胡哨的“染缸”。 363 | 364 | #### 6. 统一模版 365 | 366 | 建议由公司UI部门整体出几套模版，并明确使用的场合。模版中约定配色、布局、字体、字号的基本使用规范和样例。这样，只要是一个公司出品的PPT，不管谁去做，呈现给客户的效果都是“千人一面”，一看就是这个公司的东西。 367 | 368 | 这种“公司形象”与“企业文化”的细节性的东西，坚持久了之后，客户都会尊重你。 369 | 370 | 如果不理解，可以Google下咨询公司的PPT模版看看，罗兰贝格、埃森哲、HP、IBM等等这些咨询巨头的PPT模版，看起来是多么简单。咨询行业的“老司机”，看格式、布局、色彩、图文配合，基本就能一眼认出来这是“谁家”的PPT。 371 | 372 | #### 7. 提纲先行 373 | 374 | 做PPT之前，先梳理思路，老老实实用思维导图先把整个结构、目录和各部分重点写出来，先确定提纲，再动手制作。 375 | 376 | 不要指望一版就能定稿，所以细节的润色、增加各种小图标、配图等等的工作都要后移，否则可能为了“美化”一页，就消耗了几个小时，结果整体结构一团糟。 377 | 378 | #### 8. 反复默讲 379 | 380 | 基本成型后，打开演讲模式，老老实实一页一页按照正式场合的需求，默讲几遍。你会发现，每一遍默讲都会发现很多Bug，需要退出演讲模式修改后继续，而且还能发现看似合理的结构，但是讲起来确很别扭，需要调整的情况。等到能顺利的一遍默讲完成后，掐表计时，看看完整讲完的耗时，以决定对内容的增减和各部分演讲过程的收放。 381 | 382 | 我个人的经验是，完整的默讲起码三遍起步。 383 | 384 | #### 9. 反复试讲 385 | 386 | 默讲通过自己这一关之后，邀请几个同事，最佳选择是懂这件事的和不懂这件事的都要有。给他们拉开架势，按正式场合的标准，演讲、推敲、修改，直到大家都觉得没问题之后，再自己默讲几遍，确信一切都OK之后，开始最终的PPT润色，调整布局、字号，选择图片、图标，控制整体配色等等，最终完成一个解决方案PPT的制作。 387 | 388 | [4.产品经理的工作挑战 <--](/chapter-04/ch04_Product-Manager-Challenge.md) | [--> 6.产品/项目启动](/chapter-06/ch06_Project-or-Product-Setup.md) -------------------------------------------------------------------------------- /chapter-06/ch06_Project-or-Product-Setup.md: -------------------------------------------------------------------------------- 1 | # 六、产品/项目启动 2 | 3 | [5.项目售前与解决方案 <--](/chapter-05/ch05_Project-Consulting-and-Solutions.md) | [--> 7.数据采集、标注与管理](/chapter-07/ch07_Data-Collection-Labeling-and-Management.md) 4 | 5 | **Well begun is half done.** 6 | 7 | 万事开头难，所以用上面这句话来开始本章的内容，以示启动环节的重要性。 8 | 9 | 考虑到产品与项目在立项方式、管理模式、执行过程以及目标定义等环节具有一定差异性，本章内容的构思考虑过几个不同的版本（算是为更新慢，找了一个合理的借口），选任何一个方案又觉得似乎都有一定缺陷，要么会导致内容冗长、重复；要么会使内容单薄，不能更好的覆盖全部问题；或者是内容连贯性不够，有支离破碎之感。另外考虑的一件事情是产品/项目启动，这个话题的内容实际上是非常广泛的，如果全部涉及，本章写起来会非常累（我比较懒），所以最终的决定就是下面你将看到的内容：**仅关注产品/项目启动过程中与深度学习相关领域的内容**，其余内容，如非必要不会去涉及。后续再依据反馈（如果有的话），进一步完善、增减内容。 10 | 11 | 为了统一后续文字的语境，先对“产品”与“项目”做出定义。 12 | 13 | `“项目”是指有合同/任务支撑（特殊情况下会没有合同，先做项目），明确了交付目标与交付时间的交付型项目。` 14 | 15 | `“产品”就是我们所理解的普遍意义上的产品，更多的是基于对技术、目标客户、市场竞争等因素综合考虑后做出立项安排，虽然产品的研发过程大多也会按项目进行管理，但产品定义一般是内部可控的，不会更多的受到外部相关方的干涉。` 16 | 17 | 对于产品/项目启动这个话题，在[二、机器学习项目过程](/chapter-02/ch02_Lifecycle-of-a-ML-Project.md)中有简单介绍，仅对关键问题感兴趣的话，可以跳回去看看。 18 | 19 | 在这里，我们需要讨论的产品/项目启动，准确说应该包括启动与规划。事实上，我们在内部立项进行产品研发的过程，还是会遵循一般意义上的项目管理过程的，所以我们首先从PMBOK定义的**项目管理专业范围内知识的术语**入手，了解下项目启动环节，我们需要关注哪些内容。 20 | 21 | `BTW： 和很多参与项目管理的管理者或者拿到PMP证书的朋友沟通过程中，发现大多数人对PMBOK都有一个认知误区，认为PMBOK是一种“项目管理的方法论”，但实际上，PMI对于PMBOK对的定义是：` 22 | 23 | > `PMI 将项目管理知识体系 (PMBOK) 定义为描述项目管理专业范围内知识的术语。` 24 | 25 | `理解 PMBOK 的定位并不是方法论这个重要定义，对我们认知、运用PMBOK提供的知识是非常、非常、非常重要的。` 26 | 27 | ## PMBOK知识点解析 28 | 29 | `本节所引用的内容与图片，均来自于《项目管理知识体系指南 (PMBOK ® 指南) 第6版》（中文版），在此统一声明引用源。` 30 | 31 | 虽然我个人是比较喜欢**尊重理论而不拘泥于理论**的做事方法，以避免陷入“谨记理论的刻板遵从”而忘记了做事**初衷**与**目标**（比如很多公司把 CMMI3 最后执行成了“文档管理”，而忘记了建立CMMI体系其实想解决什么管理问题），但“不拘泥于理论”绝对不是说用“野路子”的“小作坊”模式去解决问题，而应该是： 32 | 33 | - 认知理论与标准规范，理解其“本质”要解决的问题； 34 | 35 | - 理智的评估“范围”、“时间”、“成本”、“质量”四要素； 36 | 37 | - 基于对四要素的评估，结合“理论遵从”去做取舍； 38 | 39 | - 面对四要素的取舍压力时，基于“目的”、忠于“目标”，战术选择性去“忽略”部分要素； 40 | 41 | 用一句通俗易懂的话来解释那就是：在成本有限、项目范围不可压缩的情况下，为了确保项目核心目标的“质量”可控，可牺牲的只有部分过程/文档工作，包括可能也不限于：整体需求文档、概要/详细设计文档、各种评审等。但是，这种刻意减少过程环节的安排基础是：产品经理对需求整体把控能力过关、总体设计可信任、主程对产品需求理解透彻、团队内部不会“甩锅”。 42 | 43 | 有关这种“取舍”选择方法与原则，在 `PMBOK 1.2.5 剪裁(第六版 P 28)`中有具体解释（毕竟实操性的东西最难写，解释其实也挺含混，就是原则层面的说明），有兴趣的同学可以去看看。 44 | 45 | ### 项目管理知识领域 46 | 47 | 我们知道，PMBOK定义的项目管理过程包括：启动、规划、执行、监控及收尾，共五个过程组。其中，启动、规划两个过程组，与本章所关注的产品/项目启动是相关的，具体如下图： 48 | 49 | ![项目管理过程组与知识领域](/res/ch06/ch06-01.jpg) 50 | 51 | 个人认为，我们可以用一种更简洁的方法去理解启动、规划这两个过程组需要做哪些工作： 52 | 53 | - 定规矩（项目章程） 54 | - 定计划（各种计划） 55 | - 知需求（范围管理） 56 | - 知预算（成本、资源） 57 | - 识风险（风险管理） 58 | - 识目标（相关方、质量） 59 | 60 | 此部分内容，暂不展开去进一步解释，后续再补充完善。 61 | 62 | ### 项目的生命周期 63 | 64 | 在PMBOK 的 `1.2.6 项目管理商业文件` 中对项目的生命周期用如下一张图做了解释： 65 | 66 | ![项目生命周期](/res/ch06/ch06-02.jpg) 67 | 68 | 可以看到，在进入项目生命周期之前，还有一部分项目前期准备工作需要完成。个人理解是PMI认为这一部分工作更多的是偏向与组织“商业意图”的工作，一般是由更高级别管理者或者商业团队完成，且经过前期准备的论证后，有可能最终决定是不予立项，所以没有将此部分内容归入项目管理的知识领域。 69 | 70 | > 其实这些内容非常重要，个人认为，有关于项目前期准备的工作是否应该纳入PMBOK的知识领域是值得商榷的。感觉PMBOK会在未来的版本中把这些内容放入融入，也许会增加一个“准备过程组”或者“定义过程组”，将项目管理过程组扩充为六个过程组，知识点从49个变化到52个左右。正如第四版的“干系人”在第五版之后新增一个知识领域，并提升为“项目相关方管理”这样的演进逻辑一样，逐步对“看起来不重要”的但其实非常重要的内容提高权重，这些变化对于帮助项目经理的知识领域的扩展和更深刻的理解项目是有现实意义的。 71 | 72 | 事实上，大多数公司的实际项目/产品的立项阶段，很可能会安排产品经理参与做一些竞品、市场相关的分析工作，对于组织僵化或者“唯上”倾向明显的团队，也有可能是某个领导的“一句话”就立项一个项目。项目经理在着手启动项目的时候，由于项目的“商业意图”不一定经过了严谨的论证与推演，存在 **_项目启动就注定了失败_** 这一高风险可能。 73 | 74 | 由于PMI对PMBOK的知识领域的定义，和绝大多数产品经理/项目经理的自身知识结构与工作背景，以及大多数企业的工作职能/职责划分这种综合因素导致的产品经理/项目经理的知识结构的“**瘸腿**”现状，是我看到的很多产品不成功、项目无法验收的核心原因之一。 75 | 76 | 个人的建议是：**产品经理/项目经理的知识结构一定是足够复合与宽广的，必须要理解与商业行为有关的知识与内容。** 77 | 78 | 对于产品经理/项目经理来说，在项目启动环节，一定要去寻找如下几个问题的答案： 79 | 80 | - 竞对如何做（了解SOTA的思路和做法，并“理解”各厂商产品间的差异的本质原因） 81 | - 价值是什么（可复制性、产品价值、客户价值、社会价值、经济效益） 82 | - 销售如何卖（对于 to B/G 产品，在启动规划阶段就要想清楚销售环节的竞争优势） 83 | - 运营如何推（对于线上 to C产品，在启动阶段就要思考运营问题） 84 | - 收入在哪里（对于 to B/G 产品，需要明确的就是目标客户群体以及定价） 85 | - 用户如何用（认知用户与场景） 86 | - 非预期效应（理想很丰满现实很骨感，产品使用条件部分满足、出错或者其他各种意外因素发生后，结果是什么？） 87 | 88 | 具体解释，暂不进一步展开（每个主题都涉及很多内容），后续再补充完善。 89 | 90 | ## 理解目标 91 | 92 | ### 产品目标 93 | 94 | 在讨论产品目标之前，建议对波士顿矩阵（BCG Matrix）有一定的理解。[en.wikipedia](https://en.wikipedia.org/wiki/Growth%E2%80%93share_matrix)、[zh.wikipedia](https://zh.wikipedia.org/wiki/BCG%E7%9F%A9%E9%99%A3)、[mbalib](https://wiki.mbalib.com/wiki/%E6%B3%A2%E5%A3%AB%E9%A1%BF%E7%9F%A9%E9%98%B5)、[百度百科](https://baike.baidu.com/item/%E6%B3%A2%E5%A3%AB%E9%A1%BF%E7%9F%A9%E9%98%B5)的解释建议都看看，这个词条百度百科的内容还是挺不错的（对于擅长买药的百度同学，该表扬还是要表扬）。波士顿矩阵将产品的类型划分为了四类：瘦狗、问题、现金牛及明星，分别代表四象限中的一个。企业所有的产品，经过合理的分析之后，都会落入四象限中的一个，依据产品的类型，会有具体的行动建议。 95 | 96 | 波士顿矩阵是市场、销售部门常用的分析工具，产品经理大多很难接触到这个名词，并参与相关的分析工作。但是，个人认为产品经理需要对波士顿矩阵的四象限有一定的认识与理解，这样在做产品目标定义，尤其是产品迭代过程中的目标方向选择时，才会做出更“理智”的判断。只有理解了四象限的定义，我们才会理解： 97 | 98 | - 为什么有的产品看起来还行，但是公司给砍了（瘦狗） 99 | - 为什么有的产品卖的挺好，看起来也有可以改进的问题，但是公司不采纳升级建议（现金牛） 100 | - 为什么有的产品卖的并不算好，但是公司在投入大量资源进行升级（问题） 101 | - 为什么公司会突然成立一个事业部，把某（几）个产品放入事业部单独运营（明星） 102 | 103 | 这样的商业行为与决策选择。 104 | 105 | 个人认为通过对波士顿矩阵四个分类的理解，对于产品经理最大帮助应该就是理解产品的“最终可能”，进而可更好的认识与理解产品定义阶段的目标认知与选择。 106 | 107 | #### 产品定位 108 | 109 | 任何产品，在立项阶段明确定位都是很关键的工作，定位的偏差很可能直接导致产品的早早夭折。 110 | 111 | 对于 to B/G 领域的产品来说，80%的我们以为的“新产品”都有友商已经在做，做好前期调研与市场分析工作就显的很重要；剩下的20%的“新产品”或许在公开市场上确实找不到“可对标”的产品，但是也不要乐观的以为“发现了市场空白”，先去思考下：**为什么这个事情没人做。** 112 | 113 | 通过项目前期的商业分析确定需要立项的产品，在确定产品定位的过程中建议至少需要思考以下问题： 114 | 115 | - 最终用户是谁，最终用户会如何使用产品 116 | - 最终用户使用产品的场景有哪些 117 | - 竞对的产品形态如何，优缺如何 118 | - 公司对于产品的期望定位是什么 119 | - 防守型产品：竞对都有此产品，属于产品链补全，避免存在短板给对手抓住机会 120 | - 挑战型产品：竞对有类似产品，但均存在明显短板，我司产品可在对方短板发力，获取市场机会 121 | - 试水型产品：产品定位尚属于蓝海，存在不确定性，但值得尝试，基于市场反应灵活调整 122 | - 跟随型产品：竞对此类产品属于BCG Matrix的“明星”类，照猫画虎并针对我司优势加以改造，搅动市场 123 | - 定制型产品：基于特定客户的特定需求“定制”的产品，有可能加以改造后形成通用化产品（一般我们说的“用项目养产品”，大多都是此类产品） 124 | - 公司内部“相关方”对于产品的定义是如何思考的 125 | - 市场、销售等直接面对客户与市场的人员对于产品定义的思考 126 | - 直属领导、分管领导对于产品定义与定位的思考 127 | - 公司决策层对产品定位的要求 128 | 129 | 必须要“认清”的一件事情是，对于**产品定位**这件事，更多体现的公司决策者的“意志”，所以对于产品经理而言，正确理解这件事情非常重要，否则很有可能“南辕北辙”，做的非常拼命，方向却理解错了。 130 | 131 | #### 产品周期 132 | 133 | 任何产品都是有生命周期的。在理解产品定位与产品目标后，应该能够快速判断出产品的周期，具体可能需要结合以下内容思考： 134 | 135 | - 特定行业特定场景的特定需求，复制可能性较低，后续升级可能性较低 136 | - 通用技术的不同场景应用，可考虑抽象通用性部分，后续有可能在应用层面有多种变化 137 | - 技术在场景内找落地可能性的验证性产品，后续存在大概率改版甚至推到重来 138 | 139 | 对于产品周期的判断，可以帮助产品经理对未来一个阶段的工作有一个总体的认识。短周期产品，仅仅关注眼前需求确保按期交付即可；而长周期产品，则需要在设计之初，就需要考虑未来升级、迭代的变化可能性，在产品架构层面预留足够的灵活性。 140 | 141 | ### 项目目标 142 | 143 | 相对与产品而言，项目因为有明确项目目标（合同/合同附件/技术协议 等），在启动阶段项目经理需要关注的重点工作其实并不多： 144 | 145 | - 精读并尽可能去理解项目合同相关文本中对于项目目标的描述 146 | - 与项目前期售前阶段参与的同事沟通了解项目背景情况 147 | - 明确项目工期要求 148 | 149 | 此外，对于项目目标还需要做一些延伸思考与分析： 150 | 151 | - 这个项目的目标，尤其是目前看起来是“个性化需求”的东西，有没有可能产品化 152 | - 目标是否存在客户对SOTA以及“最佳实践”对认知不足，并没有完全表达出在客户行业此类应用应该有的目标 153 | - 目标中是否存在明显的“**不当承诺**”，这些承诺销售和售前会解释为“不这么写，合同就拿不下来”。这些都是明显且非常大的项目风险点，应该在启动初期就着手做风险管理与应对预案 154 | 155 | ## 确定相关方 156 | 157 | “相关方”在PMBOK之前的版本中称之为“干系人”，不论是产品经理还是项目经理，在整个工作过程中**找到**并做好相关方的**沟通**与**管理**工作是非常重要的，一般而言，对于**相关方**我们需要从两个“视角”去观察、确定和认知。 158 | 159 | **视角一**，按相关方的决策权重去观察、确定： 160 | 161 | - **参与但不决策** 162 | - 主要是项目/产品执行过程中的绝大多数参与人员，或许会给一些建议，但大多不参与决策或者说“没有决策权”。 163 | - **参与且部分决策** 164 | - 项目/产品的核心“玩家”，一般在组织内部具备一定的“地位”，所以在活动过程中“天然”具有一定的决策权。 165 | - 这部分参与者由于对工作整体过程介入较深，一般会给出“相对正确”的判断。 166 | - **决策但不直接参与** 167 | - 项目的核心决策机构人员，主要就是“领导”。 168 | - 给出项目目标、要求和方向，不会参与工作具体过程，但会阶段性听取汇报，并作出判断。 169 | 170 | **视角二**，按相关方对项目/产品的支持/重视程度去观察、确定： 171 | 172 | - **参与且支持** 173 | - 基本上是项目/产品执行过程中的绝大多数参与人员，或许在部分细节会有不同或者保留意见，但大多情况下会对工作的推进提供积极且正向的支持。 174 | - **参与但无明确倾向性** 175 | - 很有可能是“被动”情况下参与相关工作，工作对他来说仅仅是“工作”，一般情况下会按要求工作。 176 | - 这部分参与者可以在过程中施加影响，逐渐使其积极、正向支持工作。 177 | - **参与但不一定支持** 178 | - 一般情况是“被动”参与，或对于产品/项目的部分内容存在个人不同意见，但这种不同并非不可调和。 179 | - 这部分参与者可以在过程中施加影响，逐渐使其放弃或者能接受不同观点，做到求同存异，共同推进工作。 180 | - **参与但不支持** 181 | - 基本可以理解为产品/项目过程中最大的阻力来源，由于其个人观点（或其代表的利益方的观点，这种属于“政治”层面高级玩法，本文不探讨，后面如非必要也不会特意说明此类问题。）与整体目标存在较大差异，但做为一份“工作”，其还需要参与其中。 182 | - 最好期望不要出现这种相关方，一旦识别到此类相关方，首先应列入“风险管理”内容中，按照一个风险源来管理。 183 | - 如果能求同存异、在一定共识基础下配合工作推进，则可想法就其关注的内容优先且超期望满足，以换取其支持。 184 | - **不参与且不支持** 185 | - 基本可以理解为“旗帜鲜明”的“反对者”。 186 | - 一旦识别到此类相关方，做为高级别风险来管理，需要有高级别领导出面进行早期干预。 187 | - **不参与但支持** 188 | - 一般而言就是项目/产品立项及核心目标提出的“领导”，是项目最重要的“政治”支持来源。 189 | - 按阶段汇报工作，切记汇报工作不要“只报喜不报忧”，也不要“只说问题不提进度”。 190 | 191 | 通过“视角一”，我们是去发现在产品/项目过程中的主要决策者有哪些人，以及他们决策的依据是什么；通过“视角二”，我们要能明确的知道过程总哪些人会“帮助”、哪些人“立场中立”、哪些人“负帮助”。 192 | 193 | 比如，当你发现是“负帮助”的人在给你建议，并做出了“决策”，那么你就应该知道这样的决策是“真执行”还是“假执行”或者通过一定的技巧去“拒绝”了。 194 | 195 | ## 厘清需求 196 | 197 | 研发管理模式从“瀑布式”进化到现阶段取得广泛认同，与大量IT企业选择实践的“DevOps”，最重要的驱动因素之一就是“需求响应”迟缓。但是，我们应该意识到敏捷开发的“用户故事驱动、快速迭代”并不是说“需求管理”可以降低要求，边做边思考，走一步看一步。对于需求的理解深度与程度，是应该理性对待的，对于找到一个“老司机”可以“完美”的定义出来完整的需求，这种美好的“期望”不是不可以有。但是，我们必须认识到一个现实的情况：好的产品经理本来就极其难得，再叠加进入B/G行业的需求与AI的算法相关知识，这样的“老司机”市面上真的存在么？ 198 | 199 | 所以，在“理想人选”有可能终将不可能到位的情况下，我们依然要选择用现有的人力、脑力、心力，用合适的方法推进工作的进行，最简单、有效的需求梳理方法应该就是：**分类**、**分级**。 200 | 201 | ### 需求分类 202 | 203 | 不同的团队文化，不同的对事物的认知方式，都会影响我们对事情“分类”的视角和思路，建议可以按以下分类角度来厘清需求。 204 | 205 | - 必须实现需求 206 | 207 | 这个比较好理解，就是一个产品/项目的基础核心需求，这些需求中的任意一个不能按需求实现，就会影响一个产品/项目的立项基础，直接影响成败的需求。 208 | 209 | - 锦上添花需求 210 | 211 | 此类需求可以这样来理解：不能实现，不影响产品/项目实现的基础；但是，如果实现，会让产品/项目在某方面具有更加打动客户的能力。 212 | 213 | - 防守型需求 214 | 215 | 此处的“防守”是针对“竞对”而言的，做为PM我们必须要认识到一件事：你在做的事情，竞对也在做，而对同样类型的事情，基于技术储备、行业理解、接触到的客户的“引导”等因素，竞对间的理解一定会有异同。这些相同的内容，基本就是“必须实现需求”，大家都会做；而不同的内容，由于各家公司的市场能力、宣传投入及客户资源是不同的，就会出现这种情况：我司觉得并不重要的功能需求，被友商“吹上了天”，也成功的教育了市场与客户。那么，此类需求，对于我方来说，就是“防守型需求”，因为如果不做，就明显让竞对的策略取得效果，只能选择跟随、防守（虽然不一定情愿做）。 216 | 217 | - 进攻型需求 218 | 219 | 与防守型需求对应，有些需求竞对可能受限于技术、行业理解等因素，选择性不去关注或者刻意回避，而我方的理解是在此类需求中可以产生竞争优势与竞争区隔。此类需求，从本质上来说不一定是必须实现的核心需求，但是做为“进攻武器”可以选择实现。最典型的可能就是“人脸特征”从96点开始不断的提高，做为用户并不知道人脸特征点数据有多少是“合适”的，厂商之间做为一种“核心能力”在不断提高，以展示其相对竞对的技术优势。 220 | 221 | - 其他需求 222 | 223 | 非以上需求，无法合理归类，基本都可以放在其他。 224 | 225 | ### 需求分级 226 | 227 | 对于需求分级这个任务，并不需要太多高深的理论去支撑，用非常“传统”的符合直觉（当然，这个直觉是需要有一定经验积累的，否则哪叫“瞎搞”）思路去做就足矣。 228 | 229 | - 重要且紧急 230 | - 重要不紧急 231 | - 不重要但紧急 232 | - 不重要也不紧急 233 | 234 | **重要且紧急**这一类显然是高优先级任务，一般来说基本上都是**必须实现的需求**和**进攻型需求**，这是比较好理解的，重点在于怎么去理解**不重要但紧急**的这一类任务。要理解并能正确的分类这一部分任务，首先我们需要做的是“视角转换”或者说“站在对方的角度”去思考问题。 235 | 236 | 作为技术/产品/服务/项目供应商，我们不可避免的会先入为主的基于我们对任务的理解，去分类任务、定义需求。但是，一定要**清醒的意识到**我们努力工作的目的是什么，即：为谁提供服务的问题，套用一句前段时间某综艺节目中“爆红”的一句话：**我不要你觉得我要我觉得**，我们的认知因该是：**_我不要我觉得，我要用户觉得_**。当然，最理想的状态就是能开启“上帝视角”，站在更高层面去思考需求与任务分类。 237 | 238 | 另外，对于“防守型需求”虽然在我们的计划中，可能会考虑将优先级定义为较低。但是，一定要首先想明白这个问题之后再做最终决定：这类需求不及时实现，我方会在市场竞争态势中失去什么？ 239 | 240 | ## 认知客户场景 241 | 242 | 不管我们的目标是做一个通用化的产品，还是定制或半定制化开发去交付一个项目，我们的目标都是“Shift AI Models to Real World”。要能让我们机器学习训练的模型在用户场景中发挥作用，首先我们需要做的事情就是：认知并理解客户场景适用的算法模型特征是什么。 243 | 244 | 虽然，深度学习的引入使得**特征工程**显得并不那么重要了，我们只要把数据标注好，丢进DL拿到训练后的模型就可以做inference了。但是，客户实际场景和我们之前丢进DL的数据看起来是差不多的，解决就能保证满足需求么？举一个例子。 245 | 246 | ### 案例 247 | 248 | 在之前的项目中，我们有一个需求是“集装箱号OCR”。OCR这件事情，看起来现代技术已经非常成熟，各厂商提供的OCR API有很多可选用，还有什么难度呢？ 249 | 250 | 最理想的状态下，我们可能是在这种角度下进行集装箱号的OCR。 251 | 252 | ![理想场景](/res/ch06/ch06-03.jpg) 253 | 254 | 实际上可能是这样的俯仰角度： 255 | 256 | ![俯拍角度](/res/ch06/ch06-04.jpg) 257 | ![仰拍角度](/res/ch06/ch06-05.jpg) 258 | 259 | 还有可能是这样的竖排或者不在一个平面： 260 | 261 | ![侧面竖排](/res/ch06/ch06-06.jpg) 262 | ![侧面横排](/res/ch06/ch06-07.jpg) 263 | 264 | 也有可能不在一个平面还会有残缺： 265 | 266 | ![残缺不全](/res/ch06/ch06-08.jpg) 267 | 268 | 大家有兴趣的话，可以拿这些图片丢到各厂商的通用的 OCR 中测试下效果。 269 | 270 | 可以看到这个任务虽然是一个OCR任务，但是由于客户场景的需求，导致了这个任务并没有听起来那么容易： 271 | 272 | - 关注的是集装箱号的OCR识别，但集装箱上有很多文字，别的文字提取并OCR是无意义的 273 | - 集装箱号在多个位置都有喷涂，不同位置OCR难度不同 274 | - 集装箱号的喷涂形式、字体，并无行业标准，仅有默认共识 275 | - 无法提前预判集装箱哪一个面会对准监控摄像机 276 | - 通用的OCR数据集并不能取得很好的预测效果 277 | - …… 278 | 279 | 对于这样真实客户场景，你说我有OCR识别算法，就能“搞定”项目交付么？显然可能性不大。有关这个任务的具体思考与落地实现，可以参考我另外两篇文章： 280 | 281 | [Container detection and container number OCR](https://lonelygo.github.io/2019-01-20-container-detection/) 282 | 283 | [使用Tesseract训练并识别集装箱号](https://lonelygo.github.io/2017-07-27-tesseract_ocr/) 284 | 285 | 正如我在[Container detection and container number OCR](https://lonelygo.github.io/2019-01-20-container-detection/)中提到的，对于这个特定的OCR任务，其实就是26个字母+10个数字识别问题，做一个36分类的目标检测其实也是可以搞定的。放一张用Yolo v3目标检测方式实现的“OCR”效果(图片来源：长春理工大学 崔循 硕士研究生毕业课题论文准备阶段的实验结果)。 286 | 287 | ![目标检测实现OCR效果](/res/ch06/ch06-09.jpg) 288 | 289 | ### 认知客户场景的几个关键思考 290 | 291 | 通过上面例子中的介绍，我们可以看到一个“OCR”任务，在最终交付落地的时候，其实变成了“目标检测+OCR”或者“目标检测+目标检测”的ML模型实现，与最初销售带回来的需求“客户需要一个集装箱号的识别”相比，事实上是做了任务扩展与定制化模型训练的工作。那么，我们在接到一个“任务”后，应该如何去结合用户场景去思考任务的真实需求呢？ 292 | 293 | 个人觉得这件事，并不一定会有**标准答案**和**指导手册**，需求的不同，客户的不同，任务来源的不同等因素都会影响这个“场景认知”的过程和方法。但是，个人认为有一些通用的方法是可以借鉴和采用的。 294 | 295 | #### 熟悉客户业务 296 | 297 | 熟悉业务，这句话简直就是废话，不熟悉人家的业务，怎么去理解业务，理解场景？所以，正确的废话也很重要。 298 | 299 | 在To B/G 领域，一个重要的核心竞争力就是：**_对用户行业与业务的熟悉程度_**。熟悉并理解客户的业务最大的优势就在于对于AI落地这件事情，我们只需要去关注如何结合用户现有的业务活动，将AI创造性的“嵌入”现有业务过程中，并发挥一定的价值。但是，对于大多数AI创业公司、新玩家，内部基本上都没有此类业务专家，所以要么去行业内传统软件公司去挖人，要么与这些公司合作。其实就是一句话： 300 | 301 | > **各行业领域的传统软件公司看起来做的事情比较“土气”，在现阶段要想算法落地，没有这些公司的参与或者这些公司培养的行业专家的参与，AI创业公司们要想算法落地，基本玩不转，且付出的代价也很大。** 302 | 303 | #### 理解对方语境 304 | 305 | 新手项目经理或者咨询顾问最容易犯的错误之一就是：**_以为自己听懂了用户表达的需求_**。 306 | 307 | 对于to B/G 的项目，这种情况尤其容易发生，一方面要学会听懂话外的意思，另一方面要明白对方的立场和对项目的想法，而且还要参考对方说出需求的场合。有关这个问题，是比较复杂和考验对人性、管理、体制以及权力的认识的，要展开的话，这一个主题就可以写几万字了，所以此处不再继续展开说明，仅做一个提示。 308 | 309 | 举一个例子： 310 | 311 | > 背景：刚工作不久做菜鸟项目经理的时候，去做需求调研，有一个业务流程，涉及到三个部门间的流转和处理。 312 | > 用户方安排的是逐部门需求调研，同样一个流程，主体虽然解释的都一致，但是在三个部门间听到了三种不同的细节处理方式和要求，而且每个部门都告诉我，听他们的没错：“就按这个做”。 313 | > 不得不说，**抽烟这件事情有时候真是好事情**。不小心在吸烟室遇到了三个部门负责人都在（两个来吸烟，一个不吸烟但是跑过来休息），于是就把我对这个流程的疑惑说了一下（当然作为曾经的学生会主席，我不会傻到乱说话），只说了我理解的主体，和三个部门都说的一致的内容，而有差异的部分只字未提。结果不出意料，三个部门在一起说的时候，就不能有明显的对自己这边有利的倾向性了，于是我算是得到了第四个版本的需求。 314 | > 隐约觉得这样的“非正式沟通”拿到的需求，虽然各方都能认同，但是很可能“并不是他们真实意思”的表示。但是，一个小菜鸟就算觉得有问题，也不知道问题在哪里，怎么去理解背后真实的东西。 315 | > 年轻和菜加在一起最大的好处就是“愣头青，不怕死”，于是我凑了几个疑问后，找机会冲到人家分管副总的办公室去做“需求调研”了，结果并不意外，拿到了第五个版本。 316 | 317 | ## 确定基准 318 | 319 | 毕竟说的是AI项目的启动，那么有关模型的精度基准问题是必须要提前考虑的了。 320 | 321 | 322 | 323 | 324 | ## 关注数据采集 325 | 326 | 327 | ## 评估风险 328 | 329 | 330 | ## 评估非预期效应 331 | 332 | 333 | [5.项目售前与解决方案 <--](/chapter-05/ch05_Project-Consulting-and-Solutions.md) | [--> 7.数据采集、标注与管理](/chapter-07/ch07_Data-Collection-Labeling-and-Management.md) -------------------------------------------------------------------------------- /chapter-07/ch07_Data-Collection-Labeling-and-Management.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/chapter-07/ch07_Data-Collection-Labeling-and-Management.md -------------------------------------------------------------------------------- /chapter-08/ch08_Training-and-Debugging.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/chapter-08/ch08_Training-and-Debugging.md -------------------------------------------------------------------------------- /chapter-09/ch09_Deployment-and-Testing.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/chapter-09/ch09_Deployment-and-Testing.md -------------------------------------------------------------------------------- /chapter-10/ch10_ML-DevOps.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/chapter-10/ch10_ML-DevOps.md -------------------------------------------------------------------------------- /chapter-11/ch11_Project-Delivery.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/chapter-11/ch11_Project-Delivery.md -------------------------------------------------------------------------------- /res/ch01/ch01-01.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/res/ch01/ch01-01.jpg -------------------------------------------------------------------------------- /res/ch02/ch02-01.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/res/ch02/ch02-01.jpeg -------------------------------------------------------------------------------- /res/ch03/ch03-01.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/res/ch03/ch03-01.jpg -------------------------------------------------------------------------------- /res/ch03/ch03-02.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/res/ch03/ch03-02.jpg -------------------------------------------------------------------------------- /res/ch03/ch03-03.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/res/ch03/ch03-03.jpg -------------------------------------------------------------------------------- /res/ch03/ch03-04.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/res/ch03/ch03-04.jpeg -------------------------------------------------------------------------------- /res/ch04/ch04-01.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/res/ch04/ch04-01.jpeg -------------------------------------------------------------------------------- /res/ch04/ch04-02.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/res/ch04/ch04-02.jpg -------------------------------------------------------------------------------- /res/ch04/ch04-03.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/res/ch04/ch04-03.jpg -------------------------------------------------------------------------------- /res/ch05/ch05-01.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/res/ch05/ch05-01.jpg -------------------------------------------------------------------------------- /res/ch06/ch06-01.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/res/ch06/ch06-01.jpg -------------------------------------------------------------------------------- /res/ch06/ch06-02.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/res/ch06/ch06-02.jpg -------------------------------------------------------------------------------- /res/ch06/ch06-03.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/res/ch06/ch06-03.jpg -------------------------------------------------------------------------------- /res/ch06/ch06-04.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/res/ch06/ch06-04.jpg -------------------------------------------------------------------------------- /res/ch06/ch06-05.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/res/ch06/ch06-05.jpg -------------------------------------------------------------------------------- /res/ch06/ch06-06.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/res/ch06/ch06-06.jpg -------------------------------------------------------------------------------- /res/ch06/ch06-07.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/res/ch06/ch06-07.jpg -------------------------------------------------------------------------------- /res/ch06/ch06-08.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/res/ch06/ch06-08.jpg -------------------------------------------------------------------------------- /res/ch06/ch06-09.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/lonelygo/Shift-AI-models-to-real-world-products/893ee395b489a45a9e2384bf5fa96c82fa3680b8/res/ch06/ch06-09.jpg --------------------------------------------------------------------------------