Часть 1.
Продолжаем отвечать на вопросы.
Бывает, что сотрудник затягивает сроки, проваливает проекты, а потом говорит:
Тут смежники задачу вовремя не сдали. А здесь – в библиотеке баг нашёлся, я его две недели дебажил. А потом у меня похмелье было. Затем – ноутбук в озеро уронил. А после – дизайнера автобус сбил. Так что мне не лещ, а орден мужества полагается. Скажи спасибо, что я живым выбрался!
Cоветую прозрачно сказать сотруднику, что его работа – не просто написать свою часть кода. Его работа – это:
a. Писать свою часть кода
b. Поддерживать у заказчиков актуальную информацию о времени сходимости
c. Сделать всё возможное, чтобы код оказался в продакшене
d. Если внешние обстоятельства мешают пункту (c), настойчиво потыкать в них палочкой. Если не действует – звать на помощь руководителя, чтобы он помог пробить стену
Пункт (а) – cамый простой.
(b) – сложнее. Надо ежедневно проверять, уверен ли ты, что задача доедет в срок. Если нет, стоит сразу поговорить со стейкхолдерами.
Здесь важно донести, что продолб сроков, озвученный за день до дедлайна – это косяк. Продолб сроков, озвученный за две недели – не косяк, а нормальная работа в условиях изменяющегося мира.
Пункты (c) и (d) обязательно объяснять на примерах. Для этого нужно вместе с инженером рассмотреть несколько свежих кейсов и показать, как можно было поступить:
1. Здесь – стоило прийти и попинать Петю, напомнить ему про дедлайн и вашу договорённость. Не сработало – эскалируешь в меня
2. Тут, как только ты понял, что библиотека не работает, стоило остановиться, часик потратить на описание вариантов выхода из ситуации и альтернатив, и в тот же день прийти со мной об этом поговорить
3. Здесь – можно было написать дизайнеру. Не помогло – эскалируешь
Разобрав примеры, договорись с человеком поменять подход к работе и обсудить новые проблемы на следующей встрече.
Иногда – человек окажет сопротивление и договариваться об этом не захочет.
Значит, надо разбираться в причинах.