Вот почему ваша внешняя команда дизайнеров не справляется с поставленными задачами

Пропущенные сроки - это чума команд разработчиков продуктов и, будем честны, большинства других команд и людей. Эта проблема старше, чем управление продуктом, и старше, чем само слово "дедлайн". <\/p>\r\n\r\n

Что не так со сроками?<\/h2>\r\n\r\n

Мы всегда с презрением относились к термину "дедлайн". Не только потому, что дедлайны вносят в нашу жизнь постоянное давление. Дело в ненужном драматизме, который они вносят в рабочий процесс. В самом деле, никто не умрет, если статья не будет опубликована до конца месяца. И работа дизайнеров тоже не имеет такого уж большого значения для жизни и смерти.<\/p>\r\n\r\n

Мы никогда не знаем, сколько итераций нам понадобится для достижения наилучшего результата. Когда сроки поджимают, велика вероятность того, что тестирование будет пропущено, а окончательный вариант окажется не лучшим, а наиболее близким к сроку.<\/p>\r\n\r\n

Это не означает, что дизайнеры не знают, сколько времени займет их работа. Для небольших задач, таких как "сделать экраны для потока регистрации", оценка времени в рамках жизненного цикла разработки ПО просто необходима. Но если мы реалистичны и принимаем тот факт, что первая версия нашего дизайна будет не самой лучшей, мы должны дать себе больше времени и объяснить клиентам, что сроки могут повредить качеству дизайна.<\/p>\r\n\r\n

Именно поэтому мы работаем по модели предоплаты: мы не рискуем назвать точный срок, а затем ухудшить качество из-за нехватки времени на итерации.  Мы работаем с клиентами, которые понимают, что хороший дизайн - это длительный процесс, поэтому наша модель ценообразования похожа на подписку: вы всегда можете отписаться, если почувствуете, что она не приносит вам пользы. И мы с удовольствием отмечаем, что люди продолжают подписку до тех пор, пока это необходимо для достижения наилучшей версии дизайна.<\/p>\r\n\r\n

Что не так с традиционными решениями?<\/h2>\r\n\r\n

Вы когда-нибудь ждали несколько часов, чтобы попасть к врачу с какой-то странной болезнью, а в итоге получили ибупрофен? Ибупрофен снимает симптомы, но не лечит причину болезни.<\/p>\r\n\r\n

В нашем случае симптом - это пропущенные сроки. Что типично для ибупрофена и парацетамола у менеджеров по продукту? Наем новых членов команды, изменение организационной структуры проектной группы, увеличение сроков, уменьшение объема работ и т.д.<\/p>\r\n\r\n

В чем же истинная причина? Не хочу быть тем телевизионным доктором, который ставит диагнозы на расстоянии, но позвольте рассказать об одной общей причине: подходе к взаимодействию с внешними командами. Как его оптимизировать, чтобы вылечить срывы сроков?<\/p>\r\n\r\n

Изменение подхода к руководству<\/h2>\r\n\r\n

Иногда вы приходите к врачу за сильными таблетками, которые бы вас вылечили, а вместо этого вам говорят, что вы должны ежедневно делать зарядку по 30 минут и правильно питаться. Это хорошее и комплексное лечение, но оно может и разочаровать.<\/p>\r\n\r\n

Изменение подхода к руководству - это схожий вид лечения. Оно требует постоянных усилий, но взамен приносит больше результатов в долгосрочной перспективе. Какой бы ни была структура вашей проектной группы, в ней есть владелец продукта, который должен взять на себя определенный уровень лидерства.<\/p>\r\n\r\n

Мы предлагаем вам сосредоточиться на таких полезных привычках, как правильное общение. Это обмен информацией с командой, учет мнения каждого при принятии решений, оценка инициатив команды разработчиков программного обеспечения, получение и предоставление хорошей обратной связи. Все это будет способствовать формированию культуры диалога, которая сделает вашу команду более функциональной.<\/p>\r\n\r\n

<\/p>\r\n\r\n

Объясните важность сроков<\/h2>\r\n\r\n

Команда разработчиков - это детский сад, и все знают, что опаздывать плохо. Но быть взрослым означает также, что вы, скорее всего, пропустили несколько дедлайнов в своей жизни и знаете, что от этого никто не умирает. Поэтому люди могут сделать это еще раз.<\/p>\r\n\r\n

Чтобы решить эту проблему, руководитель группы должен давать достаточно информации, чтобы команда понимала, что зависит от ее работы.<\/p>\r\n\r\n

Дизайнеры могут не спешить заканчивать экраны, если знают, что разработчики смогут приступить к реализации только через месяц. Напротив, когда вы объясняете, что раунд тестирования запланирован на следующий месяц, необходимость уложиться в срок становится очевидной.<\/p>\r\n\r\n

Когда внешняя команда разработчиков программного обеспечения не знает о ваших внутренних процессах, они могут не понимать, что их работа является частью текущего проекта. Вы должны дать им понять, что срок сдачи проекта зависит не только от них: люди склонны проявлять больше ответственности, когда речь идет о большем количестве сторон.<\/p>\r\n\r\n

Поделитесь стратегией и целями продукта<\/h2>\r\n\r\n

Часто наши клиенты обращаются к нам за редизайном и ставят жесткие временные рамки. Мы знаем, что для правильного редизайна требуется гораздо больше времени. Кроме того, мы знаем, что редизайн - это средство, а не цель, поэтому мы фокусируемся на реальной цели. Улучшить юзабилити? Или облегчение процесса внедрения? Исходя из этого, мы можем искать решения, которые приблизят нас к цели без необходимости переделывать весь продукт.<\/p>\r\n\r\n

Вести открытый диалог<\/h2>\r\n\r\n

Это еще один способ сделать дедлайн менее "смертельным". Иногда бывают моменты, когда люди оказываются перед выбором: либо признать, что им нужно больше времени на выполнение задачи, либо выполнить ее любой ценой, поступившись качеством и условиями работы.<\/p>\r\n\r\n

В продуктах с высоким уровнем доверия между руководством и членами команды люди испытывают меньшее давление и не боятся сказать, что не могут уложиться в срок, а в идеале - принять участие в планировании и с самого начала сделать временные рамки более реалистичными.<\/p>\r\n\r\n

Проще говоря, труднее сорвать сроки, когда их устанавливаешь именно ты.<\/p>\r\n\r\n

Поймите потребности своей команды<\/h2>\r\n\r\n

Прежде всего, полезно воспринимать внешнюю команду как часть своей команды. Если вы работаете с агентством, которое должно выполнить весь проект за один раз, это отличается от наличия внешней команды, с которой вы можете регулярно контактировать.<\/p>\r\n\r\n

В начале сотрудничества внешние дизайнеры должны спрашивать о многом. Естественно, вы не захотите делиться со сторонней командой дизайнеров всеми своими документами, но чем больше вы сможете предоставить, тем меньше они попросят впоследствии. Обязательно включите этот вопрос в стандартный процесс подготовки внешней команды.<\/p>\r\n\r\n

Следующие шаги?<\/h2>\r\n\r\n

Решение проблемы сроков - это марафон, а не забег на короткую дистанцию. Вы должны подготовиться и быть готовыми изменить привычки общения, процесс работы проектной группы или что-либо еще. <\/p>\r\n