Это точно был в том числе и испорченый телефон для команды, когда архитектор решал за лида, а лид был инструментом реализации идей архитектора. Мне кажется, что это одна из болезней решений спускаемых сверху.
Мое мнение, что в нашем случае архитектор, когда стал решать за команду как ей код писать, напоролся на две проблемы. Проблема 1: другому человеку свои мозги не пересадишь. Проблема 2: когда делаешь что-то реально сложное, ты можешь не учесть всего в самом начале, и итоговое решение может сильно меняться исходя из той информации, которую ты получаешь начав что-то делать. Добавлю, что для уменьшения вероятности второй проблемы можно использовать подход с прототипированием.
У вас были какие-то случаи из рабочей практики, в которых стреляли такие проблемы?
Если я правильно поняла, то предположение в том, что мы намеренно не стали делать так, как попросил архитектор. Это не так - мы на протяжении всей работы честно думали, что осуществляем его задумку. И наш техлид с ним регулярно встречался, задавал вопросы, обсуждал дизайн решения. При этом все равно были не учтены ряд ключевых идей, которые были важны для архитектора. Мы сделали что-то похожее на то, что хотел архитектор. Но этого было недостаточно для того, чтобы решение было действительно тем, что ему нужно.
Ответ на вопрос "В чем же роль архитектора или техлида в таком подходе?" нетривиальный и заслуживает отдельной статьи. Возможно, напишу её в будущем. Когда статья выйдет, скину её сюда и буду рада продолжить обсуждения в комментах под ней!
Конечно прототип не серебряная пуля. Тут могу только согласиться
Это точно был в том числе и испорченый телефон для команды, когда архитектор решал за лида, а лид был инструментом реализации идей архитектора. Мне кажется, что это одна из болезней решений спускаемых сверху.
Мое мнение, что в нашем случае архитектор, когда стал решать за команду как ей код писать, напоролся на две проблемы. Проблема 1: другому человеку свои мозги не пересадишь. Проблема 2: когда делаешь что-то реально сложное, ты можешь не учесть всего в самом начале, и итоговое решение может сильно меняться исходя из той информации, которую ты получаешь начав что-то делать.
Добавлю, что для уменьшения вероятности второй проблемы можно использовать подход с прототипированием.
У вас были какие-то случаи из рабочей практики, в которых стреляли такие проблемы?
Если я правильно поняла, то предположение в том, что мы намеренно не стали делать так, как попросил архитектор. Это не так - мы на протяжении всей работы честно думали, что осуществляем его задумку. И наш техлид с ним регулярно встречался, задавал вопросы, обсуждал дизайн решения. При этом все равно были не учтены ряд ключевых идей, которые были важны для архитектора. Мы сделали что-то похожее на то, что хотел архитектор. Но этого было недостаточно для того, чтобы решение было действительно тем, что ему нужно.
Ответ на вопрос "В чем же роль архитектора или техлида в таком подходе?" нетривиальный и заслуживает отдельной статьи. Возможно, напишу её в будущем. Когда статья выйдет, скину её сюда и буду рада продолжить обсуждения в комментах под ней!
Рада, что вам это откликнулось!)