Когда программист сказал, что всё готово, начинается главная работа

Сегодня я расскажу про тестирование сложных IT-продуктов. Это выстраданный и оттого полезный рецепт. Но сначала подпишитесь на наш Телеграм-канал. Без уведомлений вы пропускаете массу интересного!

На заре становления наша веб-студия делала зрелищные и эффективные для маркетологов сайты. Это был наш конёк и коммерческое предложение. Когда бюджет позволял, мы делали самые визуально крутые сайты в отраслях. Но функционально это были элементарные сайты. За редким исключением, мы создавали корпоративные сайты из нескольких страниц. Наше кредо в то время гласило: «Клиент не увидит продукт, пока мы не доведём его до идеала». Это производило впечатление!

С 2016 года наш фокус сместился в сторону IT-проектов, где требуется программирование уровня выше среднего. Мы по прежнему делаем сайты, вызывающие катарсис. Но теперь сильный веб-дизайн — вершина айсберга нашей работы. Мы имеем опыт затяжной программной разработки до года и более. Умеем создавать то, чего пока не существует. Интегрируем неинтегрируемое (шутка!).

читайте по теме:Как одна компания с пятой попытки сделала классный сайт. Не делайте так! Наймите нас сразу.

Внезапно мы осознали, что в таких проектах наш привычный перфекционизм в части «доведения всего и вся до идеала» сбоит. Теперь нам стало намного сложнее довести до идеала продукт, прежде чем отдадим его заказчику. Потому что тестируем и фиксим баги слишком долго. Но самое интересное, что клиентам это не нужно. Более того, мы копаем себе яму, если пытаемся сдать полностью готовый сайт (это объясню ниже).

В новой для себя реальности мы выработали алгоритм тестирования IT-продукта, который ускоряет внедрение в разы. Я пишу эту статью, потому что если вы решили заказать у нас функциональный проект, вам следует знать как и что будет происходить.

Программист сказал, что всё сделал

Когда программист откинулся на спинку стула и сказал, что закончил, на деле ничего не готово и пока ничего не работает. Давайте я не стану анализировать почему так происходит. Это просто факт. Тут можно злиться и недоумевать, но всё тщетно. Мы боролись, а потом взяли и обернули это в свою пользу. Сделали частью созидательного процесса.

Как пофиксить баги и запустить проект быстрее

С этого момента пойдут важные вещи. Это и есть наш рецепт успешной разработки в минимальные сроки.

Наша задача — посадить заказчика в админку как можно раньше. Зачем? Затем, что пользоваться сайтом ему, а не нам. И удобно должно быть ему, а не нам. Заказчик имеет своё не оформившееся до конца ожидание к админке сайта. Хотелось бы, чтобы его чаяния хотя бы в какой-то степени совпадали с реальностью. Чтобы добиться этого, мы как можно быстрее запускаем админку, где всё сикось-накось, но уже можно наполнять сайт. Параллельно наши тестировщики со своей стороны отлавливают баги функционала. Но самая ценная информация для разработчиков идёт от тех, кто начал пользоваться сайтом по назначению.

читайте по теме:Диджитализация [цифровизация] бизнес-процессов

В сущности, мы не открыли Америку. А просто сделали альфа-версию и все дружно лезут под капот ловить баги. Смысл в том, чтобы сделать эту часть работы общей и подготовить к ней заказчика. Я уже писал про значение вовлечённости клиента в работу. У нас есть красноречивый проект в портфолио, который здорово иллюстрирует это.

Когда заказчик начал работать с сайтом, происходит магия синергии. Мы отлавливаем не только функциональные недочёты, но и улучшаем эргономику продукта. Заметьте, не по окончании всех работ, а с самого начала. Без включённости заказчика мы бы пилили функционал до логического завершения, потом до упора исправляли ошибки. И только после этого запустили бы клиента внутрь. А он поковыряется в админке и скажет: «А давайте переделаем это, это и это. Да и вообще, всё!». Или, что ещё хуже, поморщится и «проглотит» как есть. Потому что время ему дороже и вообще всё должно было работать «еще в прошлом году».

Ещё один бонус

Совместная работа над проектом «притирает» разработчиков и заказчика. Это чрезвычайно важный момент, если вы запускаете крутой и сложный продукт. Без этой «притирки» команде трудно будет развивать проект. Бывает так: заказчик дал веб-студии денег и «отпустил вожжи». А через несколько месяцев получил готовый сайт, разочаровался и поругался со студией. О совместной работе над сайтом и речь не идёт. Его можно похоронить. Такие разочаровашки — результат того, что для заказчика увиденное — сюрприз. А разговаривать с разработчиками он не научился. Как не научились понимать его разработчики.

читайте по теме:Почему нужно экспериментировать с сайтом

Развитие проекта — это логическое продолжение совместной работы. Но как продолжать то, чего не было? Развитие проекта — это необходимое условие успеха сложных продуктов. Потому что (и я вам это обещаю) взгляд на многие функции в нём у вас поменяются на 180 градусов в первые три месяца работы. Чтобы развивать проект, разработчики и заказчик должны стать спаянной командой единомышленников.

К чему нужно готовиться

Я сегодня лаконичен. Готовьтесь к совместной работе над своим сайтом. И не после того, как всё будет готово, а сразу. Это касается и дизайна, и функционала. Боевое тестирование продукта никто не проведёт лучше вас. Обратная связь, которую мы получим в итоге, сокращает потерю времени в разы. Чем быстрее мы запустим проект, тем раньше вы получите результат от его внедрения. Чем больше вы вникните в проект на начальной стадии, тем удобнее вам будет им пользоваться.

Если будут вопросы, напишите нам в WhatsApp:

НАПИСАТЬ В WHATSAPP