Не берись делать то, чего не понимаешь | OTUS
⚡ Подписка на курсы OTUS!
Интенсивная прокачка навыков для IT-специалистов!
Подробнее

Курсы

Программирование
iOS Developer. Professional Kotlin Backend Developer Flutter Mobile Developer Symfony Framework C++ Developer. Basic Unity Game Developer. Basic Java Developer. Professional
-35%
Highload Architect Unity Game Developer. Professional React.js Developer Специализация Java-разработчик
-25%
Алгоритмы и структуры данных
-16%
Scala-разработчик C# Developer. Professional
-23%
Разработчик голосовых ассистентов и чат-ботов Team Lead Архитектура и шаблоны проектирования NoSQL Web-разработчик на Python Golang Developer. Professional PostgreSQL Vue.js разработчик Супер-практикум по использованию и настройке GIT Разработчик IoT Подготовка к сертификации Oracle Java Programmer (OCAJP) Программист С HTML/CSS
Инфраструктура
Инфраструктурная платформа на основе Kubernetes Microservice Architecture Базы данных Highload Architect Reverse-Engineering. Professional
-8%
Network engineer. Basic Administrator Linux.Basic MongoDB Infrastructure as a code MS SQL Server Developer Cloud Solution Architecture Мониторинг и логирование: Zabbix, Prometheus, ELK Супер-практикум по использованию и настройке GIT Разработчик IoT Экcпресс-курс «ELK» Супер-интенсив "Tarantool" Экспресс-курс «CI/CD или Непрерывная поставка с Docker и Kubernetes» Экспресс-курс «Введение в непрерывную поставку на базе Docker»
Корпоративные курсы
Безопасность веб-приложений Экосистема Hadoop, Spark, Hive Пентест. Практика тестирования на проникновение Node.js Developer Java QA Engineer. Basic
-18%
Reverse-Engineering. Professional
-8%
DevOps практики и инструменты NoSQL Reverse-Engineering. Basic Cloud Solution Architecture Внедрение и работа в DevSecOps Супер-практикум по работе с протоколом BGP Game QA Engineer Супер - интенсив по Kubernetes Дизайн сетей ЦОД Экспресс-курс «IaC Ansible» Экспресс-курс по управлению миграциями (DBVC) Экспресс-курс "Версионирование и командная работа с помощью Git" Основы Windows Server
Специализации Курсы в разработке Подготовительные курсы Подписка
+7 499 938-92-02

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор
0 комментариев
Для комментирования необходимо авторизоваться