2008-10-15 30 views
26

我目前在一家定製軟件代理商工作。有沒有人有如何贏得價格合理的工作經驗?軟件公司如何提供高質量的軟件/贏項目?

似乎有來自離岸/臥室編程團隊的競爭太激烈了,這些天成本極具競爭力。與預算方面的軟件產品公司或內部IT部門相比,我覺得它有很大的不同。正如其他人之前所說的,我們只能真正使用我們軟件的1.0版本,除非客戶端足夠大。在這種情況下,花時間製作軟件是我們所能做到的最好的方式,這沒有任何意義。這就像我們正在與內部IT人員一樣完成相同的工作質量。也有很多客戶不是技術專業人士,所以不會爲他們不明白的東西付錢。

由於我們公司沒有資金來拒絕工作,所以我們往往會花費太多的錢來完成複雜的工作。我在管理變化和保持嚴格的規格等方面已經有了很大的改進,但仍然很難。

編輯-----------------------

近3年從這篇文章,我可以列出我學到一些重要的教訓自那以後。

請參閱下面我的回答

+0

你的問題在哪裏? – 2008-10-15 17:54:41

+1

@進入空間:固定。 – Shog9 2009-05-22 16:46:18

+6

喬爾和傑夫在他們的播客中給出了他們的答案http://blog.stackoverflow.com/2009/05/podcast-54/(大約35分) – 2009-05-22 20:44:25

回答

9

如果您關心做太多的工作太少的錢然後每小時工作一次。是的,在大多數情況下很難銷售。

也許你可以嘗試兩階段的方法。如果可交付成果是非常具體的要求文件,成爲客戶的財產,那麼首次參與度非常低。您必須冒險參與實際的開發,但是您不必承擔項目定價過低的風險,因爲您已經瞭解客戶需要處理的內容以及應用程序需求。

一旦您以合理的價格贏得工作,然後使用mathieu建議的最佳實踐來幫助確保質量和生產力,從而降低您的成本。

1

這是我的開發人員的角度來看:

  • 版本控制最佳做法:保持軀幹清潔,不要提交代碼無法編譯,並經常犯
  • Continuous integration
  • Unit testing(與代碼覆蓋率)
  • 在測試服務器上自動部署
  • 應用
  • 自動化的自動包裝,就像你可以:)

此外,聘請good developerstreat them well :)

+0

好的列表,但他們真的與敏捷無關(或者至少並不敏捷)。無論您的實際開發生命週期方法是什麼(敏捷,srcum,xp,瀑布等),您列出的所有內容都是良好的實踐。 – 2008-10-15 13:38:05

+0

woops,我的壞。刪除這部分:) – mathieu 2008-10-15 17:46:50

5

你在你的帖子中描述過什麼(不是你的問題),我認爲首先是銷售,管理和營銷問題。

你說你的客戶沒有技術上的頭腦,這需要有一個有凝聚力的銷售,諮詢和溝通策略,這不是關於編程技能。另外,如果貴公司不斷接受對您的團隊而言過於複雜或昂貴的項目,並且您交付的產品質量低劣,那麼遲早會陷入困境。你會吸引你不想要的客戶,而現有的客戶會因爲你的「無能」而被關閉,並且遲早會找到他們試圖玩同一價格遊戲的另一家公司。在我看來,這些客戶是沒有價值的。

你問'你怎麼贏得價格合理的工作'?人們是社會動物,他們彼此交談。如果市場認爲你是一家不可靠的公司,人們和未來的客戶遲早會知道。客戶不關心你是否以非常低的價格向他們提供產品,時間太緊 - 這不是他們的錯誤,而是你接受它。所以我再次認爲,整個考驗是一種糟糕的商業行爲。

我發現你的確需要在低預算的工作崗位上定義嚴格的規格,定義你將要交付的產品,告訴他們價格,阻止你的老闆提供太多的長期客戶折扣價格標籤,因爲他們也是如此害怕失去客戶。當事情開始失控時,通常會提前進行溝通。撰寫精確報價以獲取更多功能。準確地寫下來,不要依靠電話交談(你:「這是額外的4小時工作」,客戶:「好的」...... 4個月後,客戶「又是什麼?爲什麼我應該這樣做?爲此付出「)。

現在當然,降低價格的一個方法就是不要僱傭完整的白癡,這些白癡最初可能比更好的合格程序員便宜。這是一種目光短淺的方法,並會失敗。

2

「離岸/臥室項目團隊競爭如此激烈」 - 聽起來你們需要花一些時間進入網絡。在一天結束時,人們喜歡與人做生意,而不喜歡與企業打交道。如果您在您的客戶社區中廣爲人知並受到歡迎,那麼您將成爲領先者,您將從自己建立的信心中獲得更好的價格。推薦將給你一個強大的優勢 - 請他們。

「我們公司沒有資金拒絕工作」 - 很多公司都以此爲出發點,但最終你必須通過這種方法你在這些類型的工作上花費的時間阻礙了取得成功。你需要決定你想要做什麼類型的工作(以及誰是客戶),同樣重要的是你不做什麼。

3

這是與您的客戶的關係,將贏得額外的業務。一位開發人員實際上挺身而出,停止了一個項目,因爲他的銷售顧問基本上就我們的解決方案向我們撒謊。然後,開發人員在相同的預算內提供了一個簡單直接的骨骼解決方案,並按時交付。

這傢伙和他的團隊已經在我的公司進行了6年多的諮詢。他的誠信和認真努力的工作性質是一個巨大的優勢,他已經找到了優質的人爲他工作,因爲他的名聲在增長。他的誠實價值比我在海外運輸我公司的知識資產所獲得的任何儲蓄都要多。

0

銷售固定價格,固定範圍的工作,而不是小時工。這可以減輕客戶的超額運行風險(您吸收所有風險,但無論如何您都會這麼做),並且根據軟件的價值來構建項目的框架,而不是進行這項工作的質量。

2

作爲一名顧問,正是因爲這個原因,我個人才轉爲小時率模式。我被太多的合同燒掉了,我感到你的痛苦。

最後,只有以最低價格提出建議的人才會爲您的公司帶來麻煩。雖然你不能這麼挑剔,以至於你從來沒有得到過項目,但你一定要避開那些支持管理層對於實際軟件開發過程不可知的合同,他們只看最初的價格標籤。通常,合同或規範中沒有的內容會改變利潤率和時間表。

無論如何,挑剔的方式而不是降低價格常常會讓您感到最終成爲麻煩的浪潮。在你的情況下,儘管RFP之間總是存在爭議,但它並不像技術要求規範那樣簡潔,但應根據RFP的清晰程度將初始報價理解爲一般估計。

我絕對同意kitsune,如果貴公司一直接受不符合貴公司開發專長或帶寬的合同,那麼所有這些都將導致管理費用和聲譽不佳。

0

我們正在嘗試構建產品並重新使用現有體驗。與烏克蘭(我工作的地方)的英國相比,薪水較低,但仍比印度高4-5倍。

到目前爲止,最好的結果是獲得兩個新客戶,這需要類似的解決方案,因此我們可以提供更好的定價,我們對我們的估算更有信心。

順便說一句,我檢查了whywaitdigital.com,似乎我們有一個產品,您的客戶可能需要。我們做門戶 - 編輯,B2C,地理啓用產品目錄,我們也使用ASP.NET MVC。您可以在我們的網站www.socialtalents.com上找到聯繫信息。

2

這可以看作是上述問題的快速指南。

提案文件

  1. 開始搭配建議文件,說明你的客戶的理解,儘可能地需要。這可以在至少1-2頁的寫作中完成。它可以開始走向需求,但它應該比那更隨意。

預算文件

  • 現在去到Excel,並列出你認爲你將不得不做這個項目的所有任務。以天爲單位放下時間,不得大於2(0.25,0.5等)。

  • 添加測試一列,並使其開發時間的百分比(20%-30%是正常的)

  • 現在添加用於管理的列(項目+帳戶),並添加一段%爲此(在前兩列)。 20-40%是正常的。 (70-30分/ pm)

  • 爲貴公司設置日費率。對於不同的用戶功能,您可以變得更加複雜並且有不同的費率,但是至少設定一個費率,這意味着無論正在執行哪項工作,您都將獲得良好的保證金。

  • 計算迄今爲止記錄的總天數的價值。然後在此基礎上添加應急金額(對於固定價格工作)10-20%在此處是正常的,但可以根據客戶的經驗以及您習慣的更改數量進行更改。

  • 在這一點上,您可以打折總金額,這比降低本文件的其他部分要好,因爲它可以向客戶表明您並非神奇地讓工作變得更快,而是將您的某些東西保證金。因此他們不應該期待你減少項目的時間。

  • **重要 - 在開發成本計算時分析客戶的預算和業務。您將爲大型企業設計的成本計算交給想要以經濟高效地完成應用程序的伴侶是毫無意義的。同樣,請確保您向適用於高端自由職業者費率的組織正確收費。

    想像一個商業分析師。它不僅可以幫助您在看到您的成本時讓客戶滿意,而且可以讓您更深入地瞭解他們的業務。如果他們想通過使用你的錢來賺錢,那麼你很可能會成爲贏家。如果你不能直接詢問他們需要花多少錢,你可以通過詢問他們有多少客戶,他們收費,他們擁有多少僱員等等來解決問題。然後,你應該能夠弄清楚是什麼你提出的將是他們的盈利。**

    1. 回到你的提案文件,並添加一個表的設計,開發,管理等部分...您可以在某些情況下向客戶展示您的成本計算表,但在大多數情況下避免複雜性會更好。它在那裏作爲備用,但你不只是咳嗽了一個數字。

    時間軸文件

  • 採取從預算的設計和開發任務的列表,並把它變成一個新的工作表(或項目,如果你像我這樣的豪華)。在每個部分的開始和結束日期中添加大約30-50%的額外費用。

  • 在Excel中爲天數添加一些圖形表示,或使用Gantt template like this one

  • 返回您的提案文檔並添加計時文檔中的關鍵里程碑。

  • 提案階段完成

  • 發送或呈現提案到您的潛在客戶。希望他們對你提出的建議感到興奮,並樂意進入下一階段,全面收集需求。在隨後的同一客戶的項目中,您可以直接找到需求。
  • 要求階段

  • 列表針對一個單獨的ID每個需求,無論是1,2,4,5或1.1,1.2,1.3。這並不重要,但第二個可以幫助大型列表。

  • 有一些測試的要求,你可以嘗試遵循這些,但有時他們不適用(一些要求可能是設計主導例如)。其中一些是:需求是否可測試,是否單一,是否清楚?我會盡力找到某個地方的鏈接。