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