偏产品型技术经理需要掌控的

偏产品型技术经理需要掌控的
在开发的过程中需要进行pdca的循环，下面这些流程并不是意味着做完一个才能开始下一个。一个合格的技术经理不应该循规蹈矩，在所有的产品过程中唯一不变的就是变，适应变化拥抱变化。时间因素在任何事情中都是很重要的，从市场竞争上讲，先一步就是先机，从开发上讲快一步就是成本降低。
产品立项：由决策人员描述大概要做个什么产品或者实现什么理念，大致功能有哪些，大致的目标市场和用户。这一步可能是领导拍脑袋的发明，也可以是客户提出来的需求。产品的决策要符合公司的决策。
可行研究：由产品经理对产品进行明确的语言描述，并从经济、技术、法律等多方面进行可行性分析其可行性，以及决定是自己开发、外包还是外部购买后二次开发，如果可行还需要确定核心功能。这一步至少要从市场和技术两方面进行论证。
大致计划：确定最终的产品大致交付日期，各个里程碑的时间点，交付的产品必须包括可行性分析中的核心功能。
需求分析：定义软件系统的全部需求，编写《需求分析说明书》和《需求规格说明书》，最好做一个产品原型，提交评审。
技术选型：一般项目缺少这个环节，但是非常重要，影响深远。在这里选择使用的开发语言等大方面，这个受公司条件影响比较大，如果和当时公司团队语音相左，选择困难还是很大。
团队建设：一般也是缺少这个环节。对于初创公司或者新的团队，这点是必须要考虑的，直接影响到产品是否能正常顺利的开发完成。放在技术选型后面是因为团队是要为开发产品这个目标服务。
开发计划：每个版本的交付时间，功能点时间点。这个计划是需要随着进度发展进行修正的。
架构设计：由架构师或高级程序员搭建软件的架构，一般基于权限管理，好架构具有连续性，以后的开发只是增加功能，新增功能类似插件一样整合进去而不影响原有代码。
详细设计：由高级程序员描述类和接口等之间的关系，这部分如果是好的框架，直接在代码里面处理就行，也就是将接口定制出来交给程序员实现即可。
开发编码：将接口进行实现。这部分工作还包括单元测试等，界面部分的就按照《需求规格说明书》来做。
项目测试：QC对开发部提供过来的项目进行测试，包括功能和性能测试，依据《需求分析说明书》和《需求规格说明书》,通过发布《用户手册》，测试验收后才能发布。
产品维护：包括bug修改，新功能收集、完善性维护等相关操作。bug要及时修改，新功能可以放置到下一版本中增加。

重要性来讲，越是前面的过程对项目产品影响越大。从商业角度讲，产品立项最重要；纯粹开发技术来讲，架构设计应该是最有技术含量的。

这些都是我多年工作经验基础上总结的。

你缺了一步：工作计划。没了工作计划，你的工作过程在上级那里就是一片空白，除非你的上级非常信任你，否则，他的顾虑迟早会成为你工作的阻碍

挺清晰，刚工作，留个名以后有感触了再来看看

你说的很对，时间因素必须要考虑在里面，做软件做项目必须优先考虑的。越是习惯上的东西越容易忽略。呵呵！

笔者这篇文章学习了。。对我有很大启发。

我认为楼主描述的并不准确

什么叫“偏产品的技术经理”，难道还有不懂产品的技术经理吗，如果产品都不懂，技术就无从谈起。所以技术经理应该是默认就有很强的产品知识的

以我来看，一个开发团队中起码有3种LEADER，可能名称不一样，但是职责范围是类似的：

资源主管：管团队成员的薪酬、考评、任命、团队能力提升、梯队建设等
项目经理：管项目的计划调整、组织日常开发活动、风险评估与规避、实施等
架构师：管产品的架构设计、技术选型、关键技术攻关、技术决策等

这些职责在楼主的描述里貌似全部都有了，所以楼主说的这个不是什么“偏产品型技术经理”，而是上述三种角色三位一体了

这样的话，对这个岗位的人要求就非常高，这个人也会非常忙，我很怀疑是不是真的能一个人兼顾下来。不过好处是各种决策和判断效率会比较高（如果正确的话）

相信楼主的个人能力是比较强的，一般也是小公司，才会出这种均衡型的选手

PS：楼主这个贴写得还是比较好的，为了回复这个贴我特地切换到WINDOWS了，UBUNTU下为什么chrome无法在ITEYE里输入呀~~我擦

所谓“偏产品的技术经理”就是在产品设计上有自己更大的主动权，做成什么样的是不是由客户说了算。ps.这个角色在很多公司里面叫技术总监。
这样的组织是一个扁平的组织，讲究内部沟通，各司其责，各有专攻，快速迭代，适合极限编程，适应市场变化。作为领导者要求高，但是也只是起到提纲挈领的作用，这个角色在产品初期很忙，压力大，但是做好了后期还是很轻松的，最主要就是合理分工，不要什么都扛着，所以团队建设这一步很重要，招的人能力态度和操守是否满足要求，能否主动的提出、发现和解决问题，市场上是否有备用资源，这些都是需要提前考虑的。做的好，老板不是那种很变态的，基本上都不用加班。公司可以很大，团队也可以很大，凡治众如治寡,分数是也。

你说的3种LEADER在团队内形成官僚主义的可能性比较高，尤其是资源主管这个职位，职责和权力完全不对称。你这种组织架构体系在很多公司也是有采用的，存在就是合理，比较适合瀑布式开发，产品原型确立比较早，后期变化很小，一般来说应用于比较大的沟通成本高的项目。不过对于现代架构而言，大项目一般都是需要拆分成小项目，高内聚低耦合，接口部分定义好，每个小团队都是快速反应部队。

谢谢你的回复，共同提高国内软件开发管理水平。

需求调研--》需求分析--》业务架构分析设计--》技术架构分析设计--》编码
一般软件过程都是这种，但执行起来会遇到各种情况
最关键的，还是如何快速适应变化

兵贵神速。是的，市场同战场，适应快速变化很重要。现在软件开发效率提高了，大部分的软件以前只能大公司开发的现在中小公司也可以开发，比如说office这样的软件以前只有类似微软这样的公司能开发出来，但是现在这样的产品国内都有几家。毫无疑问这就涉及到市场竞争问题，谁能快速适应市场甚至引领市场谁的胜算就高。作为一个扁平化组织架构，毫无疑问就是为了适应这种快速反应设计的。