На сложных проектах проблемы разнообразны: то нет ресурсов, то сорвали сроки, то появились непредвиденные обстоятельства. Но если присмотреться внимательнее, проблема всегда одна — люди. Точнее их ожидания.
Корень всех зол
Проблема возникает тогда, когда ожидания расходятся с реальностью. Ожидали товар через неделю, а его привезли через месяц. Думали, что сайт обойдется за сто тысяч, а он обошелся за миллион. Мечтали о красивом дизайне, а дизайн не впечатлил. Старались, делали отчет, а начальник отчет раскритиковал. Во всех случаях происходит одно и тоже. Ожидания не оправдываются, и стороны оказываются к этому не готовы — в результате конфликты, проблемы и разборки. Возникает логичный вопрос: как реализовать сложный проект без проблем и конфликтов?
Ответ состоит из двух частей. Во-первых, надо нанимать людей, у которых руки растут не из задницы и которые в принципе способны выдать требуемый результат. Во-вторых, надо тщательно выстроить коммуникацию между всеми участниками проекта. Если “во-первых” понятно, то “во-вторых” часто недооценивают, поэтому поговорим про важность коммуникации и формирование ожиданий.
Управляй мечтой
У меня есть мечта — управлять проектами без слез и боли. Это получается, когда картинка в моей голове и в голове исполнителя синхронизирована. Я жду дизайн к такому-то числу и исполнитель знает, что я жду дизайн к такому-то числу. Если возникают какие-то трудности, исполнитель не прячется под стол, а заранее сообщает, что возникли такие-то трудности, по таким-то причинам и он собирается сделать с ними то-то и то-то. Если от меня нужна какая-то помощь, будь то решение, дополнительная информация или ресурсы, он говорит мне, как только ощущает в этом потребность (а не через неделю или месяц).
Я же, если выступаю в роли руководителя проекта и отвечаю за результат перед конечным заказчиком, тоже не прячусь под стол, а информирую заказчика об изменениях и предлагаю варианты решений. Совместно, мы выбираем самое оптимальное: отказываемся от каких-то функций, увеличиваем сроки или выделяем дополнительные ресурсы. Эта идиллическая картина не всегда достижима на практике. Одна из причин — участники проекта недооценивают важность общения.
Ошибки коммуникации
Поговорим о самых распространенных убеждениях, которые мешают организовать эффективную командную работу.
“Зачем ему сейчас об этом знать?!” Когда мы запускали свой первый сайт, я рассуждал так: сначала напишем тексты, потом сделаем дизайн, потом закатаем в веб и только потом позовем сеошников. Не надо им присутствовать при старте проекта. Это была ошибка. Когда пришла пора разбираться с seo, выяснилось, что не учтен целый ряд моментов на уровне разработки: у сайта не та структура, не те адреса, не там использован h1 и т.д. В результате потребовались переделки, которых можно было избежать. Поэтому лучше с самого начала выяснить у всех причастных на каком этапе их следует подключить к проекту: на этапе обсуждения идеи, прототипирования или дизайна, а не решать за людей, что им важно знать, а что нет.
“Зачем рассказывать о том, что мы сейчас делаем? Мы ведь от этого быстрее работать не станем, наоборот, потратим время на идиотские отчеты”. Часто бывает, что исполнитель делает работу, результаты которой нельзя показать. Кодят сайт программисты, исследователи берут интервью, маркетинг-стратегии рисуют интеллект-карты и лепят стикеры на доску. Время идет, результатов нет и заказчик начинает нервничать: “Чем все заняты? Что происходит?” Мудрый исполнитель всегда информирует заказчика о состоянии проекта. Это может быть телефонный звонок, две строчки в Скайпе или полноценный еженедельный/ежемесячный отчет — формат неважен. Важно, чтобы заказчик был осведомлен о том, что происходит с проектом и у него возникала иллюзия контроля над ситуацией.
“Нельзя показать дизайн, пока он не будет полностью закончен. Заказчик ничего не поймет и скажет: “Что это за ерунда? Что вы тут вообще делаете?” Еще одно вредное убеждение, которое я обычно встречал у дизайнеров. Действительно, поиск решения порой сводится к перебору вариантов: это не подходит, это тоже не подходит и это тоже — процесс может затянуться на несколько дней, а показать как будто нечего. Однако именно этот процесс и важно показать заказчику. Какие варианты рассмотрели и по каким причинам их отвергли. Это существенно уменьшит риск при приемке окончательного макета, ведь когда дизайнеры покажут выстраданный результат, не факт еще, что он понравится заказчику.
Если же с самого начала посвящать заказчика в процесс создания дизайна, показывать как идет работа и объяснять, почему получилось то, что получилось, то шансы на одобрение существенно возрастают. Во-первых, заказчик чувствует себя соавтором проекта, он совместно с дизайнером отвергает или одобряет промежуточные находки. Во-вторых, если дизайнера в процессе работы занесет не туда, у заказчика будет шанс его скорректировать — так команда не потеряет зря время, воплощая заведомо неудачное решение. Все сказанное выше относится к любой, а не только дизайнерской работе.
“Не будем ничего прояснять, сделаем точно как в техзадании и точка”. Бывает так, что подрядчик получает техзадание, которое его смущает. Он мог бы предложить более дешевое и быстрое решение. Или ему кажется, что какой-то функционал не слишком важен с точки зрения пользы для бизнеса, зато его реализация влетит в копеечку. Однако вместо того, чтобы прояснить свои сомнения у заказчика, он думает: “Мне написали сделать так, я сделаю так. Любой каприз за ваши деньги”.
Может показаться, что исполнитель упрощает себе жизнь, но в перспективе он ее себе усложняет. Когда заказчик увидит сметы или случайно узнает, что было другое, более удачное решение, у него появятся вопросы: “А почему же вы не сказали, что можно иначе?” И хотя у исполнителя будет формальная отговорка: “Вы же сами написали в техзадании, делать так”, для заказчика она вряд ли прозвучит убедительно.
“Нельзя говорить о проблемах заказчику. Мы все должны исправить сами, чтобы никто не заметил”. Есть проблемы, которые команда должна и может решать сама — это проблемы, с которыми понятно что делать и есть ресурсы для их решения. Однако если эти проблемы приводят к задержке проекта о них важно и нужно информировать заказчика. Другая категория проблем требует вмешательства заказчика, и замалчивать их просто преступно. Это ситуации, когда вскрывается дополнительный объем работ, либо команда оказывается на распутье, и непонятно какой путь предпочесть.
Это ситуации, связанные с нехваткой информации, которую самостоятельно команда получить не может. Это ситуации форс-мажора, когда половину команды похитили инопланетяне. Во всех этих случаях надо ставить заказчика в известность и решать проблемы совместно.
“Все вопросы надо решать через руководителя проекта”. На мой взгляд, это убеждение сильно замедляет проект и добавляет геморроя всем причастным. Правильнее с самого начала определить зоны ответственности. Вот эти вопросы исполнители решают друг с другом, а вот для решения этих обращаются к руководителю проекта. Например, дизайнеры могут самостоятельно выкатить правки к дизайну по результатам верстки. Другое дело, если исполнители разошлись во мнении и не могут достичь согласия, тут надо привлекать руководителя проекта.
Как выстроить эффективное общение?
Первое. Задача руководителя проекта создать комфортную и безопасную среду для всех участников проекта. В конце концов, люди не задают вопросы и замалчивают проблемы, потому что боятся, что им прилетит по башке. Поэтому очень важно донести мысль, что открытость и честность приветствуются (и поощрять их на деле), а вот попытка скрыть трудности, наоборот, карается.
Второе. Распределить зоны ответственности между членами команды. Это, в частности, означает, что когда исполнитель принимает задачу, в зоне его ответственности прояснить все вопросы и предложить наилучшее решение, а не просто формально отработать ТЗ. Здесь же важно определить, какие вопросы исполнители будут решать между собой, а для каких призывать руководителя проекта.
Третье. Эффективная коммуникация предполагает прозрачные правила взаимодействия, поэтому важно договориться о правилах общения. Например, уведомлять друг друга о получении писем. Вести переписку в системе управления проектами (wrike, basecamp и т.д). Согласовывать делайны по промежуточным задачам. И т.д.
Проект без сюрпризов
Когда правила общения соблюдаются, то половина проблем исчезает сама собой. Чтобы убить второю половину, надо регулярно сообщать руководителю проекта/заказчику, как обстоят дела с проектом. Внутри команды это может быть реализовано в виде регулярных встреч или переписки в системе управления проектом. Для заказчика в виде регулярного отчета или презентации. Такие контрольные точки важны как заказчику, так и исполнителю. Заказчик видит, что работа движется, исполнитель же получает ценную обратную связь. Это позволяет выявлять ошибки по ходу дела и исправить без серьезных переделок проекта.
При таком подходе заказчик и исполнитель начинают чувствовать себя соавторами проекта. Когда возникают проблемы, они не обвиняют в этом друг друга, а совместно ищут решение.
Ключевая ценность таких презентаций в том, что они помогают согласовывать ожидания и примирять их с реальностью.
В 99% случаев для заказчика непринципиально получит он результат сегодня или через три дня. Но ему принципиально важно, чтобы его ожидания и действительность не разошлись друг с другом.
Если вы обещали закончить проект сегодня, а закончили через три дня — это может привести к серьезным проблемам. Если обещали через три дня и закончили через три дня — это вызовет только уважение и благодарность. Именно поэтому регулярная сверка результатов помогает осуществить даже самый сложный и длинный проект без сюрпризов избавляет от 80% проблем.