Книга: Без ТЗ: Как запустить сервис и ничего не упустить. Аутсорсинг разработки цифровых продуктов
Назад: Фронтенд
Дальше: 7 – Как принимать работу

Заметки и истории

Готово!

«У меня все готово, осталась буквально пара мелочей», – говорят люди, которые не умеют доводить дела до конца. Многие недооценивают этот навык.
Человек, способный проконтролировать работу специалиста (например, дотошный арт-директор работу дизайнера), выясняет, что доработка этих мелочей занимает такое же или большее время, чем вся «выполненная» работа.
По грубой оценке автора, в лучшем случае один человек из двадцати способен отвечать за результат.
Один из ста может довести до финала работу команды. Такой человек называется product owner. Другими словами, тот, кто за все отвечает в конце концов.
Каждый специалист должен быть менеджером продукта, к которому он прикладывает руку.
Зона ответственности дизайнера не заканчивается на этапе передачи макетов разработчикам. Он должен контролировать все до релиза. Это называется вовлеченность.
Специалист, который способен взять на себя ответственность за соблюдение тысячи нюансов с учетом дефицита времени, дорогого стоит.

Не работать ради работы

До того, как я взялся за разработку своего самого сложного проекта для оператора связи, его не могли запустить в течение 4 лет. Вроде бы все уже было готово. Он даже работал на тестовом сервере. В продукте была реализована ключевая функциональность, однако чего-то всё же не хватало. И этим «чем-то» были ценности для пользователей. Бизнес-заказчики и команда разработки настолько углубились в сам процесс, что напрочь забыли о ценностях.
Конечно, в мире существуют такие утилитарные вещи, как вешалки или посуда, без которых в бытовой жизни не обойтись, однако цифровыми продуктами мы пользуемся из-за того, что с их помощью более эффективно или комфортно реализуем свои потребности. Пришлось изучить массу исследований, досконально проанализировать текущий опыт клиентов компании и найти в нём изъяны, чтобы составить гипотезы о ценностях, которыми стоит наполнить продукт.
Спустя год была сформирована проектная команда, полностью изменены процессы взаимодействия с заказчиком, внешними и внутренними подрядчиками и, наконец, запущен продукт, который действительно полезен аудитории, поскольку решает её проблемы. Прародитель методики Agile провёл исследование более 20 000 проектов и доказал, что результат вовсе не связан с процессами.
Суть этой истории – в том, что не стоит работать ради работы: во главе любого цифрового продукта находятся не процессы, а реальные потребности пользователей и вовлечённая команда. Всё остальное – второстепенно.
Назад: Фронтенд
Дальше: 7 – Как принимать работу