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