Скрытые издержки плохого программного обеспечения

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

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

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

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

Задайте вопрос любому из тех, кому довелось поработать в технической поддержке любой из компаний, занятой в сфере создания настольных программ, и он непременно ответит, что больше всего времени и сил он тратит на объяснение нюансов работы с файловой системой. Пользователи, так же как Джейн из главы 1, не разбираются в рекурсивной иерархии файловой системы, и не важно, будет ли это Finder или Explorer в операционной системе Windows, Мас или UNIX. Удивительно, но очень невелика доля тех компаний, которые тратят средства на проектирование и реализацию версий файловых систем, более дружественных пользователю. В большинстве своем компании предпочитают более дорогой путь в виде содержания службы технической поддержки для ответов на бесконечные вопросы пользователей.

Можно сколько угодно обвинять «чайников» во всех грехах, но вам в любом случае придется нести значительные затраты на высокооплачиваемых телефонных консультантов технической поддержки, если ваша компания планирует продавать плохо спроектированное программное обеспечение.

Дороже разработки программ может быть только разработка плохих программ

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

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

Если же этап проектирования не выполняется прежде этапа программирования, то никакого толку от него не будет. Как-то от одного руководителя я услышал такую фразу: «Мы уже поручили нашим сотрудникам писать код, и я не собираюсь останавливать их». Посыл этого умника приблизительно такой: «Я успею соорудить парашют прежде, чем мы ударимся о землю». Звучит весьма смело, но я ни разу не видел, чтобы это сработало.

Без серьезной основы в виде плана проектирования программисты начинают бесконечные эксперименты со своими программами, пытаясь найти оптимальное решение. Как в случае с плотником, «на глаз» отпиливающим куски доски, пока не получится подходящий для латания дыры в стене, этот метод влечет избыточные потери.

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