在公司，承擔了一個項目的開發，由於開發周期短，本人繞過了異常處理，先實現了基本功能的主邏輯。

但是矛盾是：我實現了的主邏輯被認為是沒有意義的，這是個簡單活，並將我的項目由別人接手，接下來就是全盤否認，並且否認我的開發能力。站在軟體上司的角度看我沒有做任何事情，有偷懶之嫌。但是站在我的角度我確實是在努力的開發並且實現了主邏輯。

問題是：求分析其中的原由？我該何去何從？

針對 「可不可以先實現主要功能再考慮異常」，回答是：不可以。

不僅僅是異常處理問題，事實上所有開發工作，如果不能事先考慮清楚，在做的過程中修修改改，最終交付的產品質量就會有不同程度的問題。

很多程序員會這麼想，先把應用功能做出來，然後再改進、再優化，而實際上，絕大多數程序員只要能把功能應付做出來，就再也不想回去看那個 ugly 作品，並且自我安慰下個產品再做得更好，其實永遠都不會有下一次... 每一次都養成更壞的習慣。

一個好的程序員、工程師，最可貴的還是能夠一次把程序寫好的能力，寫之前理解業務流程非常重要，這也是很多項目中架構師的作用。

根據題主的描述，整個事件是：

1、題主做了個產品，

2、項目被否定了，

3、題主接著也被否定了。

這個事件，也有兩種可能性：

A：因為項目被否定，所以題主也被否定了。

B：因為題主被否定，所以題主做的任何事都被「雞蛋裡挑骨頭」給否定了。

這兩個可能性中，如果是B，背後的事情就太複雜了，題目的信息又不足，所以無法分析。

所以只能分析下A的這種可能性。

A這個可能性中，最關鍵的問題在於「主邏輯被認為是沒有意義的」。

出現了這個問題的原因，又是做產品或做項目，最常見的一個錯誤，就是「缺乏共識」。

我們不是喬布斯、不是張小龍，每個人頭上都有領導，有服務的用戶，橫向都有合作的同事、競爭的同事，還有下屬團隊成員。在做一個產品或項目之前，至少要跟領導、用戶、合作的同事和團隊成員達成共識。

什麼的共識？可以是一款產品的Product Vision，可以是一個項目要實現的功能點，但我最推薦的方法是：用數字說話，跟大家共識產品或項目的量化價值。

量化價值可以是如下之一或多個，包括但不限於：流量增加、轉化率提升、成本降低、效率提升、性能提升、穩定性提升……

這些量化價值的計算公式也必須跟大家共識。比如轉化率，是哪個值除以哪個值？值的數據來源是哪個庫的哪個表？比如成本，是怎麼計算的？等等……

如果你在做產品或項目之前，跟領導、用戶、同事、團隊達成了共識，那麼「主邏輯有沒有意義」，拿數字說話就行了。至於主邏輯、還是異常什麼的，是否影響價值交付？影響的，按照影響大小排個優先順序就行了。不影響價值的功能，who cares!

謝邀。

從你的角度出發，我覺得你的做法沒有問題。但是從產品，從公司的角度出發，在你做這種決定之前，要把責任內的事做好，具體如下：

1.評估需求開發工時時，要確保自己理解完整的需求，並且根據功能點一一做了工時評估

2.按照步驟一，做完評估後，跟產品經理或需求方溝通

3.如果步驟一二都做好了，但還是超出了規定的時間，這時候，應該跟產品經理商量，這次需求的重要緊急程度，以及整個需求對產品或者公司來說，意義有多大，如果意義很大那麼自己能否自覺加班完成，如果加班都完成不了，那麼要及時跟產品經理明確表示，自己願意加班趕需求，但這次時間真的不夠，我最多可以做完1-2-3……，你看可不可以？

總結：

1.做好自己該做的

2.遇到問題要主動溝通

3.學會換位思考

以上，是個人的一些經驗，希望對你有所幫助，加油。

有個度，這個度很難說，因為產品的機會么轉瞬即逝的，把握好

你的問題是，在一般情況下，異常處理是必須的。你認為開發周期短需要繞開異常處理，是你自己的想法，沒有跟主管溝通並獲得認可，這在那個上級看來都是不可以接受的，因為項目總的進度和質量負責不在你這裡

其實客戶追求短期實現，最大的原因是沒底和不了解。

首先的一個例子，你中午去食堂吃飯，點了一盤水餃，作為客戶你當然希望我點了之後就做好。

但是製作一盤水餃需要經過準備餃子餡，和面，包餃子之後煮的步驟。

而客戶作為外行根本不了解這些步驟，理所當然的認為這事很簡單。

所以你要做的就是列舉出來實現這些需要的步驟，然後每個步驟做出你自己的時間評估，並付上理由。

讓客戶認識到實現這些需要這些步驟，需要這些時間，而不是隨著客戶的要求來。

我經常舉例的一個例子，在醫院你作為一場手術的主刀醫生，必須做到比任何人都要冷靜，因為你一旦慌張就會出現操作錯誤和判斷錯誤，導致一個病人出現問題。

還有一個職業就是宇航員，宇航員要在任何時候都要保持清醒和冷靜，因為在遙遠的太空沒人會幫你，地球上的專家遠水解不了近渴。

所以說在開發項目上誰都可以著急，你不能著急，因此在需求分析階段，我不明白的問題就是要問清楚，我不管你對方公司工期如何緊張，那是你的事情，我要冷靜分析你的一切需求不分析明白不開工。

同時也要事前提醒他的需求，就是說把後果講在事前，比如手術之前主刀醫生都會事情告知患者家屬手術的風險與後果，需求分析階段就向客戶挑明，你的某種需求會導致什麼樣的後果，比如你不傳或省略某些數據就會導致我的程序沒法判斷，事前就講明，這樣做的後果，把風險推給客戶，讓客戶或領導去考慮，要這麼做可以，到時候程序出現某些問題後果自負。

謝邀。

研發的排期是自主制定的嗎？

產品和項目在哪？

如果這個工作是無意義的，產品需求評審的時候日狗了么？

減少接盤俠的認知負擔才是程序員的核心技能。面向人類編程了解一下

謝邀。

LZ可以先了解一下MVP的方式，各種文章和書里都有提到。

產品的MVP可以體現PM對需求的認知和把控。

因為不了解你的實際項目，只有一個建議：產品的異常流程/處理髮生的可能性會有多大？如果沒有提供異常的處理機制，會對產品或使用者帶來多大影響/損失。

至於主邏輯有沒有意義，或者是不是你偷懶了，很可能是溝通中的誤解。也可能確實你對產品的理解不到位，你可以反思一下。

你可以把你自己的想法說出來給pm和經理聽

至於模塊的優先順序都是pm定的

有責任心是必須的，因為你要證明你自己，但是你要知道，這種前後都是坑的事情不能你一個人承擔，你糾結模塊優先順序，不妨讓pm定下一步怎麼做。

推薦閱讀：
相关文章