Если вы построите это, они будут жаловаться

Говорят, что некоторые из лучших программистов в мире невероятно ленивы. И когда вы думаете об этом, это имеет большой смысл.

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

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

Ларри Уолл, создатель языка программирования Perl, лучше всего описывает эту уникальную черту: «Лень: качество, которое заставляет вас прилагать огромные усилия, чтобы сократить общий расход энергии. Это заставляет вас писать облегчающие труд программы, которые другие люди сочтут полезными, и документировать то, что вы написали, чтобы вам не приходилось отвечать на множество вопросов по этому поводу. Отсюда первая великая добродетель программиста».

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

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

Новый способ мышления

Как человек, который большую часть своей профессиональной жизни работал с разработчиками, вскоре я стал одержим программированием и эффективностью. С тех пор, как в 2012 году я создал свой первый скрипт VBA, я начал смотреть на мир через новую призму.

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

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

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

Излишне говорить, что я был взволнован потенциалом этого нового набора навыков.

Строить, поддерживать, перестраивать, повторять

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

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

Грязная правда и советы для достижения успеха

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

Внутренние проекты также подвержены неэффективному управлению и плохому планированию, что приводит к тому, что проекты не приносят ожидаемых результатов. В отчете McKinsey & Company за 2012 г., озаглавленном Выполнение крупномасштабных ИТ-проектов в срок, в рамках бюджета и с выгодой, описывается один пример крупного банка, который хотел создать центральное хранилище данных для устранить противоречия в своих данных. В этом конкретном примере конечная цель никогда не была определена должным образом, и ИТ-отдел приступил к созданию решения, которое никогда не учитывало фактические бизнес-цели, что привело к огромному количеству ненужной сложности и значительному перерасходу средств. После 18 месяцев несоблюдения сроков, почти 10 миллионов долларов невозвратных затрат и отсутствия рабочего решения банк решил остановить кровотечение и полностью отменить проект.

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

  1. Сколько времени это займет на самом деле? Иногда ИТ-специалисты слишком оптимистичны в отношении сроков. Учитывая, что SaaS-компании может потребоваться несколько лет только для того, чтобы создать MVP, важно, чтобы вы определили для своей команды реалистичные сроки. Обязательно заранее узнайте у своего ИТ-отдела полный график разработки и запланируйте контрольные даты и регулярные проверки, чтобы избежать неожиданностей.
  2. Кто будет оказывать постоянную поддержку? То, что нужно вашей команде сегодня, будет отличаться от того, что нужно вашей команде через 6 месяцев. Со временем ваши требования изменятся, или что-то сломается, и вы должны быть уверены, что вас не оставят без присмотра в самый важный момент. Убедитесь, что ваша ИТ-команда гарантирует поддержку после продажи, и не забудьте включить эти текущие расходы в свой бюджет.
  3. Чем я жертвую? Нереально ожидать, что ваша ИТ-команда сможет создать решение, полностью конкурирующее с решением стороннего поставщика. В конце концов, компании SaaS, как правило, координируют все свои ресурсы для создания единого решения, тогда как ваша ИТ-команда должна делить время между вашим проектом и всеми остальными результатами. Важно учитывать, чем вы будете жертвовать, и как это повлияет на результаты вашей команды.

Расставьте приоритеты в своих потребностях

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

Поэтому, принимая это сложное решение, обязательно тщательно оцените свои риски и возможности, соответственно сравните постоянные и переменные затраты и выберите решение, которое позволит вашей компании расти без компромиссов.