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

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

Шаги эскалации в проектном управлении:

— Проинформировать вышестоящее лицо, имеющее полномочия решить проблему

— Проанализировать причины проблемы и ее потенциальное влияние

— Разработать несколько альтернативных решений проблемы и оценить их достоинства и недостатки

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

— Объяснить последствия несвоевременного решения проблемы

— Задокументировать результаты эскалации и зафиксировать извлеченные уроки

Повседневный контроль задач

Для разных процессов повседневный контроль задач будет отличаться. Так или иначе он сводится к:

— получению сводной информации по прогрессу задач

— выявлению задач, где необходимы управленческие решения

— решению проблем и задач

Что может дать сводную информацию по прогрессу?

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

— Для итерационных процессов применяется диаграмма сгорания

— Для Kanban используется скорость потока задач за вчерашний день, скорость прохождения через каждую из колонок и весь процесс в целом.

— Для ServiceDesk необходима поддержка показателей SLA, а также количество поступивших и решенных задач.

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

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

Автоматизируйте повседневную работу с помощью ботов, которые напомнят сотрудникам о:

— Зависших задачах

— Актуализации статусов, оставшемся времени по задачам и дотировании затраченного времени на задачи

— Текущих метриках спринта, показателях эффективности

Прием результатов

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

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

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

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

Технический лидер

Компетенция в разработке важна для понимания проблем команды, возможности помочь с выполнением задач, а также для контроля выполнения задач.

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

Существует 2 варианта технического надзора в команде:

— Первый — нет технического лидера, команда самостоятельно решает, что и как сделать по каждому виду работ. Возможно использование cross-review.

— Второй — техническим лидером команды является тимлид. Он организовывает процесс технического контроля над результатами отдельных работ и общих итогов.

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

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

За что отвечает технический лидер:

— План будущего использования технологии

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

— Контроль технологических стандартов и регламентов в отдельных частях работ или итоговых результатах

В данном случае роль может включать подроли Владельца и Менеджера процесса управления технологией. Эти подроли могут быть делегированы. Например, тимлид определил стандарты и регламенты, а за счет code cross-review делегировал роль менеджера, контролирующего соблюдение стандартов.

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

Обеспечение наилучших условий труда и инструментов

Выбор инструментов разработки

Под инструментами понимается IDE, средства хранения кода и тест-кейсов, ведения задач, документации, деплоя, коммуникации и, конечно, встречи команды.

Как выбрать инструменты, которыми команда будет пользоваться?

Есть несколько критериев, влияющих на выбор:

— Функциональность и надежность

— Стоимость

— Опыт компании и коллег

— Удобство пользования и знания работы этого инструмента

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

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

Разработка своих собственных инструментов (если речь идет о значительных затратах времени) должна оцениваться бизнесом как длительные вложения.

Автоматизация процесса разработки