原创 第十七天 文檔

問:說到文檔,東西再好,包裝不行,就上不了檔次。這個我很理解。過去有一個小公司想代理我們公司的軟件,但我們連演示版都沒有,最後告吹。可是寫文檔是件很矛盾的事情,因爲最清楚功能的人當然是開發部的人,但是我們整天在編碼哪有時間再去寫文檔,而且

原创 第十六天 測試

問:我過去在另一家公司,從調研、設計數據庫設計功能、開發、測試、寫文檔、實施推動上線協調各方、培訓、修改客戶需求、接聽客戶電話都是開發部一夥人自己做。   現在這家公司還好點,有實施部,有客服部。測試就是他們在做。但也都是糊弄事,他們又不

原创 第十九天 第一個客戶檢驗

問:產品出來了,確實需要到客戶處真正運行了才能知道這個產品到底實用不實用,那選擇客戶上有什麼技巧沒有?   答:首先,選擇什麼客戶。一定要選擇一個匹配你的產品的客戶。因爲這是你最大份額的客戶,也是以後最容易擴展的客戶類型。當然你的產品首先

原创 第二十七天 客服支持

問:產品穩定,產品也有亮點,培訓也上檔次,文檔也齊全。確實,客服這回清閒了。那客服的作用是什麼呢?   答:客服當然有用了。   首先,對於上一講的需求,計算機室人員要交給客服部而不是直接交給開發部。客服部會首先把需求記錄進“需求與BUG

原创 第十二天 細描

問:老師,現在咱們有了功能點,也劃分了里程碑,在里程碑裏劃分了優先級。現在我們是不是就該對功能點進行詳細描述了。   答:對。這時候就進入了功能詳細描述階段。但是需要說明一點是:   我們只描述第一里程碑第一優先級的功能點,而且描述好一個

原创 第十五天 編寫代碼

問:我們現在可以開始編碼了,這是我們最擅長的事情,那麼在這個環節我們該注意些什麼呢?   答:在《業務開發小組》一節中我就講到,業務組長在設計功能時就要思考這個功能是不是一個其他小組也要用的功能。   這樣思考帶來的好處就是: 1大家在協

原创 第二十四天 實施之需求

問:實施時候,需求也是拖延我們實施很多時間的重要因素之一。客戶遲遲不上線,不上線我們就無法驗收。那我們該怎麼辦呢?   答:首先,你們要有一些策略的調整。你們是以什麼爲驗收標準。以客戶上線爲驗收標準是不科學的,因爲什麼算上線定論不一。我們

原创 編寫可靠的 .NET 代碼

當 我們談論某樣東西具有可靠性時,我們是指它值得信賴,而且可以預測。但是就軟件而言,還必須具備其他重要屬性,纔可以說代碼具有可靠性。   軟 件必須具有復原性,意思是說在出現內部和外部中斷情況時,它仍然可以繼續正常運行。它必須是可恢復的,

原创 第十四天 工具

問:老師,我們現在功能點、里程碑、優先級、功能點詳細描述、界面原型、數據庫結構、數據操作描述都做好了,那麼我們是否下一步就開始編碼了?   答:不。你們還需要工具。   你的軟件質量不行,銷售部一演示就報錯,實施部讓客戶用不起來,客服部整

原创 第二十二天 實施之數據準

問:我們的實施太混亂了。去了,才發現要初始化的數據,客戶那裏的數據根本對不上口。都是陳年爛賬,編碼重複,編碼不規則,名稱重複,計算方法錯誤,缺信息,就爲了準備基礎數據,就需要讓客戶方派誰來整理,誰來輸入,誰來校對。但是往往找誰都說抽不開身

原创 第二十天 考覈

問:現在終於理順了,產品銷售鋪開了,但是開發部現在我發現微妙的變化了。因爲大家都拼死拼活的走到了今天,總的有個結果吧?這個結果怎樣才能讓人滿意呢?真是個頭疼的問題   答:有了需求與BUG任務管理系統,有了代碼服務器,有這兩個管理工具,考

原创 第十八天 發佈

問:現在終於大功告成了,我們的軟件該發佈了。在這一步我們應該注意些什麼呢?   答:首先,版本打包。版本號,打包、註冊項、公共文件、密鑰許可證、幫助文件、數據庫安裝腳本這些最必須的。   另外,產品白皮書、快速入門,操作視頻,都要把這些東

原创 第二十六天 實施之每日報告

問:改成現在這種模式後,實施人員其實就是培訓人員了。但是實施人員也承擔着推動上線的任務,不上線,人家客戶就不給我們尾款呀,我們人總在那裏等着也不是回事,我們耽誤不起,我們還有其他工程要去實施呢,這個問題,老師您有什麼好的方法呢?   答:

原创 第二十一天 實施的規矩

問:開發部有規矩,那實施部的規矩是什麼呢?   答:開發部的規矩的目的是爲了限制自由散漫的開發人員的。   而實施部的規矩也是爲了限制實施人員不要在客戶面前毀了公司形象。因爲,除了銷售部和老闆,接觸客戶的主要成員就剩下實施部了,而且實施人

原创 ACE編譯設置 在Unicode中使用ACE

Don't change config.h, add ACE_HAS_WCHAR to Project properties->C/C++ -> PreprocessorThe following setting must be the