技术项目管理随想

Project management

最近看了一些技术项目排雷书,分几个方面总结了一下雷区,以及可以做得更好的地方。

工程质量 & 复杂度控制

  • 预计变化的影响:需求会变化,系统扩展性需要加强,人员在流动。架构师的职责是管理变化,更确切的说,确保变化的影响是受控的。所以以下的技巧是必须的:
    • 只进行小型、增量的改动
    • 写可重复运行的测试用例,经常执行
    • 让编写和运行测试用例变得容易
    • 追踪依赖事项的变化
    • 自动化重复事项
  • 舍弃自作聪明的设计。这样的设计让系统变得脆弱和难以维护。越老实的系统越容易扩展。
  • 关注性能。假如不从一开始就严格控制性能,「暂时不用关注性能」的想法就会在团队中蔓延。很快就变成「不得不马上解决线上的性能问题」。尽早在团队里面传授性能测试工具的用法是很有效的方法,真没那个时间的话,对依赖SQL的团队,普及一下explain的使用和结果解析都会有很大的提高。
  • 要评估系统的扩展性,那就尝试向多个方向增长业务规模,看看哪个方面会先支撑不住,那个就是你下个要关注的方向。
  • 重视界面设计。对于产品的用户来说,用户交互界面才是系统本身。系统的响应速度提高50%当然是好事,但废老大力气的优化很容易就被糟糕的交互带来的坏心情影响。
  • 不要迷信设计模式,不要为了使用设计模式而使用。
  • 所谓复用,不仅仅与架构有关,还和人有关。如果没有人知道还有个框架,没有人知道怎么复用,再厉害的框架也是白扯。所以文档是很重要的。
  • 构建系统并不是一场选美竞赛,不要为了追求完美而主动寻找错误。
  • 追踪每周有多少时间用于解决线上问题。
  • 一朵起错名的玫瑰会长成卷心菜(我真喜欢外国人的比喻啊)。做某个事情之前,假如连这个事情应该怎么称呼都没想好,那就别开始做了,想清楚再做。
  • 如果解决的问题稳定,那么很容易能得到一个可靠的解决方案。但无论开工之前想得多完善,最后的产出总不会是一模一样的。
  • 开发过程中的“新想法”要要慎重考虑。因为一个技术很酷而使用,因为框架升级而要系统跟着升级,因为做A而要重构B,因为有一个关于架构的想法而进行讨论,都隐藏着危险的信号。这些事情会带来系统的变化,使项目变得逐渐不可控。
  • 选择当下的最佳解决方案去解决问题。假如想太多关于未来的问题,可能既无法解决未来的问题,而且连当下的问题都不能好好解决。
  • 量化你的数据。不断加入统计或埋点数据。
  • 不走正路的Bugfix就像借贷,是要还利息的。利息主要表现为:系统变得更难以扩展。为了降低影响,合理的做法是,先上bugfix,并投入时间在下次发布之前做一个合理的bugfix。

团队建设

  • 提高团队战斗力(确保他们已有对应的工具,CI,code formatter,性能测试工具;确保有对应的技能,每周五对需要用到的技能进行培训,在书本和讨论上投入;引入流程的时候,确保是用来解决问题,而非引入新问题)
  • 寻找并留住有热情的工程师
  • 自己写JD。
  • 技术人员的顾客并不是真正的顾客(是产品人员),我们顾客的顾客才是真正的顾客。因此,需要考虑真正顾客的需求。例如产品为了赶工期要求暂不对数据进行加密,技术人员应该指出风险而不是默默接受,站在真正顾客的角度考虑问题,而不是提出任务的人。
  • 工程师和机器打交道,架构师和人打交道,因此要学会Sell自己的观点。如何推销自己的观点:
    • 建立起Value proposition
    • 用数据说话,尽早建立起监控进行反馈
    • 找一个合适的时间提出方案(例如前一个框架被验证是失败的时候)

沟通

  • 在讨价还价的过程中先索取得比需要的更多(以在协商中留有退路)
  • 挑战并验证假设。是否用户真的不能忍?是否这个库就是比那个库糟糕?
  • 做一个好合作、会说话、但并非好说话的工程师。
  • 许下承诺和践行承诺才能得到尊重。这就要求我们考虑预算和时间的限制,尽我们所能让系统变得高效。
  • 不断地问需求的提出方,需求能不能加上「在任何场合下,总会有……」的概括。由于需求方会比较谨慎地回答这种问题,因此他会不断地修饰和思考需求。反复地问,这样我们就会得到一个非常简洁、核心的「系统本质」。这个本质才是真正的我们需要关注的。

技术选型

  • 影响技术选型的决策因素中,需求比经历重要。不要为了简历好看而用新技术。找那些容易和其他模块配合的框架。
  • 决定技术选型之前,不妨真正去试一试。找两个工程师,花时间调研一下优点和缺点,总结对比,最后选哪个在很多情况下都是很显然的。这可能是在浪费时间吗?有可能。但总比匆匆找到一个非最优解马上开工最后发现不得不绕回来要好。
  • 记录进行设计的依据。记录做了哪些决策,为什么做了这个决策,以及为什么不用其他选择。
  • 为任何的技术决策负起责任。很多正确的设计最后却以失败告终。要避免失败,至少做到以下几点:技术决策应该传达给所有相关的人士。
  • 选好趁手的工具,不要轻易切换。

工程师的自身成长

  • 理解硬件。起码知道系统的状态和什么相关,各种硬件的性能级别,有线上报警的时候能根据报警项定位问题。
  • 软件行业的一个大问题是工程师需要解决远超自己当前理解的问题。因此学习与沟通是关键的能力
  • 架构师首先是个工程师。假如我做了设计,那起码我应该有能力亲自实现。
Share