要件定义：从客户讲的内容里，把听懂的那部分记录下来。通常只有20%。
项目预算：决定项目组每个成员，今后要当两个人用还是三个人用的估算过程。
基本设计：编写一篇文章，让客户以为这就是他们想要的系统功能。最关键的是要让客户承认这就是仕样。
详细设计：由不懂程序的SE写出来，PG最开始说这个实现不了，但最后居然都能实现的程序说明书。
编码：搜索代码，复制，粘贴等一连串动作的简称。
debug：让复制来的代码能够通过编译所做的努力。
测试：提醒客户，可以开始仕样变更的信号。
用户培训：大家约个时间，现场向用户展示系统中的bug。
项目上线：邀请终端用户来一起找bug。
运用保守：懂仕样和代码的大部队撤离后，倒霉蛋被留下来，充当沙包接受客户狂殴。
瀑布开发：比喻项目的开发状况，就像瀑布下落一样迅速崩塌，无可挽回。
敏捷开发：将不懂代码的SE清除出队伍的开发方式。但最后的系统是什么样子，只有上帝才知道。
项目开发篇
PG：把SE的奇怪逻辑翻译成计算机语言的人。
SE：和客户对话后改仕样书，和PG对话后改仕样书，项目上线以后根据系统的表现继续改仕样书的人。
PL：认为能通过加班找回来的就不算延迟。通常算完项目进度后，按实际情况的两倍报告给pm的人。
PM：每次从客户那里回来以后，都要把项目进度推翻，重新安排的人。
顾问：每次问他1个问题，用10倍听不懂的术语来回答你，直到让你放弃的人。
增员：项目着火时用来填坑的人。但对进度挽回毫无帮助，最后变成生产率计算公式中的分母。
营业：根据项目要求，编写技术者简历的专家。
社长：现场出了trouble后，登门拜访上家公司，土下座道歉的人。
客户：在系统上线的前一天，才终于弄明白自己究竟想要什么功能的奇葩。
SI公司：不会写代码，却自称会系统开发的神秘组织。
协力公司：帮助SI公司圆谎的苦逼队伍。
08:30 前一天工作内容的“締め切り”时间。
13:00 理想中的出社时间。
17:30 上司亲切地叫住你，给你安排一大坨需要当天完成的工作的时间。
23:30 可以用“就要终电了”作为借口，下班回家的标准时间。
台风来了：唯一可以按时下班回家的节日。
东京IT人
日本IT老司机，
和小伙伴们分享岛国趣事，
特别是IT相关。
欢迎大家踊跃提意见，
希望在大家的帮助下越办越好！
联系客服
