Программисты с аллергией на предметную область
В 2012-м году Wikileaks начал публикацию закрытых документов частной разведывательной компании Stratfor, известной, как «теневое ЦРУ». Среди прочих, был обнаружен документ связанный с онбордингом — словарь терминов для новых сотрудников. Вступительное слово к этому словарю выглядело так:
«Каждая предметная область имеет свои собственные термины, бесполезно обсуждать футбольный матч, используя термины, например, из бейсбола, поэтому в этом документе собраны термины, которые используем мы».
Далее следует страниц двадцать подробного разбора специфичных (и не очень) терминов, дабы познакомить новичков с местной кухней. Изучать мы их, конечно, не будем, но давайте поговорим об отношении к предметной области среднего разработчика, какие встречаются чаще остальных.
Пример из практики
Однажды, в мою команду пришёл джун, хотя сам он всем говорил, что миддл с пелёнок и даже проводит вебинары для студентов каких-то там курсов, мол собаку съел на вашей разработке (он не кореец — это фигура речи). Да и позиция не предполагала, что на ней окажется джун, но интервью тогда проводили, увы, без моего участия. Примечательно, что посыпался он не столько на нехватке знаний и навыков, сколько на резком нежелании разбираться в предметной области бизнеса, который он собирался автоматизировать.
Постановка задачи превратилась в головную боль: сложная коммуникация, ошибки, связанные с непониманием данных, разночтения, когда каждый кивает и говорит «понятно», но «понятно» как-то по-своему, по-особенному и вы уходите на второй, третий и, в конце концов, десятый круг разбора задачи. Пренебрежение предметной областью одним единственным разработчиком приносило неудобства всей команде и отнимало много времени, не вдаваясь в подробности — это было слишком дорого для всех нас. Он, простите, погроммист, ему эти две четверти или три тайма и, тем более, четыре периода в этом вашем снукере вообще по-барабану — аллергия на спорт (если у вас тоже, не обращайте внимания — это смешная шутка про виды спорта, который и был предметной областью).
Дисклеймер
Возможно, как руководитель, я не имею права перекладывать ответственность на нерадивого сотрудника и вообще сам виноват. Просто нам было не по пути и я уверен, что у него всё прекрасно, он вырос и отличный специалист. Но факт остается фактом, посредственные профессиональные навыки разработчика, ну те, что принято звать твердыми (включить компуктер или открыть IDE), оказались не так важны по сравнению с острой непереносимостью предметной области, а скорее с непониманием того, что это важно.
Вавилоняни
Можно ли рядовому кодеру не заморачиваться с пониманием предметной области и писать качественный, производительный код? Совершенно точно — да.
Если не верите, пройдитесь по компаниям и их совещаниям: пол дня два участника спорят, десять их молча слушают, а те решают проблему, которой ещё, как окажется и не существует. Невольно начинаешь оглядываться: кажется, что вдалеке шумят Тигр и Евфрат, а где-то поблизости вот-вот рухнет та самая башня, языки то уже смешались и никто друг друга понять не может. И что? И ничего — работают, к тому же успешно, раз банкет кто-то оплачивает.
Принеси то, не знаю что
Часто (чаще, чем вы можете себе представить и в местах, где «ну там то такого точно не может быть») бывает так, что все делают свою работу на пять с плюсом, но проблема бизнеса не решена и пользователь уже заплакал клавиатуру крокодильими слезами в попытках получить то, что ему требуется. Зато код — произведение искусства, производительный, даже SonarQube вами восхищается (это инструмент такой для анализа кодовой базы, с блекджеком и метриками).
Так происходит в том числе и потому, что исполнитель (программист) не в состоянии провалидировать задачу, не знает своего пользователя и не понимает проблемы бизнеса. Важно понимать, что это нормальная ситуация для совсем зеленого жуна: пусть тимлид с наставником эти вопросики обкашляют, он ещё синтаксис языка не до конца знает. Или, скажем, в заказной разработке — крыша поедет глубоко погружаться в предметную область каждого проекта.
Но в любом другом случае (на мой взгляд), понимать предметную область для программиста жизненно необходимо. Из бонусов: вы можете существенно сократить объем бестолковой работы, повлиять на выпуск продукта, который реально работает. Не в смысле, что кнопочки нажимаются, а джейсончики перекладываются — нет. В смысле, что проблема бизнеса решается, а пользователь получает то, что должен (унижение, презрение и проблемы — это не то).
Шейп ав май харт
Допустим погрузились в предметную область, имеется отличный программист: понимает бизнес и понимает пользователя. Вот бы ему в копилочку (не представляйте декольте сантехника, прошу) загрузить ещё пресловутого T-shape и будет совсем счастье. Чем занимается продакт? А проджект? Тестирование и дизайн? Аналитики вообще делают какую-то работу? С тимлидом-то понятно — этот всё делегировал.
Нет, не поймите неправильно, не надо досконально разбираться вообще во всей «чужой» работе, она на то и «чужая», но понимать смежников и этапы, на которых вы соприкасаетесь — бесценно. Например, фронтендир, который умеет в UX не хуже вашего дизайнера, а не только готовит отличный тыквенный латте, менеджер с техническим бэкграундом может быть крайне приятным в работе, как и дизайнер, который понимает ограничения и возможности разработки, ну, а скрам-мастер, который… которого выгнали с позором (да, я знаю, что скрам-мастер это просто роль, но пройти мимо не мог). Всё это повышает шансы сделать что-то реально хорошее, а не просто какой-то код. И пусть этот код совершенный, только может оказаться, что он совершенно бесполезный (а вы и не в курсе).
Лучшее, что может сделать программист для себя и для команды — разобраться в предметной области. Кто поспорит?
Заключение и мотивация
Мне бы хотелось, чтобы на моём пути (в командах, на собеседованиях, в сообществах) встречалось гораздо больше осознанных разработчиков-профессионалов, понимающих, что язык программирования — это всего-лишь инструмент; код сам по себе ничего не стоит, если не решает проблему бизнеса; «чужая» работа (к сожалению или к счастью) не совсем «чужая», так как влияет на вашу и ещё много разного и полезного, что наполняет ежедневную рутину смыслами. А без смысла вы как угли в печке: уже задумываете новую статью на скатившийся Хабрахабр о том, как вы сгорели.
Powered by Программистика — телеграм-канал для программистов, в котором мы не переписываем документацию, а говорим о вечном — о том, что важно (и не всегда очевидно) в работе программиста и, конечно, шутим. Приходите, подписывайтесь, участвуйте в обсуждениях, если что-то из сказанного отзывается где-то в сердечке. Всем хорошего рабочего дня, держите огнетушитель поблизости.
