眼瞅著風險發生為問題,是不是我們應該在執行上加大對QA識別出的風險進行控制呢?

前序:部門的每周項目例會,都會對部門管轄的項目進行監控,在例會上都要求專案經理對項目執行情況進行彙報,彙報的具體內容參見《真實案例:在周會中對專案經理制定計劃能力的改進要求》。我認為目前的我們監控水平還不是很高明,從彙報的三個內容組織上就可以看到,我們目前的彙報還停留在粗線條、感性、非數字量化的方式。真正的精細化管理其實只有檢閱項目的Project,從基準看計劃和執行的差異、變更,一個好的計劃是有意識、可以清晰看到執行策略和意圖,當然,這還不是現在的要求。通過例會加強對項目資訊的掌握,才有可能識

以此為鑒:效能和高效是編寫後台服務程式技術人員必須有的過硬本領

情境:昨日下午參加某項目周會,周會先對待辦事項進行檢查,第一項待辦事項除了開發程式外,還涉及業務部門提供給我們曆史資料檔案,由我方維護人員負責匯入系統,產生報表。業主A(以下簡稱A)詢問:此工作是否完成?專案經理B(以下簡稱B)回答:系統功能已經上線,但是報表還沒有產生,目前正在計算中。A問:周四上線的哦?!那什麼時候計算完畢呢?B回答:主要是資料量比較大,所以我們特別在是周五下班後開始匯入,想著讓機器周六日運算處理,但截至現在還在計算。A問:那現在處理到那裡呢?B回答:這個還得我回去問問開發和

溝通的故事(2)

情境1:         某個項目定了下來,做一個管理系統,接到這個項目後,我們組建了項目團隊,派出了需求分析人員從事需求開發工作,但客戶只提供了幾頁紙,並且告訴我們這就是最詳細的需求了,這也是項目需求開發中經常碰到的問題,於是我們就開始發揮我們的專業能力了,首先是根據這些蛛絲馬跡為客戶分析其商務程序,並將商務程序充分規格化,轉化為系統模型,然後是Step by

一個“放飛的風箏”式的項目

情境:某部門人事調整,調整了兩位同事A和B去到一線部門,為了讓這兩位同事更好地和部門融合,相互瞭解工作的方法和內容,特別安排這兩位同事在調動前,預先參與該部門的一線項目的建設。上周日(8月24日)這兩位同事按安排出發去異地開展該部門的某項目,出發前A反饋的資訊表明該項目會在9月上旬上線,因此風險很大,同事A說先去瞭解落實需求,再做處理。周五下午(8月29日)和該一線部門的經理C瞭解該項目的情況,C反饋是最近比較忙,還沒有瞭解該項目的情況!而兩位同事竟然象“放飛的風箏”,沒有郵件溝通,沒有電話反饋

工作Delay,應該吸取什麼教訓?(二)

情境:(續上回) 既然項目Delay直接關係是由業務負責人B導致的,那麼項目介面人A的領導C也必須談談他的改進意見。C向我們說明會向B的領導D反映B的工作對項目的影響以及重要性,但是C也再次強調說B的業務能力很強,加上很多工作又是大老闆直接安排,可能D也沒有辦法(C和D是平級關係)。思考:領導C已經承認了工作Delay的原因,已經不容易了,而且也表達進行改進的意願,下次B再造成延誤再說吧?

QA的幾件“小事”,談談我們QA的座右銘,提升我們的操守。

情境一:前周某QA同事A去抽檢項目周會,認為有不少可以改進的地方,A在會後和專案經理溝通了這些情況。但是管理中心等了3天,才收到A的郵件書面報告,書面報告中,A沒有將該郵件發送給專案經理。思考一:QA目的不是為了刁難誰、讓誰難堪,也不是向領導打小報告,目的是協助專案經理發現自身沒注意的問題,收集作得好的案例,同時向公司管理層反映項目真實情況,為管理活動收集依據和反饋。A也不能保證問題一定全面,不發送給專案經理,如果有我們分析不夠全面透徹、專業的地方,專案經理缺乏表達的機會,我們大家喪失了一起提高

同事給我發的郵件,談及上周參加項目會議,關於項目Delay的深刻體會(挖掘篇)。

續(轉述篇)收到上文的QA轉述郵件後,負責專案管理的同事和該專案經理召開了溝通會對該項目目前的情況進行瞭解,以便分析。專案經理的闡述如下:目前項目處於需求階段; 監理方對業務不夠瞭解,通過監理方進行需求調研的效果不明顯,前段時間項目組進行了思考,有了一些改進措施,譬如:提供了需求問題列表,但是反饋時間慢,並且發生多次反饋不一致的情況; 針對目前的情況,項目的時間安排難以把握; 會上,業主方的業務負責人不在場,但是業主方的介面人以及監理方在場;

一個項目,兩位經理

情境1:由於資源緊缺,某部門經理作為售前投入到了項目工作中,但客戶並不知道他是部門經理,也並不關心這位同事的身份。這位部門經理在售前階段表現非常不錯,在客戶那裡建立起了信任關係,客戶有什麼想法都希望徵求一下他的建議,可以說,客戶已經完全信任他了。隨著項目的繼續推進,進入了商業談判和確立啟動項目的階段,這時客戶提出,為了保證該項目健康穩定地運行,並取得期望的成果,該項目必須讓這位部門經理擔任專案經理。出於種種考慮,我們答應了客戶的這個要求。但部門經理的崗位要求該部門經理必須將大量精力投入到部門管理

【轉載】40人月變更的秘密

前一陣聽老總說ZHANYA項目組做的一個項目工作量170個人月,變更工作量40個人月,項目組向使用者要到了接近25%的變更。他們是怎麼做到的?有什麼秘訣?這些疑問勾起了我的好奇心,於是乎伺機抓住ZHAN和XIAOLIN“嚴刑審問”了一番。現將交流內容結合個人經驗提煉加工“昭告天下”。一、40個人月裡有什嗎?謹尊偉大領袖毛主席“沒有調查就沒有發言權”的教導,仔細向XIAOLIN調查了40個人月的來龍去脈。其中最大一塊28個人月是由於業務介面人提出的需求並不滿足終端使用者要求引起的一次性變更,其中一

關於IT服務:系統上線第一周

某項目周一上線,項目組在關鍵的第一周,將所有的精力都投放在系統的服務上,包括對系統的穩定性監控、效能監控以及使用者服務,結果只為了一個:保證系統的勝利果實,為系統後續的發展打下堅實的基礎。項目組每天下午下班前召開會議,主要召開以下的工作內容:確認並且確保每個問題都有記錄,通過相互的檢查,避免可能出現的遺漏,並且確保對每個問題,組員有相同的理解和瞭解;對每個可能問題進行討論與分析,分析可能的原因,並且結合情況,預計對每個問題採取的措施,對每個潛在問題進行初步的分類;對於操作習慣或者使用方式上的問題

談談項目部署交流會的體會

    今天早上給同事培訓了項目部署的一些實踐經驗,並且邀請了上個星期進行系統部署的項目組給大家介紹案例。  

談談專案經理的工作導向以及效率的一兩件“小事”

昨日部門經理會,看到了某項目已經完成的工作量已經接近86%了,今天早上特別給專案經理通了電話,“祝賀”他離工作量超出100%已經不遠了。他的項目已經進場一周了,還有3個星期就要上線了!(會不會與客戶為了保障奧運成功舉辦出台的相關IT系統保障措施有衝突呢?)在訊問項目情況後,告知他作為第一次在該客戶的處女作,應該緊記以下三個教條:品質導向:前提條件,不能保證品質,其它都是假的,這是我們專案經理的品牌;時間導向:時間意味承諾,已經對於已經變更過的時間目標,這是專案經理的招牌;效率導向:根據瞭解的情況

同事給我發的郵件,談及上周參加項目會議,關於項目Delay的深刻體會(轉述篇)。

注意:本文轉載過程中,隱去具體項目名稱和模組名稱,並且做了少量的修訂,特此向作者以及讀者說明。

【轉載】同事對項目UI問題案例分析培訓的總結

今早剛參加完部門特意給我們.net培訓員工安排的《項目UI問題案例分析》,趁熱打鐵,寫寫自己這次交流會的總結。首先非常感謝部門的這次交流會安排,也特別感謝Guang哥百忙之中抽空給我們準備案例並主持這次交流會!案例分析交流會主要內容:表述UI設計所要遵循的原則 具有UI問題的項目案例(UI失敗案例)

如何提高項目群組成員的會議紀要的記錄能力?

這兩天早上進行如何進行會議紀要的培訓,最後一個環節交流會議紀要的編寫經驗,有同事詢問:“如何提高項目群組成員的會議紀要的記錄能力?”,參加會議的各個專案經理紛紛出主意,現將思路整理如下:給項目組的同事在會前準備工作中,提供會議紀要的模板,讓同事們看以往會議紀要的案例,讓記錄者瞭解會議紀要的各個要素和每點內容的要素;在進行會議紀要前,必須對記錄者進行業務背景的介紹,讓他對業務知識有所認識,能夠更好地、敏感地發現需要進行記錄的內容;在進行會議紀要前,專案經理要當教練,培訓項目群組成員,讓他瞭解會議紀

曆史為鑒:穩定高於一切!

剛從客戶那裡回到家。同事們駐場了,為系統在8月8日上線做最後的準備,今晚和項目組所屬的部門領導一起去看了他們,帶了點牛奶和曲奇餅。專案經理正在外地進行業務培訓,現場辦公只有技術經理以及各位開發的同事,同事們正在忙著針對前面的試用、培訓、聯調、測試等各個方面反饋回來的Defect進行分類處理。有一些話,不吐不快!情境:專案經理和技術經理對問題的分級判斷能力一定要非常清晰才行。譬如,早上培訓共有三次出現了後台服務類似“掛起”的問題,導致前端沒有響應,影響了培訓效果。嘮叨:這樣的問題才是上線前最緊急、

關於IT服務:服務是需要不斷改進的,也是需要進行不斷培訓!(故事一)

某項目組周一上線,某地終端使用者A在QQ群中詢問:“XXX功能什麼時候可以大量匯入啊,急啊”,QQ群負責服務的同事對於A提出的這個問題沒有及時響應。經詢問瞭解,項目組的同事都知道使用者提出的這個功能,而且也知道這個功能對於一線使用者的作用,只是這個功能在需求調研時並沒有提出,直到兩個月前的第一次功能測試時,一線使用者才提出,由於業主對上線時間要求得很緊,因此這個功能以需求變更的方式會在後期功能開發實現。經過再次確認,項目組的同事對此功能變更,已經是有與業主的業務負責人、項目負責人以及當時參與功能

由於安保原因,項目上線時間從8月5日調整到8月26日,專案經理應該如何考慮?

 周日某專案經理A告知,他所管理的項目,由於aoyun安保原因,上線時間從8月5日調整到8月26日。

Intermidiate EDI–AS2

AS2EDI over the Internet (EDI/INT) is a working group of the Internet Engineering Task Force (IETF), chartered with creating specifications for transporting EDI or XML documents over the Internet in a secure (digitally signed and encrypted), highly

Intermidiate EDI–ebXML

ebXML: What's Your Strategy?ebXML, initiated in fall 1999, began as an effort by United Nations CEFACT (Center for Trade Facilitation and Electronic Business) and OASIS (Organization for the Advancement of Structured Information Standards.) It

總頁數: 61357 1 .... 18163 18164 18165 18166 18167 .... 61357 Go to: 前往

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.