又开始看到裁人了，这种职业啊...

tracychen

遗憾。。

交易人生

IT总是第一波被搞得；

听说有一个特搞得裁人，好像一个法国公司，火警演习，大家在楼下待了1个小时后被告知，谁谁被裁了，被裁security pass已经无效了，然后hr把他们的东西抱下来。

我一个前同事被裁是整个部门被搞掉，早晨不让上去了，在大厅开会，通知这个消息，然后Hr抱着一批箱子出来，全是个人物品。那个前同事讲：当看到hr大批量的买纸箱的时候，一般会裁掉很多人。

干这行正常了，2008年初我在的那家金融公司关门，还算友善，ceo领着大家到水边的餐厅吃散伙饭，没人还有礼物拿，不过幸亏董事会英明，关门早，2008年年初job market还挺好。

估计很多人都有公司倒闭，部门被裁的经历。

yangwulong1978

炒人其实和按时提交CODE 真没太大关系。

工作你再卖力，拼命也是会被炒的，，，，，

不要为了公司的项目拼命的去做，不去学新东西，，，，，

公司里干活，其实用上60-70%的精力就可以了，另外30-40%的时间要保持自己的知识的更新度，和提升自己的技能，为这种突发事件做准备。。

IsDonIsGood

原帖由 yangwulong1978 于 2012-5-7 11:34 发表
炒人其实和按时提交CODE 真没太大关系。

工作你再卖力，拼命也是会被炒的，，，，，

不要为了公司的项目拼命的去做，不去学新东西，，，，，

公司里干活，其实用上60-70%的精力就可以了，另外30-40%的时间要保持自己的知识的更新度，和提升自己的技能，为这种突发事件做准备。。

尤其是做legacy application support.再拼最后也落个project out sourcing 然后让你打包走人的下场。

泪中的倔强

发现了。。。都在 裁人啊c(monkey07) (monkey07) (monkey07) (monkey07)

无视

原帖由 yangwulong1978 于 2012-5-7 11:34 发表
炒人其实和按时提交CODE 真没太大关系。

工作你再卖力，拼命也是会被炒的，，，，，

不要为了公司的项目拼命的去做，不去学新东西，，，，，

公司里干活，其实用上60-70%的精力就可以了，另外30-40%的时间要保持自己的知识的更新度，和提升自己的技能，为这种突发事件做准备。。

在agile中如果能让dev按这种比例安排时间工作就是estimation阶段的失误。

R2005

原帖由 yangwulong1978 于 2012-5-7 11:34 发表
炒人其实和按时提交CODE 真没太大关系。

工作你再卖力，拼命也是会被炒的，，，，，

不要为了公司的项目拼命的去做，不去学新东西，，，，，

公司里干活，其实用上60-70%的精力就可以了，另外30-40%的时间要保持自己的知识的更新度，和提升自己的技能，为这种突发事件做准备。。

真理

ttkc

还是羡慕挨踢的高薪。

IsDonIsGood

原帖由 ttkc 于 2012-5-7 19:25 发表
还是羡慕挨踢的高薪。

高薪?开玩笑吧，plumber什么的赚的比我等挨踢人士高多啦。

nariko

我也是很烦写个什么代码还要给人review，幸好现在还没遇到这种公司

greed

IT就是被外包的命

莫凭栏

It......

gozh2005

写代码review我觉得是应该的，保证quality的一种方式，不过前提是大家的mind set一样。
我好奇那些做contract .net的人多少钱一小时。

nis

原帖由 无视 于 2012-5-7 14:37 发表


在agile中如果能让dev按这种比例安排时间工作就是estimation阶段的失误。

agile就相当于工业革命时代引入标准化生产动作，每个工人每天能生产多少个零件都给你算好了。能生产1000，工人却生产700，怎么办？

无视

原帖由 nis 于 2012-5-10 14:01 发表


agile就相当于工业革命时代引入标准化生产动作，每个工人每天能生产多少个零件都给你算好了。能生产1000，工人却生产700，怎么办？

取决于scrum master对此的态度，导致sprint fail的可能性有两个：

1. estimation的失误。
2. dev实施阶段的失误。

如果dev有很充足的理由说服project manager是前者，dev这边就没责任，但我比较怀疑dev这边的说服力，failed sprint一般都是由scrum master来解释。

estimation阶段的时间是根据整个team的水平来定的，跟个人无关，failed一两次都没关系，但个人长久不能达到team的平均速度，水平会遭到质疑，就会有相应的performance问题，相信没有人情愿故意这么做。

o2h2o

原帖由 nariko 于 2012-5-8 09:49 发表
我也是很烦写个什么代码还要给人review，幸好现在还没遇到这种公司

代码review 其实很有用啊
写的人也会用心
很能保证软件质量
当然 前提是看的人也要用心

future2521

原帖由 o2h2o 于 2012-5-11 20:31 发表

代码review 其实很有用啊
写的人也会用心
很能保证软件质量
当然 前提是看的人也要用心

哥们你的VPN不能用了啊?一运行MeoVPN就是严重错误。。。

derek518

哎，有时候表扬不一定是好，批评也不一定是不好啊，老外也玩这套啊！！

水星浪子

帮哥拉袋S 是什么意思？

feihong

IT是这样的 需要的时候很火 经济差的时候第一排走人
不过程序员不怕找不到 拿着package发简历呗

潜水老虎

原帖由 水星浪子 于 2012-5-12 12:31 发表
帮哥拉袋S 是什么意思？

孟加拉

o2h2o

原帖由 future2521 于 2012-5-11 20:34 发表


哥们你的VPN不能用了啊?一运行MeoVPN就是严重错误。。。

Thanks 啊
service 停了
用的人很多  donate的 狂少  
哈哈
国内封杀的又厉害
只能停了

ian1234

活在压力里的感觉真是。。。。。。。

anotherone

原帖由 无视 于 2012-5-7 14:37 发表


在agile中如果能让dev按这种比例安排时间工作就是estimation阶段的失误。

唉，agile coach们就这么想的，所以工作量排得太满了，以致于根本没有时间应对突发问题和回顾做得好和不好的地方，光顾着赶进度，所以以后的项目我们打算回归waterfall了，或者watergile，再按agile这么搞，没命的加班，真的要死人了。

无视

原帖由 anotherone 于 2012-5-16 15:59 发表

唉，agile coach们就这么想的，所以工作量排得太满了，以致于根本没有时间应对突发问题和回顾做得好和不好的地方，光顾着赶进度，所以以后的项目我们打算回归waterfall了，或者watergile，再按agile这么搞，没命的加班，真的要死人了。

agile的关键在什么事情都是在sprint planing的时候安排的，任何事情都会反映在dev的working hours上，加班赶进度说明可能在planing阶段underestimate了，或者没有严格的遵循agile流程的要求．

我一般把story point都提升一个档次，3提到5,5到8,8到13这个档次倒很少做，尽量给dev这边充裕的时间,不rush code.

从时间上一般每个sprint都给team20个小时的buffer来应急,效果不错。

anotherone

原帖由 无视 于 2012-5-17 10:13 发表


agile的关键在什么事情都是在sprint planing的时候安排的，任何事情都会反映在dev的working hours上，加班赶进度说明可能在planing阶段underestimate了，或者没有严格的遵循agile流程的要求．

我一般把story point都提升 ...

我听到这个苦笑不已，我们公司为客户onsite干活，我们已经不断的加班3个月了，我们不断的反应他们的planning有问题，可是那帮人agile coach/pm不听，甚至一开始还认为是我们不懂agile，现在总算知道是planning有问题了，但根本就没有改进的迹象。。。在这么下去，我不玩儿了我。现在听到的消息好像现在客户的高层决定部分放弃agile了，不然空有agile之壳，舍本逐末，还把整个code的质量和人员的士气搞得很低落。

无视

原帖由 anotherone 于 2012-5-17 12:03 发表

我听到这个苦笑不已，我们公司为客户onsite干活，我们已经不断的加班3个月了，我们不断的反应他们的planning有问题，可是那帮人agile coach/pm不听，甚至一开始还认为是我们不懂agile，现在总算知道是planning有问题了，但根本就 ...

安慰一下，sprint planning谁来做？一般都是project manager和scrum master根据上３个sprint的velocity来定需要完成多少个story point.

连续fail 3个sprint他们就要好好找找问题所在，如果他们不主动作，在sprint结束后retro的meeting上dev就要push,让sprint master有这方面的action point.

总之，agile是个彼此交互的过程，否则就不是真正的agile.

anotherone

原帖由 无视 于 2012-5-17 12:48 发表


安慰一下，sprint planning谁来做？一般都是project manager和scrum master根据上３个sprint的velocity来定需要完成多少个story point.

连续fail 3个sprint他们就要好好找找问题所在，如果他们不主动作，在sprint结束后retr ...

说得好，应该是个交互的过程。但planning是客户在做。。。。他们为了meet他们自己的deadline，就把压力转嫁到我们vendor身上。至于我们的客户，就是那个著名的T公司。。。。唉

现在已经根本忙得没有retro了，每个drop都要delay 1-2周，然后严重的影响下一个drop，然后恶性循环。

[ 本帖最后由 anotherone 于 2012-5-17 12:55 编辑 ]

anotherone

客户的问题好多，最主要是把太多的东西放在一个drop里面，又需要100%system testing passed才能上CAT，然后又没有任何flexibility.

无视

原帖由 anotherone 于 2012-5-17 12:53 发表

说得好，应该是个交互的过程。但planning是客户在做。。。。他们为了meet他们自己的deadline，就把压力转嫁到我们vendor身上。至于我们的客户，就是那个著名的T公司。。。。唉

现在已经根本忙得没有retro了，每个drop都要delay 1-2周，然后严重的影响下一个drop，然后恶性循环。

这的确不好办，我觉得你们要强硬，consultant不只是干活，还担负着educate的责任，如果他们做的不对，你们要坚持自己的原则。

说服力应该是consultant必备的技能之一，不能让客户牵着鼻子走。