9/22 更新
先谢谢各位前辈的建议，我每则都有看
然后我把这件事跟我的工程师朋友讨论（他现在是小主管）
原本是想了解其他人是怎么做的
没想到却意外拿到可能可以面试的机会，他说他满清楚我的能力
要帮我推荐是完全没问题的，就看我要不要投投看履历
所以没想到这件事意外让我有新的面试机会 lol
没意外的话可能真的会想去外面的世界多看看了....

直接问就好

工程师原本就是沟通吃重的工作，只照着 spec 开发完全不沟通那是码农等级

小公司本来就是这样 习惯就好

人数不够就是你做阿

1.换工作 2.拿职位(PM)+提加薪 自己选一条吧

也没几个人 总有人要做整合觉得薪水不够就要加薪 加不了就走人

其实有一个解决方法 就是api和设计都自己来，给你参考

我觉得只是不够敏捷 可以把大功能拆解

我也知道沟通很重要，但我觉得老板应该要在他自己 Review的时候就应该要发现一些问题然后退回去给设计师和后端真的很细节的问题可能要等前端整合以后才会发现我就觉得没关系，这很难免但我现在体感是，他可能只有大概看一下，就丢过来了

台厂日常：陨石式开发和通灵式开发

就是没个pm吧

你怎么会期待PM会好好review?

review 一直都是当事人做才能降低代沟，你该解决的是怎样的合作模式可以降低修改机会等。以 api 来说，是不是可以反向变成你开 spec；以设计来说，是不是可以增加假互动画面的设计步骤来降低变更机会

SA/SD沟通上很重要，建议找主管出来扛个责任

所以最好的建议就是请老板找一个PM来管事吗XD回 A 大，确实你说得对，但我的意思是像设计稿画的东西结果数据库一开始就没有，这种真的只要花一点时间检查就能发现事情，理论上应该不是到了我这边才被发现所以我才会说老板可能真的只是大概看一下，就 pass api和设计稿了甚至在规划功能的时候应该就要知道这件事了

个人经验是只能靠自己多协调,让设计的时候就考虑到文案的问题

找PM协调是一种方案..但毕竟是新创我觉得老板设计师后端都要有更多的产品心态关于需求这么做会有什么问题？会有操作问题吗？权限问题吗？什么样的情境会遇到什么需求等等看你例子设计师和后端都是需求来就解没有很深入去思考可能的情景这种坏情况就是开发流程最末端那个人最倒楣

好像真的是有这样的感觉，也就是设计师和后端应该都只是老板说啥他们做啥，没有往后想更远导致

至于数据库字段和画面对不上问题如果“后端工程师也有和设计师开会”那就是他的锅..对 后端的锅在新创的环境下后端本来就要有看画面思考可能对应字段的能力当然前后端也要讨论沟通比较好

然后老板也是只有看到表面上的东西，没有仔细想过整合在一起会发生什么事

觉得累就辞职，如果老板是个明君，公司有前途，且你也有野心就继续做。有天老板会发现根本不能没有你就成功了。

我最近也才比较有跟设计师聊天，她也是大概说一下没有UX就直接设计她觉得很恐怖，没看过这样的流程听起来设计师也觉得心累但我也不太懂真正好的设计流程应该是长怎样，所以我也只能听听她抱怨而已

回到我前面说的产品思维的能力本来新创就是要思考各种潜在情境不管是什么职位都是职位只是决定在电脑前产出的形式如果你是在有谈到配股的新创可以用股东身份和老板深入聊聊为了公司一起成长应该还算可以但如果你是没股权的建议有机会就走

好的，谢谢建议，我是没认股的，但薪资还不错所以已经待了一阵子了

跟我以前做的事好像XD~这个就是公司的同仁没有心...

设计师也待了一阵子，只是平常没什么私下交流，是最近真的很爆炸才开始关心工作状况，才知道原来他也很不满意开发流程….

mock资料先做好跟后端应该会好沟通很多。

长此以往会让公司的士气下降

我会做好mock资料，所以我过去前端先动工刻画面后接api发现问题可以很快的跟后端和老板说功能小的时候还可以，这次要做大功能以后我几乎每个画面都会把api退货，因为字段对不上…但退太多了心就会很累，我甚至上周几乎都在发呆，因为我前端能做的都做了，剩下的都是在等被我退货的api还有一部分原因是我发现 flow 有问题，回去问老板该怎么办，结果老板直接把规格大改..所以后端也整个大改我当时看后端听到要大改规格的脸也觉得他很可怜..

本来就要有一个能掌握全体系统架构的角色一般公司在前后端上面会配一个SA/SD做整体规划如果没这个人就看前后端哪边要坦另外我觉得你可以在现职磨练一下并向老板提出接手整体系统规划与把关会思考是一件好事

我们确实没这两个角色，但我以为理论上应该是老板坦…毕竟产品一开始是他自己开发的，只是现在找了我们担任他的手脚，他转为规划产品走向与开出产品规格的角色

老板在忙着生钱 角色转换的技术脱节是很正常的

没有 user story？

所以综合上述，我感觉好像没什么东西能建议老板lol

上线前连 sanity test 都没有？

只能祈祷同事慢慢学会 push 自己，要不然就是我跟老板推荐自己下去帮忙做系统规划

是不是未来公司CTO就看这波了

回 c 大，当然会测试，所以我那段什么都不说直接照错的设计稿接也没人发现是自己心里开玩笑的，我当然不敢这么做，实际上是我这关就会发现很多问题并回报了所以老板最后上线前测试的时候有越来越懒惰的趋势lol 因为他满信任我的东西，他知道我整合的过程就会解掉很多问题了，而且也都有找他讨论目前在线上的东西都蛮稳定的，流量跟营收是稳定成长中，所以可能以老板视角出发会觉得我们团队 run 得很成功吧但他可能不知道我们已经开始心累了，甚至想开履历了

你觉得公司有未来性吗?未来三年有大幅成长的空间吗?假如给你十个人 有没有办法大幅优化或做技术突破?有想法就找老板谈 薪水是谈出来的

老实说我不知道有没有未来性耶，因为我终究是别人的手脚，产品未来三年会怎么走我真的不晓得，我们老板想法迭代的很快，一直在尝试不同的mvp至于技术突破应该也不行，我自认我的程度还在 junior，我们要做的东西根本上技术不难，只是商业逻辑复杂需要好好规划规格，然后我只是比一般人细心而已，很会抓漏洞

你们老板都自己跟市场接触 没带人一起吗?不然你自告奋勇跟老板一起出去聊聊 说要改善UX感觉在你们公司纯前端你已经没有突破空间了如果觉得还想继续做纯前端技术的可以开履历了

老板要做新的mvp的时候当然都会跟我们说明为什么要做啦但我每次听完也没什么感觉XD 无法预知会不会成功就变成反正老板要啥我做啥，至于会不会成功上线了才知道

那MVP做出来是到哪里pitch?

我们有一个主平台，mvp就是一些新的服务，上线了以后我们主平台会有地方 promotion ，另外还有行销团队

那上线之后市场是怎么给feedback的?

那我们定义的成功大概就是这个mvp为我们主平台带来一波新的流量与营收，当然也有很多上线以后乏人问津的

你们产品缺乏从使用者行为了解MVP改善空间的回馈机制还有怎么越看越像博弈啊 错觉吗

不是博弈喔，但确实市场 feedback这块我们好像很弱，目前大概就是用 GA看流量和营收成长当基准吧…

Feedback设计这块是前端往产品与架构走的关键

我好像曾经听到我们行销团队的人问老板说，怎么知道平台这样改对我们是好的。当时老板回答更多时候他是相信他自己的判断，从那以后我发现老板可能也是靠直觉做事的lol

开履历吧

XD….这个夜晚受益良多，感谢各位前辈这篇文可能也不敢放太久，我怕被老板或同事看到，虽然没打名字但感觉从很多事迹上来看可以猜出是我打的lol

什么职缺做什么事 你要逾越 这件事以后就是你的工作

放心，还有100家公司是这样做事的流程是为了解决人太多沟通困难而产生的，你们才4个人，根本还用不到流程，真正有问题的是人

因为没人想当坏人不然就是废，你们才4个人，我觉得废的可能性比较高

很单纯，就是后端太菜，没有把数据库的table字段都记得，才会有这样的问题

其他人可以不管 但是跟后段一定要沟通通常带头检查的应该是后端才对

你们需要一个专职PM 很多小公司都老板兼PM 殊不知其实PM沟通的工作量超大的，被PM放生就是这种感觉，大家都会很痛苦，看老板有没有意识到吧

所以问题根本是资源少、然后同事不够细心、老板又没时间管我们吗lol

资源少不少不知道，只是产品一大就会发现PM有多么重要，可能前面都小产品开发，几个人工作分一分可以过得去，现在明显看起来就是力不从心，可能无力分或也不想分了虽说新创是个很好可以练自己的机会，但我一直不提倡工程师花太多时间处理PM的事情，本职还是要回到好好开发

我说的资源就是人力意思啦XD 因为我只是阐述开发团队遇到的事情，我们还有行销、业务等等，他们人比我们还多lol

否则工作上会很没有成就感，一直觉得自己在做份外的事情

其实我觉得你们流程看起来没啥大问题啊

没名没份的搞不好同事也不感谢，心理上会很受打击，对工作的心理健康很不好，很多人都忽略了心理健康这点

你讲的这些问题你行前会没发现吗

喔对啦，这样算的话就是没人力没错

摆烂或放大问题(拖开发时间) 老板受不了自然会出来解决

行前会的时间点是设计完成并且老板 review 过后没问题才开的，那既然老板都看过了我当然都会默认设计稿不会有什么大问题，就算真的有也是很细微的那种

内心戏不要那么多，就事论事直接讲就好，老板也不会希望专案出包

做好你份内的工作啊,有错就回报,但这些问题点要记录下来之后可能会有检讨大会,如果被说时程延误,就可以拿来保护自己

没有最好的流程 只有最适合的流程

只是随着被雷的次数增加，我现在确实在行前会的时候就会一边开会一边自己仔细看设计稿，至于后端的问题..就不可能在行前会知道了吧lol 行前会的时候大家当然都是说好好好，但最后字段怎么给才是真的

你们听起来后端蛮重要的耶，为什么一开始不把后端叫来开会啊?

4人团队沟通起来跟40人一样…你们看起来就是每个人对目标的理解不一致 看看跑敏捷会不会改善吧

1. 文案应该在 kick off 前就确稿2. Api format，应该由后端+前端与设计开会决议，并请后端先提供 api mock data docs

有个问题是为什么api有问题你不直接跟后端讲，而是要经过你问老板老板再要求后端这个流程？问题搞不好是流程太多，四个人搞得跟四个部门一样

你们需要一个PM以前也是没PM 这样的走法 现在弄了一堆债要救…

觉得后端居多 因为 DB 字段不可能是 f2e 管的

（1）在前后端开始implement feature 之前先拿到apicontract（2）够信任backend 的话就自己mock ui data下去implement,不信任后端的话就请他们提供mock api (3) 预留时间做integration test 和end to end test还有bug bashing另外design doc 应该是feature开发前就应该写好的？

没有sa吗，后端或你老板要兼sa的工作吧感觉后端比较雷吧，很难想像少字段后端开发会不知道

这种小公司最佳解就是两个人都做全端 照功能分

流程没问题 有问题的是人

前端本来就算是一个桥梁的职位，加上是使用产品的第一线这种状况在小团队多多少少会遇到

我觉得你可以找老板讨论一下工作认知～因为这个“最终核对，帮忙把关”是谁要负责做，其实没有一定，老板很可能觉得你很棒都帮她做掉了，可是你却一直觉得老板没把他工作做好...结论就是和老板讨论，你其实不喜欢抓这么多错误，然后你们协调未来怎样调整会是大家都开心，解法很多种喔，选哪种是看你们这几位利害关系人各自想要的和不想要的是什么，都可以谈的，没有什么“应该”要谁谁谁负责，我就列出几个可能选项(1)老板了解你的痛苦、他也有时间，于是他决定以后审核后端PR更严格(2)老板觉得他没空看细部东西，他觉得你帮他看很棒，他说服你把这部分把关的工作正式变成你的工作，并且他帮你升职为team lead也帮你加薪(3) 老板没空帮忙看，他其实也觉得你退回太多次，是这位backend太雷，做事都不仔细，于是他换一个新的backend(4) 老板没空看，他也认同这花你太多时间也让你空等，也让backend要重做，于是他接受你的说服，决定从此以后再多一个文件的步骤，backend在动code之间要先把db schema&api input output写在document，并且开第二次行前会（第一次行前会审ui流程，第二次行前会审backend&frontend后端设计）不过如果你想走了也可以直接离职啦哈哈