Забудьте про корпоратив, делайте для людей

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

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

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

Фразы “для людей” и “приносить пользу”, это значит что человек должен открыть программу, понимать как при её помощи он может решить свои задачи (и решать их), и в любой момент её использования не быть потерянным в ней, не получить дискомфорта от использования, а быть постоянно в курсе что происходит.

Плохой пример – открыли форму авторизации, ввели наш логин и пароль, жмакнули “Войти”, и получили ошибку что логин и пароль не найден. О блин, так логин и пароль же мой?.. а где, куда, почему?.. а всё потому что разработчики не обработали ошибки авторизации, а просто лупанули один текст ошибки в UI на любую ошибку которая прилетит с сервера. И поэтому отсутствие интернета, долгие запросы, проблемы с прокси, падение сервера, деактивация аккаунта, да и миллион других сценариев, всё это работает неправильно. Человек откроет, не поймет, закроет. Ну напишет в поддержку. Хорошо это? Конечно нет. Нормально ли это? В современных процессах часто да, просто потому что “а давайте сделаем на одну фичу больше вместо обработки исключений”.

Еще один плохой пример, лично сталкивался, бесит – открываем интернет-магазин, набираем кучу товаров, пытаемся заказать, и получаем сообщение что требуется регистрация. Не вопрос, сейчас зарегистрируемся и оформим заказ. Регистрируемся, переходим в корзину… а там пусто. Финито. То есть теперь поднимай историю, ищи товары которые просматривал, снова выбирай параметры, добавляй в корзину. Ладно если там 1-2 товара, а если там 10? 50? Я затаривался аптекой во всем известной сети, выбрал 20 позиций, и поймал этот сценарий. Ничего хорошего в этом нет, пользователи страдают от такой работы программы.

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

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

1. Фотки бывают не подходящего размера

2. Фотки бывают не тех форматов.

3. Фотки бывают не тех пропорций.

4. Фотки бывают тяжелыми (как файл).

5. Фотка может быть битой.

6. Фотка может быть подделкой (файл).

7. Фотка может не загрузиться по причинам на стороне пользователя.

8. Фотка может не загрузиться по причинам на сервере сервера.

9. Фотка может не отобразиться после загрузки.

10. Фотка может быть загружена не полностью при попытке её отобразить.

11. Загрузка просмотра фото может зависнуть по сетевым причинам.

11 пунктов, не считая факта что пункты 7-8 можно развернуть в еще целую кучу сценариев. А еще загрузка фото может быть сопряжена с другими продуктовыми сценариями, из серии продолжения загрузки при потере соединения, при перезагрузке вкладки, при ошибках загрузки, ретраи (повторные попытки) загрузки фоток, и многое другое.

Всё это должно быть правильно обработано. Я видел сервисы которые реально всё это нормально обрабатывают. Ну, большую часть. Это очень круто, когда ты можешь отправить на загрузку 100 файлов за раз, и не переживать что из-за глюка в приложении ты потеряешь данные, состояние загрузки, историю, или еще что, и всегда уверен что в любом случае ты по максимуму завершишь загрузку. Именно поэтому я использую это приложение.

На практике обычно не так. Дело в том, что чтобы загрузка фото работала, при условии что всё работает штатно, у пользователя стабильный интернет, сервер работает вечно и без падений, провайдер огонь, и так далее – достаточно лишь провалидировать файл, отправить на сервер. а дальше всё, ждем ответа сервера полные уверенности что всё будет хорошо. Так себе это представляет бизнес, и когда управлению скажут что оно работает, но что-то может пойти не так, и на обработку этого не так надо еще +N дней, то есть увеличить время разработки фичи, например, в 2 раза, то обычно чаша весов склоняются в сторону “если не должно быть, в теории, то и не делаем, не критично”. И вот это не критично выливается в удобство использования и многочисленные негативные возгласы в отзывах на продукт.

Вобщем, думаю вы поняли о чем речь. Всё это следствия подхода к разработке продукта, как к конвейеру на заводе. Задача бизнеса выпустить и собрать сливки, заработать денег. Пользователи же наоборот, хотят пользоваться удобным и работающим продуктом. Так вот, я думаю что такие задачи бизнеса это прямое противоречие интересам пользователя, если является основной целью бизнеса когда они думают про выпуск продукта. В большинстве случаев, на моей практике, компании именно стремятся выпустить, начать зарабатывать, но совершенно забывают ради кого и чего они это делают. Вот это и есть проблема. Если раньше люди (подчеркну, отдельные люди) писали программы (winrar, виктория, куча другого старого офигенного софта), импровизировали, пытались сделать удобно, хорошо, и не парились о том сколько они на этом заработают, потому что это прежде всего творчество, сейчас наоборот, программа воспринимается как продукт на полке магазина – главное выпустить и продать.

Теперь немного выдохнем (фух). Подумаем как с этим быть разработчикам.

Всё понятно, есть задачи, есть цели компании, мейлстоуны, надо сделать 100 фичей за 3 месяца, и всё это выпустить к релизу пропиаренному маркетингом. Что я могу сказать.. Если прямо, то рыба гниет с головы. Разработчик может 1000 раз быть прав, стараться сделать хорошо, но решения принимает не он. Даже если встать в позу зю и сказать “или так и сделаем хорошо, или никак”, скорее всего будет эскалация с последующей заменой разработчика. Поэтому обычно все разработчики всё понимают, но делают как надо бизнесу.

Бывает и другая ситуация, и честно говоря, сильно чаще. Это когда сам разработчик не понимает что фича не доделана. Он берет требования, делает как написано в бумажке, а то что там отвалится, или как это будут поддерживать другие разработчики, или все ли сценарии обработаны, он не продумал. Часто это нехватка опыта, особенно заметно у начинающих или средних (какое странное слово) разработчиков. Здесь всё просто – просто спрашивайте себя “что может здесь пойти не так?”, и ищите сценарии при которых что-то может отвалиться. Это и есть исключительные сценарии работы программы. Кроме того, отличный вопрос это «А что здесь может потребоваться пользователям еще?». И еще один отличный способ найти пропущенные исключительные сценарии, это просто пройти по всем путям кода в данном участке программы, и проследить необработанные пути. Обычно это или отсутствие else, или switch без дефолтного кейса, потерянная обработка события, и так далее.

Лично мое мнение, что разработчики почти бессильны в условиях когда управление диктует свои приоритеты и правила, и именно управление выбирает набор того что делаем, или не делаем (реализуем) в программе, на уровне реализации фичей, а не верхнеуровнево из серии “хочу систему регистрации”. Именно поэтому весь этот текст по большей части для управленцев, особенно для технарей которые управляют своими командами, и менеджерам – не забывайте что программа в конечном итоге должна помогать пользователям решать их задачи. Это единственная причина почему они используют вашу программу. А комфорт от использования, удобство, обработки ошибок, всё это в сумме создает опыт использования, и если он положительный, то люди придут именно к вам, а не к вашим конкурентам. Поэтому принимайте решения из расчета на реальных людей, ваших пользователей, а не на бюджеты, сроки, релизы, проблемы в процессах, давление сверху. Всё это пути к хреновым продуктам.

Данным текстом выражаю две вещи:

1. Разработчики, не пишите код для того чтобы написать код. Творите программу, пишите для людей, думайте про людей, это конечная цель в разработке продукта. Документы, дизайны, и вся остальная шелуха, всё это лишь инструменты производства, а не панацея. Думайте про использование продукта, думайте со стороны пользователя, и делайте продукты лучше. Не ориентируйтесь на то что написано в документах как на догму, всё переосмысливайте, перечитывайте, изучайте продукт, сценарии использования, исключительные сценарии, и результатом своей работы помогайте пользователям.

2. Управленцы, всё что вы делаете должно иметь целью облегчить жизнь пользователям в их задачах. Процессы, давление сверху, релизы, маркетинг, всё это ходит вокруг идеи выпуска качественного продукта, и поэтому подгоднять процессы, требования, бюджеты, сроки, лишь бы успеть и выпустить, это движение в обратную сторону. Это как жать педаль газа и тормоза одновременно, и зависимости от того что сильнее, туда и приедете. Так нельзя. Движение должно быть только максимально вперед, даже если релиз будет позже и дороже.

У меня всё.

Всем спасибо!