🚫Типовые ошибки младшего системного аналитика



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



1️⃣ Пишет ТЗ в художественном стиле. Вася только недавно закончил вуз, где он прекрасно научился лить воду. Тексты Васи, как и он сам, на 80% состоят из воды, а разработчики не могут понять, о чём ТЗ в принципе. Пример: “В случае недоступности системы платежей, к которой посредством использования интерфейса API данный сервис отправляет данные, полученные из запроса от клиента шагом ранее, сервису обязательно необходимо передать полученные данные в очередь сообщений Kafka



2️⃣ Плодит сущности. Ещё в вузе Вася хорошо научился обходить антиплагиат посредством подбора синонимов. И пытается улучшить своё красноречие обилием разных названий одной и той же сущности. Например, в одной части ТЗ использует термин “абонент”, в другой “клиент”, в третьей “пользователь”. Разработчикам остаётся только гадать, сколько на самом деле сущностей скрыто за этими синонимами



3️⃣ Прописывает в ТЗ очевидные требования. Вася пока ещё страдает тягой к излишней дететализации. Например, он пишет "Отчет должен формироваться по нажатию на кнопку “построить отчет”". Ладно, если бы это просто нагромождало ТЗ (отсылка к 1 пункту), так разработчик Георгий может принять такие требования как личное оскорбление.



4️⃣ Боится показаться глупым. Когда Вася получает задачу от старшего коллеги, он стесняется задавать глупые вопросы. В итоге Вася неправильно понимает постановку задачи и в лучшем случае теряет время впустую, пока его старший коллега не заметит косяк. Короче, Вася любит создавать себе сложности



5️⃣ Считает, что документация в конфлюэнсе всегда актуальная. Вася не успел окончательно разочароваться в людях, поэтому смело опирается на документацию. И вот, через неделю он показывает своё ТЗ коллеге: увы, придётся переделавать, так как эта система уже месяц как не используется, просто не обновили страничку…



6️⃣ Не фиксирует договорённости. Обсудив с заказчиком изменения требований в зуме, Вася никак не фиксирует, что такое-то требование было изменено и молча вносит правки в ТЗ. Через два месяца на Васю падает баг – изменения в требованиях оказались несовместимы с legacy бизнес-правилами в системе, о которых уже все забыли. Виноватым оказался конечно Вася, так как заказчик не помнит, что сам изменял требования.



7️⃣ Занимается улучшайзингом. Как истинный перфекционист, Вася не может позволить себе лишний пробел или не удалить ту самую точку на конце нумерованного списка, которая выпадает из общего ряда. А ещё однажды Вася, уже немного прокачавшись, получает задачу на небольшую доработку одного метода и решает переписать всё ТЗ целиком, так как текущие формулировки показались ему недостаточно прозрачными. От таких фокусов разработчик начал ругаться, мол, почему я должен переписывать метод заново, если мне нужно добавить всего один параметр. А ведь Вася ещё не понял, что он никогда не докажет разработчику, что это всего лишь уточнение формулировок в ТЗ без изменения логики работы метода…



А какие ошибки допускали вы? Делитесь в комментариях под постом 👇



P.S. Вася, прости



#развитие