Когда вышло первое издание на русском языке хорошо известной книги «Как пасти котов», посвященной непростой теме управления своенравными по натуре профессиональными и не очень разработчиками ПО, мой более опытный коллега руководитель проектов подметил: “Правильнее было бы её назвать «Как пасти скотов»”. Фраза запомнилась, и как показывает накопившийся с тех пор опыт взаимодействия с программистами — коллега был прав.

Как программистов ненавидят их коллеги

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

Сегодня, Мой Юный Дружок, я опишу тебе мир глазами твоих коллег и расскажу тебе о том, каким в этом мире предстаёшь для них ты, Разработчик ПО, Великий и Всегда Правый Программист. Ты уверен, что являешься Центром Вселенной, подобно твоему коту, и что тебе все обязаны по гроб жизнидо окончания проекта. Это твоё мнение подкреплено в том числе количественным превосходством твоей когорты в проектной команде, но на самом деле в доброй половине проектов, в которых ты, юный или уже седеющий, но так и не поднабравшийся ума-разума дружок принимаешь участие, остальная часть команды тебя тихо ненавидит за твоё всезнайство и излишнее самомнение. Твой снобизм перекрывается разве что непомерным и чрезмерно раздутым снобизмом архитектора, но о той касте разговор пойдёт как-нибудь в другой раз.


Бизнес-аналитик ненавидит тебя за нереализованные якобы по случайному недосмотру наиболее трудоёмкие части спецификаций.

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

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

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

Впрочем, обо всём по порядку.

Жизненный путь рядового программиста

Как-то, после одного успешно проваленного проекта, я, с согласия руководителя отдела разработки, подготовил для группы программирования презентацию, в которую помимо прочего включил «график» изображающий «жизненный путь программиста», от его самого начала, кодирования в блокноте в школьном возрасте, через освоение интегрированных сред разработки (20 лет), управление дефектами (25 лет) и взаимодействие с прочими группами специалистов и внешними подрядчиками (30 лет), до применения практик постоянного интегрирования и автоматического развёртывания релизов, достигаемых к появлению седых волос 35 годам (возрастные вехи, разумеется, условны, и служат лишь иллюстрацией к усреднённому жизненному пути). Программист, как возможно никто другой в современном мире, вынужден постоянно учиться и совершенствоваться в техническом и профессиональном плане, и очень многие в этом весьма и весьма преуспевают. В то же время большинство из тех, кто по написанию первой в своей жизни свисто-перделкипрограммы «Hello, World» и публикации резюме на hh.ru / monster.com сразу начинают растопыривать пальцы на собеседованиях и горделиво называть себя «настоящим профессионалом», — таковыми на самом деле не являются.

В том проекте один разработчик умудрился забыть выложить обновлённый код в общий репозиторий и два его коллеги полдня в экстремальном режиме пытались определить — почему же функция не работает так, как заявлено? Другой разработчик допустил ошибку в скрипте развёртывания, и если бы она не была замечена руководителем проекта(!), внедрение результатов совместной работы команды за целую итерацию было бы отложено до следующего цикла выпуска кода в продуктовое окружение, т.е. на 2 недели.

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

Взаимодействие со специалистами-непрограммистами

Да будет тебе известно, Мой Умелый Дружок, что иные специалисты, с которыми ты бок о бок трудишься в проектной команде, такие как тестировщики, аналитики, технические писатели, дизайнеры и прочие, несут ответственность за успех проекта ничуть не меньшую, чем ты, о чудо Вселенной. И все эти нелюди играют роль неменьшую, а в некоторых проектах даже большую, чем твоя роль кодировщика, и поэтому грамотное и благожелательное взаимодействие с ними является неотъемлемой и ключевой частью твоей работы, за которую ты два раза в месяц получаешь у банкомата немалые деньги (к слову — деньги гораздо большие, чем из того же банкомата вынимают все эти люди). Ты же зачастую, смотришь на них и их проектные потребности свысока или же сквозь пальцы, без того внимания, которого они справедливо требуют. А потребности и профессиональные ожидания у них имеются, причём различные, в зависимости от их ролей.

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

Тестировщица вправе ожидать от тебя безглючного качественного результата твоего труда. При приёме на работу ей было обещано и потому она ожидает, что она не будет являться частью методологии разработки TDD, согласно которой ты, МУД, «выкидываешь» недоделанный продукт в тестирование и по его итогам доделываешь пропущенные куски функциональности и исправляешь очевидные дефекты. И ещё тестировщица непременно ожидает, что ты не будешь гнобить её за то, что она не умеет тестировать продукт иначе как вручную, или что её навыки работы с языком запросов к БД существенно ниже твоих. В конце концов не забывай, что и платят за ручное тестирование ей в разы меньше, чем тебе за программирование, и что если бы она знала SQL так же хорошо, как и ты, то в твоём кресле перед твоим монитором сидела бы она, а не ты, потому как при равных квалификациях между вами именно её предпочли бы оставить в команде и организации, потому что она, в отличие от тебя, пройдя нелёгкий путь тестировщика никогда не будет гнобить коллег по цеху так, как это делаешь ты.

Инженерное знание технологий

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


«Версионирование? Комментирование кода? Придерживание стандартам кодирования и именования? Не, не слышал!» Так говорят твои коллеги там и здесь в самых разных проектных командах и организациях. Юный дружок, ты повсеместно ноешь ото всего, что не связано непосредственно с «колбашением кода»: о необходимости добавлять комментарии, покрывать код блочными тестами в соответствии с установленными в компании или отделе стандартами, сливании воедино (merge) веток репозитория… Что уж говорить о более комплексных вещах, требующих повышенной или по настоящему высокой квалификации: автоматизация тестирования, внедрение и поддержка постоянного интегрирования, настройка связок Bamboo-Cucumber-Maven-Puppet, многочасовое копание в системных логах в поисках свидетельств программных ошибок — всё это для тебя скукота и муть, которые не позволяют тебе совершенствовать навыки непосредственно кодирования и которые ты находишь принижающими твоё ЧСВ. Причём отказом от использования тех или иных технических средств ты, профессиональный разработчик ПО, зачастую попросту скрываешь неумение ими пользоваться. Я помню реакцию и лицо одного программиста, которому в качестве попытки уловить труднонаходимый «плавающий» дефект предложил воспользоваться профайлером встроенным в IDE: мне было указано, что это не собачье дело руководителя проекта советовать, какими средствами программист должен пользоваться в своей работе.

Навыки работы с инструментарием

Насколько твоя работа в рамках твоей рабочей станции автоматизирована? Ты прокачал свои навыки в работе с регулярными выражениями, создании и выполнении пакетных файлов? Ты можешь по запросу коллеги, тестировщицы, аналитика или заказчика за 3 минуты пропарсить пару сотен тысяч строк лога на удалённом сервере, найти нужное вхождение ключевого параметра, запаковать вывод, переслать его на указанный адрес и вернуться к выполнению прерванной задачи? Как быстро, МЮД, ты умеешь выполнять рутинные операции, требующие многократного повторения в течение рабочего дня?

Как известно, запуск компиляции в современных средах разработки возможен по нажатию клавиши F5 (или F6? Или F13?.. В конце концов почему я, руководитель проектов, должен знать такие вещи? Ты же не знаешь, МЮД, как быстро, за пару минут выгрузить из Jira, отформатировать надлежащим образом в Excel и послать по электронной почте заказчику отчёт о дефектах c блек-джетом и шлюхамиграфиками и трендами, но при этом никогда не преминёшь подколоть в курилке среди своих коллег своего «пиэма», что тот туп и не знает, чем деструктор отличается от конструктора). Но за достаточно долгую уже карьеру я встречал не так много программистов, использующих комбинации КБД на клавиатуре для вызова тех или иных стандартных действий — большинство для этого используют более медленный манипулятор «мышь». Условные «Tab — 1000 — Tab — 1 — Tab — 0 — Tab — Backspace — 2 — Ctrl+S — Ctrl-F6 — Enter, Alt-Tab, F5» за 6 секунд позволяют настоящему профи выполнить то, что елозением мышки и тыканием указательными пальцами по клавиатуре неумёха делает долгих пять минут. И когда такие операции выполняются по сотне раз на дню, в условиях приближающегося дэдлайна иному руководителю проекта иногда хочется взять и ......отодвинуть такого «профессионала» от клавиатуры и самому внести изменения / откомпилировать / выложить исполняемый код и дать отмашку группе тестирования, что новая сборка наконец готова.


Поэтому, МЮД, не поленись и потрать время на освоение слепой десяти-пальцевой печати и методов эффективной работы с инструментарием и поверь более опытным людям, пусть некоторые из них и являются так нелюбимыми тобою руководителями проектов, — это время тебе окупится сторицей. А пока ты, юный неумёха, не достиг в этом совершенства — Иди, уткнись в монитор и Пиши Код, Бл..!

Оценка трудозатрат

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

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

«Индусский» код

Одно из твоих любимых занятий — критиковать программный код, созданный индийскими разработчиками. Тебя хлебом не корми, но позволь лишь поизмываться над «макаронным» стилем программирования. Больше, чем обсуждать «индусский» код, ты лишь любишь болтать о технологиях (см. ниже). И это всё при том, что сам ты именуешь методы гордым именем kolbasa(), незабвенно копируешь куски кода в разные места программы и создаешь классы размером на десяток-другой экранов.

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

Бесконечное обсуждение технологий

Ты бесконечно обсуждаешь с другими программистами в чём Java++ превосходит C## или чем версия номер сто двадцать девять дробь пятнадцать какой-нибудь Javascript-библиотеки лучше версии сто двадцать девять дробь тринадцать. На такие обсуждения тебе никогда не жалко времени даже в те дни, когда до конца итерации или многомесячного проекта остаётся 2-3 дня или недели и количество назначенных на тебя неисправленных серьёзных дефектов превышает полсотни.

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

Нытьё по поводу «ненужных» митингов

Поэтому, когда после того, как ты только что проточил лясыпроговорил 2 часа на кухне / в курилке с полудюжиной таких же говнокодеров о новейшем фреймворке / вчерашней пресс-конференции Google-Microsoft-Apple-Линуса Торвальдса, чем украл пару-тройку человеко-дней разработки, ты вдруг на разборе завершенной итерации заявляешь о том, что в проекте проводится слишком много никому ненужных совещаний и надо бы их подсократить — в ответ на это тебе хочется проорать лишь одно: заткнись и ИПКБ!!!

Грамотный русский язык

Ну и в конце, как говорится, последнее, но далеко не самое неважное. Даже если ты, МУД, в совершенстве знаешь такие языки, как C## или МозгоЁб — это совершенно не избавляет тебя от необходимости грамотно писать и говорить по-русски (да и по-английски тоже, XXI век на дворе). Поэтому, прежде чем в следующий раз ты сподобишься писать спецификации, комментарии к коду, письма заказчику или свои многоумные статьи и комментарии здесь или на каком-то другом ресурсе для быдлокодеров — иди и сначала как следует выучи русский язык, бл..! Сделай это, чтобы что_бы ты ни писал — любой грамотный человек читал бы это с лёгкостью и радостью, а не спотыкался на каждой твоей орфографической ашыпке. Посети и выучи наизусть содержимое сайта tsya.ru и запомни уже наконец, что «тестер» — это прибор для определения значений различных параметров электрической сети, а специалиста по тестированию ПО называют "тестировщик" и что «функционал» — это математический термин, а набор возможностей программного продукта называется «функциональность», бл..!!111

Эпилог

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

---

Дополнение

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

Конечно, далеко не все разработчики, профессионально трудящиеся на ниве ИТ, похожи на описанных в статье. Автор согласен с широкораспространенным мнением, что программист-эксперт производительнее своего начинающего коллеги в 10 раз. Производительность разработчика средней руки примерно в 3 раза выше, чем у новичка, лоботряса или неумёхи и продуктивность, конечный выхлоп от эксперта, гуру, “зубра” также примерно в 3 раза выше такового от рядового профессионала.

По моему опыту количественные соотношения числа низкоквалифицированных разработчиков к обычным и обычных к экспертам примерно такие же: 1 к 3 и 3 к 1. Эти пропорции могут сильно варьироваться от одной организации к другой, но в среднем достаточно верны. За всё время своей карьеры мне довелось поработать с четырьмя людьми, которых я в полной мере отношу для себя к категории “звёзд” (крайняя часть “спектра”). Они умели всё необходимое для реализации поставленных перед ними задач, плюс многое сверху того, квалифицированно оценивали трудозатраты, выполняли работу в отведённый для неё срок, после своей работы в проекте, над продуктом или в компании оставляли чётко задокументированные артефакты.

“Обычных” программистов, тех, что умели делать многое из того, что умели “звёзды”, но не всё вместе, было абсолютное большинство. Их данная статья, очевидно, не касается, или касается лишь тем, что некоторые из приведённых зарисовок могут вызвать у них улыбку наподобие “а, да, точно, я, помнится, в компании XYZ поступал так же, господи, какой же дурак я тогда был (два / пять / двадцать лет назад)!”.

Примерно столько же, сколько и “звёзд”, мне повстречалось настоящих “раздолбаев”, как раз таких, какие неприглядно расписаны в статье: зазнаек, торопыг, неумёх, смотрящих свысока на всех своих коллег, которые не являются программистами по должности (кроме своего непосредственного начальника), нежелающих учиться или невидящих в этом необходимости “икспертов”.

Последней категории как раз и посвящена данная статья.