Комментарии 24
Никогда не понимал роль системного аналитика по простой причине - нанимается человек, ему платятся (чащу всего) хорошие деньги, но лиду и разработчикам от этого только проблем, почему? Потому что теперь они 20% рабочего времени будут посвящать работе с аналитиком, при этом их основную работу никто не отменяет.
А когда происходят летучки, то аналитик весь такой модный, умный и ответственный, а разрабы работать не хотят, тупые и вообще.
И всегда возникают вопросы - если аналитик такой умный, что говорит разрабам как делать правильно, то чего же он сам не сделает? А нееее, сам он не умеет на самом деле, он может только закинув шарфик порассуждать на тему, но сделать не может.
В общем аналитик, это в 99% ситуаций бесполезный элемент, такие должности появляются в крупных компаниях с раздутыми бюджетами.
Так же хотелось бы отметить, что понятие разработчик и кодер тем и отличаются, что кодер умеет только кодировать по строгому ТЗ и кодирует отлично, но он не способен сам себе сделать ТЗ как не способен мыслить категориями целого приложения. Если у вас в компании 99% кодеры, то да, им нужен будет аналитик, но который так же будет выступать разработчиком, в вашей статье эти функции могут быть делегированы лиду (придумал же кто-то это слово использовать), видимо Тёте Лиде (руководителю команды сказать очень очень сложно).
PS: кульные поинты для тим лидов XD
У меня противоположный опыт :) В одной небольшой компании (150 человек) был отдел бизнес-анализа человек 20 и отдел системного анализа тоже человек 20. Т.е. это не крупная компания, в которой избыток денег и взяли пару аналитиков, чтобы просто были, и при этом не важно есть какой-то смысл в их работе или нет.
Бизнес-аналитики занимались вещами вообще далекими от разработки: читали и писали нормативные документы, описывали процессы, общались с предметниками со стороны заказчика, занимались всякими концептуальными документами, презентациями. Очень мало разработчиков захотят, смогут или будут заниматься чем-то подобным.
Системные аналитики занимались вещами уже более близкими к разработке. Писали постановки для разработчиков. Конечно можно обойтись и без постановок, разработчик мог бы сам разобраться какие формы, кнопки и т.п. нужны и сразу всё реализовать. Но проблема в том, что в этом случае по проекту не останется никакой документации. Где-то должны быть описаны сценарии работы с системой, описаны все эти формы, кнопки. Это нужно для согласования того, что будет реализовано с заказчиком, нужно для того, чтобы тестировщики понимали как тестировать реализованную функциональность, нужно чтобы в принципе кто-то кроме разработчика мог, прочитав постановки (описание сценариев работы с системой), понять что вообще реализовано, как этим пользоваться. Нужно чтобы было проще прогнозировать сроки разработки. Затем разрабатывается ещё куча более формальных документов (ТЗ, ПМИ, руководство пользователя, администратора и т.п.) Все эти вещи должны согласовываться с заказчиком.
Это очень большой объем работы. Если этим будут заниматься разработчики, то возможно два варианта: 1) либо у них не останется времени на разработку 2) либо после их работы ничего кроме кода не останется, у них не будет времени на документирование.
Я очень часто слышал эти идеи:
1) что аналитики - это недоразработчики, и если на проекте есть хорошие разработчики, а не кодеры, то аналитики нафиг не нужны
2) или что разработчики - это кодеры без аналитических способностей, и они даже кнопку правильно не могу сделать без детальной постановки. И вообще сначала нужно определить требования к системе, а потом по ним любая обезьяна сможет написать код
На мой взгляд, нужны и разработчики, и аналитики. И те, и те делают много важной и совершенно разной работы. Задайте себе вопрос: вы готовы, скажем, 10% времени писать код, а 90% времени писать документы и общаться с кем-нибудь? Я думаю, что очень мало разработчиков хотели бы так работать.
Даже если забить на документирование, общение с заказчиком и т.п., то без аналитиков на проекте большая проблема в том, что такие проекты не масштабируются. Всё замыкается на 2-3 супер-разработчиках, которые пытаются заниматься абсолютно всем, при росте объема работы они перестают справляться, у них падает качество работы, они не могут уследить за всем что делают "обычные" разработчики, просираются сроки, накапливается тех. долг, а супер-разработчики очень быстро выгорают. Системные аналитики как-раз позволяют масштабировать проект. Каждый из них отвечает за свою часть системы. Растет система - просто берем больше системных аналитиков. Найти 100 системных аналитиков наверное проще, чем найти 100 супер-разработчиков.
А чем у вас аналитик отличается от
технического писателя, который пишет документацию, может и ТЗ оформить для истории и
PM (project manager), который общается с заказчиком?
Я не у тому, что аналитики не нужны. Просто в моем понимании и опыту они занимаются другими вещами, не связанными с разработкой вещами.
Вы приводите бизнес аналитики в примерах. Бизнес-аналитик в классическом понимании — экономист, который разбирается в процессах, экономике, финансах, организационном развитии и помогает компании решать стратегические задачи. (Из интернета)
То есть полезный член команды, но не команды разработки.
В разных компаниях было по-разному. Там где было много аналитиков был только один технический писатель. В других компаниях они тоже были единичными. На мой взгляд, технические писатели нужны либо в компаниях, где документы пишутся просто формально, чтобы были (гос. компании или гос. заказчики), хотя я не очень понимаю как можно писать документы, не погружаясь в содержательную часть, и с таким особо не сталкивался. Либо документы всё-таки в основном пишут аналитики, а тех. писатель отвечает за оформление, стиль, соответствие гостам и разным правилам, за организацию документооборота в целом, за Word-шаблоны, за организацию Wiki и т.д. Короче, я не понимаю как тех. писатели могут заменить аналитиков. Либо на самом деле это всё-таки аналитики, но их называют тех. писателями.
Ещё у нас документы сильно пересекаются. Например, постановки используются в качестве основы для ПМИ и руководства пользователя. Аналитики их сразу пишут таким образом, чтобы потом меньше времени тратить на ПМИ и т.п. А если бы аналитики занимались только постановками, а тех. документами занимались тех. писатели, то наверное это было бы более трудозатратно.
РП у нас занимаются сугубо организационной работой, обсуждают с заказчиком сроки, деньги. В содержательную часть они конечно погружаются, но уж точно аналитические документы и тех. документацию писать не будут. И с предметными специалистами со стороны заказчика тоже какие-то технические детали обсуждать не будут. Но, вообще, да, работа и бизнес-аналитиков, и системных аналитиков частично пересекается с работой РП.
У нас системные аналитики - это основное связующее звено между другими сотрудниками. Они разгружают РП в части общения с заказчиком и разработчиками. Разгружают разработчиков в части поиска вариантов, написания документов. В целом отвечают за свою часть системы, знают что хочет заказчик, как вообще эти задачи решаются в мире, что у нас сейчас реализовано, когда будет реализовано остальное и т.д. Один РП просто не сможет держать всё это в голове, тем более, что часто у него ещё несколько проектов.
Насчет бизнес-аналитиков. Здесь есть разные взгляды. Действительно, часто бизнес-аналитики - это не ИТшники, у них экономическое или другое образование. Часто они работают со стороны заказчика, а не ИТ компании. Но на мой взгляд здесь смешиваются две роли: предметный специалист (он хорошо разбирается в медицине, финансах, управлении или ещё чём-то) и сугубо бизнес-аналитик. В моём понимании "профессиональный" бизнес-аналитик не обязан быть специалистом в экономике, управлении и т.п. На этапе бизнес-анализа обычно происходит следующее:
1) На вход поступает задача в стиле сделайте нам то не знаю что и не знаю зачем, но чтобы было, потому что очень надо :)
2) Бизнес-аналитик не является специалистом в этой хз какой области, но он может собрать информацию по этой теме: от заказчика, из инета, от своих коллег, из других уже готовых инструментов и т.д. Может оценить достаточно ли информации или нужно привлечь ещё каких-то экспертов. На выходе он выдает аналитический обзор по теме, в котором разбивает всю информацию по категориям, пишет общие выводы. Затем любой человек со стороны заказчика или из команды ИТшников может прочитать этот документ из 5 минут погрузиться в тему.
3) Затем бизнес-аналитик более целенаправленно изучает аналоги создаваемой системы. Обычно всё уже давно сделано и начинать делать что-то с нуля, не познакомившись с чужим опытом, очень самонадеянно. А если аналогов нет, то либо плохо искали, либо требуется создать какую-то никому не нужную шнягу.
4) Затем он определяет критерии оценки аналогов: от наличия нужной функциональности до "красивости" UI или наличия регистрации в реестре отечественного ПО. Это прямо очень большая тема. Может быть небольшой плоский список критериев, может быть сложный древовидный. Может быть разная значимость критериев.
5) Затем оценивает аналоги по этим критериям. Это ещё большая тема. Можно оценивать по разным шкалам (да/нет, категориальная, порядковая, абсолютная и т.п.)
6) Вычисляет итоговые оценки для аналогов. Методов полно. Начиная от подсчета вариантов "да" или вычисления взвешенных сумм до метода анализа иерархий, вычисления всяких коэффициентов конкордации Кендалла и т.п.
7) Выбирает наилучшие аналоги создаваемой системы. Если есть аналог, который прямо на 100% подходит по всем критериям, то просто берем его как есть и ничего разрабатывать не нужно. Например, если у нас нет особых требований к СУБД или ОС, то нет смысла делать свою. А если есть специфические критерии, то возможно придется сделать и свою. Или может быть несколько аналогов, которые закрывают задачу. Например, нужно сделать какую-нибудь аналитическую систему. Берем СУБД, ETL-движок, движок для отчетов, для информационных панелей и т.п. - и собираем из всего этого, что нужно заказчику. Может быть ситуация, что есть готовые системы, но нужно разработать какой-нибудь интеграционный модуль, чтобы они работали совместно. Или, наконец, нет аналогов, которые полностью закрывают потребности заказчика, тогда нужно уже что-то разрабатывать.
8) Но разрабатывать ещё рано. Сначала нужно детально описать наилучший из аналогов. Потому что даже если мы будем делать что-то своё, всё равно на 99% мы повторим то, что уже сделано другими людьми. В лучшем случае там будет 1% чего-то принципиально нового. Что-то новое может быть на уровне новых подсистем, новых функций у существующих подсистем или на уровне параметров уже существующих функций. Скажем, вы разрабатываете новый текстовый редактор, социальную сеть, СУБД и т.д. Очень сложно придумать там что-то принципиально новое, скорее всего вы просто улучшите какие-то параметры функций, уже реализованных в других продуктах. Чуть более удобно будет редактироваться текст, чуть быстрее обрабатываться запросы, но никакую новую подсистему или новую функцию вы не придумаете. Короче, описали прототип нашей системы.
9) Описали чем наша система будет отличаться от прототипа. Если ничем, то может и делать её нет смысла? Какие у неё будут конкурентные преимущества? На выходе получили описание улучшенного прототипа. Ура! Теперь можно перенести это описание в ТЗ или в другой документ с описанием подсистем, функциональных и не функциональных требований. Причем, важный момент, что в этом документе не описываются никакие технические решения, языки программирования, форматы обмена данными, используемые СУБД (реляционные, NoSQL) и т.п. Если что-нибудь такое просочится в ТЗ, а потом окажется что эта СУБД не подходит, то, блин, всё равно придется её использовать. Поэтому никаких технических деталей.
10) Этот документ уже можно отдать системным аналитикам, чтобы они эти бизнес-требования превратили в технические требования к системе, описали где будет сервер, где клиент, где СУБД, какая СУБД, как всё это взаимодействует между собой, какие где формы, кнопки и т.д.
Соответственно вопрос :) Чтобы всё это делать нужно ли человеку быть экономистом и т.п.? Я, например, работал бизнес-аналитиком с ИТшным образованием. На мой взгляд, "профессиональный" бизнес-аналитик должен быть в первую очередь специалистом по бизнес-анализу, а не по управленческому учету или чему-то подобному. Если ему понадобятся знания по учету, финансам, процессам и т.п., то он получит эту информацию от предметного специалиста. Конечно, один человек может и совмещать несколько ролей, но это совершенно не обязательно.
Является ли бизнес-аналитик членом команды разработки?.. Ну, наверное в меньшей степени чем системный аналитик. Он активно работает на начальном этапе, до начала основной фазы разработки. Может и после запуска разработки тоже проводить какие-то исследования. Хотя, блин, если разработкой считать весь процесс, то наверное всё-таки участвует: 1) бизнес-анализ 2) системный анализ 3) реализация в коде 4) тестирование 5) демонстрация результатов заказчику.
На самом деле этот процесс от бизнес-анализа до демонстрации может присутствовать и при решении каких-то небольших задачек. Когда у разработчика возникает задача, в которой ничего не понятно, то он включает режим бизнес-аналитика и начинает искать варианты решения задачи, оценивает эти варианты и т.д. Вообще для разработчиков эти аналитические навыки очень полезны, и понимание процесса разработки в целом тоже полезно. Такой разработчик может решать более сложные задачи, ему проще взаимодействовать с другими участниками проекта (потому что он знает, что от них нужно требовать или ожидать), у него более высокое качество работы (потому что он знает что дальше система пойдет в тестирование и будет показываться заказчику и он ещё на этапе разработки может поставить себя на место тестировщика или заказчика и оценить адекватность сделанного) и, самое главное, ему легко делиться работой с коллегами, он не пытается всё сделать сам, понимает зачем нужны аналитики и позволяет/помогает им сделать то, что мог бы сделать и сам, но не делает потому что рабочий день ограничен и ему больше нравится разработка.
У PM, если это не микропроект, обычно несколько другие задачи , чем выяснять детальные требования. Он общается с БигБоссами . А где вы видели ТЗ в котором все детали прописаны, я вообще не знаю, в каком то идеальном проекте наверное. Кто на стороне заказчика такое сможет подготовить? Если бы у него такие специалисты были он бы проект сам сделал :-)
Угу, вложился бы на 30-50 млн рубликов, нанял штат разработчиков и написал бы за неделю софт (нет).
По своему опыту - наличие человека могущего дооформить ТЗ на стороне исполнителя абсолютно ничем не поможет, если не будет человека на стороне заказчика, могущего сделать то же самое. Собственно у нас был возможный контракт на 50 млн, по автоматизации производственных процессов, но всё умерло так и не начавшись, тупо на заводе не смогли найти человека, который понимал бы как всё работает. Оказалось что проще обанкротить завод и выгнать на улицу 1500 человек. XD Это бизнес по-русски, когда у руля ворьё.
Если добавить документы ГОСТ из области разработки программ, то предыдущие сообщения интересны как основа для подготовки специалиста по разработке ТЗ. Эта узкая специализация необходима и будет востребована по мере накопления опыта и знаний, основанных на анализе причин неудач и возможных вариантов предположительно "удачных" разработок.
В любом случае это разделение труда или выделение в отдельную категорию специалиста, отвечающего за грамотно разработанное ТЗ, исключит вмешательство "аналитиков" в процесс разработки.
К сожалению, я очень часто, в том числе и от друзей (не коллег) разработчиков, слышу подобное. И я думаю, что средний технический уровень системных аналитиков по отрасли действительно невысок. Я пришел в системный анализ будучи лидом разработки (так карьера сложилась), но это, скорее, исключение: обычно аналитики не имеют опыта разработки (институтские лабы не в счет).
Но есть решение (рабочее, проверяли): аналитика можно "настроить" под себя: во-первых, помочь с базовым техническим бекграундом, а во-вторых, совместно с ним проговорить и найти те области, где он будет вам действительно полезен и закрывать какую-то вашу боль.
Скорее соглашусь, чем не соглашусь. Начинал свою карьеру как бизнес-аналитик на проекте, где были в основном разработчики Мидл/Сениор/Лид.
Был хороший проджект менеджер, который в большинстве случаем и способствовал общению и обмену знаниями. Как итог, уже через несколько недель писались сторис и разработчики писали код. В сторис были адекватные требования, поскольку лиды и сениористые ребята не стеснялись и были готовы помогать мне понять, что и как. Очень позитивный опыт.
если аналитик такой умный, что говорит разрабам как делать правильно, то чего же он сам не сделает?
Перефразируя: Если инженер такой умный, что он говорит токарям как выточить деталь, то почему он сам не выточит?
Я сам 18 лет работал разработчиком (в том числе тим-лидом) и позже перешел в системные аналитики и более 10 лет практикую на этом поле.
Проблема состоит в том, что этап анализа - это отдельная функция в процессе разработки. это отдельный вид деятельности, требующий соответствующих навыков и умений.
Сам процесс анализа тоже делится на этапы.
1) Подготовительный этап состоит в общении с заказчиком (специалист по работе с заказчиком). Для того, чтобы профессионально снять показания с заказчика, необходимо учиться этому и понимать, что такое, например, эмоциональный интеллект, как манипулировать людьми, как правильно формализовать полученную информацию и т.д. Далеко не все хорошие разработчики обладают этими знаниями и умениями.
2) Проектирование. Для качественного выполнения проектирования, надо владеть инструментами проектирования. Например: UML хотя бы 3-5 видов диаграмм, BPMN для описания, обсуждения и внесения изменений в автоматизируемые бизнес-процессы. Иногда необходимо использовать диаграммы последовательностей, чтобы разрулить зацикливания и т.п.
Во всех эти активностях необходимо иметь опыт. Только он даст достаточный профессионализм. Может программист этим качественно овладеть? Да, если у него есть достаточно времени серьезно этим заниматься и развиваться в этих направлениях. Но есть риск уйти в это направление полностью иначе будет посредственность в обоих направлениях.
Но есть риск уйти в это направление полностью иначе будет посредственность в обоих направлениях.
На мой взгляд, не обязательно. Если человек 5-10 лет занимался разработкой и столько же занимался аналитикой или другими направлениями и достиг нормального уровня, то эти знания никуда не денутся. Он будет и хорошим разработчиком, и хорошим аналитиком. Да, у него может не быть опыта использования каких-нибудь фреймвоков, которые появились год назад, но, на мой взгляд, это последнее, что требуется от специалиста. Куда важнее понимание процесса разработки в целом, в принципе способность самостоятельно работать, задавать вопросы, искать варианты, принимать решения, если для разработчика, то способность писать вменяемый код и т.п. Эти навыки никуда не деваются, единственное, что рабочий день 8 часов и в один момент времени можно заниматься чем-то одним. Если один человек будет заниматься всем этим одновременно, ну, наверное, да, качество будет страдать. Потому что нет смысла и времени делать нормальную аналитику, если ты сам потом это и реализуешь. Или если делаешь основной акцент на аналитике, то нет времени писать нормальный код.
У меня на проектах ещё обычно делят аналитиков на бизнес-аналитиков и системных. Первые делают обзоры аналогов (смотрят как решаются такие задачи в мире, без привязки к деталям реализации), определяют требования верхнего уровня опять-таки без привязки к конкретным формам и кнопкам. Неважно как будут обновляться данные: по нажатию кнопки или автоматически или должны ли они вообще обновляться. Бизнес-аналитик описывает требования, что в принципе должны быть такие-то данные (без разницы в каком виде они хранятся, передаются или отображаются), с ними выполняются такие-то действия (без разницы по нажатию кнопки или путем ввода команды или автоматически). Это всё превращается в ТЗ, согласовывается с заказчиком.
А дальше системные аналитики уже пишут требования непосредственно к разрабатываемой системе, выбирают варианты реализации, описывают все эти формы, кнопки, обсуждая с разработчиками на сколько сложно всё это реализовать.
На некоторых проектах ещё есть архитекторы. Но у них роль ещё более размытая, чем у аналитиков - это по сути системные аналитики, которые определяют требования к системе, пишут постановки разработчикам, или это разработчики, которые принимают архитектурные решения?.. Наверное везде по-разному...
У меня лично сейчас очень насущная проблема: где искать системных аналитиков. В основном аналитики - это бизнес-аналитики, тестировщики, тех. писатели, менеджеры и т.д. А аналитиков с технической экспертизой очень мало. И разработчики очень не охотно занимаются аналитической работой. Меня самого в аналитику переманили из разработки, я несколько лет работал разработчиком, потом аналитиком, потом снова разработчиком, потом всем сразу. И на мой взгляд это оптимальный путь развития специалиста, когда у тебя есть целостное представление о всём процессе разработки. Но сагетировать других разработчиков позаниматься аналитикой получается с переменным успехом.
Вы не одиноки, всего рынка сейчас такая проблема, по крайней мере в энтерпрайзе. В свете того, как сильно перегрет рынок, я все больше склоняюсь к тому, что нужно набирать стажеров, прям после вуза, пачку, два месяца их учить под себя, можно даже не давать рабочих задач, а только учебные материалы и если получится, то через какое-то время на выходе получим пачку лояльных и заточенных под конкретные задачи мидлов за небольшие деньги. Да, сложно, но одну из последних вакансий я закрывал около 10 месяцев - или нам не подходит, или компания не нравится или еще что-то.
Хорошая статья, системный подход)
Я работал и с глупыми и с умными аналитиками.
Однажды я пришел на древнее легаси. Так же проблемой было полное незнание предметной области на тот момент и полное отсутствие ориентации в коде. Мне попался умный аналитик. Он как радар наводил меня на нужные участки кода (описывая словами что этот код должен делать), я находил эти места, вносил изменения и мы вместе тестировали. Позже я уже начал ориентироватся в коде, и немного в предметной области. Это был положительный опыт.
Некоторое время спустя на этом проекте сменился аналитик. Он был глупым. Проект и я не поменялся. Но уже я ему рассказывал про проект, то что знал. Это был отрицательный опыт.
В другой раз мне попался глупый аналитик, который писал в стиле «система должна уметь…». Он не представлял сколько времени займет реализация и можно ли вообще это сделать. Я получил крайне негативный опыт.
В той же компании на другом проекте мне попался умный аналитик. Из ее описаний я чуть ли не один к одному перекладывал интерфейсы модулей и енумы. А потом в конце этапов мы синхронизировали код и документацию. Это был крайне позитивный опыт.
Участвовал в проекте, это была продуктовая компания, где постановой задач занимался сам CEO/CTO и другие сотрудники, которые в том числе и сами пользовались этим софтом. Опыт смешанный. Они были ближе к глупым аналитикам. По сути они не были аналитиками, а пользователями и переводчиками требований от внешних клиентов. Вся документация была разбросана по задачам в жире. И вот это было ужасно. Программистов перекидывали с модуля на модуль и когда возвращался обратно - приходилось по таскам в жире восстанавливать последовательность изменений, чтобы понимать что там произошло, как все это тестировать и что-нибудь не сломать.
Так же я участвовал в проектах, где я сам был и аналитиком и программистом. Из плюсов - лучше понимаешь предметную область. Из минусов - быстро надоедает и нельзя одновременно анализировать на верхнем уровне и кодить с поиском крайних кейсов на нижнем. Время разработки увеличивается раза в два. И это были совсем небольшие проекты, на 2-4 человека месяца. Бонусом были восторженные благодарности за продукт, который реально помогал людям. Опыт смешанный, полезный и познавательный, но я за разделение труда. Пока аналитик думает, как это должно выглядеть - я успею что-нибудь сделать по другой задаче/проекту.
Работал в команде, где аналитики выполняли роли и бизнес и системных. Алгоритмы обработки, формат json-ов обмена микросервисов, модель данных с описанием таблиц и детализацией по типам полей и ключей. Дизайн экранных форм для фронтэндеров тоже.
Разрабы, конечно, периодически накатывали на аналитиков за непроработанные ситуации при обработке данных.
При этом разрабы на проекте периодически менялись. Получалось, что ответственность за результат все же больше была на аналитиках и лиде разрабов.
Из этой практики сделал вывод, что правильно иметь аналитиков, но технически грамотных.
Сейчас в подчинении есть разраб, который пилит одну задачу (не самую большую) , и который категорически отказывается заниматься аналитикой. Говорит, моё дело кодить и штудировать Стаковерфлоу, а не ставить самому себе задачи. Вот так
Полистал и стало грустно. Коллеги, а что в ИТ-ВУЗах проектированию уже не учат? В свое время учили, но, действительно, это были самые скучные предметы, и большинство студентов относились к ним соответственно. Потом приходилось догонять самостоятельно, но мы знали, что догонять и для чего!
Ребята, по-моему вам надо вспомнить или обратиться к такой дисциплине, как "проектное управление". Там все ответы на ваши вопросы.
Я хочу видеть в документации - чтобы "что за система" "роль нашей части системы" и "как мы сопрягаемся с соседними частями" было из документации ясно.
Этого обычно (после некоторого опыта работы в компании) достаточно, чтобы осознанно принимать решения по дизайну своей части системы.
Глупый, умный. Какая разница. Главное чтобы он с клиентами общался, а не я. <:o)
Умный аналитик – глупый разработчик vs. глупый аналитик – умный разработчик