Как разработчик программного обеспечения и руководитель группы, я сталкивался с бесчисленным количеством ситуаций, когда были установлены нереальные сроки, и я должен был направить свою команду к успешной реализации. Иногда крайний срок устанавливается руководством без реального понимания проекта. Иногда отставание увеличивается медленно и становится невыполнимым. Или иногда команда просто не работает так, как ожидалось.
Какие бы причины ни были, вы как тимлид или менеджер по доставке должны найти выход из этого. Если вы делаете доставку для клиента (как это обычно было в моем случае), это еще сложнее.
Последствия пропущенного срока могут быть: финансовый штраф, потеря репутации или досрочное расторжение контракта. Какие бы последствия это ни имело, вы часто мотивированы избегать этого по любой причине.
Этот список начинается с лучших советов, как это сделать, и заканчивается действиями, граничащими с довольно сомнительной практикой.
- Прозрачен для клиента
Открыто говорите, что можно и чего нельзя делать. Подготовьте возможные сценарии, чего можно добиться с помощью разных подходов. Запишите эти сценарии! Расскажите о блокировщиках и о том, как, по вашему мнению, их можно удалить. Запишите их! На этом этапе важно, чтобы у вас было хорошее представление о незавершенной работе.
В (идеальном) гибком мире вы должны иметь возможность отложить крайний срок, если у вас есть приемлемое обоснование.
Постоянно предоставлять обновления сообщить клиенту о ситуации, чтобы в конце концов это не стало неожиданностью. Объясните причины, почему что-то движется медленнее или почему вы закончили другие задачи быстрее. Будьте последовательны и прозрачны! - Descope
По моему опыту, в глазах клиента все имеет наивысший приоритет. На самом деле разработка требует времени, и обычно невозможно выполнить каждое детальное пожелание.
Клиент или владелец продукта должен расставить приоритеты, что «должно быть» и что «приятно иметь». Затем ваша задача объяснить, что некоторые части «приятно иметь» не будут частью этого релиза, но могут быть включены в следующий.
Вы можете добавлять общие оценки (например, с размерами футболок) и четко показывать, где проходит грань того, что можно и чего нельзя делать. Например. «Мы можем выпустить 2 истории XL или 4 L до релиза». Клиент будет иметь лучшее представление о том, какие есть варианты и что он может выбрать. Будьте предельно ясны: это оценки, а не обязательства! - Мотивируйте свою команду
Будьте лидером и будьте честными со своей командой. Опишите текущую ситуацию и объясните членам вашей команды вашу общую цель и то, чего вы хотите достичь. Нарисуйте путь в их сознании. Будьте честны и покажите, каковы основные причины сложившейся ситуации. Выслушайте их опасения! Если вы будете жаловаться все вместе, это намного лучше, чем они будут жаловаться за вашей спиной.
Пусть придумают решения, как можно ускорить доставку. Если идеи будут возникать внутри команды, это поможет установить приверженность реализации этих идей. - MVP
Мне очень нравится концепция минимально жизнеспособного продукта. Давайте сделаем это быстро и неидеально, и мы увидим, что работает, а что нет, и сможем строить и адаптировать на основе реального опыта, а не собственных убеждений.
Вы можете убедить клиента, что некоторые модули или функции будут разработан как можно проще с минимальной функциональностью или просто с базовым дизайном.
Клиенту нужна сложная интерактивная многоступенчатая форма? Хорошо, но на данном этапе это будет просто форма, которая по-прежнему будет выполнять свою работу, и мы сможем улучшить ее позже. Клиент хочет тщательно продуманное управление запасами интернет-магазина с множественными интеграциями? Хорошо, давайте начнем с простого стандартного функционала. Это потребует больше ручных усилий от администратора интернет-магазина, но сработает. Затем мы можем собрать информацию о самых больших болевых точках и поработать над ними позже. - Найдите ограничения ваших процессов
Это то, что нужно делать постоянно, а не только в том случае, если вы не укладываетесь в сроки. В схватке ретроспектива должна использоваться для сбора пожеланий вашей команды. Может быть, кто-то работает над задачами, которые ему не нравятся, или кому-то не хватает знаний, что замедляет работу. Существует действительно широкий спектр небольших, но также и радикальных подходов, которые вы можете использовать.
Вы знаете свой проект лучше всех. Думать! Но также спросите свою команду, что вы можете сделать, чтобы облегчить их жизнь и ускорить процесс. - Отложить тесты и документацию
Я действительно имею в виду отложить, а не пропустить! Тесты и документация важны. Здесь нет обсуждения. Но в ситуации приближающегося дедлайна может иметь смысл отложить их после дедлайна. По своему опыту я всегда пытался навязать некоторые практики в отношении тестов или документации. Мы использовали автоматические проверки покрытия кода тестами (юнит-тестами и/или интеграционными тестами), сканерами качества кода, линтингом и без этой пройденной проверки завершить вашу задачу было невозможно. Также была проверка на наличие новой записи в CHANGELOG или ручная проверка во время проверки кода, чтобы была предоставлена надлежащая документация.
В некоторых ситуациях может быть целесообразно пропустить один неудачный тест для большего блага принятия срока. Следите за всем техническим отделом. Если возможно, будьте прозрачны в этом. - Привлечь больше людей
Сложно, очень сложно! При запуске нового проекта есть кривая обучения, поэтому на самом деле вы можете терять время, поскольку адаптация новых людей не набирает большей скорости. Вы должны подумать, смогут ли дополнительные люди достаточно быстро войти в продуктивный темп и действительно помочь вам в ваших начинаниях или замедлить вас.
Подумайте, что и кто необходим для достижения успеха. Возможно, другим членам команды можно было бы передать лишь некоторые конкретные задачи (например, ручное тестирование, подготовка данных, написание тестов). - Попросите о добровольной сверхурочной работе
Некоторые люди не возражают против сверхурочной работы. Особенно когда за них доплачивают. Сверхурочные могут сработать в краткосрочной перспективе. Я имею в виду пару недель. Если люди интенсивно работают сверхурочно в течение более длительного времени, положительный эффект теряется, и вы можете нанести серьезный ущерб своей команде, а также здоровью и балансу между жизнью и работой отдельных людей. - Снижайте качество кода
Если у вас действительно нет времени, вы можете пропустить проверки качества, такие как просмотр кода, и просто закончить задачи как можно скорее. Не теряйте время с идеальной структурой кода, чистыми шаблонами проектирования и удобочитаемым кодом. Просто заставьте его работать и проведите рефакторинг после дедлайна.
Я уверен, что вы забудете, где находятся эти качественные черные дыры. Размещайте комментарии TODO в коде, чтобы их можно было легко найти позже. - Принуждать к сверхурочным работам и сокращать отпуска
Ненавижу это! Я никогда не использовал его, и я очень надеюсь, что никогда не буду. Я видел, как менеджеры отменяли отпуска и просили сверхурочные, и я ненавижу это всем сердцем. На мой взгляд, в экстремальных ситуациях можно выпросить, но лично я заставлять не стал бы. - Передайте ошибочный код
Ошибки всегда будут присутствовать в коде. Конечно, мы пытаемся искоренить большинство из них на ранних стадиях. В ситуации, когда вы должны сдать продукт вовремя, вы можете закрыть глаза на известные ошибки и проблемы. Опять же, это временное решение. По крайней мере, документируйте в своих личных заметках, чтобы вы могли вернуться к этим вопросам позже, когда истечет крайний срок. - Соберите доказательства того, что пропущенный срок не является вашей ошибкой
Даже при всех ваших усилиях вы пропустили крайний срок. С некоторыми клиентами это может означать «игру с обвинением».
Будьте мудры на протяжении всего процесса. Сбор электронных писем и других доказательств. Вы ждали фотографии от клиента на две недели дольше? Напишите его в электронной почте в то время и сохраните его. Вы уже три месяца указываете на то, что ваша команда недоукомплектована? Не просто говорите об этом во время телефонного разговора или встречи, напишите это и по электронной почте! Никто не запомнит, что вы сказали, но вы всегда можете найти это в своем почтовом ящике.
Вот несколько советов, начиная от отличных и заканчивая спорными примерами.
Управление доставкой может быть сложным делом, особенно с негибкими подходами и практиками. Ключевой принцип для меня — быть как можно более информированным и четко и регулярно сообщать эту информацию всем сторонам. Сообщайте о преимуществах, но также и о недостатках, чтобы никто не удивился, когда возникнет какая-то проблема.
И они появятся.
Я желаю, чтобы они не появились на вашем проекте. Но если они это сделают, вы будете готовы!
