先簡單的介紹情況：小城市，小公司，小專案（20-40w左右），也做過幾個大專案。但無論專案大小，其管理模式還是很low，簡單、粗獷。
業務對口的是國企在地方處級單位的資訊化專案，這類單位有個特點是：每年有一定的科研經費，做專案不差錢。一般流程是：甲方單位內部立項、招標投標、和開發商簽合同。當然具體的細節比這複雜。這裡想說的是在這個過程中涉及到的需求問題。
先說這個過程中需求是怎麼產生的。一般是甲方各職能部門根據生產需要、管理需要、基層人員平時反映的問題來決定立個專案解決目前的需要。部門領導可能會開個內部會，調研下有哪些問題需要解決，安排個人收集整理下，寫個立項報告（這個人也基本是後來和我們進行專案溝通的甲方聯絡人），再報給公司進行審議等等流程。通過後就是招投標階段，這時我們通過招標書可以看到原始的需求。而我們在投標並中標後，在準備的合同中對這部分的原始需求沒有進行過多的解讀分析，基本就是照搬過來，新增下費用構成、進度安排。合同一簽就開工了。
隱患在這時就已經種下了。檢視招標書、準備投標書到後面的擬定合同，這些都只有專案經理或是商務性質的人在做，其中的原始需求也只是粗略的看下覺得可以做，即便有少量難點覺得也可以變通解決。偶爾就其中的一兩個需求點，詢問下技術人員是否可做。大體上沒什麼問題就準備擬定合同，簽合同了。暴露的不足之處就是對需求分析不夠深入、不夠重視。
可能有人會說很多專案經理都是從以前的技術崗轉過來的，而且還是技術比較好的，否則也不會任命為專案經理。他們對需求的把握不會有大問題。但實際情況是，技術更新迭代快，專案經理如果還以以前的技術經驗來評估需求是有風險的。
其次專案經理以前的技術經驗和當前專案所要採用的技術是有差別的。拿桌面軟體的經驗去評估b/s系統的需求也有偏差、風險。即便沒有這種偏差，專案最後也不是由專案經理來開發，而是交給下面的程式設計師、架構師來完成的。這又有一種偏差，專案經理在評估需求時認為3個月可以完成，而開發人員因為技術能力、經驗與專案經理不同或者沒達到他的預期，可能認為需要5個月才能完成。但經理並沒有徵詢這個5個月，已經按3個月的進度安排寫進了合同。這在後期開發時會形成風險。
這就是我為什麼要提出：專案談判，請帶上我！這個我指的是：專案開發核心人員或者叫專案技術負責人，越早越好。
作為開發人員首先關心的是需求。了解了需求才能知道自己能不能做，怎麼做，有多少風險，大概什麼時候可以做完。從立項開始，盡早的讓你的主力、核心開發人員參與到需求收集整理、分析確認過程中來。當然大公司，有正規、完整做專案流程的公司這方面做的好些，會配有專職需求人員及需求管理制度。而小公司基本上都是專案經理兼任。後期也沒有正式的需求管理。專案經理很多時候主要精力是放在招投標、商務談判上，後期也是放在人員管理、進度管理上。
專案技術負責人在合同簽訂後才拿到全部需求（還是原始需求），已經很被動了。估計還會傻眼。在前期投標，談判等環節是由專案經理或商務人士評估的需求，他們大多也是從技術可行性上分析，能不能做。需求中包含的範圍沒有深入研究，只是按照其他專案經驗自己預估的乙個，並沒有去和甲方確認也沒體現在合同上。等到技術人員開發時就知道這個範圍不好把控，甚至成為了乙個坑，導致專案延期，驗收不過，產生糾紛。
需求中兩個要點：做什麼，做到什麼程度什麼範圍。第一點決定了你有沒有技術能力做，後面一點決定了做多久，投入多少人。都是對專案有重大影響的，都要重視。
讓技術負責人今早參與到需要中來，也本身也很好理解。畢竟專案以後是要交給他來做的，他的評估意見才是最接近實際情況的。除非你對下面人的技術能力、效率、心理素質非常了解，才可以自己評估。否則還是特定問題交給特定人士解決。
可惜的是，我們一遍遍給自己挖坑，一撥換一撥的來填坑。好的開發人員也留不住，誰也禁不起這樣的折騰。做專案的聲譽也受損。
當然這裡並不是把責任全推給專案經理和商務人士。有些現實原因。中標完後甲方有要求盡快擬定合同，開工建設。長期合作，有基本信任，細節上就沒有不厭其煩的去溝通確認。還有乙個重要原因是，甲方在內部立項時有些是基於幾個領導的一些想法，或者內部開立項審議會時到場的只是領導、幾個關鍵人員，而這些人員並不是系統的主要使用者或頻繁使用者，提的需求也是比較抽象，目標化的。如：
滿足生產報表的資料自動提取；
快速響應
與現有的系統進行資料互通
實現報表的自動生成
看到這樣的需要，任何乙個都需要去深究。資料自動提取，怎麼提取，現有的資料在哪，什麼格式，多少量，任何乙個維度都左右著完成時間。快速響應，什麼叫快速？1秒叫快，0.1秒叫快。可能達到1秒很容易，但要達到0.1秒卻很難。
需求重要的一點就是要指標化，能驗證（能通過具體的資料、表現驗證需求是否達到）。否則驗收時就知道這些抽象的需求，解釋權在甲方那。達沒達到是人家說了算。
我們的專案還有個特點就是，開工後，基本就是開發人員與甲方的終端使用者溝通了。這就是痛苦的開始。那些抽象的需求，經過這些終端使用者的發散、擴充套件，早已不是當初預估的工作量了。而且還會經常變動，需求確認過程慢，他這塊業務不熟還得等他找人確認。這些終端使用者在提需求時，也不會考慮什麼專案範圍的，只要扯得上邊就提。包括個性化的要求，並不是我們當初分析時的通用設計、一般使用方式。不會想到一分錢一分貨，叫我提需求的，那我就可勁的提。如：能不能在你們**做個像qq那樣的功能，不要那麼多功能，能聊天，能傳檔案就可以。那個word有這樣的功能，你們也照著做個嘛。就問你想哭還是想笑。
太多這樣的經歷，碰到好說話的，懂技術的還好。否則讓你懷疑進錯了行。這又涉及到開發過程中需求變動沒有控制，靠開發人員與終端使用者溝通。溝通不好，一邊向領導反映說功能沒實現，接著投訴過來了。一邊覺得做不下去，沒法做，情緒激動，軍心不穩。
原因還是在開始階段需求不夠細化，收集不全。現實中也不大可能等你把所有使用者的需求收集完，分析完，再乙個個找人確認。全部確認完了再來報進度、**。但我們還是要盡量把需求做完善，技術負責人一開始就參與進來。沒法找使用者去量化需求的，先給個基礎量化值，留些餘地。如要做報表，卻沒給出具體數量，就先給個值：20張（50個資料項），超過的經過協商確定時間和費用。
需求明確了，後面的工作才有據可循，各自完成本職工作，專案的成功率才有保障， 這才是對雙方有利的事。
又跟專案經理「談判」
又要跟專案經理 談判 注意前面已經說過了 又 字，也就是再次的意思啦。的確我還是個沒有畢業的大學生而已，但是已經在公司工作半年了，從如公司的第三天起就開始進入專案組，開始編碼。參與的算是個大專案，而且我對於業務流程已經算是熟悉了，跟同事的關係也處理的不錯，在別人看來是個好事情啊，但是有乙個問題我就老...
我的專案，我的起點
這個怎麼說呢，2個專案報到了mscenter上面，如果說是難度的話，都不大。bluecross的技術含量不是很高，聊天室，bbs式的論壇，訂單的處理等等模組如果乙個人做的話，研究一些日子沒什麼問題，現在打算大家一起來做，3個小組，1個美工組，2個技術組，初步的打算是首先熟悉這些基本模組的技術，然後整...
未來一片迷茫，我只好帶上堅強勇敢去闖。
起風了 唯有努力生存 夢想注定是孤獨的旅行 學習總會累,堅持最可貴 有夢就去追 沒死就別停 奇蹟是努力的另乙個名字 心軟注定你是天生的輸家 相愛的把握 要如何在搜尋 別和過去爭,我們不是對手。在我生存過的地方我就是自己的神 魚沒有水會死水沒有魚卻會更清澈 想走的人都走了 只留下了不願走的 年少就應該...