Или как понять, когда остановиться
Как-то раз мой коллега, лид разработки, после затяжного спора о том, что должно быть в системной спецификации, подошел ко мне и спросил:
— Скажи, а зачем нам вообще нужны аналитики?
— И действительно, зачем? – подумал тогда я и написал заявление
Вопрос этот, как бы крамольно он ни звучал, очень правильный. Системный анализ, как фаза разработки приложения, присутствует всегда (даже если это системы класса «Hello, world»), а вот системный аналитик, как выделенная роль – нет. Выделение отдельной специальной роли работает точно так же, как и разделение труда в обычном производстве: для маленьких задач не целесообразно, для больших задач – оправданно. При таком разделении системный аналитик забирает на себя часть задач и функций некоего «универсального» исполнителя задачи. Однако, подобное разделение труда имеет свою цену: это потеря знаний при коммуникации, более сложное управление процессом и др. В этой статье я хочу поделиться своим опытом: описать минусы крайностей и дать рекомендации по распределению обязанностей между системными аналитиками и разработчиками.
Итак, нам нужен системный аналитик, который формирует требования и разработчик, который эти требования реализует в коде.
Если спросить у любого разработчика, каким главным свойством должны обладать системные требования, он, скорее всего, скажет: «чтобы было понятно, что делать». И это проблема.
Заключается эта проблема в том, что между сбором и систематизацией требований (прямая и понятная задача аналитика) и непосредственно кодированием (прямая и понятная задача разработчика) есть область проектирования решения; задачи из этой области могут и должны выполнять обе роли.
Вопрос – как провести границу? Как выбрать такую степень детализации требований, при которых это будет максимально полезно разработчику и не будет содержать ненужной и избыточной информации?
Начнем с описания сложностей, которые могут возникнуть, если степень детализации будет выбрана не оптимально. Под «глупым» и «умным» участником процесса я подразумеваю не интеллект или профессиональные навыки, а степень погружения в процесс проектирования и контроля над реализуемым решением.
Глупый аналитик, умный разработчик
Аналитик формулирует только функциональные требования («система должна уметь…»), сама система для него представляется черным ящиком, она или умеет что-то, или нет. В этом случае проектирование самого решения перекладывается на плечи разработчика. К чему это может привести:
Риск высокой стоимости решения. Аналитик не знает, какое из его требований реализуется просто и дешево, а какое – сложно и дорого; у него нет возможности в процессе формирования ожиданий у заказчика/пользователя предложить и защитить решение, которое решает бизнес-задачу не хуже, но стоит сильно дешевле.
Например, желание пользователя получить автоматически обновляемые данные на форме может стоить разработки сложного и дорогого механизма по отслеживанию изменений данных, при этом реализация обновления данных по нажатию кнопки будет на порядок проще;
Риск попасть в технические ограничения. Аналитик не знает, привели ли ранее выставленные им требования к технологическим ограничениям в разрабатываемой системе. Разработчик может выбрать то решение или технологию, которые подходят для текущего набора требований; любое решение или технология накладывают ограничения – какие-то задачи решаются легко и удобно, какие-то сложно и дорого. Отсутствие понимания ограничений может привести к согласованию с заказчиком и выставлению практически нереализуемых требований;
Недостаточная проработка. Для решения ряда задач, особенно интеграционных, требований уровня «система А должна запросить у системы Б такие-то данные» недостаточны: разработчику в этом случае придется на себя взять поиск или формирование интеграционного контракта, его согласовать и распространить в каком-то виде эти знания внутри собственной команды разработки. А это – не профильные для разработчика активности, которые мог бы взять на себя аналитик;
Неудобная форма подачи. В ряде случаев, для того чтобы требования были полными и логичными, аналитик должен выбрать какую-то форму описания требований и описать их достаточно детально, фактически спроектировать решение. Если это решение не согласуется с архитектурой приложения, то, во-первых, разработчику придется тратить время и силы на перевод “писанины” в нужное ему знание, а во-вторых, сам аналитик будет тратить силы и время на те детали, которые никто не будет читать и использовать. Например, описание модели данных: аналитик описывает реляционную модель данных, создает дополнительные конструкции для связей, требования к отчетам пишет в виде SQL запросов, а разработчик, использующий объектную модель и ORM, вынужден это переводить;
Ограничения в тестировании.Тестировщик не сможет получить из требований такого уровня достаточно информации о том, как должна работать система - лишь о том, что она должна уметь, а это разные вещи. При таком подходе выше риск возникновения ситуации, при которой система требованиям формально удовлетворяет, но на практике решение не удобно или не оптимально.
Умный аналитик, глупый разработчик
Другая крайность при распределении функций – это слишком большая степень свободы для аналитика в части проектирования решения. Аналитик описывает алгоритмы на псевдокоде, пытается оперировать такими абстракциями, как слои приложения, описывает какие-то сервисные механизмы, определяет типы данных и формат обмена данными внутри приложения, суть требований скрывается за предложенными решениями. У этого подхода тоже есть серьезные минусы:
Нет возможности проверить корректность. Разработчик не видит картины в целом, не понимает, зачем он делает ту или иную задачу: ему приходит спецификация, содержащая алгоритм на псевдокоде, правильность/адекватность которого он не может проверить. Это повышает риск ошибки со стороны разработчика и не позволяет провести ревью (аналитики ошибаются и осознанное прочтение разработчиком документации позволяет это выявить);
Избыточная проработка. Системная спецификация может содержать детальное низкоуровневое описание алгоритмов работы с данными, которые разработчик не будет реализовывать. Например, не нужно описывать алгоритм вычисления количества дней между двумя датами или дня недели по дате (привет школьные олимпиады) – для большинства таких задач есть готовые решения;
Лишняя работа ради стройности описания. Хорошо и правильно, когда ТЗ или спецификация имеют примерно одинаковую глубину для всех функциональных блоков; в этом случае читающему проще понять, на какие вопросы документ может ответить, а на какие – нет. Этот подход очень быстро может затянуть аналитика в бессмысленный и беспощадный процесс описывания вообще всего на свете: как читать данные из файлов, как называть внутренние классы и т.п. Есть ряд задач, которые аналитик в большинстве случаев просто не должен описывать и сервисные/инфраструктурные функции – одна из них;
Риск потери актуальности документации. В случае если разработка решит провести рефакторинг, заменить фреймворк или какой-то модуль в приложении, слишком «близкая к коду» спецификация может стать неактуальной и неверной, причем в большом объеме. В каком-то объеме спецификации будут устаревать в любом случае, это процесс - как инфляция, но если можно не усугублять, то нужно не отказываться от такой возможности;
“Режим бога” и неадекватное восприятие границы компетенций. В ряде случаев аналитику может просто не хватить технических знаний или опыта, но так как он привык, что в его команде он «умный» и никто кроме него, он может поддаться соблазну изобрести свой собственный велосипед из костылей. Этот аспект не совсем технический, но потому он особенно важен и коварен. Проблема оценки собственной компетентности вообще довольно остро стоит перед человечеством и системный анализ - не исключение.
И что делать?
Нет на свете хуже статей, чем те, в которых поднимается проблема, а в качестве решения говорится, что все случаи разные и надо смотреть по ситуации. Я хочу привести несколько приемов и рекомендаций из своей собственной практики, которые оказались полезны и действенны.
Рекомендация первая. Она звучит настолько банально и скучно, что кажется, что в ней нет никакой магии (а она есть): спросите у своих разработчиков, что они хотят или не хотят видеть в документации. Тут штука в том, что если спросить в лоб, то в 99% случаев будет ответ «Ну, чтоб было понятно, что делать». Более эффективно будет встретиться с лидом команды (или с основными ее участниками) и проговорить несколько ключевых моментов, которые встречаются почти в каждом проекте, особенно, в корпоративной разработке.
Приведу некоторые из тех вопросов, которые я стараюсь проговорить при взаимодействии с новой командой.
Архитектура приложения / стек технологий. Какой используется язык? Как выглядит приложение изнутри? Это монолит или набор сервисов? Если набор сервисов, то как взаимодействуют между собой? Что из себя представляет фронт-энд? Как лучше разделять логику между фронтом и беком? Нужно ли описывать REST API для фронта? …и еще десяток вопросов, которые появятся после ответов на указанные выше. Попробуйте визуализировать приложение, попросите нарисовать. Если ранее с таким не сталкивались, попробуйте вместе с разработчиком проговорить один какой-нибудь кейс. Например: «пользователь открывает форму, что-то вводит, сохраняет, получает результат. Расскажи, как это будет реализовано, какие компоненты будут задействованы, куда пойдут данные». Разбор одного такого кейса даст огромный прирост в понимании того, из каких частей состоит приложение и как их можно/нужно дорабатывать.
Модель данных. Как построено взаимодействие с данными? Это прямые SQL запросы из кода или работа с объектами? Используется не-SQL хранилище? А как с ним работать, что там хранится? Нужно ли в спецификации описывать классы с их атрибутами максимально близко к коду или лучше использовать логические абстракции? Если абстракции, то, как быть с типами данных, нужно ли указывать? Нужен ли маппинг классов на таблицы?
Форматы сообщений для сервисов между компонентами системы: XML или json? Нужны ли xsd и json схемы? Нужны ли описания всех возможных ошибок для REST API? Насколько детальное описание взаимодействия нужно для подключения к внешним сервисам?
Декомпозиция функциональных блоков. Как лучше делить? Описывать бизнес сценариями или самостоятельно выделять общие куски?
Нужно ли бизнес-описание задачи? Будет ли оно полезно? Будут ли его читать?
Нужны ли эскизы форм? Насколько детально? Нужны ли реальные размеры? Что позволяет UI фреймворк? Можно ли использовать «модальные окна»? Можно ли использовать веб-сокеты?
Одна такая сессия с конкретными разработчиками вашей команды даст ответов больше, чем стопка книг по системному анализу, потому что это будут максимально релевантные ответы под конкретный проект с конкретными людьми. Опытный системный аналитик может очень хорошо и правильно сформулировать набор требований к системе – непротиворечивых, атомарных, исполнимых и так далее, но для того, чтобы они были реализованы, их нужно донести до разработчиков. И вот такой экспресс-опрос повысит эффективность коммуникации между аналитиком и разработчиком как мало что другое.
Рекомендация вторая. Нужно смотреть по ситуации. Точную идеальную степень вовлечения определить невозможно (даже ретроспективно, после внедрения), но есть некоторые признаки, которые позволят понять, стоит ли пытаться захватить полный контроль над проектом или достаточно будет «система должна позволять…». Речь идет, конечно, не о крайностях, а об оттенках.
На мой взгляд, следующие факторы говорят в пользу подхода «Умный аналитик – глупый разработчик»:
Приложение или крупный функциональный блок проектируются с нуля (т.е. начало проекта), у разработчиков еще нет понимания, как все будет реализовано
Команда разработки относительно многочисленна (>3 человек), нужна точка консолидации знаний
Разработчики имеют низкую или среднюю квалификацию
Разработчики работают или удаленно, или не полный день, или были привлечены только на этот проект – у них нет особой экспертизы в данной бизнес области и, возможно, нет особой мотивации ее приобрести: «внедрил – ушел»
В проекте большое количество интеграционных взаимодействий с другими системами – нужно все это координировать
В проекте очень часто меняются требования и нужна отдельная активность по управлению изменениями. Требования везде меняются, но иногда – настолько часто, что одно только отслеживание и учет изменений может занимать кучу времени
Есть желание стать незаменимым членом команды и спекулировать на этом. Будем честны, это тоже аргумент.
Подход «глупый аналитик – умный разработчик» оптимален, как можно догадаться, в противоположных случаях:
Аналитик подключается на фазе доработки или поддержки уже имеющейся системы, у команды сформирован подход и принципы разработки, они хорошо знают систему и им нужны только функциональные требования
Разрабатываемая система довольно изолированная, каждый разработчик в команде со временем становится владельцем почти полного набора знаний о ней
Практикуется подход итеративной/водопадной разработки, когда у команды разработки есть время спокойно спроектировать все, все новые функции аккуратно вписать в имеющуюся архитектуру. Казалось бы, как связаны методология разработки и степень вовлечения аналитика? Мой опыт показывает, что когда набор требований (хотя бы примерно) известен на целый релиз вперед, внутри команды (здесь я имею в виду и аналитиков и разработчиков) формируется некоторое общее видение решения и сильно большая и глубокая детализация не то, чтобы вредит – просто не требуется. У недостаточно детальных требований есть свои недостатки, но на подготовку релиза в такой размеренной и спокойной ситуации они имеют меньшее воздействие.
Аналитик подключается частично, не на полное время или для решения какой-то конкретной задачи. Переделывать или ретроспективно документировать все что можно - не лучшая идея.
Аналитик имеет низкую техническую квалификацию. В системном анализе, как в медицине, главное – не навредить. Если вы не понимаете, как на низком уровне работает какой-то механизм, не пытайтесь изобрести для него собственный алгоритм; скорее всего, разработчик не будет его реализовывать, а использует какую-нибудь готовую библиотеку. Разумеется, для вас это сигнал к тому, что хорошо бы понять принцип его работы, но если это не удается сделать быстро – то лучше в другой раз
В проекте всего один разработчик, сильный, все знает и умеет и от вас нужны только функциональные требования. Может быть немного обидно, но если вспомнить, что миссия системного аналитика как роли – повысить эффективность разработки, то в том, чтобы вовремя остановиться, больше профессионализма, чем в попытке (пусть и успешной) доказать, что вы бы могли спроектировать не хуже, а то и лучше.
Рекомендация третья. Спросите у разработчиков по итогам некоторого периода совместной работы, все ли им понравилось и нести ли десерт. Как правило, если разработчик получает необходимую ему информацию из спеки или ТЗ, он этим остается доволен, а лишнее просто игнорирует или приспосабливается к трансформации написанного в нужное. Выяснив по итогам релиза или какой-то крупной итерации, что было удобно и полезно, что было лишним, а что лучше излагать по-другому, можно сделать взаимодействие в последующих итерациях сильно более эффективным; там, как правило, выясняется, что часть вещей, которые вы описывали каждый раз, они давно не читают, на степень детализации это не влияет и можно в будущем просто сэкономить время.
Причем, если договариваться о правилах игры надо с лидом, то получать обратную связь лучше от рядовых разработчиков, так как лид сам может всего этого не прочувствовать. Кроме того, если лиду что-то не понравится, он, скорее всего, скажет сам, а рядовой исполнитель – нет. Мне вот, после пары таких сеансов обратной связи, хотелось сказать: «что ж ты молчал все это время?»
Если история про «захватить проект и спекулировать на этом» - ваш случай, то положительная обратная связь только усилит ваши позиции: все всегда сможете сослаться на мнение команды разработки, заявив, что ваши решения проверены временем и их эффективность подтверждена командой.
На этом, пожалуй, все. Хочу еще раз обратить внимание, что как бы это ни звучало, но при разработке ПО в качестве роли системного аналитика быть полезным лучше, чем быть «умным» - как по мне, так это самый главный признак профессионализма.
Комментарии (24)
Ares_ekb
16.09.2021 06:27+4У меня на проектах ещё обычно делят аналитиков на бизнес-аналитиков и системных. Первые делают обзоры аналогов (смотрят как решаются такие задачи в мире, без привязки к деталям реализации), определяют требования верхнего уровня опять-таки без привязки к конкретным формам и кнопкам. Неважно как будут обновляться данные: по нажатию кнопки или автоматически или должны ли они вообще обновляться. Бизнес-аналитик описывает требования, что в принципе должны быть такие-то данные (без разницы в каком виде они хранятся, передаются или отображаются), с ними выполняются такие-то действия (без разницы по нажатию кнопки или путем ввода команды или автоматически). Это всё превращается в ТЗ, согласовывается с заказчиком.
А дальше системные аналитики уже пишут требования непосредственно к разрабатываемой системе, выбирают варианты реализации, описывают все эти формы, кнопки, обсуждая с разработчиками на сколько сложно всё это реализовать.
На некоторых проектах ещё есть архитекторы. Но у них роль ещё более размытая, чем у аналитиков - это по сути системные аналитики, которые определяют требования к системе, пишут постановки разработчикам, или это разработчики, которые принимают архитектурные решения?.. Наверное везде по-разному...
У меня лично сейчас очень насущная проблема: где искать системных аналитиков. В основном аналитики - это бизнес-аналитики, тестировщики, тех. писатели, менеджеры и т.д. А аналитиков с технической экспертизой очень мало. И разработчики очень не охотно занимаются аналитической работой. Меня самого в аналитику переманили из разработки, я несколько лет работал разработчиком, потом аналитиком, потом снова разработчиком, потом всем сразу. И на мой взгляд это оптимальный путь развития специалиста, когда у тебя есть целостное представление о всём процессе разработки. Но сагетировать других разработчиков позаниматься аналитикой получается с переменным успехом.
Theon4eg Автор
16.09.2021 09:46+1Вы не одиноки, всего рынка сейчас такая проблема, по крайней мере в энтерпрайзе. В свете того, как сильно перегрет рынок, я все больше склоняюсь к тому, что нужно набирать стажеров, прям после вуза, пачку, два месяца их учить под себя, можно даже не давать рабочих задач, а только учебные материалы и если получится, то через какое-то время на выходе получим пачку лояльных и заточенных под конкретные задачи мидлов за небольшие деньги. Да, сложно, но одну из последних вакансий я закрывал около 10 месяцев - или нам не подходит, или компания не нравится или еще что-то.
WalkInWay
16.09.2021 10:13через какое-то время на выходе получим пачку лояльных и заточенных под конкретные задачи мидлов за небольшие деньги.
Звучит как джун, конечно :)
onets
16.09.2021 09:34+5Хорошая статья, системный подход)
Я работал и с глупыми и с умными аналитиками.
Однажды я пришел на древнее легаси. Так же проблемой было полное незнание предметной области на тот момент и полное отсутствие ориентации в коде. Мне попался умный аналитик. Он как радар наводил меня на нужные участки кода (описывая словами что этот код должен делать), я находил эти места, вносил изменения и мы вместе тестировали. Позже я уже начал ориентироватся в коде, и немного в предметной области. Это был положительный опыт.
Некоторое время спустя на этом проекте сменился аналитик. Он был глупым. Проект и я не поменялся. Но уже я ему рассказывал про проект, то что знал. Это был отрицательный опыт.
В другой раз мне попался глупый аналитик, который писал в стиле «система должна уметь…». Он не представлял сколько времени займет реализация и можно ли вообще это сделать. Я получил крайне негативный опыт.
В той же компании на другом проекте мне попался умный аналитик. Из ее описаний я чуть ли не один к одному перекладывал интерфейсы модулей и енумы. А потом в конце этапов мы синхронизировали код и документацию. Это был крайне позитивный опыт.
Участвовал в проекте, это была продуктовая компания, где постановой задач занимался сам CEO/CTO и другие сотрудники, которые в том числе и сами пользовались этим софтом. Опыт смешанный. Они были ближе к глупым аналитикам. По сути они не были аналитиками, а пользователями и переводчиками требований от внешних клиентов. Вся документация была разбросана по задачам в жире. И вот это было ужасно. Программистов перекидывали с модуля на модуль и когда возвращался обратно - приходилось по таскам в жире восстанавливать последовательность изменений, чтобы понимать что там произошло, как все это тестировать и что-нибудь не сломать.
Так же я участвовал в проектах, где я сам был и аналитиком и программистом. Из плюсов - лучше понимаешь предметную область. Из минусов - быстро надоедает и нельзя одновременно анализировать на верхнем уровне и кодить с поиском крайних кейсов на нижнем. Время разработки увеличивается раза в два. И это были совсем небольшие проекты, на 2-4 человека месяца. Бонусом были восторженные благодарности за продукт, который реально помогал людям. Опыт смешанный, полезный и познавательный, но я за разделение труда. Пока аналитик думает, как это должно выглядеть - я успею что-нибудь сделать по другой задаче/проекту.
AlexeyALV
16.09.2021 09:59+2Работал в команде, где аналитики выполняли роли и бизнес и системных. Алгоритмы обработки, формат json-ов обмена микросервисов, модель данных с описанием таблиц и детализацией по типам полей и ключей. Дизайн экранных форм для фронтэндеров тоже.
Разрабы, конечно, периодически накатывали на аналитиков за непроработанные ситуации при обработке данных.
При этом разрабы на проекте периодически менялись. Получалось, что ответственность за результат все же больше была на аналитиках и лиде разрабов.
Из этой практики сделал вывод, что правильно иметь аналитиков, но технически грамотных.
Сейчас в подчинении есть разраб, который пилит одну задачу (не самую большую) , и который категорически отказывается заниматься аналитикой. Говорит, моё дело кодить и штудировать Стаковерфлоу, а не ставить самому себе задачи. Вот так
dushinYu
16.09.2021 15:34Полистал и стало грустно. Коллеги, а что в ИТ-ВУЗах проектированию уже не учат? В свое время учили, но, действительно, это были самые скучные предметы, и большинство студентов относились к ним соответственно. Потом приходилось догонять самостоятельно, но мы знали, что догонять и для чего!
Ребята, по-моему вам надо вспомнить или обратиться к такой дисциплине, как "проектное управление". Там все ответы на ваши вопросы.
Theon4eg Автор
16.09.2021 16:11+1Боюсь, академическое вузовское проектирование для большинства задач будет или слишком "теоретическим" или слишком тяжеловесным. Для ТЗ по ГОСТу оно, может, и подойдет, а вот для более динамичных команд - скорее нет.
И еще, как проектное управление поможет в проектировании?
dushinYu
16.09.2021 16:43-2У Вас весьма странное представление о значении вузовского образования.
Причем тут "ТЗ по ГОСТу" и "более динамичные команды"?
Ну, а на вопрос
как проектное управление поможет в проектировании?
извините, но, похоже, что отвечать Вам на него не имеет смысла.
WASD1
16.09.2021 22:16Я хочу видеть в документации - чтобы "что за система" "роль нашей части системы" и "как мы сопрягаемся с соседними частями" было из документации ясно.
Этого обычно (после некоторого опыта работы в компании) достаточно, чтобы осознанно принимать решения по дизайну своей части системы.
mad_nazgul
17.09.2021 08:58+1Глупый, умный. Какая разница. Главное чтобы он с клиентами общался, а не я. <:o)
BellaLugoshi
Никогда не понимал роль системного аналитика по простой причине - нанимается человек, ему платятся (чащу всего) хорошие деньги, но лиду и разработчикам от этого только проблем, почему? Потому что теперь они 20% рабочего времени будут посвящать работе с аналитиком, при этом их основную работу никто не отменяет.
А когда происходят летучки, то аналитик весь такой модный, умный и ответственный, а разрабы работать не хотят, тупые и вообще.
И всегда возникают вопросы - если аналитик такой умный, что говорит разрабам как делать правильно, то чего же он сам не сделает? А нееее, сам он не умеет на самом деле, он может только закинув шарфик порассуждать на тему, но сделать не может.
В общем аналитик, это в 99% ситуаций бесполезный элемент, такие должности появляются в крупных компаниях с раздутыми бюджетами.
Так же хотелось бы отметить, что понятие разработчик и кодер тем и отличаются, что кодер умеет только кодировать по строгому ТЗ и кодирует отлично, но он не способен сам себе сделать ТЗ как не способен мыслить категориями целого приложения. Если у вас в компании 99% кодеры, то да, им нужен будет аналитик, но который так же будет выступать разработчиком, в вашей статье эти функции могут быть делегированы лиду (придумал же кто-то это слово использовать), видимо Тёте Лиде (руководителю команды сказать очень очень сложно).
PS: кульные поинты для тим лидов XD
Ares_ekb
У меня противоположный опыт :) В одной небольшой компании (150 человек) был отдел бизнес-анализа человек 20 и отдел системного анализа тоже человек 20. Т.е. это не крупная компания, в которой избыток денег и взяли пару аналитиков, чтобы просто были, и при этом не важно есть какой-то смысл в их работе или нет.
Бизнес-аналитики занимались вещами вообще далекими от разработки: читали и писали нормативные документы, описывали процессы, общались с предметниками со стороны заказчика, занимались всякими концептуальными документами, презентациями. Очень мало разработчиков захотят, смогут или будут заниматься чем-то подобным.
Системные аналитики занимались вещами уже более близкими к разработке. Писали постановки для разработчиков. Конечно можно обойтись и без постановок, разработчик мог бы сам разобраться какие формы, кнопки и т.п. нужны и сразу всё реализовать. Но проблема в том, что в этом случае по проекту не останется никакой документации. Где-то должны быть описаны сценарии работы с системой, описаны все эти формы, кнопки. Это нужно для согласования того, что будет реализовано с заказчиком, нужно для того, чтобы тестировщики понимали как тестировать реализованную функциональность, нужно чтобы в принципе кто-то кроме разработчика мог, прочитав постановки (описание сценариев работы с системой), понять что вообще реализовано, как этим пользоваться. Нужно чтобы было проще прогнозировать сроки разработки. Затем разрабатывается ещё куча более формальных документов (ТЗ, ПМИ, руководство пользователя, администратора и т.п.) Все эти вещи должны согласовываться с заказчиком.
Это очень большой объем работы. Если этим будут заниматься разработчики, то возможно два варианта: 1) либо у них не останется времени на разработку 2) либо после их работы ничего кроме кода не останется, у них не будет времени на документирование.
Я очень часто слышал эти идеи:
1) что аналитики - это недоразработчики, и если на проекте есть хорошие разработчики, а не кодеры, то аналитики нафиг не нужны
2) или что разработчики - это кодеры без аналитических способностей, и они даже кнопку правильно не могу сделать без детальной постановки. И вообще сначала нужно определить требования к системе, а потом по ним любая обезьяна сможет написать код
На мой взгляд, нужны и разработчики, и аналитики. И те, и те делают много важной и совершенно разной работы. Задайте себе вопрос: вы готовы, скажем, 10% времени писать код, а 90% времени писать документы и общаться с кем-нибудь? Я думаю, что очень мало разработчиков хотели бы так работать.
Даже если забить на документирование, общение с заказчиком и т.п., то без аналитиков на проекте большая проблема в том, что такие проекты не масштабируются. Всё замыкается на 2-3 супер-разработчиках, которые пытаются заниматься абсолютно всем, при росте объема работы они перестают справляться, у них падает качество работы, они не могут уследить за всем что делают "обычные" разработчики, просираются сроки, накапливается тех. долг, а супер-разработчики очень быстро выгорают. Системные аналитики как-раз позволяют масштабировать проект. Каждый из них отвечает за свою часть системы. Растет система - просто берем больше системных аналитиков. Найти 100 системных аналитиков наверное проще, чем найти 100 супер-разработчиков.
WalkInWay
А чем у вас аналитик отличается от
технического писателя, который пишет документацию, может и ТЗ оформить для истории и
PM (project manager), который общается с заказчиком?
Я не у тому, что аналитики не нужны. Просто в моем понимании и опыту они занимаются другими вещами, не связанными с разработкой вещами.
Вы приводите бизнес аналитики в примерах. Бизнес-аналитик в классическом понимании — экономист, который разбирается в процессах, экономике, финансах, организационном развитии и помогает компании решать стратегические задачи. (Из интернета)
То есть полезный член команды, но не команды разработки.
Ares_ekb
В разных компаниях было по-разному. Там где было много аналитиков был только один технический писатель. В других компаниях они тоже были единичными. На мой взгляд, технические писатели нужны либо в компаниях, где документы пишутся просто формально, чтобы были (гос. компании или гос. заказчики), хотя я не очень понимаю как можно писать документы, не погружаясь в содержательную часть, и с таким особо не сталкивался. Либо документы всё-таки в основном пишут аналитики, а тех. писатель отвечает за оформление, стиль, соответствие гостам и разным правилам, за организацию документооборота в целом, за Word-шаблоны, за организацию Wiki и т.д. Короче, я не понимаю как тех. писатели могут заменить аналитиков. Либо на самом деле это всё-таки аналитики, но их называют тех. писателями.
Ещё у нас документы сильно пересекаются. Например, постановки используются в качестве основы для ПМИ и руководства пользователя. Аналитики их сразу пишут таким образом, чтобы потом меньше времени тратить на ПМИ и т.п. А если бы аналитики занимались только постановками, а тех. документами занимались тех. писатели, то наверное это было бы более трудозатратно.
РП у нас занимаются сугубо организационной работой, обсуждают с заказчиком сроки, деньги. В содержательную часть они конечно погружаются, но уж точно аналитические документы и тех. документацию писать не будут. И с предметными специалистами со стороны заказчика тоже какие-то технические детали обсуждать не будут. Но, вообще, да, работа и бизнес-аналитиков, и системных аналитиков частично пересекается с работой РП.
У нас системные аналитики - это основное связующее звено между другими сотрудниками. Они разгружают РП в части общения с заказчиком и разработчиками. Разгружают разработчиков в части поиска вариантов, написания документов. В целом отвечают за свою часть системы, знают что хочет заказчик, как вообще эти задачи решаются в мире, что у нас сейчас реализовано, когда будет реализовано остальное и т.д. Один РП просто не сможет держать всё это в голове, тем более, что часто у него ещё несколько проектов.
Насчет бизнес-аналитиков. Здесь есть разные взгляды. Действительно, часто бизнес-аналитики - это не ИТшники, у них экономическое или другое образование. Часто они работают со стороны заказчика, а не ИТ компании. Но на мой взгляд здесь смешиваются две роли: предметный специалист (он хорошо разбирается в медицине, финансах, управлении или ещё чём-то) и сугубо бизнес-аналитик. В моём понимании "профессиональный" бизнес-аналитик не обязан быть специалистом в экономике, управлении и т.п. На этапе бизнес-анализа обычно происходит следующее:
1) На вход поступает задача в стиле сделайте нам то не знаю что и не знаю зачем, но чтобы было, потому что очень надо :)
2) Бизнес-аналитик не является специалистом в этой хз какой области, но он может собрать информацию по этой теме: от заказчика, из инета, от своих коллег, из других уже готовых инструментов и т.д. Может оценить достаточно ли информации или нужно привлечь ещё каких-то экспертов. На выходе он выдает аналитический обзор по теме, в котором разбивает всю информацию по категориям, пишет общие выводы. Затем любой человек со стороны заказчика или из команды ИТшников может прочитать этот документ из 5 минут погрузиться в тему.
3) Затем бизнес-аналитик более целенаправленно изучает аналоги создаваемой системы. Обычно всё уже давно сделано и начинать делать что-то с нуля, не познакомившись с чужим опытом, очень самонадеянно. А если аналогов нет, то либо плохо искали, либо требуется создать какую-то никому не нужную шнягу.
4) Затем он определяет критерии оценки аналогов: от наличия нужной функциональности до "красивости" UI или наличия регистрации в реестре отечественного ПО. Это прямо очень большая тема. Может быть небольшой плоский список критериев, может быть сложный древовидный. Может быть разная значимость критериев.
5) Затем оценивает аналоги по этим критериям. Это ещё большая тема. Можно оценивать по разным шкалам (да/нет, категориальная, порядковая, абсолютная и т.п.)
6) Вычисляет итоговые оценки для аналогов. Методов полно. Начиная от подсчета вариантов "да" или вычисления взвешенных сумм до метода анализа иерархий, вычисления всяких коэффициентов конкордации Кендалла и т.п.
7) Выбирает наилучшие аналоги создаваемой системы. Если есть аналог, который прямо на 100% подходит по всем критериям, то просто берем его как есть и ничего разрабатывать не нужно. Например, если у нас нет особых требований к СУБД или ОС, то нет смысла делать свою. А если есть специфические критерии, то возможно придется сделать и свою. Или может быть несколько аналогов, которые закрывают задачу. Например, нужно сделать какую-нибудь аналитическую систему. Берем СУБД, ETL-движок, движок для отчетов, для информационных панелей и т.п. - и собираем из всего этого, что нужно заказчику. Может быть ситуация, что есть готовые системы, но нужно разработать какой-нибудь интеграционный модуль, чтобы они работали совместно. Или, наконец, нет аналогов, которые полностью закрывают потребности заказчика, тогда нужно уже что-то разрабатывать.
8) Но разрабатывать ещё рано. Сначала нужно детально описать наилучший из аналогов. Потому что даже если мы будем делать что-то своё, всё равно на 99% мы повторим то, что уже сделано другими людьми. В лучшем случае там будет 1% чего-то принципиально нового. Что-то новое может быть на уровне новых подсистем, новых функций у существующих подсистем или на уровне параметров уже существующих функций. Скажем, вы разрабатываете новый текстовый редактор, социальную сеть, СУБД и т.д. Очень сложно придумать там что-то принципиально новое, скорее всего вы просто улучшите какие-то параметры функций, уже реализованных в других продуктах. Чуть более удобно будет редактироваться текст, чуть быстрее обрабатываться запросы, но никакую новую подсистему или новую функцию вы не придумаете. Короче, описали прототип нашей системы.
9) Описали чем наша система будет отличаться от прототипа. Если ничем, то может и делать её нет смысла? Какие у неё будут конкурентные преимущества? На выходе получили описание улучшенного прототипа. Ура! Теперь можно перенести это описание в ТЗ или в другой документ с описанием подсистем, функциональных и не функциональных требований. Причем, важный момент, что в этом документе не описываются никакие технические решения, языки программирования, форматы обмена данными, используемые СУБД (реляционные, NoSQL) и т.п. Если что-нибудь такое просочится в ТЗ, а потом окажется что эта СУБД не подходит, то, блин, всё равно придется её использовать. Поэтому никаких технических деталей.
10) Этот документ уже можно отдать системным аналитикам, чтобы они эти бизнес-требования превратили в технические требования к системе, описали где будет сервер, где клиент, где СУБД, какая СУБД, как всё это взаимодействует между собой, какие где формы, кнопки и т.д.
Соответственно вопрос :) Чтобы всё это делать нужно ли человеку быть экономистом и т.п.? Я, например, работал бизнес-аналитиком с ИТшным образованием. На мой взгляд, "профессиональный" бизнес-аналитик должен быть в первую очередь специалистом по бизнес-анализу, а не по управленческому учету или чему-то подобному. Если ему понадобятся знания по учету, финансам, процессам и т.п., то он получит эту информацию от предметного специалиста. Конечно, один человек может и совмещать несколько ролей, но это совершенно не обязательно.
Является ли бизнес-аналитик членом команды разработки?.. Ну, наверное в меньшей степени чем системный аналитик. Он активно работает на начальном этапе, до начала основной фазы разработки. Может и после запуска разработки тоже проводить какие-то исследования. Хотя, блин, если разработкой считать весь процесс, то наверное всё-таки участвует: 1) бизнес-анализ 2) системный анализ 3) реализация в коде 4) тестирование 5) демонстрация результатов заказчику.
На самом деле этот процесс от бизнес-анализа до демонстрации может присутствовать и при решении каких-то небольших задачек. Когда у разработчика возникает задача, в которой ничего не понятно, то он включает режим бизнес-аналитика и начинает искать варианты решения задачи, оценивает эти варианты и т.д. Вообще для разработчиков эти аналитические навыки очень полезны, и понимание процесса разработки в целом тоже полезно. Такой разработчик может решать более сложные задачи, ему проще взаимодействовать с другими участниками проекта (потому что он знает, что от них нужно требовать или ожидать), у него более высокое качество работы (потому что он знает что дальше система пойдет в тестирование и будет показываться заказчику и он ещё на этапе разработки может поставить себя на место тестировщика или заказчика и оценить адекватность сделанного) и, самое главное, ему легко делиться работой с коллегами, он не пытается всё сделать сам, понимает зачем нужны аналитики и позволяет/помогает им сделать то, что мог бы сделать и сам, но не делает потому что рабочий день ограничен и ему больше нравится разработка.
GorOleg
У PM, если это не микропроект, обычно несколько другие задачи , чем выяснять детальные требования. Он общается с БигБоссами . А где вы видели ТЗ в котором все детали прописаны, я вообще не знаю, в каком то идеальном проекте наверное. Кто на стороне заказчика такое сможет подготовить? Если бы у него такие специалисты были он бы проект сам сделал :-)
BellaLugoshi
Угу, вложился бы на 30-50 млн рубликов, нанял штат разработчиков и написал бы за неделю софт (нет).
По своему опыту - наличие человека могущего дооформить ТЗ на стороне исполнителя абсолютно ничем не поможет, если не будет человека на стороне заказчика, могущего сделать то же самое. Собственно у нас был возможный контракт на 50 млн, по автоматизации производственных процессов, но всё умерло так и не начавшись, тупо на заводе не смогли найти человека, который понимал бы как всё работает. Оказалось что проще обанкротить завод и выгнать на улицу 1500 человек. XD Это бизнес по-русски, когда у руля ворьё.
SVNKz
Если добавить документы ГОСТ из области разработки программ, то предыдущие сообщения интересны как основа для подготовки специалиста по разработке ТЗ. Эта узкая специализация необходима и будет востребована по мере накопления опыта и знаний, основанных на анализе причин неудач и возможных вариантов предположительно "удачных" разработок.
В любом случае это разделение труда или выделение в отдельную категорию специалиста, отвечающего за грамотно разработанное ТЗ, исключит вмешательство "аналитиков" в процесс разработки.
Theon4eg Автор
Я за всю свою карьеру не встречал разработчиков, которые бы хотели работать с ТЗ по ГОСТу. Очень часто такое ТЗ одновременно и избыточно, и недостаточно или неоптимально. В используемой в статье терминологии аналитик, который ограничивается классическим ТЗ - это "глупый аналитик".
Nehc
Я вот тоже полезных аналитиков на практике не встречал (но может у меня практика специфическая), но как автор излагает мне понравилось. Может просто не повезло?
Theon4eg Автор
К сожалению, я очень часто, в том числе и от друзей (не коллег) разработчиков, слышу подобное. И я думаю, что средний технический уровень системных аналитиков по отрасли действительно невысок. Я пришел в системный анализ будучи лидом разработки (так карьера сложилась), но это, скорее, исключение: обычно аналитики не имеют опыта разработки (институтские лабы не в счет).
Но есть решение (рабочее, проверяли): аналитика можно "настроить" под себя: во-первых, помочь с базовым техническим бекграундом, а во-вторых, совместно с ним проговорить и найти те области, где он будет вам действительно полезен и закрывать какую-то вашу боль.
RomanK_BY
Скорее соглашусь, чем не соглашусь. Начинал свою карьеру как бизнес-аналитик на проекте, где были в основном разработчики Мидл/Сениор/Лид.
Был хороший проджект менеджер, который в большинстве случаем и способствовал общению и обмену знаниями. Как итог, уже через несколько недель писались сторис и разработчики писали код. В сторис были адекватные требования, поскольку лиды и сениористые ребята не стеснялись и были готовы помогать мне понять, что и как. Очень позитивный опыт.
ARadzishevskiy
Перефразируя: Если инженер такой умный, что он говорит токарям как выточить деталь, то почему он сам не выточит?
Я сам 18 лет работал разработчиком (в том числе тим-лидом) и позже перешел в системные аналитики и более 10 лет практикую на этом поле.
Проблема состоит в том, что этап анализа - это отдельная функция в процессе разработки. это отдельный вид деятельности, требующий соответствующих навыков и умений.
Сам процесс анализа тоже делится на этапы.
1) Подготовительный этап состоит в общении с заказчиком (специалист по работе с заказчиком). Для того, чтобы профессионально снять показания с заказчика, необходимо учиться этому и понимать, что такое, например, эмоциональный интеллект, как манипулировать людьми, как правильно формализовать полученную информацию и т.д. Далеко не все хорошие разработчики обладают этими знаниями и умениями.
2) Проектирование. Для качественного выполнения проектирования, надо владеть инструментами проектирования. Например: UML хотя бы 3-5 видов диаграмм, BPMN для описания, обсуждения и внесения изменений в автоматизируемые бизнес-процессы. Иногда необходимо использовать диаграммы последовательностей, чтобы разрулить зацикливания и т.п.
Во всех эти активностях необходимо иметь опыт. Только он даст достаточный профессионализм. Может программист этим качественно овладеть? Да, если у него есть достаточно времени серьезно этим заниматься и развиваться в этих направлениях. Но есть риск уйти в это направление полностью иначе будет посредственность в обоих направлениях.
Ares_ekb
На мой взгляд, не обязательно. Если человек 5-10 лет занимался разработкой и столько же занимался аналитикой или другими направлениями и достиг нормального уровня, то эти знания никуда не денутся. Он будет и хорошим разработчиком, и хорошим аналитиком. Да, у него может не быть опыта использования каких-нибудь фреймвоков, которые появились год назад, но, на мой взгляд, это последнее, что требуется от специалиста. Куда важнее понимание процесса разработки в целом, в принципе способность самостоятельно работать, задавать вопросы, искать варианты, принимать решения, если для разработчика, то способность писать вменяемый код и т.п. Эти навыки никуда не деваются, единственное, что рабочий день 8 часов и в один момент времени можно заниматься чем-то одним. Если один человек будет заниматься всем этим одновременно, ну, наверное, да, качество будет страдать. Потому что нет смысла и времени делать нормальную аналитику, если ты сам потом это и реализуешь. Или если делаешь основной акцент на аналитике, то нет времени писать нормальный код.