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

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

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

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

Возможно, все дело в том, что я постарел. Или поумнел, хотя в этом я сомневаюсь. Но теперь я понял, насколько большое значение могут иметь даже небольшие инвестиции в себя. Вместо того чтобы взять инструменты и отправиться на очередной концерт, я (в обязательном порядке) играл сам для себя. Это позволило мне более целенаправленно подойти к инструментам. Я слушал музыку и составлял список приемов, которые неплохо было бы изучить. Скажем, я всегда хотел делать такие же штуки, которые показывал в своих соло на саксофоне Фил Вудс. Или узнать, каким образом Принс в конце песни «Let's Go Crazy» из альбома Purple Rain заставляет свою гитару так визжать.

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

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

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

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

 

Совет 11

Учимся ловить рыбу

Лао-цзы сказал: «Дай человеку рыбу, и он будет сыт целый день. Научи его ловить рыбу, и он будет сыт всю жизнь». При всей верности этой поговорки Лао-цзы не учел, что бывают люди, не желающие учиться ловить рыбу. Такой человек предпочтет на следующий день попросить еще одну рыбу. В процессе обучения задействованы как учитель, так и ученик. Но многие из нас зачастую не испытывают желания учиться.

Не жди, пока тебе расскажут. Спрашивай сам!

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

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

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

Не менее важной является используемая тобой технологическая платформа. Например, ты можешь разрабатывать приложения с помощью J2EE. Тебе приходится создавать различные классы, интерфейсы и дескрипторы развертывания. Можешь ответить на вопрос: зачем? Знаешь, как применяются все эти вещи? Что происходит при запуске J2EE-контейнера? Даже если ты не являешься разработчиком сервера приложений, знание всех этих вещей позволит тебе писать надежный код для этой платформы и устранять неисправности, когда что-то идет не так.

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

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

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

Действуй!

1.  Как и почему? Прямо сейчас после прочтения данного раздела или в следующий раз на работе подумай о тех аспектах своей деятельности, которые ты не до конца понимаешь. Для погружения в непонятную сферу можно задать себе два крайне полезных вопроса: Как это работает? и Почему это происходит ( или должно происходить)?

Возможно, ты даже не сможешь на них ответить, но сам факт постановки подобных вопросов приведет твой ум в новое состояние и поможет лучше осознать твое рабочее окружение. Как IIS-сервер передает запросы твоим ASPNET-страницам? Зачем генерировать все эти интерфейсы и дескрипторы развертывания для твоих EJB-приложений? В чем разница в работе компилятора при динамическом и статическом подключении? Почему для заказчиков из Монтаны сумма налога вычисляется по-другому?

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

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

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

 

Совет 12

Разберись, как работает бизнес

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

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

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

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

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

Ты не сможешь помогать бизнесу творчески, если не знаешь, как он устроен.

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

Понимание финансовых стимулов (и языка) компании, в которой ты работаешь, даст тебе возможность действовать осмысленно, а не блуждать в темноте, принимая решения, кажущиеся интуитивно правильными.

Действуй!

1. Найди книгу по основам бизнеса и прочитай ее внимательно. Ищи среди книг для специалистов по управлению предприятиями. Могу порекомендовать тебе книгу Стивена Силбигера «MBA за 10 дней». Я считаю ее весьма полезной (и приятно лаконичной). Ее можно прочитать всего за десять дней, а это не очень большие затраты времени.

2. Попроси кого-нибудь рассказать о финансовых показателях твоей компании или отдела (конечно, если это открытая информация).

3. Попробуй повторить эти объяснения.

4. Разберись, почему чистая прибыль называется чистой .

 

Совет 13

Найди наставника

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

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

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

Так было не всегда. Западная история включает в себя развитую систему профессионального наставничества, уходящую корнями в Средневековье. Подход к профессиональному обучению был еще более сильным и формализованным, чем принятая в современном музыкальном сообществе система. Молодые люди начинали свою карьеру подмастерьями признанных мастеров. Работали за символическую плату и привилегию учиться у мастера. А тот, в свою очередь, был обязан обучить подмастерьев созданию вещей в собственной манере (и собственного качества).

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

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

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

Устроившись специалистом по поддержке систем, я взял в оборот Кена — святого человека, который работал в нашем университете одним из сетевых администраторов. Он помог мне решить серьезную проблему с NetWare-сетью нашего кампуса, проблему, из-за которой студенты не могли пользоваться компьютерным классом, и после этого отделаться от меня ему было уже сложно (впрочем, он и не пытался). Когда я спросил у него, в каком направлении следует двигаться, чтобы стать более компетентным и независимым, он дал мне простой рецепт: разберись со службами каталогов, научись работать с их UNIX-вариантом и как следует изучи язык сценариев.

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

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

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

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

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

Действуй!

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

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

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

Добавь к списку еще один столбец и подумай, как выбранный тобой пример для подражания оценил бы тебя по десятибалльной шкале (10 — наивысшая оценка). Попытайся посмотреть на себя глазами другого человека.

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

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

 

Совет 14

Стань наставником

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

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

Мы учимся, обучая. Это звучит странно, ведь предполагается, что учитель уже знает свой предмет. Разумеется, я не имею в виду изучение нового материала путем его преподавания — откуда человек сможет узнать этот материал? Но знание фактов не означает понимания их причин и следствий. Именно такое, более глубокое понимание мы развиваем в себе, уча других. Для объяснения сложных понятий ищутся аналогии, и мы проводим внутреннюю работу, объясняя себе, почему одна аналогия кажется рабочей, но на самом деле совершенно не подходит, в то время как другая, с виду менее удачная, объясняет суть. Преподавателю порой приходится сталкиваться с вопросами, которые ни за что не возникли бы у него сами по себе. Работа учителем позволяет выявить и устранить пробелы в собственных знаниях.

А значит, ты можешь получить выгоду, не только найдя себе наставника, но и став наставником для кого-то еще.

Чтобы понять, на самом ли деле ты хорошо разбираешься в теме, попробуй объяснить эту тему кому-то еще.

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

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

Для поиска учеников вовсе не нужно расхаживать с умным видом и объявлять себя знатоком. Здесь помогут только твоя компетентность и желание терпеливо делиться знаниями. Не стоит переживать об отсутствии доскональных знаний по теме. Скорее всего, у тебя есть некий опыт, который даст возможность помогать менее опытным товарищам. Определи, в какой сфере ты накопил достаточно опыта, и начинай приносить пользу.

Как правило, наставники не попадают под сокращение.

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

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

Действуй!

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

2. Найди в интернете форум и выбери тему. Начни помогать. Приобрети репутацию человека, который хочет и может терпеливо помогать другим.

 

Совет 15

Практика, практика и еще раз практика

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

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

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

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

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

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

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

Тренируйся на пределе своих способностей.

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

♦ физические упражнения/координация;

♦ игра с листа;

♦ импровизация.

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

Физические упражнения/координация. Музыканты должны нарабатывать технику обращения с инструментом: генерация звука, координация движений (например, легкость перемещения пальцев), скорость и точность — все это крайне важно наработать.

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

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

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

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

После этого загрузи код программы и приступай к его анализу. Как понять, куда следует смотреть? Какими приемами ты пользуешься для поиска конкретного места в большом фрагменте кода? В какой точке ты начнешь работу?

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

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

Отличным способом заострить свой ум и улучшить способности к импровизации при написании кода является практика с самостоятельно наложенными ограничениями. Выбери простую программу и попытайся переписать с учетом ограничений. Моим любимым упражнением является написание программы, выводящей на экран строки старой песни «99 бутылок пива». Ты можешь это сделать, обходясь без присвоения переменных? Или попробуй минимизировать размер этой программы. В качестве дополнительного ограничителя может выступить время. Насколько быстро ты в состоянии написать код? Как насчет решения небольших сложных задач с таймером в руках?

Это всего лишь один из вариантов практики. Примеры можно добыть в любой области, от изобразительного искусства до религиозных практик монахов. Важно понять, в каких именно вещах тебе требуется тренировка, и, разумеется, никогда не тренироваться во время выступлений (на работе). Для практики нужно выделить отдельное время. Это только твоя ответственность.

Действуй!

1.  TopCoder. TopCoder.com — это сайт корпорации, проводящей соревнования по спортивному программированию. Ты можешь зарегистрироваться там и участвовать в соревнованиях с призами. Для тех, кто не любит соревноваться с другими, на сайте есть раздел с набором задач, которые послужат прекрасной основой для отработки практических навыков. Регистрируйся и начинай заниматься.

2.  Code Kata . Один из самых прагматичных программистов, наш любимый издатель Дэйв Томас (Dave Thomas), превратил идею наработки программистских навыков в… кое-что прагматичное. Его кодовая ката (code kata) — набор небольших, но провокационных упражнений. Программисты могут выполнять их на любом языке. Каждая ката делает упор на определенную технику или мыслительный процесс, нагружая один из твоих ментальных мускулов.

На момент написания этой книги Дэйвом была создана двадцать одна ката. Все они доступны в его блоге (http://codekata.pragprog.com/). Там же можно найти список рассылки и чужие решения этих упражнений, а также обсуждения способов решения.

Твоя задача — выполнить всё. Записывай результаты в дневник или веди блог. Закончив дело, напиши собственную кату и поделись ею с широкой публикой

 

Совет 16

Подход к работе

 

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

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

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

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

Очевидно, должен существовать лучший способ разработки программного обеспечения. И у большинства групп он есть.

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

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

Чтобы почувствовать причастность к процессу разработки, помоги с его внедрением.

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

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

 

Методики: Не только для зануд

Управление проектами далеко не всегда имеет отношение к методам разработки программного обеспечения, но ты можешь оказаться первым в своей компании, кто решил изучить данную тему. Многочисленные методики управления проектами широко используются во всей отрасли. Вероятно, самым известным является Свод знаний по управлению проектами (Project Management Book of Knowledge) [10]http://pmbok.narod.ru/
от Института управления проектами (с его общепризнанной программой сертификации).

Шесть сигм (Six Sigma) [11]http://www.six-sigma.ru/
— еще одна качественная методология, не связанная, впрочем, напрямую с программным обеспечением. Подход, продвигаемый такими монстрами, как General Electric и Motorola, придает особое значение измерению и анализу процессов и продукции для улучшения качества обслуживания клиентов и роста эффективности. Этот не имеющий отношения к разработке программного обеспечения, строгий и методичный подход предлагает данные, непосредственно применимые к работе программиста.

 

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

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

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

Действуй!

1. Выбери методику разработки программного обеспечения и найди посвященные ей ресурсы. Начни читать книги и сайты, присоединись к списку рассылки. Посмотри на эту методику критически. Выдели с твоей точки зрения сильные и слабые стороны. Что мешает внедрить ее на твоем рабочем месте? Изучи аналогичным способом еще одну методику. Сравни достоинства и недостатки обеих методик. Можешь ли ты скомбинировать предлагаемые подходы?

 

Совет 17

На плечах гигантов

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

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

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

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

Чтобы проникнуть в суть, анализируй чужой код.

Дизайн и программирование ПО в этом отношении во многом похожи на различные области искусства. В поисках шаблонов и трюков приходится анализировать огромные объемы готового кода. Образцы разработки, с которыми можно познакомиться в книге «Приемы объектно-ориентированного проектирования. Паттерны проектирования» (Design Patterns: Elements of Reusable Object-Oriented Software) появились как попытка обнаружить и документировать допускающие многократное использование решения часто возникающих при разработке программного обеспечения проблем. Они формализовали изучение существующего кода, сделав его доступным большому количеству профессионалов в области ПО. Тем не менее это всего лишь небольшой фрагмент обучающих практик, которыми мы можем воспользоваться посредством чтения кода.

Какими алгоритмами пользуются другие программисты для решения отдельно взятых задач? Как со стратегической точки зрения они именуют переменные, функции и структуры? Если бы я захотел реализовать протокол мгновенных сообщений Jabber на другом языке, как это можно было бы сделать? Какие нестандартные способы существуют для управления взаимодействием UNIX- и Windows-процессов? Изучение чужого кода позволит тебе найти ответы на эти и другие подобные вопросы.

Чужой код не только позволяет найти ответы на конкретные вопросы, но и служит своего рода увеличительным стеклом для рассмотрения собственного стиля и способностей. Прослушивание записей Джона Колтрейна (John Coltrane) всегда напоминает мне о моем уровне игры на саксофоне, аналогичный смирительный эффект несет чтение трудов выдающихся разработчиков программного обеспечения. Но это нужно не только для того, чтобы вспомнить про свое место. В процессе чтения их кода обнаруживаются вещи, с которыми ты сам вряд ли когда-либо справился бы. Ты может обнаружить даже то, о чем ты, скорее всего, никогда не додумался бы. Почему? О чем именно думал этот разработчик? Какой была его мотивация? Подобное придирчивое и углубленное изучение результатов чужого труда позволяет учиться даже на примере плохого кода.

Используй чужой код для оценки собственных способностей.

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

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

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

Положительным побочным эффектом чтения кода станет осведомленность о существующих видах программ. Получив новое задание, ты сможешь вспомнить: «Вот в этом и в этом проектах я видел библиотеку, опирающуюся на обработку MIME-типа». И если позволяют условия лицензионного соглашения, ты можешь сэкономить свое время и деньги фирмы, изучив особенности реализации уже готового решения. Возможно, ты удивишься, осознав, сколько денег в индустрии ПО снова и снова тратится на повторное изобретение колеса (впрочем, слово изобретение звучит в данном случае слишком сильно).

Сэр Исаак Ньютон сказал: «Если я видел дальше других, то лишь потому, что стоял на плечах гигантов». Такие умные ребята, как Исаак, знают, что мы многому можем научиться у тех, кто был до нас. Будь таким же.

Действуй!

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

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

 

Совет 18

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

Вместе с моим предприимчивым бывшим соседом, а ныне близким другом (Раджем Хаджелой) и моей женой (Видаей) я занялся мозговым штурмом, направленным на выявление неудовлетворенных потребностей на рынке. Нас привлекала электронная коммерция, но заниматься продажей товаров широкого потребления мы не хотели. Мы интересовались искусством и имели соответствующий опыт. Плюс ко всему привлекал тот факт, что каждое произведение искусства уникально по своей природе. Мой дядя-художник всю свою жизнь испытывал трудности с заработком. Исследования показали, что с этой проблемой сталкивается большинство художников. Появилась идея платформы, позволяющей художникам публиковать и рекламировать свои работы, поддерживая связь с постоянными покупателями. В результате появился сайт Passion4Art.com, а мы занялись сложным делом поиска художников, которые согласились бы там зарегистрироваться и предоставить цифровые копии своих картин. После регистрации первой тысячи пользователей, открывших у нас собственные страницы, выгода нашего предложения стала очевидной, поэтому мы занялись поисками внешнего финансирования.

В это же время (примерно в 1999 году) сайт eMazing.com ежедневно публиковал советы на самые разные темы. Мы подумали, что могли бы с ним скооперироваться (работая с нашими художниками и их каналами сбыта) и публиковать у них совет дня по искусству. С нами встретился один из их руководителей, оценил наше предложение и согласился попробовать.

После рассказа о поиске субсидий для развития инфраструктуры он любезно порекомендовал отправить наш бизнес-план в недавно появившийся в городе бизнес-акселератор bCatalyst.

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

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

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

Тогда я попросил еще об одной встрече с Китом и сказал, что собираюсь уйти из General Electric, чтобы на следующие несколько месяцев посвятить себя работе в его команде и совместному исследованию возможностей для открытия бизнеса. Я объяснил, что они ничем не рискуют, ведь я не прошу никаких долговременных гарантий (по аналогии с условно-бесплатным программным обеспечением). В итоге меня взяли на работу, потому что я смог убедить в своем желании поставить на карту все, уйдя из General Electric даже при отсутствии четких гарантий на будущее.

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

Я составил список и предлагаю вам с ним ознакомиться на случай, если вам когда-нибудь потребуется получить деньги от венчурной компании http://www.enterprisecorp.com/resources/assessment.htm .

Навыки, полученные за год работы в компании bCatalyst, привели меня на должность генерального директора Enterprise Corp. За семь прошедших лет мне довелось работать с более чем ста компаниями, которым я помог получить около 75 миллионов долларов. Я испытываю глубокое удовлетворение от своей работы, которую никогда бы не получил, не рискни я попробовать себя в совершенно новой области. Подобный процесс невозможен без крутых поворотов. Надеюсь, что вы, читатель, сможете использовать мою историю как источник вдохновения для поиска собственного уникального пути, который позволит в полной мере задействовать ваши способности.

 

Действуй!

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

2. Исследуй архитектуру, управляемую моделями (Model-Driven Architecture, MDA). Попробуй поработать с доступными инструментами. Посмотри, где в твоей работе можно применить если не весь инструментарий, то хотя бы некоторые концепции MDA. Подумай о применении этих концепций к ежедневно используемым тобой инструментам.