在大連訂單管理軟件開發(fā)的過程中，一些技術(shù)人員給他留下了深刻的印象。等到解決掉所謂的技術(shù)難點，項目進度已經(jīng)開始有點滯后了。所以他要求項目成員加班加點追趕進度。不久，項目開發(fā)工作結(jié)束了，盡管有點延遲，但還算交代得過去。噩夢從測試階段開始了。無數(shù)的bug冒了出來。他每天都疲于奔命，安排開發(fā)人員修改這些bug，項目最終延遲了兩個月。
最后，在項目總結(jié)會議上，項目經(jīng)理把這次不成功的實踐歸結(jié)為三點：第一點，這是一個時間很緊的項目；第二點，項目中的技術(shù)難點沒有充分估計；第三點，部分軟件開發(fā)人員質(zhì)量意識太薄弱。項目經(jīng)理的老板似乎看得稍遠一些，他認為，項目中應該采用一些敏捷的軟件開發(fā)方法。 會議結(jié)束后不久，新的項目又開始了，項目經(jīng)理又開始制定新的計劃，并重復著剛剛發(fā)生不久的故事。 小程序軟件開發(fā)和訂單管理軟件開發(fā)在開發(fā)過程中有很多相同地方。
在上面的故事中，我們提到了大連訂單管理軟件開發(fā)項目管理的問題，在第9章中，我們會進一步展開這個話題。這里想問的是，誰應該對這一個項目負責呢？ 我們再來看一個故事。 兩年前，公司開始研發(fā)新產(chǎn)品。研發(fā)部門成立了一個技術(shù)小組。這個技術(shù)小組有一個Leader，五個成員。每個成員都有自己的分工，例如，技術(shù)平臺、領(lǐng)域模型、集成框架等。這種分工幾乎是自然形成的，因為在進入技術(shù)小組前，這些成員就已經(jīng)在從事相關(guān)的工作了。 研發(fā)項目啟動后不久，Leader召集了一次會議，他希望每個成員可以定期介紹自己研發(fā)的階段性成果。在成員A介紹自己的設計思路時，成員B表達了自己的看法，緊接著，成員C也臨時產(chǎn)生了一些想法，他建議的設計方向獲得了大多數(shù)與會人員的贊同。
只有成員A仍然在堅持自己的想法，會議漸漸演變?yōu)橐粓鲇懻摵娃q解。 Leader對會議的氣氛感到非常滿意，但是對于成員A的固執(zhí)己見有些不滿。他做了一個決定，要求成員A采用成員C的方案，并結(jié)合成員B的想法對自己的設計思路做出修改。經(jīng)過這一次會議，Leader感到有必要更加頻繁地召開類似的會議，希望借助于團隊的力量獲得最佳的方案。 兩年后，新產(chǎn)品出爐了。但是在應用到大連訂單管理軟件開發(fā)項目時，發(fā)生了誰也沒有預料到的問題，如性能問題。這個性能問題來自兩年前成員C的想法。為此，研發(fā)部門成立了一個性能調(diào)優(yōu)小組，并投入高額的維護成本。
