Бизнес-анализ и разработка ТЗ

Что такое БИЗНЕС АНАЛИЗ, с чем его «едят», а главное стоит ли за него платить?

Бизнес-анализ сегодня играет роль «первой скрипки» в успешной реализации IT-проектов.

Прежде всего бизнес-анализ – это построение нового бизнес-процесса, с учетом возможностей разрабатываемой программы. Основными его составляющими являются анализ требований Заказчика, изучение деталей, выявление возможных «слабых» мест Проекта. Другими словами, бизнес-аналитик должен вникнуть в бизнес-процессы Заказчика, выяснить его пожелания, проанализировать их, дополнить и сформулировать новую модель бизнеса в виде технического задания. ТЗ является самодостаточным документом, с которым Заказчик может обратиться к команде разработчиков для его дальнейшей оценки и разработки. Как правило, жизненный цикл Проекта, а в особенности разработки ПО, состоит из следующих этапов:

Этапы разработки ПО

Исключение какого – либо из этих этапов резко повышает вероятность провала и потерю потраченных денег и времени.

Не понимая важности этапа «Анализа», рассчитывая сэкономить время и деньги, Заказчики часто пренебрегают именно услугами бизнес-аналитика.А зря!

Пpeдставьте, что вы приняли решение построить дом и наняли для этого бригаду гастарбайтеров из недалеких солнечных стран. Какова вepоятность того, что, излагая им ваши пожелания, вы нe потратите себе нeрвы, стараясь донести до них мысль, что то, что они делают, не есть «красиво и удобно»? И это вообще на самом дeлe не то, что Вы хотите! Несомненно, вы, в конце концов, найдете с ними общий язык. А теперь представьте, что в индустрии разработки ПО сneциализированный сленг/понятия/принципы построения систем в разы сложнее и объемнее, а программисты зачастую проявляют гораздо больше нeжeлания вас понимать и общаться с вами обыденным человеческим языком. В основном они предлагают, то что удобно им, то что они «умеют» и когда либо уже делали. То, на что необходимы минимально затраченные усилия!

Вот тут-то и приходит на помощь бизнес анализ, в лице бизнес-аналитика, который «понимает проблемы и возможности бизнеса в контексте требований и рекомендует решения, позволяющие Вам достичь своих целей.

Как подтверждает наш многолетний опыт в сфере IT, от того насколько досконально выяснена и расписана задача, насколько правильно это отражено в ТЗ и зависит будет ли Ваш Проект успешно и своевременно завершен исполнителем.
Если Вы хотите быть уверенным в том, что все пожелания к будущей системе, ПО учтены и грамотно структурированы, обратитесь в нашу Компанию. Наши специалисты в кратчайшие сроки подготовят для вас качественное ТЗ, с которым Вы сможете обратиться уже к исполнителю без риска остаться непонятым!

Схема бизнес анализа

Полезная информация!

Мифы и заблуждения.

Обзор наиболее часто встречающихся заблуждений, которые возникают при создании программ:

Миф №1 «Заказчик знает, что он хочет». Или: начинаем писать программу со слов заказчика, не разобравшись в его бизнесе.

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

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

Вывод

Перед началом разработки программы, необходимо выполнять бизнес-анализ, что бы выявить все реальные потребности бизнеса, которые должны быть отражены в программе. На основе данных этого анализа можно выполнять проектирование и написание постановок (тех. заданий), которые впоследствии будут переданы разработчикам.

Миф № 2 «Исполнитель знает, что мне нужно». Или: одних программистов нам будет достаточно, что бы сделать наш проект.

Миф зеркальный первому, но относится уже к заблуждению заказчика, о том, что исполнитель знает, или сумеет быстро разобраться, какая программа ему нужна. Уважаемые заказчики, если при разработке проекта Вы контактируете непосредственно с разработчиками (программистами), Вам необходимо понимать, что в подавляющем большинстве случаев разработчик: мыслит иначе, оценивает иначе, делает совершенно не те выводы, на которые Вы рассчитываете, и зачастую разговаривает с Вами «на разных языках». Разработчик – человек с иным образом мышления, он не мыслит категориями бизнеса, категориями функциональности и анализа, не оценивает всю взаимосвязь процессов, которые происходят в вашем бизнесе или работе. Для того что бы программу проектировал и разрабатывал один человек, он должен совмещать в себе: бизнес-аналитика, системного-аналитика и программиста. Т.к. наличие таких навыков требует одновременно и большого, разностороннего опыта и склонности человека, как к программированию, так и к анализу, несложно сделать вывод, что таких специалистов немного и встречаются они ненамного чаще, чем заказчики, четко знающие, что им нужно (миф №1).

Чем больше и сложнее проект, тем острее необходимость разделения работ. Бизнес-аналитик выполняет анализ бизнес-процессов и формирует их модели. Системный аналитик, на основании бизнес-анализа, проектирует структуру объектов и их взаимосвязи, пишет ТЗ разработчикам. Программисты занимаются разработкой, используя ТЗ от аналитиков.

Попытки экономии на этапах бизнес и системного анализа, приводят к тому, что согласовывается постановка задачи, в которой заказчик и исполнитель видят совершенно разный результат. Скорее всего, она будет успешно реализована, будут потрачены время и деньги, а польза от полученной программы будет весьма сомнительной. Есть множество примеров, когда после реализации проектов, с подобным подходом, после их внедрения, все только усложнялось и через короткий промежуток времени от программы отказывались или отправляли ее на переделку.

Вывод.

Аналогичный предыдущему: что бы созданная программа была действительно полезным инструментом и помощником в вашем бизнесе, на начальном этапе должен выполнить анализ бизнес-аналитик, только после этого выполняется этап проектирования и написания постановок для программистов и начинается ее разработка.

Миф № 3 «Программа решит все мои проблемы». Или: я хочу большую красную кнопку, что бы при ее нажатии все работало и само делалось.

Достаточно часто встречающееся заблуждение, о том, что программа – панацея от всех бед. Без нее все плохо, бардак и работа не идет. А вот если программа появится, то все, в одночасье, волшебным образом изменится и наступит счастье. На самом деле это не так. Программа это всего лишь ваш помощник, инструмент, который позволяет облегчить и ускорить выполнение ряда процессов обработки и анализа данных. Обычно потребность в использовании автоматизации появляется тогда, когда объемы данных, которыми оперируют люди, становится достаточно большим, и привычные инструменты, такие как ручка, журнал или таблички в Excel уже не спасают. Поэтому перед внедрением любой программы, нужно понять какие именно функции будут на нее возложены, кто из сотрудников будет в ней работать, с какими данными и какие операции выполнять. Только в этом случае она станет хорошим и надежным помощником.

Вывод.

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

Миф № 4 «Всегда можно найти вариант подешевле». Миф о том, что качественную программу можно заказать дешево. Нет, нет и еще раз нет! Почему? Ответ прост. Дело в том, что разработка ПО занимает достаточно много времени, а как известно, время — это деньги. Конечно всегда можно найти студентов, новичков, делающих первые шаги на поприще IT, желающих взяться за реализацию, поэкспериментировать, приобрести опыт, еще и получить за это деньги. Однако скорее всего здесь сработает поговорка «скупой платит дважды» и есть вероятность, что через какое-то время необходимо будет искать нового исполнителя. Как результат, потерянные деньги и время. Так есть ли смысл в таком неоправданном риске?

Вывод.

Не нужно гнаться за дешевыми предложениями. Необходимо найти специалистов, которые могут толково объяснить за что они берут с вас деньги и почему именно такая цена. Главное, чтобы качество разработки оправдало вложенные в него средства.

Принимайте только правильные решения!