66 Бит

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

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

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

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

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

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

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

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

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

Представьте, вашей команде нужна новая система управления проектами. На рынке два варианта: первая – функциональная, мощная, в ней есть все необходимое, но ее интерфейс напоминает панель управления атомной станцией из 90-х: мелкий шрифт, тусклые цвета, запутанное меню. Вторая система предлагает схожий набор функций, но выглядит совершенно иначе: продуманная компоновка, интуитивные иконки, приятные глазу оттенки, элементы, которые реагируют на ваши действия. За удобство просят на 30-40% больше. И...

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

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