69
В некоторых организациях разработчики это короли, а в других они пешки.
(Прим. пер. — Не так давно мне в руки попала новая книга от Tom DeMarco сотоварищи — Adrenaline Junkies and Template Zombies. Основная цель этой книги — на основе анализа проектов по разработке программного обеспечения, выделить основные шаблоны, по которым существуют такие проекты и попытаться их систематизировать. Прикладывать понятие шаблона к живым людям оказалось гораздо интереснее, чем к программному обеспечению, поэтому книга читается с удовольствием и практически каждый найдет в своем опыте пример того или иного шаблона, если не всех. Я буду выкладывать переведенные главы по одной в случайном порядке, так что если будет интерес, то надеюсь перевести всю книгу).
Манстры это был американский ситком, который стартовал в 1964 году и продержался два сезона. В нем рассказывалось про шумную жизнь семьи монстров, которые жили в обычном городе. Отец, Херман Манстр, это бестолковая версия монстра Франкенштейна; его жена — вампир; дед напоминает графа Дракулу из водевиля;, а их сын, Эдди, маленький оборотень.
Удивительно, но племянница Манстров, Мэрилин, которая живет с ними, являет собой красивую (Прим. пер. — Ну для 60-х годов) студентку колледжа. Однако семья не считает ее красавицей, а совсем наоборот — полной уродиной. Они пытаются защитить ее чувства, но все равно немного стесняются ее. И одна из основных идей сериала заключается в том, что такое отношение к Мэрилин обусловлено только тем, что она родилась в такой странной семье. И совершенно ясно, что в любой другой семье в округе, она была оценена по достоинству.
Многие разработчики живут жизнью Мэрилин Манстер. Они работают на компаниях, которые зависят от технологий, но их работа не ценится, и они имеют очень низкий статус в структуре. Во многих таких организациях менеджеры получают всю полноту власти. Менеджеры отвечают за планирование, составление календарного плана, отслеживание, оценки, и назначение работ техническим специалистам. Планирование, составление календарного плана, отслеживание и оценки обычно делаются только менеджерами с участием других менеджеров. Разработчики в этом случае просто профаны, кто «не понимает» как это действительно сложно управлять компанией.
Менеджеры зашибают большие деньги, потому что они отвечают за то, какой проект запустить, и за работу над проектом, который выбрали главные шишки. Технари же должны склонить головы и делать то, что сказали им делать менеджеры. Если им это не нравится, то они могут уходить — менеджеры, вместе с HR, найдут им замену. Замена может работать по трудовому договору и не в штате компании, или может быть вообще на другом континенте, где технические профаны дешевле, чем в штаб-квартире. Есть другой варинт этого шаблона, когда все одеяло на себя перетягивают Продажники. В принципе, вполне логично, что неважно как хорош твой продукт если ты не сумел его продать.
Действительно во что верят такие компании, так это то, что разработчиков много, все они одинаковы и все одинаково хороши, и платить им надо так мало как это только возможно, чтобы они выполняли свою работу.
Конечно есть и другие типы компаний, с совершенно другим взглядом на разработчиков. Эти компании верят, что их продукты и услуги отличаются от конкурентов по качеству и инновационности. Они понимают, что есть огромная разница в способностях и производительности между лучшими 10-ю процентами разработчиков и средним разработчиком. Они хотят лучшее, что могут получить. Это результат культуры в которой разработчики это короли, которые имеют свободу выбора в том над чем работать и как достигать результатов. Такие разработчики часто определяют возможности продукта и сами же создают его. И они же обычно бывают первыми, кто оценивает сделанную работу. Самые опытные разработчики могут стать руководителями команды, а иногда и больше. Очень часто, но не всегда, разработчики это короли в организациях, которые разрабатывают программное обеспечение или программное обеспечение является главным компоненом их продукта.
Однако перебарщивать с «культурой разработчиков-королей» не стоит. Когда разработчики сами оптимизируют свою работу и планируют не обращая внимания на влияние этих решений на остальных членов команды, проекты могут ожидать неприятности. Например, мы сталкивались с проектом в котором два разработчика решили, что они будут сначала делать каркас приложения — оставлять многие классы не законченными, чтобы дописать их потом. А сосредоточиться на самых интересных, для них, моментах. Остальные члены команды, тестировщики и технические писатели начали свою работу, только когда дата сдачи проекта была уже близка, потому что им прото нечего было делать. Не было ничего, что можно было бы потестировать или задокументировать, пока все внезапно не станет готово (когда разработчики заполнят пустоту, которую они оставили). Таким образом разработчики разоптимизировали проект, оптимизировав собственную работу.
Если вы нанимаете разработчиков, спросите себя, насколько важны качество и инновации для успеха вашей организации. Для максимальных уровней качества и инноваций необходимы действительно талантливые разработчики. Вы не сможете привлечь, взрастить и сохранить самых талантливых если вы обращаетесь с ними так, словно зря тратите на них деньги.
Если вы отличный разработчик и вы чувствуете себя как Мэрилин Манстер, не сомневайтесь, вокруг много других семей, которые смогут оказать вам уважение, которого вы заслуживаете. Спасайтесь из этого шоу уродцев.<