前一段時(shí)間忙著寫測試用例，忙著跟UI交涉，感覺去了半條命。

人手不足隨便湊，也許就是一個(gè)小型創(chuàng)業(yè)公司的悲哀！

來這家公司已經(jīng)快8個(gè)月了，從之前的每周五開列會(huì)到后面的會(huì)議省略，簡直是失望透頂。以前大家還會(huì)開會(huì)討論原型可行性等，后面會(huì)議就只屬于大神們的了。只要老板有想法了，找?guī)讉€(gè)大神開會(huì)探討一下，然后老板讓UI給原型圖，給效果圖，給需求文檔（因?yàn)槲覀兊腢I立志做產(chǎn)品，所以兼職產(chǎn)品設(shè)計(jì)和需求文檔這一塊），然后開發(fā)根據(jù)效果圖敲代碼，測試根據(jù)需求文檔寫用例，開發(fā)寫好后測試人員開始測試。

為什么我會(huì)覺得這個(gè)流程很悲哀呢？

因?yàn)槿讨挥虚_始的創(chuàng)意是有會(huì)議探討的，并且只屬于大神們的會(huì)議，其他的原型評(píng)審，需求文檔評(píng)審，測試用例評(píng)審等，全部沒有。相當(dāng)于上面的決定了，下面的照著做就行了。這樣子問題就大了。因?yàn)橛行┕δ芴D(zhuǎn)流程，開發(fā)一臉懵逼，測試一臉懵逼，而且有些功能設(shè)計(jì)很不合理，細(xì)節(jié)定位也不明確。UI 更注重視覺和交互，但是技術(shù)欠缺，技術(shù)上的問題就無法考慮到位了。因?yàn)闆]有會(huì)議，導(dǎo)致大家一臉懵逼，同時(shí)也增加了溝通成本，還有人力資源的浪費(fèi)。一個(gè)功能，開會(huì)的時(shí)候大家一起，講一次、解釋一次就夠了的，但是沒有開會(huì)，看需求文檔也不理解，大家只能跑去私聊UI，UI就需要根據(jù)不同人的不理解點(diǎn)分別解釋。而且原型和需求文檔都是UI直接確定的，相當(dāng)于是UI一個(gè)人的想法，這就會(huì)導(dǎo)致了不合理的設(shè)計(jì)出現(xiàn)。

關(guān)于不合理的設(shè)計(jì)，其他人的想法，有時(shí)候也會(huì)被扼殺了的。因?yàn)檫@又關(guān)系到個(gè)人利益的問題了。如果用了其他人的建議，原本定好了的就需要改動(dòng)，比如需要改需求文檔，改原型，改效果圖。如果開發(fā)按照UI的開發(fā)好了，還要開發(fā)改代碼，測試的還要改測試用例。所以說這就是不開會(huì)評(píng)審的悲劇。如果有個(gè)考慮成熟全面的產(chǎn)品經(jīng)理，還有進(jìn)行會(huì)議評(píng)審，很多矛盾，很多改動(dòng)，都是可以避開的。

所以問題的根本是沒有一個(gè)正式的產(chǎn)品經(jīng)理和進(jìn)行各種評(píng)審，導(dǎo)致無法在源頭上解決不合理的設(shè)計(jì)。為了節(jié)省時(shí)間不開會(huì)議討論和評(píng)審，后面需要花更多的時(shí)間來進(jìn)行溝通和修改，簡直是得不償失！