Ну что – сегодня пятница, а пятница, как известно, это день, когда начинаются разборки о том «почему опять нифига на сделано?» и «когда, наконец, это закончится?!» Практика показывает, что любые разборки косяков делятся на два извечных вопроса: 1. Кто виноват? 2. Что делать? И на оба надо отвечать, чтобы косяк а) исправить максимально эффективно б) не допускать аналогичного в дальнейшем. Не ответите на первый вопрос – не сможете устранить причину и перейти ко второму. Не решите второй – не будет срока устранения проблемы. То есть ответить надо на оба. Но есть проблема: неопытный менеджер часто попадается в ловушку первого вопроса, где обычно начинается беспощадный срач с перепихиванием вины друг на друга и поиском крайнего, и до второго вопроса часто команда не доходит, потому что на первый потратили 2 часа, все устали и забили. Поэтому некоторые слабовольные менеджеры тактично обходят стороной вопрос 1, чтобы не ранить ничью нежную душу и сразу решают второй. Проблема в том, что, если не анализировать свои ошибки, будешь наступать на одни и те же грабли все время до тех пор, пока не проанализируешь. Метод бегства от проблемы проблему не решает, а лишь усугубляет (кстати, это касается не только АйТи, а любой проблемы вообще). Потому отвечать на вопрос: «Кто виноват?» придется. Но как его решать экологично? Для начала, руководителю надо понять, что он не ищет виновного, на которого он спихнет ответственность (Вася не сделал, а у меня лапки). Ответственность уже на тебе, РПшник. Ты виноват, и это жиза. Ты принимаешь весь удар на себя, но внутри команды надо разобраться, что же случилось, только не в формате «Кто виноват?», а в формате «Как так вышло?» Чувствуете – иная постановка вопроса? Вот с такой постановкой и надо приходить в команду. Далее проводим root-cause analysis: - Если причина частная – чувак косякнул, с кем не бывает – то просто объясняем что надо быть внимательнее (он и сам уже понимает обычно) и предупреждать как можно раньше , а не сидеть в домике, пока петух не клюнет. - Если причина системная (разработка работает без ТЗ, у фронта нет дизайна и тд и тп), то тут вы, как менеджер, должны пробежаться по рискам, которые рождает системная проблема и для себя решить: фиксим проблему сейчас или принимаем риски и страдаем дальше. И тут уже дальше 100% будет ваша ответственность: это ваше решение ничего не делать для устранения системной проблемы. Кстати, есди исполнитель системно косячит с оценками, то его надо или заменить, или просто накидывать время на его оценки сверху. У меня были разработчики, оценку которых я смело умножал на два :) И вот уже после выявления причины, почему мы наступили на грабли, можно перейти к вопросу, что теперь делать с разбитой рожей 😊 Второй вопрос «Что делать?» больше технический, тут надолго останавливаться неохота. Скажу лишь что инструменты РП здесь: показать то, что есть, сдать частично, сказать, что все сделано и доделать за выходные (да, я знаю, врать нехорошо, но если заказчик проверит в понедельник, то можно), и только самое последнее – сдвинуть сроки. Вообще старайтесь двигать сроки вправо только когда вы сделали 3-5 шагов, чтобы их не двигать. А то это двиганье войдет у вас в привычку, а это тупо непрофессионально. Скилл РП не в том, чтобы аккуратно и безвольно двигать сроки, а в том, чтобы биться за изначально данные вами сроки, скоуп и бюджет. Для того и нужна эта профессия. Так что хороших и экологичных вам пятничных разборок и работы в выходные, если таковая намечается))