Как привлечь и удержать хороших IT-специалистов. Достигая тех высот

В марте 2000 года я запустил Web-сайт Joel on Software1, сделав довольно громкое заявление: большинство людей не правы, думая, что для создания успешной компании по написанию программ нужна идея. Вот мои слова.

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

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

Это очень удобная формула, особенно потому, что настоящей целью основания Fog Creek была компании по созданию программ, где нам хотелось бы работать. Еще тогда я объявил, что хорошие условия труда (или более коряво, "создание компании, где хотелось бы работать лучшим в мире разработчикам программ") должны привести к прибылям, причем так же естественно, как шоколад — к полноте и мультяшный секс в видеоиграх — к разгулу бандитизма.

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

Может, для нас это утверждение и очевидно, но для многих оно все равно нуждается в доказательстве.

Несколько лет назад сравнительно крупная компания собиралась купить Fog Creek, но я знал, что это невозможно, так как генеральный директор этой компании говорил, что в действительности он не согласен с моей теорией о найме самых лучших программистов. Аргументируя свою позицию, он использовал библейскую метафору: вам нужны только царь Давид вместе с армией солдат, которые просто должны выполнять его приказы. Впоследствии акции его компании заметно упали в цене — с 20 долл. до 5 долл. за штуку; поэтому хорошо, что мы не приняли предложение.

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

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

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

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

В сущности, разработка скорее увеличивает ценность, а не цену.

Или, попросту говоря, проявив скупость к программистам, вы создадите дорогие программы, которые даже не окупят своего производства.

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

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

Но я пока еще ничего не доказал. Что значит быть "самым лучшим программистом" и действительно ли программы, созданные разными программистами, так сильно отличаются по качеству?

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

Что касается меня, то я пользуюсь данными профессора Стэнли Айзенштата из Йельского университета. Каждый год он ведет интенсивный курс программирования (CS 323), по большей части состоящий из пяти заданий по программированию или что-то вроде этого. На выполнение каждого из них дается примерно две недели. Для вузовского курса обучения это очень серьезные задания: реализовать для системы Unix оболочку командной строки, реализовать программу ZLW-сжатия файлов и т.д.

Студенты были так недовольны слишком большой работой, требуемой на освоение курса, что профессор Айзенштат стал просить их сообщать, сколько времени они потратили на каждое задание. Эти данные он тщательно собирал в течение нескольких лет.

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

Первое, что я сделал с этими данными, — подсчитал для часов, потраченных на каждое из заданий, среднее, минимум, максимум и стандартное отклонение. Результаты моих расчетов приведены ниже.

Сильнее всего здесь бросается в глаза громадный разброс значений. Самые быстрые студенты справлялись с работой в три-четыре раза быстрее, чем средние, и в десять раз быстрее, чем самые медленные студенты. Стандартное отклонение оказалось крайне большим. Поэтому я подумал, что, скорее всего, для некоторых студентов задание оказалось ужасно сложным. Мне не хотелось учитывать тех студентов, которые, потратив на задание четыре часа, не смогли создать работающей программы. Поэтому я рассматривал данные только по студентам, находящимся в верхнем квартиле успеваемости, ...т.е. среди лучших 25% по качеству кода. Должен сказать, что оценки на курсе профессора Айзенштата полностью объективны: они вычисляются по формулам, где используется только количество пройденных автоматических тестов кода. За плохой стиль никакие баллы не вычитались.

Разница не слишком большая! Для верхнего квартиля стандартное отклонение почти одинаковое. И действительно, если внимательно просмотреть данные, то станет достаточно ясно: заметной корреляции между временем и оценкой нет. Вот типичный разброс данных по одному из заданий. Выбираю задание COMPRESS01, посвященное реализации алгоритма сжатия Зива-Лемпеля-Уэлча и предложенное студентам в 2001 году. Дело в том, что стандартное отклонение по этому заданию достаточно близко к общему стандартному отклонению.

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

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

Эти данные не совсем научные. Скорее всего, в них заложен определенный обман. Кое-кто из студентов может завысить время, потраченное на задание, надеясь добиться от преподавателя определенной симпатии и получить в следующий раз задание полегче. (Желаю удачи! В CS 323 задания сейчас такие же, как и во время моего обучения, т.е. в 80-х годах XX века.) Другие студенты, наоборот, занижают время, потому что сбились с темпа. Тем не менее, сделанный на основе этих данных вывод, что производительность разных программистов может отличаться как 5 : 1 или 10 : 1, я не считаю таким уж преувеличением.