Главная (страница 10)

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

Оригинальная статья: http://www.batimes.com/articles/know-your-audience-dont-let-your-requirements-get-lost-in-translation.html

Перевод: Юлия Волокитина, Герман Шестеров

В своей работе мы периодически устраиваем встречи между пользователями программных систем и IT-специалистами. В рамках этих собраний IT-специалисты демонстрируют последние разработки, которые могли бы принести пользу бизнесу. Не так давно я присутствовал на встрече, где команда специалистов объясняла, как улучшить бизнес-процесс посредством оптимизации некой программной системы. Учитывая то, что я немного знаком с техническим жаргоном, я смог получить хотя бы общее представление об идее, которую они продвигали, но, как вы уже наверняка догадались, в целом, это был полный провал! Пользователи абсолютно не прониклись идеей, и предложение было отклонено. Далее

Оригинальная статья: http://www.batimes.com/steve-blais/business-analysis-according-to-sherlock-holmes.html

Перевод: Валерия Астапова

С самого детства и на протяжении многих лет я читал и перечитывал рассказы Артура Конан Дойля о невероятном сыщике Шерлоке Холмсе. Не считая разве что чуть менее известного Августа Дюпина (того самого, о котором писал Эдгар Аллан По – например, в “Убийстве на улице Морг”), Холмс предстает перед нами как сверхвыдающийся детектив, чье критическое мышление не имеет равных. Шерлок Холмс представляет собой образец эксцентричного, но гениального сыщика, о котором мы читаем в книгах, слышим в радиопьесах и которого видим в кино. Мистеру Холмсу есть что рассказать нам о том, как анализировать полученную информацию и сведения с целью раскрыть преступление и выявить преступника. Далее

Авторы: Алексей Киселев, Екатерина Душечкина

В компаниях, занимающихся разработкой ПО, зачастую отсутствует хотя бы какая-то практика хранения и систематизации своих наработок.

Это приводит к тому, что аналитик, получив задачу, сразу же начинает исследовать проблему с нуля, изучать предметную область, собирать требования, анализировать их, выявлять зависимости и т.д. Это большой объем трудозатрат, которых можно было бы избежать (или хотя бы сократить) при рациональном хранении артефактов (можно сказать – опыта), накопленных на предыдущих проектах.

Если взять в качестве примера область депозитарной деятельности, то в новых проектах наличие описанного в ходе предыдущих проектов ландшафта бизнес-процессов, требований к функциональности и т.д. могло бы значительно сократить трудозатраты аналитика. Есть даже некая вероятность, что часть постановок уже была ранее написана в смежном проекте другим сотрудником, и просто ждет, когда её найдут и отправят разработчику (задачу повторного использования кода мы здесь не рассматриваем). Последствия такой ситуации, а также оптимальное, на наш взгляд, решение и будут рассмотрены в настоящей статье. Далее