Home

Автор: Джоэл Монтвелиски (Joel Montvelisky)

Оригинал статьи: http://qablog.practitest.com/complexity-also-a-bug/

Перевод: Ольга Алифанова

В прошлом месяце я участвовал в конференции DevOps в Тель-Авиве. Я делал заметки об интересных вещах, про которые рассказывали люди – как и многие на конференции – и затем убрал блокнот – как делают, опять же, многие после конференции.

Вчера, просматривая блокнот (вроде бы я хотел посмотреть, что мне еще нужно сделать из моих бесконечных списков "надо сделать"), и наткнулся на заметки с конференции. Среди рисунков и почеркушек было предложение, за которое я зацепился взглядом. Я написал его и затем позабыл, но когда вновь увидел его, оно снова привлекло мое внимание.

Вот что там было написано:

Сложность – это тоже баг. Сложность повышается и будет продолжать повышаться.

Под этим предложением были заметки о презентации этого спикера.

Он был основателем/программистом/гиком/директором из Силиконовой Долины, и он рассказывал, как, с его точки зрения, повышается сложность программных продуктов, и как она будет повышаться в будущем.

Суть его речи сводилась к тому, что компании, занимающиеся разработкой ПО, должны выбрать, кто будет справляться с этой сложностью. Он смотрел на это с точки зрения DevOps, и поэтому сказал, что варианта тут три – разработка, IT или конечные пользователи.

Проще говоря, приложения должны делать больше: разговаривать с другими приложениями, чтобы что-то сделать, делать это быстрее, делать это в разнообразных окружениях. Мы делаем все больше и больше (не считая сна и отдыха, которых у нас все меньше и меньше).

Так вот обстоят дела, и кто-то должен "заплатить штраф" за эту повышающуюся сложность, а этот штраф может понести только одна из трех вышеперечисленных сторон.

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

Частично эта задача может лечь на IT, деплоящим и настраивающим систему так, чтобы она могла справляться с повышенной сложностью.

И, наконец, все то, с чем не справились два предыдущих кандидата, уходит к конечным пользователям, которым надо разбираться с более сложными процессами установки и настройки, и менее дружелюбными приложениями.

В конце презентации он объяснил, что сложность – это игра с нулевой суммой, и в процесс разработки ПО должно входить решение, кто будет справляться со сложностью.

Рассматривайте сложность, как баг продукта

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

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

• Во-первых, сложность зависит от пользователя

Подумайте о двух разных пользователях – например, о своем отце и о себе. Мой отец – отличный хирург, но он ужасно управляется с iPhone-приложениями. Это означает, что то, что для меня обыденно, может быть невозможным для него.

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

• Во-вторых, сложность – это компромисс

Я думаю, все мы сталкивались с ситуациями, когда продакт-оунер, или продакт-менеджер, или даже конечный пользователь заявляли "Ребята, нам нужно релизиться! Время идти на компромиссы…"

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

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

Это некритично, однако, в зависимости от пользователя, это может помешать ему/ей установить приложение. Или, в лучшем случае, пользователи просто предпочли бы обойтись без таких сложностей.

• И, наконец, со сложностью очень тяжело справляться после того, как фича уже разработана.

Представьте, что вы заказываете машину, которая сделана специально для вас. Вы обсудили цвет, форму, интерьер, колеса, зеркала…

Затем вам показывают завершенный вариант, и вы понимаете, что 1) вы планировали водить эту машину в Великобритании, где правостороннее движение, 2) хотели сэкономить, установив дизельный двигатель, и 3) хотели автоматическую КПП, а в образце – механическая…

Упс.

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

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

Сложность – это проблема, к которой нужно относиться серьезно

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

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

И, в конце концов, проблему сложности куда проще, быстрее и дешевле решать раньше, а не позже.

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

Обсудить в форуме