DK
Вы про сладкое, а я про тёплое. Если ваш разработчик/тестировщик/архитектор/пм не поймёт что и зачем надо сделать, то риски будут намного выше.
А мне всё надо 😉
Size: a a a
2020 August 06
ОИ
Сперва ориентируетесь на людей, надо что-то добавить - добавляете, но как - это уже другой вопрос.
ОИ
Можно делить ТЗ и ОПЗ
ОИ
Можно для каждого человека оформлять сноски. Можно разираться брифингами.
ОИ
А мне всё надо 😉
Самый главная задача - это формирования в рамках проекта общего настроя, когда люди понимают цели проекта, понимают шаги его достижения, достаточно подробно понимают как он должен работать. Обычно это работа пм"а сформировать правильную последовательность работ, освободить команду от прочей нагрузки, сконцентрировать процесс. Но они этого не умают. Я ни одного не видел. Хотя, может один и был...
И когда вы работаете аналитиком, вы начинаете просчитывать слабые звенья в цепи, из этого строите тактику формирования требований.
И когда вы работаете аналитиком, вы начинаете просчитывать слабые звенья в цепи, из этого строите тактику формирования требований.
ОИ
И "стягиваете" людей брифингами, общением с заказчиком, консультациями, общими чатами, летучками.
ОИ
Но если у вас есть коллега/и, который/ые пришли тут работу работать, то всё это бесполезно. Им надо отработать на 3 и пойти домой. И для таких есть свой подход.
Для заинтересованных - свой.
Для учёных, систематизаторов, испытателей - свой.
Для заинтересованных - свой.
Для учёных, систематизаторов, испытателей - свой.
ОИ
Простой пример. Если у вас разработчик - дятел, то фигачте подробные требования для тестирования, а разработчику оставьте его велосипед.
ОИ
А если сильный разработчик и слабый тестировщик, то формируйте подробные требования.
ОИ
Иногда оба дятлы. Тогда приходится зализать в код и самому тестировать.
ОИ
Иногда вы - дятел. Тогда вы ничего поделать не сможете.
ОИ
ВСЯ разработка - это про людей и их желания на самом деле. Всё остальное - инструмент.
ОИ
Стандартная тема: "Сделать сэндвич с вареньем и арахисовым маслом"
https://youtu.be/7fJ42lfCUXg?t=782
https://youtu.be/7fJ42lfCUXg?t=782
ОИ
По хорошему, надо быть на одной волне.
DK
Олег, а вам встречались какие-то методики? Вы мне рассказываете очень общие концепции, и это тоже неплохо, но такой опыт у меня имеется и выводы схожие, а вот систематизированного опыта, оформленного в методики - не хватает.
F
Не только подтверждение работ. Как на счет фиксации намерений? Как на счет общего понимания задач? В одном из исследований показали, что 60% всех проблем с ПО вызвано некорректным пониманием требований. Как быть если требования не зафиксированы?
Сбор требований и после их фиксация. Намерение это работа этапа инициации.
F
Состав отчетной документации - да. А остальное - как получится. Тем более помимо перечня этих доков нужно подбирать инструменты. РП не занимается подбором инструментов для каждой практики. Для автогенерации доков, для организации тесткейсов, для управления требованиями. Этим занимаются лиды направлений. Менеджер по качеству, тимлид, и т.д.
Да, он согласует выходные данные сервисов. И объем работ отражающийся в них. Этотего ресурсы. Если аутсорс, может да, вы выставляете ценц человека с учетом всех инструментов. А если нет?
ОИ
Олег, а вам встречались какие-то методики? Вы мне рассказываете очень общие концепции, и это тоже неплохо, но такой опыт у меня имеется и выводы схожие, а вот систематизированного опыта, оформленного в методики - не хватает.
Я думаю, что о том, как сформировать команду как единый рабочий механизм, написано уже много книг. Просто мы каждый раз пытаемся сделать велосипед, не можем нормально запланировать работы и внутренне не согласны с планируемыми сроками.
О том, как действовать в цепочке людей при разработке, книг не встречал. Пока только формирую структуру действий на основании своего опыта.
Прямых указаний по глубине описания требований я не встречал. Только описания проблемы на совсем поверхностном уровне.
Может быть коллеги помогут или подскажут.
О том, как действовать в цепочке людей при разработке, книг не встречал. Пока только формирую структуру действий на основании своего опыта.
Прямых указаний по глубине описания требований я не встречал. Только описания проблемы на совсем поверхностном уровне.
Может быть коллеги помогут или подскажут.
F
Самый главная задача - это формирования в рамках проекта общего настроя, когда люди понимают цели проекта, понимают шаги его достижения, достаточно подробно понимают как он должен работать. Обычно это работа пм"а сформировать правильную последовательность работ, освободить команду от прочей нагрузки, сконцентрировать процесс. Но они этого не умают. Я ни одного не видел. Хотя, может один и был...
И когда вы работаете аналитиком, вы начинаете просчитывать слабые звенья в цепи, из этого строите тактику формирования требований.
И когда вы работаете аналитиком, вы начинаете просчитывать слабые звенья в цепи, из этого строите тактику формирования требований.
+, правильно говорите это работа ПМа. Если он договаривается с Архитектором что в проекте не нужен арчимейт, значит он не нужен.
ОИ
+, правильно говорите это работа ПМа. Если он договаривается с Архитектором что в проекте не нужен арчимейт, значит он не нужен.
Проджекты и архимейт - это вроде разные вселенные. Продукт зачастую тоже не может заставить использовать AM, т.к. если его не знают аналитики/разработка, то сразу нет.