下午好 我想讲一个短故事，发生在我不久前，与职业期望和对现实情况的错误理解有关。 雇主如何误导或不知情地损害团队动力。
我从莫斯科到达一个省市，然后打算在某公司担任IT部门主管一职。 在完成了莫斯科的职业发展以及从第一线到第三线的所有工作阶段之后，意识到我喜欢人员/流程的管理和管理并且我能做到，所以我开始寻找空缺。
细节剪下。
当公司需要“特殊，收割者和游戏玩家”时（这是当一个人需要焊接电路板并编写1C配置时），我并没有对变压器的空缺感到特别分散，我耐心地等待着一个很好的报价。 两个月后，部门副主任向我提出了一项建议，那就是很难不同意。 方向刚刚出现，这是一家联邦规模的公司，在该地区设立了支持和发展部门，该计划宏伟且完全符合我的期望。 可以从头开始建立团队和流程，进行优化并将其集成到现有流程中。 每个人都称其为“技术支持协调员/负责人”。 好吧，我准备战斗了。
最初目标：
- 第一和第二行的支持。
- 知识库创建
- 创建用户文档
- 深入研究业务流程以实施“业务咨询”
- 为了在ITIL服务台方法的框架内准备各部门之间的交互规则（我计划从那里仅采用传递应用程序和事件+编写SLA的过程，因为我知道没人会完全实施完全正式的过程，因此这是行不通的）
- 雇用支持人员。
文件制作
我想要的是：由于我必须维护所购买的信息系统，并且过去经常处理硬件基础架构，因此我决定从对我最明显的方面开始逐步进行工作-我要求系统和文档自动化的流程规则给她。 我遇到了第一个惊喜-没有购买用于“金钱”的系统的文档。 开发人员在膝盖上勾勒出了幻灯片，这些角色如何参与到流程中，仅此而已。 该公司还有另外4个月的合同支持，可以与他们联系，询问有关系统运行的问题。 没有用于实施该系统的内部项目，截止日期是由协议和一个excel文件确定的，其中指出了某些改进措施的实施日期。 是的，在我录用后，系统又添加了5个月。
发生的事情：只有一半的罪过，以Visio图表的形式描述了几个过程。 部分描述的系统模块。 由于截止日期，与购买的系统的开发人员的交流变得更加糟糕。 据我了解，购买文档不是强制性的。
结论：在 没有开发人员帮助的情况下，对未记录的未完成系统的描述很差。 尝试建立沟通过程。知识库创建
我想要的是：第一线的支持应该从用户那里收集一定的问题，假设经理已经（至少部分地）拥有了这个问题。 但是，在与销售部门负责人协商之后，很明显没有池，流程看起来像这样：用户打电话给我们，如果与技术部分联系了，我们会帮助，如果与业务部分相联系，我们会回呼。 由于答案的业务部分根本没有，因此第一批用户应该不是很幸运。 再次，在谈话中，我意识到企业并没有真正重视新用户，并准备承担这些风险。
要澄清的是，使用这样的消息来源，图片看起来相当模糊，但我将其视为挑战。
发生了什么：创建了一个文档来涵盖最初的业务咨询量。 无法规范与公司合作的程序。 企业可能会忘记回答“不在清单中”的新问题。 我不得不重新请求，保持控制。 在docuwiki的基础上创建了一个知识库，其中描述了问题，系统架构，第二个支持热线和管理员的基本操作。 无法描述用于在系统中创建新产品的设置，因为它是以半可编程的方式创建的，因此有必要与程序员一起对其进行描述。
结论： 建立牺牲客户忠诚度的知识库是错误的步骤。 如果企业这样做，那么额外的负担就会以缺陷的借口和遏制其他负面客户的形式落在支持上。员工招聘
我想要的是：为了选择员工，我有条不紊地去了我的团队：我选择了一份能力列表，并就这些能力进行了电话面试。 最初，所有问题都具有同等的重要性，经过几次面试，我意识到所有候选人都同样适合空缺，而且以这样的步调，您可以长期雇用人。 所有能力都得到了重视，整个过程变得更加有趣。
一线能力表：
该模板已发送给管理层批准，但未返回“应用-不应用”响应。
我是由一位老同事推荐的第一人称，没有模板（我工作了一周）。 下一位老板接过。 剩下的三名（女孩）是在我的参与下招募的，但没有征求我的建议，也没有兴趣发表意见。 尚未收到我的物质动力和预算。
发生的事情：招募了一个有趣但不能完全满足需求部门的人员，员工在第一线工作做得很好，但是为了更深入地融入系统，需要适当结构化的培训和知识传递过程。 与我一起，RFP高于市场平均水平的人由于工作流程设置不正确而失去了无形的动力。
结论：为新进员工准备大量的工作。 否则，它将严重影响对雇主和系统的忠诚度。 了解员工激励的过程-物质和非物质。工作流程
我想要的是：启动系统后，我们开始遇到第一个困难：旧的界面看起来很糟糕，并且无法使用所有用户友好的概念。 呼叫的主要来源是对接口而不是业务流程的不满意。 用户根本无法发出请求。 主要错误立即被带到了新招募的开发团队中，但是在这里我们遇到了第二个问题：不仅没有与外部支持系统的人员进行沟通，而且没有优先级来修复系统-所有工作都致力于编写新的系统。功能和产品，因此无法分配人员来修补会使呼叫数量减半的基本错误。
发生了什么：在再次向管理层指出问题后，它仍然允许进行更正，并且呼叫流减少了三倍。
结论： 建立确定任务优先级的过程，讨论与开发团队互动的顺序。面对上述每一项任务，我每次都会向管理层提出建议，以简化流程，并试图使自己的愿景与公司的愿景协调一致，但是我总是遇到经理的工作（系统问题）或收到“到目前为止”的答案，并且“我们不想过于形式化” ”。 我也知道计划将部门扩大到5人，并且看到有必要了解如何管理支持流程和资源。 我已经开始怀疑，由于我不断地尝试执行更改，因此当局更改了我的计划。 我不再被称为协调员或上司，我没有参加与系统开发相关的集会。
之后，我决定准备一项策略，并了解我是否正在执行该策略。 因为老板根本没有在策略上与我沟通。 该策略立即针对了莫斯科IT部门的一位高级人士，对我而言，我的工作面貌已发生变化。 然后，该策略从莫斯科直接交给了我的直接老板，然后我与当地老板发生了冲突。
结论： 分析该部门的策略。 定义短期和长期计划。 与领导者讨论愿景。“ Marleson芭蕾舞团”的第二部分
上述事件发生后，直接上司几乎停止与我交谈。 我开始考虑离开。 最初，我看到了一个有趣的项目，该项目在克服了所有参与者在流程中的正确交互中遇到的某些困难之后，可以成功完成，并且得到了一个强有力的，有正确KPI且具有明确的输出指标的支持部门，这些指标对于企业而言是可以理解的。 现在，我看到该部门陷入了日常工作，却没有真正发展。 两项任务成为当务之急-使用gitlab应答呼叫并描述系统的错误（而不是改进），这些错误由开发人员修复。
另一个故事是经理所谓的“测试”过程，我们也建议执行该过程。 没有人了解这些程序，也没有单独的测试人员。 在发布之前，整个团队没有任何性能指标的情况下对“黑匣子”进行功能测试。 没有使用其他方法。 由于缺乏发展领域的背景和缺乏培训，被征聘的工作人员无法有效参与测试。 发布日期经常失败，或者发布版本未经测试。
结论：该部门不能有效地并行处理两个大流程。 会有两个过程。
对抗仍在继续。 经理设法翻转了我认为重要的所有管理要素：
- 战略眼光
- 控制
- 管理人员
- 动力
还表达了“以早点上班而后离开的形式对公司的忠诚度”这样的魔术点。
最终我失去了动力，我邀请老板谈论我在公司的进一步职位以及离开公司的决定，当时我被告知该部门目前的形式适合每个人，并且没有开发个性化元素的计划。 结果，我离开了公司，在尝试实现对支持部门工作的愿景方面获得了实践经验。
发生了什么：经历，经历，再一次经历。
结论： 我为自己记录了哪些错误：
- 为了不浪费时间-预先确定和协调计划
- 明确定义您的策略。 如果有遗漏-立即解决问题
- 为自己决定一个舒适的工作流程。 在物质动机和非物质动机之间找到折衷方案
- 也许我花了太多时间来理解这些东西。 表面上有很多东西
我也想听听同事的实施故事和细微差别，我没有注意到这些经验和细微差别。