前言

之前寫過：前端項目負責人需要具有的能力，本篇寫一下前端項目負責人在項目初期需要做什么？

主要分四個方面

項目相關(guān)

這一部分可能看起來沒那么重要，但是做項目對于項目的關(guān)鍵信息還是要了解的。因為可能當我們在和其他不了解目前我們在做的東西的時候，會問下面的一些東西。

項目背景

通過項目背景了解當前業(yè)務(wù)痛點，想通過我們的產(chǎn)品達到什么樣的效果。
舉例：

• A：營銷增長（如：針對個體要貨訂單預測不準，店鋪運營可視化程度不夠，會員缺失有效管理等）
• B：供應鏈（如：生產(chǎn)與銷售預測不匹配，物流配送可能存在食品安全風險等）
• C：共享與組織能力（如：出賬較慢，對賬效率低等）
• D：技術(shù)與架構(gòu)（如：現(xiàn)存各系統(tǒng)協(xié)同不足，性能和功能影響業(yè)務(wù)等）

項目愿景

以公司項目為例：這里說的比較簡單。
基于中臺架構(gòu)完整構(gòu)建業(yè)務(wù)應用，實現(xiàn)業(yè)務(wù)全流程貫通，實現(xiàn)業(yè)務(wù)實施在線和數(shù)據(jù)口徑統(tǒng)一，并通過中臺能力，實現(xiàn)自動化營銷，財務(wù)自動化對賬并持續(xù)優(yōu)化。

項目價值是什么

• 增加收入
• 提升效率
• 降低成本
• 加強內(nèi)控

項目階段和周期安排

這個還是比較重要的，因為負責的開發(fā)任務(wù)是具有階段性的，分為幾個階段，幾個迭代，每個時間段需要做什么，有什么樣的產(chǎn)出，是不是在業(yè)務(wù)流程上面達成共識。這個很重要。這個在下面進行任務(wù)排期的時候也會考慮進來。

團隊相關(guān)

這里主要是對于團隊內(nèi)部的人員熟悉和周會早會的匯報形式和內(nèi)容形式的了解。有利于后期的協(xié)作。

前端相關(guān)

架構(gòu)相關(guān)

這一部分主要是為了能夠給予業(yè)務(wù)，滿足業(yè)務(wù)的情況下設(shè)計書寫出技術(shù)架構(gòu)圖。前面三個是為了能夠做好技術(shù)架構(gòu)的基礎(chǔ)信息了解。

如何書寫架構(gòu)方案

這個其實我個人也沒有很好的方法論。貼兩張以前畫過的圖：

但是到底技術(shù)架構(gòu)圖的標準是什么？

下面這些條件是公司大佬【阿里p8】和我過技術(shù)架構(gòu)圖【上面第二張圖】反饋給我的。

• 技術(shù)架構(gòu)：上面圖主要表現(xiàn)的是技術(shù)架構(gòu)
• 業(yè)務(wù)邊界：針對不同的業(yè)務(wù)場景，邊界清晰，走不通的業(yè)務(wù)架構(gòu)
• 業(yè)務(wù)架構(gòu)：針對具體的業(yè)務(wù)場景進行技術(shù)支持。例如我們遇到pos離線的場景，這屬于業(yè)務(wù)架構(gòu)
• 動態(tài)流程：業(yè)務(wù)流程 pos 下單，查商品 商品流程如何在架構(gòu)圖體現(xiàn)【缺失】
• 集成架構(gòu)：其他系統(tǒng)集成
• 部署架構(gòu)：部署

技術(shù)相關(guān)

腳手架

技術(shù)選型 & 腳手架選型

這里主要是做技術(shù)選型和腳手架選型。因為我們相對統(tǒng)一，所以基本沒這個問題。

系統(tǒng)模塊處理

這里是列舉了三個例子

• 權(quán)限
• 多頁簽
• 登陸校驗

公共模塊處理

• 公共方法：公共方法的放置
• 公共枚舉值：可參照<用dumi發(fā)布一個用于處理枚舉值的npm包>
• 公共service：數(shù)據(jù)接口處理
• 公共組件：位置放置和規(guī)范【也可通過dumi發(fā)布公有包或者私有包 參照：用react手寫一個簡單的日歷】

技術(shù)調(diào)研 & 技術(shù)落地

疑難問題的技術(shù)調(diào)研和技術(shù)落地方案。

• 以前做過：react - 多頁簽頁面緩存
• 現(xiàn)在在做：electron 做pos【js控制打印機，js加載動態(tài)庫dll適配ic卡等等】

業(yè)務(wù)開發(fā)demo

這是為了最大化的解決項目當中初級開發(fā)的開發(fā)問題。

• 代碼demo：業(yè)務(wù)開發(fā)的demo代碼
• 開發(fā)講解：同步講解demo的開發(fā)模式
• 文檔說明：沉淀文檔說明

任務(wù)劃分相關(guān)

這里的內(nèi)容就不多說了，以前的文章提到過一些：前端項目負責人需要具有的能力。

根據(jù)階段目標check任務(wù)排期是否合適

這里著重提出來，是和團隊相關(guān)部分提到的階段目標有關(guān)系。需要和階段目標契合，這樣在一個時間段，我們項目整體協(xié)作出來的東西才是完整的東西。

規(guī)范相關(guān)

開發(fā)規(guī)范

• 代碼規(guī)范
• 協(xié)作流程
• 提交規(guī)范

內(nèi)部協(xié)同規(guī)范

• 早會
• 周會
• 下發(fā)任務(wù)溝通：下發(fā)任務(wù)明確，講清楚技術(shù)重點難點，開發(fā)人員了解并確認。
• 完成任務(wù)匯報：任務(wù)完成及時匯報，更多是通過項目管理工具完成。
• 疑難問題協(xié)同

文檔規(guī)范

• 相關(guān)文檔匯總地址
• 技術(shù)文檔
• 規(guī)范文檔
• 周會文檔匯總

前端部門相關(guān)

協(xié)作相關(guān)

與產(chǎn)品

統(tǒng)一原型規(guī)范

這里著重說明：統(tǒng)一原型規(guī)范，就是原型的輸出同樣的交互頁面風格要保持統(tǒng)一，不允許有很大差距。

• 原型輸出不像一個系統(tǒng)
• 代碼開發(fā)內(nèi)耗

與后端

統(tǒng)一前端后共識

這里著重說明：前后端對于一些事情處理需要達成共識，這樣會節(jié)省很多溝通問題。

與測試

統(tǒng)一交付測試認知

• 界面無明顯的UI類型BUG，與原型圖、UI設(shè)計圖保持一致，關(guān)于頁面的設(shè)計、排版都能夠符合產(chǎn)品需求。如有修改應和產(chǎn)品、UI溝通一致并且進行修改。
• 功能能夠?qū)崿F(xiàn)產(chǎn)品的需求，且輸入文本框、選擇框、翻頁按鈕、新增校驗等能夠與產(chǎn)品原型一致。還需要考慮字段長度過長的情況如何處理。
• 當前所做的功能應該是流程性功能，不止需要考慮當前頁面的功能實現(xiàn)，需要考慮一下前置的數(shù)據(jù)是從哪里來，在當前的數(shù)據(jù)展示是否合理。前置的業(yè)務(wù)數(shù)據(jù)是否能夠在當前頁面跑下去或者完成。
• 每次做完當前頁面或者修改當前頁面的功能時，跑兩次調(diào)接口，看當前頁面是否可以傳輸數(shù)據(jù)給后端，并且成功返回響應。

公共模塊的統(tǒng)一處理認知

頁面提示語的確定

• 表單頁面提交不需要confirm提示語
• 數(shù)據(jù)刪除/列表頁更新狀態(tài)需要confirm提示語
• 新建頁面路由跳轉(zhuǎn)離開是否需要提示語

form表單的處理

• form表單必填項驗證form表單必填項/非必填項的長度驗證（依賴于數(shù)據(jù)庫設(shè)定或者也存在統(tǒng)一長度限制）
• form表單數(shù)字驗證/電話驗證/郵件驗證
• form表單日期范圍驗證的設(shè)定，startDate的日期范圍驗證是否是只可以點擊當天之前/當天之后，endDate的選擇開始日期一般為startDate的日期之后
• form表單的特殊字符驗證