开源ERP-推广开源软件的企业应用

我的最新日志

  • 新年，新人，新气象

    2008-2-18

    又是新的一年，回顾2007年，我们做的有许多不足，HOWWELL ERP 6的开发遇到了很多很大的困难，虽然最终还是挺了过来，但换来的是满身心的疲惫。

    2007年是艰辛的一年，每个成员都付出了极大的努力，但所获无几。。。

    2008年再接再厉，迎接新的挑战！！！

     

    查看(4) 评论(0)

  • HOWWELL 招聘兼职人员 - 长期有效

    2007-10-21

    HOWWELL招聘兼职人员 - 长期有效

    HOWWELL是一家致力于研发推广开源ERP的公司，现在公司发展需要，特招聘兼职开发人员多员，要求如下：
    1.具有使用DELPHI开发信息化系统之经验
    2.能按软件设计文档编写代码
    3.具有开发系统所必须的电脑及网络环境等办公条件
    4.能按时按质完成所承担的任务
    5.需要有空闲时间来完成工作任务

    应聘兼职开发人员流程：
    1.下载填写兼职申请表，下载地址： http://www.howwell.org/doc/Apply.doc
    2.将填写好的《兼职申请表》发送邮件到 jacky@howwell.org
    3.进行编码考核
    4.考核通过后，就可正式成为我们的兼职开发人员
    5.正式成为我们的兼职开发人员后，就可以承接任务

    联系人：李先生
    QQ: 414154681
    MSN: how_well@hotmail.com
    电话：0769-84928570

    浩晖资讯
    www.howwell.org
    2007-10-20

     

    查看(12) 评论(0)

  • HOWWELL ERP 6 延迟发布

    2007-9-01

    预计今日发布的HOWWELL ERP 6的第一版本，因开发进度未能达成，故不能按期正式发布此版本。
    对此我们深表歉意，为了满足大家的期待，公司决定行先行发布一个预览版本，该版本功能不完善，仅做参考使用
    也希望大家就此提出一些改进意见（请大家到论坛提出），我们会在后期开发加以考虑及修正！

    请到www.howwell.org下载预览版本

    浩晖公司
    2007-08-30

    查看(80) 评论(0)

  • 为DELPHI项目搭建每日构建系统

    2007-8-13

    为DELPHI项目搭建每日构建系统

    每日构建或者是持续集成，是现代软件工程的重要方法，它保证了软件开发的持续改进，使得软件的集成性错误的及时发现，从而保证了软件的质量。

    对于较大型的项目而言，每日构建是必备一个重要环节，对于HOWWELL ERP团队来说也是如此。
    目前Java中有许多类似的功能可供选择，相对Delphi来说此类功能相对比较匮乏，现在介绍一下HOWWELL ERP目前使用的每日构建系统，为大家提供一个参考，也希望大家不吝提供见解。


    一.准备相关软件
      1.Delphi 2006   不用介绍吧
      2.Apache 2.0.55  http服务器
      3.Subversion 1.4.4  SVN服务端
      4.TortoiseSVN 1.4.4.9706 SVN客户端
      5.FinalBuilder 5  每日构建系统
      6.Help Manual 4.1.0.853 帮助文件制作程序
      7.NSIS 2.29   安装制作程序

      下载并安装以上所有软件

    二.构建版本控制系统
      使用2-4项软件来构建版本控制系统

    三.制作帮助文件

    四.制作安装程序脚本文件
      使用NSIS制作安装程序脚本

    五.编译构建流程
      使用FinalBuilder 5设置好每次构建的流程


    大体上分为以上五个步骤，因为时间的关系，我会再补充完善！

    查看(115) 评论(0)

  • 郑重声明 - 敬告HOWWELL ERP使用者

    2007-5-31

    近来接到一些HOWWELL ERP 5的使用者发来的信息，说在使用HOWWELL ERP 5 时出现了这样那样的问题，有些在升级过程中的误操作，甚至引起了前期录入的数据不可恢复，造成了使用者的极大困扰。
    在此我们郑重声明，如使用者需在有相关资格的专业人员的指引下进行HOWWELL ERP 5的使用，自行使用者所引起的后果，浩晖公司对此不承担任何后果。

    浩晖公司
    2007-05-31

    查看(43) 评论(0)

  • ERP的技术之痛：B/S还是C/S？

    2007-5-20

    ERP的技术之痛：B/S还是C/S？

    　　你的产品是B/S还是C/S架构的？如今当厂商在应标时，经常被用户问到类似的技术问题。可以说，B/S还是C/S，已成为当前ERP 产业发展中不可回避的技术架构问题。

    　　其实，无论是B/S还是C/S，他们并不新鲜。C/S（Client/Server，客户端/服务器）技术从上世纪90年代初出现至今已经相当成熟，并得到了非常广泛的应用，其结构经历了二层C/S、三层C/S的更迭。B/S（Browser/Server，浏览器/服务器）技术则是伴随着Internet的普及而来的。有必要说明的是，B/S最早并不叫“B/S”，此类应用国外通常叫Web应用(Web Application、Web Based Application)，是国内一些公司“创造”了“B/S”这个词。

    　　应该说，B/S和C/S各有千秋，他们都是当前非常重要的计算架构。在适用Internet、维护工作量等方面，B/S比C/S要强得多；但在运行速度、数据安全、人机交互等方面，则B/S远不如C/S。综合起来可以发现，凡是C/S的强项，便是B/S的弱项，反之也然。因此，问题也就因此而产生了，我们的ERP产品到底该用B/S还是C/S架构呢？一场关于C/S与B/S的口水战也由此而在ERP业界拉开了序幕。在互联网泡沫盛行的2000年至2002年间，这场口水战达到了顶峰。但直到现在，人们也没有辩出谁是谁非。

    　　事实上，从上面的分析可以看出，这场口水战不可能有胜负出现，因为B/S与C/S具有不同的优势与特点，他们无法相互取代。例如，对于以浏览为主、录入简单的应用程序，B/S技术有很大的优势，现在全球铺天盖地的Web网站就是明证；而对于交互复杂的ERP等企业级应用，B/S则很难胜任，从全球范围看，成熟的ERP产品大多采用二层或三层C/S架构，B/S的ERP产品并不多见。

    　　“B/S还是C/S”也就由此成了ERP的技术之痛。难道这个痛就无药可救了吗？

    查看(2322) 评论(7)

  • 迈向高质量软件的12个步骤

    2007-5-19

    邁向高品質的12個步驟

    作者：周思博 (Joel Spolsky)
    譯：Paul May 梅普華
    編輯： Nick Wong
    2000, 8, 9


    聽說過SEMA嗎？這是一套相當深奧的系統，可以測量軟體團隊的好壞。等一下！不要急著連過去看。光是要搞懂那東西大概就要花上六年了。所以我自己有一套無責任的簡易方法來衡量軟體團隊的品質。這套方法的好處是只要花3分鐘左右。省下的時間足夠讓你唸趟醫學院。

    約耳測試 (Joel Test)
    1. 你有使用原始碼控制系統嗎？
    2. 你能用一個步驟建出所有結果嗎？
    3. 你有沒有每天都重新編譯建立(daily builds)嗎？
    4. 你有沒有問題追蹤資料庫(bug database)？
    5. 你會先把問題都修好之後才寫新的程式嗎？
    6. 你有一份最新的時程表嗎？
    7. 你有規格嗎？
    8. 程式人員有沒有安靜的工作環境？
    9. 你有沒有用市面上最好的工具？
    10. 你有沒有測試人員？
    11. 有沒有在面試時要求面試對象寫程式？
    12. 有沒有做走廊使用性(hallway usability)測試？


    約耳測試的好處是每個問題都很容易回答是或否。你不必計算每天寫的程式行數或是每個轉折點的平均問題數量。只要答「是」就加1分。約耳測試的缺點是絕對不能用來確保核電廠的安全性。

    得12分是完美，11分勉強可接受，不過10分以下(含10分)就表示問題大了。事實上大部份軟體組織都只拿到2或3分，這些組織都岌岌可危，因為微軟隨時都是以12分的水準運作。

    當然啦，這些並不是決定成敗的唯一因素：特別是當你的優秀團隊做些沒人要的產品時(對，沒人要)。另外也可能有那種「高手」團隊，即使完全不鳥這些東西卻還是能做出改變世界的夢幻軟體。不過除此之外其他人都一樣，如果你能把這12件事做好，就能建立一個能穩定出貨的紀律團隊。

    1.你有使用原始碼控制系統嗎？
    我用過一些商用原始碼制系統也用過免費的CVS，我可以告訴你CVS相當不錯。不過如果你沒有原始碼控制系統，當需要程式人員合作時你就會被壓垮了。程式人員沒法子知道其他人做了些什麼。也不能輕易回復成出錯前的狀態。原始碼控制系統還有另一個優點，就是原始碼會被登出(check out)到各個程式人員的硬碟裡 -- 我還沒看過哪個用了原始碼控制的專案會遺失大量程式。

    2.你能用一個步驟建出所有結果嗎？
    我的意思是：從最新的原始碼快照開始，要花多少步驟才能建立出貨用的軟體？好的團隊會有單個腳本檔案，只要執行這個檔案，就會從頭登出所有檔案，編譯每一行程式，建立執行檔(包含所有不同版本，語言以及#ifdef組合)，製作安裝程式，並且產生出最後要用的媒體形式 -- 光碟片編排，網站下載或是其他各種形式。

    如果這個程序不只一個步驟就會容易出錯。另外當出貨時程緊逼時，修正「最後的」問題，製作最終執行檔等等的過程要能飛快地完成。如果程式編譯和安裝檔製作等動作要20個步驟才能完成，你一定會急瘋掉並且做出一些蠢事。

    就是為了這一點，我前一家公司把原本用的WISE換成InstallShield：我們需要能透過NT工作排程器，在晚上用描述檔自動執行的安裝製作程序，由於WISE不能透過工作排程器半夜執行，所以我們就把它丟掉了。(親切的WISE員工跟我保證他們的最新版一定會支援夜間執行。)

    3.你有沒有每天都重新編譯建立(daily builds)嗎？
    在使用原始碼控制工具時，有時候程式人員會不慎登入(check in)某些內容而導致編譯失敗。舉例來說，某人新增加了一個原始程式檔，整個程式在他的機器上都能正常編譯，可是卻忘記把新增的程式檔加到原始碼控制程式庫中。結果這位仁兄健忘並快樂地鎖上機器回家了。其他人都不能做事，所以也只好很不爽地回家。

    導致編譯失敗非常糟糕(又經常發生)，這時每天重新編譯建立就很有幫助了。它能保證不會有漏網之魚。在大型的團隊中，要確保能立即修正編譯失敗的最佳方法就是每天下午(像是午餐時間)重新編譯。大家在午餐前儘可能的登入檔案。等大家回來的時候已經編譯完畢。如果結果正常，很好！大家可以登出最新版的原始碼繼續工作。如果有問題就去把它搞定，而其他人還可以用前一版沒問題的程式繼續幹活。

    我們Excel團隊有個規定，導致編譯失敗的人必須從此負責重新編譯的動作(作為處罰)，一直到有其他人出錯為止。這是個讓人不要導致編譯失敗的好誘因，同時是個讓大家輪流處理重新編譯的好方法，這樣大家都會知道怎麼做。

    我這篇文章裡有更多每日重新編譯的資料：每日編譯是你的好朋友。

    4.你有沒有問題追蹤資料庫(bug database)？
    不管你說什麼。只要你在寫程式(只有一個人寫也一樣)，如果沒有一套良好的資料庫列出程式中所有的問題，一定會產生品質低劣的程式碼。很多程式人員自認能把問題清單記在腦裡。才怪。我從來沒法子一次記住超過二或三個問題，而且會在第二天早上或是趕著出貨時把它們全部忘掉。你一定要正式的記錄問題。

    問題資料庫可大可小。一個最簡化的有效問題資料庫必須包含每個問題的下列資料：

      1. 重現問題的完整步驟
      2. 應該看到的行為
      3. 實際看到的(有問題的)行為
      4. 被指派的負責人
      5. 是否已修正

    如果你是覺得問題追蹤軟體太複雜才不追蹤問題，建個5欄的表，填上這些重要欄位然後開始用吧。

    想深入瞭解問題追蹤，請參閱無痛錯誤追蹤。


    5.你會先把問題都修好之後才寫新的程式嗎？
    古早第一版的Microsoft Word for Windows被視作為「死亡行軍」型專案。進度一直落後。整個團隊的工作時間長得離譜，專案卻一延再延三延，大家都承受到無比的壓力。拖了幾年後那個鬼東西終於上市了，微軟就把整個團隊送到Cancun(墨西哥著名海灘)渡假，然後再坐下來做些深度反省。

    他們發現專案經理過度堅持要保持「進度」，結果程式人員只能趕工寫出爛程式，而且正式的時程並沒有包含錯誤修正的階段。沒有人試圖要減少問題數量。而且實際上剛好相反。有個程式人員要寫程式計算一行文字的高度，結果他只寫了"return 12;"並等問題報告出爐說這個函數功能不對。時程表變成一份等著被轉換成問題的功能列表。事後檢討時稱之為「無窮錯誤法」。

    為了修正這個問題，微軟全面採用所謂的「零錯誤作法」。很多公司裡的程式人員都不禁竊笑，因為聽起來像是管理階層認為能用行政命令降低錯誤數量。實際上「零錯誤」是指無論何時都要先修正錯誤才能寫新程式。原因如下。

    一般來說，愈晚修正錯誤，修正所付出的成本(時間及金錢)愈高。

    舉例來說，當你打錯字或出現編譯器會發現的語法錯誤，要修正只是小事一件。

    當你的程式第一次執行出錯時，應該也能立即改正，因為整個程式還在你腦海裡。

    如果要為幾天前寫的程式除錯，應該需要回想好一陣子，不過當裡重讀所寫的程式之後，就會記起所有細節並在適當時間內把問題修好。

    不過如果你要為幾個月前寫的程式除錯，很可能已經忘掉了一大半，要修正就是難上加難。你也可能正在替別人的程式除錯，而當事人可能正在阿盧巴渡假，這時候除錯就像科學一樣：你得條理分明小心翼翼地慢慢來，而且也無法確定要多久時間才能解決。

    另外如果要為已出貨的程式除錯，要修正問題的代價可是難以估算的。

    要立即修正問題的理由之一，就是因為這樣做能少花點時間。另一個理由是寫新程式的時間還比修正現有錯誤的時間較易估計。舉例來說，如果要你估計寫個串列排序的程式需要多久，你應該能估算得相當準確。不過如果說你的程式在裝了Internet Explorer 5.5之後有問題，要估計需要多久才能修好這個問題，恐怕你連猜都不會，因為你不知道(當然不知道)問題哪兒來的。要找出問題可能要花3天，也可能只花2分鐘。

    我的意思是如果你的計劃時程裡有很多錯誤待修正，這種時程是不太可靠的。不過如果把已知的錯誤都修好了，所剩的就只要新程式了，那麼你的時程就會變得非常準確。

    把錯誤數量維持在零還有另外一個優點，就是面對競爭時反應更快。有些程式人員認為這樣做能讓產品隨時能推出。所以如果競爭者推出某個殺手級新功能來搶客戶，你只要把那個功能加上去就可以立即出貨，不必去修正累積下來的大量問題。

    6.你有一份最新的時程表嗎？
    我們在這裡要談談時程表。如果你的程式對公司非常重要，有太多理由可以說明預知程式完成時點有多麼重要。程式人員不愛訂定時程可是惡名昭彰。他們會對業務大叫：「該完成的時候就會完成！」

    但是問題不可能就這樣算了。業務人員有太多的計劃決策必須遠在程式出貨之前做決定：展示，商展，廣告等等。而做決定的唯一方法就是定出時程並隨時更新。

    擁有時程的另一個重點是逼你決定要製作哪些功能，並且能逼你剔除最不重要的功能而避免功能過度膨脹(featuritis，又名scope creep)。

    要維護時程表並不困難。請參閱我的文章無痛軟體時程，文中敘述建立好用時程表的簡單方法。

    7.你有規格嗎？
    寫規格像用牙線：大家都同意這是好事，卻沒有人真的在做。

    我不知道為什麼，或許是因為大多數程式人員都討厭寫文件吧。所以當全是程式人員的團體面對問題時，自然傾向用程式碼而非文件來表示答案。他們寧願跳進去寫程式也不願先寫規格。

    在設計階段發現問題時，只要改幾行就能輕易修正。等程式寫出來之後，修正的代價就高得多了，代價包含了情感(人們討厭拋棄程式碼)和時間，所以會抗拒修正問題。通常未依據規格製作的軟體最後的設計都很糟，而且進度完全無法控制。這似乎就是發生在Netscape上的問題。它的前四版變得一團亂，結果管理階層愚蠢地決定把程式丟掉重新開始。然後他們在Mozilla上又重蹈覆轍，造出了一個無法控制的怪物，而且耗了幾年才進入alpha測試階段

    我的拿手方法是把程式人員送去上密集的寫作課程，讓他們變得不那麼排斥寫作，就可以解決這個問題。另一個方法是雇用聰明的專案經理來寫規格。不管用哪一種方法，你都應該強制執行「沒有規格不寫程式」這個簡單的規則。

    你可以由我寫的四篇系列文章學到所有關於規格的內容。

    8.程式人員有沒有安靜的工作環境？
    有大量的文件記載，為知識工作者提供空間安靜及隱私可以提昇產能。軟體管理經典Peopleware大量記錄了這種產能上的增益。

    這就是問題所在。我們都知道知識工作者進入「狀況」(flow，也被稱作in the zone)時工作效果最佳，這時候他們會完全與環境脫離，全心專注在工作上。他們忘記時間並透過絕對專注產出極佳成果。他們所有豐富的產出也都是在這個時候完成的。作家，程式人員，科學家，甚至籃球球員都會告訴你進入「狀況」的情形。

    問題是要進入「狀況」不是那麼容易。如果你有試著計時，平均大概要15分鐘才能開始全速工作。有時如果你累了或是那一天已經有很多創造性的成果，會根本無法進入「狀況」，然後看看網頁玩玩俄羅斯方塊打混過完一天。

    還有一個問題就是很容易脫離「狀況」。噪音、電話、同事的中斷(特別是這一點)都會讓你脫離「狀況」。假設有個同事問了一個問題讓你中斷了1分鐘，實際上卻會讓你完全脫離「狀況」，得再等半個小時才能回復生產力，結果你的整體產能都出問題了。如果你身在一個喧鬧的BULLPEN環境中(像那些一窩蜂(caffeinated)網路公司最愛營造的典型)，行銷部門在程式人員旁對著電話大喊，你的產能就像一直被中斷的知識工作者一樣顛簸，永遠無法進入「狀況」。

    這對程式人員來說更加嚴重。生產力多寡在於是否能在短期記憶體中處理大量的細節。任何一種中斷都會讓這些細節完全消失。等你轉回來工作時就完全不記得任何細節(比如正在使用的區域變數名稱或是搜尋演算法寫到哪了)，必須把剛剛的東西找出來，於是速度就放慢下來一直到你回復為止。

    這裡有個簡單的算術。我們可以說(依照陳述所暗示的)雖然僅僅打斷程式人員一分鐘，事實上是去掉了15分鐘的產能。以此為例，假設有兩個程式人員Jeff和Mutt，把他們安排在一個標準呆伯特(Dilbert，美國漫畫)養牛場裡相鄰的開放隔間中。Mutt忘記了strcpy函數的Unicode版本拼法。他可以花30秒自己查出來，也可以花15秒問Jeff。由於人就坐在旁邊，所以他問Jeff。Jeff分心所以就損失了15分鐘的產能(替Mutt省了15秒)。

    現在把他們搬到兩間有牆有門的獨立房間裡。如果Mutt忘記那個函數的拼法，他可以花30秒查出來，也可以花45秒過去問Jeff(就典型程式人員的身裁來說離開位置並不輕鬆)。結果他就自己查了。於是Mutt損失30秒的產能，不過卻替Jeff省下15分鐘。哎呀呀呀！

    9.你有沒有用市面上最好的工具？
    用編譯語言撰寫程式是一般家用電腦還無法瞬間完成的最後幾件事之一。如果你的編譯過程超過數秒，去找台最新最棒的電腦可以替你省點時間。如果編譯需要超過15秒，程式人員覺得無聊就會跑去看線上新聞The Onion，然後陷在裡面耗掉幾個鐘頭的產能。

    在單螢幕系統上替GUI程式除錯並非絕不可能，不過用起來有夠痛苦。如果你在撰寫GUI程式，弄兩台螢幕會讓你輕鬆許多。

    大部份程式人員到最後都得修整圖示或工具列所用的圖，可是大部份人都沒有一個好用的圖形編輯器。用微軟的小畫家修圖簡直是笑話，不過卻是大多數程式不得不做的事。

    在我前一家公司，系統管理員會一直送些垃圾信給我，抱怨我在伺服器上使用了超過「220 MB」的硬碟空間。我說依據現在硬碟的價格，這點空間的費用還遠比不上我所用的衛生紙。即使只花10分鐘清理目錄也是生產力的極大浪費。

    一流的開發團隊不會虐待他們的程式人員。即使工具不好所引起的挫敗很小，累積起來都會讓程式人員心情不爽脾氣暴躁。而不爽的程式人員就等於無生產力的程式人員。

    除此之外...程式人員也是很容易用最酷最新的東西賄賂的。這可遠比再增加薪水叫他們工作要便宜多了！

    10.你有沒有測試人員？
    如果你的團隊沒有專門的測試人員(至少每兩到三個程式人員要配一名)，你要不是推出問題很多的產品，就是浪費錢叫時薪100美元的程式人員去做測試員(時薪30美元)做的事。省測試員絕對不是真省，這實在是再明顯不過了。我實在很驚訝很多人卻還認不清這一點。

    看看不用測試人員的五大(錯誤)藉口吧，這是我針對這個題目所寫的文章。

    11.有沒有在面試時要求面試對象寫程式？
    你可能不叫魔術師先表演幾招就直接雇用嗎？當然不會。

    你可能不先嘗嘗菜就決定自己婚宴的餐廳嗎？我很懷疑。(除非是Marge姑姑，如果不讓她弄一道「頂級」碎牛肝餅，她會恨你一輩子)。

    儘管如此，現在程式人員是否錄用都還是要看履歷是否突出，或是因為主試人員面談聊得很高興，或是回答些查文件就知道的瑣碎問題(比如CreateDialog()和DialogBox()間的差異是什麼？)。你根本不會管他們能否背出幾百條有關程式設計的瑣事，你真正在意的是他們能否寫出程式。更糟的情況是問那種「啊！我懂了！」的問題：就是那種知道答案時理所當然，可是不知道答案時卻莫名其妙的問題(譯註：像是腦筋急轉彎)。

    拜託別再這樣做了。隨便你想怎麼面試都行，不過記得一定要讓面試者寫些程式。(需要更多建議時可以看我寫的軟體人員面試教戰守則。)

    12.有沒有做走廊使用性(hallway usability)測試？
    走廊使用性測試是說到走廊攔住下一位經過的人，然後逼他試用你剛寫好的程式。如果你做夠五個人，就可以發現程式中95%應注意的使用性問題。

    良好的使用者介面設計並沒有想像中那麼困難，在吸引客戶中意並購買產品時又是極為重要的。你可以參閱我寫的免費線上UI設計書，是針對程式人員的短篇入門書。

    不過處理使用者介面時有一點最重要：如果你把程式展示給少數幾個人看(事實上五或六個就夠了)，就能快速地發現一般人會遇到的主要問題。Jakob Nielsen的文章中有解釋原因。即使你的UI設計技巧不足，只要強逼自己實行不花什麼工夫的走廊使用性測試，就會讓你的UI水準大幅提昇。

    約耳測試的四種用法

      1. 對你自己的軟體組織評分，再把分數給我作為講八卦的題材。
      2. 如果你是一個程式設計團隊的經理，可以用它來確保團隊能在最佳狀態工作。等拿到12分之後，就可以把程式人員放著不管，專心去避免業務的干擾就好了。
      3. 如果你正在決定是否接受一份程式設計的工作，可以問問未來可能的雇主他們能拿幾分。如果分數太低時要先確定你有權修正這種問題。否則你將會灰心喪氣而且一事無成。
      4. 如果你是個正在評估某個程式設計團隊價值的投資者，或是你的公司正考慮與其他公司合併，這個測試可以提供快速的判斷方法。

    查看(40) 评论(0)

  • HOWWELL项目最新进展

    2007-5-01

    今天是五一，劳动者的节日，祝全体劳动者节日快乐！

    HOWWELL ERP 6 的进展在此简要作个汇报总结，需求分析工作已经完成，目前正在确认评估之中，一切顺利的话可以在五月中开始详细设计了，以后的发展应该会顺利些。

    团队建设，经过一轮面试，我聘用了两个，技术能力都不强，不会我聘用他们的主要原因，是因为他们有激情，能干活，这是我需要的团队成员的基本要求。在通知他们聘用消息时，其中一人问了我很多有关待遇、工作时间等等问题，让我感觉很不好，在前期的招聘过程中也遇到过此种人员，我基本都不会考虑这种人。这让我多少有些困惑，是否现在的人都功利心太重，太过浮躁，都以眼前利益为重？？也可能是我的心态有些问题。。。应该好好反思一下。

    接下来再说说 HOWWELL ERP 6 的发展，从2006年12月立项以来，已经过了5个多月，进度可谓缓慢之极，领导一个如此大的ERP项目，一来本身经验不足，二来运作模式也个前所末有的挑战。在需求分析过程中也走了一些弯路，本想完全自选分析设计，也由于水平所限，而于半途夭折，痛定思痛后决意参考一个成熟的ERP产品。在转换思路后目前进展还算顺利。

    再说说 HOWWELL ERP 5 （www.howwell.org已发布，大家可以下载）因为所有成员都在HOWWELL ERP 6中全力以赴，所以HOWWELL ERP 5基本停滞下来，许多BUG没有修正，在此请大家谅解。HOWWELL的发展路线是，将会以新产品完全取代HOWWELL ERP 5，此新产品是一个全新的产品，与HOWWELL ERP 5基本没有任何联系了。

    查看(82) 评论(3)

  • 项目进展

    2007-3-28

    项目进展目前到了比较艰难的阶段，新的项目小组经过二个多月的努力还是没有建立起来。
    反思当初的抉择确实有些草率，在没有面试的情况下，仅通过QQ和电话而确认了人选，这为以后的工作带来了隐患。还好这个问题，暴露的比较早，还不致于影响太大。这也是个难得的经验和教训。人总是在失败中学会成长，没有失败人总是长不大，我以前听过的这句话，现在想来确实深有体会。

    项目的需求分析的发展也是出现了一些波折，所幸及时改变了策略，目前还算进展比较顺利，不过时间上也就有所延误了。刚开始时，我们是想以本身的经验加上参考一些成熟软件来做出一个全新的产品，在这个原则下我们经过努力确实做出了一个库存管理子系统，时间用了差不多1个月。如此下去，不要说编码，仅需求分析就要花上一年的时间，而我们整个项目才不过一年而已。几经努力，终于痛下决定，直接参考成熟的ERP产品做为原型，删减一部份功能作为我们产品的需求分析，在此基础上我们再行发展。

    查看(25) 评论(1)

  • HowWell 2007年计划

    2007-2-13

    目标1：HowWell DDS 1 发布   2007-01
    目标2：HowWell EFS 1 发布   2007-02
    目标3：宏科ERP项目完成    2007-11
    目标4：HowWell ERP 6 发布   2007-05
    目标5：HowWell ERP加盟厂商达10家以上  2007-12
    目标6：HowWell ERP服务收入10个项目以上  2007-12
    目标7：HowWell 团队正常运作   2007-03

    查看(27) 评论(0)

Open Toolbar