Post #351

Отличное задание для проверки аналитика на собеседовании: предложите кандидату написать требования для управления роботом-пылесосом. А потом посмотрите — появится ли в списке требований обнаружение собачьих/кошачьих 💩 и остановка в этой ситуации. Конечно, можно наткнуться на человека, у которого есть дети и/или домашние животные, и который сам оказывался в ситуации, когда робот-пылесос не обладал такой функцией, въехал в :poop: и потом разнес его по всему дому... Но если животных нет, то какой ход мысли должен быть у аналитика, чтобы выявить такую функцию? Какие вопросы можно задать, чтобы выйти на такую потребность? А после этого ещё оценить, насколько сложно реализовать такую функцию при помощи имеющихся технологий, и насколько нужно её реализовывать, какова её востребованность и влияние на пользователей? В реальном мире такая функция появилась далеко не сразу — то ли про неё и правда не подумали, то ли не знали, как решить, пока не развились технологии уверенного распознавания образов. Но уж этого-то наверняка было много сообщений от пользователей, можно целый spreadshit составить (pun intended). ⬇️⬇️⬇️ В книге Яна Александера 'Discovering Requirements' (не того, который актер озвучания в Last of Us, а английского учёного в области инженерии требований) разделяются 'greenfield development' и 'brownfield development' — проекты, стартующие с нуля, и проекты развития/модернизации существующей системы. Сбор требований к проектам разного вида имеет свои особенности. В случае Brownfield обычно имеется большое число жалоб, обращений пользователей, предложений и -- очень важный источник — народные сценарии работы, прихватки и инструкции. В компаниях они иногда написаны на клейких листочках, иногда передаются друг-другу в виде доковских файлов или постов на форуме; в старое время я видел тетрадки с записанными рукой шагами для получения какого-нибудь отчета (пойти в настройки, переключить там галочку, потом пойти в отчет, задать такие-то параметры, сохранить в xml, запустить скрипт, который написал парень, работавший здесь 4 года назад, открыть в Excel вот в этом шаблоне, вписать на первой странице точные даты начала и окончания квартала — и отчет готов!). Это всегда просто кладезь информации о том, как пользователи обходят несовершенство системы! Рассуждая дальше о greenfield и brownfield, Александер отмечает, что в университетах и на курсах практически всегда говорят о первой ситуации (сбор требований к новой системе), а в жизни чаще встречается второй вариант: доработка существующей системы. Правда, сам он тоже не слишком много внимания уделяет этой теме, зато упоминает корпоративную археологию! — когда нужно найти описания и причины текущего состояния системы, прокопавшись через несколько культурных слоев документации. Удивительно, но книга Александера никогда не переводилась на русский (написана в 2009). А по содержанию и концентрации смысла она точно не хуже Вигерса!