Не берись делать то, чего не понимаешь | OTUS
🔥 Начинаем BLACK FRIDAY!
Максимальная скидка -25% на всё. Успейте начать обучение по самой выгодной цене.
Выбрать курс

Курсы

Программирование
iOS Developer. Basic
-25%
Python Developer. Professional
-25%
Разработчик на Spring Framework
-25%
Golang Developer. Professional
-25%
Python Developer. Basic
-25%
iOS Developer. Professional
-25%
Highload Architect
-25%
JavaScript Developer. Basic
-25%
Kotlin Backend Developer
-25%
JavaScript Developer. Professional
-25%
Android Developer. Basic
-25%
Unity Game Developer. Basic
-25%
Разработчик C#
-25%
Программист С Web-разработчик на Python Алгоритмы и структуры данных Framework Laravel PostgreSQL Reverse-Engineering. Professional CI/CD Vue.js разработчик VOIP инженер Программист 1С Flutter Mobile Developer Супер - интенсив по Kubernetes Symfony Framework Advanced Fullstack JavaScript developer Супер-интенсив "Azure для разработчиков"
Инфраструктура
Мониторинг и логирование: Zabbix, Prometheus, ELK
-25%
DevOps практики и инструменты
-25%
Архитектор сетей
-25%
Инфраструктурная платформа на основе Kubernetes
-25%
Супер-интенсив «ELK»
-16%
Супер-интенсив «IaC Ansible»
-16%
Супер-интенсив "SQL для анализа данных"
-16%
Базы данных Сетевой инженер AWS для разработчиков Cloud Solution Architecture Разработчик голосовых ассистентов и чат-ботов Внедрение и работа в DevSecOps Администратор Linux. Виртуализация и кластеризация Нереляционные базы данных Супер-практикум по использованию и настройке GIT IoT-разработчик Супер-интенсив «СУБД в высоконагруженных системах»
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02

Не берись делать то, чего не понимаешь

Написать эту статью меня натолкнул один случай. В моей команде двое junior-девелоперов: парень и девушка, и девушке я делал код-ревью. Задача была простая: ранее она написал экстеншн-метод (extension method из .NET) для валидации свойств объекта, и я предложил перенести этот экстеншн в сам класс объекта в качестве публичного метода. Девушка перенесла метод и в качестве аргументов передавала те же свойства, которые нужно было провалидировать. Это было странное решение, ведь свойства объекта доступны в самом методе, поэтому нет нужды передавать их извне. Я написал ей в Slack, зачем она так написала. Разработчица мне ответила, что теперь поняла суть задачи и пообещала переделать в ближайшее время.

Суть проблемы не в том, что был написан неоптимальный код. Девелопер признался, что реализовал задачу и отправил ее на код-ревью, хотя не уловил суть задачи. Именно “не уловить суть задачи” и есть, как мне кажется, гораздо более важная проблема.

Я встречал такое раньше. Я и сам в начале своей карьеры бросался имплементировать задачи, даже когда не понимал их, и для чего они предназначены. Когда приходилось переделывать имплементацию, я задумывался, почему же так получалось. После раздумий я пришел к выводу, что причина — непонимание задачи и того, что хотят видеть в итоге, а главное — какую проблему решают.

Этот вывод может показаться очевидным для опытных разработчиков, однако для меня тогдашнего это было чем-то вроде откровения с небес. Мир как будто перестал быть прежним в тот момент. Я начал относиться к задачам более скептически и всегда стал задавать себе вопрос: а зачем хотят видеть эту бизнес-задачу выполненной? Какую проблему она решает? Естественно, мне ответить мог только заказчик (product owner), и так начались сессии общения с ним. Так я начал изучать не только программную архитектуру и computer science, но и менеджмент, и маркетинг.

К задачам и требованиям разработчик должен относиться скептически.

Теперь я каждый раз, когда беру задачу, анализирую ее и с точки зрения бизнес-проблемы, которую задача закрывает. Это помогает мне лучше ее реализовать и понять, стоит ли прорабатывать легко расширяемую архитектуру или задача — лишь одноразовая затычка проблемы.

Вторая причина — это искажения призм восприятия и вещания у людей: разработчиков, тестировщиков, аналитиков, проджект-менеджеров (Project manager) и продакт-менеджеров (Product manager). Когда мы работаем, мы часто забываем, что требования нам отдают не машины, а люди. А люди имеют свойство уставать вследствие перегруза. Максим Дорофеев, автор шикарнейшей книги про прокрастинацию и тайм-менеджмент, писал об этом.

Постановщик задач может испытывать проблему, которую Максим называет “синдромом дырявого стека”: задачи поступают аналитику настолько быстро, что он бросается выполнять их тут же и не успевает закончить с прежними. И так по кругу. В итоге ни одна из задач не проработана достаточно прозрачно для всех остальных участников проекта. А разрабам их имплементить. И если разраб не отнесется скептически к поступившей задаче и приступит к ней, не понимая сути, то продукт не получится хорошего качества. Поэтому и важно не начинать разработку, пока суть и смысл задачи не ясен.

Очень редко эта проблема встречается вследствие злого умысла. Всегда есть факторы, которые могут исказить смысл описания тикета. Например, в голове у автора задачи картинка мира идеально прорисована, а вот словарного запаса или моральных сил не хватило на то, чтобы описать тикет полноценно. И автор считает, что тикет написан достаточно доходчиво, но другим он непонятен вообще. И это — проблема не всех остальных, а отдельно взятого неверно оформленного тикета. Я не призываю обвинять конкретных людей в этом, я призываю просто признать и принять проблему и решать ее коллективно.

Хорошо описать тикет — задача не только аналитиков, но разработчиков и всех остальных участников проекта.

К этому призывают и некоторые принципы Agile-манифеста: второй и четвертый в частности. На планировании продакт-оунер (Product owner) “продает” задачи разработчикам, а они, в свою очередь, задают уточняющие вопросы и прорабатывают его коллективно. И только когда тикет понятен всем участникам проекта, его берут на оценку и закладывают в будущий спринт.

Есть еще одна причина непроработанных тикетов, которую не все признают. Чаще всего она встречается в продуктовых компаниях, хотя и аутсорс не лишен этого порока. Иногда заказчик или проектный менеджер просто хотят выслужиться перед своим руководством, и тогда начинается имитация бурной деятельности — незначительные требования и украшательства либо недооформленные тикеты. Иными словами, все процессы заказчик строит так, чтобы быть занятым либо на митингах с разрабами, “которые ничего не понимают и им нужно разъяснять все по несколько раз”, либо, наоборот, оверописанные тикеты, где можно утерять суть тикета за тонной текста. К счастью, мне не доводилось напрямую работать с такими заказчиками, однако по рассказам друзей и по их тикетам я видел это.

Одна из основных задач разраба в разработке — подвергать описание тикетов критике. Заказчик рассказывает о задаче разработчикам на своем языке бизнеса, а разработчики стремятся перевести его слова в язык технический и понять, как тикет повлияет на разрабатываемую систему. Этот рабочий доброжелательный конфликт всегда должен присутствовать в продуктивной рабочей среде.

Если рабочего конфликта между разработчиками и заказчиком не будет, то о непроработке задач будут сигнализировать уже непосредственные конечные пользователи системы.

Мой совет всем разработчикам: помогать бизнесу разрабатывать продукт, в том числе и прорабатывая тикеты совместно. Не беритесь за тикеты, пока их не понимаете, но не нужно наотрез отказываться от тикетов. Помогая аналитикам прорабатывать задачи и требования, разработчик прокачивает и свои аналитические навыки.

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться
🎁 Максимальная скидка!
Черная пятница уже в OTUS! Скидка -25% на всё!