Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

我们的时间去了哪里?

Posted on 04/26/201110/01/2024 by 四火

clock 做一个大型的 WEB 项目已有近两年,兄弟姐妹们总在忙忙碌碌中度过,看似很充实,可是当每个版本结束,我想我们又完成了一件大事,可是紧张的项目周期加上持续的加班,客户和一线还是对版本质量不满意。看到完成的作品时,我总有一种感觉:投入了相当大的人力,团队成员也兢兢业业,按说时间应该绰绰有余才对,可是实际上为什么我总觉得版本紧张,我们的时间怎么那么容易就被消耗掉了?

 

内耗之事

不可否认当一个团队人数越来越大,就越需要流程来约束人、管理人,可是团队越大,就越容易产生沟通、交流的内耗,尤其是流程产生的内耗。项目经理或者团队 Leader 能够及时识别出这样的内耗,就显得尤为重要。

流程的内耗,比如一个复杂的 bug track 流程、繁琐的转测试(发布)校验机制,事实上这在合作方参与的定制版本中,流程的损耗更严重。

反复的邮件交流、不够细致的需求讲解会议(这将导致后续过多次的口头澄清),还有难以保证的所有成员一体化工作(UCD 设计人员在外出差)等等,这是沟通的内耗。

 

临时之事

一个稳定的团队,忌讳有反复的较多临时事件的冲击,无论这样的冲击是针对个人(例如项目经理)还是团队所有成员,无论这样的临时之事是重要还是紧急。无论如何,这样的冲击都是计划外的,带来的后果就是导致项目计划变成空谈,有序和可预见性变得不可捉摸,长时间下来将损害团队中成员的积极性。

学有选择地说不,通常还是有一些选择余地的,并非事事都身不由己。如何尽可能地屏蔽外界的干扰,既需要领导的关注和协助解决,也能成为项目经理规划和安排的艺术。

 

废弃之事

这指的是有一些工作,虽然做了,但却是价值不大或者没有价值的。无论是因为没有意识到,还是迫于无奈,任何一个团队都会做一些这样的事情,只是有的做得多,有的做得少。

比如为了完成某个硬性要求,在代码中添加一些毫无意义的内容,做一些毫无意义的修改;比如为了满足某个疑似的隐性需求,做了一个复杂的设计,结果却根本不是客户需要的;比如为了兼容某个版本,投入了大量时间做接口兼容的工作,结果却没有应用这样的场景。

要减少这样的事,就要团队成员能始终清醒地认识到产品的价值所在,知道什么才是客户需要的,什么才是客户最需要的;也需要外界能少一些非必须的约束,给大家一个轻松和民主的氛围。

 

变动之事

对于一个长期发展的产品来说,随着一个一个版本的交付,它会越来越复杂,于是学习曲线就会越来越高,一个团队的新手、一个模块的新手,都会导致效率的下降。如何保持整个团队的稳定,就显得尤为重要了。

团队要能够控制住人才的流失。铁打的营盘流水的兵,人员变动往往是不可预期的,但是建立好人员培养机制,减少生手的上手时间,做好业务和技能点的备份,能够减少这种变动带来的损失。

项目团队要能够逐步引导新员工落实到实际工作上来,新员工需要学习,不仅仅是学习业务和技术,还有团队的约定,无论是成文的规定还是不成文的规矩,霸王硬上弓带来的后果只能是质量的下降。

 

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 时间投入上的权衡
  2. 谈谈 Ops(三):事务、团队和时间分配
  3. 思考、学习新技术的原则和方式
  4. 自由地生活和工作
  5. 不要让业务牵着鼻子走

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Python Spark 互联网 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 程序员 管理 系统设计 缓存 编码 编程范型 英语 西雅图 设计 评审 问题 面试 项目

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Big Data and Machine Learning (5)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • + 1.943624 BTC.NEXT - https://graph.org/Ticket--58146-05-02?hs=9a9c6f8dfe3cdbe0074006e3e640b19b& on 所有文章
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
  • Anonymous on 我裸辞了
  • Dylan on 我裸辞了
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme