Если у вас получился вывод, что в PlantUML «Описание сложной логики требует много времени» и «Не все диаграммы в итоге получаются хорошо», то попробуйте сделать сложную диаграмму в draw.io, а через неделю, все перерисовать.
В plantUML (или большом количестве аналогов, типа mermaids) все делается через написание кода, независимо от того, как много стрелочек это проще, чем руками тыкать в стрелочку и таскать туда сюда квадратики.
Вы говорите, что требования должны быть максимально полными, но, как мне показалось, нигде не указываете возможен ли обратный поток - когда разработчик при выполнении доработки придумал как сделать по другому (интереснее, лучше и т.д.) есть у него возможность придти к аналитику внести изменения в требования?
Естественно, это не касается каких то принципиальных изменений дизайна, но например изменения логики работы возможны?
Или у вас априори считается что аналитик знает лучше, а разработчик только лиш кодит?
А по теме - хотелось бы послушать как у вас решаются задачи без участия аналитика, наверное вообще кровавое рубилово, скинуть ответственность то некуда…
Или аналитиков всегда хватает на все задачи? Какой тогда уровень здравого смысла у разработчиков? Или они в доту только и рубятся?
У нас были случаи когда заказчик хотел реализовать некую функциональность, мы реализовывали, а потом он от неё открещивался словами "мы вас об этом не просили".
Я не считаю, что аналитики не нужны, но реальность такова, что аналитик не может оценить сложность реализации того или иного решения. Просто потому что он аналитик, а не программист. И в любом случае программист будет привлекаться к процессу поиска оптимального решения бизнес-задачи.
А у нас бывали случаи, когда разработчики делали так, как сами придумали себе в голове (даже не смотря на то, что с ним предварительно обсудили конкретное решение - он просто "забыл"), а потом переделывали, потому что аналитики намного лучше понимал то, как дейстаительно надо делать и прописал ровно то, что нужно было заказчику :)
Предположу, что главная ценность аналитика (естественно, кроме умения сбора и согласования реальных требований) - опыт, который позволяет, если не досконально разбираться в проблеме и возможном решении, то хотя бы закинуть разработчику "на подумать".
С другой стороны, разработчик который сам себе пишет ТЗ, тестирует и внедряет это ценный но исчезающий кадр. В том числе потому, что разделение труда это то, что этот труд делает более эффективным. У нас в компании штат разработчиков за 10 лет вырос в 12 раз, а отношение сеньоров к общему штату упало драматично (было больше 50%, а стало наверное 15%). Как следствие, штат аналитиков вырос в 6 раз. Аналитики, это опыт разработчика отделенный от умения писать код. Опыт, который может быть использован всеми разработчиками сразу.
Ещё крайне тяжелая проблема, что аналитик порой записывает не проблему заказчика, а его предполагаемое решение, не зная откуда оно возникло и какую проблему решает (проблема X-Y).
Таких "аналитиков" надо отстранять от работы, пока не научатся собирать требования, а не записывать за заказчиком.
Что такое GH?
И главное, есть ли последствия для заказчиков, которые не обеспечили соответствие плана и факта?
Если у вас получился вывод, что в PlantUML «Описание сложной логики требует много времени» и «Не все диаграммы в итоге получаются хорошо», то попробуйте сделать сложную диаграмму в draw.io, а через неделю, все перерисовать.
В plantUML (или большом количестве аналогов, типа mermaids) все делается через написание кода, независимо от того, как много стрелочек это проще, чем руками тыкать в стрелочку и таскать туда сюда квадратики.
Вы говорите, что требования должны быть максимально полными, но, как мне показалось, нигде не указываете возможен ли обратный поток - когда разработчик при выполнении доработки придумал как сделать по другому (интереснее, лучше и т.д.) есть у него возможность придти к аналитику внести изменения в требования?
Естественно, это не касается каких то принципиальных изменений дизайна, но например изменения логики работы возможны?
Или у вас априори считается что аналитик знает лучше, а разработчик только лиш кодит?
Ни для задач :)
плюсую
Да, сарказм присутствует :)
У нас аналитиков хватает не на всех, часть задач, хорошо это или плохо, идут вообще без анализа. Разработчики ваяют в режиме свободного художника.
Я из статьи сделал вывод, что аналитик в итоге сделал правильное ТЗ, уточнил его по результатам обсуждения на дэйлике и всем стало хорошо.
А вот если самого ТЗ нет, уточнять нечего и некому фронт и бэк остаются один на один и … что тогда?
А что за «вотерфлоу»?
А по теме - хотелось бы послушать как у вас решаются задачи без участия аналитика, наверное вообще кровавое рубилово, скинуть ответственность то некуда…
Или аналитиков всегда хватает на все задачи? Какой тогда уровень здравого смысла у разработчиков? Или они в доту только и рубятся?
Спасибо, начинаем думать об этом - статья очень в тему попалась на глаза
А у нас бывали случаи, когда разработчики делали так, как сами придумали себе в голове (даже не смотря на то, что с ним предварительно обсудили конкретное решение - он просто "забыл"), а потом переделывали, потому что аналитики намного лучше понимал то, как дейстаительно надо делать и прописал ровно то, что нужно было заказчику :)
Предположу, что главная ценность аналитика (естественно, кроме умения сбора и согласования реальных требований) - опыт, который позволяет, если не досконально разбираться в проблеме и возможном решении, то хотя бы закинуть разработчику "на подумать".
С другой стороны, разработчик который сам себе пишет ТЗ, тестирует и внедряет это ценный но исчезающий кадр. В том числе потому, что разделение труда это то, что этот труд делает более эффективным. У нас в компании штат разработчиков за 10 лет вырос в 12 раз, а отношение сеньоров к общему штату упало драматично (было больше 50%, а стало наверное 15%). Как следствие, штат аналитиков вырос в 6 раз. Аналитики, это опыт разработчика отделенный от умения писать код. Опыт, который может быть использован всеми разработчиками сразу.
Таких "аналитиков" надо отстранять от работы, пока не научатся собирать требования, а не записывать за заказчиком.
Кастомную доработку может сделать и вендор. "Кастомный" от вендора, это когда разработка конкретно под конкретного заказчика.
Любая профессиональная сфера насыщена жаргонизмами, попробуйте послушать как говорят сталилитейщики, хирурги или трейдеры.