这是一个创建于 3252 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司的运维人员， 从别的公司挖的，本身非开发人员，但是产品解决方案,技术选型都会让他参与会议，涉及到服务部署和网络资源分配都会看他的建议。 他可能比较熟悉 apache 家族的东西， 推崇用 apache 家族的开源项目解决所有问题，经常说按照他的部署方案，都不用 JAVA,C++开发人员写什么代码了...... ，而且 CTO 是产品经理出身，对技术细节也不了解， 觉得能缩短产品开发周期是好事，结果挖了一个又一个的大坑....。 不清楚运维人员具体的工作职责，这是否正常？
 |
1
lichao 2015-12-18 15:31:59 +08:00
CTO 不应该是最懂技术的吗？
|
 |
2
k9982874 2015-12-18 15:33:57 +08:00  1
CTO 是产品经理出身？逗我呢
|
 |
3
loading 2015-12-18 15:35:36 +08:00 via Android
和老板说，拉他到你的团队，这样你就是他上级，然后把他炒了。
|
 |
4
VeryEase OP |
 |
5
izoabr 2015-12-18 15:40:17 +08:00
CTO 可以不懂技术细节（毕竟技术日新月异），但应该懂技术选型和方案规划，还有架构，当然最重要的是协调能力和沟通能力。最后终极的是业务能力（对业务的理解和对业务给出的解决方案）。还要考虑 TCO （总拥有成本、维护成本）。
所以 CTO 是一个很综合的产物，不是什么人都能干的，技术人员有部分甚至大部分都存在一个问题就是技术思维， CTO 就不能有这种思维，不能只从技术层面考虑问题，也不能不考虑技术问题， CTO 就是个桥梁，就是个中间件；还有就是技术（比如开发人员）就是要精专的，难免会一根筋，这是正常的，但是 CTO 就不能这样，如果 CTO 一根筋了，就容易钻牛角尖，团队和产品就容易出问题。 哦，说运维呢·····不好意思 运维，提意见很好啊，很棒，有些主管偏向也是可以理解的，只是需要一个更棒的人，从大局角度去说服他，去反驳他，最后拍板选择一个合适的方案出来。 |
|
6
izoabr 2015-12-18 15:42:28 +08:00
CTO 可以不懂技术细节（毕竟技术日新月异），但应该懂技术选型和方案规划，还有架构，当然最重要的是协调能力和沟通能力。最后终极的是业务能力（对业务的理解和对业务给出的解决方案）。还要考虑 TCO （总拥有成本、维护成本）。
所以 CTO 是一个很综合的产物，不是什么人都能干的，技术人员有部分甚至大部分都存在一个问题就是技术思维， CTO 就不能有这种思维，不能只从技术层面考虑问题，也不能不考虑技术问题， CTO 就是个桥梁，就是个中间件；还有就是技术（比如开发人员）就是要精专的，难免会一根筋，这是正常的，但是 CTO 就不能这样，如果 CTO 一根筋了，就容易钻牛角尖，团队和产品就容易出问题。 哦，说运维呢·····不好意思 运维，提意见很好啊，很棒，有些 [ [ [ [ [主管 /主观] ] ] ] ] 偏向也是可以理解的，只是需要一个更棒的人，从大局角度去说服他，去反驳他，最后拍板选择一个合适的方案出来。 |
 |
7
echo1937 2015-12-18 15:48:26 +08:00
运维人员参与 产品解决方案，技术选型挺正常的.
出问题也挺正常的，只要责任明晰，哪个环节出问题打谁的板子呀。 |
|
8
izoabr 2015-12-18 15:50:33 +08:00
|
 |
9
9hills 2015-12-18 15:55:06 +08:00
正常。
就好像说 rd 写代码正常，不能因为写的代码有 bug 就说写代码不正常了。。 |
|
10
echo1937 2015-12-18 16:00:08 +08:00
@izoabr
IT 建设不规范的时候， A 环节出问题，就会需要其他环节的人去补位，导致其他人跟着遭殃、跟着加班，搞得怨声载道。 这个时候就需要 CTO 来领导架构优化，明确职责分工，如果你们的 CTO 不懂这些，没关系，多扯皮，多撂挑子，迟早有人会受不了出来干这个事。 我们管这个问题叫“男生宿舍困境悖论”，祝撕逼愉快。 |
|
11
izoabr 2015-12-18 16:08:07 +08:00
@echo1937 嗯，支持。
不过还有一个现象，就像那句，铁打的营盘流水的兵。最初技术部门成立的时候，第一任 CTO 就已经决定了这个技术部门的风格和作风。 CTO 天天忙到咳血，谁不主动自觉完成自己任务再回家，等这个 CTO 咳血死了，殉职了，再换 CTO ，那这个作风应该是会被延续下去的。因为大部分人都已经养成了这个习惯和思维，新人是会被同化的。 至于前期不规范，每个团队都会有这个过程，但是格局一定要有，就像我们现在的网站就几万 PV ，那我们的架构规划也应该考虑到日后上亿的 PV 的情况，我们要提前去考虑将来要过渡到那个架构怎么能更顺滑，有经验的架构师就知道怎么做伸缩预留，就知道用虚拟化之类的手段去提前布局对吧？所以讨论环节其实 CTO 就可以把架构定得更高，预留更多空间，以免扯皮。 哈哈，他们这也够逗的， CTO 不拿事，研发和运维扯皮，还没个人能断案···好惨 |
 |
12
radio777 2015-12-18 16:39:20 +08:00
CTO 是产品经理出身？人人都能当 CTO 了？
|
 |
13
unixbeta 2015-12-18 19:31:59 +08:00 via iPhone
楼主典型的看不起运维吧，以为自己写代码的就牛逼了
|
 |
14
tinyproxy 2015-12-18 21:53:24 +08:00 via iPhone
这是管理问题，不要甩锅给运维。。。
|
|
16
VeryEase OP 现在还没到甩锅的地步，大家都在积极填坑。毕竟产品马上上线了， 延误了时间，不是一个人倒霉，大家都有这个觉悟。 CTO 是新上任，第一次在公司主导产品开发， 想尽快完成产品第一版给大家看成绩的心态也可以理解。
楼上有人说是管理问题，是说到点上了。 不过这个问题估计不是一时半会可以改善.... |
 |
17
BSD 2015-12-18 23:10:57 +08:00
既然都不用写什么代码，那就让他搭个测试环境折腾呗，折腾出来再说。。。。
|
|
18
tinyproxy 2015-12-18 23:34:49 +08:00 via iPad
@VeryEase easy ，没上纲上线。同在创业公司，以前是研发，目前补位运维。看你描述，你们目前团队氛围还好，心还在一起就没啥大问题，但问题还是需要解决的。
|
 |
19
mongodb 2015-12-18 23:37:42 +08:00
我觉得楼主心态挺好~ 知道有坑，但也没过多的抱怨，而是积极试图解决问题。
我觉得也别着急，技术方案不是死的，尤其你们第一版都没出来，可以说，什么都是问题，唯独技术选型不会是问题。定好一个就开始往下做，等以后在合适的时候引入合适的能帮你们梳理架构和技术栈的人，通常就不会在技术这条路上走死掉。 |
 |
20
yangqi 2015-12-19 00:15:25 +08:00
楼主换个角度想想，如果你是 CTO 的话你能保证你们公司开发人员写的代码就不会有坑么？如果没有把握的话，这个方案可以缩短开发周期， CTO 刚上任当然想要早点出活，选目前这个方案也是很正常的。
不管怎么说也怪不到运维身上吧 |
 |
21
julyclyde 2015-12-19 16:26:02 +08:00
从 CTO 的水平来看，你们公司整体是不行啊
我倒是建议该运维快跳槽离坑 |
Select Language