Статья о том, что иногда надо смотреть на свой продукт не как на «добро», а скорее «неизбежное зло».
Это вольный перевод. Хотя я старался сохранить общий смысл текста, некоторые выражения могут звучать не совсем как в оригинале. Спасибо за внимание.
Софт сейчас буквально повсюду. Современное общество от него зависит. Он внутри часов, медицинского оборудования, телефонов, телевизоров, лифтов, машин, и даже «компьютеров» (как будто остальные девайсы ничего не вычисляют [игра слов: англ. compute — прим.перев.]).
Будучи консультантом, я помогаю фирмам разрабатывать программное обеспечение вот уже 14 лет, и немного программирую для себя.
Я соавтор международного стандарта, и также помогал воплотить его в жизнь. Я писал софт для управления спутниковой системой связи. Я разрабатывал инструменты для команды, которая создавала модель Европейского сверхбольшого телескопа. Я участвовал в софтовых проектах для автопрома, систем здравоохранения, банков, страхования, телекоммуникаций, авиации и многих других.
В некоторых компаниях разработка шла неплохо. Команды сдавали проекты отличного качества. Акционеры были счастливы. Фирмы наращивали свою клиентскую базу и прибыль.
Но другим приходилось туго. Я видел войны между отделами за право вставить свои пять копеек в требования к релизу. Видел, как разрабы не поспевали за раздуванием фич и за заявками на изменения. Некоторые из них вообще перестали видеть смысл в том, что делали.
Я наблюдал за тем, как пропадало понимание между разработчиками и акционерами-нетехнарями, которые ими руководили.
Через несколько лет я распознал этот паттерн, и теперь когда люди спрашивали меня, что же пошло не так, я начал отвечать им: просто никто не хочет пользоваться ПО.
Сперва люди принимали меня за сумасшедшего. Ведь программы повсюду, они рулят цивилизацией! Но когда я объяснял, что имею ввиду, многие из них начинали озадаченно кивать головой.
***
Наверняка вы, как и я, хоть раз делали покупки в интернет-магазинах.
Хотите ли проходить регистрацию в ещё одном из них?
Нравится ли вам добавлять товары в корзину один за другим?
Или каждый раз перепроверять, правильно ли ввели номер кредитки?
Мне вот не особо.
И все же, я покупаю через интернет. Но почему?
То, что я хочу получить, это желаемый результат: я хочу купить новую стиралку или почитать новую книжку. Каждое взаимодействие с софтом — это шаг между мной и этим результатом.
Осознание этого в корне поменяло мой подход к разработке.
Многие компании измеряют продуктивность разработчика по количеству строк кода, или по скорости, грубо говоря, число сделанных фич за единицу времени, умноженное на их размер.
Некоторые люди не видят разницы между продажей функционала и продажей апельсинов. Больше фич дал клиенту — больше денег получил.
Но на самом деле это не так.
Добавление функционала может упростить или, наоборот, помешать вашему пользователю получить желаемый результат. А может и вовсе сделать это невозможным. Есть другие, более полезные метрики, чем скорость разработки.
Когда вы выходите на новый рынок, убедитесь, что ваш продукт удовлетворяет какую-то потребность клиента. Хольте и лелейте своих клиентов и собирайте фидбек почаще. Не превращайте свой программный продукт в никому не нужную кашу, раздувая его функционал.
Если у вас уже есть своя ниша, тогда упрощайте. Сделайте путь пользователя к желаемому результату как можно более коротким и приятным, потому в конце этого пути ваша компания получает свой доход. Хорошо, если вы дадите пользователю то, что ему нужно, за меньшее число шагов. Разрабатывайте меньше, ведь разработка софта — это инвестиция.
Амазон в свое время начинал с продажи книг онлайн. Вы покупали у них книгу, и они доставляли её до вашей двери.
Потом они первыми сделали покупку в один клик, позволяя не вводить каждый раз свою платёжную информацию и кликать много раз для подтверждения каждого заказа. Это сократило путь пользователя.
Позже они представили Kindle. Это ещё сильнее сократило пользовательский путь: находим книжку, смотрим аннотацию, подтверждаем покупку. Немного ждем, пока скачается, и книжка у нас. Не надо ждать курьера. В конце концов это всё ведет к тому же, что и в первые дни жизни Амазона: вы можете прочитать книжку. Просто путь к ней стал гораздо короче.
Нельзя стать успешным, думая лишь о количестве фич. К счастью, я не единственный, кто так считает.
Гойко Аджич придумал Impact Mapping — подход к формированию функционала из бизнес-целей. Он призывает сообщество разработчиков «Производить эффект, а не софт» (“Make impacts, not software”).
Дэвид Хейнемейер Хансон, создатель Ruby on Rails, уверен, что всегда можно сделать меньше.
Когда я объясняю это разработчикам, они меня понимают, но лишь немногие компании воплотили в жизни философию сокращения пользовательского пути.
Так что не поймите меня неправильно: я люблю программное обеспечение. Оно меня потрясает. Я начал создавать программы в ранние 90е, и до сих пор тащусь от этого.
Софт полезен. Но не сам по себе. Софт — это всего лишь средство для получения желаемого.
Пожалуйста, помните это.
Статья о том, что иногда надо смотреть на свой продукт не как на «добро», а скорее «неизбежное зло».
Это вольный перевод. Хотя я старался сохранить общий смысл текста, некоторые выражения могут звучать не совсем как в оригинале. Спасибо за внимание.
Софт сейчас буквально повсюду. Современное общество от него зависит. Он внутри часов, медицинского оборудования, телефонов, телевизоров, лифтов, машин, и даже «компьютеров» (как будто остальные девайсы ничего не вычисляют [игра слов: англ. compute — прим.перев.]).
Будучи консультантом, я помогаю фирмам разрабатывать программное обеспечение вот уже 14 лет, и немного программирую для себя.
Я соавтор международного стандарта, и также помогал воплотить его в жизнь. Я писал софт для управления спутниковой системой связи. Я разрабатывал инструменты для команды, которая создавала модель Европейского сверхбольшого телескопа. Я участвовал в софтовых проектах для автопрома, систем здравоохранения, банков, страхования, телекоммуникаций, авиации и многих других.
В некоторых компаниях разработка шла неплохо. Команды сдавали проекты отличного качества. Акционеры были счастливы. Фирмы наращивали свою клиентскую базу и прибыль.
Но другим приходилось туго. Я видел войны между отделами за право вставить свои пять копеек в требования к релизу. Видел, как разрабы не поспевали за раздуванием фич и за заявками на изменения. Некоторые из них вообще перестали видеть смысл в том, что делали.
Я наблюдал за тем, как пропадало понимание между разработчиками и акционерами-нетехнарями, которые ими руководили.
Через несколько лет я распознал этот паттерн, и теперь когда люди спрашивали меня, что же пошло не так, я начал отвечать им: просто никто не хочет пользоваться ПО.
Сперва люди принимали меня за сумасшедшего. Ведь программы повсюду, они рулят цивилизацией! Но когда я объяснял, что имею ввиду, многие из них начинали озадаченно кивать головой.
***
Наверняка вы, как и я, хоть раз делали покупки в интернет-магазинах.
Хотите ли проходить регистрацию в ещё одном из них?
Нравится ли вам добавлять товары в корзину один за другим?
Или каждый раз перепроверять, правильно ли ввели номер кредитки?
Мне вот не особо.
И все же, я покупаю через интернет. Но почему?
Достижение желаемого результата
То, что я хочу получить, это желаемый результат: я хочу купить новую стиралку или почитать новую книжку. Каждое взаимодействие с софтом — это шаг между мной и этим результатом.
Осознание этого в корне поменяло мой подход к разработке.
Многие компании измеряют продуктивность разработчика по количеству строк кода, или по скорости, грубо говоря, число сделанных фич за единицу времени, умноженное на их размер.
Некоторые люди не видят разницы между продажей функционала и продажей апельсинов. Больше фич дал клиенту — больше денег получил.
Но на самом деле это не так.
Добавление функционала может упростить или, наоборот, помешать вашему пользователю получить желаемый результат. А может и вовсе сделать это невозможным. Есть другие, более полезные метрики, чем скорость разработки.
Когда вы выходите на новый рынок, убедитесь, что ваш продукт удовлетворяет какую-то потребность клиента. Хольте и лелейте своих клиентов и собирайте фидбек почаще. Не превращайте свой программный продукт в никому не нужную кашу, раздувая его функционал.
Если у вас уже есть своя ниша, тогда упрощайте. Сделайте путь пользователя к желаемому результату как можно более коротким и приятным, потому в конце этого пути ваша компания получает свой доход. Хорошо, если вы дадите пользователю то, что ему нужно, за меньшее число шагов. Разрабатывайте меньше, ведь разработка софта — это инвестиция.
Как Amazon Kindle сокращает ваш путь к желаемому
Амазон в свое время начинал с продажи книг онлайн. Вы покупали у них книгу, и они доставляли её до вашей двери.
Потом они первыми сделали покупку в один клик, позволяя не вводить каждый раз свою платёжную информацию и кликать много раз для подтверждения каждого заказа. Это сократило путь пользователя.
Позже они представили Kindle. Это ещё сильнее сократило пользовательский путь: находим книжку, смотрим аннотацию, подтверждаем покупку. Немного ждем, пока скачается, и книжка у нас. Не надо ждать курьера. В конце концов это всё ведет к тому же, что и в первые дни жизни Амазона: вы можете прочитать книжку. Просто путь к ней стал гораздо короче.
Нельзя стать успешным, думая лишь о количестве фич. К счастью, я не единственный, кто так считает.
Гойко Аджич придумал Impact Mapping — подход к формированию функционала из бизнес-целей. Он призывает сообщество разработчиков «Производить эффект, а не софт» (“Make impacts, not software”).
Дэвид Хейнемейер Хансон, создатель Ruby on Rails, уверен, что всегда можно сделать меньше.
Когда я объясняю это разработчикам, они меня понимают, но лишь немногие компании воплотили в жизни философию сокращения пользовательского пути.
Так что не поймите меня неправильно: я люблю программное обеспечение. Оно меня потрясает. Я начал создавать программы в ранние 90е, и до сих пор тащусь от этого.
Софт полезен. Но не сам по себе. Софт — это всего лишь средство для получения желаемого.
Пожалуйста, помните это.
