chinesefreesexvideos高潮,欧美极品少妇性运交,久久久国产一区二区三区,99久久婷婷国产综合精品,成人国产一区二区三区

　　B端產(chǎn)品工作不易，尤其是沒有相關經(jīng)驗的新人，難免會踩坑。為了不在同一個坑摔倒兩次，就需要及時復盤思考，針對問題給出解決方案。本文作者總結(jié)了自己在B端工作中的項目經(jīng)驗，與你分享。

　　可能有些朋友不了解B端產(chǎn)品交付方式，我先給大家講下目前主流的兩種交付方式，B端產(chǎn)品提供給客戶使用，目前主要有兩種方式。

　　一種是最近幾年非常火熱的SaaS模式，它是基于云的應用，可以授權給企業(yè)、組織或者個人進行使用，通過公共網(wǎng)絡訪問使用。

　　另一種是較為傳統(tǒng)的本地化部署模式，也就是把應用產(chǎn)品部署在客戶的服務器，產(chǎn)品必須通過客戶專屬網(wǎng)絡才能訪問，確保應用以及數(shù)據(jù)的安全性。對于安全性要求比較高的企業(yè)，比如銀行和政府等企業(yè)的核心系統(tǒng)基本會選擇這種交付方式。

　　目前我在做的現(xiàn)場實施項目就是屬于第二種，需要把本身具備一定成熟度的產(chǎn)品在客戶現(xiàn)場的服務器進行部署，按照客戶的規(guī)章流程進行辦事，在產(chǎn)品本身的基礎上再迭代客戶定制化的需求，最終按照合同簽訂的項目功能范圍進行項目驗收結(jié)束。

　　從2021年3月底開始，我全程參與了我們公司活動營銷平臺項目的實施，如今項目一期實施已經(jīng)完成驗收，項目二期的合同已經(jīng)簽訂并開始。

　　在這一年多的項目經(jīng)歷中，我踩了不少坑，踩坑的過程中難免痛苦，但回頭想想也正是因為踩過坑的痛苦激勵我進行反思，才加速了我個人能力的成長。

　　如果你問我踩過的坑里面，哪些是我最難忘的？我會和你說是需求范圍蔓延、輕易承諾被打臉以及生產(chǎn)問題處理手忙腳亂。

　　下文中我會逐個進行分析，我相信這三點不僅是在現(xiàn)場實施過程中會遇到，在做B端產(chǎn)品很多朋友也有可能遇到。如果你也遇到了類似的情況，希望能給你幫助。

　　可能有些朋友對于需求范圍控制有點不理解，簡單來說就是客戶需求超出簽訂合同的約定范圍，這種情況出現(xiàn)很有可能會造成項目利潤減少甚至虧損。

　　針對項目制的產(chǎn)品交付，在雙方達成合作意向后，會在簽訂的合同內(nèi)明確需要交付的需求功能點清單以及系統(tǒng)要求等內(nèi)容?？梢哉f把合同內(nèi)的功能點上線完成達到合同要求后，項目就可以進入交付驗收階段，驗收通過后客戶就會把合同尾款付給公司，那么項目也就做完了。

　　所以從負責項目實施的乙方公司而言，自然是想辦法在合理的人力成本范圍內(nèi)，盡快完成需求功能點的上線，確保項目利潤可觀。

　　但是風險點在于在簽訂合同的時候需求大多只有幾句話的描述，需要等到真正實施過程確認需求后，才能知道實現(xiàn)方式以及實際工作量。

　　需求是由客戶方提出及確定的，受外部環(huán)境變化影響。

　　客戶的需求并不會跟隨合同一成不變，而是會在合同需求的基礎上進行調(diào)整甚至變更，這本身是無可避免的，但是對于項目來說就會帶來不可控因素，如果把控不好就會導致項目虧損。

　　說實話，項目成本以及項目實施周期這類問題大多是公司領導或者項目經(jīng)理需要承擔的事情，但是產(chǎn)品經(jīng)理作為需求的具象化以及項目的關鍵角色，其實是需求范圍把控的關鍵人員，我們需要關注這件事情并通過自己的方法把控需求范圍，才能和領導以及項目經(jīng)理進行順暢溝通，也有助于自己未來的職業(yè)發(fā)展。

　　需求范圍蔓延這種情況其實并非不可預見，往往在雙方合同簽訂時，會協(xié)商預留一部分預算用于開發(fā)合同外的需求。

　　既然需求蔓延不可避免，那么產(chǎn)品經(jīng)理作為把控項目實施范圍的關鍵角色，可以做些什么呢？

　　可能大家會覺得控制需求范圍是項目經(jīng)理在開發(fā)階段需要負責的事情，其實并不是的，從成本角度來控制需求范圍必然會存在一定滯后性，而這種滯后性會增加項目的成本。

　　當需求確定后，往往客戶對功能已經(jīng)產(chǎn)生一定的預期，如果發(fā)現(xiàn)預期工作量超標再讓客戶調(diào)整需求，勢必會讓客戶感覺不爽，甚至可能會口頭說我們不專業(yè)。更不用說，實際工作量遠超預期工作量的情況。

　　實際上應該由產(chǎn)品經(jīng)理從需求調(diào)研時就開始控制，其次才是開發(fā)環(huán)節(jié)控制。

　　需求調(diào)研前，產(chǎn)品經(jīng)理需要熟悉合同需求范圍，如果知道需求大致工作量更好。只有我們自己了解合同的需求范圍才便于進行把控，如果能參與項目合同范圍擬定當然最好，如果是后期介入則需要熟讀項目合同。

　　熟悉后便于我們在需求調(diào)研的過程中能對客戶提出的需求進行識別，到底是合同內(nèi)還是合同外，合同外的需求需要識別，與項目經(jīng)理進行信息同步。

　　需求調(diào)研時，可以適當發(fā)散，但要具備可落地性。適當發(fā)散的關鍵在于不能過于限制客戶提出需求內(nèi)容，不能在最開始聊需求的時候就開始想著能不能實現(xiàn)，不能實現(xiàn)或者有難度的都建議客戶調(diào)整需求，調(diào)研目的在于需要客戶多提供些信息以便于我們挖掘需求真正的目的，而不是實現(xiàn)方式。

　　知道需求背后的目的后，便于我們針對目的提出我們的解決方案，而不是被業(yè)務牽著走。

　　具備可落地性是需要我們把控整體情況，不能任由客戶漫無邊際地提出實現(xiàn)方案，在進行具體需求設計的時候需要在具備可落地性的基礎上進行討論和細化需求。

　　在一次溝通需求的過程中，客戶提出想要實現(xiàn)活動在小程序及手機App用戶都能參與的需求，我當時評估需求實現(xiàn)難度較大，提出能不能只在手機端實現(xiàn)。

　　客戶聽后就不滿意了，說為什么不能實現(xiàn)？目前已有的活動模板是在小程序進行的，而我們目前活動都支持在手機App參與，如果放棄小程序很多客戶參與都不方便，那么活動的參與人數(shù)肯定會受到影響。

　　在我了解到客戶的目的后，冷靜想了下雖然實現(xiàn)有難度，但是并不是一定不能實現(xiàn)，客戶的訴求并不過分，于是我便回復我明白了，我們繼續(xù)溝通其他需求，具體實現(xiàn)在開發(fā)階段進行評估。

　　需求調(diào)研后，發(fā)現(xiàn)開發(fā)難點及時溝通確認調(diào)整，給出理由及備用方案。前面提到了成本角度的滯后性，但是如果在開發(fā)過程中發(fā)現(xiàn)了問題需要調(diào)整實現(xiàn)方案。要敢于和客戶進行溝通確認，很多時候客戶雖然不爽，但是我們講清楚原因和備用方案后大多都會理解同意調(diào)整。

　　在和客戶溝通的時候，需要注意溝通方式。我總結(jié)的溝通框架是：目前遇到問題描述+問題導致的影響分析+調(diào)整方案描述+調(diào)整前后方案對比效果。

　　比如我最近做的一個需求，需求方案確定后需要調(diào)整方案。于是我找到客戶說明，在開發(fā)過程中發(fā)現(xiàn)活動發(fā)布后編輯事件規(guī)則會導致數(shù)據(jù)錯亂，這是需求設計過程中未考慮到的。

　　如果按照目前的方案上線后，可以預見會有很多客戶的記錄可能會丟失導致客訴。和開發(fā)人員討論后的建議方案是限制運營人員在活動發(fā)布后修改事件規(guī)則，沒有其他可行方案了。

　　這樣調(diào)整雖然會導致活動發(fā)布后無法變更事件規(guī)則帶來操作不便，但可以通過人工確認的方式規(guī)避問題出現(xiàn)，而且能夠保證客戶的數(shù)據(jù)不丟失，從而避免客訴。

　　客戶聽了我的描述后理解了出現(xiàn)的問題、解決方案以及影響面，同意進行需求調(diào)整。

　　如果要說在項目過程中踩過最慘痛的坑，那肯定是輕易承諾上線時間。

　　在和客戶溝通完需求后，客戶往往會追問一句，這個需求什么時候能夠上線？當時缺乏”社會毒打”的我往往會根據(jù)自己對項目的了解情況，腦袋一拍給個上線時間。我想的是給個大概的時間，朝著這個目標去努力。后面我發(fā)現(xiàn)客戶并不會這么認為，他會把我提供的時間當成確定的時間，甚至會上報給他的領導。

　　這種情況下我給的時間節(jié)點會成為上線的倒排時間，弄得自己和同事身心疲憊，這種情況下如果遇到難解決的生產(chǎn)問題就會打亂節(jié)奏，從而影響上線時間節(jié)點，整個項目的計劃都會被打亂。

　　如果沒有按時上線約定功能，客戶會找到我們要個說法，為什么承諾時間做不到？這會給到項目組壓力，催促我們盡快完成功能上線，于是項目成員往往需要加班加點完成工作，而往往這個時候更容易出現(xiàn)問題。

　　最后可以發(fā)現(xiàn)，因為我拍腦袋給出客戶的上線時間，不僅讓項目組上線壓力增加，而且還讓客戶面臨領導的苛責，會造成我本人信用度的降低，甚至影響后續(xù)項目的工作開展。

　　為什么客戶會找我這個產(chǎn)品經(jīng)理提供上線時間呢？

　　我想了下，首先是因為產(chǎn)品經(jīng)理和客戶的溝通頻繁，客戶對于產(chǎn)品經(jīng)理的熟悉程度和信任程度較高。其次是客戶需要了解功能上線情況做好工作安排，最后客戶是想要一個保證，保證需求上線的時間節(jié)點和自己的預期一致，實際情況是我們沒辦法保證，因為具體上線時間由客戶方項目經(jīng)理確定。我在當時提供上線時間一方面是想滿足客戶的預期，另一方面是想證明項目組的能力，只是當時沒想到會搬起石頭砸自己的腳。

　　記得今年5月份有次項目晨會，之前我評估是5月底能上線的。因為時間評估有偏差，導致該功能要延期在6月的版本上線。于是客戶就不滿意了，說每次你們評估的工作量都不準確，我都通知客戶在端午節(jié)進行領取了，結(jié)果你們說功能上線不了，這個責任我沒辦法承擔，你們也承擔不了。這個情況我不滿意，你們最近加班趕下進度，務必要在5月底上線。

　　整個項目組經(jīng)過持續(xù)一周的加班才趕上進度，雖然按期上線了，但是同事們那段時間都很疲憊，也影響了后續(xù)功能的開發(fā)效率。

　　經(jīng)歷過幾次慘痛的教訓后，我下決心改掉輕易承諾的毛病，想辦法提高自己的專業(yè)性，經(jīng)過一段時間的摸索后，我找到了自己的應對方法。

　　現(xiàn)在當客戶問我需求上線時間的時候，我會按照以下三個步驟進行處理：

　　先反問客戶的預期時間是什么時候，以及為什么是這個時間節(jié)點。如果是個人意愿的原因可以嘗試進行說服，如果是外部不可變條件限制那就需要及時和項目經(jīng)理同步信息，提前進行風險管理。根據(jù)目前項目的計劃告知預期的可實現(xiàn)性，如果存在風險我會和客戶說明風險點，先降低客戶預期，讓客戶提前做好風險預案，避免后續(xù)因為未按預期上線導致的手忙腳亂。如果具備可能性，我會和客戶說，目前看具備可行性，具體需要和開發(fā)同事確認需求后進行工作量評估再給出答復?？蛻羧绻僮穯枙r間，我會說明即使我現(xiàn)在給出上線時間，也是我拍腦袋給出來的肯定不準確，而且還有可能會打亂項目計劃。具體時間等我們明確需求后再評估相對可行的時間。聽起來可能會感覺有些圓滑，但是這確實是我踩過坑后總結(jié)和使用的方法，也確實有效。不輕易承諾并不是學會圓滑，而是在降低客戶對于上線時間節(jié)點的預期，保持項目組的信用度，便于雙方長期合作。

　　有次在溝通活動模板的需求過程中，在溝通完具體需求后，業(yè)務又來問我大概的上線時間。

　　我回復說你的預期是什么，是要配合某個大型活動嗎?

　　客戶說是的， 最好是在10月份上線，我希望在國慶節(jié)用這個新的活動模板上線新的活動，這樣既能滿足節(jié)假日上線活動的目的，也能給客戶帶去新的玩法。

　　我回復，那我明白了。目前項目有兩個需求推進中，如果按照目前開發(fā)進度10月份上線會存在風險，是否有其他備用方案呢？比如用現(xiàn)在的活動模板舉行活動。

　　客戶說沒有備用方案，這也是領導要求的時間點。那按照目前的開發(fā)進度，你估計什么時候能夠上線?

　　我說，這個時間我這邊目前給不出來，你的訴求我基本了解。我整理下最近準備開發(fā)的需求，我們估計要調(diào)整下需求優(yōu)先級，確定需求優(yōu)先級后我和開發(fā)同事一起評估開發(fā)計劃后，在本周三下午給你反饋具體時間。

　　這時候客戶理解的具體情況，大多會接納我的意見，后續(xù)只要我們按照約定的時間給出開發(fā)計劃即可，有開發(fā)計劃后便于進行具體的溝通。

　　生產(chǎn)問題處理無疑是我最頭疼的問題。

　　因為生產(chǎn)問題它不可控，它出現(xiàn)的時候往往沒有跡象，而且需要盡快解決，但是想要解決需要項目組成員花費時間和精力，遇到難解決的問題耗時較多無疑會影響項目后續(xù)的開發(fā)計劃，影響項目整體進度。

　　經(jīng)過這一年多在客戶現(xiàn)場與生產(chǎn)問題的“交手”，我發(fā)現(xiàn)解決問題的最重要的并不是馬上響應，而是對生產(chǎn)問題保持平常心，保持平常心的意思是對于生產(chǎn)問題的出現(xiàn)無需感到意外，更沒必要因為生產(chǎn)問題手忙腳亂，內(nèi)心急躁，只有對生產(chǎn)問題保持敬畏心和平常心我們才能冷靜地分析問題，盡快查找問題出現(xiàn)原因并解決問題。

　　按照我個人的經(jīng)驗，我會把生產(chǎn)問題歸為三類，分別是人為問題、設計問題以及系統(tǒng)問題。

　　第一類是人為問題，就是由操作人員錯誤的操作行為導致的。常見的原因是操作人員對于系統(tǒng)不熟悉或者操作過程不細心。如果分析問題后發(fā)現(xiàn)是人為問題，首先需要想辦法修復數(shù)據(jù)，恢復系統(tǒng)正常。然后分析問題出現(xiàn)的操作過程，對操作人員進行培訓或者建立操作檢查規(guī)范，甚至可以增加審核流程用來規(guī)避人為的導致的問題。

　　第二類是設計問題，就是在需求設計或者開發(fā)設計的過程中影響考慮不充分，導致系統(tǒng)出現(xiàn)問題。這種情況常見的出現(xiàn)節(jié)點是上線后出現(xiàn)問題，這時候可以通過回退舊版本暫時解決問題，然后再針對出現(xiàn)問題的部分進行優(yōu)化迭代。如果是上線一段時間后，因為功能設計不完善導致問題出現(xiàn)，短時間內(nèi)就需要在開發(fā)層面先定位和解決問題，然后盡快優(yōu)化需求或開發(fā)設計方案，安排版本更新解決問題。出現(xiàn)這種問題，就需要想辦法在需求設計或開發(fā)設計階段規(guī)范流程，增加設計方案考慮場景，提升項目成員專業(yè)程度從而避免問題出現(xiàn)。

　　第三類是系統(tǒng)問題，就是系統(tǒng)本身出現(xiàn)的問題。比如服務器壓力較大或者數(shù)據(jù)庫出現(xiàn)問題，那就大多需要從系統(tǒng)或硬件層面去定位和解決問題，通過增加服務器或擴充數(shù)據(jù)庫容量解決問題，或者通過優(yōu)化代碼性能解決問題。這種問題大多是開發(fā)同事需要考慮優(yōu)化的，作為產(chǎn)品經(jīng)理需要了解問題出現(xiàn)以及解決情況，在后續(xù)做類似需求過程中進行考慮。

　　講完分類后，和大家講下我排查問題的思路。

　　當出現(xiàn)生產(chǎn)問題后，首先是對問題情況進行描述，了解大致情況。然后是和操作人員（或客戶）確認操作流程，確認操作流程無誤后，開發(fā)同事查詢具體操作時的系統(tǒng)日志定位問題。大多數(shù)情況就能定位到問題出現(xiàn)的原因，如果查詢不到日志情況那么定位問題以及解決問題花費的時間就會增加。

　　定位到問題后，首先可在測試環(huán)境嘗試是否能復現(xiàn)，如果能夠復現(xiàn)那么大多是代碼問題，如果不能復現(xiàn)那么很可能是不同環(huán)境帶來的問題，具體情況就需要排查。

　　其次是評估問題的影響面，有多少數(shù)據(jù)或者客戶受到了影響，影響的結(jié)果是這樣，會造成多少損失。

　　最后是項目組成員討論給出問題解決方案，解決方案最好能在測試環(huán)境進行驗證，驗證無誤后再安排版本上線。

　　如果是因為生產(chǎn)問題造成客戶損失，需要進行道歉并做出相應的解釋，如果損失較大還需要給出客戶的補償方案。

　　在問題解決后最好還與問題相關同事召開問題復盤會議，回顧問題出現(xiàn)的原因、問題排查和解決過程，降低后續(xù)相同問題出現(xiàn)的可能性，提升問題的處理效率。

　　出現(xiàn)問題并不可怕，怕的是手忙腳亂導致更大的問題。我們可以告訴自己，出現(xiàn)問題解決問題就好。當然每個產(chǎn)品情況不同，我提供的流程只能作為參考，推薦你按照自己產(chǎn)品的實際情況，制定解決問題的流程。

　　做B端產(chǎn)品并不是件輕松的事，沒有相關經(jīng)歷的我們難免踩坑，但最好我們要爭取相同的坑不踩兩次。這就需要我們在踩坑后及時復盤思考，思考問題出現(xiàn)原因，并針對問題制定解決方案，想辦法降低下次踩坑的概率。

　　想要控制好項目的需求范圍，需要我們深度參與到項目實施的過程中，不讓自己被產(chǎn)品經(jīng)理的角色限制，把項目保質(zhì)保量地交付作為我們的目標。

　　不輕易承諾不只是對自己負責，也是對客戶負責，更是對公司負責。承擔責任并不輕松，但是只有承擔更多的責任后，后我們才能有更多的成長機會。

　　其實生產(chǎn)問題并不可怕，因為它一定會出現(xiàn)。保持平常心能讓我們更好地定位問題以及解決問題。

　　最后我想和你說，文中說的這三點并不只是在交付項目過程中會遇到，在做其他B端產(chǎn)品的時候也會遇到，希望文章中的方法能給你一些幫助，內(nèi)容較多，感謝你閱讀完。

　　本文由 @樹園聊B端 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

　　題圖來自 Unsplash，基于CC0協(xié)議。

　　該文觀點僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務。

　　在搭建組件庫時，組件設計師和其他設計師之間，應該怎么配合呢？組件設計的工作模式又是怎么樣的？本文作者從獨立生產(chǎn)、集中生產(chǎn)、聯(lián)合生產(chǎn)這三個方面，對搭建組件庫的模式進行了分析，希望能給你帶來幫助。

　　一位同學和我說她最近也在嘗試搭建自己產(chǎn)品的業(yè)務組件庫，但是有一個困惑：

　　“搭建組件庫并不是一個簡單的工作，甚至可以說是很繁重，那么是不是我應給專職只做設計組件庫這一件事情呢？但我現(xiàn)在還需要做產(chǎn)品需求，感覺時間已經(jīng)很緊張了。

　　我想知道，組件設計師和其他設計師之間應該怎么配合呢？組件設計的工作模式應該是怎么樣的呢？”

　　搭建組件庫的工作模式有很多種，我在本文會為你介紹三種模式：獨立生產(chǎn)、集中生產(chǎn)、聯(lián)合生產(chǎn)，相信也會對你有幫助。

　　“獨立生產(chǎn)”是指對于一個團隊來說，安排某位業(yè)務設計師作為唯一的組件生產(chǎn)者；或者對于一個企業(yè)來說，安排某個業(yè)務設計團隊作為唯一的組件設計團隊。

　　這種模式下，這位業(yè)務兼組件設計師做出來的組件既在自己做業(yè)務需求設計時使用，也服務于其他的業(yè)務設計師或團隊。而其他的業(yè)務設計師或團隊則會提供組件設計需求給這位業(yè)務兼組件設計師，進行組件庫的更新和優(yōu)化。下圖以一個團隊的獨立生產(chǎn)模式為例：

　　這種協(xié)作模式看上去可行，但也有一些弊端：

　　由于是這位設計師根據(jù)自己的業(yè)務需求來做組件，做出來的組件資產(chǎn)可能適應不了其他設計師的業(yè)務需求。他人在使用的時候，可能會需要大量的修改和定制，或是提出組件優(yōu)化和調(diào)整的訴求。

　　由于這位組件設計師也需要做業(yè)務設計，所以必然沒有辦法分出太多的精力去研究和細化組件的細節(jié)；也不太可能去編寫完整的規(guī)范約束組件的使用方式；甚至是接到其他業(yè)務設計師提出的組件新增和優(yōu)化的需求也未必會全部受理。

　　工作任務：

　　“獨立生產(chǎn)”的模式比較適合相對成熟和穩(wěn)定的業(yè)務組件庫，沒有太多組件需要從 0-1 進行新增設計，各業(yè)務線及設計師也已經(jīng)對組件有了較高認可并能夠熟練應用。這種協(xié)作模式對于這位業(yè)務兼組件設計師的能力要求比較高，對組件庫需要兼顧設計與管理。其工作職責包括：

　　負責組件需求的收集、評估和排期組件需求的定義、分析與研究組件設計成果和使用規(guī)則的產(chǎn)出組件在開發(fā)上線后的質(zhì)量驗收組件和規(guī)則的評審、發(fā)布與信息同步等

　　“集中生產(chǎn)”是指對于一個團隊來說，安排專職設計師作為唯一的組件生產(chǎn)者；或者對于一個企業(yè)來說，安排某個專職設計團隊作為唯一的組件生產(chǎn)團隊。這位專職設計師或?qū)Ｂ氃O計團隊不依附于任意的一條業(yè)務線，不承接業(yè)務需求。下圖以一個團隊的集中生產(chǎn)模式為例：

　　這種協(xié)作模式的好處是：

　　1）組件專業(yè)度高

　　由于設計師是專職做組件，組件的生產(chǎn)質(zhì)量和設計深度就得以提升。不論是在組件設計的質(zhì)量還是在使用組件的流程上，都可以做得更好。

　　2）組件通用性高

　　由于不參與任何業(yè)務需求，組件設計師可以更加平等地審視各個業(yè)務的組件沉淀和優(yōu)化需求，一般不會偏重某個業(yè)務，而是站在通用性的角度做組件生產(chǎn)。

　　但這種協(xié)作模式也有弊端：組件業(yè)務性弱。

　　由于不接觸業(yè)務需求，專職的組件設計師做出來的組件可能并不“務實”，過于理想化。組件在實際業(yè)務應用中可能會“不接地氣”，沒有那么貼合業(yè)務需求，或者在解決實際業(yè)務過程中仍然考慮得不夠周全。

　　工作任務：

　　“集中生產(chǎn)”的模式比較適合從 0-1 剛剛搭建的組件庫，或者是業(yè)務屬性不強的通用基礎組件庫。專職的組件設計師的工作職責不僅僅包括以上我們提到的幾點工作內(nèi)容，還包括：

　　對于組件庫做建設管理和發(fā)展規(guī)劃主動提升組件自身的設計質(zhì)量主動思考如何從組件側(cè)如何賦能業(yè)務，提升產(chǎn)品易用性和使用體驗主動提升組件的使用體驗，以體驗度量和檢測等方式確保組件被高效、正確地使用

　　“聯(lián)合生產(chǎn)”是指對于一個團隊來說，安排幾位業(yè)務設計師同時承擔一部分組件生產(chǎn)的工作；或者對于一個企業(yè)來說，其中的幾個業(yè)務設計團隊都需要派出 1-2 名業(yè)務設計師組成一個組件生產(chǎn)團隊，大家一起建設組件庫。

　　這也需要找一名有組件庫建設及管理經(jīng)驗的設計師作為負責人，來統(tǒng)一協(xié)調(diào)和安排組件的設計工作。下圖以一個團隊的聯(lián)合生產(chǎn)模式為例：

　　這種協(xié)作模式的好處是：組件專業(yè)度、通用性、業(yè)務性得以提升。

　　業(yè)務性：組件庫可以和業(yè)務進行深度綁定，設計沉淀來源于實踐并賦能于實踐。專業(yè)性：每位業(yè)務設計師或每個業(yè)務團隊可以均分組件設計的工作量，組件的設計質(zhì)量和研究深度可以得到一定的保證。通用性：增強各業(yè)務設計師和團隊之間的聯(lián)系，大家協(xié)同配合，也可以避免組件設計偏重某個業(yè)務。但這種協(xié)作模式也有問題：需要建立清晰的協(xié)同機制。

　　這種協(xié)作方式涉及到的相關人員數(shù)量更多，因此需要更強的統(tǒng)一協(xié)調(diào)和管理機制，也需要有一位能夠?qū)Υ素撠煹脑O計師進行全局協(xié)調(diào)和統(tǒng)籌。

　　工作任務：

　　“聯(lián)合生產(chǎn)”的模式較為通用，可以適用于不同階段的組件庫建設工作。這對于組件庫負責人的能力要求比較高，需要根據(jù)實際情況，兼顧我們上文提到的所有工作內(nèi)容；尤其是在管理和協(xié)調(diào)組件工作進展上需要有一定的經(jīng)驗。

　　在我所經(jīng)歷過的團隊中，目前還沒有遇到過專職的組件設計師。因為對于業(yè)務組件庫來說，組件作為一種為業(yè)務提效的工具，是不可能脫離業(yè)務單獨存在的。業(yè)務設計師通常既是業(yè)務組件的設計者和管理者，也是使用者。

　　還有一些經(jīng)驗和建議分享給你：

　　1）組件協(xié)作模式?jīng)]有絕對的對錯，主要看是否適合你的業(yè)務和團隊特征。

　　你可以根據(jù)自己的能力、團隊的實際協(xié)作情況和業(yè)務屬性，選擇一套適合的協(xié)作方式，也可以創(chuàng)造出新模式。如果你是執(zhí)行者，也可以先給出一套協(xié)作方案，找領導商量如何將方案落實。

　　2）組件協(xié)作模式不是一成不變的，在不同階段要適時作出調(diào)整。

　　組件工作的協(xié)作模式是管理和設計組件、保證組件庫持續(xù)良性發(fā)展的一種手段。在組件庫和業(yè)務不斷發(fā)展的過程中，可以根據(jù)不同階段的變化以及模式運行的情況適時作出調(diào)整。

　　專欄作家

　　元堯，微信公眾號：長弓小子，人人都是產(chǎn)品經(jīng)理專欄作家。一線互聯(lián)網(wǎng)大廠B端體驗設計師，清華大學美術學院本碩連讀。曾負責國內(nèi)最大開源組件庫Ant Design組件的設計和運營工作，目前負責國際業(yè)務線B端產(chǎn)品體驗設計和組件庫的搭建工作。

　　本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

　　題圖來自 Unsplash，基于 CC0 協(xié)議。

　　該文觀點僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務。