Горящий ИТ-проект: искореняем дедлайны

Что такое дедлайн в работе IT-специалиста?

Продуктовую разработку нельзя представить без конкуренции — за пользователей, нишу, долю рынка. Чем быстрее компания запускает новые фичи в продукте, тем выше вероятность в этой гонке победить, поэтому задача уменьшения time-to-market стоит перед каждым менеджером, а дедлайны сопровождают каждый проект. Важно не только качество работы, но и умение делать её в срок.

Как дедлайны влияют на IT-проект?

От дедлайна может зависеть, например, объём реализованной функциональности и первоначальный вид продукта. Существует подход к планированию от даты релиза: команда договаривается с бизнесом о примерной дате, когда должен выйти релиз, и от него отсчитывается время на тестирование и оставшийся на разработку период. Зная время, которое есть у команды, можно определить объем функционала для первого релиза. Зачастую быстро выпустить MVP и собрать отклики пользователей важнее, чем реализовать весь объём задуманного.

Как оценить время на проект?

Чтобы определить ёмкость команды — сколько задач она может сделать за итерацию — большие задачи делят на атомарные части и оценивают каждую по аналогии с когда-то уже сделанными.

Популярный способ оценки сложности задач — в единицах работы, так называемых story point’ах. Первые итерации оценивают, опираясь на опыт менеджера или тимлида, а последующие — по статистике выполнения предыдущих по количеству story point’ов.

Важно определить, что мы считаем сделанной задачей, так называемый definition of done. В идеале законченная задача — это функциональность, доставленная до реальных пользователей, но могут быть и другие варианты.

Дедлайны для любого IT-специалиста — важный фактор работы. Информация быстро устаревает, и банальная просрочка задачи может погубить весь труд одного специалиста или целого отдела. Касается это зачастую мелких обновлений или небольших моментов, которые становятся «роковыми». Самое банальное влияние невыполненного дедлайна: потеря клиентов, а соответственно и прибыли.

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

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

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

Стройте свои планы так, чтобы они были выполнимыми и отказоустойчивыми. Это сильно улучшит статистику и общую динамику проекта.

Второй совет касается каждого сотрудника: закладывайте один день запаса на недельную задачу. Если при планировании директор и глава отдела заложат по дню запаса, и сам сотрудник оставит день про запас — это даст драгоценные три дня на случаи форс мажоров. Или три дня на правки и выпуск задачи не в сыром виде, как это частенько случается.

Вот три основных инструмента, которые позволяют искоренить хаос в большинстве задач:

1. Для крупных отделов или компаний могу посоветовать Asana. Это удобный корпоративный планер с подключаемой интеграцией в Slack и удобной настройкой.
2. Для более мелких отделов отлично подойдут небольшие планеры, например Trello, который уже не первый год хорошо показывает себя на рынке.
3. Для личного пользования советую познакомиться с Red Hot Timer, который умеет работать с вашим рабочим временем, напоминая как о перерывах, так и о работе. В целом, это достаточно минималистичный инструмент, который может применять каждый.

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

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

Для контроля времени существует много инструментов, все зависит от предпочтений и размера проекта: Jira, Asana, Trello, Wrike и т. д. Одно из преимуществ таких систем — это возможность создавать отчеты, строить графики и наблюдать показатели производительности в динамике, чтобы корректировать процесс и успеть в срок.

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

Главное — следить за темпом и вовремя давать себе отчет в том, что не успеваешь, и не подгоняя показатели для красивого результата. Чем раньше обозначить проблему, тем легче будет удовлетворить потребности клиента в срок.

IT-специалистам в работе часто приходится сталкиваться с дедлайнами. Дедлайн — это крайний срок выполнения задачи или сдачи проекта, если смотреть более глобально.

Соблюдение дедлайнов крайне важно, так как может повлечь за собой негативные последствия. Обычно в IT-проектах задачи не ходят по одиночке и привязаны к другим задачам. Например, если аналитик данных провалит сроки по разработке дашборда для отдела маркетинга, этот самый отдел маркетинга не сможет вовремя оценить запущенные рекламные активности. А это может повлечь слив рекламного бюджета.

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

Поэтому очень важно оценивать время как на проект в целом, так и на отдельные задачи внутри проекта. Изначально при оценке времени на проект нужно учесть несколько факторов:

1. Загруженность специалистов. Ведь если разработчик уже тратит по 8 часов в день на прочие задачи, вряд ли он сможет взять ещё какие-либо проекты.
2. Возможные болезни, отпуски, форс-мажоры. Если мы оцениваем проект в месяц, то лучше поставить дедлайн через 1,5-2 месяца. Это не значит, что нужно специально затягивать выполнение работ, но такой запас убережёт от возможных форс-мажоров.
3. Наличие необходимых ресурсов.

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

Самый рабочий для меня инструмент, и, пожалуй, самый известный — это матрица Эйзенхауэра. Матрица состоит из четырех квадратов: 1 — важные и срочные задачи, 2 — важные, но не срочные, 3 — не важные, но срочные, 4 — не срочные и не важные.

О том как пользоваться матрицей в работе можно почитать в интернете.

Приложения и онлайн-сервисы, которые облегчают управление временем, и которыми я пользуюсь чаще всего: ПланФикс, Trello, Toggl.

1. Что такое дедлайн в работе ИТ-специалиста?

Дедлайн — это крайний срок, к которому должна быть выполнена работа. Именно на этот срок ориентируется и руководитель, и заказчик, именно к нему исполнители планируют выполнить все оговоренные требования. В IT-сфере продуктом является работающая программа (или программно-аппаратный комплекс), выполняющая запрошенные бизнесом функции, а значит к дедлайну проекта должно быть не только составлено техническое задание и написан код, но и пройдено тестирование, исправлены найденные ошибки, развёрнута вся необходимая инфраструктура сначала на тестовом, а потом и на боевом, доступном конечному пользователю, окружении.

2. Как дедлайны влияют на IT-проект?

Если исполнитель не укладывается в срок, то это может грозить и устареванием требований, и штрафами или прекращением договора, и потерей репутации. Однако в IT много неопределённости, из-за чего требования могут меняться ещё до окончания проекта, что потенциально грозит срывом сроков, работой на износ и выгоранием специалистов. В таком случае очень тяжело верно оценить время на проект: опытные руководители изучают, в какие сроки решались похожие задачи, округляют оценку в пессимистичную сторону и добавляют буферное время (запас на непредвиденные обстоятельства).

3. Как оценить время на IT-проект?

В планировании и разработке помогает гибкий подход к созданию ПО. Весь процесс работы над продуктом разбивается на итерации — промежутки времени по 2-4 недели, в течение которых выполняются все основные этапы от анализа до поставки работающей программы. Таким образом формируются частые мини-дедлайны внутри большого проекта, что помогает руководителю давать более чёткую оценку трудоёмкости и сроков исполнения, командам разработки — сосредоточиться на реализации какой-то части функциональности и не снижать темп работы, а заказчику — быстрее увидеть готовое решение, опробовать его и при необходимости оперативно изменить требования. В результате мы уменьшаем вероятность срыва сроков поставки готового продукта из-за технических проблем, неточных формулировок технического задания и изменений требований.

4. Инструменты для грамотного тайм-менеджмента

Самыми распространёнными инструментами для ведения IT-проекта с применением гибкого подхода сейчас являются доски задач — Atlassian Jira, Azure Boards, Yandex Tracker. Они позволяют прогнозировать сроки выполнения, сравнивать их с реально затраченным временем, чтобы в будущем оценка была точнее, приоритизировать задачи и следить за прогрессом работы над ними, постоянно получая актуальную информацию о состоянии проекта.