Всем привет! Я недавно начинал свой путь в карьере системного аналитика, хочу обратить внимание, что в заказной разработке. И я собрал список советов, про которые надо не забывать при работе. Каждому коллеге задавался вопрос: «Какой совет ты дал(‑а) бы себе в начале карьеры?» Предлагаю посмотреть на сборку получившихся правил, выявленных мной. В основном интервьюируемые были из заказной разработке, но считаю, что правила подходят также для системных аналитиков в продуктовой разработке и бизнес-аналитиков.

Нельзя никому верить

Часто бывает, что человек говорит, сам не до конца понимая суть. Заказчик может уверять, что система работает определённым образом или что без какой-то функции всё остановится, но на деле всё работает иначе, а предложенная функция лишь добавляет неделю работы без реальной пользы. Разработчик, в свою очередь, может заявлять о невозможности реализации, хотя на самом деле ему просто лень разбираться.

Тезис «нельзя никому верить» — это про критическое мышление, а не про тотальное недоверие ко всем. Любая информация, от заинтересованных лиц, должна подвергаться проверке и критической оценке.

Идеально не получится

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

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

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

Задавать вопросы

Это правило про то, что в любой не понятной ситуации задавай вопросы. Неважно, кажется ли тебе вопрос глупым или очевидным — если он поможет прояснить ситуацию и избавиться от неопределённости, его стоит задать. Особенно важно в начале работе над проектом, когда  ещё ничего непонятно, самый лучший способ что-то выяснить. Задавать вопросы — ключевой навык аналитика. Не стоит бояться уточнять детали, выяснять причины решений и проверять, действительно ли все участники проекта говорят об одном и том же. Ошибки, возникающие из-за недосказанности, обходятся гораздо дороже, чем лишние 5 минут на обсуждение.

Заказчик может быть не прав

То, что заказчик лучше всех знает свой бизнес, не означает, что он всегда прав. Он может ошибаться в понимании бизнес-процессов, недооценивать сложности или не замечать проблем, которые очевидны со стороны. Разные участники проекта могут видеть одну и ту же ситуацию по-разному, и восприятие заказчика – это лишь одна из возможных точек зрения.

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

Постоянно взаимодействуй с заказчиком

Здесь скрывается несколько смыслов. Первый, делись промежуточными результатами, обсуждай идеи, показывай наброски требований. Это помогает скорректировать модель понимания проекта ещё на ранних этапах, когда изменения даются легче и дешевле. Чем раньше будут выявлены ошибки и недочёты, тем меньше вероятность глобальных переделок в будущем. Ожидания заказчика и реальность разработки должны синхронизироваться как можно чаще.

Второй, у заказчика должно возникнуть прямая ассоциация между ним самим и проектом. Он должен чувствовать, что участвует не только финансово, но и интеллектуально. Когда заказчик видит, что его мнение учитывается, что он влияет на процесс, он становится более заинтересованным в результате. Это снижает риск ситуаций, когда в конце разработки он вдруг заявляет: «Я ожидал совсем другого». Проект становится не просто чем-то, за что он заплатил, а делом, в которое он вложил своё время, идеи и внимание. 

Найди правильный язык общения с заказчиком

Каждый человек воспринимает информацию по‑разному. Кто‑то лучше понимает текст, кто‑то — схемы, таблицы, диаграммы или устные объяснения. Важно не только знать, что сказать заказчику, но и как это подать, чтобы он действительно понял твою идею.

Чтобы взаимодействие было продуктивным, сначала определи, какой формат восприятия удобен заказчику. Если он легко схватывает информацию на слух — обсуждай детали в разговоре. Если ему нужны чёткие факты — готовь текстовые отчёты. Если он мыслит визуально — показывай диаграммы, блок‑схемы и макеты. Использование правильных инструментов подачи информации помогает избежать недопонимания и лишних вопросов.

Заключение

Надеюсь все правильно поняли, что этот список – не жёсткие догмы, а набор практических наблюдений, которые я попытался собрать в одном месте и если к ним подойти осознано, то они правда помогут не забывать о важных вещах, мне помогли. Если кто-то с чем-то не согласен или хочет дополнить этот правила своим опытом, то жду предложений.

Всем спасибо!