я очень не люблю вот этого расшаркивания "это моё скромное имярека, не претендующее на абсолютную истину" — обычно так пишут неуверенные в себе дети на втором курсе. взрослому человеку и так понятно, что означает текст с рекомендациями, если в нём нет указаний на источники исследований
нахера вот этот унылый рефрен про "это моё мнение и оно может быть неверным"? я что, научную статью пишу?
Представим, что вакансия - это требования к соискателю, а резюме - это реализация данных требований. Вы мне предлагаете просто так переписать сами требования или best-practice по их реализации?
Было бы неплохо, если бы в с самого начала обозначили, что ваша ЦА - аналитики до 3 лет опыта, которые ещё не умеют позиционировать себя на рынке и которым особо нечего написать в резюме.
Да, в основном сценарий применения рекомендаций у меня — именно относительно начинающих. Но и даже у продолжающих в 70% случаев в тексте резюме нет достижений и это характеризует состояние умов-отрасли.
У каждой компании есть свой конкретный запрос: кому нужно апи для интеграций расписывать, кому микросервисы пилить, кому бизнес-требования собрать, кому связи нормально выстроить, кому проект из болота "все стейхолдеры хотят разного" вывести, кому следование локальным правилам, кому ещё что.
Так, и как это связано с текстом резюме, а точнее, моими рекомендациями по его форме и подаче?
Что, системным аналитикам в интеграции нужно по-другому резюме ОФОРМЛЯТЬ? Что-то я сомневаюсь.
Противоречие в том, что вы советуете Субъект-Действие-Объект в рамках подхода инструкции/мануала/требований и в то же время строите художественный текст на риторических приёмах "читатель сам себе ответит на вопрос".
Так это же разные классы текстов всё-таки.
Набор рекомендаций != точный алгоритм, процедура, требования и т.д.
Как минимум по характеру модальности, рискам, влиянию, ответственности и т.д.
Освойте язык результатов, важных для команды, бизнеса нанимателя, бизнеса клиента.
Совет неплохой, но вы сами же ему во всех примерах, кроме первого, не следуете: кому выгодно, как измерялось сокращение работ, что такое доверительные и как это измерить?.
» Мы же не говорим, что надо обязательно указывать и единицы измерения результата и количество и потребителя и механику измерения. Начните хотя бы с малого, переведите своё сознание и фразы с потокового мышления на результативное, это уже полдела. Если сможете как-то качественно и количественно отнестись к результатам —вообще супер.
Если нанимателю интересно, как измерялось, кому выгодно и т.д. — это уже повод позвать на интервью, поговорить, правда?
Да, статью писал аналитик, который благодаря таким подходам к описанию опыта, в том числе, смог получить интересную работу сразу руководителя отдела в своё время, а сейчас помогает найти работу другим.
Есть советы получше? Делитесь. Я пока вообще никаких советов для СА про резюме не видел — ни хороших, ни плохих, никаких.
"принципиально изменило работу с требованиями и проектирование системы."
"Реализацию каждой user story проектируют отдельно. Часто это делает разработчик перед реализацией, и лишь для сложных user story проводят дизайн-сессии. Впрочем, тут есть много деталей, которые присутствуют в процессе неявно.
В частности, для решения о включении в спринт должно быть не только понятно, что user story реализуема, — важна примерная оценка трудоемкости реализации. А это означает, что общее представление о дизайне уже должно быть, и для этого еще на этапе подготовки бэклога к планированию привлекается кто-то из опытных разработчиков"
Если проектируется именно реализация отдельных историй, то в какой момент проектируется архитектура?
Кстати, если мы делаем компьютерные игры определённого жанра, то БТ компании, которая сама эти игры разрабатывает, продаёт и эксплуатирует, могут быть довольно простыми и устойчивыми, их не надо в каждом проекте заново изобретать:
Организация должна разрабатывать онлайн-игры в жанре X для рынка Y
Организация должна продавать эти игры
С применением каналов оплаты KO1-KON
C применением валют V2-VN
Организация должна позволять клиентам играть в игры с использованием языков интерфейса Y1-YN
Организация должна предоставлять клиентам возможность получать качество обслуживания при игре в игры на уровне, не хуже чем конкуренты Z1, Z2 и Z3
Организация должна получать, хранить и предоставлять ответственным сотрудниками информацию о фактах продаж, подписок, отказов
Организация должна предоставлять клиентам возможность обратиться с жалобой
Организация должна анализировать поток обращений клиентов
Организация должна реагировать на обращения согласно политике CP1
мне кажется можно сказать проще — то заказчик должен сформулировать собственно ЗАКАЗ, т.е. что именно он хочет закупить
и поскольку это не закупка партии туалетной бумаги или готового холодильного оборудования, а создание уникального софта со своими свойствами, эти свойства софта надо продумать, а точнее — спроектировать
и да, такой ЗАКАЗ сформировать заказчику будет непросто, каким бы брифом подрядчик не прикрывался, поэтому нужна совместная работа по подготовке ЗАКАЗа
я вот не понимаю вот этого повсеместного стремления усложнять жизнь и работать именно с ТЗ на АС
судя по тексту автора, они в основном делают мобильные приложения, чистый софт
они не «строят» автоматизированную систему — АС на самом деле нельзя просто разработать и потом развернуть и внедрить — её можно только именно построить из людей, оборудования, процессов И софта
так что если ссылаться, то ссылаться на ГОСТ 19, ISO 29148 в части Software Requirements Specification
в ЕСПД я навскидку не вижу никаких указаний на то, кто разрабатывает ТЗ на софт, но из общей логики советской реальности это вообще делает 3-е лицо — специализированное НИИ
Завод заказывает НИР и ОКР НИИ
НИИ делает обследования и пишет ТЗ
КБ или производственная фирма разрабатывает софт
понятно, что эта модель к современной коммерческой разработке почти никак (к сожалению) не применима, института независимых проектировщиков в мелкомасштабной разработке просто не существует, а в интеграторах шаги 2 и 3 объединены в один с понятным конфликтом интересов
Заказчики сидят на VC.ru, а не тут. Тут вы ломитесь в открытую дверь.
«Бизнес-требования... ТЗ». Бизнес-требования и ТЗ — это очень разные вещи.
Бизнес-требования — это требования владельцев, бизнес-архитекторов, регуляторов, законов и т.д. к организации и её организационным единицам — что они должны делать, что не должны и с каким качеством.
Примеры:
«Организация должна продавать товары с применением электронных каналов продаж» «Организация должна информировать клиента об условиях продажи» «Организация должна мотивировать клиента на покупку конкретного товара» и т.д.
а ТЗ содержит уже ЗАДАНИЕ на разработку и/или проектирование/построение технического объекта (что является совсем другим предметом, чем организация) и содержит 2 части: 1. Требования к свойствам предмета поставки 2. Требования к порядку работ и процедурам разработки, сдачи, внедрения, сопровождения
Если вы поставляете морозильные камеры в ресторан, то конечно вам надо хоть немного разобраться в бизнесе и понять, зачем камеры, как они будут применяться, как заказчик измерит, что камеры работают хорошо. Но в ТЗ на закупку камер будет написано другое — а именно, характеристики камер, а не бизнеса.
Так что в догонку к предыдущим комментаторам — в разработке ПО можно даже и без ТЗ, но всё равно кто-то должен поставить бизнес-задачу в терминах измеримой цели и ограничений (железного треугольника), и само собой не в виде «цель проекта: внедрить CRM» :)
Поэтому я бы настаивал на:
Бизнес-требованиях (1 страничка) — что должен делать бизнес в интересующей нас области (capabilities), с каким качеством, с какими ограничениями (показатели процесса)
Концепция решения (3 странички) — что именно мы хотим сделать, как в целом будет устроена конструкция (бриф-архитектура), каким качеством, какими ключевыми свойствами (перечень user stories), с какими ограничениями (показатели ИТ-системы)
Бизнес-обоснование (1 страничка) — как именно это решение (2) приведёт к реализации бизнес-требованй, как именно будут окупаться вложения, какие вложения в каком графике понадобятся. Подрядчик может этого документа не видеть, но именно он определяет допустимые границы бюджета.
Концепция проекта (project) (1 страничка) — из каких очередей будет состоять разработка, какие свойства будут входить в каждую из них — например, в формате story map
Вот это всё так или иначе нужно, а ограничивать софт именно ТЗ стоит тогда, когда предельно точно известно, что именно нужно сделать и как оно должно работать — что требует детального проектирования, что увеличивает предпроект на 2-3 месяца и в общем случае не выгодно заказчику, да и подрядчику, т.к. в коммерческой разработке попытка угадать правильную работу фич в режиме Big Design Upfront ни к чему хорошему не приводит.
я очень не люблю вот этого расшаркивания "это моё скромное имярека, не претендующее на абсолютную истину" — обычно так пишут неуверенные в себе дети на втором курсе. взрослому человеку и так понятно, что означает текст с рекомендациями, если в нём нет указаний на источники исследований
нахера вот этот унылый рефрен про "это моё мнение и оно может быть неверным"? я что, научную статью пишу?
Ничего не понял в вашей метафоре.
Да, в основном сценарий применения рекомендаций у меня — именно относительно начинающих. Но и даже у продолжающих в 70% случаев в тексте резюме нет достижений и это характеризует состояние умов-отрасли.
Так, и как это связано с текстом резюме, а точнее, моими рекомендациями по его форме и подаче?
Что, системным аналитикам в интеграции нужно по-другому резюме ОФОРМЛЯТЬ? Что-то я сомневаюсь.
Так это же разные классы текстов всё-таки.
Набор рекомендаций != точный алгоритм, процедура, требования и т.д.
Как минимум по характеру модальности, рискам, влиянию, ответственности и т.д.
в чём именно противоречие? вы понимаете разницу между тем, что такое эффективное резюме и что такое статья с рекомендациями?
«
Совет неплохой, но вы сами же ему во всех примерах, кроме первого, не следуете: кому выгодно, как измерялось сокращение работ, что такое доверительные и как это измерить?.
»
Мы же не говорим, что надо обязательно указывать и единицы измерения результата и количество и потребителя и механику измерения. Начните хотя бы с малого, переведите своё сознание и фразы с потокового мышления на результативное, это уже полдела. Если сможете как-то качественно и количественно отнестись к результатам —вообще супер.
Если нанимателю интересно, как измерялось, кому выгодно и т.д. — это уже повод позвать на интервью, поговорить, правда?
Да, статью писал аналитик, который благодаря таким подходам к описанию опыта, в том числе, смог получить интересную работу сразу руководителя отдела в своё время, а сейчас помогает найти работу другим.
Есть советы получше? Делитесь. Я пока вообще никаких советов для СА про резюме не видел — ни хороших, ни плохих, никаких.
а что насчёт Domain Storytelling? добавляет ли он что полезное к ES?
Если проектируется именно реализация отдельных историй, то в какой момент проектируется архитектура?
ну т.е. с заводом получается в цепочке целых 4 участника?
по крайней мере в ней указано, что она про софт, а не про ПАК, АС, ИС, ГАС и прочих гавриков
Кстати, если мы делаем компьютерные игры определённого жанра, то БТ компании, которая сама эти игры разрабатывает, продаёт и эксплуатирует, могут быть довольно простыми и устойчивыми, их не надо в каждом проекте заново изобретать:
Организация должна разрабатывать онлайн-игры в жанре X для рынка Y
Организация должна продавать эти игры
С применением каналов оплаты KO1-KON
C применением валют V2-VN
Организация должна позволять клиентам играть в игры с использованием языков интерфейса Y1-YN
Организация должна предоставлять клиентам возможность получать качество обслуживания при игре в игры на уровне, не хуже чем конкуренты Z1, Z2 и Z3
Организация должна получать, хранить и предоставлять ответственным сотрудниками информацию о фактах продаж, подписок, отказов
Организация должна предоставлять клиентам возможность обратиться с жалобой
Организация должна анализировать поток обращений клиентов
Организация должна реагировать на обращения согласно политике CP1
...
и т.д.
мне кажется можно сказать проще — то заказчик должен сформулировать собственно ЗАКАЗ, т.е. что именно он хочет закупить
и поскольку это не закупка партии туалетной бумаги или готового холодильного оборудования, а создание уникального софта со своими свойствами, эти свойства софта надо продумать, а точнее — спроектировать
и да, такой ЗАКАЗ сформировать заказчику будет непросто, каким бы брифом подрядчик не прикрывался, поэтому нужна совместная работа по подготовке ЗАКАЗа
если почитать телеграм автора, он вообще в геймдеве работает
так что непонятно, зачем вы сюда всю эту галиматью с госзаказами, ФЗ, ХЗ, судами, военными ГОСТами и прикрытием жопы чиновника тащите
я вот не понимаю вот этого повсеместного стремления усложнять жизнь и работать именно с ТЗ на АС
судя по тексту автора, они в основном делают мобильные приложения, чистый софт
они не «строят» автоматизированную систему — АС на самом деле нельзя просто разработать и потом развернуть и внедрить — её можно только именно построить из людей, оборудования, процессов И софта
так что если ссылаться, то ссылаться на ГОСТ 19, ISO 29148 в части Software Requirements Specification
в ЕСПД я навскидку не вижу никаких указаний на то, кто разрабатывает ТЗ на софт, но из общей логики советской реальности это вообще делает 3-е лицо — специализированное НИИ
Завод заказывает НИР и ОКР НИИ
НИИ делает обследования и пишет ТЗ
КБ или производственная фирма разрабатывает софт
понятно, что эта модель к современной коммерческой разработке почти никак (к сожалению) не применима, института независимых проектировщиков в мелкомасштабной разработке просто не существует, а в интеграторах шаги 2 и 3 объединены в один с понятным конфликтом интересов
а по IEEE 830 требования к софту разрабатываются обеими сторонами в сотрудничестве
Заказчики сидят на VC.ru, а не тут. Тут вы ломитесь в открытую дверь.
«Бизнес-требования... ТЗ». Бизнес-требования и ТЗ — это очень разные вещи.
Бизнес-требования — это требования владельцев, бизнес-архитекторов, регуляторов, законов и т.д. к организации и её организационным единицам — что они должны делать, что не должны и с каким качеством.
Примеры:
«Организация должна продавать товары с применением электронных каналов продаж»
«Организация должна информировать клиента об условиях продажи»
«Организация должна мотивировать клиента на покупку конкретного товара»
и т.д.
а ТЗ содержит уже ЗАДАНИЕ на разработку и/или проектирование/построение технического объекта (что является совсем другим предметом, чем организация) и содержит 2 части:
1. Требования к свойствам предмета поставки
2. Требования к порядку работ и процедурам разработки, сдачи, внедрения, сопровождения
Если вы поставляете морозильные камеры в ресторан, то конечно вам надо хоть немного разобраться в бизнесе и понять, зачем камеры, как они будут применяться, как заказчик измерит, что камеры работают хорошо. Но в ТЗ на закупку камер будет написано другое — а именно, характеристики камер, а не бизнеса.
Так что в догонку к предыдущим комментаторам — в разработке ПО можно даже и без ТЗ, но всё равно кто-то должен поставить бизнес-задачу в терминах измеримой цели и ограничений (железного треугольника), и само собой не в виде «цель проекта: внедрить CRM» :)
Поэтому я бы настаивал на:
Бизнес-требованиях (1 страничка) — что должен делать бизнес в интересующей нас области (capabilities), с каким качеством, с какими ограничениями (показатели процесса)
Концепция решения (3 странички) — что именно мы хотим сделать, как в целом будет устроена конструкция (бриф-архитектура), каким качеством, какими ключевыми свойствами (перечень user stories), с какими ограничениями (показатели ИТ-системы)
Бизнес-обоснование (1 страничка) — как именно это решение (2) приведёт к реализации бизнес-требованй, как именно будут окупаться вложения, какие вложения в каком графике понадобятся. Подрядчик может этого документа не видеть, но именно он определяет допустимые границы бюджета.
Концепция проекта (project) (1 страничка) — из каких очередей будет состоять разработка, какие свойства будут входить в каждую из них — например, в формате story map
Вот это всё так или иначе нужно, а ограничивать софт именно ТЗ стоит тогда, когда предельно точно известно, что именно нужно сделать и как оно должно работать — что требует детального проектирования, что увеличивает предпроект на 2-3 месяца и в общем случае не выгодно заказчику, да и подрядчику, т.к. в коммерческой разработке попытка угадать правильную работу фич в режиме Big Design Upfront ни к чему хорошему не приводит.
комментатор намекал на технологические процессы
https://ru.wikipedia.org/wiki/Технологический_процесс
https://martinfowler.com/books/ap.html