Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 7
Очень крутая статья, спасибо! Жаль, что на Хабре не очень часто встретишь что-то годное по BA/SA.
Можно несколько вопросов?
Я правильно понял, что вы постепенно переходили от монолита к микросервисам? Если да, было бы здорово почитать про этот нелёгких процесс подробнее.
Это была продуктовая или аутсорсная работа?
Как руководство отнеслось к (довольно крупному, как мне кажется) изменению внутренних процессов? Или оно само выступало инициатором?
Каково вам совмещать обязанности/работу РП и аналитика? Или вы лид и в ваши обязанности входит и управление проектом?
Спасибо! Да, статья выстрадана собственным непростым опытом. :-)
Да, все так. Исторически был монолит. Т.к. мы - e-com, то постепенно накручивались на него всякие свистоперделки в виде отдельных сервисов, но ядром всей системы оставался все равно вот этот монолит. Обновление его приводило к полной остановке деятельности всей компании. Стало понятно, что современный рыночный темп такое уже не прощает. Стали распиливать, определяли ключевые функции и данные, которые можно было "отторгнуть" в отдельные микросервисы и через боль/откаты/панику вырезали. Это если очень сильно вкратце. Подумаю насчет отдельной статьи на этот счет, спасибо за идею!
Продуктовая, мы - разработческое подразделение e-com'а.
Тут нам повезло, руководство само осознавало важность и, я бы сказала, неизбежную необходимость, так что поддержало.
Я одновременно и лид аналитиков, и руководитель ключевых проектов. :-) Тяжело. Но опыт показывает, что как таковые руководители проектов при сильном аналитике не нужны. Это, кстати, еще одна холиварная тема для статьи - группы проектов и их составы в ИТ. Тут зависит от того, продуктовая разработка или аутсорс, кто есть из людей и с какими скиллами, как собираются команды проектов (по направлению, по фиче, по доменной области, по клиентам - вариантов масса) и т.д.
Можете показать хорошие полные ТЗ на крупные системы, типа СЭД, CRM, ГИС и т.п.? Можно обезличенные. По моим убеждениям пользователь \ заказчик никогда не напишет хорошее ТЗ на сложную систему, но от него это требуют и получается фикция. Даже если ТЗ пишет не он, а только подписывает.
Если разработчик делает новую систему, то и он вряд ли напишет. А для тиражируемых (слегка дорабатываемых) систем ТЗ особо не требуется. Хорошие ТЗ на небольшие доработки - это возможно.
Минималистическое ТЗ - обычно выгодно разработчику (при этом заказчик наивно полагает, что "будет как нужно", ведь разработчик уверено заявляет, что профи в этом вопросе), чтобы "зацепив на крючок" заказчика далее выбивать новый бюджет на доработки. А также: закрытость ТЗ, проектных материалов и т.п. Если работа (система) делается за счет бюджета, то это все должно быть публично и пере используемо. Это как минимум позволило бы сократить проектные риски.
К сожалению, показать такие ТЗ не могу, т.к. мы таких систем не разрабатываем. :-)
Я согласна, что пользователь/заказчик ТЗ не напишет. Он напишет бизнес-требования. А системный аналитик либо наложит их на существующую архитектуру (если это доработки системы, новые микросервисы к существующей экосистеме продуктов), либо опишет архитектуру будущего решения (с помощью архитектора, тим-лида разработки), если это новая система.
Разработчик тоже не напишет. Поэтому и нужен системный аналитик.
Если касаться бюджета проекта, то тут нужно балансировать между детальной проработкой ТЗ и сроками предоставления коммерческого предложения. Чем детальнее ТЗ проработано, тем точнее будет оценка бюджета, но на детальную проработку ТЗ требуется большое время, особенно для крупных систем, про которые Вы говорите. Поэтому часто коммерческие предложения делаются на основе прошлого опыта или опыта конкурентов на аналогичных проектах.
Но моя статья немного не об этом. :-)
Да это же не мем, это моя жизнь.
Как быть, если на проекте полный хаос и все в голове одного-двух людей, а руковдство особо не парится над введением процессов, документации и артефактов.
Как можно им доказать, что это нужно и важно т.к. я чувствую к чему все идет...
Можете накинуть идей каких то?
Ну, тут только действовать снизу: выбрать проект, провести там анализ, написать ТЗ, дать разработчикам почувствовать кайф от работы по ТЗ, потом - тестировщикам. Дальше начнет действовать сарафанное радио. :-)
Даже если разработчики/тестировщики привыкли работать без документации, то на конкретном примере они почувствуют, на сколько стало проще, на сколько стало меньше хаоса, перекодинга, и уже от них пойдет волна - "а пусть нам напишу ТЗ".
У меня примерно так и было. Сначала пошли фразы типа "как долго мы тебя ждали" от тестировщиков и ПМов, а потом уже и от разработчиков - "без ТЗ от NN ничего делать не буду".
Потом уже и в головах руководства что-то изменится. Можно к ним потом с метриками прийти. У меня был показательный проект по регистрации. Я просто показала, как увеличилась конверсия при реализации регистрации "по правильному" по сравнению со старой регистрацией "лишь бы как-то работало".
Но это процесс не быстрый, конечно. Не в одночасье все изменится.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Когда ТЗ перестаёт быть фикцией: практический путь к отделу системного анализа