@
rodrick #9
所以,为啥不说是哪个开源工作流呢?说不定还能找到帮你的人→_→
不影响关键任务,而是小坑多的话,是否属于 [又不是不能用.jpg] 类型?你可以做一些事情:
1. 记录所有 bug,列出 bug 对整个系统使用的影响程度。上报给领导。上报给领导。上报给领导。这是证明 [这个系统真有问题] 的重要凭据。
2. 在存在众多 bug 的情况下,不管是出于时间原因、无其它解决方案、还是其它原因(比如他对这套系统是真爱),领导还是坚持用这套系统,那么你需要继续修 bug,或者请原作者一起修 bug 。
3. 存在 bug 的功能,是否能屏蔽暂时不用?
4. 认真思考一下,bug 修不过来,主要原因是自己(团队)能力不足,还是这个开源本身问题。如果时间充足,能否修得过来?这条可以影响这个锅属于谁(或者说你心里能清楚自己该负多少责)。
5. 认真思考一下,从确定用这套系统,到第一次发现 bug,再到现在,总共过了多久?关于 bug 的问题你向领导反馈过几次?领导是否考虑过重新选择其它方案?其它同类产品二次开发是否真的无法符合你公司的需求?( [你选的嘛 偶像.jpg] )
6. 无法按时交付的话,结果是什么?锅是你的还是领导的?(如果前面几点确定锅不应该你背或者你不该背那么多,最终却是你在背,那建议早点跑路)
7. 如果打算跑路,年底了,跑路前先确定下是否好找下家,或者裸跑是否撑得住。
8. 你在 #11 有提到花钱让人修 bug 了,可以考虑下提出你们的功能需求,和对方确定一个价格,外包给对方做二次开发,这个价格是包含修 bug 的。