🧠 Разработчик vs исполнитель кода: почему думающий специалист ценнее
Недавно наткнулся на интересный спор в комментариях под статьёй о профессионализме. Два противоположных подхода к работе:
Позиция А: "Если ТЗ составлено нечётко — не буду делать задачу, пока не уточнят все детали"
Позиция Б: "Это низкая квалификация. Чем такой разработчик отличается от GPT, которой дай чёткое ТЗ — и она всё сделает?"
Звучит как холивар, но давай копнём глубже.
Проблема обеих крайностей
Представь: к работяге приходит мастер и говорит "сделай балку".
Он молча берётся за работу. Через два часа мастер возвращается: — Ну что? — Вот, сделал.
А он просто металл с двух сторон обрезал. Технически — всё по ТЗ. Но балка не выдержит нагрузку и рухнет.
Работяга не уточнил: - Какая нагрузка? - Где будет использоваться? - Какие требования к прочности?
Голову не включил. Зато формально ТЗ выполнено ✅
А теперь обратная ситуация
Разработчик получает задачу: "Добавь кнопку для экспорта данных"
И говорит: "ТЗ неполное, не буду делать. Напишите мне: - В каком формате экспорт - Какие поля выгружать - Какой дизайн кнопки - Где она должна быть - Как должна называться"
Формально — профессионально. Но на практике — он просто перекладывает свою работу на менеджера.
Потому что ты эксперт. Ты видишь систему, знаешь контекст, можешь предложить решение.
Что делает инженер?
Получает задачу "добавь экспорт" и:
1. Анализирует контекст: какие данные уже есть, как организована таблица, что экспортируют конкуренты 2. Задаёт правильные вопросы: "Я вижу три варианта — CSV, Excel и JSON. Для отчётности лучше Excel, предлагаю его. Окей?" 3. Предлагает решение: "Кнопку логичнее разместить над таблицей справа, рядом с фильтрами. Так делают в админках" 4. Думает о крайних случаях: "А если данных 100к строк? Добавить асинхронную выгрузку?"
Видишь разницу?
Ты не просто ждёшь идеального ТЗ. Ты включаешь голову, предлагаешь, уточняешь. Истина посередине
Менеджер не всегда технически подкован. Он может не знать про лимиты браузера, производительность, паттерны UX.
Ты как эксперт можешь и должен: - Видеть проблемы, о которых менеджер не подумал - Предлагать улучшения на основе технического опыта - Говорить "нет", когда сроки нереальные (да, это тяжело 😄)
Но делать это нужно конструктивно: - Не "ТЗ хуёвое, переделывай" - А "Вижу три риска в этом подходе. Предлагаю альтернативу..."
В итоге
Разработчик высокой квалификации — это не тот, кто слепо выполняет ТЗ. И не тот, кто отказывается работать без идеальной спецификации.
Это тот, кто думает системно, задаёт вопросы, предлагает решения.
Как говорят бизнесмены — win-win. Все в плюсе: - Продукт получается лучше - Менеджер видит твою ценность - Ты растёшь как специалист
Не будь камнем. Идти на контакт, видеть проблемы, говорить о них — вот что отличает инженера от исполнителя кода.
А как ты подходишь к задачам? Делишься мыслями в комментариях 💬
· 17.12
Продуктовые решения (например, в каком формате выгружать файл) должен принимать тот, кому платят за продуктовые риски. Иначе ты, как специалист, пытаешься принимать решения, за которые не несёшь ответственность.
Тут правильно предложить варианты решений вопроса, которые ты видишь на своём уровне и оставить итоговое решение тому, кто за это решение отвечает своей зарплатой или должностью.
То же относится 4 вопросам дизайна, аналитики, бэкенда и т.д...
Лезть в чужую зону ответственности, если уж очень хочется, нужно осторожно, тщательно всё обдумав, и оставляя артефакты работы (к примеру, в jira). Чтобы и коллегу не подставить, и самому не оказаться в случае чего крайним.
ответить
коммент удалён
· 17.12
Да, безусловно, лезть в чужую миску плохо
Ребят, я привел абстрактные примеры, чтоб показать проблему на мой взгляд - бездумчивое исполнение
Если ты прочел ТЗ, в которм, написана что зачем и как сделать и тебе все понятно - чудесно
Но если есть спорные моменты, не точности, опять же на мое виденье, спроси, уточни - а не молча делай или реджектить с комментом «опишите все полностью», без уточнения моментов к которым у тебя вопросы
ответить
ответ удалён