Ну, тут только действовать снизу: выбрать проект, провести там анализ, написать ТЗ, дать разработчикам почувствовать кайф от работы по ТЗ, потом - тестировщикам. Дальше начнет действовать сарафанное радио. :-)
Даже если разработчики/тестировщики привыкли работать без документации, то на конкретном примере они почувствуют, на сколько стало проще, на сколько стало меньше хаоса, перекодинга, и уже от них пойдет волна - "а пусть нам напишу ТЗ".
У меня примерно так и было. Сначала пошли фразы типа "как долго мы тебя ждали" от тестировщиков и ПМов, а потом уже и от разработчиков - "без ТЗ от NN ничего делать не буду".
Потом уже и в головах руководства что-то изменится. Можно к ним потом с метриками прийти. У меня был показательный проект по регистрации. Я просто показала, как увеличилась конверсия при реализации регистрации "по правильному" по сравнению со старой регистрацией "лишь бы как-то работало".
Но это процесс не быстрый, конечно. Не в одночасье все изменится.
Пара примеров в статье есть. Хотелось бы прям всех артефактов от ИИ?
Да, конечно, артефакты от ИИ допиливаются в 100% случаев. Часто она предлагает больше, чем надо, или не в контексте нашей архитектуры. Что-то требует большего тюнинга, что-то меньшего.
По времени: мы еще в процессе. :-) Сейчас же постоянно выходит что-то новое, то LLM, то IDE с агентом.
Но базово мы все быстро развернули: Cursor + MCP Server + настройка интеграции с Confluence и Jira примерно 2 недели. Свой сервер с LLMками - тут мы дольше ждали сам сервак. :-) Как он пришел - за один день все поставили, теперь постоянно скачиваем новые LLMки для тестирования и выбора нужной под конкретные задачи.
К сожалению, показать такие ТЗ не могу, т.к. мы таких систем не разрабатываем. :-)
Я согласна, что пользователь/заказчик ТЗ не напишет. Он напишет бизнес-требования. А системный аналитик либо наложит их на существующую архитектуру (если это доработки системы, новые микросервисы к существующей экосистеме продуктов), либо опишет архитектуру будущего решения (с помощью архитектора, тим-лида разработки), если это новая система.
Разработчик тоже не напишет. Поэтому и нужен системный аналитик.
Если касаться бюджета проекта, то тут нужно балансировать между детальной проработкой ТЗ и сроками предоставления коммерческого предложения. Чем детальнее ТЗ проработано, тем точнее будет оценка бюджета, но на детальную проработку ТЗ требуется большое время, особенно для крупных систем, про которые Вы говорите. Поэтому часто коммерческие предложения делаются на основе прошлого опыта или опыта конкурентов на аналогичных проектах.
Спасибо! Да, статья выстрадана собственным непростым опытом. :-)
Да, все так. Исторически был монолит. Т.к. мы - e-com, то постепенно накручивались на него всякие свистоперделки в виде отдельных сервисов, но ядром всей системы оставался все равно вот этот монолит. Обновление его приводило к полной остановке деятельности всей компании. Стало понятно, что современный рыночный темп такое уже не прощает. Стали распиливать, определяли ключевые функции и данные, которые можно было "отторгнуть" в отдельные микросервисы и через боль/откаты/панику вырезали. Это если очень сильно вкратце. Подумаю насчет отдельной статьи на этот счет, спасибо за идею!
Продуктовая, мы - разработческое подразделение e-com'а.
Тут нам повезло, руководство само осознавало важность и, я бы сказала, неизбежную необходимость, так что поддержало.
Я одновременно и лид аналитиков, и руководитель ключевых проектов. :-) Тяжело. Но опыт показывает, что как таковые руководители проектов при сильном аналитике не нужны. Это, кстати, еще одна холиварная тема для статьи - группы проектов и их составы в ИТ. Тут зависит от того, продуктовая разработка или аутсорс, кто есть из людей и с какими скиллами, как собираются команды проектов (по направлению, по фиче, по доменной области, по клиентам - вариантов масса) и т.д.
Я так понимаю, коллега имеет в виду работу бизнес-аналитика, а в статье идет речь о работе системного аналитика. Именно он описывает то, как система должна реализовывать бизнес-требования. Но да, юзер стори надо поменять на ТЗ, тогда вопросов не будет. :-)
Хорошая статья. Мы методом проб и ошибок тоже пришли к такой же схеме взаимодействия. Груминг - вот как называются наши презентации ТЗ разработчикам и тестировщикам! Буду знать. :-)
Мы еще на такие презентации подключаем продакт оунеров. И вот когда от всех приглашенных получен фидбек и апрув, тогда ТЗ передается в разработку. В идеале еще должны быть дизайн-макеты готовы и представлены на таких грумингах.
Тестировщики, кстати, тоже могут давать вполне себе дельные советы по реализации на таких грумингах.
А изменения в ТЗ мы фиксируем в разделе "Изменения" с обязательным описанием причин изменений. Особенно это актуально для сложных задач.
Хотя я работаю в e-com, но деятельность тоже регулируется некоторыми органами. Поэтому все очень похоже. Советы даны правильные.
Есть еще одна проблема, с которой мы сталкиваемся: изменение интеграционного API у регуляторов. Бывают минорные изменения - это не так страшно, а бывают и существенные (например поля, которые были нулабл, вдруг стали не нулабл, а нам никто об этом не сказал, мы стали получать ошибки - пока разбирались, клиенты страдали). И повлиять на это мы, увы, почти никак не можем.
Да, отчасти Вы правы. Мы слепо доверились маркетингу. :-) Но у нас ситуация, когда у пользователя богатый положительный опыт конкретно в нашем магазине, поэтом мы можем смело доверять анализу его активности и советовать именно то, что выдаст мат модель.
У нас сейчас в компании сложилась такая структура, что менеджеры проекта больше выполняют роль администраторов проекта. Они подключаются на этапе, когда аналитики передают им готовое ТЗ, назначают ресурсы и уже управляют ими.
Спасибо за комментарий! В итоге так и сделала. :-) Выложила статью еще до того, как до конца продумала и проработала ТЗ. В итоге после дополнительных размышлений сделала да, один endpoint. Но статью решила не исправлять.
Это не было задачей данной статьи. Я хотела показать, с чем, с кем и на каких этапах приходится работать системному аналитику, что он получает на вход и что выдает на выходе. Детальная проработка требований - это тема отдельной статьи.
Мы используем похожий подход, но кто у вас в итоге описывает обработку ошибок, способы решения, детали реализации? Аналитики? Вы в статье сказали, что аналитик "не способен проектировать решения на уровне системного архитектора". Я за свой опыт пришла к тому, что аналитик таки должен быть способен на это и еще быть "достаточно технически подкован, чтобы разбираться в сложных программных нюансах". По крайне мере, в общих чертах. В идеале - проконсультировавшись с архитектором. Т.е. в нашем случае аналитик предлагает некое архитектурное решение архитектору, а тот в свою очередь, вносит корректировки при необходимости, затем уже аналитик фиксирует все в документации, которая передается разработчикам.
Согласна, чаще всего именно так и бывает. Самого кассира редко спрашивают, удобно ли ему. Решают за него. :-) Особенно в крупных проектах. Но в небольших, бывают, и спрашивают. Мы вот спрашивали в данном случае. Правда, не самого кассира, а центр обучения кассиров. Ну, почти конечных пользователей. :-)
Но суть статьи в том, что клиент компании - не пользователь системы в данном случае.
Соглашусь частично. Я следую терминологии, определенной Карлом Вигерсом. В его терминологии клиенты - это в том числе и те, кто использует продукт. Т.е. в нашем случае - кассиры. Они же тоже могут и должны влиять на требования к нему, верно? Значит, могут выступать и в роли заказчиков. (Например, им удобнее иметь кнопку внизу справа. Если это не принципиально с точки зрения функциональности, то почему нет?)
Поэтому я все-таки считаю, что Вигерс прав, и пользователи входят в подмножество заказчиков, а не частично с ним пересекается.
Для нас актуализация документации - больной вопрос. Вот думаю над определением триггеров для обновления. Бывают очевидные как в Ваших примерах, а бывают нет. Понимаю, что надо встраивать в жизненный цикл, кое-что уже встроено, но над многим предстоит поработать.
Крайне важный вопрос - как поддерживаете документацию в актуальном состоянии? Кто ее владелец и как он отслеживает изменения, которые нужно отразить в документации?
Ну, тут только действовать снизу: выбрать проект, провести там анализ, написать ТЗ, дать разработчикам почувствовать кайф от работы по ТЗ, потом - тестировщикам. Дальше начнет действовать сарафанное радио. :-)
Даже если разработчики/тестировщики привыкли работать без документации, то на конкретном примере они почувствуют, на сколько стало проще, на сколько стало меньше хаоса, перекодинга, и уже от них пойдет волна - "а пусть нам напишу ТЗ".
У меня примерно так и было. Сначала пошли фразы типа "как долго мы тебя ждали" от тестировщиков и ПМов, а потом уже и от разработчиков - "без ТЗ от NN ничего делать не буду".
Потом уже и в головах руководства что-то изменится. Можно к ним потом с метриками прийти. У меня был показательный проект по регистрации. Я просто показала, как увеличилась конверсия при реализации регистрации "по правильному" по сравнению со старой регистрацией "лишь бы как-то работало".
Но это процесс не быстрый, конечно. Не в одночасье все изменится.
Да, конечно, для чувствительных данных - строго использование LLM, развернутых на нашем локальном сервере.
Пара примеров в статье есть. Хотелось бы прям всех артефактов от ИИ?
Да, конечно, артефакты от ИИ допиливаются в 100% случаев. Часто она предлагает больше, чем надо, или не в контексте нашей архитектуры. Что-то требует большего тюнинга, что-то меньшего.
По времени: мы еще в процессе. :-) Сейчас же постоянно выходит что-то новое, то LLM, то IDE с агентом.
Но базово мы все быстро развернули: Cursor + MCP Server + настройка интеграции с Confluence и Jira примерно 2 недели. Свой сервер с LLMками - тут мы дольше ждали сам сервак. :-) Как он пришел - за один день все поставили, теперь постоянно скачиваем новые LLMки для тестирования и выбора нужной под конкретные задачи.
К сожалению, показать такие ТЗ не могу, т.к. мы таких систем не разрабатываем. :-)
Я согласна, что пользователь/заказчик ТЗ не напишет. Он напишет бизнес-требования. А системный аналитик либо наложит их на существующую архитектуру (если это доработки системы, новые микросервисы к существующей экосистеме продуктов), либо опишет архитектуру будущего решения (с помощью архитектора, тим-лида разработки), если это новая система.
Разработчик тоже не напишет. Поэтому и нужен системный аналитик.
Если касаться бюджета проекта, то тут нужно балансировать между детальной проработкой ТЗ и сроками предоставления коммерческого предложения. Чем детальнее ТЗ проработано, тем точнее будет оценка бюджета, но на детальную проработку ТЗ требуется большое время, особенно для крупных систем, про которые Вы говорите. Поэтому часто коммерческие предложения делаются на основе прошлого опыта или опыта конкурентов на аналогичных проектах.
Но моя статья немного не об этом. :-)
Спасибо! Да, статья выстрадана собственным непростым опытом. :-)
Да, все так. Исторически был монолит. Т.к. мы - e-com, то постепенно накручивались на него всякие свистоперделки в виде отдельных сервисов, но ядром всей системы оставался все равно вот этот монолит. Обновление его приводило к полной остановке деятельности всей компании. Стало понятно, что современный рыночный темп такое уже не прощает. Стали распиливать, определяли ключевые функции и данные, которые можно было "отторгнуть" в отдельные микросервисы и через боль/откаты/панику вырезали. Это если очень сильно вкратце. Подумаю насчет отдельной статьи на этот счет, спасибо за идею!
Продуктовая, мы - разработческое подразделение e-com'а.
Тут нам повезло, руководство само осознавало важность и, я бы сказала, неизбежную необходимость, так что поддержало.
Я одновременно и лид аналитиков, и руководитель ключевых проектов. :-) Тяжело. Но опыт показывает, что как таковые руководители проектов при сильном аналитике не нужны. Это, кстати, еще одна холиварная тема для статьи - группы проектов и их составы в ИТ. Тут зависит от того, продуктовая разработка или аутсорс, кто есть из людей и с какими скиллами, как собираются команды проектов (по направлению, по фиче, по доменной области, по клиентам - вариантов масса) и т.д.
Мне, кстати, стиль изложения понравился: все логично, и технические детали ложатся в целостную картину.
Я так понимаю, коллега имеет в виду работу бизнес-аналитика, а в статье идет речь о работе системного аналитика. Именно он описывает то, как система должна реализовывать бизнес-требования. Но да, юзер стори надо поменять на ТЗ, тогда вопросов не будет. :-)
Хорошая статья. Мы методом проб и ошибок тоже пришли к такой же схеме взаимодействия. Груминг - вот как называются наши презентации ТЗ разработчикам и тестировщикам! Буду знать. :-)
Мы еще на такие презентации подключаем продакт оунеров. И вот когда от всех приглашенных получен фидбек и апрув, тогда ТЗ передается в разработку. В идеале еще должны быть дизайн-макеты готовы и представлены на таких грумингах.
Тестировщики, кстати, тоже могут давать вполне себе дельные советы по реализации на таких грумингах.
А изменения в ТЗ мы фиксируем в разделе "Изменения" с обязательным описанием причин изменений. Особенно это актуально для сложных задач.
Хотя я работаю в e-com, но деятельность тоже регулируется некоторыми органами. Поэтому все очень похоже. Советы даны правильные.
Есть еще одна проблема, с которой мы сталкиваемся: изменение интеграционного API у регуляторов. Бывают минорные изменения - это не так страшно, а бывают и существенные (например поля, которые были нулабл, вдруг стали не нулабл, а нам никто об этом не сказал, мы стали получать ошибки - пока разбирались, клиенты страдали). И повлиять на это мы, увы, почти никак не можем.
Да, отчасти Вы правы. Мы слепо доверились маркетингу. :-)
Но у нас ситуация, когда у пользователя богатый положительный опыт конкретно в нашем магазине, поэтом мы можем смело доверять анализу его активности и советовать именно то, что выдаст мат модель.
Спасибо. :-)
У нас сейчас в компании сложилась такая структура, что менеджеры проекта больше выполняют роль администраторов проекта. Они подключаются на этапе, когда аналитики передают им готовое ТЗ, назначают ресурсы и уже управляют ими.
Спасибо за комментарий! В итоге так и сделала. :-) Выложила статью еще до того, как до конца продумала и проработала ТЗ. В итоге после дополнительных размышлений сделала да, один endpoint. Но статью решила не исправлять.
Согласна полностью. Шикарная статья. Спасибо автору!
Это не было задачей данной статьи. Я хотела показать, с чем, с кем и на каких этапах приходится работать системному аналитику, что он получает на вход и что выдает на выходе. Детальная проработка требований - это тема отдельной статьи.
Мы используем похожий подход, но кто у вас в итоге описывает обработку ошибок, способы решения, детали реализации? Аналитики? Вы в статье сказали, что аналитик "не способен проектировать решения на уровне системного архитектора".
Я за свой опыт пришла к тому, что аналитик таки должен быть способен на это и еще быть "достаточно технически подкован, чтобы разбираться в сложных программных нюансах". По крайне мере, в общих чертах. В идеале - проконсультировавшись с архитектором. Т.е. в нашем случае аналитик предлагает некое архитектурное решение архитектору, а тот в свою очередь, вносит корректировки при необходимости, затем уже аналитик фиксирует все в документации, которая передается разработчикам.
Согласна, чаще всего именно так и бывает. Самого кассира редко спрашивают, удобно ли ему. Решают за него. :-) Особенно в крупных проектах. Но в небольших, бывают, и спрашивают. Мы вот спрашивали в данном случае. Правда, не самого кассира, а центр обучения кассиров. Ну, почти конечных пользователей. :-)
Но суть статьи в том, что клиент компании - не пользователь системы в данном случае.
Соглашусь частично. Я следую терминологии, определенной Карлом Вигерсом. В его терминологии клиенты - это в том числе и те, кто использует продукт. Т.е. в нашем случае - кассиры. Они же тоже могут и должны влиять на требования к нему, верно? Значит, могут выступать и в роли заказчиков. (Например, им удобнее иметь кнопку внизу справа. Если это не принципиально с точки зрения функциональности, то почему нет?)
Поэтому я все-таки считаю, что Вигерс прав, и пользователи входят в подмножество заказчиков, а не частично с ним пересекается.
Спасибо, буду ждать новой статьи.
Для нас актуализация документации - больной вопрос. Вот думаю над определением триггеров для обновления. Бывают очевидные как в Ваших примерах, а бывают нет. Понимаю, что надо встраивать в жизненный цикл, кое-что уже встроено, но над многим предстоит поработать.
Крайне важный вопрос - как поддерживаете документацию в актуальном состоянии? Кто ее владелец и как он отслеживает изменения, которые нужно отразить в документации?