Говоря о программных проектах, видели ли вы, как различные компании по разработке программного обеспечения и компании по проектированию программных услуг описывают проект? После их описания, можете ли вы быстро понять конкретные требования и фон проекта?

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

Описание отрасли клиента

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

Проблемы в бизнес-процессе (где находятся потребности)

Это основная мотивация клиента. Какие проблемы возникают в рабочей среде клиента? Нуждается ли текущий рабочий процесс в цифровизации, или существующая информационная система требует реорганизации, или необходимо внедрить цифровые меры в ответ на новые тенденции в отрасли? Здесь важно объективно и с пониманием отнестись к ситуации, с которой сталкивается клиент.

Предложенное решение

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

Результат

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

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

Создайте «ключевую ценность», чтобы определить границы проекта

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

Пример:

Клиент хочет, чтобы в корпоративной информационной системе была функция «нажмите кнопку запуска, и работа будет автоматически запланирована». На первый взгляд, это может показаться простым объединением рабочих процессов, но на практике может потребоваться учитывать различные бизнес-логики, такие как права доступа, статус предыдущего выполнения, стабильность соединения системы и т.д. В этот момент клиент может сказать: «Я хочу, чтобы при нажатии кнопки было ощущение оживления и движения».

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

Что делать, если в ограниченные сроки разработки возникают конфликты между функциональностью и ожиданиями клиента от интерфейса?

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

Определите наиболее подходящую «ключевую ценность» вместе с клиентом для каждого проекта

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