Информационный бизнес этапы разработки

Отсутствие партнерского диалога – серьезная преграда, которая часто возникает между заказчиком и аутсорс-командой.

• Подготовительный этап

• Аналитика

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

• Оценка проекта

• Проектирование

1. разработку карты проекта с указанием реперных точек для сверки результатов;
2. проектирование архитектуры программного обеспечения;
3. выбор технологического стека — инструментов разработки, которые включают языки программирования, фреймворки, системы управления базами данных, компиляторы и т. д.

• Дизайн

После того как завершена аналитика, проект оценен и согласован, разработчики могут переходить к дизайну. Этот этап включает два блока:

Жизненный цикл IT проекта

— разработку UX — дизайн пользовательского интерфейса. UX отвечает за логику построения элементов системы, адаптивность и юзабилити продукта.

— разработку UI — отрисовку элементов интерфейса: блоки, кнопки, иконки, которые собираются в готовый макет.

• Разработка

• Тестирование

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

• Запуск

• Передача прав

• Техническая поддержка

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

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

Информационный бизнес. Основные понятия

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

Заказчики RedLab знают, что всегда могут задать вопрос, уточнить детали и уверены, что их предложения не останутся без ответа. В проектах мы работаем в любых удобных для заказчика трекерах задач и обеспечиваем полную прозрачность процессов разработки. За годы работы мы убедились, что залог создания успешного ИТ-продукта — 100% вовлеченность компании-разработчика, именно поэтому наши специалисты уделяют огромное внимание коммуникации с заказчиком. В результате наши клиенты могут быть уверены в том, что их проекты реализуются компетентными специалистами, бюджет расходуется оптимально, а запуск производится строго в срок, а иногда даже раньше.

Источник: spark.ru

Этапы разработки: 10 шагов к успешному IT-продукту

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

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

Так из чего же состоит жизненный цикл разработки IT-продукта? Давайте рассмотрим путь разработки с соблюдением обязательных условий для получения качественного продукта:

• Подготовительный этап

Перед стартом проекта закладывается фундамент успешного партнерства, заключается NDA. Разработчик предлагает заказчику работу в комфортной для него среде – использует привычные Task Tracker и мессенджеры, чтобы обеспечить качественную коммуникацию. Залог успешного партнерства на этом этапе – способность подрядчика слышать и принимать во внимание ожидания заказчика.

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

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

Когда все вопросы по предварительной оценке улажены, наступает этап проектирования, включающий подэтапы:

1. разработку карты проекта с указанием реперных точек для сверки результатов;
2. проектирование архитектуры программного обеспечения;
3. выбор технологического стека – инструментов разработки, которые включают языки программирования, фреймворки, системы управления базами данных, компиляторы и т. д.

После того как завершена аналитика, проект оценен и согласован, разработчики могут переходить к дизайну. Этот этап включает два блока:

— разработку UX – дизайн пользовательского интерфейса. UX отвечает за логику построения элементов системы, адаптивность и юзабилити продукта.

— разработку UI – отрисовку элементов интерфейса: блоки, кнопки, иконки, которые собираются в готовый макет.

Многие ошибочно полагают, что дизайн – это только о визуальной части. На самом деле дизайн отвечает за формирование пользовательского опыта. Будет ли пользователь чувствовать себя комфортно? Как быстро он сориентируется и обнаружит то, что ему необходимо? Сможет ли он оперативно получить ответ на вопрос и захочет ли вернуться снова?

Другими словами, чем понятнее интерфейс IT- продукта, тем легче пользователю получить результат и совершить целевое действие. Все это и зависит от качества UX/ UI.

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

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

Для этого QA-инженеры могут использовать различные способы тестирования IT-продукта: модульные, интеграционные, функциональные, приемочные.

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

Запуск произведен – разработчики выполнили свою часть работы и передают готовый продукт владельцу. На этом этапе контроль над программной частью и документацией полностью переходит заказчику. Детальные условия передачи прав прописываются в договоре о сотрудничестве между заказчиком и компанией-разработчиком.

• Техническая поддержка

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

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

Источник: vc.ru

Компания «Консалтинг по управлению ИТ»

ИТ стратегия интересна тем, что она может дать для бизнеса, для ИТ службы, а также руководителей этой самой службы.
По результатам обсуждения, проведенного недавно с ИТ менеджерами, учащимися по программе MBA в МИРБИС, был получен список ожидаемых ими выгод от ИТ стратегии:

1. Четкое видение развития ИТ на 1-3 года
2. Четкие планы развития всех областей ИТ
3. Гендиректор понимает выгоды бизнеса от использования ИТ, а также риски неработоспособности ИТ
4. Делегирование нестратегических задач другим сотрудникам ИТ
5. Адекватное финансирование ИТ проектов за счет согласованными с гендиректором и бизнес-менеджерами требования бизнеса к ИТ, целям ИТ и ИТ проектам на 1-3 года
6. Возможность обоснования своего видения развития ИТ и проектов по ИТ
7. Согласованный (а может и увеличенный) ИТ бюджет. Гендиректор и бизнес-менеджеры понимают, на что уходит ИТ бюджет
8. Минимизация трат времени на «бредовые» и/или нереальные задумки гендиректора и бизнес-менеджеров
9. Реализация ИТ директора как специалиста по ИТ
10. Реализация ИТ как менеджера
11. Возможный карьерный рост и повышение личных доходов
12. Больший интерес со стороны других работодателей
13. Более довольные пользователи: они понимают, что ИТ – это очень сложная система, и иногда не работает
14. Пользователи понимают, как работает служба ИТ, куда идут деньги
15. Пользователи и бизнес-менеджеры своевременно готовят ТЗ на приложения и участвуют в их внедрении

Но разработка ИТ стратегии не является простым делом. Если делать это «в лоб», то уйдет много месяцев времени, дофига денег, и не факт, что результат Вас устроит.

Опыт обучения 150 руководителей ИТ служб позволил мне разработать форму и методику разработки ИТ стратегии, достаточно простую для понимания.

Вот форма ИТ стратегии (я бы назвал ее «Пирамидой Михайлова):

Но у тех, кто у меня учился, часто не получается сразу разработать всю ИТ стратегию: на это как времени надо бы затратить пару месяцев, так и с руководством надо долго все согласовывать. В результате, по факту, на разработку и согласование ИТ стратегии, обычно получается от трех месяцев до года.

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

1. Определение целей ИТ, исходя из целей (приоритетов) бизнеса
2. Приведение ИТ проектов в соответствие с целями ИТ и бизнеса
3. Определение требований бизнеса к требуемому через 1-2 года состоянию ИТ
4. Планирование приложений
5. Планирование инфраструктуры ИТ
6. Планирование управления ИТ
7. Объединение всех частей ИТ стратегии

Далее приведено описание 7 этапов разработки ИТ стратегии. Описание краткое, зато с рисунками.

Разработка концепции развития ИТ

Этап 1: Определение целей ИТ, исходя из целей (приоритетов) бизнеса.

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

Этап 2: Приведение ИТ проектов в соответствие с целями ИТ и бизнеса. Оценка приоритетов проектов по ИТ.

Этап 3: Определение требований бизнеса к требуемому через 1-2 года состоянию ИТ. Определение требований бизнеса к приложениям, инфраструктуре ИТ и управлению ИТ.

Разработка требуемого через 1-2 года состояния ИТ

Этап 4: Планирование приложений: анализ текущего уровня автоматизации бизнес-процессов (или ИТ сервисов), планирование требуемого через 1-2 года состояния и проектов по переходу к нему

Этап 5: Планирование инфраструктуры ИТ: анализ текущего состояния, планирование требуемого через 1-2 года состояния и проектов по переходу к нему

Этап 6: Планирование управления ИТ: анализ текущего состояния, планирование требуемого через 1-2 года состояния и проектов по переходу к нему

Этап 7: Объединение всех частей ИТ стратегии. Планирование общего плана проектов по ИТ

Замечания по выполнению этапов:

• Этапы целесообразно выполнять последовательно, не пропуская предшествующие этапы
• На этапах очень желательно участие куратора ИТ (или генерального директора). Существенное участие ИТ директора требуется на всех этапах
• Рекомендуемое время на каждый этап: 2-4 недели. Если хотелось бы выполнить все этапы сразу, то лучше планировать на это от 3-х месяцев. Саму ИТ стратегию можно разработать и быстрее, но потребуется еще время на ее согласование с руководством бизнеса
• Лучше выполнять сразу по несколько этапов: вначале этапы 1,2,3, а потом этапы 4-7
• Первые три этапа можно выполнить быстрее, чем оставшиеся четыре. При этом удастся согласовать ИТ проекты с целями ИТ и бизнеса. Это, конечно, не полноценная ИТ стратегия, но у большинства российских предприятий нет и этого.

Поддержка ИТ стратегии

К сожалению, разработанные планы и стратегии быстро устаревают, становятся неактуальными. Соответственно, стоит заранее планировать периодическое обновление ИТ стратегии. По опыту других компаний, можно предложить следующую регулярность обновления частей ИТ стратегии:

• План проектов по ИТ: раз в 3 месяца, а лучше – раз в месяц
• Требуемое состояние ИТ: раз в полгода, а также при существенных изменениях бизнеса, например, смены руководителей или выхода на новые рынки
• Цели ИТ: раз в год, как впрочем и при существенных изменениях бизнеса

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

P.S. Для тех, кто у меня проходил курс по ИТ стратегии (или хотя бы прочел книгу «ИТ стратегия и основные 15 слайдов, которые ИТ директор может сделать самостоятельно»), предлагаю:

• Бесплатный аудит стратегического управления ИТ и выбор варианта разработки ИТ стратегии, что будет входить в нее входить. Я бы рекомендовал бы совместную разработку ИТ страниц 50-70 текста (и десятка три слайдов в довесок к тексту)
• Разработка ИТ стратегии
• Регулярное обновление ИТ стратегии (настоятельно рекомендовал бы, на отсутствии этого этапа валится 90% разработавших ИТ стратегию)

С уважением, Александр Михайлов, MBA

Источник: www.info-strategy.ru