- 5 мин
- 5348
Мы много лет разрабатываем сложные цифровые продукты и часто сталкиваемся с одинаковыми проблемами. Эти проблемы, как мы сейчас понимаем, зависят не от типа или сложности бизнеса или сложности поставленной задачи, а от того как компания-заказчик выстраивает коммуникацию с подрядчиком — разработчиками, digital-агентством и как компания понимает процесс разработки цифрового продукта.
Пока у нас 7 типовых ошибок заказчика.
Типовая ошибка №1. Назначить несколько сотрудников ответственными за проект
Мы просим клиентов назначать главного ответственного сотрудника на проект. Это становится важным, когда несколько представителей заказчика выдают какую-то (иногда несогласованную) информацию. Если ответственных лиц несколько, то и ответственность размазывается между ними, что может приводить к конфликтам, поискам виноватого в критических ситуациях.
Пример:
Ответственные сотрудники по очереди дают задачи, противоречащие друг другу. Мы уточняем, почему в организации поменяли решение, и выясняется, что на самом деле произошла мискоммуникация между самими сотрудниками, не знавшими о поставленных ими задачах.
Решение:
Назначить ответственное лицо, которое будет:
— принимать решения от имени заказчика
— формировать и контролировать рабочую группу из исполнителей заказчика
Типовая ошибка №2. Не закладывать в проект время компании-заказчика
Часто заказчики не учитывают свою вовлечённость в проект. Подход — «отдал в разработку, вот и пусть там думают» не работает, так как исполнитель никогда не будет знать все процессы заказчика на 100%.
Пример:
Стадия проектирования сложного цифрового продукта может занимать до 30% от всего проекта. На этом этапе разработчикам важно получить достоверную информацию о множестве процессов клиента. Если разработчики не получают верную информацию вовремя, это всегда приводит к переделкам. Переделки ведут к затягиванию сроков сдачи проекта и финансовым потерям клиента.
Решение:
- назначить ответственное лицо, которое будет:
— принимать решения от имени заказчика
— взаимодействовать с разработчиками
— определит для рабочей группы заказчика нормы рабочего времени на проект
— вести учёт рабочего своего времени и рабочей группы
Типовая ошибка №3. Привлекать к экспертизе и принятию отдельных этапов непрофильных специалистов
Обычно эта ошибка связана с отсутствием критериев оценки результата: текстов, дизайна, видеороликов, качественных характеристик сайта или системы.
Пример:
Дизайн сайта принимает главный бухгалтер клиента по принципу «нравится-не нравится». В результате сроки запуска проекта увеличились на 2 месяца.
Решение:
- сформулировать критерии результата проекта и его отдельных этапов
Типовая ошибка №4. Ставить требования устно
Типичная ситуация — представитель заказчика сообщает об изменениях требований по всем каналам коммуникаций: по телефону, Skype, в мессенджерах, по почте, голосом. Чаще всего это связано с ленью — хочется побыстрее донести информацию до разработчиков, а формулировать требования письменно и тратить на это время не хочется. Данные, размазанные по разным каналам коммуникации, теряются. Это приводит к потерям денег и времени.
Рекомендуем вести учёт всех требований в Trello, эксель-файле или специальной программе, которую могут предложить разработчики. Фиксировать требования может аккунт-менеджер разработчика и представитель заказчика.
Пример:
Клиент вел коммуникацию в Скайпе, менеджер проекта не перенес переписку в систему. В итоге мы потеряли важное уточнение, которое влияло на проект. Мы принимаем запросы, обрабатываем и вносим в Систему постановки задач и учета трудозатрат. Cчитаем, что история по проекту должна собираться по максимуму — это экономит время обеим сторонам. При возникновении споров вся информация всегда можно посмотреть на каком этапе произошел сбой или ошибка.
Решение:
- фиксировать все требования и их изменения
В статье «Инструменты для дистанционной работы» рассказываем, как мы фиксируем требования.
Типовая ошибка №5. Не тестировать продукт
Некоторые заказчики экономят своё время и не тестируют продукт перед релизом, всецело полагаясь на разработчика. К сожалению при таком подходе, к пользователям так или иначе попадает гораздо больше багов, а после релиза заказчик переживает их правки более болезненно, чем в случае, когда они были обнаружены на этапе тестирования. Обычно в таких ситуациях страдает лояльность реальных клиентов и растягиваются сроки сдачи работ.
Пример:
Заказчик поставил задачу добавить на сайт форму. После релиза, от менеджеров заказчика стали поступать жалобы на несвоевременную доставку заявок. После проверки выяснилось, что текст письма не проходит проверку на спам. В результате были потеряны реальные заявки.
Решение:
Всегда проверяйте работы во время приёмки. Для сложных проектов лучше иметь тестировщика отвечающего за релиз на стороне заказчика.
Типовая ошибка №6. Превращать ошибки в катастрофы
Ошибки — естественная составляющая любого проекта, их нужно вовремя находить и быстро устранять. Тратить время на что либо, не имеющее отношения к непосредственному исправлению бага — тратить время впустую. Иногда представители заказчика забывают это и тратят время проекта не создавая реальной пользы.
Пример:
Тестируя новый функционал представитель заказчика обнаружил, что у него «поплыла» часть фронтенда на компонентах разработанных ранее. Он написал длинное и очень гневное сообщение с требованием поднять всю историю, сравнить состояния по разным датам и т.д., а самое главное — найти виноватого. Разработчик потратил большую часть времени на выполнение требований заказчика, чем на исправление ошибки, впал в стресс и допустил ошибку в другом месте.
Решение:
Всегда помните, что поиск и устранение ошибок — неотъемлемый, непрерывный и очень важный процесс в любом проекте на всех стадиях жизни, а найденная ошибка — всегда праздник, уже хотя бы по тому, что её можно исправить и сделать цифровой продукт чуточку лучше.
Типовая ошибка №7. Экономить на проекте, не понимая последствий
Часто заказчики пытаются удешевить проект различными способами, и результат подобной инициативы всегда предопределён — стоимость проекта увеличивается. Если не выделить на проект достаточного количества времени — возрастают риски, а если экономить на отдельных этапах — увеличивается количество переделок. Мы советуем своим клиентам, в случае если ограничен бюджет или время — пожертвовать частью функционала в пользу качества, иначе говоря — сделать меньше, но лучше.
Пример:
Клиент заказал разработку дизайна у дизайнера-фрилансера по «привлекательной цене», в результате дизайнер нарисовал шаблоны в Corel, и сдал работу заказчику в виде исходников не пригодных для дальнейшей верстки. Пришлось перерисовывать шаблоны и в итоге работа была выполнена дважды, а времени ушло даже больше, чем если бы рисовали в шаблоны с нуля.
Решение:
Старайтесь оценить последствия экономии: спрашивайте разработчиков о последствиях решений.