Программирование и вебдизайн

Перевод статьи Мартина Фаулера “Деление IT на «стратегическое» и «прикладное»”

Одной из постоянных тем, которая меня интересовала на протяжении моей карьеры, была природа и важность развития программного обеспечения. Недавно в одном из рекламных проспектов было написано, что «программное обеспечение похоже на трубы для сточных вод. Все хотят, чтобы они работали надежно, и никто при этом не хочет знать о подробностях». Именно о таком подходе говорил Николас Карр в его статье «IT не имеет значения». С противоположным подходом к делу мы проделали работу для многих коммерческих предприятий, где IT было более четким стратегически важным звеном, более приспособленным для их бизнеса, позволяющим этим компаниям войти на новые рынки или значительно увеличить их долю на прежних рынках. Итак, IT – это прикладная вещь(ориг. «utility») или стратегическая(ориг. «strategic»)?

По моему мнению, оно может быть и таким, и другим, в зависимости от системы. Классический пример прикладного IT – это платежная ведомость. Это то, в чем все нуждаются, но при этом все хотят от этого, чтобы оно «просто работало».

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

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

Однако только несколько проектов можно назвать стратегическими. Здесь применимо правило 80\20, но в исключительных случаях бывает и 95\5. В то время как многие не понимают, что между проектами существует деление, немало людей также слишком часто ошибочно считают многие проекты стратегическими.

Еще одна из областей, в которых проходит различие между этими двумя проектами, – это степень риска. Для пиркладных проектов самый большой риск – это катастрофическая ошибка: вы же не хотите, чтобы сломались водосточные трубы, или чтобы платежная ведомость исчезла. Поэтому вам необходимо достаточно внимания, чтобы проследить за тем, чтобы такого не случилось, но все это стоит не так уж дорого. Однако со стратегическими проектами самый большой риск – это не сделать чего-то раньше своих конкурентов. Поэтому вам необходимо быстро реагировать. И здесь стоимость будет исчисляться по-другому: потерять саму возможность сделать что-то раньше других стоит гораздо больше самого программного обеспечения.

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

Одна область, в которой данное деление может пригодиться, – это создание программного обеспечения на заказ и использование коробочного софта (packaged software). Если это прикладной бизнес, то очевидно, что нужно устанавливать коробочное ПО (стандартный набор программ). Если же это стратегический бизнес, то это, наоборот, испортит вашу способность отличиться от конкурентов.

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

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

Как и в любых классификациях, здесь много неточностей и неопределенности. Тем не менее, это тот самый редкий случай, когда необходимо именно понимать различия между этими двумя типами проектов и подчеркивать контраст, склоняясь четко к одному из двух типов. Как прокомментировал Росс один из черновиков это поста, «Усиление различий между двумя типами проектов могло бы обеспечить фокусировку, «заточенность», чего часто не хватает в IT-начинаниях».

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

Перевод статьи Мартина Фаулера “Командная комната”.

Общее, что объединяет agile проекты, – это то, что develop-команда сидит в одной открытой TeamRoom. Ранее это советовалось в книге «Экстремальное программирование» и названо в качестве одной из предпочитаемых практик во втором издании книги. Задействованные в таких проектах люди предпочитают открытую TeamRoom, поскольку она способствует более неформальному и тесному общению между членами команды.


ПОЧЕМУ

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

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

ДЕТАЛИ, НЕОБХОДИМЫЕ ДЛЯ ХОРОШЕЙ КОМАНДНОЙ КОМНАТЫ

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

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

Обеспечьте достаточно пространства: около 4,5 кв.м. на человека.

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

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

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

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

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

Вам понадобится много пространства стен, так как «мыслители» обожают «информационные доски». Необходимо много пространства комнаты для «стен с story», архитектурных диаграмм, а также для чего бы то ни было из того, что люди хотят прикрепить на стены. Немалая часть этого пространства стен должна быть белыми досками, чтобы люди могли рисовать что-то, если им этого захочется. Не забудьте несколько досок на колесах. Убедитесь, что поблизости есть цифровая камера, чтобы люди могли легко заснять то, что они нарисовали на доске. На сегодняшний день дисплеи достаточно дешевые, поэтому не забудьте купить несколько для стен. Это особенно удобно для динамичных показов, таких как статус проекта. Я видел однажды, как у команды были прикрепленные к стене проекторы с различными типами информационных дисплеев.

Традиционный подход – люди, работающие среди рабочих столов. Это дает вам постоянный визуальный контакт с оставшимися членами команды. Однако я слышал, как многие восхваляли UPod.

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

Я всегда был защитником большого пространства для мониторов. Хорошее программное обеспечение со множеством виртуальных рабочих пространств – это хорошая вещь, однако нет ничего быстрее, чем просто повернуть взгляд. Каждое рабочее место должно иметь как минимум пару 20-дюймовых мониторов. Мое рабочее место имеет пару 20-дюймовых мониторов для моей Ubuntu-машины, а также 25-дюймовый для моего MAC-лэптопа. Я не думаю, что это излишне.

Программное обеспечение – созидательное по своей сути, поэтому будьте готовы ко множеству мелочных отвлечений. Очень часто находят игрушки возле команды (как сказал Нил Форд, «каждая команда нуждается в пластиковом кенгуру»). Этому существует познавательные причины, это все связано с поддержанием мозга в тонусе, в творческом состоянии.

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

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