前端項目負責人在項目初期須要作什麼？

這是我參與更文挑戰的第2天，活動詳情查看： 更文挑戰

前言

以前寫過：前端項目負責人須要具備的能力，本篇寫一下前端項目負責人在項目初期須要作什麼？



主要分四個方面

項目相關

​

這一部分可能看起來沒那麼重要，可是作項目對於項目的關鍵信息仍是要了解的。由於可能當咱們在和其餘不瞭解目前咱們在作的東西的時候，會問下面的一些東西。
​

項目背景

經過項目背景瞭解當前業務痛點，想經過咱們的產品達到什麼樣的效果。
舉例：

• A：營銷增加（如：針對個體要貨訂單預測不許，店鋪運營可視化程度不夠，會員缺失有效管理等）
• B：供應鏈（如：生產與銷售預測不匹配，物流配送可能存在食品安全風險等）
• C：共享與組織能力（如：出帳較慢，對帳效率低等）
• D：技術與架構（如：現存各系統協同不足，性能和功能影響業務等）

​

項目願景

以公司項目爲例：這裏說的比較簡單。
基於中臺架構完整構建業務應用，實現業務全流程貫通，實現業務實施在線和數據口徑統一，並經過中臺能力，實現自動化營銷，財務自動化對帳並持續優化。
​

項目價值是什麼

• 增長收入
• 提高效率
• 下降成本
• 增強內控

​

項目階段和週期安排

這個仍是比較重要的，由於負責的開發任務是具備階段性的，分爲幾個階段，幾個迭代，每一個時間段須要作什麼，有什麼樣的產出，是否是在業務流程上面達成共識。這個很重要。這個在下面進行任務排期的時候也會考慮進來。
​

團隊相關

這裏主要是對於團隊內部的人員熟悉和週會早會的彙報形式和內容形式的瞭解。有利於後期的協做。


​

前端相關

​

架構相關

這一部分主要是爲了可以給予業務，知足業務的狀況下設計書寫出技術架構圖。前面三個是爲了可以作好技術架構的基礎信息瞭解。
​

如何書寫架構方案

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



​

可是到底技術架構圖的標準是什麼？

下面這些條件是公司大佬【阿里p8】和我過技術架構圖【上面第二張圖】反饋給個人。

• 技術架構：上面圖主要表現的是技術架構
• 業務邊界：針對不一樣的業務場景，邊界清晰，走不通的業務架構
• 業務架構：針對具體的業務場景進行技術支持。例如咱們遇到pos離線的場景，這屬於業務架構
• 動態流程：業務流程 pos 下單，查商品 商品流程如何在架構圖體現【缺失】
• 集成架構：其餘系統集成
• 部署架構：部署

​

技術相關

​

腳手架

技術選型 & 腳手架選型

這裏主要是作技術選型和腳手架選型。由於咱們相對統一，因此基本沒這個問題。

系統模塊處理

這裏是列舉了三個例子

• 權限
• 多頁籤
• 登錄校驗

公共模塊處理

• 公共方法：公共方法的放置
• 公共枚舉值：可參照用dumi發佈一個用於處理枚舉值的npm包
• 公共service：數據接口處理
• 公共組件：位置放置和規範【也可經過dumi發佈公有包或者私有包 參照：用react手寫一個簡單的日曆】

​

技術調研 & 技術落地

疑難問題的技術調研和技術落地方案。

• 之前作過：react - 多頁籤頁面緩存
• 如今在作：electron 作pos【js控制打印機，js加載動態庫dll適配ic卡等等】

​

業務開發demo

這是爲了最大化的解決項目當中初級開發的開發問題。

• 代碼demo：業務開發的demo代碼
• 開發講解：同步講解demo的開發模式
• 文檔說明：沉澱文檔說明

​

任務劃分相關

這裏的內容就很少說了，之前的文章提到過一些：前端項目負責人須要具備的能力。
​

根據階段目標check任務排期是否合適

這裏着重提出來，是和團隊相關部分提到的階段目標有關係。須要和階段目標契合，這樣在一個時間段，咱們項目總體協做出來的東西纔是完整的東西。
​

規範相關

開發規範

• 代碼規範
• 協做流程
• 提交規範

內部協同規範

• 早會
• 週會
• 下發任務溝通：下發任務明確，講清楚技術重點難點，開發人員瞭解並確認。
• 完成任務彙報：任務完成及時彙報，更可能是經過項目管理工具完成。
• 疑難問題協同

文檔規範

• 相關文檔彙總地址
• 技術文檔
• 規範文檔
• 週會文檔彙總

​

前端部門相關

​

協做相關

​

與產品

統一原型規範

這裏着重說明：統一原型規範，就是原型的輸出一樣的交互頁面風格要保持統一，不容許有很大差距。

• 原型輸出不像一個系統
• 代碼開發內耗

​

與後端

統一前端後共識

這裏着重說明：先後端對於一些事情處理須要達成共識，這樣會節省不少溝通問題。
​

與測試

統一交付測試認知

• 界面無明顯的UI類型BUG，與原型圖、UI設計圖保持一致，關於頁面的設計、排版都可以符合產品需求。若有修改應和產品、UI溝通一致而且進行修改。
• 功能可以實現產品的需求，且輸入文本框、選擇框、翻頁按鈕、新增校驗等可以與產品原型一致。還須要考慮字段長度過長的狀況如何處理。
• 當前所作的功能應該是流程性功能，不止須要考慮當前頁面的功能實現，須要考慮一下前置的數據是從哪裏來，在當前的數據展現是否合理。前置的業務數據是否可以在當前頁面跑下去或者完成。
• 每次作完當前頁面或者修改當前頁面的功能時，跑兩次調接口，看當前頁面是否能夠傳輸數據給後端，而且成功返回響應。

​

公共模塊的統一處理認知

頁面提示語的肯定

• 表單頁面提交不須要confirm提示語
• 數據刪除/列表頁更新狀態須要confirm提示語
• 新建頁面路由跳轉離開是否須要提示語

​

form表單的處理

• form表單必填項驗證form表單必填項/非必填項的長度驗證（依賴於數據庫設定或者也存在統一長度限制）
• form表單數字驗證/電話驗證/郵件驗證
• form表單日期範圍驗證的設定，startDate的日期範圍驗證是不是隻能夠點擊當天以前/當天以後，endDate的選擇開始日期通常爲startDate的日期以後
• form表單的特殊字符驗證