В той же «Додо Пицце» руководителям отделов в конце месяца нужно было готовить отчет о работе. Это делается, чтобы упростить процедуру совещаний: каждый перед началом собрания может узнать, чем занимались его коллеги из других подразделений. Тогда совещание проходит слаженно и быстро. Но мы столкнулись с проблемой – сотрудники старались писать в отчете как можно больше, тем самым как бы говоря: «Я не просто так сидел в офисе». Это соревнование в количестве страниц затягивало встречи на три, а иногда и четыре часа.
Мы вовремя поняли эту тенденцию и поставили ограничение – один отчет должен помещаться на одной странице. Больше – запрещено. Эта простота принесла нам большую пользу. Ушла вся вода, осталась только суть. Никто больше не измерял работу количеством слов. Короткие отчеты легче читались, в итоге встреча проходила эффективнее. Все были в курсе работы других отделов и не тратили на это много времени. Благодаря простоте наша идея начала работать.
Итак, простота – это действительно непросто. Гораздо проще создать нечто сложное, массивное и неповоротливое. Но чтобы родилась интуитивность использования, нужен особый язык – язык простоты. Он рождается через большой труд и ежедневное кропотливое внимание к каждой мелочи. Таков путь гениальной простоты.
Есть такое понятие, как MVP (minimum viable product) – минимально жизнеспособный продукт. В общих чертах смысл MVP можно сформулировать так: «скорее внедрить и улучшать в процессе». Это помогает ускорить процесс создания продукта и, следовательно, удешевить стоимость его разработки, что в результате позволяет сделать весь процесс бережливым, а также исключить риск финансирования заведомо неуспешных проектов и идей.
Вместо того чтобы очень долго разрабатывать продукт и только потом выдавать его клиентам, нужно сразу выпускать его минимальную, простую часть, без которой запуск не имеет смысла. Возможно, продукт окажется далеким от задуманного и не будет иметь особых удобств или даже необходимого функционала. Но он уже будет работать на бизнес, им уже можно будет пользоваться.
Решая запустить новый продукт, менеджеры и предприниматели, как правило, хотят, чтобы к клиенту он попадал уже идеальным и полностью доработанным. Им кажется, что они точно, до мелочей знают, чего именно хочет их аудитория. Но, какими бы опытными ни были создатели новых проектов, эта уверенность может сыграть с компанией злую шутку, потому что сразу сделать идеальный продукт очень трудно. По меньшей мере одна или несколько выдвинутых в отношении продукта гипотез обязательно окажутся неверными.
Многие стартапы так и остались нереализованными из-за того, что их разработчики долгое время двигались в заведомо ложном направлении. Они бросали все свои силы на то, что либо не нужно вовсе, либо слишком сложно для того, чтобы этим пользоваться.
Раньше я активно пользовался приложением «Тяжеловато», которое помогало мне сокращать ненужные траты. Вадим Юмадилов, его создатель, разработал и запустил его всего за месяц. Он дал пользователям базовый функционал, а все остальное дорабатывал и корректировал уже по ходу работы приложения. В итоге оно получилось очень удобным и получило успех среди пользователей. Но вот у следующего проекта Вадима, приложения по учету расходов «Койн», уже совсем другая история.
По замыслу это приложение должно было выполнять множество функций и даже иметь собственного персонажа, который бы рассказывал о планах фирмы и развлекал читателей. Вадим хотел подавать историю трат как небольшой чат, который помогал бы экономить. И все было бы хорошо, если бы не одно но. Это никому не было нужно. «Это были просто мечты, которые основывались на одном: “круто же”. А оказалось в итоге, что нужно делать совсем другое», – написал в своем блоге Вадим.
Приложение так и не вышло. Его разработчики направили все силы на воплощение идеи – создание макетов и картинок. В отличие от «Тяжеловато», они хотели сразу выпустить идеальный продукт. Но при всем этом они не проверили его жизнеспособность. Нужно ли вообще кому-то нечто, над воплощением чего команда так долго трудится? Возможно, это приложение было бы выпущено, если бы разработчики уверенней следовали принципу MVP.
Во-первых, они бы разобрались, нужен ли вообще этот продукт, будет ли на него спрос. Проверили бы свою гипотезу на практике. Как правило, идея рождается и обретает форму в кругу ограниченного числа людей, поэтому всецело полагаться на нее и не проверить на востребованность, согласитесь, рискованно, учитывая, что разработка – очень дорогой и долгий процесс.
Во-вторых, ребята получили бы обратную связь от пользователей. В процессе работы пользователи сами подсказывают, что им необходимо и как именно им удобно этим пользоваться. Фактически на основе обратной связи продукт и должен создаваться и развиваться.