最近我在做一專案，做的非常鬱悶，現在將發現的問題列出專案負責人不確定。這段時間都在圍繞這專案，其實這專案公司並沒有簽下來，公司的一副總與我們已經圍著這專案轉了三個多月了，說開發吧，可專案負責人都不知道是誰，有人可能會問，可能是我吧，呵呵，我也覺得是我，可我又不是專案組長，我為什麼要負責呢？就算我要負責，那這個專案不可能就我乙個人來做吧，總得向其他人員說說我負責這一專案，某某人歸我調遣，跟我一起完成專案吧。軟體開發是乙個團隊活動，現在不講究個人英雄主義!「你又不是專案組長，我憑什麼聽你的呢？」，唉！也是，我有這權利嗎？
做事情分工不明確。
溝通不流暢。
需求文件不清楚，格式不規範。 呵呵，需求是副總寫的，呵呵，使用者老在我們面前提「他媽的，你們寫的需求都是這邊貼一塊那邊貼一塊的！」
需求變更，這需求變更不是客戶提出的，是副總提出來的。軟體開發過程中，比較怕的就是需求變更了。呵呵，副總是搞技術出身的。提出的需求是使用者需要的還好，可偏偏把功能修改完成給使用者後，使用者則提出「原先不是好好的嗎？怎麼改成這樣了？」，聽到這句話，說不出的滋味湧上心頭！！唉！而且這種事情不是發生一次兩次了，我都跟那傢伙吵過，沒辦法，人家是老總嘛！是註冊會計師嘛！
做軟體開發以來都沒用碰到過的事情，所以我今天把我部落格的標題都修改了，修改為「軟體是一門科學，更是一門藝術」，說實在話，軟體開發是乙份很輕鬆快樂的工作，講究方法的工作。
軟體架構之需求層次 需求方面矩陣
廣義功能 質量約束 業務級需求 業務目標 快 好 省 技術性約束 法規性約束 技術趨勢 競爭因素與競爭對手 遺留系統整合 標準性約束 分批實施 使用者級需求 使用者需求 執行期質量 使用者群特點 使用者水平 多國語言 開發級需求 行為需求 開發期質量 開發團隊技術水平 開發團隊磨合程度 開發團隊分布...
管理感悟 談談使用者和需求
談談使用者和需求 柳鯤鵬2007 7 27 關鍵字 使用者 需求 簡介 使用者自己也不知道自己需要什麼，也不知道自己的需求。使用者提的意見，可以說絕大多數是沒有意義的 而使用者的需求，必須由你詳細考察使用者的工作過程才能搞清楚。軟體要做好，才有資格聽取使用者意見。別把使用者反映的產品的問題和缺陷當作...
談談用UML來做需求管理
今天在看 agile software development 讀到附錄中關於uml的介紹，不禁慨嘆 我以前在uml的時候怎麼就那麼的蹩腳呢，特別是在描述需求的時候。我剛剛設計了乙個專案，一開頭就碰到乙個頭疼的問題 需求分析。我想取消我們以前那種繁雜的用文字描述的文件方法，採用uml的圖形化來表示。...