一直都想針對於軟體專案研發，開發團隊說點什麼，可是每每拾起鍵盤又落下，因為憤世嫉俗的話一般都比較難聽。
公司不是慈善機構，公司存在的基本前提是盈利，或者至少有希望能夠看到未來盈利。乙個專案，如果一直都未盈利，而規模又在不斷變大，這個團隊就會漸漸失去投資人的信任，遲早有天會撤資。
軟體專案的垮掉，首當其衝的是產品需求的不足性與不確定性，需求分析與產品需求做的是否成功，是產品是否成功的關鍵性因素，也是研發人員能否把東西做好的基本保障。從建設的角度來說，研發軟體產品，和建房子異曲同工，先是有需求，再有設計稿，最後才開始動工建設，而某些開發團隊，前期的需求與設計稿都還沒做好，就草草的開始建設，而且早早的就招了一大批建設人員在等需求做，其後果就是養著一票人等著事情做。
曾經經歷過3,4個開發人員同時做乙個頁面的情形，每個人做該頁面的一小塊功能。先不說工作如何協作，**風格如何統一，各人的開發能力是否等同，提交**是否會衝突，但從中層管理對人員的分工來說，人員多需求少的情況很難處理，不給某個人分配工作，就會導致部分人沒事做的情形。而上層管理人卻一直覺得下面研發人員效率太低，進度太慢，又不加班，而卻沒有看到需求的不足性或者需求的不連續性。有時候看到技術人員不怎麼加班時，首先應該去檢查的是需求是否太少了。
有人會問，為什麼會出現這種情況？其根本原因是，前期開發人員過多，需求設計不足，產品設計人員缺少，或者產品設計人員能力有限，需求總是不能持續性的進行迭代，乙個版本下來，總會停留一段時間。另乙個方面，需求有些時候不能在原有版本上進行公升級，而是幾乎把原有功能完全推翻，重新做。這樣經過幾次折騰，開發人員心力交瘁，開發人員很多時候並不是不想努力趕進度，而是對於這種吃力不討好，重複性的勞動，會覺得很厭煩。一方面感覺白忙活了一通，成就感受挫，另外一方面自己也會覺得沒有什麼成長與收穫。
有人說，需求不就那麼幾個嗎，我要做成像某某產品那樣，我要擁有某某產品同樣的功能。說這種話的人，往往只會吹牛不幹實事的人，如果做產品真有那麼簡單，it業創業就不會那麼艱難了。其實這裡所說的需求，應該是將大需求細分成研發人員可以執行的產品需求，並制定為乙個研發里程碑，而不是乙個大概的功能，乙個最終的結果。以結果為導向來考核研發團隊，而不關注實現細節，其實是行不通的。
產品處於探索期，不應該做的太大太全，而是應該選擇一兩個市場能夠接受的點，先做精做完善。任何乙個成功的公司，很多時候都是從乙個很小的點慢慢做起來的。
軟體專案的垮掉，其次體現在員工工作分配的合理性以及對於工作效率質量的真實評估。
如果乙個創業團隊處於探索期，在嘗試不同的方向，加班很可能是沒多大價值的，產品早幾天晚幾點發布或許真的意義不大，還會把團隊成員搞的很疲憊，長此以往會失去信心。很多時候看到的加班是抽瘋似的加班，為了加班而加班。
加班確實是提高效率的途徑之一，但是有些時候為了趕進度，加班加點的做，但是這種東西做出來質量問題也會大打折扣，曾經經歷過乙個模組，3,5個技術人員連續加班乙個月，最後技術主管辭職了，留下了乙個漏洞百出的爛攤子，後面的人接手後改了數百個bug，使用者覺得不好用也不敢用，大量功能都基本沒什麼用處，最後整個模組只能作為擺設，當然這裡又跟前面提到的產品需求分析有關。
軟體專案的垮掉，還體現在人員組成上面。
很奇怪一些公司怎麼會招聘一些能力平平而又沒責任感的員工，招一大批這樣的人做開發，雖然說能夠實現需求，但是這種人寫出的**，往往不夠健壯，不會考慮太多擴充套件性，bug層出不窮，效能問題也經常出現。這種**後期維護的代價是巨大的，我們都知道軟體的成本包括了開發成本與維護成本，而維護成本有時候遠遠大於開發成本，乙個漏洞百出的系統，其維護成本是無可估計的，尤其是當不同的人員來接手的時候，就會越改越亂，越改越難維護，做過開發的人都知道，改別人的**是很痛苦的事情，還不如自己重寫，重寫的前提又是時間能否足夠的問題。但如果不重構，整個系統就會陷入小心翼翼的運轉階段，一旦業務量劇增，很難保證還能正常執行。
其實好的團隊，應該是2個人拿3個人的工資，幹4個人的活，這種機制，對於員工，對於公司都是有利的。好的程式設計師又何止以一敵二，《黑客與畫家》中提到，好的程式設計師有些時候甚至是以一敵
十、以一敵百，就如同一百個普通畫家也敵不過乙個梵谷一樣。
乙個團隊，沒有事業心的成員，沒有責任感的成員，遲早都會被淘汰，至少在組織進行調整時，在只能選擇乙個留下的情況下，這種人肯定不會被優先考慮。
軟體專案的垮掉，最後體現在管理及團隊建設上。
乙個團隊，如果激勵到位，使得所有人都具有渴望成功的巨大慾望，個個都捨得付出，那這只團隊的戰鬥力一定是同行裡面最強的，就算目前做出的產品比不上競爭對手，長此下去，一定會超過所有的競爭對手，成為行業裡面的no1。
研發人員在看待工作好壞的事情上，有時候並不一定是看只看工資，而更多是在工作量與薪水之間進行權衡，在成長性與薪水之間進行權衡，在自由與不自由之間進行許可權，在工作環境之間許可權。誰也不能忍受停滯不前的工作，停滯不前的能力，停滯不前的薪資，停滯不前的專案。
管理人員更應該給員工提供更多成長的空間，使得專案與員工共同成長。
憤世嫉俗的有點過了，待續……
論專案的UI設計
最近專案驗收過程中，再一次提出了 ui設計問題，到底怎樣才算是好的 ui設計，談一下我的體會。進入頁面首先映入眼簾的就是色調了，如果色調搭配的很好，會給使用者很舒服的感覺，有使用此軟體的興趣 如果色調搭配凌亂，讓人看著不舒服，估計沒人會喜歡 色調不能太單一，也不能過於豐富，這種搭配也算是一門技術兼藝...
論專案的質量管理01
對於資訊系統的質量，可以從以下層次來理解 1 資訊系統產品中能滿足給定需求的性質和特性的總體。例如，符合需求規格說明。2 資訊系統具有所期望的各種屬性和組合程度。3 顧客和使用者覺得資訊系統滿足其綜合期望的程度。4 確定資訊系統在使用中將滿足顧客預期要求的程度。質量管理是在質量方面指揮和控制組織的協...
論專案的質量管理02
1 質量計畫編制 2 專案質量保證 3 專案質量控制 4 過程改進 如何提公升專案質量。1 強有力的領導。強有力的領導是it企業提供資訊體統專案質量的基礎，去多質量專家都認為，質量問題的主要原因是缺乏強有力的領導，大部分質量問題出在管理上，而非技術上。2 建立組織級專案管理體系。it企業是全面實施專...