2016年10月19日重新修订
********************************************************************************************************************
离开大公司到创业小公司担任技术总监的岗位2年多了，时间不长，也没取得什么成绩，但作为以软件项目服务为主的公司，大大小小也负责交付了8、9个项目。
这个过程中遇到了不少问题和困难，想谈谈个人对这个岗位的理解，不算什么有价值的东西，就当给自己做点总结吧。
对于软件公司，不同于平台型的互联网企业；我们还是会以项目的形式进行交付管理，因此通用的看可以分为售前、售中和售后三个阶段。
1、项目前期（售前阶段）：
这个阶段在有一定规模的企业里通常是不需要研发人员参与的，由专门的市场、售前人员完成，当产品资料还不完善时可能少量技术支持。但在创业型小公司，从老大开始接洽这个项目开始，作为技术主管你就需要参与了。属于这个岗位的主要的工作我认为有如下一些：
1.1、需求澄清：在识别出客户的关键需求的前提下，引导并与客户（或甲方）梳理出一个有利于双方的需求边界。这个阶段是非常重要的，也对个人在业务上的理解有一定要求，需要能给客户一定的信赖感，如果之前不了解这个行业，提前做做准备。千万不要去“扯皮”（在大公司滚过几年的人应该对这个词都有体会），在大公司里只要你有本事把皮球踢出去，你就牛X，但在创业型公司，每一天都是钱、是成本，跟客户扯皮就是找屎。
突然想起原来公司一个笑话，只要你有本事把问题单扯皮到不归你改，这个问题单就算被你close了，所以某牛人可以一行代码不写改掉N个问题单。这个笑话懂不：）
1.2、初步的产品架构：这里是一些high level的架构，比如移动端采用原生、混合还是纯H5、要不要上负载均衡、数据库要不要上主备、是否需要独立缓存、是否需要引入第三方平台，如支付、短信、音视频、推送等等。这里的工作，并不是严格意义上的指导研发，而主要是为了预估工作量和实施成本。
1.3、技术选型：结合团队自身和初步产品架构的判断’完成语言、数据库、中间件等选型。技术选型之所以在售前阶段需要定下来，主要是两方面考虑，一方面是很多政企类项目需要提前出项目建议书或投标文件，里面会对这些有章节表述要求；另外一方面是它也影响你内部团队资源的调配和工期的判断。这里还是要有一定的权衡的，对于某些工期要求不重，需求相对简单清晰的，可以适当用下新的技术平台方案，比如之前大多是JAVA的项目，可以考虑试一下node、go。
1.4、关键技术风险：对于项目中的关键风险点进行识别，如果存在特别大的风险，比如复杂引擎、音视频服务等，不是短期能储备充分的，要及时把项目close掉。对于某些可承受的风险，在这个阶段也可以提前安排空余人员进行储备。
1.5、工作量评估：工作量评估及开发计划初步制定，支撑商务谈判和合同签订，简单点讲告诉你们老板，多少人天能搞定：）
2、项目中期（售中阶段）
2.1、架构设计：在售前阶段你可能做了一个初步的产品架构，在这个时候就要细化了。对于很多项目而言，可能最开始的时候就是一个单机系统，但如果客户是一个互联网平台项目，你还是要对未来有所预留。我个人的理解是在这个阶段核心还是业务子系统的划分和数据库的设计，其他很多东西后面都好说。好比，你一开始用户管理和订单管理就是混在一起的代码，以后就没法拆，给你用什么RPC都没用。数据库设计的时候，权限、角色、角色控制表都没有规划，后续想做细粒度的权限控制，也没法做。这些才是软件的核心，至于什么要不要动静分离、要不要上缓存、要不要上服务治理，我觉得都可以等等业务发展再说。
2.2、制定详细的开发计划：协调终端、前端、后端（大的项目也可能是各个子系统）之间的交付，避免彼此的功能存在依赖而阻塞，同时也要能够照顾到前期识别出的关键需求:。这里一定要先定接口，这件事情最好技术主管亲自做。开发可以采用敏捷的迭代，让进度可控，问题提前暴露。
2.3、核心问题解决；代码框架、关键代码、阻塞性问题等等；这点我感触最深的就是一个词“兜底”。因为在这里，你没有别人可以求助了，反过来你是你下面兄弟求助的对象，关键，这些时候你还不能让你的下属和客户看出来。我自己写到这里的时候，回想起很多事情，还真是有点心有余悸的，真是打落牙齿往肚子里吞啊.....
2.4、对外控制客户的预期：（这个时候项目合同已定，可以适当的和客户谈谈困难，给自己的交付留有余地）；客户一定会有很多临时的需求，比如什么时候要提前演示给某某投资方或领导啦，或者临时接了什么单子要某个功能提前上啦。这个时候尽可能挡住，别信他的鬼话，项目没找你们的时候，一年半载都拖过去了，这会晚个10天半个月，还就错过什么关键机会窗，鬼扯！实在挡不住，就和他说要加钱的，100%挡住伪需求。
2.5、对内控制项目的进度和质量：以我个人这点经验而言，比较好的实践有，早例会和周例会（能够施加一定的进度压力，同时也提升团队归属感），代码检视（针对复杂业务代码很有效，捎带也做了团队技术提升、编程规范啥的）、持续集成（平台类项目很重要，否则版本发布进度跟不上）。
我之所以把这部分工作放到这个阶段的最后，并非它不重要，而是有些从大平台出来的人（特别是管理类），总喜欢一上来就谈这方面的理念和思路，说的头头是道。以我个人的经验是省省，且不说削足适履是否合适，在你没能解决一些关键核心问题之前，真没人会愿意听你叨叨这些有的没的。
3、项目后期（售后阶段）
3.1、妥善处理客户需求变更，保证不过多增加项目成本，而又不影响后续款项的收取；
3.2、版本管理，每次发布后的版本要能在配置库可回溯，出了问题可回滚；