Онлайн
библиотека книг
Книги онлайн » Разная литература » Настольная книга тимлида разработки ПО - Виктор Большаков

Шрифт:

-
+

Закладка:

Сделать
1 ... 10 11 12 13 14 15 16 17 18 ... 24
Перейти на страницу:
работы для всей компании может оказаться меньше по сравнению с другим отделом. Правильным решением в таком случае будет выполнить ваш запрос с меньшим приоритетом, это как раз и составит максимальную выгоду для всей компании. Для четкой и правильной приоритезации необходимо описать последствия отложенного решения, его влияние и ценность вашей заявки в рамках компании.

— Регламентируем там, где нужно.

Если взаимодействие приводит к конфликтной ситуации его необходимо регламентировать — согласовать с другим подразделением точный интерфейс взаимодействия. Кто, кому, что, как и когда передает? Обычно это не односторонний процесс, он снабжен обратной связью, которую тоже требуется регламентировать. Помните, любые регламенты несут риски того, что одна из операций не подойдет и регламент сработает во вред, а не на пользу.

— Сотрудничество, а не соперничество.

Если в компании есть похожее подразделение, вы можете вместе искать способ стать лучше. При этом помните, что обмен знаниями и опытом принесет максимальную пользу для всей компании.

— Эскалация в необходимых случаях.

В некоторых ситуациях необходимо эскалировать вопросы до руководства. Невозможно всё регламентировать и предусмотреть, так что такие ситуации будут происходить (особенно из-за наличия конфликтующих целей). Для этого необходимо донести до руководства информацию о том, что в другом подразделении приоритеты выставлены неподходящим для вас образом или стиль их работы конфликтует с вашим. В этом случае вы можете в диалоге с другим подразделением открыто заявить о необходимости эскалации вопроса для поиска более правильного решения в интересах компании.

Члены вашей команды и вы легко найдете повод сплотиться против единого врага. Если вы думаете, что в качестве врага можно выбрать другое подразделение компании, это заведомо неправильная позиция. Ведь через какое-то непродолжительное время такой подход выстроит отношения на ненависти и нежелании слушать и слышать другую сторону. Обычно такие отношения взаимны, но не долгосрочны — очень скоро это будет замечено руководством и вам будет поручено наладить отношения, выстроив плодотворный созидательный труд. Заметьте, вы можете проявить непрофессионализм и продолжать искренне ненавидеть своих коллег, но это уже ваша личная позиция, работающая против общих целей. Даже если вы 100 раз правы и в другом подразделении работают непрофессионалы, вы не можете судить о том, насколько это плохо, пока не обсудите это с руководством (может быть гораздо больше причин в пользу сложившейся ситуации, чем против нее).

Строить стены плохо, как их разрушить?

— Наладить обмен информацией между подразделениями и повысить ее прозрачность.

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

— Обмениваться новостями, чтобы все имели доступ к информации и в коллективе формировались здоровые отношения.

— Разберите конфликт, формализуйте обмен информацией/результатами труда, выстроите процесс более формально чтобы исключить недопонимания и ошибочные ожидания.

— Найдите повод регулярно вместе общаться на рабочие и нерабочие темы. Как показывает практика, проявлять неуважение проще через почту, мессенджеры и т. д. В живом общении людям сложнее проявлять негативные эмоции и проще решать конфликты.

Управление ожиданиями от команды

Начните с вопросов:

— Зачем команда существует?

— Зачем команда нужна будет дальше?

Вы должны понимать, что лишь часть ожиданий формализована и доведена до вас — это бывает связано с различием в восприятии или неспособностью систематизировать ожидания. В любом случае полного детального описания того, что от вас ожидают вы скорее всего не получите.

Ожидания меняются со временем, и вы должны постоянно сверяться с тем, что от вас требуется.

Управление ожиданиями — это предмет двустороннего обсуждения. Если в компании или конкретном бизнес-направлении есть определенные цели, то ваша задача понять, как их можно достичь и какие для этого потребуются ресурсы и сроки. Желание делать и не нести никакой ответственности за сроки напрямую влияет на качество, что возвращает вас на шаг назад из позиции тимлида в позицию разработчика-исполнителя.

Старайтесь максимально конкретизировать цели (в идеале по S.M.A.R.T.) — не завышайте ожидания, оставляйте резервы для покрытия рисков и заранее продумывайте шаги для достижения поставленных целей. Поскольку это командная работа, она не может избежать влияния внешних факторов. Ваша задача определить их и скорректировать ожидания от команды. Правильный подход: «задача будет сделана в срок, если мы…». Также стоит учитывать дополнительные расходы при определении сроков на поддержку продуктов, плановый рефакторинг и др.

В разных компаниях по-разному выстроен процесс формализации ожиданий и их управления, он может опираться на результаты:

— Спринтов

— Дорожной карты

— Системы контрактов.

Стратегические ожидания будут размываться тактическими и операционными. Причем контроль всех уровней ожиданий будет на вашей стороне. Держите в фокусе команды стратегические ожидания при любых обстоятельствах и временных изменениях курса.

Требуйте обратную связь по достигнутым результатам. Выполненные задачи и достигнутые цели — это ценность, которую организация получила от работы команды. Команде важно получить эту обратную связь, и ваша функция ее транслировать. Если обратная связь негативная, вы должны принять удар на себя.

В том случае если цель размазана и не выражена какими-то конкретными границами, найдите ориентир обратной связи в виде метрик продукта или опросов заказчиков. Бизнес редко готов делиться финансовыми результатами или оборотами, для этого существуют более безопасные метрики в виде количества активных пользователей, объема операций или возврата посетителей (retention).

PR и DevRel

Ценность внутреннего PR вашего подразделения в рамках компании может быть выражена в: распределении премиального фонда в вашу пользу, потенциале роста, узнаваемости ваших сотрудников, понимании другими подразделениями специфики вашей работы.

Как этого можно добиться:

— Публиковать наиболее интересные задачи, которые вы решили

— Увлеченно рассказывать о ваших специалистах

— Приглашать другие подразделения на открытые внутренние доклады

— Публиковать статистику решаемых задач, метрик систем в проде

DevRel — отношения с разработчиками, чаще всего подразумевается внешний Tech PR. На такую деятельность в маленьких компаниях не находят ресурса, однако если даже не выделять отдельного специалиста, работа коллектива может быть организована таким образом, что такой Tech PR будет появляться естественным образом.

Основная цель DevRel — повысить узнаваемость бренда, что улучшит процесс найма.

Деятельность, развивающая DevRel:

— Участие в open-source проектах

— Публикация исследовательских задач, с которыми вы сталкиваетесь в работе, и их результатов

— Участие с докладами или вопросами в конференциях и митапах

— Участие в хакатонах и интервью

Деятельность PR и DevRel организации невозможна без привлечения компетентных сотрудников. Ваша инициатива и участие — ключ к успеху компании.

Владелец процесса разработки

Принципы построения процессов

При построении процессов необходимо придерживаться следующих принципов:

— Каждый процесс имеет определенную цель, вы должны сформулировать ее четко и ясно

— Превратите цель в последовательную модель входов-выходов

— Не регламентируйте то, где

1 ... 10 11 12 13 14 15 16 17 18 ... 24
Перейти на страницу: