Read Me Driven Development: развиваем эмпатию к пользователю
При создании сложного ПО неизбежно выстраивается длинная цепочка производства и растет разрыв между теми, кто это ПО программирует и теми, кто им в итоге пользуется. Особенно остро это ощущается, когда те, кто участвует в разработке, не используют собственный продукт. В нашем случае эта цепочка удлиняется ещё и за счёт того, что конечный продукт получают даже не наши прямые клиенты, а клиенты клиентов.
Чем больше эта цепочка, тем больше возникает проблем, и тем оторваннее от конечного пользователя получается продукт. Когда программист, разрабатывающий продукт, не может поставить себя на место пользователя, возникает две проблемы:
- Нет полноценного понимания ценности того, что разрабатывается. Программист, как правило, сосредоточен на том, что и как он умеет делать, чем на том, для чего это делается.
- Нет полноценного понимания того, как этим продуктом в итоге будут пользоваться.
В нашей практике было много примеров, к чему приводил такой разрыв.
У нас нет аналитиков в компании, их работой занимаются product owners, и неизбежно получается так, что некоторые вещи уходят на откуп программистам. Как-то раз к нам пришёл клиент и сказал, что хочет возможность получать скриншоты из архивных видео. Чтобы это работало, нужно сделать временные метки для видеофайла.
Без подробных разъяснений эта задача ушла к программисту. Мы отдали клиенту получившуюся фичу, а клиент, попользовавшись ей, заявил, что вообще ничего не понял. Мы начали разбираться, и выяснилось следующее: программист написал код, в котором нужно обратиться к номеру сегмента, после чего выдается скриншот момента из самого начала этого сегмента. Программист исходил прежде всего из того, что этот код было проще и быстрее написать, а не из того, насколько это юзабельно и понятно.
Сокращаем дистанцию
Конечно, мы всё переделали, но возник вопрос: как можно было избежать этой ситуации? Мы могли бы нанять аналитиков, но у нас не такой уровень бюрократии и не такой уровень задач, чтобы постоянно нуждаться в их услугах. Поэтому разрыв между разработчиком и пользователем нужно сокращать как-то иначе.
Есть много подходов к тому, как это сделать, при этом не убирая причину, по которой разрыв изначально возникает. Возникает же он потому, что с ростом проектов неизбежен и рост бюрократии. Это не что-то плохое, с этим не имеет смысла бороться - это просто фактор, который нужно принять. Без бюрократии проект не может существовать.
В конце концов, мы пришли к такому выводу: если бы программист сначала написал короткий, простой manual о том, как пользоваться этим кодом, которого ещё нет, он бы сразу понял, насколько неудобна и неклиентоориентирована была его идея. Да, все его решения были логичны и понятны с точки зрения разработки, но с точки зрения клиента они привели в никуда. Именно в этом и заключается Read Me Driven Development - начать с конца, встать на место клиента ещё до того, как на разработку были затрачены какие-либо ресурсы.
Нужно понимать, что речь идёт не о каком-то техническом задании, которое идёт на десятки согласований и на печать. Техническое задание - это документ, в котором описывается, что и как делать, и хорошее ТЗ по сложности сопоставимо с самим кодом. Read Me документ не должен быть про то, как делать; он про то, как клиент будет пользоваться тем, что было сделано. Файл Read Me, в отличие от сложной технической документации, удаляет ненужные детали и оставляет только самые важные вещи. Становится ясным, нужно ли разрабатывать это решение или нет, как оно решит задачу пользователя и насколько понятным оно будет.
Подход RDD сложно применить для продуктов, у которых есть графический интерфейс. Гораздо проще, когда мы имеем дело с текстовым интерфейсом и API. Это как раз наш случай - мы работаем с API, config и админкой. Когда мы делаем тикет, мы стараемся в первую очередь проработать само API, написав его заранее, после чего пишем config. Мы описываем сценарии, по которым могут идти процессы, и на ходу можем начать перекраивать наше представление о том, что и как должно работать, вплоть до переделки всей задачи.
Начинаем с конца
При разработке frontend и backend часто возникает вопрос, что делать сначала. Сейчас мы переходим на подход, когда сначала отрисовывается дизайн к разрабатываемой фиче, а уже потом пишется backend - то есть, по сути, мы начинаем с конца. Раньше, когда мы двигались от backend к frontend, в итоге приходилось много переделывать.
Когда мы начинаем движение с другой стороны, от результата к началу, мы перемещаем фокус внимания на самое важное. Если техническое задание концентрируется на деталях и отвлекает от результата, то простой файл Read Me концентрируется на результате и отвлекает от деталей. И в итоге мы получаем существенную экономию времени и довольного пользователя, который был услышан и понят.