Дмитрий Ершов - Без ТЗ - Как запустить сервис и ничего не упустить. Аутсорсинг разработки цифровых продуктов

Зачастую у бэкендеров работа больше научно-исследовательская, нежели техническая. Чем яснее сформулирована задача – тем выше вероятность готовности функционала в срок.

Сейчас многие задачи, которые раньше выполнялись на стороне бэкенда, можно решать и без него. Весь сервис может работать непосредственно в браузере. Представляете, насколько быстрее запустится продукт, если убрать из его создания целый этап работ?

Деятельность фронтенд-разработчиков влияет на первое впечатление от вашего продукта. Насколько быстро и плавно загружается контент, насколько удобно работают формы заполнения заявок, зависит не только от дизайнеров, но и от фронтендеров. Конечно, бывают и исключения, но я редко встречаю идеально работающий фронтенд со страшным дизайном, а вот обратное – на каждом шагу.

После запуска цифрового продукта в интерфейсе можно увидеть два типа ошибок: серверные и клиентские. Серверные всегда выглядят шаблонно, например: «Ой, что-то пошло не так» или «Извините, страница не найдена» и т. п. Клиентские (ошибки фронтенда) отражаются в съехавших шрифтах, дёргающихся при загрузке блоках страниц и невозможности «свайпить» картинки на экране смартфона. И если к серверным ошибкам пользователи более-менее привыкли, поскольку они типовые, то косяки с вёрсткой всплывают неожиданно и тем самым больше раздражают, выдают низкое качество продукта и снижают лояльность ваших пользователей.

«У меня все готово, осталась буквально пара мелочей», – говорят люди, которые не умеют доводить дела до конца. Многие недооценивают этот навык.

Человек, способный проконтролировать работу специалиста (например, дотошный арт-директор работу дизайнера), выясняет, что доработка этих мелочей занимает такое же или большее время, чем вся «выполненная» работа.

По грубой оценке автора, в лучшем случае один человек из двадцати способен отвечать за результат.

Один из ста может довести до финала работу команды. Такой человек называется product owner. Другими словами, тот, кто за все отвечает в конце концов.

Каждый специалист должен быть менеджером продукта, к которому он прикладывает руку.

Зона ответственности дизайнера не заканчивается на этапе передачи макетов разработчикам. Он должен контролировать все до релиза. Это называется вовлеченность.

Специалист, который способен взять на себя ответственность за соблюдение тысячи нюансов с учетом дефицита времени, дорогого стоит.

До того, как я взялся за разработку своего самого сложного проекта для оператора связи, его не могли запустить в течение 4 лет. Вроде бы все уже было готово. Он даже работал на тестовом сервере. В продукте была реализована ключевая функциональность, однако чего-то всё же не хватало. И этим «чем-то» были ценности для пользователей. Бизнес-заказчики и команда разработки настолько углубились в сам процесс, что напрочь забыли о ценностях.

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

Спустя год была сформирована проектная команда, полностью изменены процессы взаимодействия с заказчиком, внешними и внутренними подрядчиками и, наконец, запущен продукт, который действительно полезен аудитории, поскольку решает её проблемы. Прародитель методики Agile провёл исследование более 20 000 проектов и доказал, что результат вовсе не связан с процессами.

Суть этой истории – в том, что не стоит работать ради работы: во главе любого цифрового продукта находятся не процессы, а реальные потребности пользователей и вовлечённая команда. Всё остальное – второстепенно.

Спринт подошёл к концу – время принимать результат работы. В нашем случае это проверка качества исполнения на соответствие критериям приёмки. Возьмите за правило открывать бэклог и сверять результат с тем, что вы там написали. Если он соответствует критериям приёмки, но при этом вы всё равно недовольны – значит, либо вы плохо описали критерии, либо задачу поставили слишком творческую или размытую, и её нужно декомпозировать.