Все идет по плану, пока не наступает время правок
Дальние расстояния для совместной работы давно уже не помеха. Skype, Google Docs и другие инструменты позволяют связываться друг с другом из любой точки мира. Распределенная работа еще никогда не была так удобна. И все хорошо, пока дело не доходит до правок. Да, до самых обычных правок по тексту или дизайну.
И это не имеет никакого отношения к коммуникациям. Написать в Slack просьбу поправить текст или поработать с цветом логотипа легко. Суть как раз в другом. Представьте себе ситуацию, когда дизайнеру нужно изменить положение блока на макете. Вы даете ему задание «сдвинуть блок на 10 px вверх». Через некоторое время, может быть, через 12 часов, если вы в Москве, а дизайнер на Бали, вы получаете решение. Но вам не нравится. Вы пишите, «а давай еще немного направо». Снова проходит 12 часов. И так далее.
А теперь представьте ту же ситуацию, только в офисе. Вы подходите дизайнеру и облокотясь на его кресло, пальцем показываете на экране монитора: «Вот, давай чуть повыше, так, а теперь левее, еще чуть-чуть. Цвет приглуши. Вот, так хорошо». Сколько займет времени такая правка? От силы 5 минут.
Неслучайно говорят, что к заявленному времени разработки проекта всегда надо прибавлять столько же, а лучше – в три раза больше. Договорились сделать за 3 дня, значит, будет сделано за 9 дней. 3 месяца разработки в реальности займут 9 месяцев. Год – возможно, что проект никогда не стартует.
Каким может быть решение проблемы «пинга»
Надежного решения пока нет. Но можно попытаться, в соответствии с правилом Парето 20/80, снизить «пинг» до приемлемых 20% времени решения проблемы. В первую очередь, нужно обратить внимание на ТЗ и ПЗ. С аббревиатурой ТЗ (техническое задание) знакомы все. А вот с ПЗ ситуация гораздо хуже. ПЗ – это «понимание задачи», которое должен прислать исполнитель в ответ на получение ТЗ. Часто заказчик считает, что его мозг можно «телепортировать» в голову другого человека. Достаточно написать «сделайте дизайн в стиле Маяковского» и противоположная сторона сразу понимает, о чем идет речь.
И тут на первый план выходит такое понятие, как КК (культурный код). Он у всех разный. 20-летний дизайнер-исполнитель и 40-летний заказчик вряд поймут другу друга и наоборот. Может быть, дизайнер видел Маяковского только в мемасиках или демотиваторах, а заказчик имел ввиду плакаты времен НЭПа.
Поэтому ПЗ является крайне важным документом. Правильное понимание задачи исполнителем позволяет значительно снизить количество правок в будущем.
Хорошо помогает и указание референсов. Правда, есть опасность слишком буквального понимания референсов и как следствие – копирования разной степени точности. Но в любом случае с референсами лучше, чем без них. По крайней мере, у вас будет одинаковый визуальный язык, а уж как на нем «разговаривать», выясниться в процессе работы.
Помимо нюансов с ТЗ, ПЗ и КК, другие способы сокращения времени «пинга» более прикладные.
Доделывать самому
Приводить текст или дизайн в финальное состояние силами офисной команды. Не люблю так делать, но иногда проще все решить самому, чем погружаться в море правок, понимая, что на это уйдет несколько дней. Однажды я написал огромное ТЗ по правкам, на которое у меня ушло около 2 часов по времени. И только в конце осознал, что все, о чем я пишу, я могу сделать сам за 15-20 минут. С управленческой точки зрения это полный провал, ведь главное правило управления гласит – все, что можно делегировать, надо делегировать. Но с точки зрения сдачи проекта в срок приходится отодвигать «лишние» звенья и делать самим.
Делать в режиме реального времени
Садишься перед монитором и удаленно «водишь» рукой дизайнера.
Быстрый и простой вариант, когда дизайнер может показать правки через соцсеть или мессенджер. Важно научиться выделять время на такую работу. А то можно потратить недели на согласование встречи онлайн.
Доверять исполнителям и не делать правки совсем
Возможно, это лучшее решение проблемы. Но в этом случае надо нанимать действительно сильных исполнителей и доверять им. Работа без правок – это, конечно, фантастика. Но, с другой стороны, разве правки не на 80% зависят от неправильного или ленивого составления ТЗ? Иногда бывает так, что перебрав кучу вариантов, в итоге возвращаешься к первому. Вопрос самому себе – зачем было затевать эпопею с правками?
Резюме
Я постоянный участник конкурса «Наступи на грабли». Мой лоб светится ярким синим цветом почти в каждом проекте. Таковы реалии работы распределенных команд. Даже самые надежные исполнители порой выкидывают невообразимые фортеля. И все же мне удалось довести количество времени, потраченного на правки, до приемлемых 20%.
