標籤:

公司推行jira,要求工程師每天log work,監督每個工程師有沒有做滿8小時的工作,想請教下各位國外IT界大牛是否有必要,是否有這樣做的優秀的IT公司?

公司在整個公司層面推行jira,實行項目和流程管理,推行了半年多,現在每個工程師在每天繁忙的工作還要每天log work,監督每個工程師有沒有做滿8小時的工作,想請教下各位國外IT界大牛是否國外也這樣,之前在阿里工作過,完全沒有這樣的,很不習慣,感覺深深的不自在。。。


之前在一家美國公司做的時候推行過這樣的管理制度。

從管理的角度來說,記錄工作日誌這種事情毫無違和感,如果不需要你記錄工作日誌,而讓你寫工作日報,難道你就感覺舒服一些了?

這是兩條管理規則一起推動的結果,所以工程師認為記錄工作日誌是額外的工作。

我們公司當時是,先要求提交詳細的工作日報,精確到問題、小時,這樣執行了兩個多月,員工最初怨聲載道,後來逐漸麻木習慣,然後告訴大家一個好消息,在JIRA里直接記錄工作時間,一天只要湊7個小時就可以了!

這樣,只要誰還覺得在JIRA里記錄工作麻煩的,就讓丫自己去寫工作日報去。

JIRA進行時間管理,通過三個方面提高大家的工作效率:

  1. 總體工作時間要求:每周40小時;
  2. 每問題工作時間要求:平均問題解決時間,疑難問題識別
  3. 問題對工作內容的覆蓋率:任何超過一小時的工作都應創建問題

第一條要求工程師事無巨細都必須上報,第二條要求上報內容真實可靠。硬性要求總體時間後,工程師必須想盡辦法湊時間進去,而第二條,例如我當年,要求每問題平均解決時間為3小時,凡是超過3小時的必須寫明問題原因。這樣,工程師不敢在一個任務上面謊報大量時間,同時,靠這個辦法發現了大量平時掩蓋的問題,集中解決後效率提高不是一星半點。

配合Fisheye插件集成SCM工具,你可以看到,一個號稱花費了40小時的任務,到底有多少代碼變更。直觀的就可以識別出工作效率問題。這種證據是可以用在辭退工程師上的。

當年實施下來,有數名工程師離職,坦白說,都是濫竽充數的。有的離職時直接跟我說,本來就是圖個清閑,現在忙成這個樣,不幹了;有的是因為,幹了幾十個小時的任務,只有個位數的代碼變更。我們不是什麼研究演算法的團隊,這種事兒就是他娘的混。而真正有效率的工程師,勤懇的工程師,馬上就可以看出來。

管理者通過JIRA進行管理也同樣是要求很高的。最後一條是套在管理者頭頂的魔咒。管理者不能是渾渾噩噩的混子,而是應該對自己的團隊工作範圍有明確的定義,對團隊工作進度有良好的管理,這樣才能將所有的工作內容都使用不同類型的問題覆蓋。經常有這種實施失敗的案例,最大的問題並非工程師沒有執行,而是管理者水平太爛,和稀泥,於是就流於形式。

不說別的,如果問題能夠對工作內容實現完整覆蓋,很容易回答的一個問題是,團隊的生產時間佔總體比例是多少?如果回答不了這個問題,那是個什麼雞巴管理者就一眼看出來了。

Atlassian是什麼樣的公司,JIRA以及他們家的一大堆產品設計如何,在行業內的地位和水平都是無須諱言的。那麼,TEMPO插件火成這個樣子,難道老外都鹹的蛋疼


為log而log 其實沒有意義,Jira本身log 的本意,是用來記錄當前工作的人力,是個項目經驗積累的過程,便於之後開發新產品等可以有個工時人力的分配依據。同時對目前項目的進度進行跟蹤,說直白點,就是log是為項目管理服務的,不是為了監督員工工作時間。


國外的話,大公司至少亞馬遜是這樣,據我所知,JIRA的用戶還是有很多知名公司的

摘自JIRA官網

點開full list還有很多知名的包括Twitter, Autodesk, Trulia等等

我覺得JIRA是一套很好地實行敏捷開發的工具,我覺得我是管理者的話我會很喜歡它帶來的對任務進度的追蹤,更好的激勵工程師在scrum board上不停完成任務(大家計劃都寫在上面,誰效率高有的時候是會互相比一下)

不過作為工程師嘛...划水難度大大加強;每天早上去辦公室第一件事情就是standup meeting介紹昨天做了啥,今天打算做啥,每天都得有些result,要是同事做得太快還有peer pressure;確實是如果不用JIRA不開standup會壓力小很多

我也了解些不實行scrum model的公司,就給個東西讓一兩周做完,中間work from home打兩天遊戲根本沒人知道,羨慕是羨慕,不過想想特別大規模的公司要是這麼搞,的確會有不少划水匠,failure detection周期長,做不出一個東西兩周才知道,對公司效率的影響還蠻大的


我們公司一直在用jira,但是並沒有用來管理時間....

就是單純的用來管理項目,統計每一次版本的單子,目前覺得還是挺不錯的呀。

再說這玩意兒真的能管理時間嗎?雖然能看到每次提交的記錄,

但是不同的功能做的時長肯定不一樣,所以不一定每天都有提交啊


Jira 首先是個工單系統,有什麼任務了,無論是新需求,還是有 Bug,先開 Issue,Assign 給誰讓他 resolve,好了之後再 assign 回去 test,沒問題了就 close,日後需求改了就拉出來 reopen,每個任務都有明確的階段,每個階段都有人負責,任務多,大小長短任務混在一塊的時候,這麼一個工單系統,Jira 也好 Trello 也好 Slack 的 remind 也好,都是很有必要的,至於 timesheets 也不要搞太多心理負擔,反正我也是老大催了再打開 GitHub 照 commit time 填一下,關鍵是就算沒有它你自己也要做時間管理,否則你時間就浪費掉了,Timesheets 這東西好處是除了記活以外記病假事假年假什麼的也很好用,你只要早早開個不同類型的 Issue 然後當天記錄個 8h 就好,就算是記任務,Issue 頁面右下角也有個簡單的計時器,開工點一下,完工點一下,時間就自動幫你記好了,你要是划水時間太長,就專門開個 Issue 叫划水,每天 log 它兩三小時,你的負罪感就更強了。


這個我很喜歡,什麼都記錄,他們總以為我解決了多麼厲害的問題,工作投入多高。

其實基本都是我頭一天下班前兩個小時,或者晚上睡覺前兩個小時搞定的,而且我的log很好看

白天在公司幹嘛?當然是吹空調啊(逃

簡單算一下,你就會發現白天6到8個小時,拿來工作太浪費了好嗎。開放式的辦公環境更是噩夢,誰的逼逼都能打斷你,複印機印表機轟轟響也能打斷你。還不如拿這一大整塊時間來看點文檔學點東西。工作就是扯姬8蛋。

還有,我很喜歡樓上那個 @上官人 閣下的管理方式,如果還有這種看代碼產出來衡量工作甚至金錢的坑,請記得聯繫我!!!我這種水平一般的人最喜歡了好嗎!!!


花費的時間和代碼量的產出確實可以作為衡量開發人員工作的一個參考,但應該不能是完全依賴這個標準,因為越具體的工作越容易量化,反之越抽象的工作越難,而對於開發團隊而言,思考、設計、調試、閱讀代碼和討論等等,是團隊進步不可缺少的部分,如果這些工作因為考核而得不到鼓勵的話,最終就是大家都在happy地忙碌,管理者也看著儀錶洋洋自得,但最終的產出只是越來越多的麵條。


Jira 的精髓 不僅僅在於他是一個log time的工具!

可以關聯代碼提交記錄,以及相關衍生產品的聯合試用!·

log time個人感覺非常有必要 ,在忙也要強制自己按照規則辦事。。。。

無規矩 不成方圓


如果使用JIRA工具,推行的是敏捷開發(scrum),那記錄工作日誌是必須的環節。這本來就是敏捷開發項目管理中的時間管理的方式。

最主要的目的並不是監督開發者有沒有工作滿8小時,當然也包含有帶給開發者一定壓力,自然淘汰不合格開發者的作用。但是主要目的是為了版本控制(項目管理)而服務。

不過描述中的每天8小時,標準來講是不太對的。因為每個任務的時間評估,最好採用一個人完全集中精力在工作上,用多少時間能完成這個任務來評估的。一般根據團隊情況,一天的單人工作量會設置到4-5小時。(8小時工作制)

搜其他問題的時候碰巧看到了這個。先寫著點吧,有空再補點其他的。


Jira是用來記錄做某個功能花了多久,而不是屁股在椅子上放了多久。。。


log working hours 是對具體的issue,我們一人的日工作時間按5個小時算,分到每日的issue里。


以個人經驗感覺完全沒有必要.


習慣就好,所有東西都有量化目標。對於大型公司和團隊管理都有好處。不清楚阿里是咋管理公司。


回答你的問題,優秀的IT公司這樣做的肯定有。但你看看世界上頂級的幾個公司有哪家是這麼做的。

傳統型公司管理中庸的團隊用這招最好使。


京東用的jira


這和JIRA關係不大,基本上每個公司都要log timesheet,用什麼工具的都有


我還開發過類似玩意呢,短期沒啥好處,如你所說不習慣,浪費時間。長期來看對領導管理團隊啥的挺有幫助的,是個人都要寫年度總結啥的,這時候就派上用了。


用jira不是記bug的嗎?


teambition、禪道也有很多用的。剛開始很不習慣,後來慢慢覺得teambition也還行,就是免費版的功能會受到很多限制。


Jira是個好工具,好不好還要看團隊用的如何。


我們也用jira,據我的了解,jira不可以直接管理時間,只是在ticket上面log progress。我還想問,如果不用jira那用什麼來管理項目?每個ticket包含score的,這些都是agile必備的,用啥啊


推薦閱讀:

關於 jira confluence gitlab jenkins 的配置與整合以及常見的使用方式?

TAG:JIRA |