去年应一老朋友之邀，在他的公司里做了一年技术顾问，从4月份开始，参与到核心客户的二期平台改造项目，从售前方案交流、参与打标、总体设计、平台开发到最后上线，前半程作为技术侧的主要负责人，后半程因为个人原因，逐步退出，到后期平台割接上线时以核心业务的数据割接保障为主，整个项目前后断断续续投入将近一年时间，回顾参与的全过程，前半部分投入度和参与度都很高，对项目贡献较大，个人成长不小，后面聚焦在一二期的数据割接方面，贡献和收获也都小了很多，但项目复盘很有价值，是对这段工作的总结以及个人能力提升的梳理。
一、项目概述
根据个人参与项目的状况，把项目划分为三个阶段：
阶段1：项目售前阶段：包括项目售前方案的技术规划、招投标方案撰写等工作，这个阶段我的角色是技术总负责人，负责组织撰写技术解决方案、技术投标书、投标PPT等内容；
阶段2：项目开发阶段前期：中标后，作为项目的技术总负责人，组织内部研发团队、外包研发团队，配合项目经理、产品经理，对平台进行设计和开发，形成最终发布版本，但由于个人原因，这个角色没有完全做到位，从去年9月份开始，无法出差客户现场，相关的现场技术管理和大部分现场技术沟通工作由另一位副总接手，我已经有意识地把重心往数据割接、运维部署等支撑性工作迁移。
阶段3：项目开发阶段后期及上线：去年12月开始，角色转变为一二期数据割接总负责，1月份开始了另一份创业工作，因此就变成了配合项目经理、产品和技术负责人，根据项目进度要求，进行数据割接演练，配合需求调整割接脚本，最后负责割接上线过程中的数据迁移工作。
项目复盘会针对三个阶段分别展开，并结合最后的项目成果进行对照分析，以补充完善自己的知识体系。
本项目的业务是关于某个垂直领域的在线教育，客户端包括安卓和苹果的APP、PC客户端，主要业务功能包括视频学习、练习、考试、即时通讯等。二期项目在一期项目的基础上，增加了微信小程序端，对一期运营过程中的新需求和问题进行完善，并优化一期各业务功能独立烟囱式的架构。
二、项目售前阶段复盘
1、过程回顾
主要分为两个阶段，一个阶段整理平台技术解决方案，第二个阶段根据客户标书整理技术投标书。
第一个阶段，公司老大作为产品牵头人，我作为技术牵头人，共同讨论并形成产品建议书和技术建议书。
第二个阶段，撰写投标书，由售前老大牵头，分解业务、技术、部署、项目、测试等内容，我主要负责技术、部署等内容，并补充其他相关内容。
2、个人复盘
（1）问题教训
- 因为之前不直接参与售前工作，更多地是作为公司技术负责人审核售前技术材料，所以对售前解决方案感觉很熟悉，但真的要从0到1形成完整的解决方案，就缺少了成型的模版，只能从手头搜集的售前方案素材库中进行拼凑，形成一个售前方案模板。所以在解决方案的适用性上、在成稿的效率和质量上有所欠缺，而且因为售前材料没有经过有效整理，好几次发现已经采用的部分内容，结果从另一份文档中发现了更好的，于是重新调整。
后续优化措施：以这次的解决方案为蓝本，摘录各部分的标准化内容，基本上每个通用模块有2~3个版本，以便用于不同等级的项目、不同类型的客户等。
- 平台的架构设计还行，但要落实到架构图上就很有挑战了。在第一个阶段的解决方案定稿后，可能是小伙伴们不好意思说，我自己感觉架构图太丑了！就是空白底色上，一些方框，方框的颜色搭配也很渣。还记得当时我对售前老大说，下次形成标书时，架构图的美化就交给你了，主要是对自己的审美没有一点信心。
后续优化措施：在第二个阶段搞定了，见下一章节的“经验积累”。
- 检查不够细致，错别字、序号错误在最终稿仍有发生——如关键场景、软件、模型设计的章节序号重复等；
后续优化措施：严格把控自己产出，至少做一轮完整的Review，不能完全留给汇总人员进行审核。
- 技术把控职责没做到位，原计划在标书开始前，对标书进行整体的规划，确认技术标的总体架构、侧重点等，以便做好全盘控制，结果没能执行，深究原因有两个，一个是自己偷懒了，因为觉得有售前老大牵头，自己执行按照分配的工作，可以理解为逃避责任，“责任病毒”的一种表现形式；另一个原因就是逃避冲突，因为觉得如果这么做之后，可能跟售前老大、老大以及另一个副总可能有不同的看法，容易引起冲突。
后续优化措施：还是要从整体利益出发，克服自己的私念，勇于行使自己的职责，如发现其他人的问题同样敢于提出意见和建议，当然在方式上可以注意一些，如通过私下的交流先达成共识，避免公开场合的质疑和否定。
- 撰写标书时，刚开始过多地“以我为主”，参照自己的思路下笔，而忽略了标书中的评标规则，最后在PPT中才进行参照，浪费了不少的精力，做了一些反复的工作。
后续优化措施：完善售前方案撰写的Checklist，把评标要求作为章节规划、重点规划的基础。
（2）经验积累
架构图绘制能力的提升，这可以说是这个项目最大的收获，因为投标材料撰写和整合的工作量很大，原本指望售前老大帮我来优化架构图也变得不太现实，只能自力更生，我的做法是：以原来很丑的框图为基础，在百度图片中寻找类似的系统架构图，根据它的方框、图标样式对框图进行调整，更重要的是参考它的配色，这样调整之后，整个架构图一下子大变样，变得赏心悦目起来，自己感觉应该能达到70分了，也得到了小伙伴们的认可。
回顾时最大的收获是不能自我设限，可能你在某些方面确实没有天赋，但是绝大部分时候还到不了拼天赋的程度，那么通过参考、借鉴，要达到及格线以上还是有很大可能的，这时候限制自己的反而是你的心态，即“不愿意”、“自认为不可能”。
3、公司复盘
（1）问题教训
- 没有建立基础的售前材料库，很遗憾地发现，公司也没有建立成型的招投标标准库，跟我一样，都需要在原来各项目的招投标材料中重新选取、修改，这也是售前老大没时间帮我优化架构图的主要原因。
后续优化措施：执行技术顾问的职责，建议售前在一个月以内，以这次标书为基础，形成公司的招投标方案库；
- 售前标书整体进度把控不够，如上面提到的，售前老大一开始就进行了工作分解，把商务标、技术标的内容进行拆分，老大、我、技术副总还有其他小伙伴都接到了任务，但因为大家除了写标书之外，其实都有一些项目性的工作，所以最后是老大发现不对，快要投标了，材料还没有定稿，亲自跳下去推了一把才将将按时成稿。
后续优化措施：加强售前标书撰写的项目化管理，必要时集中化编写，把这一条要纳入公司售前SOP或经验库，在下次撰写时发布计划并定期通报进度，这样管理层才能快速发现问题并共同推进解决。
（2）经验积累
暂无
（3）对其他参与人员的建议
因涉及小伙伴们的具体情况，内部已经分享过，就不罗列在这里了，但大家在实际项目复盘过程中，应该要进行整理并分享，否则无从体现对团队成长的贡献了：）
4、全程回顾
从项目整个过程进行回顾，对售前环节整体还是比较满意的，最重要的当然是达成了预期目的，拿到了最高的分数成功中标，还记得在总结时，我是把最大的功劳归于老大，因为正是他与客户的有效沟通，才能让我们的标书在评估结果上更有优势，最终转换成胜利，我们所有的产品和技术方案贡献度只有30%。
可以说，只有在销售不太给力的情况下，在投标竞争激烈的情况下，售前方案的质量才能贡献更大的百分比。
另一个比较满意的是，在售前这个过程中，几个老大商量下来的项目风险，基本上在后续的项目实施过程中都被一一验证，虽然解决方案不完全是当时售前阶段就想规划好的，但至少让小伙伴在面对这些风险、困难时不会惊慌失措，而是全力投入解决方案的寻找和实施。
对于个人来说，从头到尾参与到这种中等规模的项目全过程，尤其是之前自己刻意忽略的售前阶段，很有收获，虽然可能自己无法把控或主导每一个环节，但对整个前期运作过程有了更加直观和具体的认识了解，在后续面对类似的情况下，会更有信心一些！