Да, вы правы, именно для этого, просто я ожидала отклики по конкретному решению, а не по обоснованности той цели, для достижения которой я решение предлагаю :)
К сожалению, наличие большого опыта и преодолённый путь от рядового инженера – не гарантия, что человек в состоянии отвечать за свои слова. Так же как то, что сотрудник – вчерашний студент не свидетельство его безответственности и неумения общаться с более опытным коллегами.
Определите смотрю в Википедии: комплекс неспециализированных, важных для карьеры надпрофессиональных навыков, которые отвечают за успешное участие в рабочем процессе, высокую производительность и являются сквозными, то есть не связаны с конкретной предметной областью.
Ну послушайте, я ведь не навязываю своего мнения, это не пост "я считаю, что в школьное образование непременно нужно внедрить проектное мышление", я лишь предлагаю вариант его тренировки для заинтересованных родителей. Если вы таким не являетесь, вы просто не целевая аудитория этого поста, вот и всё.
Это как с кружками – кто-то ребёнка загружает по полной, кто-то "оставляет детство" – любая позиция имеет место быть, и не нам с вами оценивать решение других родителей.
Но я лишь хочу напомнить, что мы живём в конкурентном мире, и я за то, чтобы дать ребенку хорошие стартовые условия в том числе и через такое развитие, но опять же это моё личное мнение.
Отнюдь, если пользоваться вашим словосочетанием, "вчерашний студент" по документам тоже специалист, здесь я говорю о расстановке приоритетов у нанимающей компании и в качестве примера привожу это сопоставление "сильный специалист – гибкие навыки"
Софт скиллс – это такой грубый, и, пожалуй, неудачный пример (ведь глупо утверждать, что во времена вашей молодости этого навыка не требовалось). Своим комментарием я хотела сказать, что современные менеджеры именно такие, какие нужны, чтобы решать задачи современных проектов. По крайней мере, если компания нанимает вчерашнего студента на свой проект, она, вероятно, ожидает, что этот студент даст проекту то, что бывший рядовой инженер, прошедший все стали производства, дать не сможет. А ещё можно посмотреть на это с другой стороны: студент может быть просто дешевле, чем человек с бОльшим опытом.
Просто акценты сместились и проекты стали другими: раньше требовалось быть сильным специалистом в сфере, которую возглавляешь, а сейчас – ну не знаю, уметь договариваться (те же софт скиллс, о которых сегодня все вокруг говорят, а раньше как будто не задумывались), быть "на волне" и разбираться в трендах (кто бы мог подумать тогда, что популярным станет проект, где люди танцуют на камеру и выставляют это видео в сеть) и тому подобное.
Но вы же играете с детьми в те же настольные игры? Читаете сказки и обсуждаете их с ребёнком? Это та же игра, то же чтение, просто обсуждение более организованное
Круто, что есть такая школа, но жаль, что на Хабре об этом написали только сегодня — после прочтения информации, что «приём работ закроется между 15 и 31 января — как только наберётся достаточное количество претендентов с хорошо выполненным заданием» (с сайта Яндекс Академии), энтузиазма убавляется (т.е. приём работ ведётся уже неделю, и может закрыться в любой момент до 31 января)
Что касается проектов, в которых работаю я, то в части ведения требований в джире основная задача, чтобы описание требования было полное и понятное разработчику — будь то ссылка на ТЗ (или пункт в нём) или описание непосредственно в задаче (на разных проектах это происходит по-разному).
Задами должны быть покрыты все требования. Соблюдены связи родительское-дочернее требование. Если разработчику требуется разъяснение по задаче, он должен понимать, у кого он может их получить, соответственно, задача, где возник вопрос, ставится на этого человека. В каких-то случаях получение разъяснений через общение (задача ни на кого не переназначается тогда), но окончательное решение должно быть кем-то обязательно зафиксировано.
Jira требует регистрации в ней пользователя (например, бизнес заказчик не имеет к ней доступа, ему это и не нужно), т.е. её содержимое доступно не всем, к тому же она стоит денег и явно не подходит под описание «простой способ» :)
Но и, конечно, преимуществ в ней огромное множество. Думаю, тут нужно ориентироваться на собственный комфорт и возможности. Первоначальные требования я собираю вот в такой документ (который доступен и заказчику тоже), а уже полноценные требования можно формировать в задачах в Jira (ну либо в отдельном ТЗ, на пункты которого можно ссылаться в задачах).
В моём случае путаницы не вызывает, т.к. задачи использовать конкретное изменение за какую-то дату (из конкретной версии требования) не стояло никогда.
Простите, а вы вот это с радиобаттанами и базой данных прямо в юзкейсе описываете?
Грешила этим раньше, потом пришло понимание, что это плохо. После этого начала делить все требования на типы (в пользовательском сценарии — только работа пользователя, и т.д.).
Спасибо:)
Сергей, а приводить примеры — прям там же, в тексте описания?
А системные сценарии как вписываются? Ну, например, в зависимости от того, какой радиобаттон выбрал пользователь, мы обращаемся или в БД, или отправляем запрос в стороннюю систему, это будет прописано прямо в самом сценарии? Или здесь только пользовательские сценарии?
Если честно, впервые прочитала о gherkin из вашего комментария. Выглядит круто, но при первом обращении смущает, как будут при таком оформлении выглядеть альтернативные сценарии (если таких накопится достаточно много). При оформлении в формате юзкейсов к каждому шагу основного сценария можно расписать альтернативный сценарий(ии), и выглядит это всё достаточно гармонично и легко читается.
Хотя, как мне кажется, многое зависит здесь от привычки и особенностей восприятия каждого. В общем, надо пробовать:) За наводку спасибо — поинтересуюсь у разработчиков о том, как им такой формат оформления.
Что касается чтения клиентами, то «недостаточно серьёзно» — распространённая проблема, и, думаю, дело здесь не только в том, как оформлены требования (хотя это, конечно, тоже имеет существенное значение).
Для начала нужно убедиться, что писателя 1.есть понимание, что документ с требованиями в рамках описания того, «как это должно работать», может решать разные задачи и давать ответы на разные вопросы — в зависимости от того, какие инструменты использовать; 2. есть понимание, какую задачу должен выполнять конкретный описываемый документ; 3. есть понимание, какой инструмент поможет справится с этой задачей качественнее. А далее — учиться применять нужный инструмент, оттачивать это умение.
Но понимание не приходит из ниоткуда — либо это опыт, либо информация извне. Если речь идёт о начинающих бизнес аналитиках (хотя я всё-таки склоняюсь, что в данном контексте речь идёт о системных аналитиках), то значит нужно разговаривать. Нужно заявлять о том, что вам нужно, и в каком виде хотелось бы это получить. Это моё мнение. Я в своей работе сталкиваюсь с обратными явлениями: время от времени пытаюсь получить фидбек от разработчиков по тому, что и как им комфортнее усваивать информацию, но получить какие-то внятные пожелания не всегда удаётся к сожалению)
Confluence — это удобно, но когда требуется официальное согласование сторон, отметки о согласовании проще собирать в документе. Но опять-таки, всё зависит от конкретных потребностей и задач.
Здорово описан опыт! После чтения статьи осваивать новые сферы будет морально чу-точку не так страшно :)
Да, вы правы, именно для этого, просто я ожидала отклики по конкретному решению, а не по обоснованности той цели, для достижения которой я решение предлагаю :)
К сожалению, наличие большого опыта и преодолённый путь от рядового инженера – не гарантия, что человек в состоянии отвечать за свои слова. Так же как то, что сотрудник – вчерашний студент не свидетельство его безответственности и неумения общаться с более опытным коллегами.
Определите смотрю в Википедии: комплекс неспециализированных, важных для карьеры надпрофессиональных навыков, которые отвечают за успешное участие в рабочем процессе, высокую производительность и являются сквозными, то есть не связаны с конкретной предметной областью.
Ну послушайте, я ведь не навязываю своего мнения, это не пост "я считаю, что в школьное образование непременно нужно внедрить проектное мышление", я лишь предлагаю вариант его тренировки для заинтересованных родителей. Если вы таким не являетесь, вы просто не целевая аудитория этого поста, вот и всё.
Это как с кружками – кто-то ребёнка загружает по полной, кто-то "оставляет детство" – любая позиция имеет место быть, и не нам с вами оценивать решение других родителей.
Но я лишь хочу напомнить, что мы живём в конкурентном мире, и я за то, чтобы дать ребенку хорошие стартовые условия в том числе и через такое развитие, но опять же это моё личное мнение.
Отнюдь, если пользоваться вашим словосочетанием, "вчерашний студент" по документам тоже специалист, здесь я говорю о расстановке приоритетов у нанимающей компании и в качестве примера привожу это сопоставление "сильный специалист – гибкие навыки"
Но ведь вы понимаете, что отсутствие определения не равнозначно отсутствию явления так такового
Просто акценты сместились и проекты стали другими: раньше требовалось быть сильным специалистом в сфере, которую возглавляешь, а сейчас – ну не знаю, уметь договариваться (те же софт скиллс, о которых сегодня все вокруг говорят, а раньше как будто не задумывались), быть "на волне" и разбираться в трендах (кто бы мог подумать тогда, что популярным станет проект, где люди танцуют на камеру и выставляют это видео в сеть) и тому подобное.
Но вы же играете с детьми в те же настольные игры? Читаете сказки и обсуждаете их с ребёнком? Это та же игра, то же чтение, просто обсуждение более организованное
Что касается проектов, в которых работаю я, то в части ведения требований в джире основная задача, чтобы описание требования было полное и понятное разработчику — будь то ссылка на ТЗ (или пункт в нём) или описание непосредственно в задаче (на разных проектах это происходит по-разному).
Задами должны быть покрыты все требования. Соблюдены связи родительское-дочернее требование. Если разработчику требуется разъяснение по задаче, он должен понимать, у кого он может их получить, соответственно, задача, где возник вопрос, ставится на этого человека. В каких-то случаях получение разъяснений через общение (задача ни на кого не переназначается тогда), но окончательное решение должно быть кем-то обязательно зафиксировано.
Но и, конечно, преимуществ в ней огромное множество. Думаю, тут нужно ориентироваться на собственный комфорт и возможности. Первоначальные требования я собираю вот в такой документ (который доступен и заказчику тоже), а уже полноценные требования можно формировать в задачах в Jira (ну либо в отдельном ТЗ, на пункты которого можно ссылаться в задачах).
В моём случае путаницы не вызывает, т.к. задачи использовать конкретное изменение за какую-то дату (из конкретной версии требования) не стояло никогда.
Грешила этим раньше, потом пришло понимание, что это плохо. После этого начала делить все требования на типы (в пользовательском сценарии — только работа пользователя, и т.д.).
Спасибо:)
А системные сценарии как вписываются? Ну, например, в зависимости от того, какой радиобаттон выбрал пользователь, мы обращаемся или в БД, или отправляем запрос в стороннюю систему, это будет прописано прямо в самом сценарии? Или здесь только пользовательские сценарии?
Хотя, как мне кажется, многое зависит здесь от привычки и особенностей восприятия каждого. В общем, надо пробовать:) За наводку спасибо — поинтересуюсь у разработчиков о том, как им такой формат оформления.
Что касается чтения клиентами, то «недостаточно серьёзно» — распространённая проблема, и, думаю, дело здесь не только в том, как оформлены требования (хотя это, конечно, тоже имеет существенное значение).
Для начала нужно убедиться, что писателя 1.есть понимание, что документ с требованиями в рамках описания того, «как это должно работать», может решать разные задачи и давать ответы на разные вопросы — в зависимости от того, какие инструменты использовать; 2. есть понимание, какую задачу должен выполнять конкретный описываемый документ; 3. есть понимание, какой инструмент поможет справится с этой задачей качественнее. А далее — учиться применять нужный инструмент, оттачивать это умение.
Но понимание не приходит из ниоткуда — либо это опыт, либо информация извне. Если речь идёт о начинающих бизнес аналитиках (хотя я всё-таки склоняюсь, что в данном контексте речь идёт о системных аналитиках), то значит нужно разговаривать. Нужно заявлять о том, что вам нужно, и в каком виде хотелось бы это получить. Это моё мнение. Я в своей работе сталкиваюсь с обратными явлениями: время от времени пытаюсь получить фидбек от разработчиков по тому, что и как им комфортнее усваивать информацию, но получить какие-то внятные пожелания не всегда удаётся к сожалению)