ПМ. Одна из задач QA - определить возможные неявные требования

в данном случае - девы, хотя я считаю, что это неправильно

Верно думаете.

А пм там просто для галочки?

срам-мастер

Вообще иногда полезно ПМа засунуть куда-нибудь подальше и все разузнать самим и сделать.

не верный подход.

А потом потребовать его зарплату приплюсовать.

только что фиксировали требования для 1й версии, вместе с девами ПМ сказал, что какие-то были коллы, переговоры, но он не помнит ?

Если такая идея возникает, значит ПМ является боттлнеком проекта.

А пм там просто для галочки?

скорее всего

ну и отчеты подавать

Если такая идея возникает, значит ПМ является боттлнеком проекта.

Если он засунут подальше и на него не обращают внимание то он не может быть ботлнеком

Не можешь решить проблему, решай человека. Меняйте ПМа.

грустная история :(

просто нужны менеджеры, я считаю, в любом случае

Если он засунут подальше и на него не обращают внимание то он не может быть ботлнеком

Повторюсь, это всё равно очень плохая практика.

кроме людей-разработчиков с космическим ЧСВ

Это лучше чем ждать по полмесяца пока ПМ раздуплится

Ну или просто скандал устроить

Мне кажется это отличный повод привыкнуть работать без менеджеров.

Потом пригодится.

просто нужны менеджеры, я считаю, в любом случае

Верно. Это человек, который несет ответственность за проект и кучу соответствующих активностей. Если человек некомпетентен - его надо уволить. Провожу аналогию. Если девелопер не справляется со своими задачами, куэи не говорят "да чем его ждать лучше самом накодить". Такого девелопера заменяют. Здесь то же самое.

я скоро научусь работать без девелоперов ?

Вообще, выяснять требования - обязанность всех участников команды. Мир, в котором "менеджер всё выяснил, а мы просто делаем по формализованным требованиям" - грустен и печален. Вопрос должен ли этот процесс проходить через манагера, или можно напрямую пообщаться с клиентом и получить информацию - весьма спорный и сильно зависит от команды и проекта.

+++

+

Верно. Это человек, который несет ответственность за проект и кучу соответствующих активностей. Если человек некомпетентен - его надо уволить. Провожу аналогию. Если девелопер не справляется со своими задачами, куэи не говорят "да чем его ждать лучше самом накодить". Такого девелопера заменяют. Здесь то же самое.

У нас считаeтся, что eсли проeкт зафeйлился, то виноваты всe. Поэтому, eсли ПМ забиваeт, приходится брать на сeбя eго обязанности, и проeкт в итогe выeзжаeт на остальных

в идеальном мире есть для управления проектом такие вещи. как Джира, Бейзкамп и их аналоги, где каждый участник процесса может задавать вопросы нужным людям по нужным доменам.

где прозрачная коммуникация

И ПМ вродe бы молодeц тожe

в идеальном мире есть для управления проектом такие вещи. как Джира, Бейзкамп и их аналоги, где каждый участник процесса может задавать вопросы нужным людям по нужным доменам.

Мир, в котором вопросы задаются через джиру - весьма далек от идеального.

У нас считаeтся, что eсли проeкт зафeйлился, то виноваты всe. Поэтому, eсли ПМ забиваeт, приходится брать на сeбя eго обязанности, и проeкт в итогe выeзжаeт на остальных

так и есть :)

Мир, в котором вопросы задаются через джиру - весьма далек от идеального.

да брось

Не брошу.

объясни тогда

в идеальном мире есть для управления проектом такие вещи. как Джира, Бейзкамп и их аналоги, где каждый участник процесса может задавать вопросы нужным людям по нужным доменам.

Но лучшe это дeлать в мeссeнджeрe </sarcasm>

с лимитом на хистори, да

Джира не предназначена для коммуникации. Джира предназначена для таск менеджмента.

и не прибитым к юзер стори никак

Джира не предназначена для коммуникации. Джира предназначена для таск менеджмента.

там есть комментарии к таскам, если че.

Да и не оперативно это, через жиру выяснять

Можно ещё голубиной почтой требования уточнять, да.

Да и не оперативно это, через жиру выяснять

зависит от того, как вы ее приготовили

Только для общения есть инструменты, предназначенные для этого самого общения.

Мессенджеры, войс, живое общение, вот это всё.

В джире - таски.

Соглашусь.

срам

срам

аргументно.

очень аргументированно.

через джиру нормально коммуницировать, когда таска не горит и не требует быстрого ответа, или боишься отвлечь удаленщика) зачем через нее общаться в любом другом случае, лично я не понимаю

тогда опенсорс вообще закрывать нужно

там Issues общаются

опенсорс скорости не требует

Евгений, пока что никаких аргументов в свою пользу ты не привел. Ничего, кроме эмоциональной оценки и гиперболизации спора.

Issues не является основным способом общения ни для одного опенсорса, если что.

Это скорее фидбэк форма, не больше.

https://www.youtube.com/watch?v=7EytYc7K5JA

По факту же есть живые коммьюнити, чатики и вот это всё.

послушайте успешного умного дядьку

я не говорю что это панацея от всех бед

о чем доклад?)

просто в Джире отлично техническая команда может выявлять критерии решения юзер стоири . таски . бага

о том как удаленно работать и не факапить?)

для более бизнесового слоя - бейзкамп. плюсы этих интсрументов - формализм. слова хороши, когда ты бизнес решение и требование записываешь

Во первых, это не должно делаться в джире. Она для этого не предназначена. Во вторых, техническая команда может выявить критерии решения юзерстори хоть в экселе. Стоит ли от этого его использовать? Нет.

Обсуждать требования и записывать требования - разные вещи.

ERROR: S client not available

Сильно разные.

dat works for me

Для записи требования - джира подходит. Для обсуждения - нет.

dat works for me

И ещё один классный аргумент. :)

послушайте успешного умного дядьку

С названием extremely Disturbed Software Development - кажется, что это не доминирующая практика.

С названием extremely Disturbed Software Development - кажется, что это не доминирующая практика.

само собой, это то, к чему можн стремиться :)

потому что это очень и очень крутое ведение бизнеса

я работал на удаленке долго и успешно, и могу сказать что джира отлично подходит когда тебе не надо сегодня быстро-быстро пилить

если тебе нужно решить вопрос "вот прямо сейчас", в джире это не будешь делать, есть мессенджеры и голос для супер-особых случаев

это что-то такое идеальное, как у Шу на работе, где автоматизировать релиз на 15 ПБ данных можно и нужно пытаться делать потому что "это практика " (с)

Ещё раз, @panemquotidianum Назови хотя бы один плюс, чем Джира удобнее для обсуждения требований чем условный voice call?

если тебе нужно решить вопрос "вот прямо сейчас", в джире это не будешь делать, есть мессенджеры и голос для супер-особых случаев

согласен. но т.к. я повторюсь, этм занимается техническая команда, а ответы тебе нужны от PM, То насколько он шустрый и зависит качество фидбека. Я работал с лучшим ПМ который отвечал в пределах пары минут, всегда :)

согласен. но т.к. я повторюсь, этм занимается техническая команда, а ответы тебе нужны от PM, То насколько он шустрый и зависит качество фидбека. Я работал с лучшим ПМ который отвечал в пределах пары минут, всегда :)

зачем общаться с ПМом в джире, когда можно не в джире? :)

Чтобы другие видели как он общается

общаться не про котиков, если че

И была история и видны причинно-следственные связи

я не вижу проблемы – по итогам общения правится задача) в джире все происходит медленнее чем в личном общении по другим каналам, как ни крути

Доктор, меня игнорируют. ;[

Ну это если правится, а обычно два человек считают что если они пообщались то все порешали и никому знать не нужно.

Ну это если правится, а обычно два человек считают что если они пообщались то все порешали и никому знать не нужно.

Не работайте с мудаками (с)

Тогда надо уйти в лес и жить отшельником

Ну это если правится, а обычно два человек считают что если они пообщались то все порешали и никому знать не нужно.

ну просто что проще читать – переписку в комментах или нормальные поправленные актуальные данные по задаче?

это забота о коллегах элементарная

Задачи конечно

Но иногда мне хочется видеть что привело к той или иной задаче. Какая проблема. Бывает так что проблема надуманная.

Что привело -> это нормальная часть дескрипшена юзерстори.

Там _должно_ быть описание того, какую проблему вы должны решить.

Это скорее хорошее исключение, чем правило ;) Вот в нормальной практие весьма редко такое встречал.

Там _должно_ быть описание того, какую проблему вы должны решить.

все так, нужна предыстория, желательно бизнесовая

у меня на двух работах из трех всегда такое есть :)

Это скорее хорошее исключение, чем правило ;) Вот в нормальной практие весьма редко такое встречал.

Sad to be you.