Недавно вышла статья, мимо которой я не мог пройти — "Программист не должен решать задачи бизнеса". Неожиданно мой комментарий вырос до мини-статьи. Я не согласен с мнением автора статьи, все сказано ниже ИМХО, с удовольствием подискутирую в комментариях. Сразу замечу, что я веб-разработчик, и все примеры я привожу в контексте своего опыта.
Лычки
Думаю стоит начать с лычек. К сожалению, 3 известнейших грейда не имеют четких определений, каждый человек и компания определяют требования индивидуально, границы которых размыты, а иногда это приобретает неожиданные обороты. Поэтому для начала стоит определить, что я понимаю под этими понятиями.
- Juinor — тут меньше всего проблем с определением, начинающий программист, который только-только выучил теорию, возможно, сделал пару pet проектов. Ну или только выпустился из университета.
- Middle — опытный программист, разбирается, а не просто знает стек-технологии, которые использует каждый день.
- Senior — это опытный программист, который обладает большим разноплановым опытом, имеет "production" работы на нескольких стеках и обладает "насмотренностью", обладает опытом в смежных областях (например: я считаю нормой, когда Senior Web может обладает навыками администрирования), спокойно может перейти с одного фрейворка на другой или даже с языка на язык без сильной просадки.
Хочешь не хочешь
Программист, хочешь или не хочешь, решает проблемы бизнеса. Всегда, но есть редкие исключения. Нужно понимать, что работа по найму или работа на себя — это всегда товарно-денежные отношения. Бизнесу нужно получать прибыль, с этой прибыли в том числе платиться зарплата сотрудникам. Из этого также следует, что для получения прибыли нужно решать проблемы (ну или можно сказать — решение задач бизнеса). Программисту же нужно на что-то жить, и желательно не плохо. Так же нужно понимать, что "пользу" бизнесу (или решать его проблемы) можно приносить по-разному — как косвенно, так и напрямую.
Как это происходит
Давайте разберем классический кейс, и на его примере посмотрим, как происходит решение проблем бизнеса. Прилетает задача — нужно сделать новый сайт, ничего особенного. Если упростить, то задача прилетает по такой цепочке: руководитель компании -> 1-& руководитель более низкого звена -> менеджер -> Тим Лид и дизайнер (как правило два разных отдела, поэтому задача ставиться параллельно) -> senior и/или сразу всем исполнителям. Есть два варианта дальнейших действий:
Кейс 1. Можно просто делать, что скажут, "тупо кодить" — то есть просто все делают в рамках своих прямых обязанностей — Тим Лид обсуждает с бизнесом и заводит задачки в джире, senior продумывает архитектуру и берет на себя наиболее сложные участки, junior верстает, а middle делает обычные задачи, возможно, и сложные вещи вместе с Senior (для упрощения, все Full Stack).
Кейс 2. Перед тем, как взять в работу, организуется несколько совещаний, на которых Senior с Тим лидом, дизайнерами и руководством обсуждают подробно проблему бизнеса. И даже не просто, как решить, а как решить эффективно для всех — и для бизнеса, и для разработчиков, и для дизайнеров. Находится золотая середина, устраивающая всех, и только после этого начинается уже собственно разработка.
Что в итоге?
В рамках первого варианта, когда все "тупо кодят" — в итоге решается проблема бизнеса. Другой вопрос, что она решается не эффективно — 100% срывы сроков, костыли, передача ответственности друг другу, потом, как правило, очень долгое исправление правок и добавление "новых пожеланий заказчика". Все потому, что делали задачу, как поставил ее бизнес. Никто не сказал, что так не нужно делать — все работали как "винтики" в рамках своих компетенций и не лезли решать проблему бизнеса. Здесь не было команды. После таких проектов, как правило, отношения к разработчикам не очень. Бизнесу важен результат. Умные руководители после этого как раз нанимают Senior, которые готовы решать проблемы бизнеса.
А теперь рассмотрим второй вариант. В этом случае максимальное количество подводных камней, которые случаются всегда, удалось решить командным взаимодействием. Не говоря уже о том, что разработчики могут кардинально изменить реализацию проектов, потому что бизнес может понимать не правильно что для этого нужно. Возможны ли в этом случае проблемы? Конечно, многое зависит от компетенций, но их точно будет несоизмеримо меньше. В этом случае также решается проблема бизнеса, но эффективно.
Инфраструктурные проекты
В комментариях к статье, ссылку на которую я приводил в самом начале, советуют перейти на инфраструктурные проекты. Что там как раз можно просто кодить. Это обманчиво. Разработчики так же решают проблемы бизнеса, внутренние. Это точно такие же товарно-денежные отношения. И проблемы такие же, как и при работе над внешним продуктом компании. Другой вопрос, что, как правило, инфраструктурные проекты пишут по первому кейсу. Отсюда и результат. Но даже здесь решаются проблемы бизнеса, и программист принимает участие в решениях.
Команда
Основное отличие первого и второго кейса даже не в реализации, а в команде. И под командой я подразумеваю не пару кодеров, которые реализуют проект, а всю компанию. В первом случае — просто отсутствие команды, во втором ее присутствие — все работают совместно, чтобы получился хороший результат. Понятно, что есть много допущений, но мир в целом не идеальный.
Решение проблем бизнеса != продажи
Я не знаю почему, но часто решение проблем связывают с продажами. Да, зачастую многие задачи с ними связаны, но это только один из факторов и зачастую не самый важный. Программист не должен задумываться о том КАК будут продавать, но он должен задумывать о том ЧТО будут продавать. От принятия чисто архитектурных решений (которые зачастую Senior и продумывает), скорости отклика, логики работы, дизайна (да, перед его разработкой программисту НУЖНО учавствовать в проектирование интерфейса) и т.п. — зависит качество конечного продукта. Даже инфраструктурный проект продают, но внутри компании. От качества конечного продукта зависит эффективность компании и соответственно персональные плюшки (не только материальные).
Исключения
В самом начале статьи, я говорил, что программист хочет не хочет — решает проблему бизнеса, но есть исключения. На мой взгляд единственное исключение, это pet проекты. То, что ты делаешь для себя. С натяжкой можно взять OpenSource, но там часто получается, что твой коммит решает проблему бизнеса, но не твоего.
Вывод
Программист ДОЛЖЕН решать проблемы бизнеса? Да, должен. На уровне своих компетенций, должности и опыта. Программист должен ПРОДАВАТЬ? Нет конечно, хотя навык далеко не бесполезный, особенно на высоких позициях. Можно ли просто кодить? Конечно, можно. Может ли Senior просто кодить? Нет, на просто кодить можно взять мидла.
Автор: Немировский Лев
