Чем занимается системный аналитик 2⁠⁠

Прочитав комментарии к 1-ой части данной писанины я понял что как-то слишком просто написал. Чтож, в этот раз задайте накинем деталей)

Дано

Вы джун (Junior). Только-только успешно прошли испытательный срок.
Сейчас вы отвечаете за автоматизированный процесс по которому «бегают» заявки на согласование строительства сараев/ангаров/загонов и прочих аграрных сооружений.
Вам доверили боевую задачу.

Пришла задача

Заказчик просит добавить на шаг №4 небольшое препятствие – сделать так, чтобы строитель не смог пройти дальше, пока не вложит в систему нужный заказчику файлик.

Решение

1. Анализ и сбор требований

• Весь испытательный срок нам рассказывали о том как работает система. В связи с этим мы понимаем что шаг в системе не один и все они сильно влияют друг на друга. Смотрим BPMN-схему, базу данных с остальными документами и понимаем что догадка верна – за шагом 4, в зависимости от условий, может быть от 2 до 5 дополнительных шагов, на некоторых из которых могут быть аналогичные файлы.

• Далее формируем список возникших вопросов: всегда просить файл? Что с ним дальше делать? Все сотрудники знают как этот файл должен выглядеть? А если кто-то не знает? И т.д. всё что приходит в голову.

• С окончательным списком вопросов бежим звонить\писать заказчику для получения интересующих деталей. В результате чего получаем полное понимание того где и что делать с файлом далее, получаем образец и список сценариев когда запрашивать его НЕ надо. Записали. Перешли к следующему этапу.

2. Проектирование

• Вроде бы, понимаем что для решения проблемы надо добавить в базу данных несколько записей и попросить программиста настроить проверку на наличие файла на шаге.

• Но так как, пока что, в наши кривые руки никто доступа к редактированию базы не дал, то дополнительно понимаем что надо просить об этом кого-то другого. В итоге пишем бадди (наставнику\напарнику) чтобы обсудить наброски доработки и уточнить кого просить для добавления записей в базу.

• Получаем одобрение по наброскам, имя человека который может писать в базу и инсайд о том что программиста беспокоить не надо, т.к. проверка наличия нужных файлов уже настроена. Достаточно добавить записи в базу данных и всё поедет само. Тем лучше :)

Разработка

Тут всё просто – человечку, на которого указал пальцем бадди, ставим задачу на работу с базой данных и ожидаем (попивая чай) вопросов, либо уведомления о выполнении.

Тестирование

Тут ещё проще – идём на шаг №4 и начинаем тыкаться-мыкаться по задуманному сценарию чтобы получить тот результат который заказывали в задаче. Иииииии получаем только половинку того о чём просили – файлик система как бы просит, но как бы и без него пускает дальше... Непорядок!

Разработка №2

В результате дополнительного анализа понимаем что, к сожалению, ремонтировать ошибку в инструменте никто не будет, т.к. организация от него скоро (пол года - год) избавиться, а время программиста дорого.
В связи с этим (прости господи) просим программиста поставить «костыль» чтобы всё таки заработало так как надо.
Для этого, аналогично первой разработке, ставим задачу и ожидаем (уныло хлюпая чаем)

Тестирование №2

Пусть и с «костылём», но при повторной проверке сценария всё работает точно так как просил заказчик. Бежим докладывать заказчику о готовности.

Приёмка заказчиком

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

В связи с этим заказчик на своей стороне также проводит собственное расследование тестирование. Слава богам ошибок не было найдено и мы спокойно можем закрыть задачку, погладить себя по головке и, наконец-то, допить свой чай и получить миллион долларов ни за что.

Возможные ошибки

1. Если побежать ставить задачу на программиста НЕ выполнив сбор требований, то временные затраты всех участников будут увеличены в 2 раза. Неважно что заказчик что-то не дописал, важно что нас это никак не озаботило. Если бездумно лепить доработки, то можно сделать не только НЕ лучше, но и наставить палок в колеса всем остальным, у которых было нормально.

2. Если побежал ставить задачу на программиста НЕ поговорив с бадди, то потратите плюс минус 4 часа (с момента взятия задачи программистом, а это сильно не сразу может быть). В этом случае вы также узнаете что есть специальный инструмент, но сначала программист будет долго-долго чесать голову чтобы понять где поправить и почему он это ГДЕ не может найти.

3. Если не провести повторное тестирование, то можно, в будущем, получить ещё пачку проблем. Если думаете что и в первый раз заметили все возможные ошибки, то когда нибудь, немного на этом споткнувшись, передумаете). Даже если это просто мелкая правка, проверить всё равно надо, т.к. даже 1-2 символа в программировании могут пустить программу не по тому пути.

Документация

И в этот раз её не будет, т.к. она есть в коде, а оттуда в базе понятно что откуда растёт)