Школа
системного анализа
и проектирования
системного анализа
и проектирования
Systems Education
Школа системного анализа
и проектирования
Школа системного анализа
и проектирования
Оглавление
Автор: денис бесков
Профессия «Системный аналитик информационных систем для бизнеса»
Оглавление и обзор глав книги
Профессия
«Системный аналитик информационных систем для бизнеса»
Это универсальное пособие для всех, кто связан с системным анализом: оно охватывает весь путь информационной системы — от идеи и требований до внедрения и развития. Новичкам книга подскажет, как войти в профессию; джуны поймут свою роль в проекте; мидлы смогут восполнить пробелы и увереннее вести переговоры; сеньоры сравнят свои подходы с альтернативными мнениями, а руководители отделов анализа получат обзор ключевых навыков, инструментов и актуальных трендов. По сути, это настольная книга, к которой стоит обращаться по мере возникновения новых задач и вопросов.
Раздел I. Роль системного аналитика в разработке информационных систем для бизнеса
Раздел I отвечает на главный вопрос: кто такой системный аналитик и почему без него IT-проекты часто буксуют. При этом не нужно погружаться во все главы подряд, достаточно открыть ту, которая решает вашу насущную задачу.
Скажем, в главе 1 вы узнаёте, почему аналитик — это не специалист по классическому «системному анализу и теории систем» из вузовского учебника, а специалист на стыке бизнеса и IT.
Глава 2 помогает разобраться с «предметами разработки», будь то внутренняя информационная система, программный продукт или интернет-сервис: это особенно полезно, когда приходится переключаться между корпоративным внедрением и созданием тиражного ПО.
Глава 3 про «контексты разработки» объяснит, что нужно учитывать при автоматизации бизнеса, работе в стартапе или системной интеграции.
Если не понимаете, как аналитик взаимодействует с архитектором, тестировщиком, менеджером проекта или специалистом по внедрению, загляните в главу 4 — там всё разложено по ролям.
В главе 5 показано место профессии на рынке: как в мире, так и в России, а вы сможете оценить свои перспективы. Захотелось разобраться, с чем вы вообще работаете ежедневно (коллективы, люди, процессы, документы)? Откройте главу 6.
Глава 7 рассказывает о методах работы с людьми: проведение интервью, встреч, презентаций — вы вдруг поймёте, почему так важно задавать «правильные» вопросы.
И наконец, если хотите наладить проектную работу и понять, как грамотно ставить задачи, вести их сдачу и сбор обратной связи, то в главе 8 «раскрыт» весь механизм, чтобы не застревать на согласованиях и бюрократии.
Возможные инсайты с Вашей стороны: «Похоже, всё же придётся отвечать на вопросы тестировщика» и «Подождите, если мои задачи по операционным процессам — это не проект, значит, я не получу проектную премию?».
Скажем, в главе 1 вы узнаёте, почему аналитик — это не специалист по классическому «системному анализу и теории систем» из вузовского учебника, а специалист на стыке бизнеса и IT.
Глава 2 помогает разобраться с «предметами разработки», будь то внутренняя информационная система, программный продукт или интернет-сервис: это особенно полезно, когда приходится переключаться между корпоративным внедрением и созданием тиражного ПО.
Глава 3 про «контексты разработки» объяснит, что нужно учитывать при автоматизации бизнеса, работе в стартапе или системной интеграции.
Если не понимаете, как аналитик взаимодействует с архитектором, тестировщиком, менеджером проекта или специалистом по внедрению, загляните в главу 4 — там всё разложено по ролям.
В главе 5 показано место профессии на рынке: как в мире, так и в России, а вы сможете оценить свои перспективы. Захотелось разобраться, с чем вы вообще работаете ежедневно (коллективы, люди, процессы, документы)? Откройте главу 6.
Глава 7 рассказывает о методах работы с людьми: проведение интервью, встреч, презентаций — вы вдруг поймёте, почему так важно задавать «правильные» вопросы.
И наконец, если хотите наладить проектную работу и понять, как грамотно ставить задачи, вести их сдачу и сбор обратной связи, то в главе 8 «раскрыт» весь механизм, чтобы не застревать на согласованиях и бюрократии.
Возможные инсайты с Вашей стороны: «Похоже, всё же придётся отвечать на вопросы тестировщика» и «Подождите, если мои задачи по операционным процессам — это не проект, значит, я не получу проектную премию?».
Раздел II. Анализ информационных систем для бизнеса
Раздел II рассказывает, как именно системный аналитик «залезает под капот» будущей системы и превращает бизнес-идеи в чёткие требования и концептуальные схемы. При этом не нужно читать подряд все главы — достаточно открыть ту, которая к вам ближе по текущим задачам.
Скажем, в главе 9 вы узнаете, как «прочувствовать» бизнес: провести бизнес-анализ, смоделировать процессы и правильно оформить бизнес-требования.
В главе 10 речь пойдёт о надсистемном анализе: где заканчиваются границы системы и чем она взаимодействует «снаружи» (особенно полезно, когда вы запутались в окружении).
Глава 11 — «Ах, вот почему все ругают требования!» — покажет, что вы не один.
В 12-й главе анализируется, зачем нам моделирование «до уровня UML» и почему Domain-Driven Design спасает, когда UML-модели перестают быть полезными.
Если же вы застряли в вопросах интерфейсов или пользовательских сценариев, загляните в главу 13 — проектирование использования, UI/UX.
Надо разобраться с концептуальным дизайном? Глава 14 расскажет, как разложить систему на части ещё до детальной проработки.
И наконец, в 15-й главе — внутрисистемный анализ с разработкой функциональных и нефункциональных требований, выявлением технических ограничений и критериев качества.
Возможные инсайты с Вашей стороны: «Подождите, то есть сценарии использования — не просто красивый текст, а инструмент для реального UX?» и «М-да, если бы мы если бы мы сделали концептуальное проектирование в прошлом проекте, не пришлось бы потом переделывать половину интеграций».
Скажем, в главе 9 вы узнаете, как «прочувствовать» бизнес: провести бизнес-анализ, смоделировать процессы и правильно оформить бизнес-требования.
В главе 10 речь пойдёт о надсистемном анализе: где заканчиваются границы системы и чем она взаимодействует «снаружи» (особенно полезно, когда вы запутались в окружении).
Глава 11 — «Ах, вот почему все ругают требования!» — покажет, что вы не один.
В 12-й главе анализируется, зачем нам моделирование «до уровня UML» и почему Domain-Driven Design спасает, когда UML-модели перестают быть полезными.
Если же вы застряли в вопросах интерфейсов или пользовательских сценариев, загляните в главу 13 — проектирование использования, UI/UX.
Надо разобраться с концептуальным дизайном? Глава 14 расскажет, как разложить систему на части ещё до детальной проработки.
И наконец, в 15-й главе — внутрисистемный анализ с разработкой функциональных и нефункциональных требований, выявлением технических ограничений и критериев качества.
Возможные инсайты с Вашей стороны: «Подождите, то есть сценарии использования — не просто красивый текст, а инструмент для реального UX?» и «М-да, если бы мы если бы мы сделали концептуальное проектирование в прошлом проекте, не пришлось бы потом переделывать половину интеграций».
Раздел III. Проектирование информационных систем для бизнеса
Раздел III посвящён проектированию информационных систем и охватывает самые «технические» аспекты. Но при этом не нужно штудировать всё залпом — достаточно выбрать, что у вас болит.
Допустим, глава 16 описывает «техническое проектирование»: как внутри системы распределить логику, какие базы данных выбрать, зачем нужна контейнеризация. Если вы туманно представляете, чем занимаются архитекторы и почему обсуждают микросервисы или ER-диаграммы, то здесь вас ждёт прозрение: «Ах, вот оно что, так строится внутреннее моделирование!»
В 17-й главе речь идёт о более широком подходе к архитектуре: микросервисы, распределённые системы, слоистая архитектура, балансировщики, оркестрация — всё то, что часто звучит на командных встречах.
Глава 18 открывает тему интеграции: очереди сообщений, API, брокеры — если вы застряли в вопросах «какими форматами мы обмениваемся с внешними системами?» или «как мы синхронизируем редактуру данных?», вам обязательно туда.
И, наконец, глава 19 покажет, как оформлять задачи на разработку так, чтобы не остаться в недоумении: «Почему у нас всё время разные люди по-разному поняли одни и те же требования?»
Возможные инсайты: «Подождите, значит REST-подход и очереди — это не взаимоисключающие методы?» и «Вместо того, чтобы в четвёртый раз переписывать техническое задание для разработчиков, я могу наконец-то составить критерии приёмки».
Раздел IV. Сопровождение аналитиком дальнейших этапов создания информационных систем
Раздел IV показывает, что после написания «основных» требований и проектирования работа аналитика не заканчивается: ему ещё предстоит участвовать в тестировании, документировании и сопровождать проект в боевом режиме.
И вновь не обязательно читать подряд: если вам больно смотреть на нескончаемые баги и надо понять, чем QA-жизнь отличается от обычной, загляните в главу 20 — «тестирование и качество».
Если вы вдруг запутались в том, как оформить и актуализировать документацию, добро пожаловать в главу 21.
Глава 22 расскажет, как системный аналитик может «подружиться» с AI, чтобы собирать требования и анализировать большие массивы данных.
И, наконец, в 23-й главе вы поймёте, почему внедрение и поддержка системы — это не просто «запустить и забыть», а постоянное взаимодействие с DevOps, службой поддержки, бизнесом.
Возможные инсайты: «Ого, оказывается, тестирование — это не в конце, а часть цикла!» и «Так вот, как правильно поддерживать документацию, чтобы её читал не только я».
И вновь не обязательно читать подряд: если вам больно смотреть на нескончаемые баги и надо понять, чем QA-жизнь отличается от обычной, загляните в главу 20 — «тестирование и качество».
Если вы вдруг запутались в том, как оформить и актуализировать документацию, добро пожаловать в главу 21.
Глава 22 расскажет, как системный аналитик может «подружиться» с AI, чтобы собирать требования и анализировать большие массивы данных.
И, наконец, в 23-й главе вы поймёте, почему внедрение и поддержка системы — это не просто «запустить и забыть», а постоянное взаимодействие с DevOps, службой поддержки, бизнесом.
Возможные инсайты: «Ого, оказывается, тестирование — это не в конце, а часть цикла!» и «Так вот, как правильно поддерживать документацию, чтобы её читал не только я».
Раздел V. Профессиональное развитие системного аналитика
Раздел V рассказывает о том, как расти в профессии системного аналитика, оставаясь при этом в адекватном психологическом состоянии и не теряя интерес к делу.
Если вы только начинаете карьеру и хотите понять, с чего стартовать, обратитесь к главе 24: там — «Как стать системным аналитиком», об опыте в IT, стажировках и работе с ментором.
А в 25-й главе речь про психогигиену: как не «сгореть», балансируя общение с заказчиками, командой и постоянными изменениями.
В 26-й главе вы найдёте инструменты самооценки и планирования развития — чтобы трезво понять, каких навыков не хватает и куда можно двигаться (в бизнес-анализ, архитектуру, продакт-менеджмент).
И наконец, глава 27 отвечает на вопрос «Куда идёт сама профессия?» — тенденции, AI, гибридные роли.
Возможные инсайты: «Хм, оказывается, есть легальные способы не сойти с ума от всей этой коммуникации» и «Кажется, мне хочется большего влияния, подумаю о том, чтобы перейти из аналитика в продуктовую роль».
Если вы только начинаете карьеру и хотите понять, с чего стартовать, обратитесь к главе 24: там — «Как стать системным аналитиком», об опыте в IT, стажировках и работе с ментором.
А в 25-й главе речь про психогигиену: как не «сгореть», балансируя общение с заказчиками, командой и постоянными изменениями.
В 26-й главе вы найдёте инструменты самооценки и планирования развития — чтобы трезво понять, каких навыков не хватает и куда можно двигаться (в бизнес-анализ, архитектуру, продакт-менеджмент).
И наконец, глава 27 отвечает на вопрос «Куда идёт сама профессия?» — тенденции, AI, гибридные роли.
Возможные инсайты: «Хм, оказывается, есть легальные способы не сойти с ума от всей этой коммуникации» и «Кажется, мне хочется большего влияния, подумаю о том, чтобы перейти из аналитика в продуктовую роль».