百问百答精华帖之规划和需求篇 | NO.23-NO.45
宝玉/专栏用户

该思维导图由 AI 生成,仅供参考
一问一答
No.23
Charles:可行性分析形同虚设,小公司岗位职责不清晰,互相照顾面子怕得罪人,谁都怕犯错背锅,感觉谁都对,最终就导致谁是“老板”谁拍板!我感觉这个问题挺严重的,很影响决策正确性,只能等所谓的市场反馈。也用类似项目成员“扑克牌”打分的方式可以解决吗?核心问题出在哪里?
宝玉:这个问题已经不是可行性研究的问题了!核心问题在于没有一套合理的类似于扑克牌打分的机制和流程。
扑克牌为什么是个好机制:
公平合理,每个人都有机会不受他人影响的表达
不用背锅,估错了也没关系,意见不一致还可以讨论
可行性研究是不是也可以形成类似机制?有专门会议,大家提前准备,会议上一起讨论结果,不用背锅,根据讨论结果形成最终决议。项目结束后在回顾对比当初的分析,作为下一次的参考。
No.24
川杰:架构师是否也属于管理者的范畴?因为他需要对产品的整个框架的负责,进而涉及到对每个人的代码的管理,必要时还要给带领团队成员去做重难点问题的攻坚。那么对于架构师而言,是更偏向技术还是管理呢?
宝玉:我觉得架构师和管理有相通的也有不同的,简单说一下我的观点:
相同之处:
都需要大局观;
都需要好的沟通能力,让团队清晰的理解自己的意图;
都需要用好流程和工具;
都要善于“分而治之”,把复杂的问题拆分成小的具体的问题。
公开
同步至部落
取消
完成
0/2000
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结

本文深入探讨了项目规划和需求领域的关键问题和解决方法,涵盖了小公司管理挑战、架构师角色定位、团队目标一致性、技术管理、敏捷项目计划、需求文档和测试用例的验收等多个方面。作者以问答形式清晰解答了第23到第33个问题,并分享了项目管理各阶段的典型工具和风险管理方法。此外,还提供了优秀的需求规格说明书、概要设计、详细设计、代码规范文档、测试文档、部署文档等具体案例和链接。整体而言,本文内容涵盖了多个方面的知识点,适合需要深入了解规划和需求领域的技术人员阅读参考。 文章还介绍了在敏捷开发中产品部门和开发部门的合作方式,以及在前后端分离、Restful风格的应用架构下如何提高代码重用率和开发速度。建议使用第三方API云服务来简化后端开发,如Apollo GraphQL和Firebase Firestore。这些内容为读者提供了快速了解规划和需求领域关键问题和解决方法的机会,是一篇值得技术人员深入阅读的文章。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《软件工程之美》,新⼈⾸单¥59
《软件工程之美》,新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示,欢迎踊跃留言。
收起评论