前一段時間忙著寫測試用例，忙著跟UI交涉滔金，感覺去了半條命。
人手不足隨便湊茂嗓，也許就是一個小型創(chuàng)業(yè)公司的悲哀餐茵！
來這家公司已經(jīng)快8個月了，從之前的每周五開列會到后面的會議省略述吸，簡直是失望透頂忿族。以前大家還會開會討論原型可行性等锣笨，后面會議就只屬于大神們的了。只要老板有想法了道批，找?guī)讉€大神開會探討一下错英，然后老板讓UI給原型圖，給效果圖隆豹，給需求文檔（因為我們的UI立志做產(chǎn)品椭岩，所以兼職產(chǎn)品設(shè)計和需求文檔這一塊），然后開發(fā)根據(jù)效果圖敲代碼璃赡，測試根據(jù)需求文檔寫用例判哥，開發(fā)寫好后測試人員開始測試。
為什么我會覺得這個流程很悲哀呢碉考？
因為全程只有開始的創(chuàng)意是有會議探討的塌计，并且只屬于大神們的會議，其他的原型評審侯谁，需求文檔評審锌仅，測試用例評審等，全部沒有墙贱。相當于上面的決定了热芹，下面的照著做就行了。這樣子問題就大了嫩痰。因為有些功能跳轉(zhuǎn)流程剿吻，開發(fā)一臉懵逼窍箍，測試一臉懵逼串纺，而且有些功能設(shè)計很不合理，細節(jié)定位也不明確椰棘。UI 更注重視覺和交互纺棺，但是技術(shù)欠缺，技術(shù)上的問題就無法考慮到位了邪狞。因為沒有會議祷蝌，導致大家一臉懵逼，同時也增加了溝通成本帆卓，還有人力資源的浪費巨朦。一個功能，開會的時候大家一起剑令，講一次糊啡、解釋一次就夠了的，但是沒有開會吁津，看需求文檔也不理解棚蓄，大家只能跑去私聊UI，UI就需要根據(jù)不同人的不理解點分別解釋。而且原型和需求文檔都是UI直接確定的梭依，相當于是UI一個人的想法稍算，這就會導致了不合理的設(shè)計出現(xiàn)。
關(guān)于不合理的設(shè)計役拴，其他人的想法糊探，有時候也會被扼殺了的。因為這又關(guān)系到個人利益的問題了河闰。如果用了其他人的建議侧到，原本定好了的就需要改動，比如需要改需求文檔淤击，改原型匠抗，改效果圖。如果開發(fā)按照UI的開發(fā)好了污抬，還要開發(fā)改代碼汞贸，測試的還要改測試用例。所以說這就是不開會評審的悲劇印机。如果有個考慮成熟全面的產(chǎn)品經(jīng)理矢腻，還有進行會議評審，很多矛盾射赛，很多改動多柑，都是可以避開的。
所以問題的根本是沒有一個正式的產(chǎn)品經(jīng)理和進行各種評審楣责，導致無法在源頭上解決不合理的設(shè)計竣灌。為了節(jié)省時間不開會議討論和評審，后面需要花更多的時間來進行溝通和修改秆麸，簡直是得不償失初嘹！
