Можно, во многих компаниях так и делают. Мы пошли чуть по другому пути. Почему: системные аналитики создадут новое звено в цепочке передачи бизнес требований продуктовик<->аналитик<->разработчик. А как мы знаем, чем длиннее цепочка, тем больше потери/искажения информации, в результате можно получить в продукте не то, что изначально хотел пользователь, а результат выполнения некой функции какЭтоУслышалПрограммист(какЭтоПонялАналитик(какЭтоПонялПродуктовик(то, что хотел юзер)))). Поэтому мы в компании чаще идём по пути "развить у разработчика компетенции системного анализа". Оказалось, что не все программисты такое хотят, многим хочется писать код) Поэтому встал вопрос, как нанять/найти-и-обучить программистов системному анализу, чтобы им было в кайф и попадало в их мотивацию.
Я позволил себе сделать такое допущение ради гиперболизации крайних и не очень приятных состояний. И для описания, к чему такие состояния, или состояния, близкие к ним, приводят.
Конечно, одна из наших целей в индустрии - придумать, как работать быстро и качественно. Для этого можно создать сработанную команду профессионалов, помочь им создать договорённости, наладить коммуникацию и построить процессы. Тогда мы можем упереться уже в проектный треугольник (цена-время-качество) или тройственную ограниченность, где, как в CAP теореме, нужно будет чем-то жертвовать.
В конце статьи я как раз привёл небольшой список вопросов-подсказок, на которые стоит обратить внимание тем, кто ищет скорости и качества. Будем рады, если вы поделитесь своими способами организации быстрой и качественной разработки. Насобираем на вторую часть статьи)
Любое противопоставление "разработки" и "бизнеса", неважно, какую из сторон вы считаете условно "хорошей", а какую - условно "плохой" - это, конечно же, абсолютное зло.
Согласен, на это я и хотел обратить внимание.
В статье отражён скорее наш путь развития и становления процессов. Сделано это для того, чтобы читатель мог узнать в этом пути своё текущее состояние и сделать шаги к улучшению
Можно, во многих компаниях так и делают. Мы пошли чуть по другому пути. Почему: системные аналитики создадут новое звено в цепочке передачи бизнес требований продуктовик<->аналитик<->разработчик. А как мы знаем, чем длиннее цепочка, тем больше потери/искажения информации, в результате можно получить в продукте не то, что изначально хотел пользователь, а результат выполнения некой функции какЭтоУслышалПрограммист(какЭтоПонялАналитик(какЭтоПонялПродуктовик(то, что хотел юзер)))). Поэтому мы в компании чаще идём по пути "развить у разработчика компетенции системного анализа". Оказалось, что не все программисты такое хотят, многим хочется писать код) Поэтому встал вопрос, как нанять/найти-и-обучить программистов системному анализу, чтобы им было в кайф и попадало в их мотивацию.
Сам в шоке, да, птицы прелестные, порадую лишний раз дизайнера)
Я позволил себе сделать такое допущение ради гиперболизации крайних и не очень приятных состояний. И для описания, к чему такие состояния, или состояния, близкие к ним, приводят.
Конечно, одна из наших целей в индустрии - придумать, как работать быстро и качественно. Для этого можно создать сработанную команду профессионалов, помочь им создать договорённости, наладить коммуникацию и построить процессы. Тогда мы можем упереться уже в проектный треугольник (цена-время-качество) или тройственную ограниченность, где, как в CAP теореме, нужно будет чем-то жертвовать.
В конце статьи я как раз привёл небольшой список вопросов-подсказок, на которые стоит обратить внимание тем, кто ищет скорости и качества. Будем рады, если вы поделитесь своими способами организации быстрой и качественной разработки. Насобираем на вторую часть статьи)
Согласен, на это я и хотел обратить внимание.
В статье отражён скорее наш путь развития и становления процессов. Сделано это для того, чтобы читатель мог узнать в этом пути своё текущее состояние и сделать шаги к улучшению