Коллеги, подскажите, что нужно было бы прочесть, чтобы наладить рабочий процесс?
В компании у нас "работают по agile", что кажется не вполне правильным.
Весь workflow на одной доске, с чем я не согласен. Ясно, что нужен scrum master, но его необходимость ещё нужно доказать. Начальство же.
Пока что изучаю неструктурированную информацию, пытаюсь понять, как правильно организовать работу. Надеюсь, что сообщество сможет подсказать подходящую литературу и курсы.
Методологий есть куча, но это не руководство к действию и всегда приходится думать головой. Если оно работает то как минимум это уже успех. Работает - не трогай это хороший принцип и менять что-то по причине "кажется не вполне правильным" - глупо и не выгодно.
НО!
Если у вас есть в команде какие-то боли то их надо решать. Надо определись больные места, найти причину этих болей (Five whys) и лечить это.
Вот как лечить - зависит от проблемы, условий и команды
По мне так наличие доски имеющей горизонтальную прокрутку, включающей в себя весь воркфлоу от получения задачи от бизнеса до установки на бой уже само по себе является проблемой.
Задачи, которые в теле имеют только ссылку на закрытую для участников доски задачу в сервисдеске - это проблема. И таких здесь много.
Я же пытаюсь обосновать и предложить нормально организованный процесс.
AnotherAnkor, проблема является таковой только когда она наносит импакт бизнесу. До этого это только кажется проблемой. Если тебе хочется что-то улучшить для начала надо иметь проблему. Улучшение ради улучшения ни один бизнес не принимает
AnotherAnkor, не с того конца заходишь. Сейчас ты хочешь улучшить по тому что ты считаешь что нужно делать иначе. Ты пойдешь, прочитаешь кучу книг и даже предложишь изменить процесс, но 99% что тебя отправят погулять. Почему это? Просто - изменения должны быть выгодны бизнесу. Либо они приносят дополнительную прибыль либо избавляют компанию от расходов.
Поскольку изменение процесса не приносит дохода в управлении задачами то остается только снижение расходов. Где расход?
Иван Шумов, в нашем случае расход на качестве реализации задачи. Потому что каждый участник процесса несёт на себе дополнительно функцию аналитика. По моему скромному это недопустимо.
Или тут я ошибаюсь и у всех так? Когда задача от бизнеса выглядит как: добавь мне тут кнопку с isin. На этом постановка кончается. При уточнениях от бизнеса обычно приходит что - то в духе: я всё сказал. Не люби мне мозг!
Это уже проблема.
Моя же цель вытолкнуть глав отделов на сбор требований. Т. е. выпихнуть на встречу с бизнесом аналитика, технолога и кого-то от тестирования. Тем самым сократить список открытых вопросов и начать разработку как можно раньше и качественнее.
Сейчас же из-за нечёткого тз и невнятных ответов задачи часто зависают на стадии разработки.
Вся наша переписка здесь есть ни что иное, как выяснение корневой причины. Забавно.
Когда задача от бизнеса выглядит как: добавь мне тут кнопку с isin. На этом постановка кончается. При уточнениях от бизнеса обычно приходит что - то в духе: я всё сказал. Не люби мне мозг!
Это не проблема. Любой бизнес так ведет. Обычный программист или даже рядовой CTO не справится с этой задачей. Тут нужен или BA или SA.
Моя же цель вытолкнуть глав отделов на сбор требований. Т. е. выпихнуть на встречу с бизнесом аналитика, технолога и кого-то от тестирования.
Желание хорошее, состав спорный, но я не знаю размер и структуру организации
Сейчас же из-за нечёткого тз и невнятных ответов задачи часто зависают на стадии разработки.
Управление задачами тут никак не поможет. Проблема тут глубже и лежит в отсутствии определенных процессов в SDLC как практики и общения (грамотного) с бизнесом.
Что можно тут предложить - менять майндсет бизнеса, в первую очередь.
Простой
