Мне кажется, что кривое ТЗ не самая большая проблема. Проблемы с количеством и качеством специалистов у государственных и муниципальных Заказчиков это не решит. Сроки исполнения, требования, объемы и даже стоимость работ можно согласовать на стадии заключения контракта и даже во время его исполнения. Все это возможно и по 44-ФЗ. Главное все верно оформить, контролирующих органов много - нужно всем угодить. Как не было в бюджете спецов для написания ТЗ, так и нет их для внесения изменений в документацию. Где найти грамотного специалиста, что бы смог обосновать изменение существенных условий контракта? Да так, что бы угодить Исполнителю, юристам, минимизировать риски административных санкций и вопросы контролирующих органов. Где найти контрактного управляющего знающего действующее законодательство, бюджетный кодекс, разбирающегося в IT, имеющего достаточно софт скиллов для общения с должностными лицами Заказчика и Исполнителя, еще стальные я..ца для Прокуратуры, ФАС, Фин. органа, КСП, Казначейства... следственного комитета (было и такое). Вот это проблема! Было бы желание обоих сторон согласовать разногласия и знания как безопасно это сделать - изначально кривое ТЗ не проблема.
Согласна, в строительстве главное для некоторых видов работ нам обязательна проектная документация, а чем рынок IT хуже? То же строительство функционирующей системы со своей четкой архитектурой и ценники не меньше.)
Получается хороший БА должен быть еще немного юристом, что бы объяснить важность СЭД для заказчика? Некоторые штрафы могут быть существенны - особенно в государственных, муниципальных закупках, где СЭД применяется по закону. А прослеживаемы товары? Документы по их обороту проходят только через ЭДО, в том, числе и по части оборудования, на котором разработчики работают (Мониторы и проекторы зарубежного производства). Получается разработчики совсем не боятся кнута (штрафов)? Правильно это же не им прилетит, а Заказчику. Был случай в централизованной бухгалтерии истекли ЭЦП у нескольких учреждений в срок сдачи отчетов, а системный администратор не изготавливает новые ЭЦП - нет настроения... По-хорошему человек 2 недели не понимал. Тогда мы (ответственные за представление отчетности) собрались и пошли к нему. Сказали за непредоставление отчета - штраф 200руб. за каждого физика, их около 200. Штраф получается 40 000. Платить будешь сам. Тогда это были существенные деньги. И хоть по закону с него их вряд ли можно было взыскать, но ему хватило суток что-бы выпустить все новые эцп. А в целом у нас были хорошие отношения - просто сис. админы и правда не всегда понимают почему мы такие злые.
Спасибо за пояснения. У нас на работе бывают очень жаркие дискуссии и не всегда они приводят к лучшей реализации. Иногда после совместного решения проблемы только увеличиваются, иногда директор принимает решение, которое изначально не оптимально. Решение директора - реальность в которой приходится жить. Она так видит. И если коллективные решения мы можем пересмотреть после реализации, то решения руководителя безапелляционны.
"Я всегда задаю вопрос на собеседованиях: если у вас 3 заказчика и они вам говорят противоположные требования к системе, что вы будете делать? По ответам всегда понятно, имеет ли кандидат реальный опыт работы БА."
А какой ответ верный?
Я бы их вместе собрала пусть (передерутся) договорятся))) Опыта у меня нет, я ток учусь. И прав тоже на Хабр нет)) Я могу пока только под свежими статьями комментировать и только под комментами других пользователей - это так дискриминационно(((.
Сейчас буду делать домашку по CRISP-DM. Попробую систематизировать не системное. Там как раз описаны ситуации когда на выходе мы получаем не то, что хотел заказчик. И по схеме в этом случае мы должны вернуться в исходную точку - к бизнес анализу. И вновь пройти все этапы от сбора данных, определения целей и методов и т.д. до оценки результата. И так по кругу, до тех пор пока Заказчик не будет удовлетворен результатом. И только после этого наступает этап внедрения.
Так что то, что Вы описываете как не системное поведение Заказчика(ов) является обычным процессом работы с данными. И даже утверждение "если трансформировать нельзя " (или реализовать "хотелки" Заказчика), тоже является частью методологии работы с данными. Системный анализ предусматривает возможность неоправданности реализации тех или иных проектов, в этом случае, в идеале, это выяснить на этапе сбора данных и первичного анализа, а не на этапе внедрения.
Согласитесь, Заказчику лучше сразу узнать, что его идеи не реализуемы или не оправданны, чем потратить месяцы на анализ и разработку, привлечь кучу специалистов, купить железо, выделить вам носителей hard scills из своей штатки и, в итоге, получить нерабочий продукт. А потом узнать, что он изначально был не реализуем.
Хороший системный аналитик данных на 50% состоит из опыта и на 50% из знаний. У меня нет ни того ни другого - я плохой аналитик. Поэтому процесс обучения в системном анализе бесконечен. Опыта недостаточно - нужно все время учиться. И если в чем то Вы перестали видеть систему, то значит пора учиться ее видеть...
Это один из методов сетевого маркетинга. И он сработал)) Мы же зашли, прочитали и прокомментировали. А ожидания у всех разные, да и в целом в жизни ожидания и реальность мало когда совпадают.
Хорошо кому-то она может копать в стороны.)) А я только зарегистрировалась я даже спросить ничего не могу, нет прав. )) Numba для jit-компиляции, CuPy и joblib еще не изучала, Все еще впереди. А описанная выше статья вполне закрепляет ранее пройденный материал, лично мне полезно.
Мне кажется, что кривое ТЗ не самая большая проблема. Проблемы с количеством и качеством специалистов у государственных и муниципальных Заказчиков это не решит. Сроки исполнения, требования, объемы и даже стоимость работ можно согласовать на стадии заключения контракта и даже во время его исполнения. Все это возможно и по 44-ФЗ. Главное все верно оформить, контролирующих органов много - нужно всем угодить. Как не было в бюджете спецов для написания ТЗ, так и нет их для внесения изменений в документацию. Где найти грамотного специалиста, что бы смог обосновать изменение существенных условий контракта? Да так, что бы угодить Исполнителю, юристам, минимизировать риски административных санкций и вопросы контролирующих органов. Где найти контрактного управляющего знающего действующее законодательство, бюджетный кодекс, разбирающегося в IT, имеющего достаточно софт скиллов для общения с должностными лицами Заказчика и Исполнителя, еще стальные я..ца для Прокуратуры, ФАС, Фин. органа, КСП, Казначейства... следственного комитета (было и такое). Вот это проблема! Было бы желание обоих сторон согласовать разногласия и знания как безопасно это сделать - изначально кривое ТЗ не проблема.
Согласна, в строительстве главное для некоторых видов работ нам обязательна проектная документация, а чем рынок IT хуже? То же строительство функционирующей системы со своей четкой архитектурой и ценники не меньше.)
Получается хороший БА должен быть еще немного юристом, что бы объяснить важность СЭД для заказчика? Некоторые штрафы могут быть существенны - особенно в государственных, муниципальных закупках, где СЭД применяется по закону. А прослеживаемы товары? Документы по их обороту проходят только через ЭДО, в том, числе и по части оборудования, на котором разработчики работают (Мониторы и проекторы зарубежного производства). Получается разработчики совсем не боятся кнута (штрафов)? Правильно это же не им прилетит, а Заказчику. Был случай в централизованной бухгалтерии истекли ЭЦП у нескольких учреждений в срок сдачи отчетов, а системный администратор не изготавливает новые ЭЦП - нет настроения... По-хорошему человек 2 недели не понимал. Тогда мы (ответственные за представление отчетности) собрались и пошли к нему. Сказали за непредоставление отчета - штраф 200руб. за каждого физика, их около 200. Штраф получается 40 000. Платить будешь сам. Тогда это были существенные деньги. И хоть по закону с него их вряд ли можно было взыскать, но ему хватило суток что-бы выпустить все новые эцп. А в целом у нас были хорошие отношения - просто сис. админы и правда не всегда понимают почему мы такие злые.
"бить по рукам программисту" - это я люблю. И тыкать в ненужные ему бумажки. Значит я правильно выбрала новую профессию))
Спасибо за пояснения. У нас на работе бывают очень жаркие дискуссии и не всегда они приводят к лучшей реализации. Иногда после совместного решения проблемы только увеличиваются, иногда директор принимает решение, которое изначально не оптимально. Решение директора - реальность в которой приходится жить. Она так видит. И если коллективные решения мы можем пересмотреть после реализации, то решения руководителя безапелляционны.
"Я всегда задаю вопрос на собеседованиях: если у вас 3 заказчика и они вам говорят противоположные требования к системе, что вы будете делать? По ответам всегда понятно, имеет ли кандидат реальный опыт работы БА."
А какой ответ верный?
Я бы их вместе собрала пусть (передерутся) договорятся))) Опыта у меня нет, я ток учусь. И прав тоже на Хабр нет)) Я могу пока только под свежими статьями комментировать и только под комментами других пользователей - это так дискриминационно(((.
Сейчас буду делать домашку по CRISP-DM. Попробую систематизировать не системное. Там как раз описаны ситуации когда на выходе мы получаем не то, что хотел заказчик. И по схеме в этом случае мы должны вернуться в исходную точку - к бизнес анализу. И вновь пройти все этапы от сбора данных, определения целей и методов и т.д. до оценки результата. И так по кругу, до тех пор пока Заказчик не будет удовлетворен результатом. И только после этого наступает этап внедрения.
Так что то, что Вы описываете как не системное поведение Заказчика(ов) является обычным процессом работы с данными. И даже утверждение "если трансформировать нельзя " (или реализовать "хотелки" Заказчика), тоже является частью методологии работы с данными. Системный анализ предусматривает возможность неоправданности реализации тех или иных проектов, в этом случае, в идеале, это выяснить на этапе сбора данных и первичного анализа, а не на этапе внедрения.
Согласитесь, Заказчику лучше сразу узнать, что его идеи не реализуемы или не оправданны, чем потратить месяцы на анализ и разработку, привлечь кучу специалистов, купить железо, выделить вам носителей hard scills из своей штатки и, в итоге, получить нерабочий продукт. А потом узнать, что он изначально был не реализуем.
Хороший системный аналитик данных на 50% состоит из опыта и на 50% из знаний. У меня нет ни того ни другого - я плохой аналитик. Поэтому процесс обучения в системном анализе бесконечен. Опыта недостаточно - нужно все время учиться. И если в чем то Вы перестали видеть систему, то значит пора учиться ее видеть...
Киньте помидоркой - домашку легче будет сделать))
Это один из методов сетевого маркетинга. И он сработал)) Мы же зашли, прочитали и прокомментировали. А ожидания у всех разные, да и в целом в жизни ожидания и реальность мало когда совпадают.
Хорошо кому-то она может копать в стороны.)) А я только зарегистрировалась я даже спросить ничего не могу, нет прав. )) Numba для jit-компиляции, CuPy и joblib еще не изучала, Все еще впереди. А описанная выше статья вполне закрепляет ранее пройденный материал, лично мне полезно.