Программист-фанатик

Фаулер Чед

Совет 18

Автоматизация задач

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

К сожалению, меня часто прерывали на полуслове. И проблема была вовсе не в моей неправоте (это очевидно!). Но простого способа доказать мою правоту

не существует. А с точки зрения затрат единственные имеющиеся у нас объективные данные заставляли сделать вывод о выгоде найма сотрудников с более низкой почасовой оплатой.

Представь себе гипотетический проект по созданию программного обеспечения для какой-либо сферы по твоему выбору. Сколько программистов потребуется, чтобы написать такую программу за три месяца? Говоришь, пять? Шесть? (Потерпи минутку.) Хорошо. А как насчет выполнения этого проекта за два месяца? Как ты уберешь целый месяц?

Руководство отделов информационных технологий, как правило, заявляет, что для ускорения процесса следует нанять дополнительных программистов. Это неправильно, но люди так считают. И раз можно ускорить один проект, увеличив число исполнителей, значит, экстраполируя эту тенденцию, получим, что продуктивность прямо пропорциональна количеству рабочего персонала.

Но достичь поставленной цели можно несколькими способами. Для увеличения объемов производства программного обеспечения можно:

нанять тех, кто будет работать быстрее;

нанять дополнительных работников;

автоматизировать работу.

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

Это дает простую формулу, привязанную к фиксированному периоду времени:

Продуктивность = Количество проектов / (Количество программистов * Почасовая оплата)

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

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

Я помню сенсационную безработицу в США в 1980-х. В то время мы возлагали вину не только на другие страны, но и на машины, а особенно на компьютеры. На предприятиях стали появляться гигантские роботы-манипуляторы. Эти роботы настолько превосходили людей в производительности и точности, что состязаться с ними не было никакой возможности. Расстроены такой ситуацией были все, кроме создателей этих роботов.

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

Введя в формулу нашего финансового директора некоторые (вымышленные) цифры, мы получим показанное ниже уравнение.

Сравнение производительности

Быстрые программисты: 5 / (З * $80) = 0,02.

Дешевые

программисты: 5 / (20 * $12) = 0,02.

Один программист + робот: 5 / (1 * $80) = 0,06

Автоматизация является неотъемлемой частью нашей отрасли. Но по каким-то причинам мы пока не хотим автоматизировать наш труд разработчиков программного обеспечения. Как гарантированно создавать программы быстрее и дешевле зарубежных конкурентов? Нужно сделать роботов. Автоматизируй свою работу!

От консультанта по вопросам информатизации до генерального директора

Вик Чадха, генеральный директор Enterprise Corp.

Путь от консультанта по информационным технологиям в General Electric до должности entrepreneur-in-residence [12] в bCatalyst (бизнес-акселератор с фондом в 5 миллионов долларов) — вовсе не та карьера, о которой я мечтал.

12

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

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

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

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