今天说一说产品和技术，以及对应的人员组织架构。
产品直接决定着项目的成败，技术虽没有直接决定成败，但是它的架构和储备积累决定了后期的研发、工作效率。
如果要长期走下去，管理者要产品和技术同样的重视与发展。
产品
产品一般是说最终呈现出来的项目，而在我们平常工作中，它以更零散的名称存在着，就是我们所说的业务。
对零散的业务进行归集、整理，最后形成我们的模块功能，模块功能组成我们的产品。
业务的搜集，大体可以分为两个方式进行收集，主动搜集和被动搜集；
主动收集业务，即产品人员去一线观摩，主动了解业务，挖掘需求，解决痛点；
被动收集业务，即一线人员有明确的反馈渠道，可以是工作群、电子表格任何形式的反馈都算。
一般的团队是两种方式都存在，只是两种方式占比的多与少。
主动搜集方式占比高的团队，会带来诸多好处，对我们产品有着主动权，有着优先定义产品的权利，能够从这些主动信息里面去思考、抽象出自己的产品，而不是变成业务堆积出来的产品；
被动搜集方式占比高的团队，会带来诸多坏处，比如一线人员觉得我们不专业，有时候被动搜集上来的业务很少，更多的时候，是反馈急需解决的问题，没有足够的时间去思考、调研业务、挖掘需求、解决问题，最后上线的产品的业务质量、技术质量都可想而知。
所以，真正做得好的团队，应该团队内形成共识，采取主动搜集的方式，绞尽脑汁的提高主动搜集业务的占比。
这样就能提前做好规划，掌握产品规划的主动权，与研发团队进行更高效的协同工作；减少从业务源头对后续环节产生影响，很多时候被动反馈的业务，是急需解决的，首先会打乱研发团队的研发节奏，后续每个环节多少都有影响，久而久之，给产品使用方的感受就是研发产品团队不专业。
好的产品应该是被定义出来的，思考出来的，而不是靠功能堆积出来的。
技术
这里说的技术，是说技术规划与架构。
技术和其他的事物一样，要聚齐一群人，就要让其有目标感，每天徒劳的搬砖没啥很大的意思。
选择一门合适的编程语言，挑选一款合适的中间件，使用一种合适的服务框架，合理的规划项目层级，等等都可以归为技术架构。
技术规划是否合理，还有一些技术架构的选型是否合适的判断依据，还是来自产品的定义，所以应该是先有产品规划，然后才有技术规划与技术架构。
比如研发的产品的呈现形式是B/S架构，是做移动App，还是小程序？
是做平台，还是做产品微服务，一开始大的方向还是需要定下来的。
定义好大的规划之后，也找出技术积累点进行业务的积累。
像做工业控制软件，上位机与设备打交道就非常频繁，我们是不是要抽取一层驱动层，来专门沉淀解决与设备打交道的系列问题，不要每个上位机都为了设备打交道而折腾得死去活来；而涉及到大数据储存，我们就要整理出一套成熟的大数据储存方案，真有大数据使用的情况，就有开箱即用的方案。
还有服务之间相互依赖调度，是不是一开始就定义为整体项目是微服务体系架构，而不是通过各种curl满天飞？
通过产品对项目的定义，分析清楚项目之间的界限与依赖关系，决定好项目的层级，然后定好基本的开发路径，这个是一开始就要定下来的，而且在很长一段时间内也不会去进行变更调整的，后续根据该规划进行相应的人员组织架构，沉淀相关的技术。
人员组织架构
前面说了产品和技术，接下来说一说人员的组织架构。人员组织架构是与产品规划和技术架构相结合，然后一一对应的，需要注意两点：一个是各司其职，一个是责任到人。这样子有利于管理者对项目进行跟进，不然团队大了，无法协同工作。
如果项目涉及多个部门，要注意部门内部的事情或者需求要把握住从一个口径来，一般该口径为项目经理，不然团队内部事情优先级会无法排，整个团队的节奏就会不稳定。
总结
最后总结一下，还有一个注意点，不要让做技术的去同步做产品，一个是人都有惰性，二是技术人员不能从整体出发，很多时候只了解自己模块的业务，对整个项目的业务没有一个全局的认识；
还有就是产品业务不是一蹴而就的，是在技术工程师的实现的过程中会有变化的，其中就涉及到各种交涉问题，而普遍的技术人员在沟通上有明显的不足，而且容易打断技术工程师有整块的开发时间，从而导致降低工作效率。
但是可以让技术工程师在某个整段的时间内负责某个产品调研，调研之后出具PRD文档。
最后，不管是对产品还是技术，重要的还是要有产品规划和技术架构让其有使命感、目标感、责任感，然后保护好他们的整块研发时间，相信你就能打造出一支战斗力和凝聚力非常不错的团队。
