Топ-7 стыдных вопросов в работе системного аналитика
“Пить кофе с наставниками и стейкхолдерами, читать первые главы Вигерса, задавать заказчикам экзистенциальные вопросы”.
Практика показывает, что этих советов достаточно, чтобы младшему аналитику нырнуть в рабочую пучину и не утонуть. Сложности начинаются, когда в процессе работы возникают вопросы, которые неудобно задать коллеге, а ответы на которые не найти в поисковой системе.
Для этой статьи я собрала F.A.Q. с ответами на самые частые вопросы, которые задают начинающие специалисты на менторских сессиях — всего их вышло семь. Может быть, в вашей практике встречаются другие темы, которые вводят в недоумение молодых бойцов. Если поймете, что список недостаточен, смело делитесь в комментариях вашими наблюдениями.
Итак, начнем.
1. Почему программисты не соблюдают ТЗ?
Если вы — джуниор, то вскоре раскроете обман: разработчик — профессия творческая, пусть и техническая. Однажды во время тестирования вы обнаружите, что итог довольно сильно отличается от вашего opus magnum. Прежде чем задавать вопросы о тщетности ТЗ, необходимо выдохнуть и определить, в какой его части есть отклонения.
Типичный документ включает в себя бизнес-постановку задачи, описание функциональных требований и дизайн системы. Например, пользовательский интерфейс, структуру базы данных, контракт обмена данными между системами. Если выполненная доработка не решает бизнес-задачу заказчика, стоит бить тревогу и стучать в барабан. Если не соблюдена часть функциональных требований или дизайна системы, прежде всего рекомендуется выяснить причину.
Причина 1. Исполнитель понял ТЗ, но знает лучшее решение
Разработчик решал подобные задачи и знает более оптимальный способ. Рекомендация — договорится с командой обсуждать ТЗ во время анализа (при наличии возможности) и согласовывать изменения, если они возникают во время разработки. Участники должны быть в курсе, а документ — актуальным.
Причина 2. Исполнитель понял бы ТЗ, но заснул во время чтения
Диалоги двигают детективы, а диаграммы и таблицы — документ. Любите ваших читателей, убирайте из документа воду и представляйте информацию наглядно. Посмотреть подробнее, как писать документацию и ТЗ так, чтобы это читали, можно в статье 7 принципов описания требований на языке разработки.
Причина 3. Исполнитель — художник и реализовал свое видение
Системный аналитик — представитель заказчика в команде и отвечает за соблюдение требований. Если разработчик не может предоставить конструктивное объяснение отклонениям от требований, настаивайте на соблюдении ТЗ и при необходимости привлекайте руководителя.
Помните, что ПО создается в соответствии с требованиями заказчиков. Поэтому любые отклонения от изначальных требований могут привести к:
a) неудовлетворенности заказчиков;
b) невостребованности разработанного ПО пользователями.
Если рассмотреть более детально, это выливается в череду других непредсказуемых и не всегда приятных последствий: технические ошибки при реализации, несоблюдение сроков, дополнительные издержки и т.д. Любое решение должно быть обосновано и аргументировано, за любым решением должно стоять ответственное лицо и в конечном итоге оно должно делать удобнее жизнь пользователя и вызывать улыбку на лице заказчика. Если аргументы в попытке что-то изменить не слишком убедительные, возвращаемся к ТЗ и строго его соблюдаем.
2. Что делать, когда в ТЗ постоянно вносятся правки, и проект не выходит на финальную стадию?
У каждого проекта или задачи должен быть заказчик, исполнитель и строгий дедлайн. Установите сроки и обговорите с заказчиком, что при внесении изменений после обозначенной даты правки будут вносится только при согласовании руководства. Также обговорите возможные сдвиги по срокам в связи с внесением доработок в релиз.
3. Почему в моей работе есть простои?
Простои в работе могут возникать по разным причинам: вы работаете по методу waterfall и завершилась стадия анализа. Или вы подготовили документы и ожидаете ревью. А может быть у вас десять задач, но по каждой мяч на стороне другого участника. Прекрасное затишье! Можно причесать документацию, обновить F.A.Q. по продукту, пройтись по бэклогу или заняться самообразованием. Но важно помнить: если простои носят длительный и регулярный характер, стоит обсудить загрузку с руководителем.
4. Что делать, когда говорят “собери аналитику по проекту”?
Задача аналитика — задавать вопросы, уточнять и переспрашивать, пока не останется неясностей. Если специалисту поставили задачу, и он не понимает, что от него хотят, необходимо прояснить постановку. Желательно, чтобы она соответствовала критериям SMART — Specific, Measurable, Attainable, Relevant, Time-bound (прим. Конкретность, Измеримость, Достижимость, Уместность, Ограниченность во времени).
Задача должна быть конкретной и иметь сроки, исполнитель должен знать, какой результат ожидается на выходе. Если у вас несколько задач, необходимо обсудить приоритеты с постановщиком, чтобы вовремя переключаться.
5. Почему руководитель не контролирует мою работу? Как понять, что у меня получается?
Позиция системного аналитика подразумевает самоорганизованность, самостоятельность и ответственность. Руководитель может подключаться на определенных этапах работы, чтобы оценить вашу эффективность. Если этого не происходит, можно назначить с ним встречу и попросить обратную связь, договориться о целях на следующий период (квартал, полгода). Подчеркну еще раз: важно, чтобы цели были поставлены по SMART — тогда будут четкие критерии для оценки результатов.
6. Что делать, если допустил ошибку?
В зависимости от типа ошибки, сообщить о ней — разработчику, руководителю проекта или продакт оунеру. И обновить ТЗ. Толерантность к ошибкам — отличный показатель сплоченности команды и атмосферы в компании.
7. Как оставаться спокойным, когда данные в системах не сходятся?
В первую очередь, необходимо определить, какая система является мастером — то есть источником информации. После необходимо проанализировать, по каким причинам могли возникнуть расхождения и насколько они критичны для выполняемых задач. В любом случае, используйте практики медитации. ИТ-система может быть стабильной, а поведение пользователей — нет.
Заключение
Для специалиста с небольшим опытом может быть непросто давать о себе знать и задавать вопросы. Каждая рабочая ситуация переживается как лакмусовая бумажка для неопытности и незнания. Стоит помнить, что все с этого начинали.
Когда я была джуном, мой наставник поделился со мной правилом: “Системный аналитик не должен всего знать, но он должен знать, как найти ответ”. Возможно, это главный принцип в работе аналитика любого уровня.
Итак, если в данной статье не удалось покрыть полный список самых часто задаваемых молодыми специалистами вопросов, с радостью будем ждать ваши варианты в комментариях. Пишите, что тревожит молодые умы.
Об авторе
Татьяна Демьянова, Product Owner / System Analyst в команде CT Software в группе компаний CT Customertimes corp — CT Customertimes, CT Consulting, Masterdata, CT Cloud.
Развивает продукт CT Presenter & Remote Detailing.
Более 12 лет опыта в IT. Участвовала в разработке крупных корпоративных ERP-систем и коммерческих продуктов для внешних клиентов.
Ментор в сообществе Women in Tech Russia.
Автор фотографий: Alex Fokin, Instagram: @alexskywhale
