Перед вами первая часть из трёх частей общего труда, вводная часть цикла статей о проектировании процессов разработки IT-продукта.
Данная вводная статья носит философский характер, некий взгляд на вещи, на то, каким путём имеет смысл идти в выстраивании рабочих процессов над продуктом. Это не является догмой, естественно не является законом.
Это пища для размышления руководителям продукта и руководителям отделов разработки продукта, а так же, руководителям отделов, косвенно имеющих влияние на продукт. Для всех тех, кто имеет начальный уровень,в статье оставлены поясняющие определения для используемых терминов. Возможно, кто-то найдёт в этом смысл и сможет дополнить этот взгляд своим опытом и обстоятельствами IT продукта, использовав данный подход,что в конечном счёте поможет решить продукту свои организационные и производственные проблемы.
Начало начал
На начальных этапах формирования программных обеспечений периода
90-ых, 2000-ых годов, подход к проектированию программ был условным,
Разработка ПО, процесс шаг за шагом
в большей степени определялся самими разработчиками. С ростом конкуренции и качеством продуктов на рынке, создавать продукты на основе личной интерпретации понимания разработчика — является как минимум некорректным. Современный подход к разработке продуктов требует всеобъемлющего проектирования процессов разработки, как некую форму общего дизайна продукта и процессов работы над этим продуктом такой инженерной системы взаимодействий, которая включает в себя:
- проектирование интерфейсов;
- маркетинговые идеи и решения;
- взаимодействие бизнеса с пользователем;
- создание аккуратного кода, разбитого по сегментам и контекстам бизнес-процессов для более удобного управления и рефакторинга в будущем.
Рефакторинг — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения, для облегчения понимания работы программы.
Однако, ещё далеко не все компании обрели понимание подобного системного подхода.
Борьба с системой уже тоже система
Привычный подход устарел
Классический подход в разработке продуктов, который зародился в конце
XX века, на сегодняшний день укрепил образ некой системы, которая работает на потоке, который, в свою очередь, сложно отследить, внести изменения или интегрировать инструменты, которые помогут как минимум стабилизировать процессы в управлении продуктом и командами, сократив расходы бизнеса
на IT-продукт. В конечном счёте, такой подход выглядит более нестабильным, трудозатратным и экономически невыгодным, поскольку в перспективе тратится больше ресурсов на доработку IT-продукта, бесконечный поиск причин ошибок, которые были допущены на этапе проектирования общих рабочих процессов, и такая же бесконечная борьба со следствием в виде вливания бюджетов и времени на залатывание производственных дыр. По нашему мнению, одна из причин, это невозможность в принципе, или нежелание бизнеса (владельца продукта) по каким-то личным соображениям, мировоззренческим установкам, стереотипам мышления или попросту страха, строить организационные процессы и выстраивать внутренние отношения между отделами IT-продукта более системно, как некий общий организм, который функционирует ради достижения общей цели.
Разработка бизнес процесса «Разработка ПО» в ELMA
Альтернатива губительному «потоку»
В данной труде мы предлагаем рассмотреть альтернативу подобной устаревшей, и попросту губительной (на наш взгляд) модели, относящуюся
к производству IT-продуктов. Данная альтернатива подразумевает под собой изначальное проектирование процессов в зарождающемся продукте получившем финансирование или постепенное интегрирование «порядка»
в уже функционирующие процессы работающих продуктов на рынке. Интегрирование «порядка» в уже функционирующие процессы, может быть болезненным, в силу масштабов и обстоятельств внутреннего бардака, однако, это хотя бы является путём к исправлению ошибок и выстраиванию систематизации продукта в управлении, как между командами, внутри команд, так и внутри исходного кода продукта.
Перетягивание одеял
В нашем понимании, основой системного подхода к производственным процессам работы над IT-продуктом, является такое выстраивание производственных процессов, в котором всем участникам процесса работы над продуктом, важно принять то обстоятельство, что именно коллективная сплоченность в достижении общей цели на разработку продукта, поможет достичь более высоких и качественных результатов, в отличии от индивидуальной игры отдельных команд работающих «на потоке» в своих песочницах, в отрыве от общего курса и политики IT-продукта. Конечно, этот вопрос должен решатся управленцами продукта, должны создаваться такие условия и процессы работы, при которых подобное перетягивание будет недопустимо, ибо подобные «перетягивания одеял», через недоговоренности
и конфликты, будут рождать внутренний раздор и непонимание, трату времени и финансов. Потому, необходимо выстроить процесс симбиоза между бизнесом, дизайном и разработкой, с помощью внутренних «языков общения» относительно каждого из направлений, где дизайн и разработка понимают
и учитывают интересы бизнеса, через представителей стороны бизнеса (маркетологи, аналитики) , а также выстраивают общей язык внутри собственной среды разработки (дизайн/front-end) с помощью токенов,
о которых ниже пойдёт речь, а бизнес, в свою очередь, понимает свою целевую аудиторию (пользователя) и умеет объяснить и донести свои ключевые потребности до команд разработки.
Более и менее важные специалисты
В погоне за общей целью, мы не делим разработчиков на более или менее важных в контексте общего процесса в достижении цели, не обесцениваем труд проектировщика интерфейсов (ux/ui-дизайнер) только потому, что по субъективным ощущениям, проектирование интерфейсов не так важно как программирование, и что ux/ui-дизайнер не так серьезен в знаниях и важности как разработчик. Порой, такое отношение можно встретить внутри компаний. Основные процессы более важны в данном случае, чем личные отношения к кому-либо. В масштабах управления разработкой продуктов, мыслить подобным образом — попросту глупо и опасно.
Пренебрежение проектированием
Дизайн интерфейса, как форма взаимодействия пользователя с интерфейсом — важная часть на этапе общего проектирования процессов. Если проектирование интерфейсов (ux/ui-дизайн) не будет учитываться, если им будут пренебрегать, то хороший дизайн сменится плохим дизайном от разработчиков, которые сделают по своему, опираясь на свой сухой взгляд и опыт в данной сфере, в итоге сделав дизайн интерфейса, но не тот который нужен продукту, или спроектировав архитектуру продукта так, что внедрение каких-либо изменений в архитектуру или проектирование интерфейса, будет невозможным или на столько затратным, что легче всё начать заново. В конечном счёте, хорошо спроектированный интерфейс сменится плохо спроектированным интерфейсом, ибо сама форма останется — интерфейс всё равно будет спроектирован, но не ux/ui-дизайнером, что недопустимо в нынешних условиях конкуренции продуктов на рынке. Потому, имеет большое значение изначальное проектирование производственных процессов и продукта, поскольку у одних только разработчиков вряд-ли в запасе есть опыт и время на изучение потребностей клиента, бизнес-целей и качественное проектирование интерфейса.
«Предположим, что центральная сущность разрабатываемого продукта это — обращение. Процесс работы с обращением очень разветвленный и зависит от темы обращения, через N-ное количество спринтов мы осознали, что неверно выделили центральную сущность как единицу бизнес процесса.
Центральной сущностью оказалась задача, которая порождалась по результату обращения, задач могло быть несколько, но к тому времени, мы сконструировали большой bpmn-процесс который никак не учитывал появления в нем задач. Если абстрактно отвечать на вопрос пренебрежения проектированием, то это неправильное выделение сущностей на начальном этапе или неправильное формулирование отношений между сущностями, либо неправильный выбор технологии какой-либо, на базе которой строится какой-то функционал системы (основной или поддерживающий с точки зрения D.D.D.). Тут же все упирается в то, что дороже — пилить дальше по тем же рельсам, переписать или закрыть проект. Сама точка невозврата находится на начальном этапе, когда идет исследование домена в котором будет вестись разработка, и если что-то не достаточно глубоко изучили, то это приведет к проблемам как та, что я описал выше, или это может привести к неверно выбранной технологии (типа храним данный в реляционный базе данных или в документо-ориентированной), с чем придется так же либо мириться, либо переделывать, вопрос опять за чей счет? Так же плохая изученность объектов моделирования, может быть причиной неверно выбранной архитектуры самого решения (типа синхронно, асинхронно, событийно и т.п.), которая может не учесть чего-то, о чем станет известно потом. Вот поэтому есть всякие SOLID KISS DRY и прочие рекомендации, которые могут тебе помочь снизить издержки и страдания, когда что-то надо менять.»
Елагин Андрей . Ведущий разработчик АБЦТ (Ак Барс Цифровые Технологии)
Бизнесу в свою очередь необходимо понимать и выстраивать отношение в пользователем, уважать его как основного участника процесса, кем он и является. Бизнес-аналитики и маркетологи могут предлагать модные методологии изучения, вестись на общепринятые сценарии поведения в изучении и для понимания своей аудитории через условный Метод Персон или Jobs to Be Done, делая это в тех обстоятельствах и для тех целей, для которых эти методологии излишни или не оправдывают себя в конкретной ситуации. Это глупый подход, которому более нет места, особенно в рамках масштабных продуктов, с высокой финансово-репутационной ответственностью. Скорее это вопрос о зрелости команд и понимании каждой командой своего предмета в теории и практике.
Следствием подобных упущений/пренебрежений, будут систематические доработки со стороны разработки, фикс багов, работа с бэклогом, базой данных и т.д.
Бэклог — очередь задач, перечень всех функций, которые заинтересованные люди хотят получить от продукта
Источник: vc.ru
Программное обеспечение как бизнес-процесс
Последнее десятилетие было отмечено ростом понимания значимости информационных технологий (ИТ) в развитии современной экономики вообще и каждого конкретного предприятия в частности.
Сегодня ни у кого не вызывает сомнений, что инвестиции в ИТ должны быть направлены на совершенствование бизнес-процессов компании с целью выделения ее конкурентных преимуществ, оптимизации затрат и поддержки изменений в бизнесе. Отсюда следует, что программное обеспечение играет все более важную роль в достижении организациями целей своего бизнеса.
Рисунок 11 – Новая концепция процесса разработки ПО
Разработка программного обеспечения становится частью бизнеса компании и одним из ключевых бизнес процессов, тесно интегрированным с другими процессами и инфраструктурой предприятия. Согласно этой концепции, связь бизнес-целей, операционной деятельности и задач автоматизации в компании представляет собой замкнутый цикл: цели бизнеса определяют новые потребности в автоматизации, которые затем закрываются в процессе создания или развития программных решений. Результат внедрения новых информационных систем, который может быть проанализирован и измерен, создает новые возможности для развития бизнеса, что, в свою очередь, создает новые потребности в автоматизации и т.д. Таким образом, успешные организации больше не ограничиваются просто автоматизацией бизнес-процессов, они также отслеживают процесс их выполнения и обеспечивают обратную связь в реальном времени, позволяющую совершенствовать бизнес-процессы в соответствии с изменяющимися потребностями клиентов.
Рисунок 12 – Роль ИТ в компании, действующей в соответствии с моделями бизнес-процессов
Несмотря на то, что ключевые элементы автоматизации многих бизнес-процессов сегодня можно купить в «готовом» виде, существует множество других задач, которые имеют уникальный характер для каждого бизнеса. Тиражируемые решения, такие как системы управление ресурсами предприятия (ERP), системы управления цепочкой поставок (SCM), системы управления взаимоотношениями с клиентами (CRM) и многие другие, предлагают стандартные варианты реализации соответствующих функций и обеспечивают минимальные риски в процессе их внедрения, эксплуатации и модернизации. Но чтобы выделить компанию в ряду конкурентов, внедрения этих продуктов недостаточно, нужны адаптированные решения, которые учитывают специфику данной компании и отражают ее уникальные ключевые практики. Автоматизацию подобных процессов невозможно осуществить, просто купив готовые пакеты приложений. Вот некоторые примеры таких процессов для конкретных отраслей:
— — Страхование – заключение договоров, ранжирование клиентов и обработка заявлений от клиентов
— — Финансы – трейдерские и брокерские услуги, управление инвестиционными портфелями и урегулирование спорных вопросов
— — Туризм и транспорт – фрахтование, обслуживание инфраструктуры и эксплуатация оборудования
С другой стороны, если ранее каждый бизнес-процесс рассматривался как последовательность автономных, независимых друг от друга действий, которые поддерживались различными системами ИТ, то с течением времени процесс бизнес-интеграции дошел до такой стадии, на которой все действия рассматриваются как компоненты единого, горизонтально интегрированного бизнес-процесса, поддерживаемого единым программным обеспечением.
Рисунок 13 – Разработка программного обеспечения – стратегический бизнес-процесс
В связи с этим, все больше компаний начинают понимать ценность интегрированной платформы разработки приложений для повышения эффективности взаимосвязанных процессов при создании программных продуктов. А сам процесс разработки программного обеспечения становится важной составляющей бизнес-процессов компании, направленной на решение трех основных задач:
— — Увязывание потребностей бизнеса с решениями в сфере ИТ
— — Организация совместной работы специалистов
— — Обеспечение прозрачности решений, контроля затрат и управления рисками
В этот процесс оказываются вовлечены сотрудники компании на всех уровнях, каждый из которых получает ощутимые преимущества от использования интегрированной платформы разработки ПО:
— — Руководители высшего звена и бизнес-менеджеры получают возможность направить ИТ на реализацию целей своего бизнеса и отслеживать отдачу от инвестиций, как в рамках всего портфеля ИТ, так и в разрезе отдельных проектов
— — Руководители отдела разработки ПО и руководители проектов получают новые возможности для контроля за состоянием проекта и обеспечения качества конечного продукта
— — Члены команды разработки получают еще больше возможностей для эффективной, согласованной совместной работы, которая исключает непродуктивные операции, дублирование усилий или несогласованные действия
— — Сотрудники службы внедрения и эксплуатации получают эффективные средства настройки, развертывания и сопровождения программных систем
Рисунок 14 – Организация коллективной работы с IBM SDP
IBM Rational Suite в свое время стала первым интегрированным решением для разработки программного обеспечения. Теперь идеи коллективной работы получили дальнейшее развитие на уровне всей компании, а IBM Software Development Platform стала первой интегрированной платформой, которая позволяет увязать задачи разработки ИТ с целями бизнеса.
Воспользуйтесь поиском по сайту:
studopedia.org — Студопедия.Орг — 2014-2023 год. Студопедия не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования (0.008 с) .
Источник: studopedia.org
Разработка программного обеспечения как бизнес процесс
Основа для успешного запуска IT-проекта складывается из правильной интерпретации бизнес-целей, взаимодействия с клиентами (учета их потребностей и нужд) и расстановке приоритетов. Все эти критерии — следствие в выборе подхода разработки ПО.
В этой статье рассмотрим методологии разработки программного обеспечения и под какие задачи бизнеса они подходят.
Начнем с того, что именно представляет собой ПО.
Что такое программное обеспечение?
Программное обеспечение — то, что позволяет нам (обычным пользователям) выполнять любые действия с компьютером. Взаимодействие любого пользователя с компьютером без ПО невозможно.
Например, без интернет-браузера (Google Chrome, Yandex и т.д.) никто не смог бы пользоваться интернетом. А без операционной системы (Windows, Android, macOS и др.) невозможна работа интернет-браузера.
Здесь два примера программного обеспечения: интернет-браузер и операционная система. Интернет-браузер также — программа, а ОС при этом — нет. Таким образом, все программы — это ПО, но не все ПО — программы.
Когда есть цель — разработать проект программного обеспечения, как это сделать? Как происходит процесс?
Этапы разработки и жизненного цикла ПО
Каждое ПО проходит определенный порядок этапов с момента создания до окончания внедрения. Стандартный цикл: подготовительный этап, проектирование, разработка (создание) и поддержка.
Этапы разработки проекта программного обеспечения
Теперь рассмотрим эти процессы на примере создания приложения для онлайн покупок и доставки продуктов для сети продуктовых магазинов.
Подготовка.
Руководители сети супермаркетов приняли решение о запуске приложения для своих покупателей и начали анализировать, какие подобные приложения и программы уже есть на рынке. Кроме того, они собрали все необходимые данные об их трафике и функциональности.
Проектирование.
Руководители выбрали компанию-подрядчика для создания программного обеспечения и обсудили архитектуру и дизайн будущего IT-продукта с ее специалистами.
Создание.
Руководители сети магазинов заключили договор с разработчиками. Специалисты запустили кодирование, начали отрисовывать дизайн и составлять необходимую документацию.
Поддержка.
Представители сети супермаркетов подписали акт сдачи-приемки, а специалисты компании-подрядчика разместили продукт (приложение) на серверах. Пользователи начали им пользоваться и сообщать о замеченных ошибках в раздел технической поддержки, а программисты — оперативно их исправлять.
Так выглядит стандартный процесс разработки проекта программного обеспечения.
Кроме того, есть еще два понятия: модель и методология разработки ПО. Что это такое и в чем разница?
Модель разработки ПО — про то, какие стадии или этапы жизненного цикла оно проходит и что именно происходит на каждой из них.
А методология — это то, что именно входит в набор методов по управлению и контролю разработки: правила, техники и принципы, которые делают весь процесс более эффективным.
Далее — расскажем подробнее о популярных моделях разработки ПО, их плюсах и минусах.
Модели разработки ПО
- модель кодирования и устранения ошибок (Code and fix),
- каскадная модель или «водопад» (Waterfall),
- V-образная модель — разработка через тестирование (V-model),
- инкрементная модель (Incremental Model),
- итеративная или итерационная модель (Iterative Model),
- спиральная модель (Spiral Model),
- прототипная модель (Prototype Model) и др..
На них остановимся, рассмотрим более подробно.
Виды популярных моделей разработки ПО по данным ScienceSoft
«Водопад» — каскадная модель (Waterfall)
При выборе этой модели создание программного обеспечения происходит поэтапно, т.е. каждая стадия начинается по завершению предыдущей. Появилась давно — в 1970-х годах. Зачастую наиболее быстрая и простая в применении.
Преимущества
✔️ Простой контроль. Заказчик всегда в курсе, что именно выполняют разработчики в конкретный момент, и имеет возможность управлять стоимостью и сроками разработки.
✔️ Определение стоимости на начальном этапе. На этапе согласования договора планируются все шаги разработки, поэтому написание ПО от начала до конца происходит непрерывно.
✔️ Нет необходимости в тестировщиках высокого уровня. Подробная техническая документация позволяет успешно проводить тестирование специалистам без серьезной технической подготовки. Это помогает заказчику сэкономить общую стоимость создания проекта.
Недостатки
❌ Тестирование на последних этапах. В случае допущенной ошибки в определении требований к IT-продукту, ее исправление становится дорогостоящим, т.к. тестировщики обнаруживают ее, когда код уже написан разработчиком, а документация также уже подготовлена техническими писателями.
❌ Возможность посмотреть готовый IT-продукт заказчику только в конце разработки. Это нередко влечет несоответствие ожиданиям и, соответственно, неудовлетворенность заказчика.
❌ Увеличенные сроки из-за большого количества технической документации. Чем больше масштаб проекта и объем необходимой документации, тем больше корректировок необходимо вносить, тем дольше происходит их согласование.
Каскадная модель хорошо подходит для разработки ПО в сфере медицины или космоса, т.к. в них уже есть обширная база документов (СНиПы и спецификации), на их основе легче и быстрее написать требования к новому проекту.
Источник: leantech.ai