Написать эту статью меня натолкнул один случай. В моей команде двое junior-девелоперов: парень и девушка, и девушке я делал код-ревью. Задача была простая: ранее она написал экстеншн-метод (extension method из .NET) для валидации свойств объекта, и я предложил перенести этот экстеншн в сам класс объекта в качестве публичного метода. Девушка перенесла метод, и в качестве аргументов передавала те же свойства, которые нужно было провалидировать. Это было странное решение, ведь свойства объекта доступны в самом методе, нет нужды передавать их извне. Я написал ей в Slack, зачем она так написала. Разработчица мне ответила, что теперь поняла суть задачи и пообещала переделать в ближайшее время.
Суть проблемы не в том, что был написан неоптимальный код. Девелопер признался, что реализовал задачу и отправил ее на код-ревью, хотя не уловил суть задачи. Именно “не уловить суть задачи” и есть, как мне кажется, гораздо более важная проблема.
Я встречал такое раньше. Я и сам в начале своей карьеры бросался имплементировать задачи, даже когда не понимал их и для чего они предназначены. Когда приходилось переделывать имплементацию, я задумывался, почему же так получалось. После раздумий я пришел к выводу, что причина - непонимание задачи и того, что хотят видеть в итоге, а главное - какую проблему решают.
Этот вывод может показаться очевидным для опытных разработчиков, однако для меня тогдашнего это было чем-то вроде откровения с небес. Мир как будто перестал быть прежним в тот момент. Я начал относиться к задачам более скептически и всегда стал задавать себе вопрос: а зачем хотят видеть эту бизнес-задачу выполненной? Какую проблему она решает? Естественно, мне ответить мог только заказчик (product owner), и так начались сессии общения с ним. Так я начал изучать не только программную архитектуру и computer science, но и менеджмент и маркетинг.
К задачам и требованиям разработчик должен относиться скептически.
Теперь я каждый раз, когда я беру задачу, я анализирую ее и с точки зрения бизнес-проблемы, которую задача закрывает. Это помогает мне лучше ее реализовать и понять, стоит ли прорабаывать легко расширяемую архитектуру или задача - лишь одноразовая затычка проблемы.
Вторая причина - это искажения призм восприятия и вещания у людей: разработчиков, тестировщиков, аналитиков, проджект-менеджеров (Project manager) и продакт-менеджеров (Product manager). Когда мы работаем, мы часто забываем, что требования нам отдают не машины, а люди. А люди имеют свойство уставать вследствие перегруза. Максим Дорофеев, автор шикарнейшей книги про прокрастинацию и тайм-менеджмент, писал об этом.
Постановщик задач может испытывать проблему, которую Максим называет “синдромом дырявого стека”: задачи поступают аналитику настолько быстро, что он бросается выполнять их тут же и не успевает закончить с прежними. И так по кругу. В итоге, ни одна из задач не проработана достаточно прозрачно для всех остальных участников проекта. А разрабам их имплементить. И если разраб не отнесется скептически к поступившей задаче и приступит к ней, не понимая сути, то продукт не получится хорошего качества. Поэтому и важно не начинать разработку, пока суть и смысл задачи не ясен.
Очень редко эта проблема встречается вследствие злого умысла. Всегда есть факторы, которые могут исказить смысл описания тикета. Например, в голове у автора задачи картинка мира идеально прорисована, а вот словарного запаса или моральных сил не хватило на то, чтобы описать тикет полноценно. И автор считает, что тикет написан достаточно доходчиво, но другим он непонятен вообще. И это - проблема не всех остальных, а отдельно взятого неверно оформленного тикета. Я не призываю обвинять конкретных людей в этом, я призываю просто признать и принять проблему и решать ее коллективно.
Хорошо описать тикет - задача не только аналитиков, но разработчиков и всех остальных участников проекта.
К этому призывают и некоторые принципы Agile-манифеста: второй и четвертый в частности. На планировании продакт-оунер (Product owner) “продает” задачи разработчикам, а они, в свою очередь, задают уточняющие вопросы и прорабатывают его коллективно. И только когда тикет понятен всем участникам проекта, его берут на оценку и закладывают в будущий спринт.
Есть еще одна причина непроработанных тикетов, которую не все признают. Чаще всего она встречатеся в продуктовых компаниях, хотя и аутсорс не лишен этого порока. Иногда заказчик или проектный менеджер просто хотят выслужиться перед своим руководством, и тогда начинается имитация бурной деятельности - незначительные требования и украшательства либо недооформленные тикеты. Иными словами, все процессы заказчик строит так, чтобы быть занятым либо на митингах с разрабами, “которые ничего не понимают и им нужно разъяснять все по несколько раз”, либо наоборот овер-описанные тикеты, где можно утерять суть тикета за тонной текста. К счастью, мне не доводилось напрямую работать с такими заказчиками, однако по рассказам друзей и по их тикетам я видел это.
Одна из основных задач разраба в разработке - подвергать описание тикетов критике. Заказчик рассказывает о задаче разработчикам на своем языке бизнеса, а разработчики стремятся перевести его слова в язык технический и понять, как тикет повлияет на разрабатываемую систему. Этот рабочий доброжелательный конфликт всегда должен присутствовать в продуктивной рабочей среде.
Если рабочего конфликта между разработчиками и заказчиком не будет, то о непроработке задач будут сигнализировать уже непосредственные конечные пользователи системы.
Мой совет всем разработчикам: помогать бизнесу разрабатывать продукт, в том числе и прорабатывая тикеты совместно. Не беритесь за тикеты, пока их не понимаете, но не нужно наотрез отказываться от тикетов. Помогая аналитикам прорабаывать задачи и требования, разработчик прокачивает и свои аналитические навыки.