Дедлайн — заимствованное слово из американского словаря. Раньше так называли границы пребывания преступников. Если переступить через линию — считай, что провалил правило и сбежал.
Сейчас о дедлайнах говорят в двух значениях. Первое и синоним дедлайна — конкретный срок сдачи проекта, домашнего задания. Второе — что-то страшное, после чего специалист подвел клиента, руководителя и коллег.
Как справляться с дедлайнами и что это означает для специалиста: нужно тушить пожар или время для сдачи работы? Делимся советами в статье.
Важно помнить, что проект всегда идет не по плану
Представим ситуацию: проджект-менеджер компании согласовывает с клиентом разработку мобильного приложения.
Перед встречей менеджер пишет план: нужно сделать все максимально хорошо — разработчики смогут продумать несколько обновлений наперед, установить последнюю версию антивирусного софта.
Довольный менеджер представляет предложение перед клиентом. Тому все нравится.
🔥 Когда дело доходит до выполнения работы, все идет не по плану:
-
Глава отдела кибербезопасности ушел в отпуск. Только он разбирался в проектировании системы безопасности для мобильных приложений.
-
Сделать несколько обновлений наперед — неудачная затея. Еще не было тестирования продукта, а уже собираемся обновлять. А время – деньги.
-
Некоторые разработчики сидят без дела, потому что не получили заданий.
Остается несколько месяцев до сдачи, а проект не готов. Сроки и цену согласовали и подводить клиента очень не хочется: можно лишиться состоятельного клиента, репутации. Но что можно сделать?
👉 Метафора с разработкой мобильного приложения условная. Но отражает реальные примеры дедлайнов в диджитале: руководитель взял проект и не рассчитал сроки, хочется сделать всего побольше или один из сотрудников оттягивает сдачу этапа проекта до последнего дня. В результате сроки затягиваются, компания не успевает, а клиент негодует.
Жить сложнее, чем все расписать на бумаге. Планирование в голове и на бумаге всегда идеально. Но можно неправильно рассчитать стоимость, возможные сроки, неправильно расставить приоритеты.
IT работает не столько с кодом, сколько с людьми. У них тоже свои потребности, тяга к прокрастинации и причины переносить дедлайны.
Дедлайн нужно принять и обсудить
Вернемся к примеру с менеджером. Планирование провалилось и нужно спасать проект. Клиент ждет результат и подтверждение, что деньги не потратили впустую. Одно из возможных решений — показать клиенту проблему.
Если сейчас исправить ничего не получится — лучше рассказать клиенту о ситуации:
Николай Семенович, извините за беспокойство. В отделе разработки произошло ЧП: часть программистов заболела, поэтому не успеваем вовремя сдать проект. Можем ли мы встретиться и обсудить перенос сроков, если это возможно?
Возмутится ли Николай Семенович? — конечно. Человек потратил деньги и время на сотрудничество. Но также для него важно получить проект. Он пойдет на встречу и продлит сроки. Приложение будет, что уже хорошо. Пусть позже, с правками по смете.
Возможно, что Николай Семенович посчитает менеджера безответственным и никогда не обратится в эту IT-компанию. А проджекта уволят за слабый риск-менеджмент.
Вот что в интервью редакции посоветовал основатель Ed-Tech-компании Visotsky Inc Александр Высоцкий:
В этом году команда выпустила IT-платформу по автоматизации инструментов управления. Мы давно мечтали о таком продукте.
Чтобы клиенты могли пользоваться платформой вне офиса, решили сделать мобильное приложение. Здесь появились проблемы: тесты показали много багов. Приложение дорабатывается, тем самым срываем сроки презентации.
Главное для нас — открытая коммуникация с клиентами. Мы открыто признались, что срыв дедлайнов — наша проблема. Клиенты отнеслись к задержке с пониманием. А мы продолжаем работу.
👉 Важно то, стороны прояснили ситуацию: проблема есть и ее готовы исправлять. Если этого не сделать — результат непредсказуем. Могут и в суд подать за срыв условий договора.
Можно презентовать функциональную часть проекта
В диджитал-разработке куча стадий: от планирования до продакшена. Некоторые этапы могут оттягивать презентацию: нужно подкрасить стены, сделать косметические корректировки продукта, подумать над обновлениями, упростить код и т.д.
Если по дедлайну невозможно сделать все, а результат нужен сейчас — сдайте функциональную часть. На примере со мобильным приложением: можно отказаться окончательного дизайна, продуманного до мелочей UX-дизайна. Показать только функциональную часть, чтобы клиент мог покликать на кнопки и почувствовать — приложение работает.
Важное правило дедлайнов:
🔥 Между «сдать идеально» и «сдать вовремя» всегда выбирайте «вовремя».
Разработчики, как и строители: после выпуска продукта вносят правки и переделывают. Нормально перенести косметическую работу, но показать работающий продукт сейчас.
Чтобы показаться в глазах клиента более ответственным, можно рассказать о причинах переносах плана.
Николай Семенович, на совещании заметили, что разработка приложения невозможна по прошлым срокам. Мы перенесли этап повторного тестирования, чтобы сейчас показать вам рабочую архитектуру. Остальное установим, пока объект будет тестироваться нами и фокус-группами.
Клиент доволен, что есть результаты. А менеджер сохранил репутацию и клиента, избавил коллег от стресса от дедлайна. Даже если компания виновата, и 6-месячную работу можно сделать за 6 недель.
Помогите, если человек в команде не справляется с дедлайнами
На одном из этапов менеджер видит: сотрудник одного из отделов зашивается. Двое коллег ушли в отпуск, а начальник отдела заболел. Он не успевает закончить код, потому что ему вовремя не передали макеты. Возможно, поэтому стажеры-разработчики сидят без заданий.
❌ Можно пройти мимо. Это дело конкретного отдела. Как-нибудь успеют, а если нет — оштрафуем.
✅ Или предложить какую-то помощь. Не делать работу за сотрудника, а дать совет или показать инструмент автоматизации. Можно попросить директора перевести часть сотрудников, потому что те сидят без дела и пьют кофе по три часа.
Василий, давай я помогу. Можем подключить наших стажеров. Давай им стандартные задачи, а сам принимайся за работу посложнее.
Главное — не оставаться в стороне. Задача написать код — Василия. Но сдать мобильное приложение нужно в срок и это общее дело.
👉 Может показаться, что совет из мира фантазии. Часто сотрудники или проджект-менеджеры передают задания и ждут результат. «Мои сотрудники — взрослые люди со своими обязанностями. Если у них что-то не получается, то придут и попросят помощи». Но так никогда не будет: страшно, стыдно и все на словах самостоятельные.
Вот что советует основатель Ed-Tech-компании Visotsky Inc Александр Высоцкий:
Чтобы держать коллег «на крючке», у хорошего руководителя есть инструменты: например — ежедневные созвоны с командой. На созвонах важно не только спрашивать о состоянии задач, но и интересоваться внутренним состоянием сотрудника.
Иногда стоит снять с коллеги рутинные задачи, а оставить работу на проектами. Важно поддерживать и мотивировать, чтобы сотрудник чувствовал важность своей работы: это не только деньги, но и взаимоотношения.
Бежать и спасать не нужно. Достаточно спросить: на каком этапе находится проект сотрудника, что можно презентовать и с какими проблемами столкнулись. Еще лучше — подсказать, как решить неурядицу.
Дедлайн — это нормальная практика. Его нужно не бояться, а продумывать заранее
Перенесемся на встречу менеджера и заказчика.
❌ Менеджер понимает, что компания может сдать проект за 3 месяца. Так и передаст клиенту: без учета возможных проблем, ЧП и того, что приложение строится на новом языке программирования, а разработчики не успели его досконально изучить.
✅ В другой реальности менеджер помнит про 3 месяца. Но понимает, что часто все идет не по плану. Клиента расстраивать нельзя: это большая ответственность и деньги. Вместо 3 месяцев менеджер предложит проект за 5 месяцев. Клиент соглашается.
Человек во втором примере подготовил площадку для решения проблем. А если время останется, можно сделать косметические правки. Или презентовать проект раньше, от чего клиент будет в восторге. Еще и поделится хорошим отзывом.
Часто такие решения приходят не в момент согласования сроков. Нужно подумать час, два, а то и день.
Вот что советует Head of Software Engineering Данило Толмачов:
Хорошему инженеру не важно, откуда появился дедлайн: поставил руководитель или это прихоть клиента. Лучше всегда брать дополнительное время и глубоко оценить задание.
Вы никого не обидите и не расстроите, если перенесете согласование дедлайнов. Часто это показывает профессионализм: специалист не несется делать работу, а грамотно подходит к решению задачи.
Еще тайм-аут помогает определить: что реально сделать к сроку, а что лучше перенести. Можно расставить приоритеты и рассказать руководству, коллегам. Это тоже показывает человека, как профессионала.
С дедлайнами в работе и учебе всегда можно справиться. Лучше — принимать и обсуждать проблему. Или ставить дедлайны с запасом, если сноровка и опыт дают маневрировать. Например, люди делают сайты за неделю, а специалист — за 5 дней. Можно поставить ту же неделю и сдать раньше.
Если хотите получить профессию в IT и грамотно распределять рабочее время, контролировать дедлайны — записывайтесь на курсы IT STEP.
