В любой IT-компании, где жизнь бурлит, кофе льётся рекой, а задачи множатся каждый день, наступает момент, когда всё идёт не по плану. Мы в PRAI называем это «срыв дедлайна». Некоторые используют другую терминологию, но нас читают дети, поэтому остановимся на этом варианте.

И вот мы стоим с календарем в руках, уставившись на дату, которая уже вчера, и думаем — что делать?

В нашей компании такое случается крайне редко, но, когда всё-таки случается, мы спокойны и не паникуем. Практикуем дзен и инженерный подход. А ещё — разговариваем с людьми, верим в силу человеческого потенциала и четкого KPI.

Во-первых, мы не хватаемся за ножи и пистолеты. И даже не высылаем гневный мем в корпоративный чат. Мы делаем то, что давно доказало свою эффективность: выясняем причину. Ведь нам важно не наказать виновных, а сделать так, чтобы срывы не повторялись, и команда работала чётко и слаженно.

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

Вариант первый: менеджер — человек, а не ясновидящий

Да, у нас отличные менеджеры. Но даже они иногда могут немного недооценить сложность задачи.

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

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

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

Вариант второй: разработчик запнулся

Кажется, всё шло нормально. Бэк готов, фронт почти, API подключили, UI сверстали. И вдруг — тишина. Разработчик либо в раздумьях, либо в депрессии, либо мониторит интернет в попытке найти решение для сложной задачи.

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

Вариант третий: «Я не знаю, у меня лапки»

Если даже с моральной поддержкой и профессиональной помощью человек продолжает смотреть в пустоту и говорить, что ещё чуть-чуть, пора принимать кардинальные меры.

Задача передаётся другому разработчику. Да, звучит жёстко. Но в IT нельзя превращать сроки сдачи в предмет философских дискуссий. Мы уважаем талант, но в проекте важна предсказуемость. Главное — мы не бросаем тех, у кого не получилось. Мы просто перераспределяем задачи, а потом снова обучаем, подсказываем и мотивируем. Но тогда, когда на это есть время, а не ценой срыва сроков и контракта. 

Потому что у нас в PRAI — уникальная система подсчёта KPI. Не просто баллы за задачи, а живой механизм, который мотивирует выполнять задачи вовремя и брать новые. Система разрабатывалась не один месяц и в ней мы учли все возможные нюансы. Это почти геймификация, только вместо очков — бонусы, признание и ощущение, что ты не просто пишешь код, а участвуешь в большом и крутом деле.

У нас каждый знает, зачем он работает. И что его вклад важен. А ещё — что в случае затруднений мы всегда придем  на помощь.

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

Мы не просто пишем код по ТЗ, мы создаём продукты, которые работают. И да, мы делаем это в срок. Обращайтесь, ваш проект будет готов вовремя.