Итоги второго модуля.
Всем привет!

Пока я был в отпуске, закончился второй модуль обучения, о котором я подробнее говорил тут.

Модуль называется «Тимлид и бизнес». Я бы его немного переименовал, чтобы лучше раскрыть вам суть этого модуля: «Конструктивное взаимодействие с командой и рук-лем». Это упрощенная формулировка, которая позволит нам сконцентрироваться на основных идеях.

Для того чтобы лиду(да на самом деле кому угодно, для обычного разработчика это тоже очень важно) конструктивно взаимодействовать с командой, рук-лем и т.д., чтобы грамотно выполнять свою в целом, очень важно понимать, кто чем занимается. И нет, формулировка «разработчик пишет код, тимлид руководит разработчиками, рук-ль направления руководит лидами и т.д.» тут нам не подойдет. Почему? Просто знания иерархии не позволят нам как минимум доносить наши мысли на языке собеседника, не говоря уже про корректную работу. Нам очень важно понимать, на каком уровне абстракции находятся те или иные роли, чтобы мы могли понять их цели, подобрать понятные для этой роли аргументы. Уверен, что вашему СТО совершенно без разницы, какой стейт-менеджер вы выбрали, т.к. у него другой уровень абстракции, другой масштаб целей и решений. Давайте кратко опишу эти уровни:

Cовладельцы, СЕО — Стратегия

1. С помощью какой стратегии мы превратим инвестиции в прибыль?
2. Это на каком рынке и с помощью каких конкурентных преимуществ?
3. Как это позволит нам создать доходный и устойчивый в долгосроке бизнес?
4. Какие финансовые и другие показатели мы таким образом хотим достичь?

CTO, COO, CPO, СМО — С-level — Концепт. Верхнеуровнево.

1. Какой продукт/сервис мы для этого создадим и как будем доставлять
ценность-опыт клиенту? (верхнеуровнево)
2. Какая оргструктура, инфраструктура и специалисты нам для этого нужны?
3. Какие бизнес-процессы (верхнеуровнево) за какие деньги позволят нам
производить и доставлять клиенту ту ценность-опыт, которую мы хотим?

Рукли направления, рукля команд — Механика. Что именно и как мы делаем согласно концепта.

1. Как именно мы отстроим эти бизнес-процессы?
2. Как и что будут делать какие конкретно люди в какие моменты?
3. Какие планы найма сотрудников для этого?

Это достаточно краткая схема, но она уже должна дать вам понимание уровней абстракции. Отталкиваясь от этого, вы сможете лучше понимать, какие проблемы волнуют ту или иную роль, какие вещи важны для этой роли, а какие просто белый шум и трата времени.

Нужно ли это простому разработчику?

Если вы хотите расти, то точно да, т.к. разработчик — это не переводчик слов в код(с этим уже неплохо справляются инструменты разработки типа курсора и т.д.), а решать проблем, и чем лучше понимаете мотивы ваших «заказчиков» (обобщено), тем лучше вы сможете это сделать.

Если хотите еще глубже понять каждую роль, то советую вам почитать книгу «От разработчика до руководителя».

После того как мы разобрались с уровнями абстракции, давайте перейдем к конкретным практикам, которые вам помогут:

Конструктивная конфронтация. Штука полезная, для старта есть прям готовый алгоритм, который позволит вам начать практиковаться.

Принцип позитивного намерения. Супер принцип, понимание и применение которого позволяет вам не просто «собачиться» и «холиварить», а действительно конструктивно двигаться в разговоре. Ну и этот принцип отлично помогает экономить нервы. Я часто применяю его за рулем — а вдруг тот, кто вас подрезал, не злостный нарушитель, который хочет разбить вашу машину, а спешит в больницу? Может, не стоит на него злиться, а просто пропустить его, пусть спешит дальше.(без перегибов, конечно)

Принцип безоценочности. Это, пожалуй, самое сложное. Но стоит практиковаться.

Принцип аргументации через выгоды собеседника. Принцип до безумия прост, все про это знают, но в момент спора забывают.

Правило формирования устойчивой договоренности. В идеале по SMART.

Это не все принципы, их куда больше, но я бы начал именно с этих. Но, как говорят, знать — это одно, а делать — совсем другое. Действительно, внедрить их в работу куда сложнее, чем просто понять.