之前一直在做ios開發工程師，現在有機會作為乙個類似軟體經理的位置（職稱仍然是ios工程師，但是實質上我不做開發的）來對專案進行把控，感覺很奇妙。
我所在的公司是甲方，請了一些外包公司來做軟體開發，我會核查他們的**和進度，並提出一些意見。總而言之要盡我所能保證ios應用（以及其他部分）的質量和進度。
實質上3個月前，我還在作為工程師開發專案。基於一些同理心，我不願對現有的外包工程師苛責，但是專案是比較複雜的，我有機會反思之前自己開發中的不足。順便說一句，我一直以為我做開發的時候專案管控是很糟糕的，可是現在的外包公司比我之前還要糟糕。我之前的公司專案出現問題是由於專案過多，而且開發流程不夠規範；但是現在外包的公司人手足夠（5個人乙個專案），時間相對充裕，從來不用加班，可是問題也很多。
先說好話：這些開發人員的**質量還是都不錯的，我認為至少都開發一年半以上了。但是對專案質量的理解太差了，很多時候僅僅是完成功能而已。我們**給使用者的是產品，而不是乙個測試過的，剛剛能夠使用的軟體。這個涉及到測試員對滿意度的認識了，我認為是不夠的。
再就是專案的結構存在不合理的地方，新的工程和老的工程重在一起，慘不忍睹。但是我來的時候這個專案已經上架了，呵呵噠！還有一些老的模組，據他們老大說沒人敢動，怕出問題。功能劃分的不夠清晰，我看過幾次**找個檔案都有麻煩。長期做專案的人，都有自己的乙個比較成熟的框架，它可能不是最優秀的，但是是保證可以快速熟練完成專案而且容易被理解的，這一點他們做的不夠。
即使這些框架不夠清晰，我認為通過文件也是可以彌補的。但是來到公司之後竟然沒有看到任何與專案相關的文件，只有一些舊的郵件，反正這些郵件我暫時也沒看到。需求分析，概念定義，框架梳理，軟體專案說明，版本更新說明，什麼都沒有。。。。。。不是說外包都是快速開發的嗎？我以為文件完善才會比較快。加個功能倒是蠻快的，可是做出來後親你們都不自己先測試嗎？10次成功1，2次敢拿去給客戶用嗎？連個單元測試都沒做過，靠！
作為甲方我也只能提提意見了，沒辦法直接插手專案。不管怎麼樣，以後自己做專案這些情況自己一定要避免，即使時間緊迫也要做好點。要是專案太趕要求只保留寫**的時間（這樣的領導遇見不止乙個），也只能who can who up了。
對軟體開發模型的學習與思考
對軟體開發模型的學習與思考 軟體開發模型，是對於軟體開發全部過程 活動及任務的框架。包括需求 設計 編碼 測試等階段，明確了需要完成的任務。即以交付更為完美的軟體為目標，結合具體情況，所規劃的一套整體解決方案和實現方式。早在1970年提出的瀑布模型，曾是唯一被廣泛採用的軟體開發模型，然而在80年代早...
軟體開發平台設計思考
乙個軟體公司要想提高公司的軟體開發效率，一定會有自己的軟體開發平台。今天就和大家分享下乙個軟體平台的設計思考。在設計軟體開發平台過程中，為了少走彎路，我們要盡量多往外看一看，吸取一下別人成功的經驗，結合自己的實際情況進行設計。在我檢視了不少的業界軟體開發平台，我把它們分為三類。下面介紹如下三類 第一...
關於軟體開發工作的思考
關於軟體開發工作的思考 挨踢界小人物 工作中時常遇到這樣一種情況，在做網頁的時候，我會秉承使用者體驗的原則，視自己為使用者的心態，去設計和改造介面，但並非老闆喜歡，老闆要的只是系統穩定，不要搞出事情，所有多數情況我的改造優化都不能上線成為正式產品，然後會指揮你怎麼做，怎麼做！而你會怎麼抉擇。在這種情...