66 Бит

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

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

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

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

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

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

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

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

Представьте, что вы открываете новый сервис, до запуска остаётся месяц, а ваш технический директор предлагает арендовать серверные мощности. Он показывает расчёты: нужно взять с запасом, потому что после запуска нагрузка может вырасти. Вы соглашаетесь, подписываете договор, и каждый месяц с вашего счёта списывается фиксированная сумма за аренду выделенных серверов. Запуск проходит успешно, но первые три месяца пользователей немного. Вы платите за серверы, которые загружены на десять процентов, остальные девяносто процентов мощностей простаивают, но счёт за них приходит неизменный...

Это прорыв! Вы придумали приложение или целую цифровую платформу, которая изменит рынок. В голове уже сложилась четкая картина: как это будет работать, какие проблемы решит, почему клиенты выстроятся в очередь. Осталось только найти команду, которая воплотит задумку в жизнь но тут возникает тревога: а что, если я расскажу идею – и они её просто возьмут и сделают сами? Или расскажут кому-то еще? Стоит ли вообще говорить что-то конкретное до того, как будет подписан документ о неразглашении? Может...

Представьте, что вы заказываете строительство загородного дома. Вы утвердили проект, согласовали материалы, строители залили фундамент, возвели стены и уже приступили к крыше. И тут вы замечаете, что окно в спальне расположено на полметра левее, чем вам представлялось. Вы просите строителей передвинуть окно, они останавливают работы, вызывают бригаду, переделывают кладку. Проходит неделя, и вам выставляют счёт за дополнительные работы. Вы удивлены: «Я же просто попросил передвинуть окно, это же мелочь!» В разработке программного обеспечения такие ситуации возникают на каждом шагу...

«Никто не обязан говорить вам правду. Вы сами должны её узнать». – Роберт Фитцпатрик, «Спроси маму». Мы привыкли думать, что создание программного продукта начинается с написания кода. Появилась идея, значит нужно нанять разработчиков, заплатить деньги, и через несколько месяцев получить готовое приложение. Такой подход выглядит прямолинейным и понятным, именно поэтому большинство предпринимателей и стартаперов действуют именно так. Проблема в том, что этот путь почти всегда ведет к потерям. Статистика...